linux-kernel - Re: [PATCH 0/9] mm, swap: introduce swap table as swap cache (phase I)

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAMgjq7Bv99OHvbEiDcEMVYS5bRdSgSu75a8YUEQ+3roLiOo=ug@mail.gmail.com>
Date: Fri, 5 Sep 2025 00:36:15 +0800
From: Kairui Song <ryncsn@...il.com>
To: Chris Li <chrisl@...nel.org>
Cc: linux-mm@...ck.org, Andrew Morton <akpm@...ux-foundation.org>, 
	Matthew Wilcox <willy@...radead.org>, Hugh Dickins <hughd@...gle.com>, Barry Song <baohua@...nel.org>, 
	Baoquan He <bhe@...hat.com>, Nhat Pham <nphamcs@...il.com>, 
	Kemeng Shi <shikemeng@...weicloud.com>, Baolin Wang <baolin.wang@...ux.alibaba.com>, 
	Ying Huang <ying.huang@...ux.alibaba.com>, Johannes Weiner <hannes@...xchg.org>, 
	David Hildenbrand <david@...hat.com>, Yosry Ahmed <yosryahmed@...gle.com>, 
	Lorenzo Stoakes <lorenzo.stoakes@...cle.com>, Zi Yan <ziy@...dia.com>, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/9] mm, swap: introduce swap table as swap cache (phase I)

On Sat, Aug 30, 2025 at 2:57 PM Chris Li <chrisl@...nel.org> wrote:
>
> Hi Kairui,
>
> I give one pass of review on your series already. I Ack a portion of
> it. I expect some clarification or update on the rest.
>
> I especially want to double check the swap cache atomic set a range of
> swap entries to folio.
> I want to make sure this bug does not happen to swap table:
> https://lore.kernel.org/linux-mm/5bee194c-9cd3-47e7-919b-9f352441f855@kernel.dk/
>
> I just double checked, the swap table should be fine in this regard.
> The bug is triggered by memory allocation failure in the middle of
> insert folio. Swap tables already populated the table when the swap
> entry is allocated and handed out to the caller. We don't do memory
> allocation when inserting folio into swap cache, which is a good
> thing. We should not have that bug.
>
> I also want some extra pair of eyes on those subtle behavior change
> patches, I expect you to split them out in the next version.
> I will need to go through the split out subtle patch one more time as
> well. This pass I only catch the behavior change, haven't got a chance
> to reason those behavior changes patches are indeed fine. If you can
> defer those split out patches, that will save me some time to reason
> them on the next round. Your call.

Thanks a lot for the review and raising concern about robustness of phase 1.

I just added more atomic runtime checks and ran another few days of
stress and performance tests. So far I don't think there is a race or
bug in the code, as I have been testing the longer series for months.
But with more checks, we are still a lot faster than before, and much
less error prone. So it seems very reasonable and acceptable to have
them as this is a quite important part, even for a long term.

That will surely help catch any potential new or historical issue.

V2 would have a few more patches splitted from old ones so it should
be cleaner. The code should be basically still the same though. Some
parts like the whole new infrastructure are really hard to split though
as they are supposed to work as a whole.

>
> Oh, I also want to write a design document for the swap table idea. I
> will send it your way to incorporate into your next version of the
> series.
>
> Thanks for the great work! I am very excited about this.

Later phases will also be exciting where we start to trim down the LOC
and long existing issues, with net gains :)