From: Al Viro <viro@ZenIV.linux.org.uk>
To: Guenter Roeck <linux@roeck-us.net>
Cc: Paul Moore <pmoore@redhat.com>,
Sabrina Dubroca <sd@queasysnail.net>,
Stephen Rothwell <sfr@canb.auug.org.au>,
linux-next@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-fsdevel@vger.kernel.org, linux-audit@redhat.com,
Richard Guy Briggs <rgb@redhat.com>
Subject: Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
Date: Wed, 21 Jan 2015 03:36:00 +0000 [thread overview]
Message-ID: <20150121033600.GN29656@ZenIV.linux.org.uk> (raw)
In-Reply-To: <54BF1292.2080902@roeck-us.net>
On Tue, Jan 20, 2015 at 06:44:34PM -0800, Guenter Roeck wrote:
> >The shit hits the fan earlier - when we end up missing /dev. There are
> >two places where it could've been created (depending on CONFIG_BLK_DEV_INITRD);
> > sys_mkdir(collected, mode);
> >in init/initramfs.c (line 353 in linux-next) and
> > err = sys_mkdir((const char __user __force *) "/dev", 0755);
> >in init/noinitramfs.c (line 32). The latter would've screamed on failure;
> >could you printk of collected (%s), mode (%o) and return value (%d) in the
> >former and see what happens?
> >
>
> sys_mkdir .:40775 returned -17
> sys_mkdir usr:40775 returned 0
> sys_mkdir usr/lib:40775 returned -2
> sys_mkdir usr/share:40755 returned -2
> sys_mkdir usr/share/udhcpc:40755 returned -2
> sys_mkdir usr/bin:40775 returned -2
> sys_mkdir usr/sbin:40775 returned -2
> sys_mkdir mnt:40775 returned 0
> sys_mkdir proc:40775 returned 0
> sys_mkdir root:40775 returned 0
> sys_mkdir lib:40775 returned 0
> sys_mkdir lib/modules:40775 returned -2
> sys_mkdir lib/modules/3.9.2:40775 returned -2
> sys_mkdir lib/modules/3.9.2/kernel:40775 returned -2
>
> with
> int err = sys_mkdir(collected, mode);
> pr_info("sys_mkdir %s:%o returned %d\n", collected, mode, err);
> added in init/initramfs.c.
Just what is lib/modules/3.9.2 doing there? In any case, I think I have at
least a plausible direction for digging. Look:
struct dentry *user_path_create(int dfd, const char __user *pathname,
struct path *path, unsigned int lookup_flags)
{
struct filename *tmp = getname(pathname);
struct dentry *res;
if (IS_ERR(tmp))
return ERR_CAST(tmp);
res = kern_path_create(dfd, tmp->name, path, lookup_flags);
struct dentry *kern_path_create(int dfd, const char *pathname,
struct path *path, unsigned int lookup_flags)
{
struct dentry *dentry = ERR_PTR(-EEXIST);
struct nameidata nd;
int err2;
int error;
bool is_dir = (lookup_flags & LOOKUP_DIRECTORY);
/*
* Note that only LOOKUP_REVAL and LOOKUP_DIRECTORY matter here. Any
* other flags passed in are ignored!
*/
lookup_flags &= LOOKUP_REVAL;
error = do_path_lookup(dfd, pathname, LOOKUP_PARENT|lookup_flags, &nd);
static int do_path_lookup(int dfd, const char *name,
unsigned int flags, struct nameidata *nd)
{
int retval;
struct filename *filename;
filename = getname_kernel(name);
if (unlikely(IS_ERR(filename)))
return PTR_ERR(filename);
retval = filename_lookup(dfd, filename, flags, nd);
and we have done getname_kernel() on the name->name of result of getname().
At the very least, it's pointless - we already *have* struct filename for
that sucker. Now, it shouldn't have screwed the things up - it would better
not, anyway, since we might legitimately have two identical pathname
among the syscall arguments. However, let's see if this (on top of
linux-next, in addition to the same printks) changes behaviour:
diff --git a/fs/namei.c b/fs/namei.c
index 323957f..c7d107c 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -3314,7 +3314,7 @@ struct file *do_file_open_root(struct dentry *dentry, struct vfsmount *mnt,
return file;
}
-struct dentry *kern_path_create(int dfd, const char *pathname,
+static struct dentry *__kern_path_create(int dfd, struct filename *name,
struct path *path, unsigned int lookup_flags)
{
struct dentry *dentry = ERR_PTR(-EEXIST);
@@ -3329,7 +3329,7 @@ struct dentry *kern_path_create(int dfd, const char *pathname,
*/
lookup_flags &= LOOKUP_REVAL;
- error = do_path_lookup(dfd, pathname, LOOKUP_PARENT|lookup_flags, &nd);
+ error = filename_lookup(dfd, name, LOOKUP_PARENT|lookup_flags, &nd);
if (error)
return ERR_PTR(error);
@@ -3383,6 +3383,19 @@ out:
path_put(&nd.path);
return dentry;
}
+
+struct dentry *kern_path_create(int dfd, const char *pathname,
+ struct path *path, unsigned int lookup_flags)
+{
+ struct filename *filename = getname_kernel(pathname);
+ struct dentry *res = ERR_CAST(filename);
+
+ if (!IS_ERR(filename)) {
+ res = __kern_path_create(dfd, filename, path, lookup_flags);
+ putname(filename);
+ }
+ return res;
+}
EXPORT_SYMBOL(kern_path_create);
void done_path_create(struct path *path, struct dentry *dentry)
@@ -3401,7 +3414,7 @@ struct dentry *user_path_create(int dfd, const char __user *pathname,
struct dentry *res;
if (IS_ERR(tmp))
return ERR_CAST(tmp);
- res = kern_path_create(dfd, tmp->name, path, lookup_flags);
+ res = __kern_path_create(dfd, tmp, path, lookup_flags);
putname(tmp);
return res;
}
next prev parent reply other threads:[~2015-01-21 3:36 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20150120185308.53f4af4e@canb.auug.org.au>
2015-01-20 16:56 ` linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs Sabrina Dubroca
2015-01-20 17:39 ` Paul Moore
2015-01-20 17:51 ` Sabrina Dubroca
2015-01-20 19:54 ` Al Viro
2015-01-20 20:45 ` Sabrina Dubroca
2015-01-20 21:02 ` Al Viro
2015-01-20 21:38 ` Sabrina Dubroca
2015-01-20 21:58 ` Al Viro
2015-01-20 22:08 ` Sabrina Dubroca
2015-01-20 22:13 ` Guenter Roeck
2015-01-20 22:50 ` Al Viro
2015-01-20 23:17 ` Al Viro
2015-01-20 23:27 ` Sabrina Dubroca
2015-01-21 0:04 ` Paul Moore
2015-01-21 0:14 ` Paul Moore
2015-01-21 0:41 ` Al Viro
2015-01-21 2:44 ` Guenter Roeck
2015-01-21 3:36 ` Al Viro [this message]
2015-01-21 4:01 ` Guenter Roeck
2015-01-21 4:36 ` Al Viro
2015-01-21 11:05 ` Sabrina Dubroca
2015-01-21 13:32 ` Guenter Roeck
2015-01-21 18:29 ` Al Viro
2015-01-21 19:06 ` Guenter Roeck
2015-01-21 20:06 ` Al Viro
2015-01-21 21:03 ` Guenter Roeck
2015-01-21 21:28 ` Al Viro
2015-01-21 21:38 ` Guenter Roeck
2015-01-21 21:40 ` Sabrina Dubroca
2015-01-21 21:54 ` Paul Walmsley
2015-01-22 2:28 ` Paul Moore
2015-01-22 4:12 ` Al Viro
2015-01-22 4:49 ` Paul Moore
2015-01-21 21:30 ` Sabrina Dubroca
2015-01-21 14:42 ` Thierry Reding
2015-01-21 15:24 ` Paul Moore
2015-01-21 15:39 ` Thierry Reding
2015-01-21 15:54 ` Sabrina Dubroca
2015-01-21 16:16 ` Paul Moore
2015-01-21 17:38 ` Al Viro
2015-01-21 17:51 ` Guenter Roeck
2015-01-21 16:21 ` Guenter Roeck
2015-01-21 15:06 ` Paul Moore
2015-01-20 21:43 ` Guenter Roeck
2015-01-20 17:54 ` Fabio Estevam
2015-01-20 19:00 ` Ross Zwisler
2015-01-20 19:16 ` Fabio Estevam
2015-01-20 19:24 ` Paul Moore
2015-01-20 19:43 ` Fabio Estevam
2015-01-20 20:10 ` Paul Moore
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=20150121033600.GN29656@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=linux-audit@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=pmoore@redhat.com \
--cc=rgb@redhat.com \
--cc=sd@queasysnail.net \
--cc=sfr@canb.auug.org.au \
/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;
as well as URLs for NNTP newsgroup(s).