[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <67063387-6ba9-47fe-b283-d6346da15d9a@paulmck-laptop>
Date: Thu, 20 Feb 2025 14:04:47 -0800
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Jeff Johnson <jeff.johnson@....qualcomm.com>
Cc: rcu@...r.kernel.org, linux-kernel@...r.kernel.org, kernel-team@...a.com,
rostedt@...dmis.org, Jens Axboe <axboe@...nel.dk>,
ath12k@...ts.infradead.org
Subject: Re: [PATCH rcu 1/9] rcu: Add lockdep_assert_in_rcu_read_lock() and
friends
On Thu, Feb 20, 2025 at 11:38:14AM -0800, Jeff Johnson wrote:
> On 6/4/24 15:23, Paul E. McKenney wrote:
> > There is no direct RCU counterpart to lockdep_assert_irqs_disabled()
> > and friends. Although it is possible to construct them, it would
> > be more convenient to have the following lockdep assertions:
> >
> > lockdep_assert_in_rcu_read_lock()
> > lockdep_assert_in_rcu_read_lock_bh()
> > lockdep_assert_in_rcu_read_lock_sched()
> > lockdep_assert_in_rcu_reader()
> >
> > This commit therefore creates them.
>
> I'm looking at some downstream code that is trying to become
> upstream compliant, and currently that code uses:
>
> RCU_LOCKDEP_WARN(!rcu_read_lock_held(), "some message");
>
> It seems like this would be a good use of one of these helper
> functions, but I'm shocked to see that no upstream code is using
> them yet.
>
> Is there a reason to not use these helpers?
In cases where there is no additional useful information that can be
placed in "some message", the new helpers should be just fine.
Thanx, Paul
Powered by blists - more mailing lists