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: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-20 7:53 linux-next: Tree for Jan 20 Stephen Rothwell
2015-01-20 14:16 ` Guenter Roeck
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
2015-01-20 20:26 ` linux-next: Tree for Jan 20 Guenter Roeck
2015-01-20 22:54 ` Kirill A. Shutemov
2015-01-21 3:05 ` Guenter Roeck
2015-01-21 10:43 ` Kirill A. Shutemov
2015-01-21 23:34 ` Guenter Roeck
2015-01-22 3:14 ` Guenter Roeck
2015-01-22 17:13 ` linux-next: Tree for Jan 20 -- sparc32: fix broken set_pte() Kirill A. Shutemov
2015-01-22 17:27 ` Kirill A. Shutemov
2015-01-22 17:27 ` Kirill A. Shutemov
2015-01-22 19:34 ` Guenter Roeck
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.