Re: [Kernel Bug] INFO: task hung in zswap_decompress

[Kanchana P. Sridhar]

On Tue, Jun 9, 2026 at 10:50 AM Yosry Ahmed <yosry@xxxxxxxxxx> wrote:
>
> On Tue, Jun 9, 2026 at 8:40 AM Nhat Pham <nphamcs@xxxxxxxxx> wrote:
> >
> > On Tue, Jun 9, 2026 at 4:51 AM Longxing Li <coregee2000@xxxxxxxxx> wrote:
> > >
> > > Dear Linux kernel developers and maintainers,
> > >
> > > We would like to report a new kernel bug found by our tool. INFO: task
> > > hung in zswap_decompress. Details are as follows.
> > >
> > > Kernel commit: v7.0.6
> > > Kernel config: see attachment
> > > report: see attachment
>
> If I am reading the report correctly, it seems like we are doing
> swapin from the page fault path, and waiting for the per-CPU mutex
> that is held by kswapd. Since we can sleep waiting for decompression
> while holding the mutex, it's possible that we have some kind of
> priority inversion where kswap held the lock, went to sleep, and
> didn't run again for a while. But that always been possible for a long
> time AFAICT.
>
> Do you have any more details? Is this a new regression (observed when
> upgrading to v7.0.6), or is it possible this was a pre-existing issue
> and you just found it on this kernel?
>
> > >
> > > We are currently analyzing the root cause and  working on a
> > > reproducible PoC. We will provide further updates in this thread as
> > > soon as we have more information.
>
> Yeah more details like a known-good kernel version, or even better a
> reproducer, would certainly help a lot.
>
> > >
> > > Best regards,
> > > Longxing Li
> > >
> > > ==================================================================
> > > https://drive.google.com/file/d/1Bx2unEf-QntjVi8g6Zw7QNO6OP4cjGO_/view?usp=drive_link
> > >
> > > https://drive.google.com/file/d/16xzUrwOvwE67cnMPH3AhhNRWq6hr26Qj/view?usp=drive_link
> >
> > + Kanchana, who last worked on this piece of code

Thanks Nhat and Yosry. I agree with Yosry, having a known-good kernel
version would be helpful.

Also, it appears the kernel stack-trace is from before the merging of
the per-CPU acomp_ctx simplifications wrt the mutex, and resources'
lifetime being tied to that of the zswap pool.

Looking forward to more details.

Thanks,
Kanchana