linux-kernel - Re: [PATCH 1/2] percpu-rw-semaphores: use light/heavy barriers

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]

Date:	Wed, 24 Oct 2012 09:23:04 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Mikulas Patocka <mpatocka@...hat.com>
Cc:	Oleg Nesterov <oleg@...hat.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <peterz@...radead.org>,
	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>,
	Ananth N Mavinakayanahalli <ananth@...ibm.com>,
	Anton Arapov <anton@...hat.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] percpu-rw-semaphores: use light/heavy barriers

On Tue, Oct 23, 2012 at 05:39:43PM -0400, Mikulas Patocka wrote:
> 
> 
> On Tue, 23 Oct 2012, Paul E. McKenney wrote:
> 
> > On Tue, Oct 23, 2012 at 01:29:02PM -0700, Paul E. McKenney wrote:
> > > On Tue, Oct 23, 2012 at 08:41:23PM +0200, Oleg Nesterov wrote:
> > > > On 10/23, Paul E. McKenney wrote:
> > > > >
> > > > >  * Note that this guarantee implies a further memory-ordering guarantee.
> > > > >  * On systems with more than one CPU, when synchronize_sched() returns,
> > > > >  * each CPU is guaranteed to have executed a full memory barrier since
> > > > >  * the end of its last RCU read-side critical section
> > > >          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > > 
> > > > Ah wait... I misread this comment.
> > > 
> > > And I miswrote it.  It should say "since the end of its last RCU-sched
> > > read-side critical section."  So, for example, RCU-sched need not force
> > > a CPU that is idle, offline, or (eventually) executing in user mode to
> > > execute a memory barrier.  Fixed this.
> 
> Or you can write "each CPU that is executing a kernel code is guaranteed 
> to have executed a full memory barrier".

Perhaps I could, but it isn't needed, nor is it particularly helpful.
Please see suggestions in preceding email.

> It would be consistent with the current implementation and it would make 
> it possible to use
> 
> barrier()-synchronize_sched() as biased memory barriers.

But it is simpler to rely on the properties of RCU.  We really should
avoid memory barriers where possible, as they are way too easy to
get wrong.

> ---
> 
> In percpu-rwlocks, CPU 1 executes
> 
> ...make some writes in the critical section...
> barrier();
> this_cpu_dec(*p->counters);
> 
> and the CPU 2 executes
> 
> while (__percpu_count(p->counters))
> 	msleep(1);
> synchronize_sched();
> 
> So, when CPU 2 finishes synchronize_sched(), we must make sure that
> all writes done by CPU 1 are visible to CPU 2.
> 
> The current implementation fulfills this requirement, you can just add it 
> to the specification so that whoever changes the implementation keeps it.

I will consider doing that if and when someone shows me a situation where
adding that requirement makes things simpler and/or faster.  From what I
can see, your example does not do so.

							Thanx, Paul

> Mikulas
> 
> > And I should hasten to add that for synchronize_sched(), disabling
> > preemption (including disabling irqs, further including NMI handlers)
> > acts as an RCU-sched read-side critical section.  (This is in the
> > comment header for synchronize_sched() up above my addition to it.)
> > 	
> > 							Thanx, Paul
> 

--
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/