Re: [BUG] shmem: shmem_get_folio_gfp livelock

[Baolin Wang]

On 7/2/26 1:25 AM, Kairui Song wrote:
> On Wed, Jul 1, 2026 at 6:09 PM Baolin Wang
> <baolin.wang@xxxxxxxxxxxxxxxxx> wrote:
> > CC Hugh and Kairui.
>
> Hello!
>
> > On 6/30/26 9:15 PM, 马超 wrote:
> > > Hello,
> > > I encountered a bug in the shmem subsystem. Details below.
> > >
> > > [Summary]
> > > shmem_get_folio_gfp() can livelock when multiple threads fault on the
> > > same shmem page concurrently. The -EEXIST retry loop (goto repeat) has
> > > no cond_resched(), causing busy-looping threads to starve the thread
> > > that holds the swapcache slot, resulting in an indefinite RCU stall and
> > > system hang.
> > > [Environment]
> > > 1.Kernel: 6.18.21 (ARM64, PREEMPT, CONFIG_LRU_GEN=y)
> > > 2.Triggered by: multi-threaded app with threads constrained to 2 CPUs
> > > via cpuset
> > > [Root Cause]
> > > When multiple threads in the same process fault on the same shmem
> > > swap entry:
> > > 1.Thread A enters shmem_swap_alloc_folio(), succeeds at
> > > swapcache_prepare() (sets SWAP_HAS_CACHE), then enters
> > > workingset_refault() → lru_gen_refault() → rcu_read_lock().
> > > While inside the RCU read-side critical section, it is
> > > preempted via preempt_schedule_irq (IRQ exit path detects
> > > TIF_NEED_RESCHED).
> > > 2.Threads B & C enter shmem_swap_alloc_folio(), fail at
> > > swapcache_prepare() (slot already taken by A), return -EEXIST.
> > > 3.In shmem_get_folio_gfp():
> > >       error = shmem_swapin_folio(...);
> > >       if (error == -EEXIST)
> > >           goto repeat;// no cond_resched(), tight loop
> > > 4.Threads B & C spin at 100% CPU on the retry loop. All three
> > > threads share the same cpuset (CPU0-1,cpus_allowed=0x3).Thread A
> > > is perpetually preempted and starved — it cannot complete the
> > > few instructions needed to call rcu_read_unlock().
> > > 5.The held RCU read lock blocks the grace period indefinitely,
> > > causing all synchronize_rcu() callers (cgroup operations,
> > > fd allocation, etc.) to hang, eventually blocking init.
> > > [Scheduling Details]
> > > Key observations:
> > > 1.Thread A was RCU-boosted to prio 98 but accumulated only
> > > 99ms of execution over the entire stall period (~1200s).
> > > It was effectively starved despite the priority boost.
> > > 2.Threads B & C have vruntime=0 and prio 91, indicating
> > > they run in an RT-equivalent scheduling class (SCHED_FIFO/RT
> > > policy). Each accumulated ~1134 seconds of execution with
> > > only ~1600 context switches, meaning they ran uninterrupted
> > > for ~700ms per scheduling quantum on average.
> > > 3.Thread A cannot preempt Threads B & C: Although RCU boost
> > > raised Thread A to prio 98, Threads B & C at prio 91 (lower
> > > numeric value = higher priority in RT class) have equal or
> > > higher effective priority. The busy-looping threads never
> > > voluntarily yield (no cond_resched(), no blocking calls in
> > > the loop), so Thread A never gets scheduled.
> > > 4.CPU contention: CPU0 had nr_running=28 and CPU1 had
> > > nr_running=24, with 3-4 RT tasks per CPU. Thread A competed
> > > with Thread B on CPU0 but could not win scheduling.
> > > [Observed Impact]
> > > 1.RCU stall lasting 910+ seconds (19 consecutive stall
> > > warnings, grace period g=4398761 never advanced)
> > > 2.synchronize_rcu_expedited() callers blocked 742+ seconds
> > > 3.init process hung > 720 seconds → system unresponsive
> > > [Call Traces]
> > > Thread A (RCU stall source, sampled 19 times identically):
> > > __switch_to+0x1a4/0x360 (T)
> > > __schedule+0x96c/0xf3c
> > > preempt_schedule_irq+0xec/0x198
> > > raw_irqentry_exit_cond_resched+0x2c/0x44
> > > irqentry_exit+0x38/0x64
> > > exit_to_kernel_mode+0x28/0x38
> > > el1_interrupt+0x5c/0xa8
> > > el1h_64_irq_handler+0x18/0x24
> > > el1h_64_irq+0x84/0x88
> > > workingset_refault+0x16c/0x79c (P)
> > >     shmem_swapin_folio+0x8e4/0xd44
> > >       shmem_get_folio_gfp+0xb8/0x710
> > >         shmem_fault+0xa0/0x174
> > >           __do_fault
> > > do_pte_missing
> > > handle_mm_fault
> > > do_page_fault
> > > el0_ia
> > >
> > > Thread B (busy-loop on CPU0, sum_exec_runtime=1134s):
> > > xas_load+0x78/0xe4 (P)
> > >     shmem_swapin_folio+0x950/0xd44
> > >       shmem_get_folio_gfp+0xb8/0x710
> > >         shmem_fault → ... → el0_ia
> > >
> > > Thread C (busy-loop on CPU1, sum_exec_runtime=1134s):
> > > xas_load+0x50/0xe4 (P)
> > >     shmem_swapin_folio+0xd8/0xd44
> > >       shmem_get_folio_gfp+0xb8/0x710
> > >         shmem_fault → ... → el0_ia
> > > [Question]
> > > What is the recommended approach to fix this livelock?
> > > We are considering adding a cond_resched() before the
> > > goto repeat in shmem_get_folio_gfp() to break the tight
> > > loop and allow the swapcache-holding thread to make
> > > progress. Would this be an acceptable fix, or is there
> > > a better strategy (e.g., bounded retry with fallback,
> > > or yielding to the specific waiter)?
>
> So this is a 6.18 issue, the SWAP_HAS_CACHE design was a long time
> issue and we had a workaround for anon in commit 13ddaf26be32, the
> `schedule_timeout_uninterruptible(1)`. That's fine as a workaroud and
> we remove the workaround with proper redesign later in commit
> f1879e8a0c60. Shmem never used a workaround like
> schedule_timeout_uninterruptible and we jump to the right design
> directly.
>
> For 6.18 LTS, do we need a fix though? I think we can have a similar
> timeout for shmem as well, just do a
> schedule_timeout_uninterruptible(1), yes it's really ugly, and we have
> another long time workaround like that in mm/swap_state.c as well in
> 6.18. Without the later proper redesign there seems no better way.
> Barry provided an extra improvement on top of that workaround in
> commit 01626a182302, maybe can also be carried into shmem. So maybe
> having both for shmem is a good choice for a 6.18 fix.

Thanks for the explanation. I think we need a fix for 6.18 LTS, and it 
sounds reasonable to me to follow what anon folios did. Would you mind 
sending a proper fix for this issue? If you don't have time, I can fix 
it based on your suggestion.