[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20151120175643.GM22011@ZenIV.linux.org.uk>
Date: Fri, 20 Nov 2015 17:56:44 +0000
From: Al Viro <viro@...IV.linux.org.uk>
To: Christophe Leroy <christophe.leroy@....fr>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
LinuxPPC-dev <linuxppc-dev@...ts.ozlabs.org>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
BOUET Serge <serge.bouet@....fr>,
BARABAN Luc <luc.baraban@....fr>
Subject: Re: Recurring Oops in link_path_walk()
On Fri, Nov 20, 2015 at 06:07:59PM +0100, Christophe Leroy wrote:
> Al,
>
> We've been running Kernel 3.18 for several monthes on our embedded
> boards, and we have a recurring Oops in link_path_walk()
> It doesn't happen very often (approximatly once every month on one
> board among a set of 50 boards, never the same board).
>
> Here below is the last oops I got, with kernel 3.18.22. It crashes
> at address 0xc00b75ac. Here below is the full desassembly of
> link_path_walk() so that you can see exactly the offending line.
>
> The address it fails at is always the same (link_path_walk+0x414)
> but the oopsing data address is each time different. I added all
> Oops I got below after the disassembly (on different sub-versions of
> 3.18).
Looks like garbage in dentry->d_inode, assuming that reconstruction of
the mapping of line numbers to addresses is correct... Not sure it is,
though; what's more, just how does LR manage to point to the insn right
after the call of dput(), of all things?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists