mm/shmem.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
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.
Fixes: 8315f42295d2 ("rcu: Add call_rcu_tasks()")
Cc: stable@vger.kernel.org
Signed-off-by: Breno Leitao <leitao@debian.org>
---
mm/shmem.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/shmem.c b/mm/shmem.c
index b572c60f2af85..bf48cb49565ea 100644
--- 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();
}
/*
@@ -1408,7 +1408,7 @@ static void shmem_undo_range(struct inode *inode, loff_t lstart, uoff_t lend,
index = start;
while (index < end) {
- cond_resched();
+ cond_resched_tasks_rcu_qs();
if (!find_get_entries(mapping, &index, end - 1, &fbatch,
indices)) {
---
base-commit: e657a464aba873f5eaf3ca821b6e4016674492d6
change-id: 20260918-shmem-tasks-rcu-6be37ae730f3
Best regards,
--
Breno Leitao <leitao@debian.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.
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@vger.kernel.org
> Signed-off-by: Breno Leitao <leitao@debian.org>
Reviewed-by: SJ Park <sj@kernel.org>
Thanks,
SJ
[...]
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?
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
On Fri, 18 Sep 2026 13:24:53 -0700 "Paul E. McKenney" <paulmck@kernel.org> wrote:
> >
> > > --- 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)
>
Oh, should've looked.
And it appears to have been this way forever, so
s/cond_resched/cond_resched_tasks_rcu_qs/ won't break old kernels.
On Fri, Sep 18, 2026 at 01:43:42PM -0700, Andrew Morton wrote:
> On Fri, 18 Sep 2026 13:24:53 -0700 "Paul E. McKenney" <paulmck@kernel.org> wrote:
>
> > >
> > > > --- 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)
>
> Oh, should've looked.
No problem, and yes, I do know that feeling. ;-)
Thanx, Paul
> And it appears to have been this way forever, so
> s/cond_resched/cond_resched_tasks_rcu_qs/ won't break old kernels.
© 2016 - 2026 Red Hat, Inc.