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

["Paul E. McKenney" <paulmck@kernel.org>]

On Fri, Sep 18, 2026 at 12:32:39PM -0700, Andrew Morton wrote:
> 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().

*I* don't have an objection to that.  ;-)

> > 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?

The cond_resched_tasks_rcu_qs() macro implies cond_resched():

	#define cond_resched_tasks_rcu_qs() \
	do { \
		rcu_tasks_qs(current, false); \
		cond_resched(); \
	} while (0)

							Thanx, Paul