Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On Thursday, January 22, 2015 04:12:41 AM Al Viro wrote:
> On Wed, Jan 21, 2015 at 09:28:51PM -0500, Paul Moore wrote:
> > Al, do you mind if I fold your patch below into the existing patches?
>
> No problem, but I'd probably prefer to put this series through vfs.git.
> With the following as the first step:
I just finished fixing up the patchset and giving it a quick sanity test on my
system, some additional testing is still needed to verify that all the audit
stuff is still okay (I did change the __audit_inode() as discussed and bumped
the refcount in __audit_reusename()) but I think as things stand the boot
panic problems should be resolved - thanks again for your help.
I'm going to (re)post what I've currently got for a patchset and call it a
day. Tomorrow I'll add your below patch and finish up my testing, if all goes
well I'll repost the whole set. If you would prefer it to go via the VFS
tree, that's fine with me, as long as it hits Linus' tree at some point I'm
happy.
> Cut down on do_path_lookup() callers
>
> Use filename_lookup() instead. And don't bother with creating new
> struct filename when caller already has one.
>
> Signed-off-by: Al Viro
> ---
> diff --git a/fs/namei.c b/fs/namei.c
> index bc35b02..73fcf42 100644
> --- a/fs/namei.c
> +++ b/fs/namei.c
> @@ -2046,7 +2046,8 @@ struct dentry *kern_path_locked(const char *name,
> struct path *path) {
> struct nameidata nd;
> struct dentry *d;
> - int err = do_path_lookup(AT_FDCWD, name, LOOKUP_PARENT, );
> + struct filename filename = {.name = name};
> + int err = filename_lookup(AT_FDCWD, , LOOKUP_PARENT, );
> if (err)
> return ERR_PTR(err);
> if (nd.last_type != LAST_NORM) {
> @@ -3290,7 +3291,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 *filename_create(int dfd, struct filename *name,
> struct path *path, unsigned int lookup_flags)
> {
> struct dentry *dentry = ERR_PTR(-EEXIST);
> @@ -3305,7 +3306,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, );
> + error = filename_lookup(dfd, name, LOOKUP_PARENT|lookup_flags, );
> if (error)
> return ERR_PTR(error);
>
> @@ -3359,6 +3360,13 @@ out:
> path_put();
> return dentry;
> }
> +
> +struct dentry *kern_path_create(int dfd, const char *pathname,
> + struct path *path, unsigned int lookup_flags)
> +{
> + struct filename filename = {.name = pathname};
> + return filename_create(dfd, , path, lookup_flags);
> +}
> EXPORT_SYMBOL(kern_path_create);
>
> void done_path_create(struct path *path, struct dentry *dentry)
> @@ -3377,7 +3385,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 = filename_create(dfd, tmp, path, lookup_flags);
> putname(tmp);
> return res;
> }
--
paul moore
security @ redhat
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On Wed, Jan 21, 2015 at 09:28:51PM -0500, Paul Moore wrote:
> Al, do you mind if I fold your patch below into the existing patches?
No problem, but I'd probably prefer to put this series through vfs.git.
With the following as the first step:
Cut down on do_path_lookup() callers
Use filename_lookup() instead. And don't bother with creating new
struct filename when caller already has one.
Signed-off-by: Al Viro
---
diff --git a/fs/namei.c b/fs/namei.c
index bc35b02..73fcf42 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -2046,7 +2046,8 @@ struct dentry *kern_path_locked(const char *name, struct
path *path)
{
struct nameidata nd;
struct dentry *d;
- int err = do_path_lookup(AT_FDCWD, name, LOOKUP_PARENT, );
+ struct filename filename = {.name = name};
+ int err = filename_lookup(AT_FDCWD, , LOOKUP_PARENT, );
if (err)
return ERR_PTR(err);
if (nd.last_type != LAST_NORM) {
@@ -3290,7 +3291,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 *filename_create(int dfd, struct filename *name,
struct path *path, unsigned int lookup_flags)
{
struct dentry *dentry = ERR_PTR(-EEXIST);
@@ -3305,7 +3306,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, );
+ error = filename_lookup(dfd, name, LOOKUP_PARENT|lookup_flags, );
if (error)
return ERR_PTR(error);
@@ -3359,6 +3360,13 @@ out:
path_put();
return dentry;
}
+
+struct dentry *kern_path_create(int dfd, const char *pathname,
+ struct path *path, unsigned int lookup_flags)
+{
+ struct filename filename = {.name = pathname};
+ return filename_create(dfd, , path, lookup_flags);
+}
EXPORT_SYMBOL(kern_path_create);
void done_path_create(struct path *path, struct dentry *dentry)
@@ -3377,7 +3385,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 = filename_create(dfd, tmp, path, lookup_flags);
putname(tmp);
return res;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On Wednesday, January 21, 2015 09:28:33 PM Al Viro wrote:
> On Wed, Jan 21, 2015 at 01:03:20PM -0800, Guenter Roeck wrote:
> > failing case:
> >
> > path_lookupat: calling path_init 'usr' flags=40
> > path_init: link_path_walk() returned 0
> > path_lookupat: path_init 'usr' flags=40[50] returned 0
> > walk_component: lookup_fast() returned 1
> > walk_component: lookup_slow() returned 0
> > walk_component: inode= (null), negative=1
> > do_path_lookup(usr, 0x10)
> > path_lookupat: calling path_init 'usr' flags=50
> > path_init: link_path_walk() returned 0
> > path_lookupat: path_init 'usr' flags=50[50] returned 0
> > mkdir[c74012a0,/kkk] => 0 <
> > SIC!
>
> Cute. 'k' being 0x6b, aka POISON_FREE... OK, the next question is what's
> been freed under us - I don't believe that it's dentry itself...
> Oh, fuck. OK, I see what happens. Look at kern_path_create(); it does
> LOOKUP_PARENT walk, leaving nd->last pointing to the last component of
> the *COPY* of the name it's just created, walked and freed.
>
> OK... Fortunately, struct nameidata is completely opaque outside of
> fs/namei.c, so we only need to care about a couple of codepaths.
>
> Folks, could you check if the following on top of linux-next fixes the
> problem?
Thanks Al, and Guenter, and Sabrina for helping resolve this; it surely would
have taken me much longer alone.
Al, do you mind if I fold your patch below into the existing patches?
> diff --git a/fs/namei.c b/fs/namei.c
> index 323957f..cda89c3 100644
> --- a/fs/namei.c
> +++ b/fs/namei.c
> @@ -2056,13 +2056,22 @@ static int do_path_lookup(int dfd, const char *name,
> /* does lookup, returns the object with parent locked */
> struct dentry *kern_path_locked(const char *name, struct path *path)
> {
> + struct filename *filename = getname_kernel(name);
> struct nameidata nd;
> struct dentry *d;
> - int err = do_path_lookup(AT_FDCWD, name, LOOKUP_PARENT, );
> - if (err)
> + int err;
> +
> + if (IS_ERR(filename))
> + return ERR_CAST(filename);
> +
> + err = filename_lookup(AT_FDCWD, filename, LOOKUP_PARENT, );
> + if (err) {
> + putname(filename);
> return ERR_PTR(err);
> + }
> if (nd.last_type != LAST_NORM) {
> path_put();
> + putname(filename);
> return ERR_PTR(-EINVAL);
> }
> mutex_lock_nested(>d_inode->i_mutex, I_MUTEX_PARENT);
> @@ -2070,9 +2079,11 @@ struct dentry *kern_path_locked(const char *name,
> struct path *path) if (IS_ERR(d)) {
> mutex_unlock(>d_inode->i_mutex);
> path_put();
> + putname(filename);
> return d;
> }
> *path = nd.path;
> + putname(filename);
> return d;
> }
>
> @@ -3314,7 +3325,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 *filename_create(int dfd, struct filename *name,
> struct path *path, unsigned int lookup_flags)
> {
> struct dentry *dentry = ERR_PTR(-EEXIST);
> @@ -3329,7 +3340,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, );
> + error = filename_lookup(dfd, name, LOOKUP_PARENT|lookup_flags, );
> if (error)
> return ERR_PTR(error);
>
> @@ -3383,6 +3394,19 @@ out:
> path_put();
> 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 = filename_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 +3425,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 = filename_create(dfd, tmp, path, lookup_flags);
> putname(tmp);
> return res;
> }
--
paul moore
security @ redhat
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On Wed, 21 Jan 2015, Al Viro wrote:
> Folks, could you check if the following on top of linux-next fixes the
> problem?
Tested-by: Paul Walmsley # Tegra124 Jetson TK1
>
> diff --git a/fs/namei.c b/fs/namei.c
> index 323957f..cda89c3 100644
> --- a/fs/namei.c
> +++ b/fs/namei.c
> @@ -2056,13 +2056,22 @@ static int do_path_lookup(int dfd, const char *name,
> /* does lookup, returns the object with parent locked */
> struct dentry *kern_path_locked(const char *name, struct path *path)
> {
> + struct filename *filename = getname_kernel(name);
> struct nameidata nd;
> struct dentry *d;
> - int err = do_path_lookup(AT_FDCWD, name, LOOKUP_PARENT, );
> - if (err)
> + int err;
> +
> + if (IS_ERR(filename))
> + return ERR_CAST(filename);
> +
> + err = filename_lookup(AT_FDCWD, filename, LOOKUP_PARENT, );
> + if (err) {
> + putname(filename);
> return ERR_PTR(err);
> + }
> if (nd.last_type != LAST_NORM) {
> path_put();
> + putname(filename);
> return ERR_PTR(-EINVAL);
> }
> mutex_lock_nested(>d_inode->i_mutex, I_MUTEX_PARENT);
> @@ -2070,9 +2079,11 @@ struct dentry *kern_path_locked(const char *name,
> struct path *path)
> if (IS_ERR(d)) {
> mutex_unlock(>d_inode->i_mutex);
> path_put();
> + putname(filename);
> return d;
> }
> *path = nd.path;
> + putname(filename);
> return d;
> }
>
> @@ -3314,7 +3325,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 *filename_create(int dfd, struct filename *name,
> struct path *path, unsigned int lookup_flags)
> {
> struct dentry *dentry = ERR_PTR(-EEXIST);
> @@ -3329,7 +3340,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, );
> + error = filename_lookup(dfd, name, LOOKUP_PARENT|lookup_flags, );
> if (error)
> return ERR_PTR(error);
>
> @@ -3383,6 +3394,19 @@ out:
> path_put();
> 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 = filename_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 +3425,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 = filename_create(dfd, tmp, path, lookup_flags);
> putname(tmp);
> return res;
> }
> --
> To unsubscribe from this list: send the line "unsubscribe linux-next" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
2015-01-21, 21:28:33 +, Al Viro wrote: > On Wed, Jan 21, 2015 at 01:03:20PM -0800, Guenter Roeck wrote: > > ok case (putname commented out): > > > > user_path_at_empty lookup usr flags 0x0 > > path_lookupat: calling path_init 'usr' flags=40 > > path_init: link_path_walk() returned 0 > > path_lookupat: path_init 'usr' flags=40[50] returned 0 > > walk_component: lookup_fast() returned 1 > > walk_component: lookup_slow() returned 0 > > walk_component: inode= (null), negative=1 > > do_path_lookup(usr, 0x10) > > path_lookupat: calling path_init 'usr' flags=50 > > path_init: link_path_walk() returned 0 > > path_lookupat: path_init 'usr' flags=50[50] returned 0 > > mkdir[c74012a0,/usr] => 0 > > user_path_at_empty lookup usr flags 0x1 > > path_lookupat: calling path_init 'usr' flags=41 > > path_init: link_path_walk() returned 0 > > path_lookupat: path_init 'usr' flags=41[51] returned 0 > > walk_component: inode=c74004a0, negative=0 > > user_path_at_empty lookup usr flags 0x1 > > path_lookupat: calling path_init 'usr' flags=41 > > path_init: link_path_walk() returned 0 > > path_lookupat: path_init 'usr' flags=41[51] returned 0 > > > > failing case: > > > > path_lookupat: calling path_init 'usr' flags=40 > > path_init: link_path_walk() returned 0 > > path_lookupat: path_init 'usr' flags=40[50] returned 0 > > walk_component: lookup_fast() returned 1 > > walk_component: lookup_slow() returned 0 > > walk_component: inode= (null), negative=1 > > do_path_lookup(usr, 0x10) > > path_lookupat: calling path_init 'usr' flags=50 > > path_init: link_path_walk() returned 0 > > path_lookupat: path_init 'usr' flags=50[50] returned 0 > > mkdir[c74012a0,/kkk] => 0 < > > SIC! > > Cute. 'k' being 0x6b, aka POISON_FREE... OK, the next question is what's > been freed under us - I don't believe that it's dentry itself... > Oh, fuck. OK, I see what happens. Look at kern_path_create(); it does > LOOKUP_PARENT walk, leaving nd->last pointing to the last component of > the *COPY* of the name it's just created, walked and freed. > > OK... Fortunately, struct nameidata is completely opaque outside of > fs/namei.c, > so we only need to care about a couple of codepaths. > > Folks, could you check if the following on top of linux-next fixes the > problem? Yes, it works. -- Sabrina -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On Wed, Jan 21, 2015 at 09:28:33PM +, Al Viro wrote: > On Wed, Jan 21, 2015 at 01:03:20PM -0800, Guenter Roeck wrote: > > > > failing case: > > > > path_lookupat: calling path_init 'usr' flags=40 > > path_init: link_path_walk() returned 0 > > path_lookupat: path_init 'usr' flags=40[50] returned 0 > > walk_component: lookup_fast() returned 1 > > walk_component: lookup_slow() returned 0 > > walk_component: inode= (null), negative=1 > > do_path_lookup(usr, 0x10) > > path_lookupat: calling path_init 'usr' flags=50 > > path_init: link_path_walk() returned 0 > > path_lookupat: path_init 'usr' flags=50[50] returned 0 > > mkdir[c74012a0,/kkk] => 0 < > > SIC! > > Cute. 'k' being 0x6b, aka POISON_FREE... OK, the next question is what's > been freed under us - I don't believe that it's dentry itself... > Oh, fuck. OK, I see what happens. Look at kern_path_create(); it does > LOOKUP_PARENT walk, leaving nd->last pointing to the last component of > the *COPY* of the name it's just created, walked and freed. > Cool. > OK... Fortunately, struct nameidata is completely opaque outside of > fs/namei.c, > so we only need to care about a couple of codepaths. > > Folks, could you check if the following on top of linux-next fixes the > problem? > > diff --git a/fs/namei.c b/fs/namei.c > index 323957f..cda89c3 100644 Yes, this patch fixes the problem for me. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
2015-01-21, 13:03:20 -0800, Guenter Roeck wrote:
> On 01/21/2015 12:06 PM, Al Viro wrote:
> >On Wed, Jan 21, 2015 at 11:06:27AM -0800, Guenter Roeck wrote:
> >>On 01/21/2015 10:29 AM, Al Viro wrote:
> >>>On Wed, Jan 21, 2015 at 05:32:13AM -0800, Guenter Roeck wrote:
> Another data point (though I have no idea if it is useful or what it
> means):
>
> In the working case, path_init sets nd->flags to 0x50 or 0x51.
> In the non-working case (ie for all files with a '/' in the name),
> it sets nd->flags to 0x10 or 0x11, even though it is always called
> with the LOOKUP_RCU bit set in flags.
> >>>
> >>>Umm... Are those path_init() succeeding or failing? Note that path_init()
> >>>includes "walk everything except for the last component", so your
> >>>non-working
> >>>case is "have it walk anything at all". What's failing there? path_init()
> >>>or handling the remaining component?
> >>>
> >>path_init() returns -2. Guess that explains the unexpected flags ;-).
> >>The failuere is from
> >>link_path_walk()
> >>walk_component()
> >
> >Which is to say, lookup gave it a negative dentry. OK, let's just make
> >vfs_mkdir() and walk_component() print what they are doing; on top of
> >linux-next
> >
> >diff --git a/fs/namei.c b/fs/namei.c
> >index 323957f..8a4e22f 100644
> >--- a/fs/namei.c
> >+++ b/fs/namei.c
> >@@ -1586,8 +1586,11 @@ static inline int walk_component(struct nameidata
> >*nd, struct path *path,
> > inode = path->dentry->d_inode;
> > }
> > err = -ENOENT;
> >-if (!inode || d_is_negative(path->dentry))
> >+if (!inode || d_is_negative(path->dentry)) {
> >+printk(KERN_ERR "walk_component[%p,%pd4] -> negative\n",
> >+path->dentry, path->dentry);
> > goto out_path_put;
> >+}
> >
> > if (should_follow_link(path->dentry, follow)) {
> > if (nd->flags & LOOKUP_RCU) {
> >@@ -3521,6 +3524,7 @@ int vfs_mkdir(struct inode *dir, struct dentry
> >*dentry, umode_t mode)
> > error = dir->i_op->mkdir(dir, dentry, mode);
> > if (!error)
> > fsnotify_mkdir(dir, dentry);
> >+printk(KERN_ERR "mkdir[%p,%pd4] => %d\n", dentry, dentry, error);
> > return error;
> > }
> > EXPORT_SYMBOL(vfs_mkdir);
> >
>
> ok case (putname commented out):
>
> user_path_at_empty lookup usr flags 0x0
> path_lookupat: calling path_init 'usr' flags=40
> path_init: link_path_walk() returned 0
> path_lookupat: path_init 'usr' flags=40[50] returned 0
> walk_component: lookup_fast() returned 1
> walk_component: lookup_slow() returned 0
> walk_component: inode= (null), negative=1
> do_path_lookup(usr, 0x10)
> path_lookupat: calling path_init 'usr' flags=50
> path_init: link_path_walk() returned 0
> path_lookupat: path_init 'usr' flags=50[50] returned 0
> mkdir[c74012a0,/usr] => 0
> user_path_at_empty lookup usr flags 0x1
> path_lookupat: calling path_init 'usr' flags=41
> path_init: link_path_walk() returned 0
> path_lookupat: path_init 'usr' flags=41[51] returned 0
> walk_component: inode=c74004a0, negative=0
> user_path_at_empty lookup usr flags 0x1
> path_lookupat: calling path_init 'usr' flags=41
> path_init: link_path_walk() returned 0
> path_lookupat: path_init 'usr' flags=41[51] returned 0
>
> failing case:
>
> path_lookupat: calling path_init 'usr' flags=40
> path_init: link_path_walk() returned 0
> path_lookupat: path_init 'usr' flags=40[50] returned 0
> walk_component: lookup_fast() returned 1
> walk_component: lookup_slow() returned 0
> walk_component: inode= (null), negative=1
> do_path_lookup(usr, 0x10)
> path_lookupat: calling path_init 'usr' flags=50
> path_init: link_path_walk() returned 0
> path_lookupat: path_init 'usr' flags=50[50] returned 0
> mkdir[c74012a0,/kkk] => 0 <
> SIC!
> user_path_at_empty lookup usr flags 0x1
> path_lookupat: calling path_init 'usr' flags=41
> path_init: link_path_walk() returned 0
> path_lookupat: path_init 'usr' flags=41[51] returned 0
> walk_component: lookup_fast() returned 1
> walk_component: lookup_slow() returned 0
> walk_component: inode= (null), negative=1
> user_path_at_empty lookup usr flags 0x1
> path_lookupat: calling path_init 'usr' flags=41
> path_init: link_path_walk() returned 0
> path_lookupat: path_init 'usr' flags=41[51] returned 0
> walk_component: lookup_fast() returned 1
> walk_component: lookup_slow() returned 0
> walk_component: inode= (null), negative=1
Yep, I get some "kkk" too.
With that patch:
## panic
[0.544839] walk_component[88001d6edbd8,/dev] -> negative
[0.545507] mkdir[88001d6ed1b8,/kkk] => 0
[0.545886] sys_mkdir dev:40755 returned 0
[0.546275] walk_component[88001d6ec288,/dev] -> negative
[0.546835] walk_component[88001d6eca20,/dev] -> negative
[0.547403] walk_component[88001d6ed950,/dev] -> negative
[0.547954] walk_component[88001d6ed440,/dev] -> negative
[0.549260]
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On Wed, Jan 21, 2015 at 01:03:20PM -0800, Guenter Roeck wrote:
> ok case (putname commented out):
>
> user_path_at_empty lookup usr flags 0x0
> path_lookupat: calling path_init 'usr' flags=40
> path_init: link_path_walk() returned 0
> path_lookupat: path_init 'usr' flags=40[50] returned 0
> walk_component: lookup_fast() returned 1
> walk_component: lookup_slow() returned 0
> walk_component: inode= (null), negative=1
> do_path_lookup(usr, 0x10)
> path_lookupat: calling path_init 'usr' flags=50
> path_init: link_path_walk() returned 0
> path_lookupat: path_init 'usr' flags=50[50] returned 0
> mkdir[c74012a0,/usr] => 0
> user_path_at_empty lookup usr flags 0x1
> path_lookupat: calling path_init 'usr' flags=41
> path_init: link_path_walk() returned 0
> path_lookupat: path_init 'usr' flags=41[51] returned 0
> walk_component: inode=c74004a0, negative=0
> user_path_at_empty lookup usr flags 0x1
> path_lookupat: calling path_init 'usr' flags=41
> path_init: link_path_walk() returned 0
> path_lookupat: path_init 'usr' flags=41[51] returned 0
>
> failing case:
>
> path_lookupat: calling path_init 'usr' flags=40
> path_init: link_path_walk() returned 0
> path_lookupat: path_init 'usr' flags=40[50] returned 0
> walk_component: lookup_fast() returned 1
> walk_component: lookup_slow() returned 0
> walk_component: inode= (null), negative=1
> do_path_lookup(usr, 0x10)
> path_lookupat: calling path_init 'usr' flags=50
> path_init: link_path_walk() returned 0
> path_lookupat: path_init 'usr' flags=50[50] returned 0
> mkdir[c74012a0,/kkk] => 0 <
> SIC!
Cute. 'k' being 0x6b, aka POISON_FREE... OK, the next question is what's
been freed under us - I don't believe that it's dentry itself...
Oh, fuck. OK, I see what happens. Look at kern_path_create(); it does
LOOKUP_PARENT walk, leaving nd->last pointing to the last component of
the *COPY* of the name it's just created, walked and freed.
OK... Fortunately, struct nameidata is completely opaque outside of fs/namei.c,
so we only need to care about a couple of codepaths.
Folks, could you check if the following on top of linux-next fixes the problem?
diff --git a/fs/namei.c b/fs/namei.c
index 323957f..cda89c3 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -2056,13 +2056,22 @@ static int do_path_lookup(int dfd, const char *name,
/* does lookup, returns the object with parent locked */
struct dentry *kern_path_locked(const char *name, struct path *path)
{
+ struct filename *filename = getname_kernel(name);
struct nameidata nd;
struct dentry *d;
- int err = do_path_lookup(AT_FDCWD, name, LOOKUP_PARENT, );
- if (err)
+ int err;
+
+ if (IS_ERR(filename))
+ return ERR_CAST(filename);
+
+ err = filename_lookup(AT_FDCWD, filename, LOOKUP_PARENT, );
+ if (err) {
+ putname(filename);
return ERR_PTR(err);
+ }
if (nd.last_type != LAST_NORM) {
path_put();
+ putname(filename);
return ERR_PTR(-EINVAL);
}
mutex_lock_nested(>d_inode->i_mutex, I_MUTEX_PARENT);
@@ -2070,9 +2079,11 @@ struct dentry *kern_path_locked(const char *name, struct
path *path)
if (IS_ERR(d)) {
mutex_unlock(>d_inode->i_mutex);
path_put();
+ putname(filename);
return d;
}
*path = nd.path;
+ putname(filename);
return d;
}
@@ -3314,7 +3325,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 *filename_create(int dfd, struct filename *name,
struct path *path, unsigned int lookup_flags)
{
struct dentry *dentry = ERR_PTR(-EEXIST);
@@ -3329,7 +3340,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, );
+ error = filename_lookup(dfd, name, LOOKUP_PARENT|lookup_flags, );
if (error)
return ERR_PTR(error);
@@ -3383,6 +3394,19 @@ out:
path_put();
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 = filename_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 +3425,7 @@ struct dentry *user_path_create(int dfd, const char
__user *pathname,
struct dentry *res;
if (IS_ERR(tmp))
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On 01/21/2015 12:06 PM, Al Viro wrote:
On Wed, Jan 21, 2015 at 11:06:27AM -0800, Guenter Roeck wrote:
On 01/21/2015 10:29 AM, Al Viro wrote:
On Wed, Jan 21, 2015 at 05:32:13AM -0800, Guenter Roeck wrote:
Another data point (though I have no idea if it is useful or what it means):
In the working case, path_init sets nd->flags to 0x50 or 0x51.
In the non-working case (ie for all files with a '/' in the name),
it sets nd->flags to 0x10 or 0x11, even though it is always called
with the LOOKUP_RCU bit set in flags.
Umm... Are those path_init() succeeding or failing? Note that path_init()
includes "walk everything except for the last component", so your non-working
case is "have it walk anything at all". What's failing there? path_init()
or handling the remaining component?
path_init() returns -2. Guess that explains the unexpected flags ;-).
The failuere is from
link_path_walk()
walk_component()
Which is to say, lookup gave it a negative dentry. OK, let's just make
vfs_mkdir() and walk_component() print what they are doing; on top of
linux-next
diff --git a/fs/namei.c b/fs/namei.c
index 323957f..8a4e22f 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -1586,8 +1586,11 @@ static inline int walk_component(struct nameidata *nd,
struct path *path,
inode = path->dentry->d_inode;
}
err = -ENOENT;
- if (!inode || d_is_negative(path->dentry))
+ if (!inode || d_is_negative(path->dentry)) {
+ printk(KERN_ERR "walk_component[%p,%pd4] -> negative\n",
+ path->dentry, path->dentry);
goto out_path_put;
+ }
if (should_follow_link(path->dentry, follow)) {
if (nd->flags & LOOKUP_RCU) {
@@ -3521,6 +3524,7 @@ int vfs_mkdir(struct inode *dir, struct dentry *dentry,
umode_t mode)
error = dir->i_op->mkdir(dir, dentry, mode);
if (!error)
fsnotify_mkdir(dir, dentry);
+ printk(KERN_ERR "mkdir[%p,%pd4] => %d\n", dentry, dentry, error);
return error;
}
EXPORT_SYMBOL(vfs_mkdir);
ok case (putname commented out):
user_path_at_empty lookup usr flags 0x0
path_lookupat: calling path_init 'usr' flags=40
path_init: link_path_walk() returned 0
path_lookupat: path_init 'usr' flags=40[50] returned 0
walk_component: lookup_fast() returned 1
walk_component: lookup_slow() returned 0
walk_component: inode= (null), negative=1
do_path_lookup(usr, 0x10)
path_lookupat: calling path_init 'usr' flags=50
path_init: link_path_walk() returned 0
path_lookupat: path_init 'usr' flags=50[50] returned 0
mkdir[c74012a0,/usr] => 0
user_path_at_empty lookup usr flags 0x1
path_lookupat: calling path_init 'usr' flags=41
path_init: link_path_walk() returned 0
path_lookupat: path_init 'usr' flags=41[51] returned 0
walk_component: inode=c74004a0, negative=0
user_path_at_empty lookup usr flags 0x1
path_lookupat: calling path_init 'usr' flags=41
path_init: link_path_walk() returned 0
path_lookupat: path_init 'usr' flags=41[51] returned 0
failing case:
path_lookupat: calling path_init 'usr' flags=40
path_init: link_path_walk() returned 0
path_lookupat: path_init 'usr' flags=40[50] returned 0
walk_component: lookup_fast() returned 1
walk_component: lookup_slow() returned 0
walk_component: inode= (null), negative=1
do_path_lookup(usr, 0x10)
path_lookupat: calling path_init 'usr' flags=50
path_init: link_path_walk() returned 0
path_lookupat: path_init 'usr' flags=50[50] returned 0
mkdir[c74012a0,/kkk] => 0< SIC!
user_path_at_empty lookup usr flags 0x1
path_lookupat: calling path_init 'usr' flags=41
path_init: link_path_walk() returned 0
path_lookupat: path_init 'usr' flags=41[51] returned 0
walk_component: lookup_fast() returned 1
walk_component: lookup_slow() returned 0
walk_component: inode= (null), negative=1
user_path_at_empty lookup usr flags 0x1
path_lookupat: calling path_init 'usr' flags=41
path_init: link_path_walk() returned 0
path_lookupat: path_init 'usr' flags=41[51] returned 0
walk_component: lookup_fast() returned 1
walk_component: lookup_slow() returned 0
walk_component: inode= (null), negative=1
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On Wed, Jan 21, 2015 at 11:06:27AM -0800, Guenter Roeck wrote:
> On 01/21/2015 10:29 AM, Al Viro wrote:
> >On Wed, Jan 21, 2015 at 05:32:13AM -0800, Guenter Roeck wrote:
> >>Another data point (though I have no idea if it is useful or what it means):
> >>
> >>In the working case, path_init sets nd->flags to 0x50 or 0x51.
> >>In the non-working case (ie for all files with a '/' in the name),
> >>it sets nd->flags to 0x10 or 0x11, even though it is always called
> >>with the LOOKUP_RCU bit set in flags.
> >
> >Umm... Are those path_init() succeeding or failing? Note that path_init()
> >includes "walk everything except for the last component", so your non-working
> >case is "have it walk anything at all". What's failing there? path_init()
> >or handling the remaining component?
> >
> path_init() returns -2. Guess that explains the unexpected flags ;-).
> The failuere is from
> link_path_walk()
> walk_component()
Which is to say, lookup gave it a negative dentry. OK, let's just make
vfs_mkdir() and walk_component() print what they are doing; on top of
linux-next
diff --git a/fs/namei.c b/fs/namei.c
index 323957f..8a4e22f 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -1586,8 +1586,11 @@ static inline int walk_component(struct nameidata *nd,
struct path *path,
inode = path->dentry->d_inode;
}
err = -ENOENT;
- if (!inode || d_is_negative(path->dentry))
+ if (!inode || d_is_negative(path->dentry)) {
+ printk(KERN_ERR "walk_component[%p,%pd4] -> negative\n",
+ path->dentry, path->dentry);
goto out_path_put;
+ }
if (should_follow_link(path->dentry, follow)) {
if (nd->flags & LOOKUP_RCU) {
@@ -3521,6 +3524,7 @@ int vfs_mkdir(struct inode *dir, struct dentry *dentry,
umode_t mode)
error = dir->i_op->mkdir(dir, dentry, mode);
if (!error)
fsnotify_mkdir(dir, dentry);
+ printk(KERN_ERR "mkdir[%p,%pd4] => %d\n", dentry, dentry, error);
return error;
}
EXPORT_SYMBOL(vfs_mkdir);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On 01/21/2015 10:29 AM, Al Viro wrote: On Wed, Jan 21, 2015 at 05:32:13AM -0800, Guenter Roeck wrote: Another data point (though I have no idea if it is useful or what it means): In the working case, path_init sets nd->flags to 0x50 or 0x51. In the non-working case (ie for all files with a '/' in the name), it sets nd->flags to 0x10 or 0x11, even though it is always called with the LOOKUP_RCU bit set in flags. Umm... Are those path_init() succeeding or failing? Note that path_init() includes "walk everything except for the last component", so your non-working case is "have it walk anything at all". What's failing there? path_init() or handling the remaining component? path_init() returns -2. Guess that explains the unexpected flags ;-). The failuere is from link_path_walk() walk_component() Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On Wed, Jan 21, 2015 at 05:32:13AM -0800, Guenter Roeck wrote: > Another data point (though I have no idea if it is useful or what it means): > > In the working case, path_init sets nd->flags to 0x50 or 0x51. > In the non-working case (ie for all files with a '/' in the name), > it sets nd->flags to 0x10 or 0x11, even though it is always called > with the LOOKUP_RCU bit set in flags. Umm... Are those path_init() succeeding or failing? Note that path_init() includes "walk everything except for the last component", so your non-working case is "have it walk anything at all". What's failing there? path_init() or handling the remaining component? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On 01/21/2015 09:38 AM, Al Viro wrote: On Wed, Jan 21, 2015 at 11:16:23AM -0500, Paul Moore wrote: On Wednesday, January 21, 2015 04:54:07 PM Sabrina Dubroca wrote: 2015-01-21, 16:39:12 +0100, Thierry Reding wrote: That doesn't seem to help, at least in my case. Same here. Okay, thanks for trying. Sorry that didn't resolve things. Well, it's probably not an audit issue. I tried audit=0 on the commandline, and I just rebuilt a kernel with CONFIG_AUDIT=n, and it's still panicing. This should have fixed any audit-related issue, right? Most likely. Back to the code I go ... FWIW, I really wonder if populate_rootfs() (run ultimately from kernel_init(), by way of kernel_init_freeable(), do_basic_setup() and do_initcalls()) ends up with some side effects as far as struct filename are concerned... Note that if we _ever_ hit reuse logics there, we are going to get bogus matches asoddingplenty - *all* those sys_mkdir(), etc. are going to be with filenames in the same reused buffer. So if anything in there leaks from one call to another, we are going to have a mess on hands. Another place where that can be a problem is devtmpfs - there's a kernel thread doing actual mkdir, mknod, etc. in that abomination and if _that_ ends up accumulating aushit entries, we'll end up with interesting problems. Folks, could you print the value of audit_dummy_context() in populate_rootfs() and in drivers/base/devtmpfs.c:devtmpfsd()? populate_rootfs: audit_dummy_context() returns 1 Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On Wed, Jan 21, 2015 at 11:16:23AM -0500, Paul Moore wrote: > On Wednesday, January 21, 2015 04:54:07 PM Sabrina Dubroca wrote: > > 2015-01-21, 16:39:12 +0100, Thierry Reding wrote: > > > That doesn't seem to help, at least in my case. > > > > Same here. > > Okay, thanks for trying. Sorry that didn't resolve things. > > > Well, it's probably not an audit issue. I tried audit=0 on the > > commandline, and I just rebuilt a kernel with CONFIG_AUDIT=n, and it's > > still panicing. This should have fixed any audit-related issue, > > right? > > Most likely. Back to the code I go ... FWIW, I really wonder if populate_rootfs() (run ultimately from kernel_init(), by way of kernel_init_freeable(), do_basic_setup() and do_initcalls()) ends up with some side effects as far as struct filename are concerned... Note that if we _ever_ hit reuse logics there, we are going to get bogus matches asoddingplenty - *all* those sys_mkdir(), etc. are going to be with filenames in the same reused buffer. So if anything in there leaks from one call to another, we are going to have a mess on hands. Another place where that can be a problem is devtmpfs - there's a kernel thread doing actual mkdir, mknod, etc. in that abomination and if _that_ ends up accumulating aushit entries, we'll end up with interesting problems. Folks, could you print the value of audit_dummy_context() in populate_rootfs() and in drivers/base/devtmpfs.c:devtmpfsd()? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On 01/21/2015 07:54 AM, Sabrina Dubroca wrote:
2015-01-21, 16:39:12 +0100, Thierry Reding wrote:
On Wed, Jan 21, 2015 at 10:24:11AM -0500, Paul Moore wrote:
On Wednesday, January 21, 2015 03:42:16 PM Thierry Reding wrote:
On Wed, Jan 21, 2015 at 12:05:39PM +0100, Sabrina Dubroca wrote:
2015-01-21, 04:36:38 +, Al Viro wrote:
On Tue, Jan 20, 2015 at 08:01:26PM -0800, Guenter Roeck wrote:
With this patch:
sys_mkdir .:40775 returned -17
sys_mkdir usr:40775 returned 0
sys_mkdir usr/lib:40775 returned 0
sys_mkdir usr/share:40755 returned 0
sys_mkdir usr/share/udhcpc:40755 returned 0
sys_mkdir usr/bin:40775 returned 0
sys_mkdir usr/sbin:40775 returned 0
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 0
...
and the problem is fixed.
This patch also works for me.
... except that it simply confirms that something's fishy with
getname_kernel() of ->name of struct filename returned by getname().
IOW, I still do not understand the mechanism of breakage there.
I'm not so sure about that. I tried to copy name to a new string in
do_path_lookup and that didn't help.
Now, I've removed the
putname(filename);
line from do_path_lookup and I don't get the panic.
That would indicate that somehow the refcount got unbalanced. Looking
more closely it seems like the various audit_*() function do take a
reference, but maybe that's not enough.
I'm thinking the same thing and I think the problem may be that
__audit_reusename() is not bumping the filename->refcnt. Can someone who is
seeing this problem bump the refcnt in __audit_reusename()?
struct filename *
__audit_reusename(const __user char *uptr)
{
struct audit_context *context = current->audit_context;
struct audit_names *n;
list_for_each_entry(n, >names_list, list) {
if (!n->name)
continue;
if (n->name->uptr == uptr) {
+ n->name->refcnt++;
return n->name;
}
}
return NULL;
}
That doesn't seem to help, at least in my case.
Same here.
Well, it's probably not an audit issue. I tried audit=0 on the
commandline, and I just rebuilt a kernel with CONFIG_AUDIT=n, and it's
still panicing. This should have fixed any audit-related issue,
right?
I don't have audit enabled, so I don't think that is the problem either
(the refcount increase didn't help, and a WARN(1) added to the code
at the same location did not trigger).
Wonder if we have a use-after-free case and just have been lucky all along.
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On Wednesday, January 21, 2015 04:54:07 PM Sabrina Dubroca wrote: > 2015-01-21, 16:39:12 +0100, Thierry Reding wrote: > > That doesn't seem to help, at least in my case. > > Same here. Okay, thanks for trying. Sorry that didn't resolve things. > Well, it's probably not an audit issue. I tried audit=0 on the > commandline, and I just rebuilt a kernel with CONFIG_AUDIT=n, and it's > still panicing. This should have fixed any audit-related issue, > right? Most likely. Back to the code I go ... -- paul moore security @ redhat -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
2015-01-21, 16:39:12 +0100, Thierry Reding wrote:
> On Wed, Jan 21, 2015 at 10:24:11AM -0500, Paul Moore wrote:
> > On Wednesday, January 21, 2015 03:42:16 PM Thierry Reding wrote:
> > > On Wed, Jan 21, 2015 at 12:05:39PM +0100, Sabrina Dubroca wrote:
> > > > 2015-01-21, 04:36:38 +, Al Viro wrote:
> > > > > On Tue, Jan 20, 2015 at 08:01:26PM -0800, Guenter Roeck wrote:
> > > > > > With this patch:
> > > > > >
> > > > > > sys_mkdir .:40775 returned -17
> > > > > > sys_mkdir usr:40775 returned 0
> > > > > > sys_mkdir usr/lib:40775 returned 0
> > > > > > sys_mkdir usr/share:40755 returned 0
> > > > > > sys_mkdir usr/share/udhcpc:40755 returned 0
> > > > > > sys_mkdir usr/bin:40775 returned 0
> > > > > > sys_mkdir usr/sbin:40775 returned 0
> > > > > > 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 0
> > > > > > ...
> > > > > >
> > > > > > and the problem is fixed.
> > > >
> > > > This patch also works for me.
> > > >
> > > > > ... except that it simply confirms that something's fishy with
> > > > > getname_kernel() of ->name of struct filename returned by getname().
> > > > > IOW, I still do not understand the mechanism of breakage there.
> > > >
> > > > I'm not so sure about that. I tried to copy name to a new string in
> > > > do_path_lookup and that didn't help.
> > > >
> > > > Now, I've removed the
> > > >
> > > > putname(filename);
> > > >
> > > > line from do_path_lookup and I don't get the panic.
> > >
> > > That would indicate that somehow the refcount got unbalanced. Looking
> > > more closely it seems like the various audit_*() function do take a
> > > reference, but maybe that's not enough.
> >
> > I'm thinking the same thing and I think the problem may be that
> > __audit_reusename() is not bumping the filename->refcnt. Can someone who
> > is
> > seeing this problem bump the refcnt in __audit_reusename()?
> >
> > struct filename *
> > __audit_reusename(const __user char *uptr)
> > {
> > struct audit_context *context = current->audit_context;
> > struct audit_names *n;
> >
> > list_for_each_entry(n, >names_list, list) {
> > if (!n->name)
> > continue;
> > if (n->name->uptr == uptr) {
> > + n->name->refcnt++;
> > return n->name;
> > }
> > }
> > return NULL;
> > }
>
> That doesn't seem to help, at least in my case.
Same here.
Well, it's probably not an audit issue. I tried audit=0 on the
commandline, and I just rebuilt a kernel with CONFIG_AUDIT=n, and it's
still panicing. This should have fixed any audit-related issue,
right?
--
Sabrina
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On Wed, Jan 21, 2015 at 10:24:11AM -0500, Paul Moore wrote:
> On Wednesday, January 21, 2015 03:42:16 PM Thierry Reding wrote:
> > On Wed, Jan 21, 2015 at 12:05:39PM +0100, Sabrina Dubroca wrote:
> > > 2015-01-21, 04:36:38 +, Al Viro wrote:
> > > > On Tue, Jan 20, 2015 at 08:01:26PM -0800, Guenter Roeck wrote:
> > > > > With this patch:
> > > > >
> > > > > sys_mkdir .:40775 returned -17
> > > > > sys_mkdir usr:40775 returned 0
> > > > > sys_mkdir usr/lib:40775 returned 0
> > > > > sys_mkdir usr/share:40755 returned 0
> > > > > sys_mkdir usr/share/udhcpc:40755 returned 0
> > > > > sys_mkdir usr/bin:40775 returned 0
> > > > > sys_mkdir usr/sbin:40775 returned 0
> > > > > 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 0
> > > > > ...
> > > > >
> > > > > and the problem is fixed.
> > >
> > > This patch also works for me.
> > >
> > > > ... except that it simply confirms that something's fishy with
> > > > getname_kernel() of ->name of struct filename returned by getname().
> > > > IOW, I still do not understand the mechanism of breakage there.
> > >
> > > I'm not so sure about that. I tried to copy name to a new string in
> > > do_path_lookup and that didn't help.
> > >
> > > Now, I've removed the
> > >
> > > putname(filename);
> > >
> > > line from do_path_lookup and I don't get the panic.
> >
> > That would indicate that somehow the refcount got unbalanced. Looking
> > more closely it seems like the various audit_*() function do take a
> > reference, but maybe that's not enough.
>
> I'm thinking the same thing and I think the problem may be that
> __audit_reusename() is not bumping the filename->refcnt. Can someone who is
> seeing this problem bump the refcnt in __audit_reusename()?
>
> struct filename *
> __audit_reusename(const __user char *uptr)
> {
> struct audit_context *context = current->audit_context;
> struct audit_names *n;
>
> list_for_each_entry(n, >names_list, list) {
> if (!n->name)
> continue;
> if (n->name->uptr == uptr) {
> + n->name->refcnt++;
> return n->name;
> }
> }
> return NULL;
> }
That doesn't seem to help, at least in my case.
Thierry
pgpcbzV7dLN6u.pgp
Description: PGP signature
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On Wednesday, January 21, 2015 03:42:16 PM Thierry Reding wrote:
> On Wed, Jan 21, 2015 at 12:05:39PM +0100, Sabrina Dubroca wrote:
> > 2015-01-21, 04:36:38 +, Al Viro wrote:
> > > On Tue, Jan 20, 2015 at 08:01:26PM -0800, Guenter Roeck wrote:
> > > > With this patch:
> > > >
> > > > sys_mkdir .:40775 returned -17
> > > > sys_mkdir usr:40775 returned 0
> > > > sys_mkdir usr/lib:40775 returned 0
> > > > sys_mkdir usr/share:40755 returned 0
> > > > sys_mkdir usr/share/udhcpc:40755 returned 0
> > > > sys_mkdir usr/bin:40775 returned 0
> > > > sys_mkdir usr/sbin:40775 returned 0
> > > > 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 0
> > > > ...
> > > >
> > > > and the problem is fixed.
> >
> > This patch also works for me.
> >
> > > ... except that it simply confirms that something's fishy with
> > > getname_kernel() of ->name of struct filename returned by getname().
> > > IOW, I still do not understand the mechanism of breakage there.
> >
> > I'm not so sure about that. I tried to copy name to a new string in
> > do_path_lookup and that didn't help.
> >
> > Now, I've removed the
> >
> > putname(filename);
> >
> > line from do_path_lookup and I don't get the panic.
>
> That would indicate that somehow the refcount got unbalanced. Looking
> more closely it seems like the various audit_*() function do take a
> reference, but maybe that's not enough.
I'm thinking the same thing and I think the problem may be that
__audit_reusename() is not bumping the filename->refcnt. Can someone who is
seeing this problem bump the refcnt in __audit_reusename()?
struct filename *
__audit_reusename(const __user char *uptr)
{
struct audit_context *context = current->audit_context;
struct audit_names *n;
list_for_each_entry(n, >names_list, list) {
if (!n->name)
continue;
if (n->name->uptr == uptr) {
+ n->name->refcnt++;
return n->name;
}
}
return NULL;
}
--
paul moore
security @ redhat
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On Wednesday, January 21, 2015 04:36:38 AM Al Viro wrote:
> Another thing I really do not understand is
> + if (inode->i_ino) {
> + /* valid inode number, use that for the ...
> + if (n->ino != inode->i_ino ||
> + n->dev != inode->i_sb->s_dev)
> + continue;
> in __audit_inode(). We don't *have* dentries with dentry->d_inode->i_ino ==
> 0. Ever. WTF is that about? Paul?
Likely stupidity on my part. It looks like a typo, that first if conditional
should check "n->ino" instead of "inode->i_ino"; in __audit_getname() we
record names without any inode numbers, so we need to see if this is one of
those records. Interesting that it passed my testing; either my testing is
crap (always a strong possibility) or something else came to the rescue. I'm
still coming up to speed on the audit/VFS code ...
I'll fix that up and include in the next patchset once we resolve this issue.
--
paul moore
security @ redhat
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On Wed, Jan 21, 2015 at 12:05:39PM +0100, Sabrina Dubroca wrote: > 2015-01-21, 04:36:38 +, Al Viro wrote: > > On Tue, Jan 20, 2015 at 08:01:26PM -0800, Guenter Roeck wrote: > > > With this patch: > > > > > > sys_mkdir .:40775 returned -17 > > > sys_mkdir usr:40775 returned 0 > > > sys_mkdir usr/lib:40775 returned 0 > > > sys_mkdir usr/share:40755 returned 0 > > > sys_mkdir usr/share/udhcpc:40755 returned 0 > > > sys_mkdir usr/bin:40775 returned 0 > > > sys_mkdir usr/sbin:40775 returned 0 > > > 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 0 > > > ... > > > > > > and the problem is fixed. > > This patch also works for me. > > > > ... except that it simply confirms that something's fishy with > > getname_kernel() > > of ->name of struct filename returned by getname(). IOW, I still do not > > understand the mechanism of breakage there. > > I'm not so sure about that. I tried to copy name to a new string in > do_path_lookup and that didn't help. > > Now, I've removed the > > putname(filename); > > line from do_path_lookup and I don't get the panic. That would indicate that somehow the refcount got unbalanced. Looking more closely it seems like the various audit_*() function do take a reference, but maybe that's not enough. But debugging this further I see no indication that the memory is ever freed, or otherwise corrupted. I did collect a bit more data, perhaps that's useful. I started seeing this issue as well on devices that boot over NFS. After reading this thread I also realized that another warning that I was seeing might be related: [ 28.261930] Warning: unable to open an initial console. I've added a couple of printks and see that the reason for this is that /dev/console doesn't get created. /dev however does get created. [ 11.786627] sys_mkdir dev:40755 returned 0 ... [ 11.978748] sys_mknod dev/console:20600 returned -2 The chain that fails turns out to be this: sys_mknod() sys_mknodat() user_path_create() kern_path_create() do_path_lookup() filename_lookup() path_lookupat() path_init() link_path_walk() walk_component() walk_components() ends up calling lookup_slow() and the result is that inode == NULL and d_is_negative(path->dentry) returns true, therefore causing -ENOENT to be returned. I tried to figure out why inode would be NULL at that point or why d_is_negative() returned true, but I ended up getting completely lost, so I thought it best to report my findings before I confuse everything. Is there anything else I can investigate to track this down? Thierry pgpt9_x3k1AqW.pgp Description: PGP signature
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On 01/21/2015 03:05 AM, Sabrina Dubroca wrote: 2015-01-21, 04:36:38 +, Al Viro wrote: On Tue, Jan 20, 2015 at 08:01:26PM -0800, Guenter Roeck wrote: With this patch: sys_mkdir .:40775 returned -17 sys_mkdir usr:40775 returned 0 sys_mkdir usr/lib:40775 returned 0 sys_mkdir usr/share:40755 returned 0 sys_mkdir usr/share/udhcpc:40755 returned 0 sys_mkdir usr/bin:40775 returned 0 sys_mkdir usr/sbin:40775 returned 0 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 0 ... and the problem is fixed. This patch also works for me. ... except that it simply confirms that something's fishy with getname_kernel() of ->name of struct filename returned by getname(). IOW, I still do not understand the mechanism of breakage there. I'm not so sure about that. I tried to copy name to a new string in do_path_lookup and that didn't help. Now, I've removed the putname(filename); line from do_path_lookup and I don't get the panic. And BTW, I added Guenter's debugging to init/initramfs.c and got: sys_mkdir dev:40755 returned 0 sys_mkdir root:40700 returned 0 even if it ends up panic'ing. Another data point (though I have no idea if it is useful or what it means): In the working case, path_init sets nd->flags to 0x50 or 0x51. In the non-working case (ie for all files with a '/' in the name), it sets nd->flags to 0x10 or 0x11, even though it is always called with the LOOKUP_RCU bit set in flags. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
2015-01-21, 04:36:38 +, Al Viro wrote: > On Tue, Jan 20, 2015 at 08:01:26PM -0800, Guenter Roeck wrote: > > With this patch: > > > > sys_mkdir .:40775 returned -17 > > sys_mkdir usr:40775 returned 0 > > sys_mkdir usr/lib:40775 returned 0 > > sys_mkdir usr/share:40755 returned 0 > > sys_mkdir usr/share/udhcpc:40755 returned 0 > > sys_mkdir usr/bin:40775 returned 0 > > sys_mkdir usr/sbin:40775 returned 0 > > 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 0 > > ... > > > > and the problem is fixed. This patch also works for me. > ... except that it simply confirms that something's fishy with > getname_kernel() > of ->name of struct filename returned by getname(). IOW, I still do not > understand the mechanism of breakage there. I'm not so sure about that. I tried to copy name to a new string in do_path_lookup and that didn't help. Now, I've removed the putname(filename); line from do_path_lookup and I don't get the panic. And BTW, I added Guenter's debugging to init/initramfs.c and got: sys_mkdir dev:40755 returned 0 sys_mkdir root:40700 returned 0 even if it ends up panic'ing. -- Sabrina -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On 01/21/2015 09:38 AM, Al Viro wrote: On Wed, Jan 21, 2015 at 11:16:23AM -0500, Paul Moore wrote: On Wednesday, January 21, 2015 04:54:07 PM Sabrina Dubroca wrote: 2015-01-21, 16:39:12 +0100, Thierry Reding wrote: That doesn't seem to help, at least in my case. Same here. Okay, thanks for trying. Sorry that didn't resolve things. Well, it's probably not an audit issue. I tried audit=0 on the commandline, and I just rebuilt a kernel with CONFIG_AUDIT=n, and it's still panicing. This should have fixed any audit-related issue, right? Most likely. Back to the code I go ... FWIW, I really wonder if populate_rootfs() (run ultimately from kernel_init(), by way of kernel_init_freeable(), do_basic_setup() and do_initcalls()) ends up with some side effects as far as struct filename are concerned... Note that if we _ever_ hit reuse logics there, we are going to get bogus matches asoddingplenty - *all* those sys_mkdir(), etc. are going to be with filenames in the same reused buffer. So if anything in there leaks from one call to another, we are going to have a mess on hands. Another place where that can be a problem is devtmpfs - there's a kernel thread doing actual mkdir, mknod, etc. in that abomination and if _that_ ends up accumulating aushit entries, we'll end up with interesting problems. Folks, could you print the value of audit_dummy_context() in populate_rootfs() and in drivers/base/devtmpfs.c:devtmpfsd()? populate_rootfs: audit_dummy_context() returns 1 Guenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On Wed, Jan 21, 2015 at 05:32:13AM -0800, Guenter Roeck wrote: Another data point (though I have no idea if it is useful or what it means): In the working case, path_init sets nd-flags to 0x50 or 0x51. In the non-working case (ie for all files with a '/' in the name), it sets nd-flags to 0x10 or 0x11, even though it is always called with the LOOKUP_RCU bit set in flags. Umm... Are those path_init() succeeding or failing? Note that path_init() includes walk everything except for the last component, so your non-working case is have it walk anything at all. What's failing there? path_init() or handling the remaining component? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On 01/21/2015 10:29 AM, Al Viro wrote: On Wed, Jan 21, 2015 at 05:32:13AM -0800, Guenter Roeck wrote: Another data point (though I have no idea if it is useful or what it means): In the working case, path_init sets nd-flags to 0x50 or 0x51. In the non-working case (ie for all files with a '/' in the name), it sets nd-flags to 0x10 or 0x11, even though it is always called with the LOOKUP_RCU bit set in flags. Umm... Are those path_init() succeeding or failing? Note that path_init() includes walk everything except for the last component, so your non-working case is have it walk anything at all. What's failing there? path_init() or handling the remaining component? path_init() returns -2. Guess that explains the unexpected flags ;-). The failuere is from link_path_walk() walk_component() Guenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On Wed, Jan 21, 2015 at 11:16:23AM -0500, Paul Moore wrote: On Wednesday, January 21, 2015 04:54:07 PM Sabrina Dubroca wrote: 2015-01-21, 16:39:12 +0100, Thierry Reding wrote: That doesn't seem to help, at least in my case. Same here. Okay, thanks for trying. Sorry that didn't resolve things. Well, it's probably not an audit issue. I tried audit=0 on the commandline, and I just rebuilt a kernel with CONFIG_AUDIT=n, and it's still panicing. This should have fixed any audit-related issue, right? Most likely. Back to the code I go ... FWIW, I really wonder if populate_rootfs() (run ultimately from kernel_init(), by way of kernel_init_freeable(), do_basic_setup() and do_initcalls()) ends up with some side effects as far as struct filename are concerned... Note that if we _ever_ hit reuse logics there, we are going to get bogus matches asoddingplenty - *all* those sys_mkdir(), etc. are going to be with filenames in the same reused buffer. So if anything in there leaks from one call to another, we are going to have a mess on hands. Another place where that can be a problem is devtmpfs - there's a kernel thread doing actual mkdir, mknod, etc. in that abomination and if _that_ ends up accumulating aushit entries, we'll end up with interesting problems. Folks, could you print the value of audit_dummy_context() in populate_rootfs() and in drivers/base/devtmpfs.c:devtmpfsd()? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On Wed, Jan 21, 2015 at 10:24:11AM -0500, Paul Moore wrote:
On Wednesday, January 21, 2015 03:42:16 PM Thierry Reding wrote:
On Wed, Jan 21, 2015 at 12:05:39PM +0100, Sabrina Dubroca wrote:
2015-01-21, 04:36:38 +, Al Viro wrote:
On Tue, Jan 20, 2015 at 08:01:26PM -0800, Guenter Roeck wrote:
With this patch:
sys_mkdir .:40775 returned -17
sys_mkdir usr:40775 returned 0
sys_mkdir usr/lib:40775 returned 0
sys_mkdir usr/share:40755 returned 0
sys_mkdir usr/share/udhcpc:40755 returned 0
sys_mkdir usr/bin:40775 returned 0
sys_mkdir usr/sbin:40775 returned 0
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 0
...
and the problem is fixed.
This patch also works for me.
... except that it simply confirms that something's fishy with
getname_kernel() of -name of struct filename returned by getname().
IOW, I still do not understand the mechanism of breakage there.
I'm not so sure about that. I tried to copy name to a new string in
do_path_lookup and that didn't help.
Now, I've removed the
putname(filename);
line from do_path_lookup and I don't get the panic.
That would indicate that somehow the refcount got unbalanced. Looking
more closely it seems like the various audit_*() function do take a
reference, but maybe that's not enough.
I'm thinking the same thing and I think the problem may be that
__audit_reusename() is not bumping the filename-refcnt. Can someone who is
seeing this problem bump the refcnt in __audit_reusename()?
struct filename *
__audit_reusename(const __user char *uptr)
{
struct audit_context *context = current-audit_context;
struct audit_names *n;
list_for_each_entry(n, context-names_list, list) {
if (!n-name)
continue;
if (n-name-uptr == uptr) {
+ n-name-refcnt++;
return n-name;
}
}
return NULL;
}
That doesn't seem to help, at least in my case.
Thierry
pgpcbzV7dLN6u.pgp
Description: PGP signature
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
2015-01-21, 16:39:12 +0100, Thierry Reding wrote:
On Wed, Jan 21, 2015 at 10:24:11AM -0500, Paul Moore wrote:
On Wednesday, January 21, 2015 03:42:16 PM Thierry Reding wrote:
On Wed, Jan 21, 2015 at 12:05:39PM +0100, Sabrina Dubroca wrote:
2015-01-21, 04:36:38 +, Al Viro wrote:
On Tue, Jan 20, 2015 at 08:01:26PM -0800, Guenter Roeck wrote:
With this patch:
sys_mkdir .:40775 returned -17
sys_mkdir usr:40775 returned 0
sys_mkdir usr/lib:40775 returned 0
sys_mkdir usr/share:40755 returned 0
sys_mkdir usr/share/udhcpc:40755 returned 0
sys_mkdir usr/bin:40775 returned 0
sys_mkdir usr/sbin:40775 returned 0
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 0
...
and the problem is fixed.
This patch also works for me.
... except that it simply confirms that something's fishy with
getname_kernel() of -name of struct filename returned by getname().
IOW, I still do not understand the mechanism of breakage there.
I'm not so sure about that. I tried to copy name to a new string in
do_path_lookup and that didn't help.
Now, I've removed the
putname(filename);
line from do_path_lookup and I don't get the panic.
That would indicate that somehow the refcount got unbalanced. Looking
more closely it seems like the various audit_*() function do take a
reference, but maybe that's not enough.
I'm thinking the same thing and I think the problem may be that
__audit_reusename() is not bumping the filename-refcnt. Can someone who
is
seeing this problem bump the refcnt in __audit_reusename()?
struct filename *
__audit_reusename(const __user char *uptr)
{
struct audit_context *context = current-audit_context;
struct audit_names *n;
list_for_each_entry(n, context-names_list, list) {
if (!n-name)
continue;
if (n-name-uptr == uptr) {
+ n-name-refcnt++;
return n-name;
}
}
return NULL;
}
That doesn't seem to help, at least in my case.
Same here.
Well, it's probably not an audit issue. I tried audit=0 on the
commandline, and I just rebuilt a kernel with CONFIG_AUDIT=n, and it's
still panicing. This should have fixed any audit-related issue,
right?
--
Sabrina
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On 01/21/2015 07:54 AM, Sabrina Dubroca wrote:
2015-01-21, 16:39:12 +0100, Thierry Reding wrote:
On Wed, Jan 21, 2015 at 10:24:11AM -0500, Paul Moore wrote:
On Wednesday, January 21, 2015 03:42:16 PM Thierry Reding wrote:
On Wed, Jan 21, 2015 at 12:05:39PM +0100, Sabrina Dubroca wrote:
2015-01-21, 04:36:38 +, Al Viro wrote:
On Tue, Jan 20, 2015 at 08:01:26PM -0800, Guenter Roeck wrote:
With this patch:
sys_mkdir .:40775 returned -17
sys_mkdir usr:40775 returned 0
sys_mkdir usr/lib:40775 returned 0
sys_mkdir usr/share:40755 returned 0
sys_mkdir usr/share/udhcpc:40755 returned 0
sys_mkdir usr/bin:40775 returned 0
sys_mkdir usr/sbin:40775 returned 0
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 0
...
and the problem is fixed.
This patch also works for me.
... except that it simply confirms that something's fishy with
getname_kernel() of -name of struct filename returned by getname().
IOW, I still do not understand the mechanism of breakage there.
I'm not so sure about that. I tried to copy name to a new string in
do_path_lookup and that didn't help.
Now, I've removed the
putname(filename);
line from do_path_lookup and I don't get the panic.
That would indicate that somehow the refcount got unbalanced. Looking
more closely it seems like the various audit_*() function do take a
reference, but maybe that's not enough.
I'm thinking the same thing and I think the problem may be that
__audit_reusename() is not bumping the filename-refcnt. Can someone who is
seeing this problem bump the refcnt in __audit_reusename()?
struct filename *
__audit_reusename(const __user char *uptr)
{
struct audit_context *context = current-audit_context;
struct audit_names *n;
list_for_each_entry(n, context-names_list, list) {
if (!n-name)
continue;
if (n-name-uptr == uptr) {
+ n-name-refcnt++;
return n-name;
}
}
return NULL;
}
That doesn't seem to help, at least in my case.
Same here.
Well, it's probably not an audit issue. I tried audit=0 on the
commandline, and I just rebuilt a kernel with CONFIG_AUDIT=n, and it's
still panicing. This should have fixed any audit-related issue,
right?
I don't have audit enabled, so I don't think that is the problem either
(the refcount increase didn't help, and a WARN(1) added to the code
at the same location did not trigger).
Wonder if we have a use-after-free case and just have been lucky all along.
Guenter
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On Wednesday, January 21, 2015 04:54:07 PM Sabrina Dubroca wrote: 2015-01-21, 16:39:12 +0100, Thierry Reding wrote: That doesn't seem to help, at least in my case. Same here. Okay, thanks for trying. Sorry that didn't resolve things. Well, it's probably not an audit issue. I tried audit=0 on the commandline, and I just rebuilt a kernel with CONFIG_AUDIT=n, and it's still panicing. This should have fixed any audit-related issue, right? Most likely. Back to the code I go ... -- paul moore security @ redhat -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On 01/21/2015 12:06 PM, Al Viro wrote:
On Wed, Jan 21, 2015 at 11:06:27AM -0800, Guenter Roeck wrote:
On 01/21/2015 10:29 AM, Al Viro wrote:
On Wed, Jan 21, 2015 at 05:32:13AM -0800, Guenter Roeck wrote:
Another data point (though I have no idea if it is useful or what it means):
In the working case, path_init sets nd-flags to 0x50 or 0x51.
In the non-working case (ie for all files with a '/' in the name),
it sets nd-flags to 0x10 or 0x11, even though it is always called
with the LOOKUP_RCU bit set in flags.
Umm... Are those path_init() succeeding or failing? Note that path_init()
includes walk everything except for the last component, so your non-working
case is have it walk anything at all. What's failing there? path_init()
or handling the remaining component?
path_init() returns -2. Guess that explains the unexpected flags ;-).
The failuere is from
link_path_walk()
walk_component()
Which is to say, lookup gave it a negative dentry. OK, let's just make
vfs_mkdir() and walk_component() print what they are doing; on top of
linux-next
diff --git a/fs/namei.c b/fs/namei.c
index 323957f..8a4e22f 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -1586,8 +1586,11 @@ static inline int walk_component(struct nameidata *nd,
struct path *path,
inode = path-dentry-d_inode;
}
err = -ENOENT;
- if (!inode || d_is_negative(path-dentry))
+ if (!inode || d_is_negative(path-dentry)) {
+ printk(KERN_ERR walk_component[%p,%pd4] - negative\n,
+ path-dentry, path-dentry);
goto out_path_put;
+ }
if (should_follow_link(path-dentry, follow)) {
if (nd-flags LOOKUP_RCU) {
@@ -3521,6 +3524,7 @@ int vfs_mkdir(struct inode *dir, struct dentry *dentry,
umode_t mode)
error = dir-i_op-mkdir(dir, dentry, mode);
if (!error)
fsnotify_mkdir(dir, dentry);
+ printk(KERN_ERR mkdir[%p,%pd4] = %d\n, dentry, dentry, error);
return error;
}
EXPORT_SYMBOL(vfs_mkdir);
ok case (putname commented out):
user_path_at_empty lookup usr flags 0x0
path_lookupat: calling path_init 'usr' flags=40
path_init: link_path_walk() returned 0
path_lookupat: path_init 'usr' flags=40[50] returned 0
walk_component: lookup_fast() returned 1
walk_component: lookup_slow() returned 0
walk_component: inode= (null), negative=1
do_path_lookup(usr, 0x10)
path_lookupat: calling path_init 'usr' flags=50
path_init: link_path_walk() returned 0
path_lookupat: path_init 'usr' flags=50[50] returned 0
mkdir[c74012a0,/usr] = 0
user_path_at_empty lookup usr flags 0x1
path_lookupat: calling path_init 'usr' flags=41
path_init: link_path_walk() returned 0
path_lookupat: path_init 'usr' flags=41[51] returned 0
walk_component: inode=c74004a0, negative=0
user_path_at_empty lookup usr flags 0x1
path_lookupat: calling path_init 'usr' flags=41
path_init: link_path_walk() returned 0
path_lookupat: path_init 'usr' flags=41[51] returned 0
failing case:
path_lookupat: calling path_init 'usr' flags=40
path_init: link_path_walk() returned 0
path_lookupat: path_init 'usr' flags=40[50] returned 0
walk_component: lookup_fast() returned 1
walk_component: lookup_slow() returned 0
walk_component: inode= (null), negative=1
do_path_lookup(usr, 0x10)
path_lookupat: calling path_init 'usr' flags=50
path_init: link_path_walk() returned 0
path_lookupat: path_init 'usr' flags=50[50] returned 0
mkdir[c74012a0,/kkk] = 0 SIC!
user_path_at_empty lookup usr flags 0x1
path_lookupat: calling path_init 'usr' flags=41
path_init: link_path_walk() returned 0
path_lookupat: path_init 'usr' flags=41[51] returned 0
walk_component: lookup_fast() returned 1
walk_component: lookup_slow() returned 0
walk_component: inode= (null), negative=1
user_path_at_empty lookup usr flags 0x1
path_lookupat: calling path_init 'usr' flags=41
path_init: link_path_walk() returned 0
path_lookupat: path_init 'usr' flags=41[51] returned 0
walk_component: lookup_fast() returned 1
walk_component: lookup_slow() returned 0
walk_component: inode= (null), negative=1
Guenter
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On Wed, Jan 21, 2015 at 09:28:33PM +, Al Viro wrote: On Wed, Jan 21, 2015 at 01:03:20PM -0800, Guenter Roeck wrote: failing case: path_lookupat: calling path_init 'usr' flags=40 path_init: link_path_walk() returned 0 path_lookupat: path_init 'usr' flags=40[50] returned 0 walk_component: lookup_fast() returned 1 walk_component: lookup_slow() returned 0 walk_component: inode= (null), negative=1 do_path_lookup(usr, 0x10) path_lookupat: calling path_init 'usr' flags=50 path_init: link_path_walk() returned 0 path_lookupat: path_init 'usr' flags=50[50] returned 0 mkdir[c74012a0,/kkk] = 0 SIC! Cute. 'k' being 0x6b, aka POISON_FREE... OK, the next question is what's been freed under us - I don't believe that it's dentry itself... Oh, fuck. OK, I see what happens. Look at kern_path_create(); it does LOOKUP_PARENT walk, leaving nd-last pointing to the last component of the *COPY* of the name it's just created, walked and freed. Cool. OK... Fortunately, struct nameidata is completely opaque outside of fs/namei.c, so we only need to care about a couple of codepaths. Folks, could you check if the following on top of linux-next fixes the problem? diff --git a/fs/namei.c b/fs/namei.c index 323957f..cda89c3 100644 Yes, this patch fixes the problem for me. Guenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On Wed, Jan 21, 2015 at 01:03:20PM -0800, Guenter Roeck wrote:
ok case (putname commented out):
user_path_at_empty lookup usr flags 0x0
path_lookupat: calling path_init 'usr' flags=40
path_init: link_path_walk() returned 0
path_lookupat: path_init 'usr' flags=40[50] returned 0
walk_component: lookup_fast() returned 1
walk_component: lookup_slow() returned 0
walk_component: inode= (null), negative=1
do_path_lookup(usr, 0x10)
path_lookupat: calling path_init 'usr' flags=50
path_init: link_path_walk() returned 0
path_lookupat: path_init 'usr' flags=50[50] returned 0
mkdir[c74012a0,/usr] = 0
user_path_at_empty lookup usr flags 0x1
path_lookupat: calling path_init 'usr' flags=41
path_init: link_path_walk() returned 0
path_lookupat: path_init 'usr' flags=41[51] returned 0
walk_component: inode=c74004a0, negative=0
user_path_at_empty lookup usr flags 0x1
path_lookupat: calling path_init 'usr' flags=41
path_init: link_path_walk() returned 0
path_lookupat: path_init 'usr' flags=41[51] returned 0
failing case:
path_lookupat: calling path_init 'usr' flags=40
path_init: link_path_walk() returned 0
path_lookupat: path_init 'usr' flags=40[50] returned 0
walk_component: lookup_fast() returned 1
walk_component: lookup_slow() returned 0
walk_component: inode= (null), negative=1
do_path_lookup(usr, 0x10)
path_lookupat: calling path_init 'usr' flags=50
path_init: link_path_walk() returned 0
path_lookupat: path_init 'usr' flags=50[50] returned 0
mkdir[c74012a0,/kkk] = 0
SIC!
Cute. 'k' being 0x6b, aka POISON_FREE... OK, the next question is what's
been freed under us - I don't believe that it's dentry itself...
Oh, fuck. OK, I see what happens. Look at kern_path_create(); it does
LOOKUP_PARENT walk, leaving nd-last pointing to the last component of
the *COPY* of the name it's just created, walked and freed.
OK... Fortunately, struct nameidata is completely opaque outside of fs/namei.c,
so we only need to care about a couple of codepaths.
Folks, could you check if the following on top of linux-next fixes the problem?
diff --git a/fs/namei.c b/fs/namei.c
index 323957f..cda89c3 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -2056,13 +2056,22 @@ static int do_path_lookup(int dfd, const char *name,
/* does lookup, returns the object with parent locked */
struct dentry *kern_path_locked(const char *name, struct path *path)
{
+ struct filename *filename = getname_kernel(name);
struct nameidata nd;
struct dentry *d;
- int err = do_path_lookup(AT_FDCWD, name, LOOKUP_PARENT, nd);
- if (err)
+ int err;
+
+ if (IS_ERR(filename))
+ return ERR_CAST(filename);
+
+ err = filename_lookup(AT_FDCWD, filename, LOOKUP_PARENT, nd);
+ if (err) {
+ putname(filename);
return ERR_PTR(err);
+ }
if (nd.last_type != LAST_NORM) {
path_put(nd.path);
+ putname(filename);
return ERR_PTR(-EINVAL);
}
mutex_lock_nested(nd.path.dentry-d_inode-i_mutex, I_MUTEX_PARENT);
@@ -2070,9 +2079,11 @@ struct dentry *kern_path_locked(const char *name, struct
path *path)
if (IS_ERR(d)) {
mutex_unlock(nd.path.dentry-d_inode-i_mutex);
path_put(nd.path);
+ putname(filename);
return d;
}
*path = nd.path;
+ putname(filename);
return d;
}
@@ -3314,7 +3325,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 *filename_create(int dfd, struct filename *name,
struct path *path, unsigned int lookup_flags)
{
struct dentry *dentry = ERR_PTR(-EEXIST);
@@ -3329,7 +3340,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 +3394,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 = filename_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 +3425,7 @@ struct dentry *user_path_create(int dfd, const char
__user *pathname,
struct dentry *res;
if
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On Wed, Jan 21, 2015 at 11:06:27AM -0800, Guenter Roeck wrote:
On 01/21/2015 10:29 AM, Al Viro wrote:
On Wed, Jan 21, 2015 at 05:32:13AM -0800, Guenter Roeck wrote:
Another data point (though I have no idea if it is useful or what it means):
In the working case, path_init sets nd-flags to 0x50 or 0x51.
In the non-working case (ie for all files with a '/' in the name),
it sets nd-flags to 0x10 or 0x11, even though it is always called
with the LOOKUP_RCU bit set in flags.
Umm... Are those path_init() succeeding or failing? Note that path_init()
includes walk everything except for the last component, so your non-working
case is have it walk anything at all. What's failing there? path_init()
or handling the remaining component?
path_init() returns -2. Guess that explains the unexpected flags ;-).
The failuere is from
link_path_walk()
walk_component()
Which is to say, lookup gave it a negative dentry. OK, let's just make
vfs_mkdir() and walk_component() print what they are doing; on top of
linux-next
diff --git a/fs/namei.c b/fs/namei.c
index 323957f..8a4e22f 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -1586,8 +1586,11 @@ static inline int walk_component(struct nameidata *nd,
struct path *path,
inode = path-dentry-d_inode;
}
err = -ENOENT;
- if (!inode || d_is_negative(path-dentry))
+ if (!inode || d_is_negative(path-dentry)) {
+ printk(KERN_ERR walk_component[%p,%pd4] - negative\n,
+ path-dentry, path-dentry);
goto out_path_put;
+ }
if (should_follow_link(path-dentry, follow)) {
if (nd-flags LOOKUP_RCU) {
@@ -3521,6 +3524,7 @@ int vfs_mkdir(struct inode *dir, struct dentry *dentry,
umode_t mode)
error = dir-i_op-mkdir(dir, dentry, mode);
if (!error)
fsnotify_mkdir(dir, dentry);
+ printk(KERN_ERR mkdir[%p,%pd4] = %d\n, dentry, dentry, error);
return error;
}
EXPORT_SYMBOL(vfs_mkdir);
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
2015-01-21, 13:03:20 -0800, Guenter Roeck wrote:
On 01/21/2015 12:06 PM, Al Viro wrote:
On Wed, Jan 21, 2015 at 11:06:27AM -0800, Guenter Roeck wrote:
On 01/21/2015 10:29 AM, Al Viro wrote:
On Wed, Jan 21, 2015 at 05:32:13AM -0800, Guenter Roeck wrote:
Another data point (though I have no idea if it is useful or what it
means):
In the working case, path_init sets nd-flags to 0x50 or 0x51.
In the non-working case (ie for all files with a '/' in the name),
it sets nd-flags to 0x10 or 0x11, even though it is always called
with the LOOKUP_RCU bit set in flags.
Umm... Are those path_init() succeeding or failing? Note that path_init()
includes walk everything except for the last component, so your
non-working
case is have it walk anything at all. What's failing there? path_init()
or handling the remaining component?
path_init() returns -2. Guess that explains the unexpected flags ;-).
The failuere is from
link_path_walk()
walk_component()
Which is to say, lookup gave it a negative dentry. OK, let's just make
vfs_mkdir() and walk_component() print what they are doing; on top of
linux-next
diff --git a/fs/namei.c b/fs/namei.c
index 323957f..8a4e22f 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -1586,8 +1586,11 @@ static inline int walk_component(struct nameidata
*nd, struct path *path,
inode = path-dentry-d_inode;
}
err = -ENOENT;
-if (!inode || d_is_negative(path-dentry))
+if (!inode || d_is_negative(path-dentry)) {
+printk(KERN_ERR walk_component[%p,%pd4] - negative\n,
+path-dentry, path-dentry);
goto out_path_put;
+}
if (should_follow_link(path-dentry, follow)) {
if (nd-flags LOOKUP_RCU) {
@@ -3521,6 +3524,7 @@ int vfs_mkdir(struct inode *dir, struct dentry
*dentry, umode_t mode)
error = dir-i_op-mkdir(dir, dentry, mode);
if (!error)
fsnotify_mkdir(dir, dentry);
+printk(KERN_ERR mkdir[%p,%pd4] = %d\n, dentry, dentry, error);
return error;
}
EXPORT_SYMBOL(vfs_mkdir);
ok case (putname commented out):
user_path_at_empty lookup usr flags 0x0
path_lookupat: calling path_init 'usr' flags=40
path_init: link_path_walk() returned 0
path_lookupat: path_init 'usr' flags=40[50] returned 0
walk_component: lookup_fast() returned 1
walk_component: lookup_slow() returned 0
walk_component: inode= (null), negative=1
do_path_lookup(usr, 0x10)
path_lookupat: calling path_init 'usr' flags=50
path_init: link_path_walk() returned 0
path_lookupat: path_init 'usr' flags=50[50] returned 0
mkdir[c74012a0,/usr] = 0
user_path_at_empty lookup usr flags 0x1
path_lookupat: calling path_init 'usr' flags=41
path_init: link_path_walk() returned 0
path_lookupat: path_init 'usr' flags=41[51] returned 0
walk_component: inode=c74004a0, negative=0
user_path_at_empty lookup usr flags 0x1
path_lookupat: calling path_init 'usr' flags=41
path_init: link_path_walk() returned 0
path_lookupat: path_init 'usr' flags=41[51] returned 0
failing case:
path_lookupat: calling path_init 'usr' flags=40
path_init: link_path_walk() returned 0
path_lookupat: path_init 'usr' flags=40[50] returned 0
walk_component: lookup_fast() returned 1
walk_component: lookup_slow() returned 0
walk_component: inode= (null), negative=1
do_path_lookup(usr, 0x10)
path_lookupat: calling path_init 'usr' flags=50
path_init: link_path_walk() returned 0
path_lookupat: path_init 'usr' flags=50[50] returned 0
mkdir[c74012a0,/kkk] = 0
SIC!
user_path_at_empty lookup usr flags 0x1
path_lookupat: calling path_init 'usr' flags=41
path_init: link_path_walk() returned 0
path_lookupat: path_init 'usr' flags=41[51] returned 0
walk_component: lookup_fast() returned 1
walk_component: lookup_slow() returned 0
walk_component: inode= (null), negative=1
user_path_at_empty lookup usr flags 0x1
path_lookupat: calling path_init 'usr' flags=41
path_init: link_path_walk() returned 0
path_lookupat: path_init 'usr' flags=41[51] returned 0
walk_component: lookup_fast() returned 1
walk_component: lookup_slow() returned 0
walk_component: inode= (null), negative=1
Yep, I get some kkk too.
With that patch:
## panic
[0.544839] walk_component[88001d6edbd8,/dev] - negative
[0.545507] mkdir[88001d6ed1b8,/kkk] = 0
[0.545886] sys_mkdir dev:40755 returned 0
[0.546275] walk_component[88001d6ec288,/dev] - negative
[0.546835] walk_component[88001d6eca20,/dev] - negative
[0.547403] walk_component[88001d6ed950,/dev] - negative
[0.547954] walk_component[88001d6ed440,/dev] - negative
[0.549260] walk_component[88001d6ec510,/dev] - negative
[0.551161] walk_component[88001d6ec798,/dev] - negative
[0.551719] walk_component[88001d6ed6c8,/dev] - negative
[0.552281] walk_component[88001d6eef30,/root] - negative
[0.552866]
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On Thursday, January 22, 2015 04:12:41 AM Al Viro wrote:
On Wed, Jan 21, 2015 at 09:28:51PM -0500, Paul Moore wrote:
Al, do you mind if I fold your patch below into the existing patches?
No problem, but I'd probably prefer to put this series through vfs.git.
With the following as the first step:
I just finished fixing up the patchset and giving it a quick sanity test on my
system, some additional testing is still needed to verify that all the audit
stuff is still okay (I did change the __audit_inode() as discussed and bumped
the refcount in __audit_reusename()) but I think as things stand the boot
panic problems should be resolved - thanks again for your help.
I'm going to (re)post what I've currently got for a patchset and call it a
day. Tomorrow I'll add your below patch and finish up my testing, if all goes
well I'll repost the whole set. If you would prefer it to go via the VFS
tree, that's fine with me, as long as it hits Linus' tree at some point I'm
happy.
Cut down on do_path_lookup() callers
Use filename_lookup() instead. And don't bother with creating new
struct filename when caller already has one.
Signed-off-by: Al Viro v...@zeniv.linux.org.uk
---
diff --git a/fs/namei.c b/fs/namei.c
index bc35b02..73fcf42 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -2046,7 +2046,8 @@ struct dentry *kern_path_locked(const char *name,
struct path *path) {
struct nameidata nd;
struct dentry *d;
- int err = do_path_lookup(AT_FDCWD, name, LOOKUP_PARENT, nd);
+ struct filename filename = {.name = name};
+ int err = filename_lookup(AT_FDCWD, filename, LOOKUP_PARENT, nd);
if (err)
return ERR_PTR(err);
if (nd.last_type != LAST_NORM) {
@@ -3290,7 +3291,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 *filename_create(int dfd, struct filename *name,
struct path *path, unsigned int lookup_flags)
{
struct dentry *dentry = ERR_PTR(-EEXIST);
@@ -3305,7 +3306,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);
@@ -3359,6 +3360,13 @@ 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 = {.name = pathname};
+ return filename_create(dfd, filename, path, lookup_flags);
+}
EXPORT_SYMBOL(kern_path_create);
void done_path_create(struct path *path, struct dentry *dentry)
@@ -3377,7 +3385,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 = filename_create(dfd, tmp, path, lookup_flags);
putname(tmp);
return res;
}
--
paul moore
security @ redhat
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On Wed, Jan 21, 2015 at 09:28:51PM -0500, Paul Moore wrote:
Al, do you mind if I fold your patch below into the existing patches?
No problem, but I'd probably prefer to put this series through vfs.git.
With the following as the first step:
Cut down on do_path_lookup() callers
Use filename_lookup() instead. And don't bother with creating new
struct filename when caller already has one.
Signed-off-by: Al Viro v...@zeniv.linux.org.uk
---
diff --git a/fs/namei.c b/fs/namei.c
index bc35b02..73fcf42 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -2046,7 +2046,8 @@ struct dentry *kern_path_locked(const char *name, struct
path *path)
{
struct nameidata nd;
struct dentry *d;
- int err = do_path_lookup(AT_FDCWD, name, LOOKUP_PARENT, nd);
+ struct filename filename = {.name = name};
+ int err = filename_lookup(AT_FDCWD, filename, LOOKUP_PARENT, nd);
if (err)
return ERR_PTR(err);
if (nd.last_type != LAST_NORM) {
@@ -3290,7 +3291,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 *filename_create(int dfd, struct filename *name,
struct path *path, unsigned int lookup_flags)
{
struct dentry *dentry = ERR_PTR(-EEXIST);
@@ -3305,7 +3306,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);
@@ -3359,6 +3360,13 @@ 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 = {.name = pathname};
+ return filename_create(dfd, filename, path, lookup_flags);
+}
EXPORT_SYMBOL(kern_path_create);
void done_path_create(struct path *path, struct dentry *dentry)
@@ -3377,7 +3385,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 = filename_create(dfd, tmp, path, lookup_flags);
putname(tmp);
return res;
}
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On Wednesday, January 21, 2015 09:28:33 PM Al Viro wrote:
On Wed, Jan 21, 2015 at 01:03:20PM -0800, Guenter Roeck wrote:
failing case:
path_lookupat: calling path_init 'usr' flags=40
path_init: link_path_walk() returned 0
path_lookupat: path_init 'usr' flags=40[50] returned 0
walk_component: lookup_fast() returned 1
walk_component: lookup_slow() returned 0
walk_component: inode= (null), negative=1
do_path_lookup(usr, 0x10)
path_lookupat: calling path_init 'usr' flags=50
path_init: link_path_walk() returned 0
path_lookupat: path_init 'usr' flags=50[50] returned 0
mkdir[c74012a0,/kkk] = 0
SIC!
Cute. 'k' being 0x6b, aka POISON_FREE... OK, the next question is what's
been freed under us - I don't believe that it's dentry itself...
Oh, fuck. OK, I see what happens. Look at kern_path_create(); it does
LOOKUP_PARENT walk, leaving nd-last pointing to the last component of
the *COPY* of the name it's just created, walked and freed.
OK... Fortunately, struct nameidata is completely opaque outside of
fs/namei.c, so we only need to care about a couple of codepaths.
Folks, could you check if the following on top of linux-next fixes the
problem?
Thanks Al, and Guenter, and Sabrina for helping resolve this; it surely would
have taken me much longer alone.
Al, do you mind if I fold your patch below into the existing patches?
diff --git a/fs/namei.c b/fs/namei.c
index 323957f..cda89c3 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -2056,13 +2056,22 @@ static int do_path_lookup(int dfd, const char *name,
/* does lookup, returns the object with parent locked */
struct dentry *kern_path_locked(const char *name, struct path *path)
{
+ struct filename *filename = getname_kernel(name);
struct nameidata nd;
struct dentry *d;
- int err = do_path_lookup(AT_FDCWD, name, LOOKUP_PARENT, nd);
- if (err)
+ int err;
+
+ if (IS_ERR(filename))
+ return ERR_CAST(filename);
+
+ err = filename_lookup(AT_FDCWD, filename, LOOKUP_PARENT, nd);
+ if (err) {
+ putname(filename);
return ERR_PTR(err);
+ }
if (nd.last_type != LAST_NORM) {
path_put(nd.path);
+ putname(filename);
return ERR_PTR(-EINVAL);
}
mutex_lock_nested(nd.path.dentry-d_inode-i_mutex, I_MUTEX_PARENT);
@@ -2070,9 +2079,11 @@ struct dentry *kern_path_locked(const char *name,
struct path *path) if (IS_ERR(d)) {
mutex_unlock(nd.path.dentry-d_inode-i_mutex);
path_put(nd.path);
+ putname(filename);
return d;
}
*path = nd.path;
+ putname(filename);
return d;
}
@@ -3314,7 +3325,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 *filename_create(int dfd, struct filename *name,
struct path *path, unsigned int lookup_flags)
{
struct dentry *dentry = ERR_PTR(-EEXIST);
@@ -3329,7 +3340,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 +3394,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 = filename_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 +3425,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 = filename_create(dfd, tmp, path, lookup_flags);
putname(tmp);
return res;
}
--
paul moore
security @ redhat
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
2015-01-21, 21:28:33 +, Al Viro wrote: On Wed, Jan 21, 2015 at 01:03:20PM -0800, Guenter Roeck wrote: ok case (putname commented out): user_path_at_empty lookup usr flags 0x0 path_lookupat: calling path_init 'usr' flags=40 path_init: link_path_walk() returned 0 path_lookupat: path_init 'usr' flags=40[50] returned 0 walk_component: lookup_fast() returned 1 walk_component: lookup_slow() returned 0 walk_component: inode= (null), negative=1 do_path_lookup(usr, 0x10) path_lookupat: calling path_init 'usr' flags=50 path_init: link_path_walk() returned 0 path_lookupat: path_init 'usr' flags=50[50] returned 0 mkdir[c74012a0,/usr] = 0 user_path_at_empty lookup usr flags 0x1 path_lookupat: calling path_init 'usr' flags=41 path_init: link_path_walk() returned 0 path_lookupat: path_init 'usr' flags=41[51] returned 0 walk_component: inode=c74004a0, negative=0 user_path_at_empty lookup usr flags 0x1 path_lookupat: calling path_init 'usr' flags=41 path_init: link_path_walk() returned 0 path_lookupat: path_init 'usr' flags=41[51] returned 0 failing case: path_lookupat: calling path_init 'usr' flags=40 path_init: link_path_walk() returned 0 path_lookupat: path_init 'usr' flags=40[50] returned 0 walk_component: lookup_fast() returned 1 walk_component: lookup_slow() returned 0 walk_component: inode= (null), negative=1 do_path_lookup(usr, 0x10) path_lookupat: calling path_init 'usr' flags=50 path_init: link_path_walk() returned 0 path_lookupat: path_init 'usr' flags=50[50] returned 0 mkdir[c74012a0,/kkk] = 0 SIC! Cute. 'k' being 0x6b, aka POISON_FREE... OK, the next question is what's been freed under us - I don't believe that it's dentry itself... Oh, fuck. OK, I see what happens. Look at kern_path_create(); it does LOOKUP_PARENT walk, leaving nd-last pointing to the last component of the *COPY* of the name it's just created, walked and freed. OK... Fortunately, struct nameidata is completely opaque outside of fs/namei.c, so we only need to care about a couple of codepaths. Folks, could you check if the following on top of linux-next fixes the problem? Yes, it works. -- Sabrina -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On Wed, 21 Jan 2015, Al Viro wrote:
Folks, could you check if the following on top of linux-next fixes the
problem?
Tested-by: Paul Walmsley p...@pwsan.com # Tegra124 Jetson TK1
diff --git a/fs/namei.c b/fs/namei.c
index 323957f..cda89c3 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -2056,13 +2056,22 @@ static int do_path_lookup(int dfd, const char *name,
/* does lookup, returns the object with parent locked */
struct dentry *kern_path_locked(const char *name, struct path *path)
{
+ struct filename *filename = getname_kernel(name);
struct nameidata nd;
struct dentry *d;
- int err = do_path_lookup(AT_FDCWD, name, LOOKUP_PARENT, nd);
- if (err)
+ int err;
+
+ if (IS_ERR(filename))
+ return ERR_CAST(filename);
+
+ err = filename_lookup(AT_FDCWD, filename, LOOKUP_PARENT, nd);
+ if (err) {
+ putname(filename);
return ERR_PTR(err);
+ }
if (nd.last_type != LAST_NORM) {
path_put(nd.path);
+ putname(filename);
return ERR_PTR(-EINVAL);
}
mutex_lock_nested(nd.path.dentry-d_inode-i_mutex, I_MUTEX_PARENT);
@@ -2070,9 +2079,11 @@ struct dentry *kern_path_locked(const char *name,
struct path *path)
if (IS_ERR(d)) {
mutex_unlock(nd.path.dentry-d_inode-i_mutex);
path_put(nd.path);
+ putname(filename);
return d;
}
*path = nd.path;
+ putname(filename);
return d;
}
@@ -3314,7 +3325,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 *filename_create(int dfd, struct filename *name,
struct path *path, unsigned int lookup_flags)
{
struct dentry *dentry = ERR_PTR(-EEXIST);
@@ -3329,7 +3340,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 +3394,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 = filename_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 +3425,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 = filename_create(dfd, tmp, path, lookup_flags);
putname(tmp);
return res;
}
--
To unsubscribe from this list: send the line unsubscribe linux-next in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
2015-01-21, 04:36:38 +, Al Viro wrote: On Tue, Jan 20, 2015 at 08:01:26PM -0800, Guenter Roeck wrote: With this patch: sys_mkdir .:40775 returned -17 sys_mkdir usr:40775 returned 0 sys_mkdir usr/lib:40775 returned 0 sys_mkdir usr/share:40755 returned 0 sys_mkdir usr/share/udhcpc:40755 returned 0 sys_mkdir usr/bin:40775 returned 0 sys_mkdir usr/sbin:40775 returned 0 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 0 ... and the problem is fixed. This patch also works for me. ... except that it simply confirms that something's fishy with getname_kernel() of -name of struct filename returned by getname(). IOW, I still do not understand the mechanism of breakage there. I'm not so sure about that. I tried to copy name to a new string in do_path_lookup and that didn't help. Now, I've removed the putname(filename); line from do_path_lookup and I don't get the panic. And BTW, I added Guenter's debugging to init/initramfs.c and got: sys_mkdir dev:40755 returned 0 sys_mkdir root:40700 returned 0 even if it ends up panic'ing. -- Sabrina -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On Wednesday, January 21, 2015 04:36:38 AM Al Viro wrote:
Another thing I really do not understand is
+ if (inode-i_ino) {
+ /* valid inode number, use that for the ...
+ if (n-ino != inode-i_ino ||
+ n-dev != inode-i_sb-s_dev)
+ continue;
in __audit_inode(). We don't *have* dentries with dentry-d_inode-i_ino ==
0. Ever. WTF is that about? Paul?
Likely stupidity on my part. It looks like a typo, that first if conditional
should check n-ino instead of inode-i_ino; in __audit_getname() we
record names without any inode numbers, so we need to see if this is one of
those records. Interesting that it passed my testing; either my testing is
crap (always a strong possibility) or something else came to the rescue. I'm
still coming up to speed on the audit/VFS code ...
I'll fix that up and include in the next patchset once we resolve this issue.
--
paul moore
security @ redhat
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On Wed, Jan 21, 2015 at 12:05:39PM +0100, Sabrina Dubroca wrote: 2015-01-21, 04:36:38 +, Al Viro wrote: On Tue, Jan 20, 2015 at 08:01:26PM -0800, Guenter Roeck wrote: With this patch: sys_mkdir .:40775 returned -17 sys_mkdir usr:40775 returned 0 sys_mkdir usr/lib:40775 returned 0 sys_mkdir usr/share:40755 returned 0 sys_mkdir usr/share/udhcpc:40755 returned 0 sys_mkdir usr/bin:40775 returned 0 sys_mkdir usr/sbin:40775 returned 0 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 0 ... and the problem is fixed. This patch also works for me. ... except that it simply confirms that something's fishy with getname_kernel() of -name of struct filename returned by getname(). IOW, I still do not understand the mechanism of breakage there. I'm not so sure about that. I tried to copy name to a new string in do_path_lookup and that didn't help. Now, I've removed the putname(filename); line from do_path_lookup and I don't get the panic. That would indicate that somehow the refcount got unbalanced. Looking more closely it seems like the various audit_*() function do take a reference, but maybe that's not enough. But debugging this further I see no indication that the memory is ever freed, or otherwise corrupted. I did collect a bit more data, perhaps that's useful. I started seeing this issue as well on devices that boot over NFS. After reading this thread I also realized that another warning that I was seeing might be related: [ 28.261930] Warning: unable to open an initial console. I've added a couple of printks and see that the reason for this is that /dev/console doesn't get created. /dev however does get created. [ 11.786627] sys_mkdir dev:40755 returned 0 ... [ 11.978748] sys_mknod dev/console:20600 returned -2 The chain that fails turns out to be this: sys_mknod() sys_mknodat() user_path_create() kern_path_create() do_path_lookup() filename_lookup() path_lookupat() path_init() link_path_walk() walk_component() walk_components() ends up calling lookup_slow() and the result is that inode == NULL and d_is_negative(path-dentry) returns true, therefore causing -ENOENT to be returned. I tried to figure out why inode would be NULL at that point or why d_is_negative() returned true, but I ended up getting completely lost, so I thought it best to report my findings before I confuse everything. Is there anything else I can investigate to track this down? Thierry pgpt9_x3k1AqW.pgp Description: PGP signature
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On 01/21/2015 03:05 AM, Sabrina Dubroca wrote: 2015-01-21, 04:36:38 +, Al Viro wrote: On Tue, Jan 20, 2015 at 08:01:26PM -0800, Guenter Roeck wrote: With this patch: sys_mkdir .:40775 returned -17 sys_mkdir usr:40775 returned 0 sys_mkdir usr/lib:40775 returned 0 sys_mkdir usr/share:40755 returned 0 sys_mkdir usr/share/udhcpc:40755 returned 0 sys_mkdir usr/bin:40775 returned 0 sys_mkdir usr/sbin:40775 returned 0 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 0 ... and the problem is fixed. This patch also works for me. ... except that it simply confirms that something's fishy with getname_kernel() of -name of struct filename returned by getname(). IOW, I still do not understand the mechanism of breakage there. I'm not so sure about that. I tried to copy name to a new string in do_path_lookup and that didn't help. Now, I've removed the putname(filename); line from do_path_lookup and I don't get the panic. And BTW, I added Guenter's debugging to init/initramfs.c and got: sys_mkdir dev:40755 returned 0 sys_mkdir root:40700 returned 0 even if it ends up panic'ing. Another data point (though I have no idea if it is useful or what it means): In the working case, path_init sets nd-flags to 0x50 or 0x51. In the non-working case (ie for all files with a '/' in the name), it sets nd-flags to 0x10 or 0x11, even though it is always called with the LOOKUP_RCU bit set in flags. Guenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On Wednesday, January 21, 2015 03:42:16 PM Thierry Reding wrote:
On Wed, Jan 21, 2015 at 12:05:39PM +0100, Sabrina Dubroca wrote:
2015-01-21, 04:36:38 +, Al Viro wrote:
On Tue, Jan 20, 2015 at 08:01:26PM -0800, Guenter Roeck wrote:
With this patch:
sys_mkdir .:40775 returned -17
sys_mkdir usr:40775 returned 0
sys_mkdir usr/lib:40775 returned 0
sys_mkdir usr/share:40755 returned 0
sys_mkdir usr/share/udhcpc:40755 returned 0
sys_mkdir usr/bin:40775 returned 0
sys_mkdir usr/sbin:40775 returned 0
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 0
...
and the problem is fixed.
This patch also works for me.
... except that it simply confirms that something's fishy with
getname_kernel() of -name of struct filename returned by getname().
IOW, I still do not understand the mechanism of breakage there.
I'm not so sure about that. I tried to copy name to a new string in
do_path_lookup and that didn't help.
Now, I've removed the
putname(filename);
line from do_path_lookup and I don't get the panic.
That would indicate that somehow the refcount got unbalanced. Looking
more closely it seems like the various audit_*() function do take a
reference, but maybe that's not enough.
I'm thinking the same thing and I think the problem may be that
__audit_reusename() is not bumping the filename-refcnt. Can someone who is
seeing this problem bump the refcnt in __audit_reusename()?
struct filename *
__audit_reusename(const __user char *uptr)
{
struct audit_context *context = current-audit_context;
struct audit_names *n;
list_for_each_entry(n, context-names_list, list) {
if (!n-name)
continue;
if (n-name-uptr == uptr) {
+ n-name-refcnt++;
return n-name;
}
}
return NULL;
}
--
paul moore
security @ redhat
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On Tue, Jan 20, 2015 at 08:01:26PM -0800, Guenter Roeck wrote:
> With this patch:
>
> sys_mkdir .:40775 returned -17
> sys_mkdir usr:40775 returned 0
> sys_mkdir usr/lib:40775 returned 0
> sys_mkdir usr/share:40755 returned 0
> sys_mkdir usr/share/udhcpc:40755 returned 0
> sys_mkdir usr/bin:40775 returned 0
> sys_mkdir usr/sbin:40775 returned 0
> 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 0
> ...
>
> and the problem is fixed.
... except that it simply confirms that something's fishy with getname_kernel()
of ->name of struct filename returned by getname(). IOW, I still do not
understand the mechanism of breakage there.
Another thing I really do not understand is
+ if (inode->i_ino) {
+ /* valid inode number, use that for the comparison */
+ if (n->ino != inode->i_ino ||
+ n->dev != inode->i_sb->s_dev)
+ continue;
in __audit_inode(). We don't *have* dentries with dentry->d_inode->i_ino == 0.
Ever. WTF is that about? Paul?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On 01/20/2015 07:36 PM, Al Viro wrote:
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
Artifact from when I created the root file system (which apparently was with
3.9.2). It is irrelevant for my testing, at least so far, so I never
bothered fixing it.
least a plausible direction for digging. Look:
diff --git a/fs/namei.c b/fs/namei.c
index 323957f..c7d107c 100644
--- a/fs/namei.c
+++ b/fs/namei.c
With this patch:
sys_mkdir .:40775 returned -17
sys_mkdir usr:40775 returned 0
sys_mkdir usr/lib:40775 returned 0
sys_mkdir usr/share:40755 returned 0
sys_mkdir usr/share/udhcpc:40755 returned 0
sys_mkdir usr/bin:40775 returned 0
sys_mkdir usr/sbin:40775 returned 0
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 0
...
and the problem is fixed.
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
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, );
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, );
+ error = filename_lookup(dfd, name, LOOKUP_PARENT|lookup_flags, );
if (error)
return ERR_PTR(error);
@@ -3383,6 +3383,19 @@ out:
path_put();
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;
}
--
To unsubscribe from this
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On 01/20/2015 04:41 PM, Al Viro 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.
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On Tue, Jan 20, 2015 at 07:14:46PM -0500, Paul Moore wrote:
> > > with the patch applied (+panic)
> > >
> > >
> > > and:
> > >
> > > stat("/dev/root") -> 0
> > > stat("dev") -> 0
> > > with the old version of do_path_lookup.
> >
> > Wait a minute ... at this early stage of boot, I'm pretty sure we don't have
> > a valid current->audit_context since we haven't fork'd anything. If the
> > audit context was non-NULL garbage that might explain the panic ...
Not really - the panic is predicatable result of not finding /dev/root (hell,
not even /dev there!) in mount_block_root().
> Could you try initializing the init_task's audit_context to NULL in the
> INIT_TASK macro in include/linux/init_task.h?
Missing fields in struct initializer are treated as zeroes.
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?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On Tuesday, January 20, 2015 07:04:54 PM Paul Moore wrote:
> On Wednesday, January 21, 2015 12:27:26 AM Sabrina Dubroca wrote:
> > 2015-01-20, 23:17:25 +, Al Viro wrote:
> > > On Tue, Jan 20, 2015 at 10:50:41PM +, Al Viro wrote:
> > > > doesn't look at _anything_ other than name->name other than for
> > > > audit_inode(). And name->name is apparently the same.
> > > >
> > > > It looks like something ends up buggering name->name in process, but
> > > > then
> > > > the damn thing appears to be normal after return from
> > > > filename_lookup()...
> > >
> > > If my reconstruction of what's going on is correct, the call chain here
> > > is do_path_lookup() <- kern_path() <- lookup_bdev() <-
> > > blkdev_get_by_path()
> > > <- mount_bdev() <- some_type.mount() <- mount_fs()
> > > <- vfs_kern_mount() <- do_new_mount() <- do_mount() <- sys_mount()
> > > <- do_mount_root() <- mount_block_root() <- mount_root(). Which is
> > > obscenely long, BTW, but that's a separate story...
> > >
> > > Could you slap
> > >
> > > struct stat buf;
> > > int n = sys_newstat(name, );
> > > printk(KERN_ERR "stat(\"%s\") -> %d\n", name, n);
> > > n = sys_newstat("/dev", );
> > > printk(KERN_ERR "stat(\"dev\") -> %d\n", n);
> > >
> > > in the beginning of mount_block_root() (init/do_mounts.c) and see what
> > > it
> > > prints?
> >
> > I get
> >
> > stat("/dev/root") -> -2
> > stat("dev") -> -2
> > with the patch applied (+panic)
> >
> >
> > and:
> >
> > stat("/dev/root") -> 0
> > stat("dev") -> 0
> > with the old version of do_path_lookup.
>
> Wait a minute ... at this early stage of boot, I'm pretty sure we don't have
> a valid current->audit_context since we haven't fork'd anything. If the
> audit context was non-NULL garbage that might explain the panic ...
Could you try initializing the init_task's audit_context to NULL in the
INIT_TASK macro in include/linux/init_task.h?
Example:
#define INIT_TASK(tsk)
{
.state = 0,
.stack = _thread_info,
...
.audit_context = NULL,
...
}
--
paul moore
security @ redhat
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On Wednesday, January 21, 2015 12:27:26 AM Sabrina Dubroca wrote:
> 2015-01-20, 23:17:25 +, Al Viro wrote:
> > On Tue, Jan 20, 2015 at 10:50:41PM +, Al Viro wrote:
> > > doesn't look at _anything_ other than name->name other than for
> > > audit_inode(). And name->name is apparently the same.
> > >
> > > It looks like something ends up buggering name->name in process, but
> > > then
> > > the damn thing appears to be normal after return from
> > > filename_lookup()...
> >
> > If my reconstruction of what's going on is correct, the call chain here
> > is do_path_lookup() <- kern_path() <- lookup_bdev() <-
> > blkdev_get_by_path()
> > <- mount_bdev() <- some_type.mount() <- mount_fs()
> > <- vfs_kern_mount() <- do_new_mount() <- do_mount() <- sys_mount()
> > <- do_mount_root() <- mount_block_root() <- mount_root(). Which is
> > obscenely long, BTW, but that's a separate story...
> >
> > Could you slap
> >
> > struct stat buf;
> > int n = sys_newstat(name, );
> > printk(KERN_ERR "stat(\"%s\") -> %d\n", name, n);
> > n = sys_newstat("/dev", );
> > printk(KERN_ERR "stat(\"dev\") -> %d\n", n);
> >
> > in the beginning of mount_block_root() (init/do_mounts.c) and see what it
> > prints?
>
> I get
>
> stat("/dev/root") -> -2
> stat("dev") -> -2
> with the patch applied (+panic)
>
>
> and:
>
> stat("/dev/root") -> 0
> stat("dev") -> 0
> with the old version of do_path_lookup.
Wait a minute ... at this early stage of boot, I'm pretty sure we don't have a
valid current->audit_context since we haven't fork'd anything. If the audit
context was non-NULL garbage that might explain the panic ...
--
paul moore
security @ redhat
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
2015-01-20, 23:17:25 +, Al Viro wrote:
> On Tue, Jan 20, 2015 at 10:50:41PM +, Al Viro wrote:
> > doesn't look at _anything_ other than name->name other than for
> > audit_inode().
> > And name->name is apparently the same.
> >
> > It looks like something ends up buggering name->name in process, but then
> > the damn thing appears to be normal after return from filename_lookup()...
>
> If my reconstruction of what's going on is correct, the call chain here
> is do_path_lookup() <- kern_path() <- lookup_bdev() <- blkdev_get_by_path()
> <- mount_bdev() <- some_type.mount() <- mount_fs()
> <- vfs_kern_mount() <- do_new_mount() <- do_mount() <- sys_mount()
> <- do_mount_root() <- mount_block_root() <- mount_root(). Which is
> obscenely long, BTW, but that's a separate story...
>
> Could you slap
> struct stat buf;
> int n = sys_newstat(name, );
> printk(KERN_ERR "stat(\"%s\") -> %d\n", name, n);
> n = sys_newstat("/dev", );
> printk(KERN_ERR "stat(\"dev\") -> %d\n", n);
>
> in the beginning of mount_block_root() (init/do_mounts.c) and see what it
> prints?
I get
stat("/dev/root") -> -2
stat("dev") -> -2
with the patch applied (+panic)
and:
stat("/dev/root") -> 0
stat("dev") -> 0
with the old version of do_path_lookup.
--
Sabrina
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On Tue, Jan 20, 2015 at 10:50:41PM +, Al Viro wrote:
> doesn't look at _anything_ other than name->name other than for audit_inode().
> And name->name is apparently the same.
>
> It looks like something ends up buggering name->name in process, but then
> the damn thing appears to be normal after return from filename_lookup()...
If my reconstruction of what's going on is correct, the call chain here
is do_path_lookup() <- kern_path() <- lookup_bdev() <- blkdev_get_by_path()
<- mount_bdev() <- some_type.mount() <- mount_fs()
<- vfs_kern_mount() <- do_new_mount() <- do_mount() <- sys_mount()
<- do_mount_root() <- mount_block_root() <- mount_root(). Which is
obscenely long, BTW, but that's a separate story...
Could you slap
struct stat buf;
int n = sys_newstat(name, );
printk(KERN_ERR "stat(\"%s\") -> %d\n", name, n);
n = sys_newstat("/dev", );
printk(KERN_ERR "stat(\"dev\") -> %d\n", n);
in the beginning of mount_block_root() (init/do_mounts.c) and see what it
prints?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On Tue, Jan 20, 2015 at 02:13:09PM -0800, Guenter Roeck wrote:
> > > Nuts... Is reverting just this (do_path_lookup()) part of commit
> > > sufficient
> > > to recover the normal behaviour?
> >
> > Yes.
> >
> Same on microblaze.
This is completely insane.
static int filename_lookup(int dfd, struct filename *name,
unsigned int flags, struct nameidata *nd)
{
int retval = path_lookupat(dfd, name->name, flags | LOOKUP_RCU, nd);
if (unlikely(retval == -ECHILD))
retval = path_lookupat(dfd, name->name, flags, nd);
if (unlikely(retval == -ESTALE))
retval = path_lookupat(dfd, name->name,
flags | LOOKUP_REVAL, nd);
if (likely(!retval))
audit_inode(name, nd->path.dentry, flags & LOOKUP_PARENT);
return retval;
}
doesn't look at _anything_ other than name->name other than for audit_inode().
And name->name is apparently the same.
It looks like something ends up buggering name->name in process, but then
the damn thing appears to be normal after return from filename_lookup()...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On Tue, Jan 20, 2015 at 11:08:23PM +0100, Sabrina Dubroca wrote: > 2015-01-20, 21:58:31 +, Al Viro wrote: > > On Tue, Jan 20, 2015 at 10:38:58PM +0100, Sabrina Dubroca wrote: > > > > > [1.538646] fn_lookup bsg/0:0:0:0 -2, 88001f718000 bsg/0:0:0:0 > > > [1.539704] fn_lookup bsg 0, 88001f718000 bsg > > > [1.540559] fn_lookup bsg/0:0:0:0 -2, 88001f718000 bsg/0:0:0:0 > > > [1.552611] fn_lookup bsg/1:0:0:0 -2, 88001f718000 bsg/1:0:0:0 > > > [1.553689] fn_lookup bsg 0, 88001f718000 bsg > > > [1.554505] fn_lookup bsg/1:0:0:0 -2, 88001f718000 bsg/1:0:0:0 > > > [1.557554] fn_lookup sda 0, 88001f718000 sda > > > [1.558368] fn_lookup sda 0, 88001f718000 sda > > > [1.564190] fn_lookup sda1 0, 88001f718000 sda1 > > > [1.565008] fn_lookup sda1 0, 88001f718000 sda1 > > > [1.570751] fn_lookup /dev/ram -2, 88001f71a300 /dev/ram > > > [1.571786] fn_lookup /dev/root -2, 88001f71b480 /dev/root > > > > Nuts... Is reverting just this (do_path_lookup()) part of commit sufficient > > to recover the normal behaviour? > > Yes. > Same on microblaze. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
2015-01-20, 21:58:31 +, Al Viro wrote: > On Tue, Jan 20, 2015 at 10:38:58PM +0100, Sabrina Dubroca wrote: > > > [1.538646] fn_lookup bsg/0:0:0:0 -2, 88001f718000 bsg/0:0:0:0 > > [1.539704] fn_lookup bsg 0, 88001f718000 bsg > > [1.540559] fn_lookup bsg/0:0:0:0 -2, 88001f718000 bsg/0:0:0:0 > > [1.552611] fn_lookup bsg/1:0:0:0 -2, 88001f718000 bsg/1:0:0:0 > > [1.553689] fn_lookup bsg 0, 88001f718000 bsg > > [1.554505] fn_lookup bsg/1:0:0:0 -2, 88001f718000 bsg/1:0:0:0 > > [1.557554] fn_lookup sda 0, 88001f718000 sda > > [1.558368] fn_lookup sda 0, 88001f718000 sda > > [1.564190] fn_lookup sda1 0, 88001f718000 sda1 > > [1.565008] fn_lookup sda1 0, 88001f718000 sda1 > > [1.570751] fn_lookup /dev/ram -2, 88001f71a300 /dev/ram > > [1.571786] fn_lookup /dev/root -2, 88001f71b480 /dev/root > > Nuts... Is reverting just this (do_path_lookup()) part of commit sufficient > to recover the normal behaviour? Yes. -- Sabrina -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On Tue, Jan 20, 2015 at 10:38:58PM +0100, Sabrina Dubroca wrote: > [1.538646] fn_lookup bsg/0:0:0:0 -2, 88001f718000 bsg/0:0:0:0 > [1.539704] fn_lookup bsg 0, 88001f718000 bsg > [1.540559] fn_lookup bsg/0:0:0:0 -2, 88001f718000 bsg/0:0:0:0 > [1.552611] fn_lookup bsg/1:0:0:0 -2, 88001f718000 bsg/1:0:0:0 > [1.553689] fn_lookup bsg 0, 88001f718000 bsg > [1.554505] fn_lookup bsg/1:0:0:0 -2, 88001f718000 bsg/1:0:0:0 > [1.557554] fn_lookup sda 0, 88001f718000 sda > [1.558368] fn_lookup sda 0, 88001f718000 sda > [1.564190] fn_lookup sda1 0, 88001f718000 sda1 > [1.565008] fn_lookup sda1 0, 88001f718000 sda1 > [1.570751] fn_lookup /dev/ram -2, 88001f71a300 /dev/ram > [1.571786] fn_lookup /dev/root -2, 88001f71b480 /dev/root Nuts... Is reverting just this (do_path_lookup()) part of commit sufficient to recover the normal behaviour? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On Tue, Jan 20, 2015 at 09:02:03PM +, Al Viro wrote: > On Tue, Jan 20, 2015 at 09:45:04PM +0100, Sabrina Dubroca wrote: > > > printk(KERN_ERR "fn_lookup %s %d\n", name, retval); > > > > and I get: > > > > [1.618558] fn_lookup bsg/0:0:0:0 -2 > > [1.619437] fn_lookup bsg 0 > > [1.620236] fn_lookup bsg/0:0:0:0 -2 > > [1.625996] fn_lookup sda 0 > > [1.626609] fn_lookup sda 0 > > [1.639007] fn_lookup sda1 0 > > [1.639691] fn_lookup sda1 0 > > [1.643656] fn_lookup bsg/1:0:0:0 -2 > > [1.644974] fn_lookup bsg 0 > > [1.645928] fn_lookup bsg/1:0:0:0 -2 > > [1.649483] fn_lookup /dev/ram -2 > > [1.650424] fn_lookup /dev/root -2 > > [1.651234] VFS: Cannot open root device "sda1" or unknown-block(8,1): > > error -2 > > That -2 is -ENOENT... Wait a sec, what's in filename, filename->name and > what do you get from your printk on kernel with that commit reverted? On microblaze target: patch reverted: name . rv 0 name usr rv 0 name usr/lib rv 0 name usr/share rv 0 name usr/share/udhcpc rv 0 name usr/bin rv 0 name usr/bin/logger rv 0 ... broken: filename c78a4000 filename->name c78a4014:. name . rv 0 filename c78a4000 filename->name c78a4014:usr name usr rv 0 filename c78a4000 filename->name c78a4014:usr/lib name usr/lib rv -2 filename c78a4000 filename->name c78a4014:usr/share name usr/share rv -2 filename c78a4000 filename->name c78a4014:usr/share/udhcpc name usr/share/udhcpc rv -2 filename c78a4000 filename->name c78a4014:usr/bin name usr/bin rv -2 filename c78ae000 filename->name c78ae014:usr/bin/logger name usr/bin/logger rv -2 ... Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
2015-01-20, 21:02:03 +, Al Viro wrote: > On Tue, Jan 20, 2015 at 09:45:04PM +0100, Sabrina Dubroca wrote: > > > printk(KERN_ERR "fn_lookup %s %d\n", name, retval); > > > > and I get: > > > > [1.618558] fn_lookup bsg/0:0:0:0 -2 > > [1.619437] fn_lookup bsg 0 > > [1.620236] fn_lookup bsg/0:0:0:0 -2 > > [1.625996] fn_lookup sda 0 > > [1.626609] fn_lookup sda 0 > > [1.639007] fn_lookup sda1 0 > > [1.639691] fn_lookup sda1 0 > > [1.643656] fn_lookup bsg/1:0:0:0 -2 > > [1.644974] fn_lookup bsg 0 > > [1.645928] fn_lookup bsg/1:0:0:0 -2 > > [1.649483] fn_lookup /dev/ram -2 > > [1.650424] fn_lookup /dev/root -2 > > [1.651234] VFS: Cannot open root device "sda1" or unknown-block(8,1): > > error -2 > > That -2 is -ENOENT... Wait a sec, what's in filename, filename->name and > what do you get from your printk on kernel with that commit reverted? filename->name matches name. with printk(KERN_ERR "fn_lookup %s %d, %p %s\n", name, retval, filename, filename->name); [1.538646] fn_lookup bsg/0:0:0:0 -2, 88001f718000 bsg/0:0:0:0 [1.539704] fn_lookup bsg 0, 88001f718000 bsg [1.540559] fn_lookup bsg/0:0:0:0 -2, 88001f718000 bsg/0:0:0:0 [1.552611] fn_lookup bsg/1:0:0:0 -2, 88001f718000 bsg/1:0:0:0 [1.553689] fn_lookup bsg 0, 88001f718000 bsg [1.554505] fn_lookup bsg/1:0:0:0 -2, 88001f718000 bsg/1:0:0:0 [1.557554] fn_lookup sda 0, 88001f718000 sda [1.558368] fn_lookup sda 0, 88001f718000 sda [1.564190] fn_lookup sda1 0, 88001f718000 sda1 [1.565008] fn_lookup sda1 0, 88001f718000 sda1 [1.570751] fn_lookup /dev/ram -2, 88001f71a300 /dev/ram [1.571786] fn_lookup /dev/root -2, 88001f71b480 /dev/root and with printk(KERN_ERR "fn_lookup %s %d, %s\n", name, retval, filename.name); in the original do_path_lookup: [1.426101] fn_lookup bsg/0:0:0:0 -2, bsg/0:0:0:0 [1.426893] fn_lookup bsg 0, bsg [1.427406] fn_lookup bsg/0:0:0:0 0, bsg/0:0:0:0 [1.431530] fn_lookup sda 0, sda [1.438346] fn_lookup bsg/1:0:0:0 0, bsg/1:0:0:0 [1.443658] fn_lookup sda1 0, sda1 [1.448344] fn_lookup /dev/ram 0, /dev/ram [1.449148] fn_lookup /dev/root 0, /dev/root [1.449835] fn_lookup /dev/root 0, /dev/root [1.451586] EXT4-fs (sda1): couldn't mount as ext3 due to feature incompatibilities [1.452954] fn_lookup /dev/root 0, /dev/root [1.454292] EXT4-fs (sda1): couldn't mount as ext2 due to feature incompatibilities [1.456331] fn_lookup /dev/root 0, /dev/root [1.480208] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) [1.481323] VFS: Mounted root (ext4 filesystem) readonly on device 8:1. -- Sabrina -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On Tue, Jan 20, 2015 at 09:45:04PM +0100, Sabrina Dubroca wrote: > printk(KERN_ERR "fn_lookup %s %d\n", name, retval); > > and I get: > > [1.618558] fn_lookup bsg/0:0:0:0 -2 > [1.619437] fn_lookup bsg 0 > [1.620236] fn_lookup bsg/0:0:0:0 -2 > [1.625996] fn_lookup sda 0 > [1.626609] fn_lookup sda 0 > [1.639007] fn_lookup sda1 0 > [1.639691] fn_lookup sda1 0 > [1.643656] fn_lookup bsg/1:0:0:0 -2 > [1.644974] fn_lookup bsg 0 > [1.645928] fn_lookup bsg/1:0:0:0 -2 > [1.649483] fn_lookup /dev/ram -2 > [1.650424] fn_lookup /dev/root -2 > [1.651234] VFS: Cannot open root device "sda1" or unknown-block(8,1): > error -2 That -2 is -ENOENT... Wait a sec, what's in filename, filename->name and what do you get from your printk on kernel with that commit reverted? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
2015-01-20, 19:54:32 +, Al Viro wrote:
> On Tue, Jan 20, 2015 at 06:51:35PM +0100, Sabrina Dubroca wrote:
> > 2015-01-20, 12:39:08 -0500, Paul Moore wrote:
> > > On Tuesday, January 20, 2015 05:56:55 PM Sabrina Dubroca wrote:
> > > > Hello,
> > > >
> > > > Today's linux-next doesn't boot on my qemu VM:
> > >
> > > ...
> > >
> > > > I bisected it down to:
> > > >
> > > > 5dc5218840e1 fs: create proper filename objects using getname_kernel()
> > > >
> > > > I reverted then reapplied each part of that patch. It works if I
> > > > leave out the hunk for do_path_lookup:
> > > >
> > > > diff --git a/fs/namei.c b/fs/namei.c
> > > > index eeb3b83661f8..c3d21b79090e 100644
> > > > --- a/fs/namei.c
> > > > +++ b/fs/namei.c
> > > > @@ -2001,9 +2001,15 @@ static int filename_lookup(int dfd, struct
> > > > filename
> > > > *name, static int do_path_lookup(int dfd, const char *name,
> > > > unsigned int flags, struct nameidata
> > > > *nd)
> > > > {
> > > > - struct filename filename = { .name = name };
> > > > + int retval;
> > > > + struct filename *filename;
> > > >
> > > > - return filename_lookup(dfd, , flags, nd);
> > > > + filename = getname_kernel(name);
> > > > + if (unlikely(IS_ERR(filename)))
> > > > + return PTR_ERR(filename);
> > > > + retval = filename_lookup(dfd, filename, flags, nd);
> > > > + putname(filename);
> > > > + return retval;
> > > > }
> > > >
> > > > I don't know what other info you may need.
> > > > Full dmesg for the failed boot included below.
> > >
> > > Thanks for testing this and reporting the problem, especially such a
> > > small
> > > bisection. Unfortunately nothing is immediately obvious to me, would you
> > > mind
> > > sharing your kernel config so I can try to reproduce and debug the
> > > problem?
> >
> > Sure.
> >
> > I run qemu with:
> >
> > qemu-system-x86_64 -enable-kvm -cpu host -m 512 -kernel bzImage -append
> > 'root=/dev/sda1' $IMG
> >
> > and the image contains a single ext4 partition with a basic ArchLinux
> > install.
>
> Could you turn that return PTR_ERR(filename); into
> {
> printk(KERN_ERR "failed(%p -> %d)", name, PTR_ERR(filename));
> return PTR_ERR(filename);
> }
> reproduce the panic and see what has it produced?
Nothing.
Not sure if it helps, but I added after filename_lookup:
printk(KERN_ERR "fn_lookup %s %d\n", name, retval);
and I get:
[1.618558] fn_lookup bsg/0:0:0:0 -2
[1.619437] fn_lookup bsg 0
[1.620236] fn_lookup bsg/0:0:0:0 -2
[1.625996] fn_lookup sda 0
[1.626609] fn_lookup sda 0
[1.639007] fn_lookup sda1 0
[1.639691] fn_lookup sda1 0
[1.643656] fn_lookup bsg/1:0:0:0 -2
[1.644974] fn_lookup bsg 0
[1.645928] fn_lookup bsg/1:0:0:0 -2
[1.649483] fn_lookup /dev/ram -2
[1.650424] fn_lookup /dev/root -2
[1.651234] VFS: Cannot open root device "sda1" or unknown-block(8,1): error
-2
--
Sabrina
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On Tuesday, January 20, 2015 05:43:01 PM Fabio Estevam wrote: > On Tue, Jan 20, 2015 at 5:24 PM, Paul Moore wrote: > > On Tuesday, January 20, 2015 05:16:45 PM Fabio Estevam wrote: > >> On Tue, Jan 20, 2015 at 5:00 PM, Ross Zwisler > >> > >> wrote: > >> > These were just nuisance warnings, I believe, so my guess is that this > >> > isn't related to your kernel panic. Reverting Boaz's patches to make > >> > these warnings go away would let you know for sure. > >> > >> You are right. Reverting 937af5ecd0591e makes such warnings disappear. > > > > You guys are much quicker compiling kernels than I am :) > > > > Fabio, are you still seeing the same panic, just without the warnings? Or > > has the panic resolved itself as well? > > Just to clarify: I was not getting the same panic Sabrina originally > reported. > > Reverting 937af5ecd0591e made the ram warnings go away. > > On my case I am running linux-next 20150120 plus this fix: > http://www.spinics.net/lists/arm-kernel/msg393205.html > > and things seem to boot fine here on my ARM platform. Okay, thanks for the clarification; glad you got it working. -- paul moore security @ redhat -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On Tue, Jan 20, 2015 at 06:51:35PM +0100, Sabrina Dubroca wrote:
> 2015-01-20, 12:39:08 -0500, Paul Moore wrote:
> > On Tuesday, January 20, 2015 05:56:55 PM Sabrina Dubroca wrote:
> > > Hello,
> > >
> > > Today's linux-next doesn't boot on my qemu VM:
> >
> > ...
> >
> > > I bisected it down to:
> > >
> > > 5dc5218840e1 fs: create proper filename objects using getname_kernel()
> > >
> > > I reverted then reapplied each part of that patch. It works if I
> > > leave out the hunk for do_path_lookup:
> > >
> > > diff --git a/fs/namei.c b/fs/namei.c
> > > index eeb3b83661f8..c3d21b79090e 100644
> > > --- a/fs/namei.c
> > > +++ b/fs/namei.c
> > > @@ -2001,9 +2001,15 @@ static int filename_lookup(int dfd, struct filename
> > > *name, static int do_path_lookup(int dfd, const char *name,
> > > unsigned int flags, struct nameidata *nd)
> > > {
> > > - struct filename filename = { .name = name };
> > > + int retval;
> > > + struct filename *filename;
> > >
> > > - return filename_lookup(dfd, , flags, nd);
> > > + filename = getname_kernel(name);
> > > + if (unlikely(IS_ERR(filename)))
> > > + return PTR_ERR(filename);
> > > + retval = filename_lookup(dfd, filename, flags, nd);
> > > + putname(filename);
> > > + return retval;
> > > }
> > >
> > > I don't know what other info you may need.
> > > Full dmesg for the failed boot included below.
> >
> > Thanks for testing this and reporting the problem, especially such a small
> > bisection. Unfortunately nothing is immediately obvious to me, would you
> > mind
> > sharing your kernel config so I can try to reproduce and debug the problem?
>
> Sure.
>
> I run qemu with:
>
> qemu-system-x86_64 -enable-kvm -cpu host -m 512 -kernel bzImage -append
> 'root=/dev/sda1' $IMG
>
> and the image contains a single ext4 partition with a basic ArchLinux install.
Could you turn that return PTR_ERR(filename); into
{
printk(KERN_ERR "failed(%p -> %d)", name, PTR_ERR(filename));
return PTR_ERR(filename);
}
reproduce the panic and see what has it produced?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On Tue, Jan 20, 2015 at 5:24 PM, Paul Moore wrote: > On Tuesday, January 20, 2015 05:16:45 PM Fabio Estevam wrote: >> On Tue, Jan 20, 2015 at 5:00 PM, Ross Zwisler >> >> wrote: >> > These were just nuisance warnings, I believe, so my guess is that this >> > isn't related to your kernel panic. Reverting Boaz's patches to make >> > these warnings go away would let you know for sure. >> >> You are right. Reverting 937af5ecd0591e makes such warnings disappear. > > You guys are much quicker compiling kernels than I am :) > > Fabio, are you still seeing the same panic, just without the warnings? Or has > the panic resolved itself as well? Just to clarify: I was not getting the same panic Sabrina originally reported. Reverting 937af5ecd0591e made the ram warnings go away. On my case I am running linux-next 20150120 plus this fix: http://www.spinics.net/lists/arm-kernel/msg393205.html and things seem to boot fine here on my ARM platform. Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On Tuesday, January 20, 2015 05:16:45 PM Fabio Estevam wrote: > On Tue, Jan 20, 2015 at 5:00 PM, Ross Zwisler > > wrote: > > These were just nuisance warnings, I believe, so my guess is that this > > isn't related to your kernel panic. Reverting Boaz's patches to make > > these warnings go away would let you know for sure. > > You are right. Reverting 937af5ecd0591e makes such warnings disappear. You guys are much quicker compiling kernels than I am :) Fabio, are you still seeing the same panic, just without the warnings? Or has the panic resolved itself as well? -- paul moore security @ redhat -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On Tue, Jan 20, 2015 at 5:00 PM, Ross Zwisler wrote: > These were just nuisance warnings, I believe, so my guess is that this > isn't related to your kernel panic. Reverting Boaz's patches to make > these warnings go away would let you know for sure. You are right. Reverting 937af5ecd0591e makes such warnings disappear. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On Tue, 2015-01-20 at 15:54 -0200, Fabio Estevam wrote: > On Tue, Jan 20, 2015 at 3:39 PM, Paul Moore wrote: > > > Thanks for testing this and reporting the problem, especially such a small > > bisection. Unfortunately nothing is immediately obvious to me, would you > > mind > > sharing your kernel config so I can try to reproduce and debug the problem? > > In case it helps, I also get the similar errors on a mx6 which is > built with arch/arm/configs/imx_v6_v7_defconfig: > > [1.594196] imx-ipuv3 280.ipu: IPUv3H probed > [1.601836] ram0: unknown partition table > [1.607247] ram1: unknown partition table > [1.612617] ram2: unknown partition table > [1.618010] ram3: unknown partition table > [1.623359] ram4: unknown partition table > [1.628761] ram5: unknown partition table > [1.634065] ram6: unknown partition table > [1.639436] ram7: unknown partition table > [1.644749] ram8: unknown partition table > [1.650132] ram9: unknown partition table > [1.655447] ram10: unknown partition table > [1.660911] ram11: unknown partition table > [1.666268] ram12: unknown partition table > [1.671778] ram13: unknown partition table > [1.677154] ram14: unknown partition table > [1.682593] ram15: unknown partition table > [1.687165] brd: module loaded > [1.705148] loop: module loaded This is probably related to the issue reported in this thread: https://lkml.org/lkml/2015/1/16/563 These were just nuisance warnings, I believe, so my guess is that this isn't related to your kernel panic. Reverting Boaz's patches to make these warnings go away would let you know for sure. - Ross -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On Tue, Jan 20, 2015 at 3:39 PM, Paul Moore wrote: > Thanks for testing this and reporting the problem, especially such a small > bisection. Unfortunately nothing is immediately obvious to me, would you mind > sharing your kernel config so I can try to reproduce and debug the problem? In case it helps, I also get the similar errors on a mx6 which is built with arch/arm/configs/imx_v6_v7_defconfig: [1.594196] imx-ipuv3 280.ipu: IPUv3H probed [1.601836] ram0: unknown partition table [1.607247] ram1: unknown partition table [1.612617] ram2: unknown partition table [1.618010] ram3: unknown partition table [1.623359] ram4: unknown partition table [1.628761] ram5: unknown partition table [1.634065] ram6: unknown partition table [1.639436] ram7: unknown partition table [1.644749] ram8: unknown partition table [1.650132] ram9: unknown partition table [1.655447] ram10: unknown partition table [1.660911] ram11: unknown partition table [1.666268] ram12: unknown partition table [1.671778] ram13: unknown partition table [1.677154] ram14: unknown partition table [1.682593] ram15: unknown partition table [1.687165] brd: module loaded [1.705148] loop: module loaded -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
2015-01-20, 12:39:08 -0500, Paul Moore wrote:
> On Tuesday, January 20, 2015 05:56:55 PM Sabrina Dubroca wrote:
> > Hello,
> >
> > Today's linux-next doesn't boot on my qemu VM:
>
> ...
>
> > I bisected it down to:
> >
> > 5dc5218840e1 fs: create proper filename objects using getname_kernel()
> >
> > I reverted then reapplied each part of that patch. It works if I
> > leave out the hunk for do_path_lookup:
> >
> > diff --git a/fs/namei.c b/fs/namei.c
> > index eeb3b83661f8..c3d21b79090e 100644
> > --- a/fs/namei.c
> > +++ b/fs/namei.c
> > @@ -2001,9 +2001,15 @@ static int filename_lookup(int dfd, struct filename
> > *name, static int do_path_lookup(int dfd, const char *name,
> > unsigned int flags, struct nameidata *nd)
> > {
> > - struct filename filename = { .name = name };
> > + int retval;
> > + struct filename *filename;
> >
> > - return filename_lookup(dfd, , flags, nd);
> > + filename = getname_kernel(name);
> > + if (unlikely(IS_ERR(filename)))
> > + return PTR_ERR(filename);
> > + retval = filename_lookup(dfd, filename, flags, nd);
> > + putname(filename);
> > + return retval;
> > }
> >
> > I don't know what other info you may need.
> > Full dmesg for the failed boot included below.
>
> Thanks for testing this and reporting the problem, especially such a small
> bisection. Unfortunately nothing is immediately obvious to me, would you
> mind
> sharing your kernel config so I can try to reproduce and debug the problem?
Sure.
I run qemu with:
qemu-system-x86_64 -enable-kvm -cpu host -m 512 -kernel bzImage -append
'root=/dev/sda1' $IMG
and the image contains a single ext4 partition with a basic ArchLinux install.
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86 3.19.0-rc5 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_PERF_EVENTS_INTEL_UNCORE=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_HAVE_INTEL_TXT=y
CONFIG_X86_64_SMP=y
CONFIG_X86_HT=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx
-fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10
-fcall-saved-r11"
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="earth"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_FHANDLE=y
CONFIG_USELIB=y
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_WATCH=y
CONFIG_AUDIT_TREE=y
#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_LEGACY_ALLOC_HWIRQ=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_IRQ_DOMAIN=y
CONFIG_GENERIC_MSI_IRQ=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y
#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
# CONFIG_NO_HZ_FULL is not set
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set
# CONFIG_IRQ_TIME_ACCOUNTING is not set
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On Tuesday, January 20, 2015 05:56:55 PM Sabrina Dubroca wrote:
> Hello,
>
> Today's linux-next doesn't boot on my qemu VM:
...
> I bisected it down to:
>
> 5dc5218840e1 fs: create proper filename objects using getname_kernel()
>
> I reverted then reapplied each part of that patch. It works if I
> leave out the hunk for do_path_lookup:
>
> diff --git a/fs/namei.c b/fs/namei.c
> index eeb3b83661f8..c3d21b79090e 100644
> --- a/fs/namei.c
> +++ b/fs/namei.c
> @@ -2001,9 +2001,15 @@ static int filename_lookup(int dfd, struct filename
> *name, static int do_path_lookup(int dfd, const char *name,
> unsigned int flags, struct nameidata *nd)
> {
> - struct filename filename = { .name = name };
> + int retval;
> + struct filename *filename;
>
> - return filename_lookup(dfd, , flags, nd);
> + filename = getname_kernel(name);
> + if (unlikely(IS_ERR(filename)))
> + return PTR_ERR(filename);
> + retval = filename_lookup(dfd, filename, flags, nd);
> + putname(filename);
> + return retval;
> }
>
> I don't know what other info you may need.
> Full dmesg for the failed boot included below.
Thanks for testing this and reporting the problem, especially such a small
bisection. Unfortunately nothing is immediately obvious to me, would you mind
sharing your kernel config so I can try to reproduce and debug the problem?
-Paul
--
paul moore
security @ redhat
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
Hello,
Today's linux-next doesn't boot on my qemu VM:
[1.248357] scsi 0:0:0:0: Direct-Access ATA QEMU HARDDISK0
PQ: 0 ANSI: 5
[1.255899] sd 0:0:0:0: [sda] 8388608 512-byte logical blocks: (4.29 GB/4.00
GiB)
[1.258333] sd 0:0:0:0: [sda] Write Protect is off
[1.259475] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled,
doesn't support DPO or FUA
[1.268417] scsi 1:0:0:0: CD-ROMQEMU QEMU DVD-ROM 2.2.
PQ: 0 ANSI: 5
[1.271673] sda: sda1
[1.281061] sd 0:0:0:0: [sda] Attached SCSI disk
[1.282320] VFS: Cannot open root device "sda1" or unknown-block(8,1): error
-2
[1.283484] Please append a correct "root=" boot option; here are the
available partitions:
[1.284748] 01004096 ram0 (driver?)
[1.285479] 01014096 ram1 (driver?)
[1.286218] 01024096 ram2 (driver?)
[1.286992] 01034096 ram3 (driver?)
[1.287741] 01044096 ram4 (driver?)
[1.288640] 01054096 ram5 (driver?)
[1.289394] 01064096 ram6 (driver?)
[1.290195] 01074096 ram7 (driver?)
[1.290962] 01084096 ram8 (driver?)
[1.291695] 01094096 ram9 (driver?)
[1.292404] 010a4096 ram10 (driver?)
[1.293114] 010b4096 ram11 (driver?)
[1.293922] 010c4096 ram12 (driver?)
[1.294643] 010d4096 ram13 (driver?)
[1.295401] 010e4096 ram14 (driver?)
[1.296167] 010f4096 ram15 (driver?)
[1.296975] 0800 4194304 sda driver: sd
[1.297697] 0801 4194272 sda1 -01
[1.298418] Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(8,1)
[1.300034] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
3.19.0-rc5-next-20150120-dirty #410
[1.300039] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.7.5-20140617_173321-var-lib-archbuild-testing-x86_64-tobias 04/01/2014
[1.300039] ea001340 88001f673dd8 817e1197
004e
[1.300039] 81a6f2c8 88001f673e58 817dfd43
81c9a860
[1.300039] 8810 88001f673e68 88001f673e08
31616473
[1.300039] Call Trace:
[1.300039] [] dump_stack+0x4f/0x7b
[1.300039] [] panic+0xd2/0x217
[1.300039] [] mount_block_root+0x200/0x28d
[1.300039] [] mount_root+0x54/0x58
[1.300039] [] prepare_namespace+0x168/0x1a1
[1.300039] [] kernel_init_freeable+0x29d/0x2ad
[1.300039] [] ? rest_init+0x140/0x140
[1.300039] [] kernel_init+0xe/0xf0
[1.300039] [] ret_from_fork+0x7c/0xb0
[1.300039] [] ? rest_init+0x140/0x140
[1.300039] Kernel Offset: 0x0 from 0x8100 (relocation range:
0x8000-0x9fff)
[1.300039] ---[ end Kernel panic - not syncing: VFS: Unable to mount root
fs on unknown-block(8,1)
I bisected it down to:
5dc5218840e1 fs: create proper filename objects using getname_kernel()
I reverted then reapplied each part of that patch. It works if I
leave out the hunk for do_path_lookup:
diff --git a/fs/namei.c b/fs/namei.c
index eeb3b83661f8..c3d21b79090e 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -2001,9 +2001,15 @@ static int filename_lookup(int dfd, struct filename
*name,
static int do_path_lookup(int dfd, const char *name,
unsigned int flags, struct nameidata *nd)
{
- struct filename filename = { .name = name };
+ int retval;
+ struct filename *filename;
- return filename_lookup(dfd, , flags, nd);
+ filename = getname_kernel(name);
+ if (unlikely(IS_ERR(filename)))
+ return PTR_ERR(filename);
+ retval = filename_lookup(dfd, filename, flags, nd);
+ putname(filename);
+ return retval;
}
/* does lookup, returns the object with parent locked */
I don't know what other info you may need.
Full dmesg for the failed boot included below.
Thanks.
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 3.19.0-rc5-next-20150120-dirty (zappy@kria) (gcc
version 4.9.2 20141224 (prerelease) (GCC) ) #410 SMP PREEMPT Tue Jan 20
17:27:49 CET 2015
[0.00] Command line: root=/dev/sda1 console=ttyS0
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009fbff] usable
[0.00] BIOS-e820: [mem 0x0009fc00-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000f-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x1ffd] usable
[0.00] BIOS-e820: [mem 0x1ffe-0x1fff] reserved
[0.00] BIOS-e820: [mem 0xfeffc000-0xfeff] reserved
[0.00] BIOS-e820: [mem
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
Hello,
Today's linux-next doesn't boot on my qemu VM:
[1.248357] scsi 0:0:0:0: Direct-Access ATA QEMU HARDDISK0
PQ: 0 ANSI: 5
[1.255899] sd 0:0:0:0: [sda] 8388608 512-byte logical blocks: (4.29 GB/4.00
GiB)
[1.258333] sd 0:0:0:0: [sda] Write Protect is off
[1.259475] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled,
doesn't support DPO or FUA
[1.268417] scsi 1:0:0:0: CD-ROMQEMU QEMU DVD-ROM 2.2.
PQ: 0 ANSI: 5
[1.271673] sda: sda1
[1.281061] sd 0:0:0:0: [sda] Attached SCSI disk
[1.282320] VFS: Cannot open root device sda1 or unknown-block(8,1): error
-2
[1.283484] Please append a correct root= boot option; here are the
available partitions:
[1.284748] 01004096 ram0 (driver?)
[1.285479] 01014096 ram1 (driver?)
[1.286218] 01024096 ram2 (driver?)
[1.286992] 01034096 ram3 (driver?)
[1.287741] 01044096 ram4 (driver?)
[1.288640] 01054096 ram5 (driver?)
[1.289394] 01064096 ram6 (driver?)
[1.290195] 01074096 ram7 (driver?)
[1.290962] 01084096 ram8 (driver?)
[1.291695] 01094096 ram9 (driver?)
[1.292404] 010a4096 ram10 (driver?)
[1.293114] 010b4096 ram11 (driver?)
[1.293922] 010c4096 ram12 (driver?)
[1.294643] 010d4096 ram13 (driver?)
[1.295401] 010e4096 ram14 (driver?)
[1.296167] 010f4096 ram15 (driver?)
[1.296975] 0800 4194304 sda driver: sd
[1.297697] 0801 4194272 sda1 -01
[1.298418] Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(8,1)
[1.300034] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
3.19.0-rc5-next-20150120-dirty #410
[1.300039] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.7.5-20140617_173321-var-lib-archbuild-testing-x86_64-tobias 04/01/2014
[1.300039] ea001340 88001f673dd8 817e1197
004e
[1.300039] 81a6f2c8 88001f673e58 817dfd43
81c9a860
[1.300039] 8810 88001f673e68 88001f673e08
31616473
[1.300039] Call Trace:
[1.300039] [817e1197] dump_stack+0x4f/0x7b
[1.300039] [817dfd43] panic+0xd2/0x217
[1.300039] [81efd58b] mount_block_root+0x200/0x28d
[1.300039] [81efd78b] mount_root+0x54/0x58
[1.300039] [81efd8f7] prepare_namespace+0x168/0x1a1
[1.300039] [81efd2b1] kernel_init_freeable+0x29d/0x2ad
[1.300039] [817d7440] ? rest_init+0x140/0x140
[1.300039] [817d744e] kernel_init+0xe/0xf0
[1.300039] [817eb87c] ret_from_fork+0x7c/0xb0
[1.300039] [817d7440] ? rest_init+0x140/0x140
[1.300039] Kernel Offset: 0x0 from 0x8100 (relocation range:
0x8000-0x9fff)
[1.300039] ---[ end Kernel panic - not syncing: VFS: Unable to mount root
fs on unknown-block(8,1)
I bisected it down to:
5dc5218840e1 fs: create proper filename objects using getname_kernel()
I reverted then reapplied each part of that patch. It works if I
leave out the hunk for do_path_lookup:
diff --git a/fs/namei.c b/fs/namei.c
index eeb3b83661f8..c3d21b79090e 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -2001,9 +2001,15 @@ static int filename_lookup(int dfd, struct filename
*name,
static int do_path_lookup(int dfd, const char *name,
unsigned int flags, struct nameidata *nd)
{
- struct filename filename = { .name = name };
+ int retval;
+ struct filename *filename;
- return filename_lookup(dfd, filename, flags, nd);
+ filename = getname_kernel(name);
+ if (unlikely(IS_ERR(filename)))
+ return PTR_ERR(filename);
+ retval = filename_lookup(dfd, filename, flags, nd);
+ putname(filename);
+ return retval;
}
/* does lookup, returns the object with parent locked */
I don't know what other info you may need.
Full dmesg for the failed boot included below.
Thanks.
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 3.19.0-rc5-next-20150120-dirty (zappy@kria) (gcc
version 4.9.2 20141224 (prerelease) (GCC) ) #410 SMP PREEMPT Tue Jan 20
17:27:49 CET 2015
[0.00] Command line: root=/dev/sda1 console=ttyS0
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009fbff] usable
[0.00] BIOS-e820: [mem 0x0009fc00-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000f-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x1ffd] usable
[0.00] BIOS-e820: [mem
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On Tue, 2015-01-20 at 15:54 -0200, Fabio Estevam wrote: On Tue, Jan 20, 2015 at 3:39 PM, Paul Moore pmo...@redhat.com wrote: Thanks for testing this and reporting the problem, especially such a small bisection. Unfortunately nothing is immediately obvious to me, would you mind sharing your kernel config so I can try to reproduce and debug the problem? In case it helps, I also get the similar errors on a mx6 which is built with arch/arm/configs/imx_v6_v7_defconfig: [1.594196] imx-ipuv3 280.ipu: IPUv3H probed [1.601836] ram0: unknown partition table [1.607247] ram1: unknown partition table [1.612617] ram2: unknown partition table [1.618010] ram3: unknown partition table [1.623359] ram4: unknown partition table [1.628761] ram5: unknown partition table [1.634065] ram6: unknown partition table [1.639436] ram7: unknown partition table [1.644749] ram8: unknown partition table [1.650132] ram9: unknown partition table [1.655447] ram10: unknown partition table [1.660911] ram11: unknown partition table [1.666268] ram12: unknown partition table [1.671778] ram13: unknown partition table [1.677154] ram14: unknown partition table [1.682593] ram15: unknown partition table [1.687165] brd: module loaded [1.705148] loop: module loaded This is probably related to the issue reported in this thread: https://lkml.org/lkml/2015/1/16/563 These were just nuisance warnings, I believe, so my guess is that this isn't related to your kernel panic. Reverting Boaz's patches to make these warnings go away would let you know for sure. - Ross -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On Tuesday, January 20, 2015 05:56:55 PM Sabrina Dubroca wrote:
Hello,
Today's linux-next doesn't boot on my qemu VM:
...
I bisected it down to:
5dc5218840e1 fs: create proper filename objects using getname_kernel()
I reverted then reapplied each part of that patch. It works if I
leave out the hunk for do_path_lookup:
diff --git a/fs/namei.c b/fs/namei.c
index eeb3b83661f8..c3d21b79090e 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -2001,9 +2001,15 @@ static int filename_lookup(int dfd, struct filename
*name, static int do_path_lookup(int dfd, const char *name,
unsigned int flags, struct nameidata *nd)
{
- struct filename filename = { .name = name };
+ int retval;
+ struct filename *filename;
- return filename_lookup(dfd, filename, flags, nd);
+ filename = getname_kernel(name);
+ if (unlikely(IS_ERR(filename)))
+ return PTR_ERR(filename);
+ retval = filename_lookup(dfd, filename, flags, nd);
+ putname(filename);
+ return retval;
}
I don't know what other info you may need.
Full dmesg for the failed boot included below.
Thanks for testing this and reporting the problem, especially such a small
bisection. Unfortunately nothing is immediately obvious to me, would you mind
sharing your kernel config so I can try to reproduce and debug the problem?
-Paul
--
paul moore
security @ redhat
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
2015-01-20, 12:39:08 -0500, Paul Moore wrote:
On Tuesday, January 20, 2015 05:56:55 PM Sabrina Dubroca wrote:
Hello,
Today's linux-next doesn't boot on my qemu VM:
...
I bisected it down to:
5dc5218840e1 fs: create proper filename objects using getname_kernel()
I reverted then reapplied each part of that patch. It works if I
leave out the hunk for do_path_lookup:
diff --git a/fs/namei.c b/fs/namei.c
index eeb3b83661f8..c3d21b79090e 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -2001,9 +2001,15 @@ static int filename_lookup(int dfd, struct filename
*name, static int do_path_lookup(int dfd, const char *name,
unsigned int flags, struct nameidata *nd)
{
- struct filename filename = { .name = name };
+ int retval;
+ struct filename *filename;
- return filename_lookup(dfd, filename, flags, nd);
+ filename = getname_kernel(name);
+ if (unlikely(IS_ERR(filename)))
+ return PTR_ERR(filename);
+ retval = filename_lookup(dfd, filename, flags, nd);
+ putname(filename);
+ return retval;
}
I don't know what other info you may need.
Full dmesg for the failed boot included below.
Thanks for testing this and reporting the problem, especially such a small
bisection. Unfortunately nothing is immediately obvious to me, would you
mind
sharing your kernel config so I can try to reproduce and debug the problem?
Sure.
I run qemu with:
qemu-system-x86_64 -enable-kvm -cpu host -m 512 -kernel bzImage -append
'root=/dev/sda1' $IMG
and the image contains a single ext4 partition with a basic ArchLinux install.
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86 3.19.0-rc5 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_PERF_EVENTS_INTEL_UNCORE=y
CONFIG_OUTPUT_FORMAT=elf64-x86-64
CONFIG_ARCH_DEFCONFIG=arch/x86/configs/x86_64_defconfig
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_HAVE_INTEL_TXT=y
CONFIG_X86_64_SMP=y
CONFIG_X86_HT=y
CONFIG_ARCH_HWEIGHT_CFLAGS=-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx
-fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10
-fcall-saved-r11
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME=earth
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_FHANDLE=y
CONFIG_USELIB=y
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_WATCH=y
CONFIG_AUDIT_TREE=y
#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_LEGACY_ALLOC_HWIRQ=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_IRQ_DOMAIN=y
CONFIG_GENERIC_MSI_IRQ=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y
#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
# CONFIG_NO_HZ_FULL is not set
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set
# CONFIG_IRQ_TIME_ACCOUNTING is not set
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
CONFIG_TASK_IO_ACCOUNTING=y
#
#
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On Tue, Jan 20, 2015 at 3:39 PM, Paul Moore pmo...@redhat.com wrote: Thanks for testing this and reporting the problem, especially such a small bisection. Unfortunately nothing is immediately obvious to me, would you mind sharing your kernel config so I can try to reproduce and debug the problem? In case it helps, I also get the similar errors on a mx6 which is built with arch/arm/configs/imx_v6_v7_defconfig: [1.594196] imx-ipuv3 280.ipu: IPUv3H probed [1.601836] ram0: unknown partition table [1.607247] ram1: unknown partition table [1.612617] ram2: unknown partition table [1.618010] ram3: unknown partition table [1.623359] ram4: unknown partition table [1.628761] ram5: unknown partition table [1.634065] ram6: unknown partition table [1.639436] ram7: unknown partition table [1.644749] ram8: unknown partition table [1.650132] ram9: unknown partition table [1.655447] ram10: unknown partition table [1.660911] ram11: unknown partition table [1.666268] ram12: unknown partition table [1.671778] ram13: unknown partition table [1.677154] ram14: unknown partition table [1.682593] ram15: unknown partition table [1.687165] brd: module loaded [1.705148] loop: module loaded -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On Tuesday, January 20, 2015 05:43:01 PM Fabio Estevam wrote: On Tue, Jan 20, 2015 at 5:24 PM, Paul Moore pmo...@redhat.com wrote: On Tuesday, January 20, 2015 05:16:45 PM Fabio Estevam wrote: On Tue, Jan 20, 2015 at 5:00 PM, Ross Zwisler ross.zwis...@linux.intel.com wrote: These were just nuisance warnings, I believe, so my guess is that this isn't related to your kernel panic. Reverting Boaz's patches to make these warnings go away would let you know for sure. You are right. Reverting 937af5ecd0591e makes such warnings disappear. You guys are much quicker compiling kernels than I am :) Fabio, are you still seeing the same panic, just without the warnings? Or has the panic resolved itself as well? Just to clarify: I was not getting the same panic Sabrina originally reported. Reverting 937af5ecd0591e made the ram warnings go away. On my case I am running linux-next 20150120 plus this fix: http://www.spinics.net/lists/arm-kernel/msg393205.html and things seem to boot fine here on my ARM platform. Okay, thanks for the clarification; glad you got it working. -- paul moore security @ redhat -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On Tue, Jan 20, 2015 at 10:38:58PM +0100, Sabrina Dubroca wrote: [1.538646] fn_lookup bsg/0:0:0:0 -2, 88001f718000 bsg/0:0:0:0 [1.539704] fn_lookup bsg 0, 88001f718000 bsg [1.540559] fn_lookup bsg/0:0:0:0 -2, 88001f718000 bsg/0:0:0:0 [1.552611] fn_lookup bsg/1:0:0:0 -2, 88001f718000 bsg/1:0:0:0 [1.553689] fn_lookup bsg 0, 88001f718000 bsg [1.554505] fn_lookup bsg/1:0:0:0 -2, 88001f718000 bsg/1:0:0:0 [1.557554] fn_lookup sda 0, 88001f718000 sda [1.558368] fn_lookup sda 0, 88001f718000 sda [1.564190] fn_lookup sda1 0, 88001f718000 sda1 [1.565008] fn_lookup sda1 0, 88001f718000 sda1 [1.570751] fn_lookup /dev/ram -2, 88001f71a300 /dev/ram [1.571786] fn_lookup /dev/root -2, 88001f71b480 /dev/root Nuts... Is reverting just this (do_path_lookup()) part of commit sufficient to recover the normal behaviour? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
2015-01-20, 21:02:03 +, Al Viro wrote: On Tue, Jan 20, 2015 at 09:45:04PM +0100, Sabrina Dubroca wrote: printk(KERN_ERR fn_lookup %s %d\n, name, retval); and I get: [1.618558] fn_lookup bsg/0:0:0:0 -2 [1.619437] fn_lookup bsg 0 [1.620236] fn_lookup bsg/0:0:0:0 -2 [1.625996] fn_lookup sda 0 [1.626609] fn_lookup sda 0 [1.639007] fn_lookup sda1 0 [1.639691] fn_lookup sda1 0 [1.643656] fn_lookup bsg/1:0:0:0 -2 [1.644974] fn_lookup bsg 0 [1.645928] fn_lookup bsg/1:0:0:0 -2 [1.649483] fn_lookup /dev/ram -2 [1.650424] fn_lookup /dev/root -2 [1.651234] VFS: Cannot open root device sda1 or unknown-block(8,1): error -2 That -2 is -ENOENT... Wait a sec, what's in filename, filename-name and what do you get from your printk on kernel with that commit reverted? filename-name matches name. with printk(KERN_ERR fn_lookup %s %d, %p %s\n, name, retval, filename, filename-name); [1.538646] fn_lookup bsg/0:0:0:0 -2, 88001f718000 bsg/0:0:0:0 [1.539704] fn_lookup bsg 0, 88001f718000 bsg [1.540559] fn_lookup bsg/0:0:0:0 -2, 88001f718000 bsg/0:0:0:0 [1.552611] fn_lookup bsg/1:0:0:0 -2, 88001f718000 bsg/1:0:0:0 [1.553689] fn_lookup bsg 0, 88001f718000 bsg [1.554505] fn_lookup bsg/1:0:0:0 -2, 88001f718000 bsg/1:0:0:0 [1.557554] fn_lookup sda 0, 88001f718000 sda [1.558368] fn_lookup sda 0, 88001f718000 sda [1.564190] fn_lookup sda1 0, 88001f718000 sda1 [1.565008] fn_lookup sda1 0, 88001f718000 sda1 [1.570751] fn_lookup /dev/ram -2, 88001f71a300 /dev/ram [1.571786] fn_lookup /dev/root -2, 88001f71b480 /dev/root and with printk(KERN_ERR fn_lookup %s %d, %s\n, name, retval, filename.name); in the original do_path_lookup: [1.426101] fn_lookup bsg/0:0:0:0 -2, bsg/0:0:0:0 [1.426893] fn_lookup bsg 0, bsg [1.427406] fn_lookup bsg/0:0:0:0 0, bsg/0:0:0:0 [1.431530] fn_lookup sda 0, sda [1.438346] fn_lookup bsg/1:0:0:0 0, bsg/1:0:0:0 [1.443658] fn_lookup sda1 0, sda1 [1.448344] fn_lookup /dev/ram 0, /dev/ram [1.449148] fn_lookup /dev/root 0, /dev/root [1.449835] fn_lookup /dev/root 0, /dev/root [1.451586] EXT4-fs (sda1): couldn't mount as ext3 due to feature incompatibilities [1.452954] fn_lookup /dev/root 0, /dev/root [1.454292] EXT4-fs (sda1): couldn't mount as ext2 due to feature incompatibilities [1.456331] fn_lookup /dev/root 0, /dev/root [1.480208] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) [1.481323] VFS: Mounted root (ext4 filesystem) readonly on device 8:1. -- Sabrina -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
2015-01-20, 21:58:31 +, Al Viro wrote: On Tue, Jan 20, 2015 at 10:38:58PM +0100, Sabrina Dubroca wrote: [1.538646] fn_lookup bsg/0:0:0:0 -2, 88001f718000 bsg/0:0:0:0 [1.539704] fn_lookup bsg 0, 88001f718000 bsg [1.540559] fn_lookup bsg/0:0:0:0 -2, 88001f718000 bsg/0:0:0:0 [1.552611] fn_lookup bsg/1:0:0:0 -2, 88001f718000 bsg/1:0:0:0 [1.553689] fn_lookup bsg 0, 88001f718000 bsg [1.554505] fn_lookup bsg/1:0:0:0 -2, 88001f718000 bsg/1:0:0:0 [1.557554] fn_lookup sda 0, 88001f718000 sda [1.558368] fn_lookup sda 0, 88001f718000 sda [1.564190] fn_lookup sda1 0, 88001f718000 sda1 [1.565008] fn_lookup sda1 0, 88001f718000 sda1 [1.570751] fn_lookup /dev/ram -2, 88001f71a300 /dev/ram [1.571786] fn_lookup /dev/root -2, 88001f71b480 /dev/root Nuts... Is reverting just this (do_path_lookup()) part of commit sufficient to recover the normal behaviour? Yes. -- Sabrina -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On Tue, Jan 20, 2015 at 10:50:41PM +, Al Viro wrote: doesn't look at _anything_ other than name-name other than for audit_inode(). And name-name is apparently the same. It looks like something ends up buggering name-name in process, but then the damn thing appears to be normal after return from filename_lookup()... If my reconstruction of what's going on is correct, the call chain here is do_path_lookup() - kern_path() - lookup_bdev() - blkdev_get_by_path() - mount_bdev() - some_type.mount() - mount_fs() - vfs_kern_mount() - do_new_mount() - do_mount() - sys_mount() - do_mount_root() - mount_block_root() - mount_root(). Which is obscenely long, BTW, but that's a separate story... Could you slap struct stat buf; int n = sys_newstat(name, buf); printk(KERN_ERR stat(\%s\) - %d\n, name, n); n = sys_newstat(/dev, buf); printk(KERN_ERR stat(\dev\) - %d\n, n); in the beginning of mount_block_root() (init/do_mounts.c) and see what it prints? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On Wednesday, January 21, 2015 12:27:26 AM Sabrina Dubroca wrote: 2015-01-20, 23:17:25 +, Al Viro wrote: On Tue, Jan 20, 2015 at 10:50:41PM +, Al Viro wrote: doesn't look at _anything_ other than name-name other than for audit_inode(). And name-name is apparently the same. It looks like something ends up buggering name-name in process, but then the damn thing appears to be normal after return from filename_lookup()... If my reconstruction of what's going on is correct, the call chain here is do_path_lookup() - kern_path() - lookup_bdev() - blkdev_get_by_path() - mount_bdev() - some_type.mount() - mount_fs() - vfs_kern_mount() - do_new_mount() - do_mount() - sys_mount() - do_mount_root() - mount_block_root() - mount_root(). Which is obscenely long, BTW, but that's a separate story... Could you slap struct stat buf; int n = sys_newstat(name, buf); printk(KERN_ERR stat(\%s\) - %d\n, name, n); n = sys_newstat(/dev, buf); printk(KERN_ERR stat(\dev\) - %d\n, n); in the beginning of mount_block_root() (init/do_mounts.c) and see what it prints? I get stat(/dev/root) - -2 stat(dev) - -2 with the patch applied (+panic) and: stat(/dev/root) - 0 stat(dev) - 0 with the old version of do_path_lookup. Wait a minute ... at this early stage of boot, I'm pretty sure we don't have a valid current-audit_context since we haven't fork'd anything. If the audit context was non-NULL garbage that might explain the panic ... -- paul moore security @ redhat -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On Tue, Jan 20, 2015 at 09:45:04PM +0100, Sabrina Dubroca wrote: printk(KERN_ERR fn_lookup %s %d\n, name, retval); and I get: [1.618558] fn_lookup bsg/0:0:0:0 -2 [1.619437] fn_lookup bsg 0 [1.620236] fn_lookup bsg/0:0:0:0 -2 [1.625996] fn_lookup sda 0 [1.626609] fn_lookup sda 0 [1.639007] fn_lookup sda1 0 [1.639691] fn_lookup sda1 0 [1.643656] fn_lookup bsg/1:0:0:0 -2 [1.644974] fn_lookup bsg 0 [1.645928] fn_lookup bsg/1:0:0:0 -2 [1.649483] fn_lookup /dev/ram -2 [1.650424] fn_lookup /dev/root -2 [1.651234] VFS: Cannot open root device sda1 or unknown-block(8,1): error -2 That -2 is -ENOENT... Wait a sec, what's in filename, filename-name and what do you get from your printk on kernel with that commit reverted? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On Tue, Jan 20, 2015 at 09:02:03PM +, Al Viro wrote: On Tue, Jan 20, 2015 at 09:45:04PM +0100, Sabrina Dubroca wrote: printk(KERN_ERR fn_lookup %s %d\n, name, retval); and I get: [1.618558] fn_lookup bsg/0:0:0:0 -2 [1.619437] fn_lookup bsg 0 [1.620236] fn_lookup bsg/0:0:0:0 -2 [1.625996] fn_lookup sda 0 [1.626609] fn_lookup sda 0 [1.639007] fn_lookup sda1 0 [1.639691] fn_lookup sda1 0 [1.643656] fn_lookup bsg/1:0:0:0 -2 [1.644974] fn_lookup bsg 0 [1.645928] fn_lookup bsg/1:0:0:0 -2 [1.649483] fn_lookup /dev/ram -2 [1.650424] fn_lookup /dev/root -2 [1.651234] VFS: Cannot open root device sda1 or unknown-block(8,1): error -2 That -2 is -ENOENT... Wait a sec, what's in filename, filename-name and what do you get from your printk on kernel with that commit reverted? On microblaze target: patch reverted: name . rv 0 name usr rv 0 name usr/lib rv 0 name usr/share rv 0 name usr/share/udhcpc rv 0 name usr/bin rv 0 name usr/bin/logger rv 0 ... broken: filename c78a4000 filename-name c78a4014:. name . rv 0 filename c78a4000 filename-name c78a4014:usr name usr rv 0 filename c78a4000 filename-name c78a4014:usr/lib name usr/lib rv -2 filename c78a4000 filename-name c78a4014:usr/share name usr/share rv -2 filename c78a4000 filename-name c78a4014:usr/share/udhcpc name usr/share/udhcpc rv -2 filename c78a4000 filename-name c78a4014:usr/bin name usr/bin rv -2 filename c78ae000 filename-name c78ae014:usr/bin/logger name usr/bin/logger rv -2 ... Guenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On Tue, Jan 20, 2015 at 11:08:23PM +0100, Sabrina Dubroca wrote: 2015-01-20, 21:58:31 +, Al Viro wrote: On Tue, Jan 20, 2015 at 10:38:58PM +0100, Sabrina Dubroca wrote: [1.538646] fn_lookup bsg/0:0:0:0 -2, 88001f718000 bsg/0:0:0:0 [1.539704] fn_lookup bsg 0, 88001f718000 bsg [1.540559] fn_lookup bsg/0:0:0:0 -2, 88001f718000 bsg/0:0:0:0 [1.552611] fn_lookup bsg/1:0:0:0 -2, 88001f718000 bsg/1:0:0:0 [1.553689] fn_lookup bsg 0, 88001f718000 bsg [1.554505] fn_lookup bsg/1:0:0:0 -2, 88001f718000 bsg/1:0:0:0 [1.557554] fn_lookup sda 0, 88001f718000 sda [1.558368] fn_lookup sda 0, 88001f718000 sda [1.564190] fn_lookup sda1 0, 88001f718000 sda1 [1.565008] fn_lookup sda1 0, 88001f718000 sda1 [1.570751] fn_lookup /dev/ram -2, 88001f71a300 /dev/ram [1.571786] fn_lookup /dev/root -2, 88001f71b480 /dev/root Nuts... Is reverting just this (do_path_lookup()) part of commit sufficient to recover the normal behaviour? Yes. Same on microblaze. Guenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On Tuesday, January 20, 2015 07:04:54 PM Paul Moore wrote:
On Wednesday, January 21, 2015 12:27:26 AM Sabrina Dubroca wrote:
2015-01-20, 23:17:25 +, Al Viro wrote:
On Tue, Jan 20, 2015 at 10:50:41PM +, Al Viro wrote:
doesn't look at _anything_ other than name-name other than for
audit_inode(). And name-name is apparently the same.
It looks like something ends up buggering name-name in process, but
then
the damn thing appears to be normal after return from
filename_lookup()...
If my reconstruction of what's going on is correct, the call chain here
is do_path_lookup() - kern_path() - lookup_bdev() -
blkdev_get_by_path()
- mount_bdev() - some_type.mount() - mount_fs()
- vfs_kern_mount() - do_new_mount() - do_mount() - sys_mount()
- do_mount_root() - mount_block_root() - mount_root(). Which is
obscenely long, BTW, but that's a separate story...
Could you slap
struct stat buf;
int n = sys_newstat(name, buf);
printk(KERN_ERR stat(\%s\) - %d\n, name, n);
n = sys_newstat(/dev, buf);
printk(KERN_ERR stat(\dev\) - %d\n, n);
in the beginning of mount_block_root() (init/do_mounts.c) and see what
it
prints?
I get
stat(/dev/root) - -2
stat(dev) - -2
with the patch applied (+panic)
and:
stat(/dev/root) - 0
stat(dev) - 0
with the old version of do_path_lookup.
Wait a minute ... at this early stage of boot, I'm pretty sure we don't have
a valid current-audit_context since we haven't fork'd anything. If the
audit context was non-NULL garbage that might explain the panic ...
Could you try initializing the init_task's audit_context to NULL in the
INIT_TASK macro in include/linux/init_task.h?
Example:
#define INIT_TASK(tsk)
{
.state = 0,
.stack = init_thread_info,
...
.audit_context = NULL,
...
}
--
paul moore
security @ redhat
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
2015-01-20, 23:17:25 +, Al Viro wrote: On Tue, Jan 20, 2015 at 10:50:41PM +, Al Viro wrote: doesn't look at _anything_ other than name-name other than for audit_inode(). And name-name is apparently the same. It looks like something ends up buggering name-name in process, but then the damn thing appears to be normal after return from filename_lookup()... If my reconstruction of what's going on is correct, the call chain here is do_path_lookup() - kern_path() - lookup_bdev() - blkdev_get_by_path() - mount_bdev() - some_type.mount() - mount_fs() - vfs_kern_mount() - do_new_mount() - do_mount() - sys_mount() - do_mount_root() - mount_block_root() - mount_root(). Which is obscenely long, BTW, but that's a separate story... Could you slap struct stat buf; int n = sys_newstat(name, buf); printk(KERN_ERR stat(\%s\) - %d\n, name, n); n = sys_newstat(/dev, buf); printk(KERN_ERR stat(\dev\) - %d\n, n); in the beginning of mount_block_root() (init/do_mounts.c) and see what it prints? I get stat(/dev/root) - -2 stat(dev) - -2 with the patch applied (+panic) and: stat(/dev/root) - 0 stat(dev) - 0 with the old version of do_path_lookup. -- Sabrina -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On Tue, Jan 20, 2015 at 02:13:09PM -0800, Guenter Roeck wrote:
Nuts... Is reverting just this (do_path_lookup()) part of commit
sufficient
to recover the normal behaviour?
Yes.
Same on microblaze.
This is completely insane.
static int filename_lookup(int dfd, struct filename *name,
unsigned int flags, struct nameidata *nd)
{
int retval = path_lookupat(dfd, name-name, flags | LOOKUP_RCU, nd);
if (unlikely(retval == -ECHILD))
retval = path_lookupat(dfd, name-name, flags, nd);
if (unlikely(retval == -ESTALE))
retval = path_lookupat(dfd, name-name,
flags | LOOKUP_REVAL, nd);
if (likely(!retval))
audit_inode(name, nd-path.dentry, flags LOOKUP_PARENT);
return retval;
}
doesn't look at _anything_ other than name-name other than for audit_inode().
And name-name is apparently the same.
It looks like something ends up buggering name-name in process, but then
the damn thing appears to be normal after return from filename_lookup()...
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On Tue, Jan 20, 2015 at 07:14:46PM -0500, Paul Moore wrote: with the patch applied (+panic) and: stat(/dev/root) - 0 stat(dev) - 0 with the old version of do_path_lookup. Wait a minute ... at this early stage of boot, I'm pretty sure we don't have a valid current-audit_context since we haven't fork'd anything. If the audit context was non-NULL garbage that might explain the panic ... Not really - the panic is predicatable result of not finding /dev/root (hell, not even /dev there!) in mount_block_root(). Could you try initializing the init_task's audit_context to NULL in the INIT_TASK macro in include/linux/init_task.h? Missing fields in struct initializer are treated as zeroes. 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? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
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;
}
--
To unsubscribe from this list: send the line unsubscribe
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On 01/20/2015 04:41 PM, Al Viro 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. Guenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On 01/20/2015 07:36 PM, Al Viro wrote: 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 Artifact from when I created the root file system (which apparently was with 3.9.2). It is irrelevant for my testing, at least so far, so I never bothered fixing it. least a plausible direction for digging. Look: diff --git a/fs/namei.c b/fs/namei.c index 323957f..c7d107c 100644 --- a/fs/namei.c +++ b/fs/namei.c With this patch: sys_mkdir .:40775 returned -17 sys_mkdir usr:40775 returned 0 sys_mkdir usr/lib:40775 returned 0 sys_mkdir usr/share:40755 returned 0 sys_mkdir usr/share/udhcpc:40755 returned 0 sys_mkdir usr/bin:40775 returned 0 sys_mkdir usr/sbin:40775 returned 0 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 0 ... and the problem is fixed. Guenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On Tue, Jan 20, 2015 at 08:01:26PM -0800, Guenter Roeck wrote:
With this patch:
sys_mkdir .:40775 returned -17
sys_mkdir usr:40775 returned 0
sys_mkdir usr/lib:40775 returned 0
sys_mkdir usr/share:40755 returned 0
sys_mkdir usr/share/udhcpc:40755 returned 0
sys_mkdir usr/bin:40775 returned 0
sys_mkdir usr/sbin:40775 returned 0
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 0
...
and the problem is fixed.
... except that it simply confirms that something's fishy with getname_kernel()
of -name of struct filename returned by getname(). IOW, I still do not
understand the mechanism of breakage there.
Another thing I really do not understand is
+ if (inode-i_ino) {
+ /* valid inode number, use that for the comparison */
+ if (n-ino != inode-i_ino ||
+ n-dev != inode-i_sb-s_dev)
+ continue;
in __audit_inode(). We don't *have* dentries with dentry-d_inode-i_ino == 0.
Ever. WTF is that about? Paul?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
2015-01-20, 19:54:32 +, Al Viro wrote:
On Tue, Jan 20, 2015 at 06:51:35PM +0100, Sabrina Dubroca wrote:
2015-01-20, 12:39:08 -0500, Paul Moore wrote:
On Tuesday, January 20, 2015 05:56:55 PM Sabrina Dubroca wrote:
Hello,
Today's linux-next doesn't boot on my qemu VM:
...
I bisected it down to:
5dc5218840e1 fs: create proper filename objects using getname_kernel()
I reverted then reapplied each part of that patch. It works if I
leave out the hunk for do_path_lookup:
diff --git a/fs/namei.c b/fs/namei.c
index eeb3b83661f8..c3d21b79090e 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -2001,9 +2001,15 @@ static int filename_lookup(int dfd, struct
filename
*name, static int do_path_lookup(int dfd, const char *name,
unsigned int flags, struct nameidata
*nd)
{
- struct filename filename = { .name = name };
+ int retval;
+ struct filename *filename;
- return filename_lookup(dfd, filename, flags, nd);
+ filename = getname_kernel(name);
+ if (unlikely(IS_ERR(filename)))
+ return PTR_ERR(filename);
+ retval = filename_lookup(dfd, filename, flags, nd);
+ putname(filename);
+ return retval;
}
I don't know what other info you may need.
Full dmesg for the failed boot included below.
Thanks for testing this and reporting the problem, especially such a
small
bisection. Unfortunately nothing is immediately obvious to me, would you
mind
sharing your kernel config so I can try to reproduce and debug the
problem?
Sure.
I run qemu with:
qemu-system-x86_64 -enable-kvm -cpu host -m 512 -kernel bzImage -append
'root=/dev/sda1' $IMG
and the image contains a single ext4 partition with a basic ArchLinux
install.
Could you turn that return PTR_ERR(filename); into
{
printk(KERN_ERR failed(%p - %d), name, PTR_ERR(filename));
return PTR_ERR(filename);
}
reproduce the panic and see what has it produced?
Nothing.
Not sure if it helps, but I added after filename_lookup:
printk(KERN_ERR fn_lookup %s %d\n, name, retval);
and I get:
[1.618558] fn_lookup bsg/0:0:0:0 -2
[1.619437] fn_lookup bsg 0
[1.620236] fn_lookup bsg/0:0:0:0 -2
[1.625996] fn_lookup sda 0
[1.626609] fn_lookup sda 0
[1.639007] fn_lookup sda1 0
[1.639691] fn_lookup sda1 0
[1.643656] fn_lookup bsg/1:0:0:0 -2
[1.644974] fn_lookup bsg 0
[1.645928] fn_lookup bsg/1:0:0:0 -2
[1.649483] fn_lookup /dev/ram -2
[1.650424] fn_lookup /dev/root -2
[1.651234] VFS: Cannot open root device sda1 or unknown-block(8,1): error
-2
--
Sabrina
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On Tue, Jan 20, 2015 at 5:00 PM, Ross Zwisler ross.zwis...@linux.intel.com wrote: These were just nuisance warnings, I believe, so my guess is that this isn't related to your kernel panic. Reverting Boaz's patches to make these warnings go away would let you know for sure. You are right. Reverting 937af5ecd0591e makes such warnings disappear. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On Tue, Jan 20, 2015 at 5:24 PM, Paul Moore pmo...@redhat.com wrote: On Tuesday, January 20, 2015 05:16:45 PM Fabio Estevam wrote: On Tue, Jan 20, 2015 at 5:00 PM, Ross Zwisler ross.zwis...@linux.intel.com wrote: These were just nuisance warnings, I believe, so my guess is that this isn't related to your kernel panic. Reverting Boaz's patches to make these warnings go away would let you know for sure. You are right. Reverting 937af5ecd0591e makes such warnings disappear. You guys are much quicker compiling kernels than I am :) Fabio, are you still seeing the same panic, just without the warnings? Or has the panic resolved itself as well? Just to clarify: I was not getting the same panic Sabrina originally reported. Reverting 937af5ecd0591e made the ram warnings go away. On my case I am running linux-next 20150120 plus this fix: http://www.spinics.net/lists/arm-kernel/msg393205.html and things seem to boot fine here on my ARM platform. Thanks -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On Tuesday, January 20, 2015 05:16:45 PM Fabio Estevam wrote: On Tue, Jan 20, 2015 at 5:00 PM, Ross Zwisler ross.zwis...@linux.intel.com wrote: These were just nuisance warnings, I believe, so my guess is that this isn't related to your kernel panic. Reverting Boaz's patches to make these warnings go away would let you know for sure. You are right. Reverting 937af5ecd0591e makes such warnings disappear. You guys are much quicker compiling kernels than I am :) Fabio, are you still seeing the same panic, just without the warnings? Or has the panic resolved itself as well? -- paul moore security @ redhat -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On Tue, Jan 20, 2015 at 06:51:35PM +0100, Sabrina Dubroca wrote:
2015-01-20, 12:39:08 -0500, Paul Moore wrote:
On Tuesday, January 20, 2015 05:56:55 PM Sabrina Dubroca wrote:
Hello,
Today's linux-next doesn't boot on my qemu VM:
...
I bisected it down to:
5dc5218840e1 fs: create proper filename objects using getname_kernel()
I reverted then reapplied each part of that patch. It works if I
leave out the hunk for do_path_lookup:
diff --git a/fs/namei.c b/fs/namei.c
index eeb3b83661f8..c3d21b79090e 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -2001,9 +2001,15 @@ static int filename_lookup(int dfd, struct filename
*name, static int do_path_lookup(int dfd, const char *name,
unsigned int flags, struct nameidata *nd)
{
- struct filename filename = { .name = name };
+ int retval;
+ struct filename *filename;
- return filename_lookup(dfd, filename, flags, nd);
+ filename = getname_kernel(name);
+ if (unlikely(IS_ERR(filename)))
+ return PTR_ERR(filename);
+ retval = filename_lookup(dfd, filename, flags, nd);
+ putname(filename);
+ return retval;
}
I don't know what other info you may need.
Full dmesg for the failed boot included below.
Thanks for testing this and reporting the problem, especially such a small
bisection. Unfortunately nothing is immediately obvious to me, would you
mind
sharing your kernel config so I can try to reproduce and debug the problem?
Sure.
I run qemu with:
qemu-system-x86_64 -enable-kvm -cpu host -m 512 -kernel bzImage -append
'root=/dev/sda1' $IMG
and the image contains a single ext4 partition with a basic ArchLinux install.
Could you turn that return PTR_ERR(filename); into
{
printk(KERN_ERR failed(%p - %d), name, PTR_ERR(filename));
return PTR_ERR(filename);
}
reproduce the panic and see what has it produced?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
