Re: BUG_ON(nd->inode != parent->d_inode);

From: Dave Jones
Date: Sat Mar 09 2013 - 00:16:55 EST


On Sat, Mar 09, 2013 at 12:13:16AM -0500, Sasha Levin wrote:
> On 03/08/2013 11:39 PM, Dave Jones wrote:
> > On Fri, Mar 08, 2013 at 08:31:48PM -0800, Linus Torvalds wrote:
> > > On Fri, Mar 8, 2013 at 7:50 PM, Dave Jones <davej@xxxxxxxxxx> wrote:
> > > > > >
> > > > > > I have a feeling there were some sysfs ones that may still be unfixed.
> > > >
> > > > I was right..
> > > >
> > > > [ 425.836722] general protection fault: 0000 [#1] PREEMPT SMP
> > >
> > > You forgot to enable DEBUG_PAGE_ALLOC again, but I don't think it much
> > > matters. It's another slab free poison thing.
> > >
> > > The faulting instruction is
> > >
> > > mov 0x28(%rbx),%ecx
> > >
> > > with %rbx having the value 6b6b6b6b6b6b6b6b.
> > >
> > > > [ 425.847859] RIP: 0010:[<ffffffff8123f657>] [<ffffffff8123f657>] sysfs_find_dirent+0x47/0xf0
> > >
> > > That seems to be
> > >
> > > if (hash != sd->s_hash)
> > >
> > > from sysfs_name_compare() that has been inlined into
> > > sysfs_find_dirent(). And where "sd" is the corrupted value. If I read
> > > things right.
> > >
> > > So it looks like the sysfs rbtree is corrupted or something. Adding
> > > Greg to the cc.
> >
> > oh , that rings a bell. ISTR this had something to do with Sasha's idr changes.
>
> I believe the issue you're referring to is my report of a panic in sysfs keys
> where the device has gone away? If that is it, I don't think that this issue
> is related to that one.
>
> If not, I'm not sure which change you're referring to.

Hmm I might have been thinking of the hlist changes rather than idr.
Though looking at those oopses, they were in find_pid_ns, so different.

So many bugs.

Dave


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/