On Thu, Mar 20, 2025 at 09:28:12PM -0700, Nhat Pham wrote: > On Wed, Mar 19, 2025 at 9:31 PM Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > > > > > > > > On Wed, Mar 12, 2025, at 9:52 PM, Chris Murphy wrote: > > > 6.14.0-0.rc6.49.fc42.x86_64+debug > > > swap is enabled using a swapfile on btrfs (which is also used for /) > > > zswap is enabled using zsmalloc/zstd > > > > > > Downstream bug report includes full dmesg.log attachment > > > https://bugzilla.redhat.com/show_bug.cgi?id=2351794 > > > > Also occurs with 6.14.0-0.rc7.56.fc42.x86_64 > > > > It's not reproducible in any way I'm aware of, but isn't uncommon. Updated bug report with rc7 dmesg. > > > > > > -- > > Chris Murphy > > > > Eyeballing the trace, this looks awfully similar to the problem that > Yosry was fixing here: > > https://lore.kernel.org/all/20250226185625.2672936-1-yosry.ahmed@xxxxxxxxx/ > > That should break the following link in the chain: > > &per_cpu_ptr(pool->acomp_ctx, cpu)->mutex --> scomp_lock > > since we release the first lock, before acquiring the second lock. > > I don't think this is in rc6 yet. Can you apply the patch and test again? Yeah I don't see it in any MM branches. I suspect it's because there were discussions about fixing this on the zswap side vs the crypto side. Although I mentioned that I prefer that we take the zswap fix anyway. Andrew, is it too late to squeeze that patch in? If it is, maybe we can just land it in v6.15 and backport it to v6.14 via stable.
