* [PATCH 6.18.y v2] mm: shmem: fix potential livelock issue for shmem direct swapin
@ 2026-07-10 2:09 Baolin Wang
2026-07-10 9:15 ` Barry Song
2026-07-13 11:55 ` 回复: [External Mail][PATCH " 马超
0 siblings, 2 replies; 6+ messages in thread
From: Baolin Wang @ 2026-07-10 2:09 UTC (permalink / raw)
To: akpm, hughd, stable
Cc: kasong, baohua, machao26, baolin.wang, linux-mm, linux-kernel
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 commit
029c4628b2eb ("mm: swap: get rid of livelock in swapin readahead") and
commit 13ddaf26be32 ("mm/swap: fix race when skipping swapcache").
However, commit 01626a1823 ("mm: avoid unconditional one-tick sleep when
swapcache_prepare fails") found that the unconditional one-tick sleep can
cause UI stuttering on latency-sensitive Android devices. So we can follow
the same approach by adding a waitqueue to wake up tasks when needed,
instead of always sleeping for a full tick.
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>
---
Changes from v1:
- Add a waitqueue to wake up tasks when needed.
Hi Chao, could you try this patch to check if fix your issue? Thanks.
---
mm/shmem.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/mm/shmem.c b/mm/shmem.c
index 94c5b0d78ac3..3c329b794ae4 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -2005,11 +2005,14 @@ static struct folio *shmem_alloc_and_add_folio(struct vm_fault *vmf,
return ERR_PTR(error);
}
+static DECLARE_WAIT_QUEUE_HEAD(shmem_swapcache_wq);
+
static struct folio *shmem_swap_alloc_folio(struct inode *inode,
struct vm_area_struct *vma, pgoff_t index,
swp_entry_t entry, int order, gfp_t gfp)
{
struct shmem_inode_info *info = SHMEM_I(inode);
+ DECLARE_WAITQUEUE(wait, current);
int nr_pages = 1 << order;
struct folio *new;
gfp_t alloc_gfp;
@@ -2066,6 +2069,10 @@ 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 */
+ add_wait_queue(&shmem_swapcache_wq, &wait);
+ schedule_timeout_uninterruptible(1);
+ remove_wait_queue(&shmem_swapcache_wq, &wait);
/* Try smaller folio to avoid cache conflict */
goto fallback;
}
@@ -2423,6 +2430,8 @@ static int shmem_swapin_folio(struct inode *inode, pgoff_t index,
if (skip_swapcache) {
folio->swap.val = 0;
swapcache_clear(si, swap, nr_pages);
+ if (waitqueue_active(&shmem_swapcache_wq))
+ wake_up(&shmem_swapcache_wq);
} else {
swap_cache_del_folio(folio);
}
@@ -2442,8 +2451,11 @@ static int shmem_swapin_folio(struct inode *inode, pgoff_t index,
if (folio)
folio_unlock(folio);
failed_nolock:
- if (skip_swapcache)
+ if (skip_swapcache) {
swapcache_clear(si, folio->swap, folio_nr_pages(folio));
+ if (waitqueue_active(&shmem_swapcache_wq))
+ wake_up(&shmem_swapcache_wq);
+ }
if (folio)
folio_put(folio);
put_swap_device(si);
--
2.47.3
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH 6.18.y v2] mm: shmem: fix potential livelock issue for shmem direct swapin
2026-07-10 2:09 [PATCH 6.18.y v2] mm: shmem: fix potential livelock issue for shmem direct swapin Baolin Wang
@ 2026-07-10 9:15 ` Barry Song
2026-07-13 11:55 ` 回复: [External Mail][PATCH " 马超
1 sibling, 0 replies; 6+ messages in thread
From: Barry Song @ 2026-07-10 9:15 UTC (permalink / raw)
To: Baolin Wang; +Cc: akpm, hughd, stable, kasong, machao26, linux-mm, linux-kernel
On Fri, Jul 10, 2026 at 10:09 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 commit
> 029c4628b2eb ("mm: swap: get rid of livelock in swapin readahead") and
> commit 13ddaf26be32 ("mm/swap: fix race when skipping swapcache").
>
> However, commit 01626a1823 ("mm: avoid unconditional one-tick sleep when
> swapcache_prepare fails") found that the unconditional one-tick sleep can
> cause UI stuttering on latency-sensitive Android devices. So we can follow
> the same approach by adding a waitqueue to wake up tasks when needed,
> instead of always sleeping for a full tick.
>
> 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>
> ---
LGTM,
Acked-by: Barry Song <baohua@kernel.org>
^ permalink raw reply [flat|nested] 6+ messages in thread
* 回复: [External Mail][PATCH 6.18.y v2] mm: shmem: fix potential livelock issue for shmem direct swapin
2026-07-10 2:09 [PATCH 6.18.y v2] mm: shmem: fix potential livelock issue for shmem direct swapin Baolin Wang
2026-07-10 9:15 ` Barry Song
@ 2026-07-13 11:55 ` 马超
2026-07-14 2:34 ` Baolin Wang
1 sibling, 1 reply; 6+ messages in thread
From: 马超 @ 2026-07-13 11:55 UTC (permalink / raw)
To: Baolin Wang, akpm@linux-foundation.org, hughd@google.com,
stable@vger.kernel.org
Cc: kasong@tencent.com, baohua@kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, 田孝斌,
俞东斌, 李鹏程
>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 commit 029c4628b2eb ("mm: swap: get rid of livelock in swapin readahead") and commit 13ddaf26be32 ("mm/swap: fix race when skipping swapcache").
>
>However, commit 01626a1823 ("mm: avoid unconditional one-tick sleep when swapcache_prepare fails") found that the unconditional one-tick sleep can cause UI stuttering on latency-sensitive Android devices. So we can follow the same approach by adding a waitqueue to wake up tasks when needed, instead of always sleeping for a full tick.
>
>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>
>---
>Changes from v1:
> - Add a waitqueue to wake up tasks when needed.
>
>Hi Chao, could you try this patch to check if fix your issue? Thanks.
>---
> mm/shmem.c | 14 +++++++++++++-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
>diff --git a/mm/shmem.c b/mm/shmem.c
>index 94c5b0d78ac3..3c329b794ae4 100644
>--- a/mm/shmem.c
>+++ b/mm/shmem.c
>@@ -2005,11 +2005,14 @@ static struct folio *shmem_alloc_and_add_folio(struct vm_fault *vmf,
> return ERR_PTR(error);
> }
>
>+static DECLARE_WAIT_QUEUE_HEAD(shmem_swapcache_wq);
>+
> static struct folio *shmem_swap_alloc_folio(struct inode *inode,
> struct vm_area_struct *vma, pgoff_t index,
> swp_entry_t entry, int order, gfp_t gfp) {
> struct shmem_inode_info *info = SHMEM_I(inode);
>+ DECLARE_WAITQUEUE(wait, current);
> int nr_pages = 1 << order;
> struct folio *new;
> gfp_t alloc_gfp;
>@@ -2066,6 +2069,10 @@ 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 */
>+ add_wait_queue(&shmem_swapcache_wq, &wait);
>+ schedule_timeout_uninterruptible(1);
>+ remove_wait_queue(&shmem_swapcache_wq, &wait);
> /* Try smaller folio to avoid cache conflict */
> goto fallback;
> }
>@@ -2423,6 +2430,8 @@ static int shmem_swapin_folio(struct inode *inode, pgoff_t index,
> if (skip_swapcache) {
> folio->swap.val = 0;
> swapcache_clear(si, swap, nr_pages);
>+ if (waitqueue_active(&shmem_swapcache_wq))
>+ wake_up(&shmem_swapcache_wq);
> } else {
> swap_cache_del_folio(folio);
> }
>@@ -2442,8 +2451,11 @@ static int shmem_swapin_folio(struct inode *inode, pgoff_t index,
> if (folio)
> folio_unlock(folio);
> failed_nolock:
>- if (skip_swapcache)
>+ if (skip_swapcache) {
> swapcache_clear(si, folio->swap, folio_nr_pages(folio));
>+ if (waitqueue_active(&shmem_swapcache_wq))
>+ wake_up(&shmem_swapcache_wq);
>+ }
> if (folio)
> folio_put(folio);
> put_swap_device(si);
>--
>2.47.3
We have conducted stress tests on over 10 pcs for 40 hours each, and no relevant issues have been reproduced.
#/******本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ 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!******/#
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: 回复: [External Mail][PATCH 6.18.y v2] mm: shmem: fix potential livelock issue for shmem direct swapin
2026-07-13 11:55 ` 回复: [External Mail][PATCH " 马超
@ 2026-07-14 2:34 ` Baolin Wang
2026-07-14 6:05 ` 回复: " 马超
0 siblings, 1 reply; 6+ messages in thread
From: Baolin Wang @ 2026-07-14 2:34 UTC (permalink / raw)
To: 马超, akpm@linux-foundation.org, hughd@google.com,
stable@vger.kernel.org
Cc: kasong@tencent.com, baohua@kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, 田孝斌,
俞东斌, 李鹏程
On 7/13/26 7:55 PM, 马超 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 commit 029c4628b2eb ("mm: swap: get rid of livelock in swapin readahead") and commit 13ddaf26be32 ("mm/swap: fix race when skipping swapcache").
>>
>> However, commit 01626a1823 ("mm: avoid unconditional one-tick sleep when swapcache_prepare fails") found that the unconditional one-tick sleep can cause UI stuttering on latency-sensitive Android devices. So we can follow the same approach by adding a waitqueue to wake up tasks when needed, instead of always sleeping for a full tick.
>>
>> 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>
>> ---
>> Changes from v1:
>> - Add a waitqueue to wake up tasks when needed.
>>
>> Hi Chao, could you try this patch to check if fix your issue? Thanks.
>> ---
>> mm/shmem.c | 14 +++++++++++++-
>> 1 file changed, 13 insertions(+), 1 deletion(-)
>>
>> diff --git a/mm/shmem.c b/mm/shmem.c
>> index 94c5b0d78ac3..3c329b794ae4 100644
>> --- a/mm/shmem.c
>> +++ b/mm/shmem.c
>> @@ -2005,11 +2005,14 @@ static struct folio *shmem_alloc_and_add_folio(struct vm_fault *vmf,
>> return ERR_PTR(error);
>> }
>>
>> +static DECLARE_WAIT_QUEUE_HEAD(shmem_swapcache_wq);
>> +
>> static struct folio *shmem_swap_alloc_folio(struct inode *inode,
>> struct vm_area_struct *vma, pgoff_t index,
>> swp_entry_t entry, int order, gfp_t gfp) {
>> struct shmem_inode_info *info = SHMEM_I(inode);
>> + DECLARE_WAITQUEUE(wait, current);
>> int nr_pages = 1 << order;
>> struct folio *new;
>> gfp_t alloc_gfp;
>> @@ -2066,6 +2069,10 @@ 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 */
>> + add_wait_queue(&shmem_swapcache_wq, &wait);
>> + schedule_timeout_uninterruptible(1);
>> + remove_wait_queue(&shmem_swapcache_wq, &wait);
>> /* Try smaller folio to avoid cache conflict */
>> goto fallback;
>> }
>> @@ -2423,6 +2430,8 @@ static int shmem_swapin_folio(struct inode *inode, pgoff_t index,
>> if (skip_swapcache) {
>> folio->swap.val = 0;
>> swapcache_clear(si, swap, nr_pages);
>> + if (waitqueue_active(&shmem_swapcache_wq))
>> + wake_up(&shmem_swapcache_wq);
>> } else {
>> swap_cache_del_folio(folio);
>> }
>> @@ -2442,8 +2451,11 @@ static int shmem_swapin_folio(struct inode *inode, pgoff_t index,
>> if (folio)
>> folio_unlock(folio);
>> failed_nolock:
>> - if (skip_swapcache)
>> + if (skip_swapcache) {
>> swapcache_clear(si, folio->swap, folio_nr_pages(folio));
>> + if (waitqueue_active(&shmem_swapcache_wq))
>> + wake_up(&shmem_swapcache_wq);
>> + }
>> if (folio)
>> folio_put(folio);
>> put_swap_device(si);
>> --
>> 2.47.3
>
> We have conducted stress tests on over 10 pcs for 40 hours each, and no relevant issues have been reproduced.
Thanks for testing. Could you add your 'Tested-by:' tag?
^ permalink raw reply [flat|nested] 6+ messages in thread
* 回复: 回复: [External Mail][PATCH 6.18.y v2] mm: shmem: fix potential livelock issue for shmem direct swapin
2026-07-14 2:34 ` Baolin Wang
@ 2026-07-14 6:05 ` 马超
2026-07-15 0:12 ` Sasha Levin
0 siblings, 1 reply; 6+ messages in thread
From: 马超 @ 2026-07-14 6:05 UTC (permalink / raw)
To: Baolin Wang, akpm@linux-foundation.org, hughd@google.com,
stable@vger.kernel.org
Cc: kasong@tencent.com, baohua@kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, 田孝斌,
俞东斌, 李鹏程
>On 7/13/26 7:55 PM, 马超 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 commit 029c4628b2eb ("mm: swap: get rid of livelock in swapin readahead") and commit 13ddaf26be32 ("mm/swap: fix race when skipping swapcache").
>>>
>>> However, commit 01626a1823 ("mm: avoid unconditional one-tick sleep when swapcache_prepare fails") found that the unconditional one-tick sleep can cause UI stuttering on latency-sensitive Android devices. So we can follow the same approach by adding a waitqueue to wake up tasks when needed, instead of always sleeping for a full tick.
>>>
>>> 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>
>>> ---
>>> Changes from v1:
>>> - Add a waitqueue to wake up tasks when needed.
>>>
>>> Hi Chao, could you try this patch to check if fix your issue? Thanks.
>>> ---
>>> mm/shmem.c | 14 +++++++++++++-
>>> 1 file changed, 13 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/mm/shmem.c b/mm/shmem.c
>>> index 94c5b0d78ac3..3c329b794ae4 100644
>>> --- a/mm/shmem.c
>>> +++ b/mm/shmem.c
>>> @@ -2005,11 +2005,14 @@ static struct folio *shmem_alloc_and_add_folio(struct vm_fault *vmf,
>>> return ERR_PTR(error);
>>> }
>>>
>>> +static DECLARE_WAIT_QUEUE_HEAD(shmem_swapcache_wq);
>>> +
>>> static struct folio *shmem_swap_alloc_folio(struct inode *inode,
>>> struct vm_area_struct *vma, pgoff_t index,
>>> swp_entry_t entry, int order, gfp_t gfp) {
>>> struct shmem_inode_info *info = SHMEM_I(inode);
>>> + DECLARE_WAITQUEUE(wait, current);
>>> int nr_pages = 1 << order;
>>> struct folio *new;
>>> gfp_t alloc_gfp;
>>> @@ -2066,6 +2069,10 @@ 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 */
>>> + add_wait_queue(&shmem_swapcache_wq, &wait);
>>> + schedule_timeout_uninterruptible(1);
>>> + remove_wait_queue(&shmem_swapcache_wq, &wait);
>>> /* Try smaller folio to avoid cache conflict */
>>> goto fallback;
>>> }
>>> @@ -2423,6 +2430,8 @@ static int shmem_swapin_folio(struct inode *inode, pgoff_t index,
>>> if (skip_swapcache) {
>>> folio->swap.val = 0;
>>> swapcache_clear(si, swap, nr_pages);
>>> + if (waitqueue_active(&shmem_swapcache_wq))
>>> + wake_up(&shmem_swapcache_wq);
>>> } else {
>>> swap_cache_del_folio(folio);
>>> }
>>> @@ -2442,8 +2451,11 @@ static int shmem_swapin_folio(struct inode *inode, pgoff_t index,
>>> if (folio)
>>> folio_unlock(folio);
>>> failed_nolock:
>>> - if (skip_swapcache)
>>> + if (skip_swapcache) {
>>> swapcache_clear(si, folio->swap,
>>> folio_nr_pages(folio));
>>> + if (waitqueue_active(&shmem_swapcache_wq))
>>> + wake_up(&shmem_swapcache_wq);
>>> + }
>>> if (folio)
>>> folio_put(folio);
>>> put_swap_device(si);
>>> --
>>> 2.47.3
>>
>> We have conducted stress tests on over 10 pcs for 40 hours each, and no relevant issues have been reproduced.
>
>Thanks for testing. Could you add your 'Tested-by:' tag?
We have conducted stress tests on over 10 pcs for 40 hours each, and no relevant issues have been reproduced.
Tested-by: Ma Chao <machao26@xiaomi.com>
#/******本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ 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!******/#
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: 回复: 回复: [External Mail][PATCH 6.18.y v2] mm: shmem: fix potential livelock issue for shmem direct swapin
2026-07-14 6:05 ` 回复: " 马超
@ 2026-07-15 0:12 ` Sasha Levin
0 siblings, 0 replies; 6+ messages in thread
From: Sasha Levin @ 2026-07-15 0:12 UTC (permalink / raw)
To: Baolin Wang, akpm@linux-foundation.org, hughd@google.com,
stable@vger.kernel.org
Cc: Sasha Levin, kasong@tencent.com, baohua@kernel.org,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
田孝斌, 俞东斌,
李鹏程, 马超
> We have conducted stress tests on over 10 pcs for 40 hours each, and no
> relevant issues have been reproduced.
> Tested-by: Ma Chao <machao26@xiaomi.com>
Queued for 6.18, thanks.
--
Thanks,
Sasha
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2026-07-15 0:12 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-07-10 2:09 [PATCH 6.18.y v2] mm: shmem: fix potential livelock issue for shmem direct swapin Baolin Wang
2026-07-10 9:15 ` Barry Song
2026-07-13 11:55 ` 回复: [External Mail][PATCH " 马超
2026-07-14 2:34 ` Baolin Wang
2026-07-14 6:05 ` 回复: " 马超
2026-07-15 0:12 ` Sasha Levin
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox