[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141009203505.GD25729@saruman>
Date: Thu, 9 Oct 2014 15:35:05 -0500
From: Felipe Balbi <balbi@...com>
To: Felipe Balbi <balbi@...com>
CC: Johannes Weiner <hannes@...xchg.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Sasha Levin <sasha.levin@...cle.com>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
Linux USB Mailing List <linux-usb@...r.kernel.org>,
Alan Stern <stern@...land.harvard.edu>,
<josh@...htriplett.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Tony Lindgren <tony@...mide.com>,
Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
Linux ARM Kernel Mailing List
<linux-arm-kernel@...ts.infradead.org>,
Rik van Riel <riel@...hat.com>
Subject: Re: RCU bug with v3.17-rc3 ?
Hi,
On Thu, Oct 09, 2014 at 11:26:56AM -0500, Felipe Balbi wrote:
> > I'm thinking it's not the slot pointer itself that's bad, because
> > __radix_tree_lookup() dereferences that to test if it's populated
> > before returning it, and slot life-time is guaranteed by RCU.
> >
> > That would only leave garbage in the slot itself, crashing during
> > page_cache_get_speculative().
> >
> > I'll keep staring at this change, but nothing stands out to me yet.
>
> alright, it's pretty deterministic however. Always on the same test, no
> matter which USB controller, no matter if backing store is RAM or MMC.
>
> Those two undefined instructions on the disassembly caught my attention,
> perhaps I'm facing a GCC bug ?
no, probably not a GCC bug. Looking at your commit, however. Man, it
does quite many things at once. Moves code around, adds new functions by
refactoring (and changing) code, renames things, changes int offset into
unsigned ints. Should not be too difficult too to miss a bug in there.
I'll continue digging here.
--
balbi
Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)
Powered by blists - more mailing lists