(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\[email protected]\"tqkvv is>dnamz";
while(*i)((j+=strchr(t,*i++)-(int)t),(j%=sizeof t-1),
(putchar(t[j])));return 0;}/* under GPL */
Chiaki <[email protected]> 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 <[email protected]>
===== 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
[email protected]
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;
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?
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\[email protected]\"tqkvv is>dnamz";
while(*i)((j+=strchr(t,*i++)-(int)t),(j%=sizeof t-1),
(putchar(t[j])));return 0;}/* under GPL */
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\[email protected]\"tqkvv is>dnamz";
while(*i)((j+=strchr(t,*i++)-(int)t),(j%=sizeof t-1),
(putchar(t[j])));return 0;}/* under GPL */
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;
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\[email protected]\"tqkvv is>dnamz";
while(*i)((j+=strchr(t,*i++)-(int)t),(j%=sizeof t-1),
(putchar(t[j])));return 0;}/* under GPL */