Re: [PATCH v7 0/2] mm/swap, PM: hibernate: fix swapoff race and optimize swap

[Andrew Morton <akpm@linux-foundation.org>]

On Sun, 22 Mar 2026 19:31:01 +0900 YoungJun Park <youngjun.park@lge.com> wrote:

> 1. Grab cont_lock on the SWP_HIBERNATION set path, or grab
>    swap_lock in add_swap_count_continuation(). This would
>    serialize the race, but adds lock contention on a path
>    that doesn't really need it.
> 
> 2. Convert si->flags to atomic ops. This would be the correct
>    fix, but is quite extensive and better suited as a separate
>    effort.
> 
> However, on mm-new, Kairui's series [1] has removed
> add_swap_count_continuation() and SWP_CONTINUED entirely, so
> this race path no longer exists (verified by code inspection
> and AI review on mm-new).
> 
> [1] https://lore.kernel.org/linux-mm/20260128-swap-table-p3-v2-9-fe0b67ef0215@tencent.com/
> 
> I based this series on v7.0-rc4 per Rafael's request since it
> depends on PM-side changes. I'm not very familiar with how
> cross-subsystem dependencies are typically coordinated -- if
> rebasing onto mm-new is an option, the race goes away and the
> PM-side changes could be picked up separately. Would that be
> a reasonable approach? I'd appreciate any guidance on this.

The kernel/power/ changes are small.  How about we prepare all this
against mm-new and ask Rafael for an ack?

> On a side note -- the AI review is becoming genuinely useful.
> It might be worth having it gate-check patches before they hit
> the mailing list, rather than reviewing after the fact.

Totally agree.  Problem is, these review are expensive and permitting
people to check their work before publishing could be terribly abused -
anyone in the world gets free patch review.  I don't think Google wants
to pay for that!

Hopefully over time, as engineers see the value in this tool they will
persuade their employers to purchase the tokens they need for such
screening work.