From: "Måns Rullgård" <mru@inprovide.com>
To: Chiaki <ishikawa@yk.rim.or.jp>
Cc: linux-kernel <linux-kernel@vger.kernel.org>
Subject: [PATCH] Re: Configuration system bug? : tmpfs listing in /proc/filesystems when TMPFS was not configured!?
Date: Sat, 06 Nov 2004 20:04:11 +0100 [thread overview]
Message-ID: <yw1xekj6ol3o.fsf@ford.inprovide.com> (raw)
In-Reply-To: <418D0EFB.2040002@yk.rim.or.jp> (Chiaki's message of "Sun, 07 Nov 2004 02:50:51 +0900")
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
next prev parent reply other threads:[~2004-11-06 19:04 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-06 17:50 Chiaki
2004-11-06 19:04 ` Måns Rullgård [this message]
2004-11-06 21:09 ` Hugh Dickins
2004-11-07 1:31 ` Chiaki
2004-11-07 2:05 ` Chiaki
2004-11-07 2:12 ` Chiaki
2004-11-07 4:49 ` Hugh Dickins
2004-11-07 6:00 ` Chiaki
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=yw1xekj6ol3o.fsf@ford.inprovide.com \
--to=mru@inprovide.com \
--cc=ishikawa@yk.rim.or.jp \
--cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®