All of lore.kernel.org
 help / color / mirror / Atom feed
From: Randy Dunlap <rdunlap@infradead.org>
To: Rob Landley <rob@landley.net>
Cc: Byron Stanoszek <bstanoszek@comtime.com>, linux-kernel@vger.kernel.org
Subject: Re: [RFC] rootmpfs
Date: Tue, 09 Apr 2013 10:28:21 -0700	[thread overview]
Message-ID: <51644FB5.9050103@infradead.org> (raw)
In-Reply-To: <1365519128.18069.55@driftwood>

On 04/09/13 07:52, Rob Landley wrote:
> On 04/05/2013 02:53:12 PM, Byron Stanoszek wrote:
>> Rob,
>>
>> FWIW I have a patch to do something like this. It even gives you a rdsize=xxx
>> tunable kernel parameter that lets you specify the size of the tmpfs, which
>> acts like the -osize= mount flag (so phrases like 100M or 20% works). So doing
>> things like 'cat /dev/zero > filename' will not run you out of all available
>> memory. (Note: If you don't specify rdsize= on the kernel command line, it will
>> not convert rootfs to tmpfs).
> 
> In init/do_mounts.c the boot infrastructure already has kernel command line options "rootflags=" and "rootfstype=", so the logical thing to do is probably to hook those up to rootfs. (That way instead of special casing a new option we use the existing tmpfs option parsing.)
> 
> The default tmpfs size is 50%, which solves the "trivial to exhaust memory and panic a kernel running under rootfs" problem. Having one tmpfs also fixes the case that multiple tmpfs mounts (for /home and /var, for example,) have separate memory limits that don't coordinate with each other, so if /home can use 30% and /var can use 30%, that's 60% plus whatever rootfs is already using, so you can easily squeeze the kernel against the wall without meaning to. (Yes, you can make one tmpfs mount and --bind mount from there to elsewhere, I've seen that done. Having rootfs just _be_ tmpfs makes this much easier to track.)
> 
>> See attached.
> 
> You're not actually changing the type of rootfs, you're overmounting it with a second filesystem instance. (Mine hasn't got a "change", it just mounts it correctly the first time, and there's just one rootfs instance.)
> 
> What _is_ wrong with my version is that if you select tmpfs as a module bad things happen; it tries to use code that's not there. I dunno of an #ifdef that distinguishes between module and builtin, so I think I have to add another kconfig symbol...

See include/linux/kconfig.h:  IS_MODULE() and IS_BUILTIN().

> 
> I'll poke at it.


-- 
~Randy

  reply	other threads:[~2013-04-09 17:28 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-03 12:30 [RFC] rootmpfs Rob Landley
2013-04-03 12:32 ` Rob Landley
2013-04-05 19:53 ` Byron Stanoszek
2013-04-09 14:52   ` Rob Landley
2013-04-09 17:28     ` Randy Dunlap [this message]
2013-04-10 17:23       ` Rob Landley
2013-04-10 13:43 ` Robin Holt
2013-04-11 17:25 ` Lauri Kasanen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51644FB5.9050103@infradead.org \
    --to=rdunlap@infradead.org \
    --cc=bstanoszek@comtime.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rob@landley.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.