linux-kernel - Re: [PATCH 2/4] jrcu: tap rcu_read

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, 9 Mar 2011 16:34:19 -0800
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Joe Korty <joe.korty@...r.com>
Cc:	Frederic Weisbecker <fweisbec@...il.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Lai Jiangshan <laijs@...fujitsu.com>,
	"mathieu.desnoyers@...icios.com" <mathieu.desnoyers@...icios.com>,
	"dhowells@...hat.com" <dhowells@...hat.com>,
	"loic.minier@...aro.org" <loic.minier@...aro.org>,
	"dhaval.giani@...il.com" <dhaval.giani@...il.com>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"josh@...htriplett.org" <josh@...htriplett.org>,
	"houston.jim@...cast.net" <houston.jim@...cast.net>
Subject: Re: [PATCH 2/4] jrcu: tap rcu_read_unlock

On Wed, Mar 09, 2011 at 05:15:17PM -0500, Joe Korty wrote:
> jrcu: tap into rcu_read_unlock().
> 
> All places where rcu_read_unlock() is the final lock in
> a set of nested rcu locks are known rcu quiescent points.
> This patch recognizes that subset of those which also make
> the task preemptable.  The others are left unrecognized.
> 
> Not fundamentally needed, accelerates rcu batching.

Wouldn't you need to hook rcu_read_lock() as well, at least in
the CONFIG_PREEMPT_RCU case?  Otherwise, the RCU read-side critical
section's accesses could leak out, possibly causing an RCU read-side
critical section that looked like it started after a given grace period
(thus not blocking that grace period) actually have accesses that precede
the grace period?  If this situation could arise, the grace period could
end too soon, resulting in memory corruption.

Or am I missing something here?

							Thanx, Paul

> Signed-off-by: Joe Korty <joe.korty@...r.com>
> 
> Index: b/include/linux/jrcu.h
> ===================================================================
> --- a/include/linux/jrcu.h
> +++ b/include/linux/jrcu.h
> @@ -21,8 +21,10 @@
>  #ifndef __LINUX_JRCU_H
>  #define __LINUX_JRCU_H
> 
> +extern void rcu_read_unlock_jrcu(void);
> +
>  #define __rcu_read_lock()			preempt_disable()
> -#define __rcu_read_unlock()			preempt_enable()
> +#define __rcu_read_unlock()			rcu_read_unlock_jrcu()
> 
>  #define __rcu_read_lock_bh()			__rcu_read_lock()
>  #define __rcu_read_unlock_bh()			__rcu_read_unlock()
> Index: b/kernel/jrcu.c
> ===================================================================
> --- a/kernel/jrcu.c
> +++ b/kernel/jrcu.c
> @@ -153,6 +153,14 @@ static inline void rcu_eob(int cpu)
>  	}
>  }
> 
> +void rcu_read_unlock_jrcu(void)
> +{
> +	if (preempt_count() == 1)
> +		rcu_eob(rcu_cpu());
> +	preempt_enable();
> +}
> +EXPORT_SYMBOL_GPL(rcu_read_unlock_jrcu);
> +
>  void rcu_note_context_switch(int cpu)
>  {
>  	rcu_eob(cpu);
--
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/