Re: zswap_writeback_entry crashes in 6.9.5

[Nhat Pham <nphamcs@gmail.com>]

On Sun, Jun 30, 2024 at 10:58 AM Pedro Falcato <pedro.falcato@gmail.com> wrote:
>
> Hi everyone,

Hi Pedro,

Thanks for the bug report! Taking a look now - some preliminary
questions to narrow down the suspects and aid the debugging process:

a) Do you observe this bug in 6.8? 6.10?

b) Have you run the faddr2line script to verify that the line that
triggers the crash is count_objcg_event(entry->objcg, ZSWPWB);?

c) Do you have a full dmesg log? Or maybe some other reproduction instructions?

If entry->objcg is garbage, then this smells like a lifetime/reference
counting issue. Either:

a) The zswap entry itself is garbage. Not impossible, but seems
unlikely. In 6.9, we effectively isolate the entry first through the
swap cache, then check and remove it from the zswap tree (under the
tree's lock). The former locks out concurrent accessors, and the
latter should have taken care of invalidated entries (and prevents
future invalidation attempts). Furthermore, after this, if the entry
is somehow garbage (i.e freed and recycled), it should also be
possible to blow up in the decompression step first, by feeding a
garbage handle to zsmalloc and crashing the kernel at that point. IOW,
we should also see zsmalloc crashes in addition to this particular
crash, no? I cannot think of any protection mechanism that applies to
the decompression step and not to count_objcg_event().

b) entry->objcg has been freed/recycled under us. This is much
trickier, as the culprit could be any holder of the objcg reference
who accidentally double-released the reference it held. That said, if
it only happened on zswap shrinker path, then maybe there is something
to this...

Let me muse on this a bit more. Please let us know if you have other
clues, traces, hints, or observation - it will help the investigation
a lot!