From: Al Viro <viro@ZenIV.linux.org.uk>
To: Hillf Danton <dhillf@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] hugetlbfs: add err code in initializing module
Date: Thu, 22 Mar 2012 00:33:56 +0000 [thread overview]
Message-ID: <20120322003356.GT6589@ZenIV.linux.org.uk> (raw)
In-Reply-To: <CAJd=RBBK4tx91ZQu0WKzBGx8E-Na6oUwmpBUQVB0yPkR=ySPjg@mail.gmail.com>
On Sun, Mar 11, 2012 at 01:09:59PM +0800, Hillf Danton wrote:
> Error code is added if fail to create inode kmem cache, and newly registered
> hugetlb FS is unregistered if fail to mount, both for unlikely corner cases.
>
> --- a/fs/hugetlbfs/inode.c Sun Mar 11 12:46:38 2012
> +++ b/fs/hugetlbfs/inode.c Sun Mar 11 12:49:28 2012
> @@ -1000,6 +1000,7 @@ static int __init init_hugetlbfs_fs(void
> hugetlbfs_inode_cachep = kmem_cache_create("hugetlbfs_inode_cache",
> sizeof(struct hugetlbfs_inode_info),
> 0, 0, init_once);
> + error = -ENOMEM;
> if (hugetlbfs_inode_cachep == NULL)
> goto out2;
>
> @@ -1015,6 +1016,7 @@ static int __init init_hugetlbfs_fs(void
> }
>
> error = PTR_ERR(vfsmount);
> + unregister_filesystem(&hugetlbfs_fs_type);
Bloody bad idea, that... Realistically, the proper action on failure here
(as well as in sock_init(), etc.) is panic(). If we fail to OOM that early,
the box is doomed anyway.
Note that unregister_filesystem() in module init is *always* wrong; it's not
an issue here (it's done too early to care about and realistically the box
is not going anywhere - it'll panic when attempt to exec /sbin/init fails,
if not earlier), but it's a damn bad example.
Consider a normal fs module. Somebody loads it and in parallel with that
we get a mount attempt on that fs type. It comes between register and
failure exits that causes unregister; at that point we are screwed since
grabbing a reference to module as done by mount is enough to prevent
exit, but not to prevent the failure of init. As the result, module will
get freed when init fails, mounted fs of that type be damned.
Again, this is not an issue here, but we had a bunch of real races of that
sort - the fixes for those just went in. We _still_ have b0rken ones -
e.g. fuse and gfs2 are FUBAR in that respect and there's not a damn thing
we can do with the current API - anything that registers several fs types
can fail on the last register_filesystem() and that's it.
BTW, why in the name of everything unholy does hugetlbfs have module_exit()?
* it's not a module
* it does kern_mount() in module_init, which pins it down anyway
* even if it wouldn't bother with kern_mount() (that can be worked
around, by switching to simple_pin_fs() done on demand), we would still have
the code in core kernel calling the functions in there. Good luck working
around _that_ in a race-free way...
next prev parent reply other threads:[~2012-03-22 0:33 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-11 5:09 [PATCH] hugetlbfs: add err code in initializing module Hillf Danton
2012-03-11 5:21 ` Hillf Danton
2012-03-11 20:25 ` David Rientjes
2012-03-12 12:01 ` Hillf Danton
2012-03-12 21:38 ` David Rientjes
2012-03-12 23:58 ` Andrew Morton
2012-03-22 0:33 ` Al Viro [this message]
2012-03-22 13:26 ` Hillf Danton
2012-03-28 7:24 ` David Rientjes
2012-03-28 12:40 ` Hillf Danton
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=20120322003356.GT6589@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=akpm@linux-foundation.org \
--cc=dhillf@gmail.com \
--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