Configuration system bug? : tmpfs listing in /proc/filesystems when TMPFS was not configured!?

Configuration system bug? : tmpfs listing in /proc/filesystems when TMPFS was not configured!?

[Chiaki]

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

(Please cc: me since I am not subscribed to linux-kernel list.)

I think there is something fishy about kernel 2.6.9.

I failed to enable TMPFS during configuration of
my linux kernel 2.6.9.

However, somehow /proc/filesystems lists "nodev tmpfs" line !?

Is this to be expected?

Background:
I found this hard way. At least one program, namely,
Debian udev package checks whether the system
supports tmpfs by looking at the contents of /proc/filesystems.
Because of this entry in /proc/filesystems, the script fails miserably
now.

Because of the listing of tmpfs although TMPFS was not configured(!?),
a system initialization script for udev is fooled into believing that
tmpfs is supported and tries to mount tmpfs on /dev.


Worse. Somehow the mount command doesn't complain
about tmpfs not supported, and returns succcess code to the
invoking shell. (I checked.)
(If mount fails, then we can probably fix the script to detect the
internal consistency problem and quits.)

Since the tmpfs functionality is not actually available,
from that point on, udev script fails miserably
and my kernel 2.6.9 no longer boots from that point on.

I had to disable udev initialization script for this reason by booting
under older kernel 2.4.25 and then modifies it, and
then figured out what the problem is after rebooting into 2.6.9
without udev and reporting it.

(I experienced a similar problem earlier with Debian's udev script a
few weeks ago, but when udev script was updated to a new version this
problem was not observed. The udev script used different method to
decide whether udev ought to be invoked or not.  But the latest udev
script in Debain, which I upgraded recently, now uses the checking of
availability of tmpfs feature by looking at /proc/filesystems
and then mount tmpfs, and  this strange kernel behavior is causing a
grave problem.

Listing;

Kernel version.
ishikawa@duron$ uname -a
Linux duron 2.6.9-test-tmscsim #10 Sat Oct 23 01:25:17 JST 2004 i686
GNU/Linux

Used config /proc/config.gz (attached in full)

ishikawa@duron$ zcat /proc/config.gz | grep -i tmpfs
# CONFIG_TMPFS is not set


/proc/filesystems contents:

ishikawa@duron$ cat /proc/filesystems
nodev	sysfs
nodev	rootfs
nodev	bdev
nodev	proc
nodev	sockfs
nodev	binfmt_misc
nodev	futexfs
nodev	tmpfs		<==== Why is this line here???
nodev	pipefs
nodev	eventpollfs
nodev	devpts
	ext2
nodev	ramfs
	msdos
nodev	devfs
	hpfs
	vfat
nodev	usbfs
nodev	usbdevfs
ishikawa@duron$ lsmod
Module                  Size  Used by
via686a                18720  0
w83781d                34096  0
i2c_sensor              4608  2 via686a,w83781d
i2c_isa                 2048  0
i2c_core               23168  4 via686a,w83781d,i2c_sensor,i2c_isa
snd_ymfpci             66212  0
snd_pcm               114056  1 snd_ymfpci
snd_ac97_codec         74960  1 snd_ymfpci
snd_opl3_lib           12160  1 snd_ymfpci
snd_timer              33540  3 snd_ymfpci,snd_pcm,snd_opl3_lib
snd_hwdep               8836  1 snd_opl3_lib
snd_page_alloc          8328  2 snd_ymfpci,snd_pcm
snd_mpu401_uart         9472  1 snd_ymfpci
snd_rawmidi            28068  1 snd_mpu401_uart
snd_seq_device          7432  2 snd_opl3_lib,snd_rawmidi
snd                    59492  9
snd_ymfpci,snd_pcm,snd_ac97_codec,snd_opl3_lib,snd_timer,snd_hwdep,snd_mpu401_uart,snd_rawmidi,snd_seq_device
soundcore               9440  1 snd
uhci_hcd               34188  0
usbcore               133348  3 uhci_hcd
evdev                   7808  0
nls_iso8859_1           3968  1
vfat                   14592  1
radeon                137860  0
ide_cd                 39456  0
st                     35612  0
tmscsim                23360  0
sr_mod                 15396  0
cdrom                  38172  2 ide_cd,sr_mod
sg                     35232  0
nls_cp437               5632  1
hpfs                   87172  0
ishikawa@duron$

-- 
int main(void){int j=2003;/*(c)2003 cishikawa. */
char t[] ="<CI> @abcdefghijklmnopqrstuvwxyz.,\n\"";
char *i ="g>qtCIuqivb,gCwe\np@.ietCIuqi\"tqkvv is>dnamz";
while(*i)((j+=strchr(t,*i++)-(int)t),(j%=sizeof t-1),
(putchar(t[j])));return 0;}/* under GPL */

[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 7172 bytes --]

[PATCH] Re: Configuration system bug? : tmpfs listing in /proc/filesystems when TMPFS was not configured!?

[Måns Rullgård]

Chiaki <ishikawa@yk.rim.or.jp> writes:

> (Please cc: me since I am not subscribed to linux-kernel list.)
>
> I think there is something fishy about kernel 2.6.9.
>
> I failed to enable TMPFS during configuration of
> my linux kernel 2.6.9.
>
> However, somehow /proc/filesystems lists "nodev tmpfs" line !?
>
> Is this to be expected?
>
> Background:
> I found this hard way. At least one program, namely,
> Debian udev package checks whether the system
> supports tmpfs by looking at the contents of /proc/filesystems.
> Because of this entry in /proc/filesystems, the script fails miserably
> now.
>
> Because of the listing of tmpfs although TMPFS was not configured(!?),
> a system initialization script for udev is fooled into believing that
> tmpfs is supported and tries to mount tmpfs on /dev.

Is this new to 2.6.9?  I don't see anything in the diffs that would
suggest a change.  The reason for the behavior you are seeing is
rather obvious.  In mm/shmem.c, init_tmpfs() always calls
register_filesystem() for tmpfs, irrespective of the CONFIG_TMPFS
setting.  The /proc/filesystems is created by get_filesystem_list() in
fs/filesystems.c, which doesn't (and couldn't without an ugly hack)
know that tmpfs is bogus.

If init_tmpfs() did not register_filesystem(), what would the effects
be?  I can't see that it would hurt shared memory maps, which are
implemented on top of tmpfs, but I haven't looked that closely.

Here's a patch (untested) for the brave.

Signed-off-by: Måns Rullgård <mru@inprovide.com>

===== mm/shmem.c 1.172 vs edited =====
--- 1.172/mm/shmem.c    2004-10-28 09:39:47 +02:00
+++ edited/mm/shmem.c   2004-11-06 20:01:30 +01:00
@@ -2200,12 +2200,12 @@
        if (error)
                goto out3;
 
+#ifdef CONFIG_TMPFS
        error = register_filesystem(&tmpfs_fs_type);
        if (error) {
                printk(KERN_ERR "Could not register tmpfs\n");
                goto out2;
        }
-#ifdef CONFIG_TMPFS
        devfs_mk_dir("shm");
 #endif
        shm_mnt = do_kern_mount(tmpfs_fs_type.name, MS_NOUSER,
@@ -2218,8 +2218,10 @@
        return 0;
 
 out1:
+#ifdef CONFIG_TMPFS
        unregister_filesystem(&tmpfs_fs_type);
 out2:
+#endif
        destroy_inodecache();
 out3:
        shm_mnt = ERR_PTR(error);

-- 
Måns Rullgård
mru@inprovide.com

Re: Configuration system bug? : tmpfs listing in /proc/filesystems when TMPFS was not configured!?

[Hugh Dickins]

On Sun, 7 Nov 2004, Chiaki wrote:

> (Please cc: me since I am not subscribed to linux-kernel list.)
> 
> I think there is something fishy about kernel 2.6.9.
> 
> I failed to enable TMPFS during configuration of
> my linux kernel 2.6.9.
> 
> However, somehow /proc/filesystems lists "nodev tmpfs" line !?
> 
> Is this to be expected?

It's been like that since 2.4.4.  I suspect it started out as a mistake,
but it's been like that for so long, I've been reluctant to change it
for fear of what might break instead.

> Background:
> I found this hard way. At least one program, namely,
> Debian udev package checks whether the system
> supports tmpfs by looking at the contents of /proc/filesystems.
> Because of this entry in /proc/filesystems, the script fails miserably
> now.

That seems a reasonable thing to do, and it may be okay even
despite the misleading advertizement of tmpfs in /proc/filesystems,
if the mount fails as it should.

> Because of the listing of tmpfs although TMPFS was not configured(!?),
> a system initialization script for udev is fooled into believing that
> tmpfs is supported and tries to mount tmpfs on /dev.
> 
> Worse. Somehow the mount command doesn't complain
> about tmpfs not supported, and returns succcess code to the
> invoking shell. (I checked.)
> (If mount fails, then we can probably fix the script to detect the
> internal consistency problem and quits.)

This is the really bad part, that is new behaviour in 2.6.9, and
my fault for not thinking harder about MS_NOUSER.  Worse than that,
it leaves the directory in a bizarre state, "Not a directory" when
you try to list it for example - Anton reported this weeks ago, but
we couldn't reproduce it, not knowing it needed CONFIG_TMPFS off.

Please try the patch below (against 2.6.9, I'll send Andrew and Linus
the same for 2.6.10-rc later, with proper comment), it fixes mount to
fail cleanly when CONFIG_TMPFS is off.  Let us (or Debian) know if it
also then fixes the Debian udev initialization in this case.

Thanks,
Hugh

--- 2.6.9/mm/shmem.c	2004-10-18 22:56:29.000000000 +0100
+++ linux/mm/shmem.c	2004-11-06 21:04:41.743173040 +0000
@@ -1904,6 +1904,8 @@ static int shmem_fill_super(struct super
 		sbinfo->max_inodes = inodes;
 		sbinfo->free_inodes = inodes;
 	}
+#else
+	sb->s_flags |= MS_NOUSER;
 #endif
 
 	sb->s_maxbytes = SHMEM_MAX_BYTES;

Re: Configuration system bug? : tmpfs listing in /proc/filesystems when TMPFS was not configured!?

[Chiaki]

Chiaki wrote:
> (Please cc: me since I am not subscribed to linux-kernel list.)
> 
> I think there is something fishy about kernel 2.6.9.
> 
> I failed to enable TMPFS during configuration of
> my linux kernel 2.6.9.
> 
> However, somehow /proc/filesystems lists "nodev tmpfs" line !?
> 
> Is this to be expected?
>

Just in case, the compilation of the kernel used stale object files, or
something,
I recompiled the kernel after running make clean.

Still, "tmpfs" shows up in /proc/filesystems
listing although TMPFS was not configured.

I tried to figure out where "tmpfs" was
exported to /proc/filesystems, but could
not.

This bug may bite more users in subtle ways
in the future.

BTW, the kernel version is 2.6.9
(-test-tmscsim suffix to the version string below
is added to remind me that I was testing tmscsim SCSI driver module.)

ishikawa@duron$ uname -a
Linux duron 2.6.9-test-tmscsim #11 Sun Nov 7 03:28:42 JST 2004 i686 
GNU/Linux

Is there a specific sub-system module to whose maintainer
I should submit a bug report?

Re: Configuration system bug? : tmpfs listing in /proc/filesystems when TMPFS was not configured!?

[Chiaki]

Chiaki wrote:
> Chiaki wrote:
> 
>> (Please cc: me since I am not subscribed to linux-kernel list.)
>>
>> I think there is something fishy about kernel 2.6.9.
>>
>> I failed to enable TMPFS during configuration of
>> my linux kernel 2.6.9.
>>
>> However, somehow /proc/filesystems lists "nodev tmpfs" line !?
>>
>> Is this to be expected?
>>
> 
> Just in case, the compilation of the kernel used stale object files, or
> something,
> I recompiled the kernel after running make clean.
> 
> Still, "tmpfs" shows up in /proc/filesystems
> listing although TMPFS was not configured.
> 
> I tried to figure out where "tmpfs" was
> exported to /proc/filesystems, but could
> not.
> 
> This bug may bite more users in subtle ways
> in the future.
> 
> BTW, the kernel version is 2.6.9
> (-test-tmscsim suffix to the version string below
> is added to remind me that I was testing tmscsim SCSI driver module.)
> 
> ishikawa@duron$ uname -a
> Linux duron 2.6.9-test-tmscsim #11 Sun Nov 7 03:28:42 JST 2004 i686 
> GNU/Linux
> 
> Is there a specific sub-system module to whose maintainer
> I should submit a bug report?
> 
> 


-- 
int main(void){int j=2003;/*(c)2003 cishikawa. */
char t[] ="<CI> @abcdefghijklmnopqrstuvwxyz.,\n\"";
char *i ="g>qtCIuqivb,gCwe\np@.ietCIuqi\"tqkvv is>dnamz";
while(*i)((j+=strchr(t,*i++)-(int)t),(j%=sizeof t-1),
(putchar(t[j])));return 0;}/* under GPL */

Re: Configuration system bug? : tmpfs listing in /proc/filesystems when TMPFS was not configured!?

[Chiaki]

Hello,

(Now I am bcc:ing to Hugh Dickins hugh at veritas.com since
  his name was in filesystems/tmpfs.txt documentation file.)

I noticed that /proc/filesystems lists "tmpfs"
although I have not configured TMPFS during the kernel compilation.

I have somehow figured out where tmpfs is registered although
I have not configured it in .config.

(Kernel 2.6.9)

Please note that in mm/shmem.c, all the normal file operations
are ifdef'ed out when CONFI_TMPFS is not set.
(See shmem_dir_inode_operations initial value below.)
So file creation, etc. won't be supported.

However(!), regsiter_filesystem(&tmpfs_fs_type) line
Line 2057 in mm/shmem.c:
in init_tmpfs() is NOT ifdef'ed out.

Should not this line be ifdef'ed out???
That is, should we modify the line like this?

#ifdef CONFIG_TMPFS
	error = register_filesystem(&tmpfs_fs_type);
#endif

Chiaki

cf.
Here is the explanation for kernel mount operation we find
in init_tmpfs().

 From /usr/src/linux/Documentation/filesystems/tmpfs.txt

>tmpfs has the following uses:
>
>1) There is always a kernel internal mount which you will not see at
>   all. This is used for shared anonymous mappings and SYSV shared
>   memory. 
>
>   This mount does not depend on CONFIG_TMPFS. If CONFIG_TMPFS is not
>   set, the user visible part of tmpfs is not build. But the internal
>   mechanisms are always present.

I agree user visible part of tmpfs is not build when CONFIG_TMPFS is
not set, and thus tmpfs should not be registered.
Trying to use tmpfs (by creating files/directories) will fail
when CONFIG_TMPFS is not set. Thus useless and so /proc/filesystems
should not show tmpfs IMHO.
(Or not registering it interferes with the internal kernel mount
operation? [like not being able to find tmpfs function for internal
kernel mount operaton mentioned above??? We probably need to unregister it
in that case immediately after the internal mount succeeded. Maybe.]
]


References:

 From mm/shmem.c:


static struct inode_operations shmem_dir_inode_operations = {
#ifdef CONFIG_TMPFS
	.create		= shmem_create,
	.lookup		= simple_lookup,
	.link		= shmem_link,
	.unlink		= shmem_unlink,
	.symlink	= shmem_symlink,
	.mkdir		= shmem_mkdir,
	.rmdir		= shmem_rmdir,
	.mknod		= shmem_mknod,
	.rename		= shmem_rename,
#endif
};

static struct super_operations shmem_ops = {
	.alloc_inode	= shmem_alloc_inode,
	.destroy_inode	= shmem_destroy_inode,
#ifdef CONFIG_TMPFS
	.statfs		= shmem_statfs,
	.remount_fs	= shmem_remount_fs,
#endif
	.delete_inode	= shmem_delete_inode,
	.drop_inode	= generic_delete_inode,
	.put_super	= shmem_put_super,
};


Then later in init_tmpfs():

static int __init init_tmpfs(void)
{
	int error;

	error = init_inodecache();
	if (error)
		goto out3;

	error = register_filesystem(&tmpfs_fs_type);
	if (error) {
		printk(KERN_ERR "Could not register tmpfs\n");
		goto out2;
	}
#ifdef CONFIG_TMPFS
	devfs_mk_dir("shm");
#endif
	shm_mnt = do_kern_mount(tmpfs_fs_type.name, MS_NOUSER,
				tmpfs_fs_type.name, NULL);



I think the above register_filesystem() ought to be ifdef'ed out.


-- 
int main(void){int j=2003;/*(c)2003 cishikawa. */
char t[] ="<CI> @abcdefghijklmnopqrstuvwxyz.,\n\"";
char *i ="g>qtCIuqivb,gCwe\np@.ietCIuqi\"tqkvv is>dnamz";
while(*i)((j+=strchr(t,*i++)-(int)t),(j%=sizeof t-1),
(putchar(t[j])));return 0;}/* under GPL */

Re: Configuration system bug? : tmpfs listing in /proc/filesystems when TMPFS was not configured!?

[Hugh Dickins]

On Sun, 7 Nov 2004, Chiaki wrote:
> Should not this line be ifdef'ed out???
> That is, should we modify the line like this?
> 
> #ifdef CONFIG_TMPFS
> 	error = register_filesystem(&tmpfs_fs_type);
> #endif

I'd be more inclined to register under a different
name than "tmpfs" in the !CONFIG_TMPFS case.

But as I said in my earlier reply to you (which you should have
received before you sent this?), it's been like this ever since
2.4.4 when "tmpfs" and CONFIG_TMPFS came into being, so I don't
see why we need to change it now.

The real 2.4.9 error is fixed by the patch below that I sent then:
does that solve your problems?

Hugh

--- 2.6.9/mm/shmem.c	2004-10-18 22:56:29.000000000 +0100
+++ linux/mm/shmem.c	2004-11-06 21:04:41.743173040 +0000
@@ -1904,6 +1904,8 @@ static int shmem_fill_super(struct super
 		sbinfo->max_inodes = inodes;
 		sbinfo->free_inodes = inodes;
 	}
+#else
+	sb->s_flags |= MS_NOUSER;
 #endif
 
 	sb->s_maxbytes = SHMEM_MAX_BYTES;

Re: Configuration system bug? : tmpfs listing in /proc/filesystems when TMPFS was not configured!?

[Chiaki]

Hugh Dickins wrote:

> On Sun, 7 Nov 2004, Chiaki wrote:
> 
>>Should not this line be ifdef'ed out???
>>That is, should we modify the line like this?
>>
>>#ifdef CONFIG_TMPFS
>>	error = register_filesystem(&tmpfs_fs_type);
>>#endif
> 
> 
> I'd be more inclined to register under a different
> name than "tmpfs" in the !CONFIG_TMPFS case.

Something like "tMpfs" might be a good idea to
show the strange setting :-)

> 
> But as I said in my earlier reply to you (which you should have
> received before you sent this?), it's been like this ever since
> 2.4.4 when "tmpfs" and CONFIG_TMPFS came into being, so I don't
> see why we need to change it now.

Thank you for your previous e-mail.
I didn't know it reached my computer since my mozilla e-mail
filtering mitakingly classified your kind response into
an unexpected folder. I searched after reading the above paragraph
and found your previous e-mail.

> The real 2.4.9 error is fixed by the patch below that I sent then:
> does that solve your problems?

YES!

With the original 2.6.9, the mount didn't complain at all, and
then I got bizarre behavir afterward and udev script and booting
stopped at that point.

But wih your patch, now mount fails.
So now it is a matter of fixing udev script to
take care of the case of failing tmpfs mounting.
I will re-open the debian bugzilla entry concerning this
so that Debian udev package and possibly an upstream package
can be fixed.



tmpfs mount failure example: (I had created /tmp/t-dir.)

duron:/home/ishikawa# mount -n -o size=1m,mode=0755 -t tmpfs none /tmp/t-dir
mount: wrong fs type, bad option, bad superblock on none,
        or too many mounted file systems
duron:/home/ishikawa#


> Hugh
> 
> --- 2.6.9/mm/shmem.c	2004-10-18 22:56:29.000000000 +0100
> +++ linux/mm/shmem.c	2004-11-06 21:04:41.743173040 +0000
> @@ -1904,6 +1904,8 @@ static int shmem_fill_super(struct super
>  		sbinfo->max_inodes = inodes;
>  		sbinfo->free_inodes = inodes;
>  	}
> +#else
> +	sb->s_flags |= MS_NOUSER;
>  #endif
>  
>  	sb->s_maxbytes = SHMEM_MAX_BYTES;
> 
> 
> 


Thank you very much!



-- 
int main(void){int j=2003;/*(c)2003 cishikawa. */
char t[] ="<CI> @abcdefghijklmnopqrstuvwxyz.,\n\"";
char *i ="g>qtCIuqivb,gCwe\np@.ietCIuqi\"tqkvv is>dnamz";
while(*i)((j+=strchr(t,*i++)-(int)t),(j%=sizeof t-1),
(putchar(t[j])));return 0;}/* under GPL */