[PATCH 0/5] initmpfs v2: use tmpfs instead of ramfs for rootfs

[PATCH 0/5] initmpfs v2: use tmpfs instead of ramfs for rootfs

[Rob Landley]

Use tmpfs for rootfs when CONFIG_TMPFS=y and there's no root=.
Specify rootfstype=ramfs to get the old initramfs behavior.

The previous initramfs code provided a fairly crappy root filesystem:
didn't let you --bind mount directories out of it, reported zero
size/usage so it didn't show up in "df" and couldn't run things like
rpm that query available space before proceeding, would fill up all
available memory and panic the system if you wrote too much to it...

Using tmpfs instead provides a much better root filesystem.

Changes from last time: use test_and_set_bit() for "once" logic.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[PATCH 4/5] initmpfs v2: Make rootfs use tmpfs when CONFIG_TMPFS enabled.

[Rob Landley]

From: Rob Landley <rob@landley.net>

Conditionally call the appropriate fs_init function and fill_super functions.
Add a use once guard to shmem_init() to simply succeed on a second call.

(Note that IS_ENABLED() is a compile time constant so dead code elimination
removes unused function calls when CONFIG_TMPFS is disabled.)

Signed-off-by: Rob Landley <rob@landley.net>
---

 init/do_mounts.c |   10 ++++++++--
 mm/shmem.c       |    4 ++++
 2 files changed, 12 insertions(+), 2 deletions(-)

--- initold/init/do_mounts.c	2013-06-27 00:02:26.283442977 -0500
+++ initwork/init/do_mounts.c	2013-06-27 00:45:21.599550312 -0500
@@ -27,6 +27,7 @@
 #include <linux/fs_struct.h>
 #include <linux/slab.h>
 #include <linux/ramfs.h>
+#include <linux/shmem_fs.h>
 
 #include <linux/nfs_fs.h>
 #include <linux/nfs_fs_sb.h>
@@ -598,7 +597,8 @@
 	if (test_and_set_bit(1, &once))
 		return ERR_PTR(-ENODEV);
 
-	return mount_nodev(fs_type, flags, data, ramfs_fill_super);
+	return mount_nodev(fs_type, flags, data,
+		IS_ENABLED(CONFIG_TMPFS) ? shmem_fill_super : ramfs_fill_super);
 }
 
 static struct file_system_type rootfs_fs_type = {
@@ -614,7 +614,11 @@
 	if (err)
 		return err;
 
-	err = init_ramfs_fs();
+	if (IS_ENABLED(CONFIG_TMPFS))
+		err = shmem_init();
+	else
+		err = init_ramfs_fs();
+
 	if (err)
 		unregister_filesystem(&rootfs_fs_type);
 
--- initold/mm/shmem.c	2013-06-25 13:09:22.215743137 -0500
+++ initwork/mm/shmem.c	2013-06-27 00:16:58.195479317 -0500
@@ -2816,6 +2816,10 @@
 {
 	int error;
 
+	/* If rootfs called this, don't re-init */
+	if (shmem_inode_cachep)
+		return 0;
+
 	error = bdi_init(&shmem_backing_dev_info);
 	if (error)
 		goto out4;

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 0/5] initmpfs v2: use tmpfs instead of ramfs for rootfs

[Andrew Morton]

On Tue, 16 Jul 2013 08:31:13 -0700 (PDT) Rob Landley <rob@landley.net> wrote:

> Use tmpfs for rootfs when CONFIG_TMPFS=y and there's no root=.
> Specify rootfstype=ramfs to get the old initramfs behavior.
> 
> The previous initramfs code provided a fairly crappy root filesystem:
> didn't let you --bind mount directories out of it, reported zero
> size/usage so it didn't show up in "df" and couldn't run things like
> rpm that query available space before proceeding, would fill up all
> available memory and panic the system if you wrote too much to it...

The df problem and the mount --bind thing are ramfs issues, are they
not?  Can we fix them?  If so, that's a less intrusive change, and we
also get a fixed ramfs.

> Using tmpfs instead provides a much better root filesystem.
> 
> Changes from last time: use test_and_set_bit() for "once" logic.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 0/5] initmpfs v2: use tmpfs instead of ramfs for rootfs

[Hugh Dickins]

On Wed, 17 Jul 2013, Andrew Morton wrote:
> On Tue, 16 Jul 2013 08:31:13 -0700 (PDT) Rob Landley <rob@landley.net> wrote:
> 
> > Use tmpfs for rootfs when CONFIG_TMPFS=y and there's no root=.
> > Specify rootfstype=ramfs to get the old initramfs behavior.
> > 
> > The previous initramfs code provided a fairly crappy root filesystem:
> > didn't let you --bind mount directories out of it, reported zero
> > size/usage so it didn't show up in "df" and couldn't run things like
> > rpm that query available space before proceeding, would fill up all
> > available memory and panic the system if you wrote too much to it...
> 
> The df problem and the mount --bind thing are ramfs issues, are they
> not?  Can we fix them?  If so, that's a less intrusive change, and we
> also get a fixed ramfs.

I'll leave others to comment on "mount --bind", but with regard to "df":
yes, we could enhance ramfs with accounting such as tmpfs has, to allow
it to support non-0 "df".  We could have done so years ago; but have
always preferred to leave ramfs as minimal, than import tmpfs features
into it one by one.

I prefer Rob's approach of making tmpfs usable for rootfs.

Hugh

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 0/5] initmpfs v2: use tmpfs instead of ramfs for rootfs

[Rob Landley]

Andrew: I'll save you the time of reading this message.

   tl;dr: "I agree with what Hugh said".

You're welcome. :)

On 07/17/2013 07:15:29 PM, Hugh Dickins wrote:
> On Wed, 17 Jul 2013, Andrew Morton wrote:
> > On Tue, 16 Jul 2013 08:31:13 -0700 (PDT) Rob Landley  
> <rob@landley.net> wrote:
> >
> > > Use tmpfs for rootfs when CONFIG_TMPFS=y and there's no root=.
> > > Specify rootfstype=ramfs to get the old initramfs behavior.
> > >
> > > The previous initramfs code provided a fairly crappy root  
> filesystem:
> > > didn't let you --bind mount directories out of it, reported zero
> > > size/usage so it didn't show up in "df" and couldn't run things  
> like
> > > rpm that query available space before proceeding, would fill up  
> all
> > > available memory and panic the system if you wrote too much to  
> it...
> >
> > The df problem and the mount --bind thing are ramfs issues, are they
> > not?  Can we fix them?  If so, that's a less intrusive change, and  
> we
> > also get a fixed ramfs.
> 
> I'll leave others to comment on "mount --bind",

It's unrelated to tmpfs but _is_ related to exposing a non-broken rootfs
to the user.

> but with regard to "df":
> yes, we could enhance ramfs with accounting such as tmpfs has, to  
> allow
> it to support non-0 "df".  We could have done so years ago; but have
> always preferred to leave ramfs as minimal, than import tmpfs features
> into it one by one.

Ramfs reporting 0 size is not a new issue, here it is 13 years ago:

http://lkml.indiana.edu/hypermail/linux/kernel/0011.2/0098.html

And people proposed adding resource limits to ramfs at the time (yes,
13 years ago):

http://lkml.indiana.edu/hypermail/linux/kernel/0011.2/0713.html

And Linus complained about complicating ramfs which he thought was a  
good
educational example and could be turned into a reusable code library.
(Somewhere around  
http://lkml.indiana.edu/hypermail/linux/kernel/0112.3/0257.html
or http://lkml.indiana.edu/hypermail/linux/kernel/0101.0/1167.html or...
I'd have to dig for that one. I remember reading it but my google roll
missed.)

Way back when Linus also mentioned embedded users benefitting from
rootfs, ala:

http://lkml.indiana.edu/hypermail/linux/kernel/0112.3/0307.html

Which is why I documented rootfs to be ramfs "or tmpfs, if that's
enabled" back in 2005:

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/filesystems/ramfs-rootfs-initramfs.txt#n57

And when I found out it still wasn't the case a year later I went
"um, hey!" on the list, but ironically I got pushback from the same
guy who objected to my perl removal patches as an "academic"
exercise because it's not how _he_ uses linux...

http://lkml.indiana.edu/hypermail/linux/kernel/0607.3/2480.html
https://lkml.org/lkml/2013/3/20/321

(And you wonder why embedded guys don't speak up more? I'm an
outright "bullhorn and plackard" guy in this community. Random
example: a guy named Rich Felker has been hanging out on the
busybox and uclibc lists and IRC channels for years, and recently
wrote musl-libc.org from "git init" to "builds linux from scratch"
in 2 years. He's on the posix committe list and posts there
multiple times per week. Number of times he's posted to
linux-kernel: zero. I'm sure Sarah Sharp just facepalmed...)

I was recently reminded of initmpfs because I'm finishing up a
contract at Cray and they wanted to do this on their supercomputers
and I went "oh, that's easy", and then had to make it work.
(Embedded and supercomputing have always been closer to each other
than either is to the desktop...) This is very much Not My Area
but I've been waiting a _decade_ for other people to do this and
nada. Really, you could see this as just "fixing my documentation"
from way back when, by changing the code to match the docs. :)

> I prefer Rob's approach of making tmpfs usable for rootfs.

Me too. The resource accounting logic in tmpfs is hundreds of lines,
with shmem_default_max_blocks and shmem_default_max_inodes to specify
default size limits, mount-time option parsing to specify different
values for those limits, plus remount logic (what if you specify a
smaller size after the fact?), plus displaying the settings per-mount
in /proc/mounts... see mm/shmem.c lines 2414 through 2581 for the
largest chunk of it.

That's why we got tmpfs/shmfs as a separate filesystem in the first
place: it's a design decision. Ramfs is intentionally minimalist.

Ramfs can't say how big it is because it doesn't _know_ how big it is.
If you write unlimited data to ramfs, the OOM killer zaps everything but
init and then the system hangs in a page eviction loop. (The OOM killer
can't free pinned page cache with nowhere to evict it to.)

My patch series switching over tmpfs is much smaller than the tmpfs
size accounting code, and we get the swap backing store for free. Plus
hooking up years-old existing tested code (instead of putting new  
untested
logic in the boot path), without duplicating functionality.

I.E. "what Hugh said."

Rob
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 0/5] initmpfs v2: use tmpfs instead of ramfs for rootfs

[H. Peter Anvin]

On 07/17/2013 04:06 PM, Andrew Morton wrote:
> On Tue, 16 Jul 2013 08:31:13 -0700 (PDT) Rob Landley <rob@landley.net> wrote:
> 
>> Use tmpfs for rootfs when CONFIG_TMPFS=y and there's no root=.
>> Specify rootfstype=ramfs to get the old initramfs behavior.
>>
>> The previous initramfs code provided a fairly crappy root filesystem:
>> didn't let you --bind mount directories out of it, reported zero
>> size/usage so it didn't show up in "df" and couldn't run things like
>> rpm that query available space before proceeding, would fill up all
>> available memory and panic the system if you wrote too much to it...
> 
> The df problem and the mount --bind thing are ramfs issues, are they
> not?  Can we fix them?  If so, that's a less intrusive change, and we
> also get a fixed ramfs.
> 

mount --bind might be useful to fix for ramfs in general (as ramfs
should provide minimal standard filesystem functionality, and that one
counts, I believe), but honestly... we should have had tmpfs as a root
filesystem option either as rootfs or as an automatic overmount a long
time ago.

The automatic overmount option (that is tmpfs on top of rootfs) is nice
in some ways, as it makes garbage-collecting the inittmpfs trivial; this
might save some boot time in the more conventional root scenarios.  On
the other hand, it doesn't exactly seem to be a big problem to just
unlink everything.

	-hpa

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[PATCH 0/5] initmpfs v2: use tmpfs instead of ramfs for rootfs

[Rob Landley]

Use tmpfs for rootfs when CONFIG_TMPFS=y and there's no root=.
Specify rootfstype=ramfs to get the old initramfs behavior.

The previous initramfs code provided a fairly crappy root filesystem:
didn't let you --bind mount directories out of it, reported zero
size/usage so it didn't show up in "df" and couldn't run things like
rpm that query available space before proceeding, would fill up all
available memory and panic the system if you wrote too much to it...

Using tmpfs instead provides a much better root filesystem.

Changes from v1: use test_and_set_bit() for "once" logic.

Changes from this morning's send: none, just hopefully not screwing
up the message-id this time trying to make it a reply to another message
via cut and paste...

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[PATCH 4/5] initmpfs v2: Make rootfs use tmpfs when CONFIG_TMPFS enabled.

[Rob Landley]

From: Rob Landley <rob@landley.net>

Conditionally call the appropriate fs_init function and fill_super functions.
Add a use once guard to shmem_init() to simply succeed on a second call.

(Note that IS_ENABLED() is a compile time constant so dead code elimination
removes unused function calls when CONFIG_TMPFS is disabled.)

Signed-off-by: Rob Landley <rob@landley.net>
---

 init/do_mounts.c |   10 ++++++++--
 mm/shmem.c       |    4 ++++
 2 files changed, 12 insertions(+), 2 deletions(-)

--- initold/init/do_mounts.c	2013-06-27 00:02:26.283442977 -0500
+++ initwork/init/do_mounts.c	2013-06-27 00:45:21.599550312 -0500
@@ -27,6 +27,7 @@
 #include <linux/fs_struct.h>
 #include <linux/slab.h>
 #include <linux/ramfs.h>
+#include <linux/shmem_fs.h>
 
 #include <linux/nfs_fs.h>
 #include <linux/nfs_fs_sb.h>
@@ -598,7 +597,8 @@
 	if (test_and_set_bit(1, &once))
 		return ERR_PTR(-ENODEV);
 
-	return mount_nodev(fs_type, flags, data, ramfs_fill_super);
+	return mount_nodev(fs_type, flags, data,
+		IS_ENABLED(CONFIG_TMPFS) ? shmem_fill_super : ramfs_fill_super);
 }
 
 static struct file_system_type rootfs_fs_type = {
@@ -614,7 +614,11 @@
 	if (err)
 		return err;
 
-	err = init_ramfs_fs();
+	if (IS_ENABLED(CONFIG_TMPFS))
+		err = shmem_init();
+	else
+		err = init_ramfs_fs();
+
 	if (err)
 		unregister_filesystem(&rootfs_fs_type);
 
--- initold/mm/shmem.c	2013-06-25 13:09:22.215743137 -0500
+++ initwork/mm/shmem.c	2013-06-27 00:16:58.195479317 -0500
@@ -2816,6 +2816,10 @@
 {
 	int error;
 
+	/* If rootfs called this, don't re-init */
+	if (shmem_inode_cachep)
+		return 0;
+
 	error = bdi_init(&shmem_backing_dev_info);
 	if (error)
 		goto out4;

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>