Re: [Bug 205937] New: BUG: unable to handle page fault for address: f3170000

[Roman Gushchin <guro@fb.com>]

On Thu, Dec 26, 2019 at 09:41:30PM +0000, Christopher Lameter wrote:
> On Mon, 23 Dec 2019, Andrew Morton wrote:
> 
> > Guys, did we make recent changes in this area?
> 
> Yes the cgroup folks did. f.e.
> 
> commit 04f768a39d55967246c002aa66b407b3bfdd8269
> Author: Waiman Long <longman@redhat.com>
> Date:   Mon Sep 23 15:33:46 2019 -0700
> 
>     mm, slab: extend slab/shrink to shrink all memcg caches

I'd be surprised if the issue is caused by using of this very
new interface. But it would be an easy thing...

> 
>     Currently, a value of '1" is written to /sys/kernel/slab/<slab>/shrink
>     file to shrink the slab by flushing out all the per-cpu slabs and free
>     slabs in partial lists.  This can be useful to squeeze out a bit more
>     memory under extreme condition as well as making the active object
> counts
>     in /proc/slabinfo more accurate.
> 
>     This usually applies only to the root caches, as the SLUB_ME
>

Otherwise I bet on some race around s->kobj.state_in_sysfs .
It interesting that it reproduces on a single cpu i386 machine.
I really wonder what makes it different.

Dennis, can you, please, insert some debug printing into
sysfs_slab_remove_workfn()? I wonder if it's really called twice
and where exactly it panics?

Thanks!