Re: [PATCH v5 0/3] Fix swapoff race and cleanup in hibernation swap path

[YoungJun Park <youngjun.park@lge.com>]

On Thu, Mar 19, 2026 at 07:50:32PM -0700, Andrew Morton wrote:
> On Thu, 19 Mar 2026 23:24:01 +0900 Youngjun Park <youngjun.park@lge.com> wrote:
> 
> > Currently, in the uswsusp path, only the swap type value is retrieved at
> > lookup time without holding a reference. If swapoff races after the type
> > is acquired, subsequent slot allocations operate on a stale swap device.
> > 
> > Additionally, grabbing and releasing the swap device reference on every
> > slot allocation is inefficient across the entire hibernation swap path.
> 
> AI review has questions:
> 	https://sashiko.dev/#/patchset/20260319142404.3683019-1-youngjun.park%40lge.com

Hi Andrew,

Thanks for sharing the AI review. Some comments are indeed good catches.

patch 2 comments are wrong.
patch 3 comments are right.

Regarding patch 2, the AI review raised the following concerns:

> If this race occurs, swapoff clears SWP_WRITEOK and calls try_to_unuse()
> to scan and evict swap slots. Without the SWP_WRITEOK check here, it
> looks like uswsusp could successfully allocate slots while
> try_to_unuse() is actively scanning.

Right. but..

> If try_to_unuse() encounters these newly allocated slots, wouldn't it
> attempt to page them in and subsequently free them via
> folio_free_swap()?

I believe this concern is not valid.

swapoff calls try_to_unuse(), which scans swap_map[] entries:
(this logic is slightly different from each kerenl version but, fundamental is same)
    ...
    for (i = prev + 1; i < si->max; i++) {
            count = READ_ONCE(si->swap_map[i]);
            if (count && swap_count(count) != SWAP_MAP_BAD)
                    break;
    }
    ...

However, hibernation allocations marked with SWAP_HAS_CACHE are not
visible via this swap_map[] scanning logic, so they cannot be found
or reclaimed in that path.

As a result swapoff keeps retrying while swap_usage_in_pages(si) is
non-zero until user signal is delivered., rather than freeing those entrie.

I will also verify this behavior at runtime to be absolutely sure.

For patch 3, I agree with the comment and have responded in Rafael’s
thread.

I will update the series shortly.

Thanks,
Youngjun Park