Re: Crash in -next due to 'MIPS: Add cacheinfo support'

[Guenter Roeck <linux@roeck-us.net>]

On Fri, Feb 10, 2017 at 10:39:32PM +0000, James Hogan wrote:
> > 
> > > and essentially Justin's commit just made problem 1) to occur, but is
> > > not the root cause of the crash you are seeing?
> > 
> > That would not necessarily be my conclusion. Of course, the code appears
> > to be heavily SMP related, so it may well be that it exposes some
> > problem associated with cache handling or support in non-SMP configurations.
> > 
> > Of course, it might also be possible that there is a qemu problem somewhere
> > which only manifests itself on non-SMP mips images with Justin's commit
> > applied. That appears to be somewhat unlikely, though I have no hard data
> > supporting this guess.
> > 
> > I'll do some more testing and try to find the actual crash location.
> > Tricky though since it almost looks like there is a not completely
> > initialized workqueue. Making things worse, the problem "goes away"
> > if I add some debug log into process_one_work(), meaning there may
> > be a heisenbug.
> 
> cracked it by moving around an early return error. populate_cache()
> macro has multiple statements with no do while (0) around it. The
> c->scache.waysize condition in populate_cache_leaves then only
> conditionalises the first statement in the macro and in absense of l2
> (or l3 for that matter) it'll continue to write beyond the end of the
> array allocated in detect_cache_attributes(). Badness ensues.
> 
Outch. Yes, after you mention it, the problem is easy to see.

> The SMP calls in arch/mips/kernel/cacheinfo.c file are pretty redundant
> too since all the cache info is read from the cpu info structures.
> 
> I'll write a patch. Thanks for reporting Guenter!
> 
Thank you for tracking it down!

Guenter