* [PATCH] mm/shmem: report RCU-tasks quiescent states while undoing a range
@ 2026-09-18 11:24 Breno Leitao
2026-09-18 19:32 ` Andrew Morton
2026-09-19 0:25 ` SJ Park
0 siblings, 2 replies; 6+ messages in thread
From: Breno Leitao @ 2026-09-18 11:24 UTC (permalink / raw)
To: Hugh Dickins, Baolin Wang, Andrew Morton, Paul E. McKenney
Cc: linux-mm, linux-kernel, kernel-team, stable, Breno Leitao
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>
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH] mm/shmem: report RCU-tasks quiescent states while undoing a range
2026-09-18 11:24 [PATCH] mm/shmem: report RCU-tasks quiescent states while undoing a range Breno Leitao
@ 2026-09-18 19:32 ` Andrew Morton
2026-09-18 20:24 ` Paul E. McKenney
2026-09-19 0:25 ` SJ Park
1 sibling, 1 reply; 6+ messages in thread
From: Andrew Morton @ 2026-09-18 19:32 UTC (permalink / raw)
To: Breno Leitao
Cc: Hugh Dickins, Baolin Wang, Paul E. McKenney, linux-mm,
linux-kernel, kernel-team, stable
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?
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH] mm/shmem: report RCU-tasks quiescent states while undoing a range
2026-09-18 19:32 ` Andrew Morton
@ 2026-09-18 20:24 ` Paul E. McKenney
2026-09-18 20:43 ` Andrew Morton
0 siblings, 1 reply; 6+ messages in thread
From: Paul E. McKenney @ 2026-09-18 20:24 UTC (permalink / raw)
To: Andrew Morton
Cc: Breno Leitao, Hugh Dickins, Baolin Wang, linux-mm, linux-kernel,
kernel-team, stable
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
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH] mm/shmem: report RCU-tasks quiescent states while undoing a range
2026-09-18 20:24 ` Paul E. McKenney
@ 2026-09-18 20:43 ` Andrew Morton
2026-09-18 20:48 ` Paul E. McKenney
0 siblings, 1 reply; 6+ messages in thread
From: Andrew Morton @ 2026-09-18 20:43 UTC (permalink / raw)
To: paulmck
Cc: Breno Leitao, Hugh Dickins, Baolin Wang, linux-mm, linux-kernel,
kernel-team, stable
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.
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH] mm/shmem: report RCU-tasks quiescent states while undoing a range
2026-09-18 20:43 ` Andrew Morton
@ 2026-09-18 20:48 ` Paul E. McKenney
0 siblings, 0 replies; 6+ messages in thread
From: Paul E. McKenney @ 2026-09-18 20:48 UTC (permalink / raw)
To: Andrew Morton
Cc: Breno Leitao, Hugh Dickins, Baolin Wang, linux-mm, linux-kernel,
kernel-team, stable
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] mm/shmem: report RCU-tasks quiescent states while undoing a range
2026-09-18 11:24 [PATCH] mm/shmem: report RCU-tasks quiescent states while undoing a range Breno Leitao
2026-09-18 19:32 ` Andrew Morton
@ 2026-09-19 0:25 ` SJ Park
1 sibling, 0 replies; 6+ messages in thread
From: SJ Park @ 2026-09-19 0:25 UTC (permalink / raw)
To: Breno Leitao
Cc: SJ Park, Hugh Dickins, Baolin Wang, Andrew Morton,
Paul E. McKenney, linux-mm, linux-kernel, kernel-team, stable
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
[...]
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2026-09-19 0:26 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-09-18 11:24 [PATCH] mm/shmem: report RCU-tasks quiescent states while undoing a range Breno Leitao
2026-09-18 19:32 ` Andrew Morton
2026-09-18 20:24 ` Paul E. McKenney
2026-09-18 20:43 ` Andrew Morton
2026-09-18 20:48 ` Paul E. McKenney
2026-09-19 0:25 ` SJ Park
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®