linux-kernel - Re: [PATCH] fix misplaced mb() in rcu_enter/exit

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: <20080317190605.GG10955@linux.vnet.ibm.com>
Date:	Mon, 17 Mar 2008 12:06:05 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Oleg Nesterov <oleg@...sign.ru>
Cc:	linux-kernel@...r.kernel.org, rostedt@...dmis.org,
	linux-rt-users@...r.kernel.org, mingo@...e.hu, ego@...ibm.com,
	dipankar@...ibm.com, tytso@...ibm.com, dvhltc@...ibm.com,
	akpm@...ux-foundation.org, josh@...edesktop.org,
	tglx@...utronix.de, niv@...ibm.com
Subject: Re: [PATCH] fix misplaced mb() in rcu_enter/exit_nohz()

On Mon, Mar 17, 2008 at 09:30:47PM +0300, Oleg Nesterov wrote:
> On 03/16, Paul E. McKenney wrote:
> > 
> > In the process of writing up the mechanical proof of correctness for the
> > dynticks/preemptable-RCU interface, I noticed misplaced memory barriers
> > in rcu_enter_nohz() and rcu_exit_nohz().
> 
> Can't comment this patch, there is no rcu_enter_nohz() in my rcupreempt.h ;)

It is in 2.6.25-rc4 and later.  ;-)

> I'm not sure the code below is up to date, but what I have in
> arch/s390/kernel/time.c is:
> 
> 	stop_hz_timer:
> 
> 		cpu_set(cpu, nohz_cpu_mask);
> 		
> 		if (rcu_needs_cpu(cpu) || local_softirq_pending()) {
> 			cpu_clear(cpu, nohz_cpu_mask);
> 			return;
> 		}
> 
> Don't we need smp_mb() after cpu_set() ?

S390's memory model is quite strong, so it might not be needed.  In any
case, if needed, it goes -before- the cpu_set(), because the problems
would arise if prior RCU read-side critical sections were to be reordered
to follow this cpu_set(), right?

Let's see...  In S390, a store cannot be reordered to precede any prior
load or store, so any preceding RCU read-side critical section would be
seen by all CPUs as preceding the shift to nohz mode.  Might be trouble
for the opposite transition...

But last I heard, the s390 guys were thinking in terms of moving to the
generic dynticks model.  If they really are doing so, then the above
code goes away in any case.

							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/