linux-kernel - Re: [PATCH v3 2/4] srcu: Add srcu_read_lock_fast_notrace() and srcu_read_unlock_fast

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250722184736.13a0e879@gandalf.local.home>
Date: Tue, 22 Jul 2025 18:47:36 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: "Paul E. McKenney" <paulmck@...nel.org>
Cc: Joel Fernandes <joelagnelf@...dia.com>, rcu@...r.kernel.org,
 linux-kernel@...r.kernel.org, kernel-team@...a.com, Mathieu Desnoyers
 <mathieu.desnoyers@...icios.com>, Sebastian Andrzej Siewior
 <bigeasy@...utronix.de>
Subject: Re: [PATCH v3 2/4] srcu: Add srcu_read_lock_fast_notrace() and
 srcu_read_unlock_fast_notrace()

On Tue, 22 Jul 2025 15:34:52 -0700
"Paul E. McKenney" <paulmck@...nel.org> wrote:

> > > +static inline struct srcu_ctr __percpu *srcu_read_lock_fast_notrace(struct srcu_struct *ssp)
> > > +	__acquires(ssp)  
> > 
> > Should these also be marked with 'notrace' attribute?
> > 
> > I am not sure what the precedent is, I do see a few examples of 'notrace' and
> > 'inline' in the same function signature though.  
> 
> Heh!!!
> 
> There are six instance of static-inline notrace functions, and eight
> instances of static-inline non-notrace functions whose names contain
> "_notrace", not counting the srcu_read_lock_fast_notrace() and
> srcu_read_unlock_fast() functions currently under review.
> 
> My guess is that I should add "notrace" to handle the possible case
> where the compiler declines to inline this function.  I will do this
> on the next rebase unless I hear otherwise.
> 
> Steven, Mathieu, thoughts?

If you add "__always_inline" then it will include "notrace" as inlined
functions are not traced. But we have removed "notrace" from the generic
"inline" a while ago. If the compiler decides to ignore an "inline" it
*will* be traced.

We probably should fix any "_notrace" functions that are not
"__always_inline" and do not have "notrace".

-- Steve