Rootfs mounted from user space - problem with umount

Rootfs mounted from user space - problem with umount

[John Zielinski]

I modified my kernel so that rootfs uses tmpfs (shm) instead of ramfs.  
I also modified it so that it allows mounting from user space.  My 
problem is when I try to umount it, umount hangs.  I checked it's 
proc/#/wchan entry and it's stuck in rwsem_down_write_failed.  Now the 
strange thing is I can mount it again from another console and then 
umount it with no problems.  It just hangs the first time.  I know I'm 
missing something simple but I can't seem to find it.

Here's the mods I made:

diff -urNX dontdiff linux.old/drivers/block/Kconfig linux/drivers/block/Kconfig
--- linux.old/drivers/block/Kconfig	2003-10-25 14:43:07.000000000 -0400
+++ linux/drivers/block/Kconfig	2003-11-28 23:43:05.000000000 -0500
@@ -320,6 +320,24 @@
 	  "real" root file system, etc. See <file:Documentation/initrd.txt>
 	  for details.
 
+config SHM_ROOTFS
+	bool "Use tmpfs (shm) instead of ramfs for rootfs"
+	depends on BLK_DEV_INITRD
+	default n
+	help
+	  This option switches rootfs so that it uses tmpfs rather than ramfs
+	  for it's file storage.  This makes rootfs swappable so having a large
+	  initrd or initramfs image won't eat up valuable RAM.
+	  
+	  You don't have to select the tmpfs option in the file system menu
+	  as that's only for user space mounting.  
+	  
+config RAMFS_ROOTFS
+	bool 
+	depends on !SHM_ROOTFS
+	default y
+	select RAMFS
+
 config LBD
 	bool "Support for Large Block Devices"
 	depends on X86 || MIPS32 || PPC32 || ARCH_S390_31 || SUPERH
diff -urNX dontdiff linux.old/fs/Kconfig linux/fs/Kconfig
--- linux.old/fs/Kconfig	2003-10-25 14:43:51.000000000 -0400
+++ linux/fs/Kconfig	2003-11-28 23:20:48.000000000 -0500
@@ -879,8 +879,8 @@
 config HUGETLB_PAGE
 	def_bool HUGETLBFS
 
-config RAMFS
-	bool
+config RAMFS 
+	tristate "Ramfs file system support"
 	default y
 	---help---
 	  Ramfs is a file system which keeps all files in RAM. It allows
diff -urNX dontdiff linux.old/fs/ramfs/inode.c linux/fs/ramfs/inode.c
--- linux.old/fs/ramfs/inode.c	2003-10-25 14:43:21.000000000 -0400
+++ linux/fs/ramfs/inode.c	2003-11-28 23:32:21.000000000 -0500
@@ -204,22 +204,26 @@
 	return get_sb_nodev(fs_type, flags, data, ramfs_fill_super);
 }
 
+#ifdef CONFIG_RAMFS_ROOTFS
 static struct super_block *rootfs_get_sb(struct file_system_type *fs_type,
 	int flags, const char *dev_name, void *data)
 {
 	return get_sb_nodev(fs_type, flags|MS_NOUSER, data, ramfs_fill_super);
 }
+#endif
 
 static struct file_system_type ramfs_fs_type = {
 	.name		= "ramfs",
 	.get_sb		= ramfs_get_sb,
 	.kill_sb	= kill_litter_super,
 };
+#ifdef CONFIG_RAMFS_ROOTFS
 static struct file_system_type rootfs_fs_type = {
 	.name		= "rootfs",
 	.get_sb		= rootfs_get_sb,
 	.kill_sb	= kill_litter_super,
 };
+#endif
 
 static int __init init_ramfs_fs(void)
 {
@@ -234,9 +238,11 @@
 module_init(init_ramfs_fs)
 module_exit(exit_ramfs_fs)
 
+#ifdef CONFIG_RAMFS_ROOTFS
 int __init init_rootfs(void)
 {
 	return register_filesystem(&rootfs_fs_type);
 }
+#endif
 
 MODULE_LICENSE("GPL");
diff -urNX dontdiff linux.old/mm/shmem.c linux/mm/shmem.c
--- linux.old/mm/shmem.c	2003-10-25 14:43:30.000000000 -0400
+++ linux/mm/shmem.c	2003-11-29 00:00:37.000000000 -0500
@@ -1773,7 +1773,7 @@
 	sb->s_fs_info = NULL;
 }
 
-static kmem_cache_t *shmem_inode_cachep;
+static kmem_cache_t *shmem_inode_cachep = NULL;
 
 static struct inode *shmem_alloc_inode(struct super_block *sb)
 {
@@ -1801,12 +1801,14 @@
 
 static int init_inodecache(void)
 {
-	shmem_inode_cachep = kmem_cache_create("shmem_inode_cache",
-					     sizeof(struct shmem_inode_info),
-					     0, SLAB_HWCACHE_ALIGN|SLAB_RECLAIM_ACCOUNT,
-					     init_once, NULL);
-	if (shmem_inode_cachep == NULL)
-		return -ENOMEM;
+	if (!shmem_inode_cachep) {
+		shmem_inode_cachep = kmem_cache_create("shmem_inode_cache",
+						     sizeof(struct shmem_inode_info),
+						     0, SLAB_HWCACHE_ALIGN|SLAB_RECLAIM_ACCOUNT,
+						     init_once, NULL);
+		if (shmem_inode_cachep == NULL)
+			return -ENOMEM;
+	}
 	return 0;
 }
 
@@ -2008,3 +2010,29 @@
 }
 
 EXPORT_SYMBOL(shmem_file_setup);
+
+#ifdef CONFIG_SHM_ROOTFS
+static struct super_block *rootfs_sb = NULL;
+
+static struct super_block *rootfs_get_sb(struct file_system_type *fs_type,
+	int flags, const char *dev_name, void *data)
+{
+	if (!rootfs_sb) {
+		rootfs_sb = get_sb_single(fs_type, flags, data, shmem_fill_super);
+		shmem_set_size(SHMEM_SB(rootfs_sb), ULONG_MAX, ULONG_MAX);
+	}
+	return rootfs_sb;
+}
+
+static struct file_system_type rootfs_fs_type = {
+	.name		= "rootfs",
+	.get_sb		= rootfs_get_sb,
+	.kill_sb	= kill_litter_super,
+};
+
+int __init init_rootfs(void)
+{
+	init_inodecache();
+	return register_filesystem(&rootfs_fs_type);
+}
+#endif


John

Re: Rootfs mounted from user space - problem with umount

[William Lee Irwin III]

On Sat, Nov 29, 2003 at 12:24:31AM -0500, John Zielinski wrote:
> I modified my kernel so that rootfs uses tmpfs (shm) instead of ramfs.  
> I also modified it so that it allows mounting from user space.  My 
> problem is when I try to umount it, umount hangs.  I checked it's 
> proc/#/wchan entry and it's stuck in rwsem_down_write_failed.  Now the 
> strange thing is I can mount it again from another console and then 
> umount it with no problems.  It just hangs the first time.  I know I'm 
> missing something simple but I can't seem to find it.

Could you do a sysrq t and send in a backtrace?


-- wli

Re: Rootfs mounted from user space - problem with umount

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 397 bytes --]

On Sat, 29 Nov 2003 00:24:31 EST, John Zielinski <grim@undead.cc>  said:

> +	  This option switches rootfs so that it uses tmpfs rather than ramfs
> +	  for it's file storage.  This makes rootfs swappable so having a large
> +	  initrd or initramfs image won't eat up valuable RAM.

I'm missing something - why not use an initrd and pivot_root and then
unmount the old root?  Seems to work here.

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Rootfs mounted from user space - problem with umount

[John Zielinski]

William Lee Irwin III wrote:

>
>Could you do a sysrq t and send in a backtrace?
>
>  
>
Here's the trace for umount:

umount        D DF9D98C0  3920   380    245                     (NOTLB)
def55f18 00000086 c015be66 df9d98c0 dffe0900 def55f3c c0169f59 def55f00
       def55f00 def55ef8 00108291 0c4cb8db 00000042 df0ec6a0 dffe2640 00000002
       df0ec6a0 def55f44 c01e169c dffe0900 dffe2644 dffe2644 dffe2644 df0ec6a0
Call Trace:
 [<c015be66>] path_release+0x16/0x40
 [<c0169f59>] umount_tree+0xa9/0x100
 [<c01e169c>] rwsem_down_write_failed+0x8c/0x140
 [<c0155e0b>] .text.lock.super+0x12/0x187
 [<c016a22c>] sys_umount+0x3c/0x90
 [<c016a299>] sys_oldumount+0x19/0x20
 [<c010938f>] syscall_call+0x7/0xb


I'm running the 2.6.0-test9 kernel.

John

Re: Rootfs mounted from user space - problem with umount

[William Lee Irwin III]

William Lee Irwin III wrote:
>> Could you do a sysrq t and send in a backtrace?

On Sat, Nov 29, 2003 at 01:14:34AM -0500, John Zielinski wrote:
> Here's the trace for umount:
> umount        D DF9D98C0  3920   380    245                     (NOTLB)
[...]
> Call Trace:
> [<c015be66>] path_release+0x16/0x40
> [<c0169f59>] umount_tree+0xa9/0x100
> [<c01e169c>] rwsem_down_write_failed+0x8c/0x140
> [<c0155e0b>] .text.lock.super+0x12/0x187
> [<c016a22c>] sys_umount+0x3c/0x90
> [<c016a299>] sys_oldumount+0x19/0x20
> [<c010938f>] syscall_call+0x7/0xb

Looks like either namespace->sem or sb->s_umount; you should be able
to put some instrumentation code in down_write() and/or down_read() to
see who acquired it first by checking to see if the sem acquired belongs
to rootfs' sb or some namespace (doubtful you'll create many of them).


-- wli

Re: Rootfs mounted from user space - problem with umount

[John Zielinski]

Valdis.Kletnieks@vt.edu wrote:

>I'm missing something - why not use an initrd and pivot_root and then
>unmount the old root?  Seems to work here.
>  
>

I'm using the 2.6.0-test9 kernel and initramfs to store video mode data 
that my kernel mods will read during boot.  Using cpio is a lot easier 
than making a file system using the loopback device.   I want to keep 
the rootfs around since I can modify it and then cpio it back up in a 
shutdown script for next boot.

If I used initrd I'd also have to set up a usable filesystem.  This way 
I can just have data in there.

John

Re: Rootfs mounted from user space - problem with umount

[John Zielinski]

William Lee Irwin III wrote:

>Looks like either namespace->sem or sb->s_umount; you should be able
>to put some instrumentation code in down_write() and/or down_read() to
>see who acquired it first by checking to see if the sem acquired belongs
>to rootfs' sb or some namespace (doubtful you'll create many of them).
>
>
>  
>

Found it.  It was a stupid mistake.  I made the get_sb function return 
the same superblock when it was still get_sb_nodev.  When I switched it 
to the proper get_sb_single I forgot to remove the code that returned 
the old sb so it wasn't calling get_sb_single to increase the sb's usage 
count.  Doh!

John

Re: Rootfs mounted from user space - problem with umount

[William Lee Irwin III]

William Lee Irwin III wrote:
>> Looks like either namespace->sem or sb->s_umount; you should be able
>> to put some instrumentation code in down_write() and/or down_read() to
>> see who acquired it first by checking to see if the sem acquired belongs
>> to rootfs' sb or some namespace (doubtful you'll create many of them).

On Sat, Nov 29, 2003 at 04:40:51AM -0500, John Zielinski wrote:
> Found it.  It was a stupid mistake.  I made the get_sb function return 
> the same superblock when it was still get_sb_nodev.  When I switched it 
> to the proper get_sb_single I forgot to remove the code that returned 
> the old sb so it wasn't calling get_sb_single to increase the sb's usage 
> count.  Doh!

Cool! So when do we get a swappable initrd's/initramfs's?


-- wli

Re: Rootfs mounted from user space - problem with umount

[John Zielinski]

William Lee Irwin III wrote:

>Cool! So when do we get a swappable initrd's/initramfs's?
>
>  
>
It was 5 in the morning and I ran out of cola.  :(   Here's the updated 
patch.  I added an extra error check just in case we ran out of memory 
initializing shm's inode cache.  Shm defaults to half of available ram 
which should be a good limit.  Otherwise the machine might not boot if 
we fill up ram with that early on.   And we can probably remount it with 
a new set of limits later.   Can the swap device be started in early 
userspace?

Just found something while testing.  Looks like we do need CONFIG_TMPFS 
or else we get a kernel oops on bootup.  I'll force that if SHM_ROOTFS 
is selected.  It adds some extra code that the internal kernel use of 
shmem didn't need.   If you already use tmpfs that won't matter and 
ramfs can now be deselected.

Let me know if you find anything wrong with this.

diff -urNX dontdiff linux-2.6.0-test9/drivers/block/Kconfig linux/drivers/block/Kconfig
--- linux-2.6.0-test9/drivers/block/Kconfig	2003-10-25 14:43:07.000000000 -0400
+++ linux/drivers/block/Kconfig	2003-11-29 14:50:02.000000000 -0500
@@ -320,6 +320,22 @@
 	  "real" root file system, etc. See <file:Documentation/initrd.txt>
 	  for details.
 
+config SHM_ROOTFS
+	bool "Use tmpfs (shm) instead of ramfs for rootfs"
+	depends on BLK_DEV_INITRD
+	default n
+	select TMPFS
+	help
+	  This option switches rootfs so that it uses tmpfs rather than ramfs
+	  for it's file storage.  This makes rootfs swappable so having a large
+	  initrd or initramfs image won't eat up valuable RAM.
+	  
+config RAMFS_ROOTFS
+	bool 
+	depends on !SHM_ROOTFS
+	default y
+	select RAMFS
+
 config LBD
 	bool "Support for Large Block Devices"
 	depends on X86 || MIPS32 || PPC32 || ARCH_S390_31 || SUPERH
diff -urNX dontdiff linux-2.6.0-test9/fs/Kconfig linux/fs/Kconfig
--- linux-2.6.0-test9/fs/Kconfig	2003-10-25 14:43:51.000000000 -0400
+++ linux/fs/Kconfig	2003-11-28 23:20:48.000000000 -0500
@@ -879,8 +879,8 @@
 config HUGETLB_PAGE
 	def_bool HUGETLBFS
 
-config RAMFS
-	bool
+config RAMFS 
+	tristate "Ramfs file system support"
 	default y
 	---help---
 	  Ramfs is a file system which keeps all files in RAM. It allows
diff -urNX dontdiff linux-2.6.0-test9/fs/ramfs/inode.c linux/fs/ramfs/inode.c
--- linux-2.6.0-test9/fs/ramfs/inode.c	2003-10-25 14:43:21.000000000 -0400
+++ linux/fs/ramfs/inode.c	2003-11-29 00:13:33.000000000 -0500
@@ -204,22 +204,26 @@
 	return get_sb_nodev(fs_type, flags, data, ramfs_fill_super);
 }
 
+#ifdef CONFIG_RAMFS_ROOTFS
 static struct super_block *rootfs_get_sb(struct file_system_type *fs_type,
 	int flags, const char *dev_name, void *data)
 {
 	return get_sb_nodev(fs_type, flags|MS_NOUSER, data, ramfs_fill_super);
 }
+#endif
 
 static struct file_system_type ramfs_fs_type = {
 	.name		= "ramfs",
 	.get_sb		= ramfs_get_sb,
 	.kill_sb	= kill_litter_super,
 };
+#ifdef CONFIG_RAMFS_ROOTFS
 static struct file_system_type rootfs_fs_type = {
 	.name		= "rootfs",
 	.get_sb		= rootfs_get_sb,
 	.kill_sb	= kill_litter_super,
 };
+#endif
 
 static int __init init_ramfs_fs(void)
 {
@@ -234,9 +238,11 @@
 module_init(init_ramfs_fs)
 module_exit(exit_ramfs_fs)
 
+#ifdef CONFIG_RAMFS_ROOTFS
 int __init init_rootfs(void)
 {
 	return register_filesystem(&rootfs_fs_type);
 }
+#endif
 
 MODULE_LICENSE("GPL");
diff -urNX dontdiff linux-2.6.0-test9/mm/shmem.c linux/mm/shmem.c
--- linux-2.6.0-test9/mm/shmem.c	2003-10-25 14:43:30.000000000 -0400
+++ linux/mm/shmem.c	2003-11-29 14:24:37.000000000 -0500
@@ -1773,7 +1773,7 @@
 	sb->s_fs_info = NULL;
 }
 
-static kmem_cache_t *shmem_inode_cachep;
+static kmem_cache_t *shmem_inode_cachep = NULL;
 
 static struct inode *shmem_alloc_inode(struct super_block *sb)
 {
@@ -1801,12 +1801,14 @@
 
 static int init_inodecache(void)
 {
-	shmem_inode_cachep = kmem_cache_create("shmem_inode_cache",
-					     sizeof(struct shmem_inode_info),
-					     0, SLAB_HWCACHE_ALIGN|SLAB_RECLAIM_ACCOUNT,
-					     init_once, NULL);
-	if (shmem_inode_cachep == NULL)
-		return -ENOMEM;
+	if (!shmem_inode_cachep) {
+		shmem_inode_cachep = kmem_cache_create("shmem_inode_cache",
+						     sizeof(struct shmem_inode_info),
+						     0, SLAB_HWCACHE_ALIGN|SLAB_RECLAIM_ACCOUNT,
+						     init_once, NULL);
+		if (shmem_inode_cachep == NULL)
+			return -ENOMEM;
+	}
 	return 0;
 }
 
@@ -2008,3 +2010,24 @@
 }
 
 EXPORT_SYMBOL(shmem_file_setup);
+
+#ifdef CONFIG_SHM_ROOTFS
+static struct super_block *rootfs_get_sb(struct file_system_type *fs_type,
+	int flags, const char *dev_name, void *data)
+{
+	return get_sb_single(fs_type, flags, data, shmem_fill_super);
+}
+
+static struct file_system_type rootfs_fs_type = {
+	.name		= "rootfs",
+	.get_sb		= rootfs_get_sb,
+	.kill_sb	= kill_litter_super,
+};
+
+int __init init_rootfs(void)
+{
+	if (init_inodecache())
+	    panic("Can't initialize shm inode cache");
+	return register_filesystem(&rootfs_fs_type);
+}
+#endif


John

Re: Rootfs mounted from user space - problem with umount

[John Zielinski]

John Zielinski wrote:

> +      +config RAMFS_ROOTFS
> +    bool +    depends on !SHM_ROOTFS
> +    default y
> +    select RAMFS
> +
>  
>  
>
> -config RAMFS
> -    bool
> +config RAMFS +    tristate "Ramfs file system support"
>     default y


Doh.  Looks like my mailer combined a few lines when I pasted the patch 
into my message.   There's three places shown above where the + is not 
at the start of the line.   Just edit that before applying the patch.

John

Re: Rootfs mounted from user space - problem with umount

[William Lee Irwin III]

On Sat, Nov 29, 2003 at 03:20:36PM -0500, John Zielinski wrote:
> Doh.  Looks like my mailer combined a few lines when I pasted the patch 
> into my message.   There's three places shown above where the + is not 
> at the start of the line.   Just edit that before applying the patch.

Best to just attach it; cut and paste doesn't preserve whitespace.


-- wli

Re: Rootfs mounted from user space - problem with umount

[John Zielinski]

William Lee Irwin III wrote:

>Best to just attach it; cut and paste doesn't preserve whitespace.
>  
>

I mailx the patch to my email and then cut and paste it from one message 
to another.  Since it's the same program it keeps the same formatting 
(it marks it as fixed width).   I just saved that message to a file and 
it's formatted properly.   It even looks ok when using "View Message 
Source".   I sent the patch back to my test box and it's a 100% match to 
the original.  Looks like the merged lines were a display bug in 
Thunderbird...

John

Re: Rootfs mounted from user space - problem with umount

[Sean Neakums]

John Zielinski <grim@undead.cc> writes:

> William Lee Irwin III wrote:
>
>>Best to just attach it; cut and paste doesn't preserve whitespace.
>
> I mailx the patch to my email and then cut and paste it from one
> message to another.  Since it's the same program it keeps the same
> formatting (it marks it as fixed width).   I just saved that message
> to a file and it's formatted properly.   It even looks ok when using
> "View Message Source".   I sent the patch back to my test box and it's
> a 100% match to the original.  Looks like the merged lines were a
> display bug in Thunderbird...

I don't think so; it's mangled here in Gnus, too.

Re: Rootfs mounted from user space - problem with umount

[John Zielinski]

Sean Neakums wrote:

>I don't think so; it's mangled here in Gnus, too.
>
>  
>
Can you check the message source or save the mail to your HD and see if 
it's mangled there as well?  The lines that cause the problems have an 
extra space at the end of them.   But that's how the were in my original 
patch file.  I forwarded that message to myself and checked that actual 
file on my mail server and the patch was 100% like the original.  It 
_is_ a display bug.

I'll install samba onto that test machine so I can make the patches into 
attachments.  (Yes, this is a windows box.  Please forgive me!   Once I 
get a new monitor for my SMP linux box it'll become my web/email machine).

John

[OT] Re: Rootfs mounted from user space - problem with umount

[Sean Neakums]

John Zielinski <grim@undead.cc> writes:

> Sean Neakums wrote:
>
>>I don't think so; it's mangled here in Gnus, too.
>
> Can you check the message source or save the mail to your HD and see
> if it's mangled there as well?  The lines that cause the problems have
> an extra space at the end of them.   But that's how the were in my
> original patch file.  I forwarded that message to myself and checked
> that actual file on my mail server and the patch was 100% like the
> original.  It _is_ a display bug.

You're right, the patch looks fine in the raw message.  However, the
message's Content-Type header specifies "format=flowed", and according
to RFC 2646, if a line ends in one or more spaces, it is to be flowed
(sec 4.2, paragraph 3).  So it is not a display bug.