BPF List
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: "Paul E. McKenney" <paulmck@kernel.org>
Cc: rcu@vger.kernel.org, linux-kernel@vger.kernel.org,
	kernel-team@meta.com,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	bpf@vger.kernel.org
Subject: Re: [PATCH v2 10/16] tracing: Guard __DECLARE_TRACE() use of __DO_TRACE_CALL() with SRCU-fast
Date: Thu, 6 Nov 2025 12:10:05 -0500	[thread overview]
Message-ID: <20251106121005.76087677@gandalf.local.home> (raw)
In-Reply-To: <522b01cf-0cb6-4766-9102-2d08a3983d8a@paulmck-laptop>

On Thu, 6 Nov 2025 09:01:30 -0800
"Paul E. McKenney" <paulmck@kernel.org> wrote:

> On Thu, Nov 06, 2025 at 11:02:30AM -0500, Steven Rostedt wrote:
> > On Wed,  5 Nov 2025 12:32:10 -0800
> > "Paul E. McKenney" <paulmck@kernel.org> wrote:  
> > > 
> > > The current commit can be thought of as an approximate revert of that
> > > commit, with some compensating additions of preemption disabling pointed
> > > out by Steven Rostedt (thank you, Steven!).  This preemption disabling  
> >   
> > > uses guard(preempt_notrace)(), and while in the area a couple of other
> > > use cases were also converted to guards.  
> > 
> > Actually, please don't do any conversions. That code is unrelated to
> > this work and I may be touching it. I don't need unneeded conflicts.  
> 
> OK, thank you for letting me know.  Should I set up for the merge window
> after this coming one (of course applying your feedback below), or will
> you be making this safe for PREEMPT_RT as part of your work?

Just don't convert the open coded preempt_disable() to a guard(). That's
the code I plan on touching. The rest is fine (with my suggestions ;-)

-- Steve

  reply	other threads:[~2025-11-06 17:10 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bb177afd-eea8-4a2a-9600-e36ada26a500@paulmck-laptop>
2025-11-05 20:32 ` [PATCH v2 02/16] srcu: Create an srcu_expedite_current() function Paul E. McKenney
2025-11-05 20:32 ` [PATCH v2 03/16] rcutorture: Test srcu_expedite_current() Paul E. McKenney
2025-11-05 20:32 ` [PATCH v2 04/16] srcu: Create a DEFINE_SRCU_FAST() Paul E. McKenney
2025-11-05 20:32 ` [PATCH v2 05/16] srcu: Make grace-period determination use ssp->srcu_reader_flavor Paul E. McKenney
2025-11-05 20:32 ` [PATCH v2 06/16] rcutorture: Exercise DEFINE_STATIC_SRCU_FAST() and init_srcu_struct_fast() Paul E. McKenney
2025-11-05 20:32 ` [PATCH v2 07/16] srcu: Require special srcu_struct define/init for SRCU-fast readers Paul E. McKenney
2025-11-05 20:32 ` [PATCH v2 08/16] srcu: Make SRCU-fast readers enforce use of SRCU-fast definition/init Paul E. McKenney
2025-11-05 20:32 ` [PATCH v2 09/16] doc: Update for SRCU-fast definitions and initialization Paul E. McKenney
2025-11-05 20:32 ` [PATCH v2 10/16] tracing: Guard __DECLARE_TRACE() use of __DO_TRACE_CALL() with SRCU-fast Paul E. McKenney
2025-11-06 16:02   ` Steven Rostedt
2025-11-06 17:01     ` Paul E. McKenney
2025-11-06 17:10       ` Steven Rostedt [this message]
2025-11-06 17:52         ` Paul E. McKenney
2025-11-07  0:03           ` Steven Rostedt
2025-11-07  1:04             ` Paul E. McKenney
2025-11-07  1:16               ` Steven Rostedt
2025-11-07  1:53                 ` Paul E. McKenney
2025-11-07 12:58                   ` Steven Rostedt
2025-11-05 20:32 ` [PATCH v2 12/16] srcu: Add SRCU_READ_FLAVOR_FAST_UPDOWN CPP macro Paul E. McKenney
2025-11-05 20:32 ` [PATCH v2 14/16] srcu: Create an SRCU-fast-updown API Paul E. McKenney
2025-11-25 14:18   ` Frederic Weisbecker
2025-11-25 15:54     ` Paul E. McKenney
2025-11-26 14:06       ` Frederic Weisbecker
2025-11-26 17:09         ` Paul E. McKenney
2025-11-05 20:32 ` [PATCH v2 15/16] srcu: Optimize SRCU-fast-updown for arm64 Paul E. McKenney
2025-11-08 13:07   ` Will Deacon
2025-11-08 18:38     ` Paul E. McKenney
2025-11-10 11:24       ` Will Deacon
2025-11-10 17:29         ` Paul E. McKenney
2025-11-24 13:04           ` Will Deacon
2025-11-24 17:20             ` Paul E. McKenney
2025-11-24 22:47               ` Frederic Weisbecker
2025-11-25 11:40                 ` Will Deacon

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=20251106121005.76087677@gandalf.local.home \
    --to=rostedt@goodmis.org \
    --cc=bigeasy@linutronix.de \
    --cc=bpf@vger.kernel.org \
    --cc=kernel-team@meta.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=paulmck@kernel.org \
    --cc=rcu@vger.kernel.org \
    /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