Re: zswap explosion when using zsmalloc pool compression

From: Mike Galbraith <efault@gmx.de>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: RT <linux-rt-users@vger.kernel.org>
Subject: Re: zswap explosion when using zsmalloc pool compression
Date: Thu, 03 Dec 2020 12:03:11 +0100	[thread overview]
Message-ID: <2b297170dbf98b36526f876650a2707e59d4ae92.camel@gmx.de> (raw)
In-Reply-To: <20201203094805.dhk3f7mlth3vm6ck@linutronix.de>

On Thu, 2020-12-03 at 10:48 +0100, Sebastian Andrzej Siewior wrote:
> On 2020-12-03 10:40:16 [+0100], Mike Galbraith wrote:
> > In thread "scheduling while atomic in z3fold", I mentioned that of the
> > three pool methods, only zbud did not explode.  Below is the explosion
> > encountered when zsmalloc is used in conjunction with runltp -f mm.  As
> > with the z3fold explosion, this one also seems to be highly repeatable,
> > this from one of my full distro "my box plays russian dolls [1]" KVMs.
>
> great.
>
> > [ 5763.720268] kernel BUG at kernel/locking/rtmutex.c:1057!
> …
> > [ 5763.726016] RAX: 00000000ffffffdd RBX: ffff903f77c68080 RCX: 0000000000000001
>
> That is a deadlock. Does lockdep say anything or does it disable the bug
> from happening?

The later, for the first time it did not explode.  However...

[  458.195604] BUG: spinlock bad magic on CPU#1, oom01/9449
[  458.195609]  lock: 0xffff980db7c69560, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
[  458.195613] CPU: 1 PID: 9449 Comm: oom01 Kdump: loaded Tainted: G            E     5.9.12-rt20-rt #19
[  458.195615] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba527-rebuilt.opensuse.org 04/01/2014
[  458.195616] Call Trace:
[  458.195617]  dump_stack+0x77/0x97
[  458.195633]  do_raw_spin_lock+0x71/0xc0
[  458.195644]  _raw_spin_lock_irqsave+0x45/0x50
[  458.195650]  ? rt_spin_lock_slowlock+0x3a/0x70
[  458.195652]  rt_spin_lock_slowlock+0x3a/0x70
[  458.195656]  rt_spin_lock+0x46/0xc0
[  458.195658]  ? zswap_frontswap_store+0x26e/0xa50
[  458.195665]  zswap_frontswap_store+0x26e/0xa50
[  458.195667]  ? rt_mutex_futex_unlock+0x56/0x80
[  458.195668]  __frontswap_store+0x6e/0x100
[  458.195670]  swap_writepage+0x37/0x70
[  458.195671]  shmem_writepage+0x267/0x400
[  458.195674]  pageout+0xd2/0x400
[  458.195677]  shrink_page_list+0xa6e/0xbd0
[  458.195679]  shrink_inactive_list+0x216/0x620
[  458.195683]  shrink_lruvec+0x39f/0x5e0
[  458.195689]  ? shrink_node+0x237/0x6e0
[  458.195694]  shrink_node+0x237/0x6e0
[  458.195697]  do_try_to_free_pages+0xb9/0x400
[  458.195698]  try_to_free_pages+0xe6/0x3b0
[  458.195701]  __alloc_pages_slowpath.constprop.108+0x3f8/0x1090
[  458.195705]  __alloc_pages_nodemask+0x3f6/0x480
[  458.195707]  alloc_pages_vma+0x135/0x190
[  458.195711]  handle_mm_fault+0x87c/0x16f0
[  458.195715]  ? lockdep_hardirqs_on+0x79/0x100
[  458.195718]  exc_page_fault+0x343/0x720
[  458.195720]  ? asm_exc_page_fault+0x1e/0x30
[  458.195722]  ? asm_exc_page_fault+0x8/0x30
[  458.195723]  asm_exc_page_fault+0x1e/0x30
[  458.195724] RIP: 0033:0x414300
[  458.195726] Code: e8 d5 f5 fe ff 48 83 f8 ff 0f 84 9c 00 00 00 41 83 fd 02 48 89 c5 74 32 41 83 fd 03 74 74 49 63 c4 48 89 ea 66 0f 1f 44 00 00 <c6> 02 07 48 01 c2 48 89 d1 48 29 e9 48 39 cb 7f ef 31 c0 48 83 c4
[  458.195730] RSP: 002b:00007f1e1d790ec0 EFLAGS: 00010206
[  458.195731] RAX: 0000000000001000 RBX: 00000000c0000000 RCX: 00000000416a8000
[  458.195731] RDX: 00007f1cdde38000 RSI: 00000000c0000000 RDI: 0000000000000000
[  458.195732] RBP: 00007f1c9c790000 R08: ffffffffffffffff R09: 0000000000000000
[  458.195732] R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000001000
[  458.195733] R13: 0000000000000001 R14: 0000000000000001 R15: 00007ffe1f97c860