Re: [PATCH] mm/shmem: report RCU-tasks quiescent states while undoing a range
From: SJ Park
Date: Fri Sep 18 2026 - 20:33:04 EST
On Fri, 18 Sep 2026 04:24:37 -0700 Breno Leitao <leitao@xxxxxxxxxx> wrote:
> This shows up in the Meta fleet on ftruncate() of large tmpfs files:
>
> INFO: rcu_tasks detected stalls on tasks:
> 00000000752fd185: .. nvcsw: 59455/59455 holdout: 1 idle_cpu: -1/0
> task:rocksdb:bottom state:R running task
> __folio_split
> find_get_entry
> find_get_entries
> truncate_inode_partial_folio
> shmem_undo_range
> shmem_setattr
> notify_change
> do_ftruncate
> __x64_sys_ftruncate
> do_syscall_64
>
> shmem_undo_range() walks the whole of the requested range in folio_batch
> sized steps, twice, and its two cond_resched() calls are the only
> reschedule points in that walk.
>
> cond_resched() is not an RCU-tasks quiescent state. Use
> cond_resched_tasks_rcu_qs() at both points so the walk reports an
> RCU-tasks quiescent state as it proceeds.
Makes sense to me.
Btw I wonder how many cond_resched() will survive from the Mutphy's machine.
Just thinking loud.
>
> Fixes: 8315f42295d2 ("rcu: Add call_rcu_tasks()")
> Cc: stable@xxxxxxxxxxxxxxx
> Signed-off-by: Breno Leitao <leitao@xxxxxxxxxx>
Reviewed-by: SJ Park <sj@xxxxxxxxxx>
Thanks,
SJ
[...]