Re: [PATCH] mm/shmem: report RCU-tasks quiescent states while undoing a range

[Andrew Morton <akpm@linux-foundation.org>]

On Fri, 18 Sep 2026 04:24:37 -0700 Breno Leitao <leitao@debian.org> 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.

We keep hitting this.  Whyohwhy doesn't cond_resched() imply
cond_resched_tasks_rcu_qs().

> Fixes: 8315f42295d2 ("rcu: Add call_rcu_tasks()")
> Cc: stable@vger.kernel.org

That's 2014.

> --- a/mm/shmem.c
> +++ b/mm/shmem.c
> @@ -1367,7 +1367,7 @@ static void shmem_undo_range(struct inode *inode, loff_t lstart, uoff_t lend,
>  		}
>  		folio_batch_remove_exceptionals(&fbatch);
>  		folio_batch_release(&fbatch);
> -		cond_resched();
> +		cond_resched_tasks_rcu_qs();

Won't this change remove the cond_resched() function from old kernels
which really want it?