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  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Wed, 25 Mar 2009 20:34:00 -0700
From:	"Paul E. McKenney" <>
To:	Ingo Molnar <>
Subject: Re: [tip:tracing/kmemtrace] rcutree: fix rcu_tree_trace.c data
	structure dependencies

On Wed, Mar 25, 2009 at 05:57:13PM +0100, Ingo Molnar wrote:
> * Paul E. McKenney <> wrote:
> > > I think many of the data definitions (and the resulting include 
> > > file dependencies) in include/linux/rcu*.h could move into 
> > > kernel/rcu*.h and be privatized that way. 'struct rcu_state' 
> > > would be an example.
> > > 
> > > Agreed?
> > 
> > In principle, yes.  In practice, my attempts to make headway in 
> > this direction have usually collided with the desire to inline 
> > some of the functions that appear on fastpaths, so I would prefer 
> > caution when moving in this direction, especially given my 
> > treercu-related todos, to which "speeding up synchronize_rcu()" 
> > just got added.
> I think there's a solution, for example the quiescent-state inlines 
> could still be offered in a kernel/rcupdate_internals.h header to be 
> included by kernel/softirq.c et al directly.

Could definitely do this, as I used to do it this way in a former life.
As long as we are now OK with creating an additional header file or two
per flavor of RCU.

> Otherwise ... i think it generally is not worth the trouble to put 
> huge data types into common headers just to be able to inline into a 
> small number of callsites.

Information hiding can indeed be a good thing.

							Thanx, Paul
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists