linux-kernel - Re: [PATCH RESEND 2/2] mm: zswap: use SRCU to synchronize with CPU hotunplug

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAKEwX=PdNo-Me1GL760PhaWR0QRdqhWF0tm33KHCU3qubsp+hQ@mail.gmail.com>
Date: Wed, 8 Jan 2025 11:34:38 +0700
From: Nhat Pham <nphamcs@...il.com>
To: Yosry Ahmed <yosryahmed@...gle.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>, Johannes Weiner <hannes@...xchg.org>, 
	Chengming Zhou <chengming.zhou@...ux.dev>, Vitaly Wool <vitalywool@...il.com>, 
	Barry Song <baohua@...nel.org>, Sam Sun <samsun1006219@...il.com>, linux-mm@...ck.org, 
	linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH RESEND 2/2] mm: zswap: use SRCU to synchronize with CPU hotunplug

On Wed, Jan 8, 2025 at 11:14 AM Yosry Ahmed <yosryahmed@...gle.com> wrote:
>
> On Tue, Jan 7, 2025 at 7:56 PM Nhat Pham <nphamcs@...il.com> wrote:
>
> I may have found a simpler "proper" fix than disabling migration,
> please see my suggestion in:
> https://lore.kernel.org/lkml/CAJD7tkYpNNsbTZZqFoRh-FkXDgxONZEUPKk1YQv7-TFMWWQRzQ@mail.gmail.com/

Discovered that thread just now - sorry, too many emails to catch up
on :) Taking a look now.

>
> >
> > Is this a frequently occured problem in the wild? If so, we can
> > disable migration to firefight, and then do the proper thing down the
> > line.
>
> I don't believe so. Actually, I think the deadlock introduced by the
> previous fix is more problematic than the UAF it fixes.
>
> Andrew, could you please pick up patch 1 (the revert) while we figure
> out the alternative fix? It's important that it lands in v6.13 to
> avoid the possibility of deadlock. Figuring out an alternative fix is
> less important.

Agree. Let's revert the "fix" first. CPU offlining is a much rarer
event than this deadlocking scenario discovered by syzbot.