From: Andrea Righi <arighi@nvidia.com>
To: Gabriele Monaco <gmonaco@redhat.com>
Cc: Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Juri Lelli <juri.lelli@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Steven Rostedt <rostedt@goodmis.org>,
Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
Valentin Schneider <vschneid@redhat.com>,
K Prateek Nayak <kprateek.nayak@amd.com>,
Sechang Lim <rhkrqnwk98@gmail.com>,
bpf@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] sched: Set need-resched flags before tracing
Date: Sat, 12 Sep 2026 09:34:00 +0200 [thread overview]
Message-ID: <aqUAaH6fSMhHF0EF@gpd4> (raw)
In-Reply-To: <71619AD0-A163-40DA-94B1-39052E808DDC@redhat.com>
Hi Gabriele,
On Sat, Sep 12, 2026 at 07:13:48AM +0000, Gabriele Monaco wrote:
> Il 11 settembre 2026 21:33:00 UTC, Andrea Righi <arighi@nvidia.com> ha scritto:
> >sched_set_need_resched_tp is emitted before the corresponding thread
> >flag is set. This allows a BPF tracepoint program to recursively invoke
> >the same tracepoint while leaving its RCU read-side critical section.
> >
> >If rcu_read_unlock_special() must defer a quiescent state while
> >preemption or interrupts are disabled, it calls
> >set_need_resched_current(). Since TIF_NEED_RESCHED is still clear, this
> >emits the tracepoint again and repeats until the kernel stack overflows:
> >
> > __trace_set_need_resched()
> > bpf_trace_run3()
> > rcu_read_unlock_migrate()
> > rcu_read_unlock_special()
> > set_need_resched_current()
> > set_tsk_need_resched()
> > __trace_set_need_resched()
> >
> >Set the thread flag before emitting the tracepoint in both
> >set_tsk_need_resched() and __resched_curr(). For a remote reschedule,
> >retain the result of set_nr_and_not_polling() so that tracing remains
> >ahead of IPI delivery while still observing the updated flag.
> >
> >Fixes: adcc3bfa8806 ("sched: Adapt sched tracepoints for RV task model")
> >Signed-off-by: Andrea Righi <arighi@nvidia.com>
> >---
>
> Hi Andrea,
>
> Isn't this mostly what was done in [1]? I wonder if that patch was just forgotten.
>
> There was a discussion that apparently didn't go anywhere, but it doesn't look like a blocker for the change to me.
>
It is **exactly** the same fix! I hit the same issue and missed Sechang's
series. There's also a v3:
https://lore.kernel.org/all/20260630084750.2792851-1-rhkrqnwk98@gmail.com/
We can ignore this one and go with Sechang's. Sorry for the noise.
Thanks,
-Andrea
> Thanks,
> Gabriele
>
> [1] - https://lore.kernel.org/lkml/20260627081657.499781-1-rhkrqnwk98@gmail.com
>
> > include/linux/sched.h | 5 ++++-
> > kernel/sched/core.c | 7 +++++--
> > 2 files changed, 9 insertions(+), 3 deletions(-)
> >
> >diff --git a/include/linux/sched.h b/include/linux/sched.h
> >index 59f6366fdf501..6003dcd080e6c 100644
> >--- a/include/linux/sched.h
> >+++ b/include/linux/sched.h
> >@@ -2105,8 +2105,11 @@ static inline int test_tsk_thread_flag(struct task_struct *tsk, int flag)
> > static inline void set_tsk_need_resched(struct task_struct *tsk)
> > {
> > if (tracepoint_enabled(sched_set_need_resched_tp) &&
> >- !test_tsk_thread_flag(tsk, TIF_NEED_RESCHED))
> >+ !test_tsk_thread_flag(tsk, TIF_NEED_RESCHED)) {
> >+ set_tsk_thread_flag(tsk, TIF_NEED_RESCHED);
> > __trace_set_need_resched(tsk, TIF_NEED_RESCHED);
> >+ return;
> >+ }
> > set_tsk_thread_flag(tsk,TIF_NEED_RESCHED);
> > }
> >
> >diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> >index 91f059a556950..aed403fd2f82e 100644
> >--- a/kernel/sched/core.c
> >+++ b/kernel/sched/core.c
> >@@ -1196,6 +1196,7 @@ static void __resched_curr(struct rq *rq, int tif)
> > {
> > struct task_struct *curr = rq->curr;
> > struct thread_info *cti = task_thread_info(curr);
> >+ bool send_ipi;
> > int cpu;
> >
> > lockdep_assert_rq_held(rq);
> >@@ -1212,15 +1213,17 @@ static void __resched_curr(struct rq *rq, int tif)
> >
> > cpu = cpu_of(rq);
> >
> >- trace_sched_set_need_resched_tp(curr, cpu, tif);
> > if (cpu == smp_processor_id()) {
> > set_ti_thread_flag(cti, tif);
> > if (tif == TIF_NEED_RESCHED)
> > set_preempt_need_resched();
> >+ trace_sched_set_need_resched_tp(curr, cpu, tif);
> > return;
> > }
> >
> >- if (set_nr_and_not_polling(cti, tif)) {
> >+ send_ipi = set_nr_and_not_polling(cti, tif);
> >+ trace_sched_set_need_resched_tp(curr, cpu, tif);
> >+ if (send_ipi) {
> > if (tif == TIF_NEED_RESCHED)
> > smp_send_reschedule(cpu);
> > } else {
>
next prev parent reply other threads:[~2026-09-12 7:34 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-11 21:33 Andrea Righi
2026-09-12 7:13 ` Gabriele Monaco
2026-09-12 7:34 ` Andrea Righi [this message]
2026-09-12 21:30 ` bot+bpf-ci
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aqUAaH6fSMhHF0EF@gpd4 \
--to=arighi@nvidia.com \
--cc=bpf@vger.kernel.org \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=gmonaco@redhat.com \
--cc=juri.lelli@redhat.com \
--cc=kprateek.nayak@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rhkrqnwk98@gmail.com \
--cc=rostedt@goodmis.org \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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®