[PATCH 6.18.y] mm: shmem: fix potential livelock issue for shmem direct swapin

[PATCH 6.18.y] mm: shmem: fix potential livelock issue for shmem direct swapin

[Baolin Wang]

When skipping swapcache for synchronous IO swap devices, swapcache_prepare()
is used to prevent parallel swapin from proceeding with the swap cache flag.
However, on PREEMPT kernels this can lead to a livelock, as reported by Chao[1]:

Thread A starts direct swapin of a shmem folio and calls swapcache_prepare()
to set SWAP_HAS_CACHE. It may then be preempted inside workingset_refault().
Meanwhile, a higher priority thread B also attempts direct swapin of the same
shmem swap entry. Since swapcache_prepare() already marks the entry, thread B
repeatedly gets -EEXIST and busy-loops waiting for thread A to finish. But as
thread B runs at higher priority, thread A cannot preempt it, resulting in
starvation and a livelock.

Fix it by yielding the CPU with schedule_timeout_uninterruptible(1) when
swapcache_prepare() fails, following the same approach used in commits
029c4628b2eb ("mm: swap: get rid of livelock in swapin readahead") and
13ddaf26be32 ("mm/swap: fix race when skipping swapcache").

Note that mainline does not have this potential issue, which has already been
resolved by Kairui's swap refactoring work[2].

[1] https://lore.kernel.org/all/700a2cbf90a2484f979aac858f08f5d4@xiaomi.com/
[2] https://lore.kernel.org/all/20260517-swap-table-p4-v5-0-88ae43e064c7@tencent.com/
Fixes: 1dd44c0af4fa ("mm: shmem: skip swapcache for swapin of synchronous swap device")
Reported-by: Ma Chao <machao26@xiaomi.com>
Closes: https://lore.kernel.org/all/700a2cbf90a2484f979aac858f08f5d4@xiaomi.com/
Signed-off-by: Baolin Wang <baolin.wang@linux.alibaba.com>
---
Hi Chao, could you try this patch to check if it fixes your issue? Thanks.
---
 mm/shmem.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/mm/shmem.c b/mm/shmem.c
index 94c5b0d78ac3..d4cb57b3b0ef 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -2066,6 +2066,8 @@ static struct folio *shmem_swap_alloc_folio(struct inode *inode,
 	if (swapcache_prepare(entry, nr_pages)) {
 		folio_put(new);
 		new = ERR_PTR(-EEXIST);
+		/* Relax a bit to prevent rapid repeated page faults */
+		schedule_timeout_uninterruptible(1);
 		/* Try smaller folio to avoid cache conflict */
 		goto fallback;
 	}
-- 
2.47.3

Re: [PATCH 6.18.y] mm: shmem: fix potential livelock issue for shmem direct swapin

[Kairui Song]

On Mon, Jul 6, 2026 at 11:25 AM Baolin Wang
<baolin.wang@linux.alibaba.com> wrote:
>
> When skipping swapcache for synchronous IO swap devices, swapcache_prepare()
> is used to prevent parallel swapin from proceeding with the swap cache flag.
> However, on PREEMPT kernels this can lead to a livelock, as reported by Chao[1]:
>
> Thread A starts direct swapin of a shmem folio and calls swapcache_prepare()
> to set SWAP_HAS_CACHE. It may then be preempted inside workingset_refault().
> Meanwhile, a higher priority thread B also attempts direct swapin of the same
> shmem swap entry. Since swapcache_prepare() already marks the entry, thread B
> repeatedly gets -EEXIST and busy-loops waiting for thread A to finish. But as
> thread B runs at higher priority, thread A cannot preempt it, resulting in
> starvation and a livelock.
>
> Fix it by yielding the CPU with schedule_timeout_uninterruptible(1) when
> swapcache_prepare() fails, following the same approach used in commits
> 029c4628b2eb ("mm: swap: get rid of livelock in swapin readahead") and
> 13ddaf26be32 ("mm/swap: fix race when skipping swapcache").
>
> Note that mainline does not have this potential issue, which has already been
> resolved by Kairui's swap refactoring work[2].
>
> [1] https://lore.kernel.org/all/700a2cbf90a2484f979aac858f08f5d4@xiaomi.com/
> [2] https://lore.kernel.org/all/20260517-swap-table-p4-v5-0-88ae43e064c7@tencent.com/
> Fixes: 1dd44c0af4fa ("mm: shmem: skip swapcache for swapin of synchronous swap device")
> Reported-by: Ma Chao <machao26@xiaomi.com>
> Closes: https://lore.kernel.org/all/700a2cbf90a2484f979aac858f08f5d4@xiaomi.com/
> Signed-off-by: Baolin Wang <baolin.wang@linux.alibaba.com>
> ---
> Hi Chao, could you try this patch to check if it fixes your issue? Thanks.
> ---
>  mm/shmem.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/mm/shmem.c b/mm/shmem.c
> index 94c5b0d78ac3..d4cb57b3b0ef 100644
> --- a/mm/shmem.c
> +++ b/mm/shmem.c
> @@ -2066,6 +2066,8 @@ static struct folio *shmem_swap_alloc_folio(struct inode *inode,
>         if (swapcache_prepare(entry, nr_pages)) {
>                 folio_put(new);
>                 new = ERR_PTR(-EEXIST);
> +               /* Relax a bit to prevent rapid repeated page faults */
> +               schedule_timeout_uninterruptible(1);
>                 /* Try smaller folio to avoid cache conflict */
>                 goto fallback;
>         }
> --
> 2.47.3
>

Thanks! That's much more simpler than I expected. Do we need a wakeup
queue like the one in commit 01626a1823024? Perhaps the reporter can
help confirm and test? I personally prefer to keep it simple if shmem
users aren't as sensitive as anon users.

Re: [PATCH 6.18.y] mm: shmem: fix potential livelock issue for shmem direct swapin

[Baolin Wang]

On 7/6/26 1:59 PM, Kairui Song wrote:
> On Mon, Jul 6, 2026 at 11:25 AM Baolin Wang
> <baolin.wang@linux.alibaba.com> wrote:
>>
>> When skipping swapcache for synchronous IO swap devices, swapcache_prepare()
>> is used to prevent parallel swapin from proceeding with the swap cache flag.
>> However, on PREEMPT kernels this can lead to a livelock, as reported by Chao[1]:
>>
>> Thread A starts direct swapin of a shmem folio and calls swapcache_prepare()
>> to set SWAP_HAS_CACHE. It may then be preempted inside workingset_refault().
>> Meanwhile, a higher priority thread B also attempts direct swapin of the same
>> shmem swap entry. Since swapcache_prepare() already marks the entry, thread B
>> repeatedly gets -EEXIST and busy-loops waiting for thread A to finish. But as
>> thread B runs at higher priority, thread A cannot preempt it, resulting in
>> starvation and a livelock.
>>
>> Fix it by yielding the CPU with schedule_timeout_uninterruptible(1) when
>> swapcache_prepare() fails, following the same approach used in commits
>> 029c4628b2eb ("mm: swap: get rid of livelock in swapin readahead") and
>> 13ddaf26be32 ("mm/swap: fix race when skipping swapcache").
>>
>> Note that mainline does not have this potential issue, which has already been
>> resolved by Kairui's swap refactoring work[2].
>>
>> [1] https://lore.kernel.org/all/700a2cbf90a2484f979aac858f08f5d4@xiaomi.com/
>> [2] https://lore.kernel.org/all/20260517-swap-table-p4-v5-0-88ae43e064c7@tencent.com/
>> Fixes: 1dd44c0af4fa ("mm: shmem: skip swapcache for swapin of synchronous swap device")
>> Reported-by: Ma Chao <machao26@xiaomi.com>
>> Closes: https://lore.kernel.org/all/700a2cbf90a2484f979aac858f08f5d4@xiaomi.com/
>> Signed-off-by: Baolin Wang <baolin.wang@linux.alibaba.com>
>> ---
>> Hi Chao, could you try this patch to check if it fixes your issue? Thanks.
>> ---
>>   mm/shmem.c | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/mm/shmem.c b/mm/shmem.c
>> index 94c5b0d78ac3..d4cb57b3b0ef 100644
>> --- a/mm/shmem.c
>> +++ b/mm/shmem.c
>> @@ -2066,6 +2066,8 @@ static struct folio *shmem_swap_alloc_folio(struct inode *inode,
>>          if (swapcache_prepare(entry, nr_pages)) {
>>                  folio_put(new);
>>                  new = ERR_PTR(-EEXIST);
>> +               /* Relax a bit to prevent rapid repeated page faults */
>> +               schedule_timeout_uninterruptible(1);
>>                  /* Try smaller folio to avoid cache conflict */
>>                  goto fallback;
>>          }
>> --
>> 2.47.3
>>
> 
> Thanks! That's much more simpler than I expected. Do we need a wakeup
> queue like the one in commit 01626a1823024? Perhaps the reporter can
> help confirm and test? I personally prefer to keep it simple if shmem
> users aren't as sensitive as anon users.

I agree. I'd like to keep the bugfix as simple as possible, if the 
reporter's scenario isn't latency-sensitive.

Re: [PATCH 6.18.y] mm: shmem: fix potential livelock issue for shmem direct swapin

[Barry Song]

On Mon, Jul 6, 2026 at 8:08 PM Baolin Wang
<baolin.wang@linux.alibaba.com> wrote:
>
>
>
> On 7/6/26 1:59 PM, Kairui Song wrote:
> > On Mon, Jul 6, 2026 at 11:25 AM Baolin Wang
> > <baolin.wang@linux.alibaba.com> wrote:
> >>
> >> When skipping swapcache for synchronous IO swap devices, swapcache_prepare()
> >> is used to prevent parallel swapin from proceeding with the swap cache flag.
> >> However, on PREEMPT kernels this can lead to a livelock, as reported by Chao[1]:
> >>
> >> Thread A starts direct swapin of a shmem folio and calls swapcache_prepare()
> >> to set SWAP_HAS_CACHE. It may then be preempted inside workingset_refault().
> >> Meanwhile, a higher priority thread B also attempts direct swapin of the same
> >> shmem swap entry. Since swapcache_prepare() already marks the entry, thread B
> >> repeatedly gets -EEXIST and busy-loops waiting for thread A to finish. But as
> >> thread B runs at higher priority, thread A cannot preempt it, resulting in
> >> starvation and a livelock.
> >>
> >> Fix it by yielding the CPU with schedule_timeout_uninterruptible(1) when
> >> swapcache_prepare() fails, following the same approach used in commits
> >> 029c4628b2eb ("mm: swap: get rid of livelock in swapin readahead") and
> >> 13ddaf26be32 ("mm/swap: fix race when skipping swapcache").
> >>
> >> Note that mainline does not have this potential issue, which has already been
> >> resolved by Kairui's swap refactoring work[2].
> >>
> >> [1] https://lore.kernel.org/all/700a2cbf90a2484f979aac858f08f5d4@xiaomi.com/
> >> [2] https://lore.kernel.org/all/20260517-swap-table-p4-v5-0-88ae43e064c7@tencent.com/
> >> Fixes: 1dd44c0af4fa ("mm: shmem: skip swapcache for swapin of synchronous swap device")
> >> Reported-by: Ma Chao <machao26@xiaomi.com>
> >> Closes: https://lore.kernel.org/all/700a2cbf90a2484f979aac858f08f5d4@xiaomi.com/
> >> Signed-off-by: Baolin Wang <baolin.wang@linux.alibaba.com>
> >> ---
> >> Hi Chao, could you try this patch to check if it fixes your issue? Thanks.
> >> ---
> >>   mm/shmem.c | 2 ++
> >>   1 file changed, 2 insertions(+)
> >>
> >> diff --git a/mm/shmem.c b/mm/shmem.c
> >> index 94c5b0d78ac3..d4cb57b3b0ef 100644
> >> --- a/mm/shmem.c
> >> +++ b/mm/shmem.c
> >> @@ -2066,6 +2066,8 @@ static struct folio *shmem_swap_alloc_folio(struct inode *inode,
> >>          if (swapcache_prepare(entry, nr_pages)) {
> >>                  folio_put(new);
> >>                  new = ERR_PTR(-EEXIST);
> >> +               /* Relax a bit to prevent rapid repeated page faults */
> >> +               schedule_timeout_uninterruptible(1);
> >>                  /* Try smaller folio to avoid cache conflict */
> >>                  goto fallback;
> >>          }
> >> --
> >> 2.47.3
> >>
> >
> > Thanks! That's much more simpler than I expected. Do we need a wakeup
> > queue like the one in commit 01626a1823024? Perhaps the reporter can
> > help confirm and test? I personally prefer to keep it simple if shmem
> > users aren't as sensitive as anon users.
>
> I agree. I'd like to keep the bugfix as simple as possible, if the
> reporter's scenario isn't latency-sensitive.

On Android, we don't see much shmem; it's much less common
than anon. So the chance of this concurrency happening should
be lower than for anon. However, shmem can be shared by
multiple processes, so could this still happen if process A is
blocked by process B?

I'm not really sure. Only large-scale data can tell. :-)

Re: [PATCH 6.18.y] mm: shmem: fix potential livelock issue for shmem direct swapin

[Baolin Wang]

On 7/6/26 9:04 PM, Barry Song wrote:
> On Mon, Jul 6, 2026 at 8:08 PM Baolin Wang
> <baolin.wang@linux.alibaba.com> wrote:
>>
>>
>>
>> On 7/6/26 1:59 PM, Kairui Song wrote:
>>> On Mon, Jul 6, 2026 at 11:25 AM Baolin Wang
>>> <baolin.wang@linux.alibaba.com> wrote:
>>>>
>>>> When skipping swapcache for synchronous IO swap devices, swapcache_prepare()
>>>> is used to prevent parallel swapin from proceeding with the swap cache flag.
>>>> However, on PREEMPT kernels this can lead to a livelock, as reported by Chao[1]:
>>>>
>>>> Thread A starts direct swapin of a shmem folio and calls swapcache_prepare()
>>>> to set SWAP_HAS_CACHE. It may then be preempted inside workingset_refault().
>>>> Meanwhile, a higher priority thread B also attempts direct swapin of the same
>>>> shmem swap entry. Since swapcache_prepare() already marks the entry, thread B
>>>> repeatedly gets -EEXIST and busy-loops waiting for thread A to finish. But as
>>>> thread B runs at higher priority, thread A cannot preempt it, resulting in
>>>> starvation and a livelock.
>>>>
>>>> Fix it by yielding the CPU with schedule_timeout_uninterruptible(1) when
>>>> swapcache_prepare() fails, following the same approach used in commits
>>>> 029c4628b2eb ("mm: swap: get rid of livelock in swapin readahead") and
>>>> 13ddaf26be32 ("mm/swap: fix race when skipping swapcache").
>>>>
>>>> Note that mainline does not have this potential issue, which has already been
>>>> resolved by Kairui's swap refactoring work[2].
>>>>
>>>> [1] https://lore.kernel.org/all/700a2cbf90a2484f979aac858f08f5d4@xiaomi.com/
>>>> [2] https://lore.kernel.org/all/20260517-swap-table-p4-v5-0-88ae43e064c7@tencent.com/
>>>> Fixes: 1dd44c0af4fa ("mm: shmem: skip swapcache for swapin of synchronous swap device")
>>>> Reported-by: Ma Chao <machao26@xiaomi.com>
>>>> Closes: https://lore.kernel.org/all/700a2cbf90a2484f979aac858f08f5d4@xiaomi.com/
>>>> Signed-off-by: Baolin Wang <baolin.wang@linux.alibaba.com>
>>>> ---
>>>> Hi Chao, could you try this patch to check if it fixes your issue? Thanks.
>>>> ---
>>>>    mm/shmem.c | 2 ++
>>>>    1 file changed, 2 insertions(+)
>>>>
>>>> diff --git a/mm/shmem.c b/mm/shmem.c
>>>> index 94c5b0d78ac3..d4cb57b3b0ef 100644
>>>> --- a/mm/shmem.c
>>>> +++ b/mm/shmem.c
>>>> @@ -2066,6 +2066,8 @@ static struct folio *shmem_swap_alloc_folio(struct inode *inode,
>>>>           if (swapcache_prepare(entry, nr_pages)) {
>>>>                   folio_put(new);
>>>>                   new = ERR_PTR(-EEXIST);
>>>> +               /* Relax a bit to prevent rapid repeated page faults */
>>>> +               schedule_timeout_uninterruptible(1);
>>>>                   /* Try smaller folio to avoid cache conflict */
>>>>                   goto fallback;
>>>>           }
>>>> --
>>>> 2.47.3
>>>>
>>>
>>> Thanks! That's much more simpler than I expected. Do we need a wakeup
>>> queue like the one in commit 01626a1823024? Perhaps the reporter can
>>> help confirm and test? I personally prefer to keep it simple if shmem
>>> users aren't as sensitive as anon users.
>>
>> I agree. I'd like to keep the bugfix as simple as possible, if the
>> reporter's scenario isn't latency-sensitive.
> 
> On Android, we don't see much shmem; it's much less common
> than anon. So the chance of this concurrency happening should
> be lower than for anon. However, shmem can be shared by
> multiple processes, so could this still happen if process A is
> blocked by process B?

Could you be more specific about how that happens? I think we should fix 
this starvation/livelock issue if you think it could still happen.

回复: [External Mail]Re: [PATCH 6.18.y] mm: shmem: fix potential livelock issue for shmem direct swapin

[马超]

> On 7/6/26 1:59 PM, Kairui Song wrote:
>> On Mon, Jul 6, 2026 at 11:25 AM Baolin Wang
>> <baolin.wang@linux.alibaba.com> wrote:
>>>
>>> When skipping swapcache for synchronous IO swap devices,
>>> swapcache_prepare() is used to prevent parallel swapin from proceeding with the swap cache flag.
>>> However, on PREEMPT kernels this can lead to a livelock, as reported by Chao[1]:
>>>
>>> Thread A starts direct swapin of a shmem folio and calls
>>> swapcache_prepare() to set SWAP_HAS_CACHE. It may then be preempted inside workingset_refault().
>>> Meanwhile, a higher priority thread B also attempts direct swapin of
>>> the same shmem swap entry. Since swapcache_prepare() already marks
>>> the entry, thread B repeatedly gets -EEXIST and busy-loops waiting
>>> for thread A to finish. But as thread B runs at higher priority,
>>> thread A cannot preempt it, resulting in starvation and a livelock.
>>>
>>> Fix it by yielding the CPU with schedule_timeout_uninterruptible(1)
>>> when
>>> swapcache_prepare() fails, following the same approach used in
>>> commits 029c4628b2eb ("mm: swap: get rid of livelock in swapin
>>> readahead") and
>>> 13ddaf26be32 ("mm/swap: fix race when skipping swapcache").
>>>
>>> Note that mainline does not have this potential issue, which has
>>> already been resolved by Kairui's swap refactoring work[2].
>>>
>>> [1]
>>> https://lore.kernel.org/all/700a2cbf90a2484f979aac858f08f5d4@xiaomi.c
>>> om/ [2]
>>> https://lore.kernel.org/all/20260517-swap-table-p4-v5-0-88ae43e064c7@
>>> tencent.com/
>>> Fixes: 1dd44c0af4fa ("mm: shmem: skip swapcache for swapin of
>>> synchronous swap device")
>>> Reported-by: Ma Chao <machao26@xiaomi.com>
>>> Closes:
>>> https://lore.kernel.org/all/700a2cbf90a2484f979aac858f08f5d4@xiaomi.c
>>> om/
>>> Signed-off-by: Baolin Wang <baolin.wang@linux.alibaba.com>
>>> ---
>>> Hi Chao, could you try this patch to check if it fixes your issue? Thanks.
>>> ---
>>>   mm/shmem.c | 2 ++
>>>   1 file changed, 2 insertions(+)
>>>
>>> diff --git a/mm/shmem.c b/mm/shmem.c
>>> index 94c5b0d78ac3..d4cb57b3b0ef 100644
>>> --- a/mm/shmem.c
>>> +++ b/mm/shmem.c
>>> @@ -2066,6 +2066,8 @@ static struct folio *shmem_swap_alloc_folio(struct inode *inode,
>>>          if (swapcache_prepare(entry, nr_pages)) {
>>>                  folio_put(new);
>>>                  new = ERR_PTR(-EEXIST);
>>> +               /* Relax a bit to prevent rapid repeated page faults */
>>> +               schedule_timeout_uninterruptible(1);
>>>                  /* Try smaller folio to avoid cache conflict */
>>>                  goto fallback;
>>>          }
>>> --
>>> 2.47.3
>>>
>>
>> Thanks! That's much more simpler than I expected. Do we need a wakeup
>> queue like the one in commit 01626a1823024? Perhaps the reporter can
>> help confirm and test? I personally prefer to keep it simple if shmem
>> users aren't as sensitive as anon users.
>
> I agree. I'd like to keep the bugfix as simple as possible, if the reporter's scenario isn't latency-sensitive.

Thanks for your analysis and the provided fix patch. I will test and verify it. By the way, when is the fix patch expected to be merged into the kernel?
#/******本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ This e-mail and its attachments contain confidential information from XIAOMI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!******/#