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

[马超 <machao26@xiaomi.com>]

> 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!******/#