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

On 04/09/2013 12:28:21 PM, Randy Dunlap wrote:
> 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().

Good to know, thanks.

(It turns out I was looking at a distro kernel directory and vanilla  
only lets TMPFS be static anyway, but I should still use that in case  
it changes, and I think I still need to wire up a rootfsflags argument.)

Rob

  reply	other threads:[~2013-04-10 17:23 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
2013-04-10 17:23       ` Rob Landley [this message]
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=1365614602.18069.65@driftwood \
    --to=rob@landley.net \
    --cc=bstanoszek@comtime.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rdunlap@infradead.org \
    /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.