Subject: Re: [BUG -next] "memcg: charge before adding to swapcache on swapin" broken

From: Heiko Carstens <[email-masked]>
Date: Wed, 17 Mar 2021 22:11:02 +0100

On Wed, Mar 17, 2021 at 09:44:21PM +0100, Heiko Carstens wrote:
> On Wed, Mar 17, 2021 at 08:44:14AM -0700, Shakeel Butt wrote:
> > > Config below. And the fun thing is that I cannot reproduce it today
> > > anymore with the elfutils test case - what _seems_ to be different is
> > > that the test suite runs much faster than yesterday evening. Usually
> > > an indication that there is no steal time (other guests which steal
> > > cpu time), which again _could_ indicate a race / lack of locking
> > > somewhere.
> > > This is kind of odd, since yesterday evening it was very reliable to
> > > trigger the bug :/
> > >
> > 
> > Thanks for the config. One question regarding swap, is it disk based
> > swap or zram?
> 
> Swap device is a real disk.
> 
> > By guests, do you mean there was another significant workload running
> > on the machine in parallel to the tests?
> 
> That I don't know. I didn't check. I still can't reproduce with
> elfutils anymore, however...
> 
> > If you don't mind can you try swapping01 as well.
> 
> ltp's swapping01 test triggers immediately random processes being
> killed with SIGSEGV. I also tested with linux-next 20210316 and _only_
> "memcg: charge before adding to swapcache on swapin" being reverted on
> top, and the problem is away - so it looks like the result of
> yesterday's bisect is indeed valid.

I have to correct myself, actually the system has both: a real disk
_and_ zram as swap devices:

# swapon -s
Filename                                Type            Size    Used    Priority
/dev/dasdb1                             partition       21635084        0       -2
/dev/zram0                              partition       1014780 0       100

When I disable /dev/zram with "swapoff /dev/zram0" the problem is away
as well, even with your patch applied.