linux-kernel - Re: [PATCH tip/core/rcu 08/10] rcu: Add a TINY_PREEMPT

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: <20100817162525.GA21945@Krystal>
Date:	Tue, 17 Aug 2010 12:25:25 -0400
From:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	linux-kernel@...r.kernel.org, mingo@...e.hu, laijs@...fujitsu.com,
	dipankar@...ibm.com, akpm@...ux-foundation.org,
	josh@...htriplett.org, dvhltc@...ibm.com, niv@...ibm.com,
	tglx@...utronix.de, peterz@...radead.org, Valdis.Kletnieks@...edu,
	dhowells@...hat.com, eric.dumazet@...il.com,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH tip/core/rcu 08/10] rcu: Add a TINY_PREEMPT_RCU

* Steven Rostedt (rostedt@...dmis.org) wrote:
> On Tue, 2010-08-17 at 12:04 -0400, Steven Rostedt wrote:
> 
> > > Then we could go for the simpler:
> > > 
> > >   	--t->rcu_read_lock_nesting;
> > >  	barrier();
> > >         if (t->rcu_read_lock_nesting == 0 &&
> > >              unlikely((t->rcu_read_unlock_special))
> > 
> > Yeah, that's what I meant, I was too lazy to remove the ACCESS_ONCE()
> > from the cut and paste I did.
> > 
> > > 
> > > Which puts a constraint across all memory accesses. I'd be fine with
> > > that if you are afraid of too much micro-optimization (e.g. my
> > > barrier2(a, b) proposal).
> > 
> > Not afraid, but just too much code for a simple solution.
> 
> IOW,
> 
> I think just pulling out the '--' and adding the barrier() is the proper
> solution here. Compiler barriers are rather cheap.
> 
> Can we all agree on this solution?

Given that we already have a barrier() at the beginning of
rcu_read_unlock(), adding a second one will not have much more global
optimisation impact than what is already there. I'm personally fine with
this solution. Let's see what others have to say about this.

Thanks,

Mathieu


-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/