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

[Shakeel Butt <shakeelb@google.com>]

CC: Minchan

On Wed, Mar 17, 2021 at 2:39 PM Shakeel Butt <shakeelb@google.com> wrote:
>
> On Wed, Mar 17, 2021 at 2:11 PM Heiko Carstens <hca@linux.ibm.com> wrote:
> >
> > 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.
>
> Thanks a lot. This was really helpful. I will try with zram on my setup.
>
> Can you also try with just one type of swap at the time for both? I
> really appreciate your help.

Never mind I think I found the issue. Can you please add
set_page_private(page, entry.val) before swap_readpage(page, true) in
function do_swap_page() in mm/memory.c and try the swapping01 test
again?

Michan, for SWP_SYNCHRONOUS_IO swap, do we ever reset page->private?
Normally for swapcache pages, it gets reset on delete from swap cache
but these types of swap skips swapcache, so, I think we never reset
page->private.

The simplest solution I can think of is to do set_page_private(page,
entry.val) before swap_readpage(page, true) and set_page_private(page,
0) after.