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: <20110314084718.GH2167@linux.vnet.ibm.com>
Date:	Mon, 14 Mar 2011 01:47:18 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Joe Korty <joe.korty@...r.com>
Cc:	fweisbec@...il.com, peterz@...radead.org, laijs@...fujitsu.com,
	mathieu.desnoyers@...icios.com, dhowells@...hat.com,
	loic.minier@...aro.org, dhaval.giani@...il.com, tglx@...utronix.de,
	josh@...htriplett.org, houston.jim@...cast.net,
	andi@...stfloor.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 8/9] jrcu: fix broken rcu_barrier

On Sun, Mar 13, 2011 at 11:50:44PM -0400, Joe Korty wrote:
> jrcu: fix bug in rcu_barrier.
> 
> It is not equivalent to synchronize_rcu.  But it
> can be implemented by a pair of synchronize_rcu's,
> so do so.
> 
> Thanks go to Paul E McKenney for finding this.
> 
> Signed-off-by: Joe Korty <joe.korty@...r.com>
> 
> Index: b/kernel/jrcu.c
> ===================================================================
> --- a/kernel/jrcu.c
> +++ b/kernel/jrcu.c
> @@ -183,7 +183,7 @@ void rcu_note_might_resched(void)
>  }
>  EXPORT_SYMBOL(rcu_note_might_resched);
> 
> -void rcu_barrier(void)
> +void synchronize_sched(void)
>  {
>  	struct rcu_synchronize rcu;
> 
> @@ -196,6 +196,13 @@ void rcu_barrier(void)
>  	atomic_inc(&rcu_stats.nbarriers);
> 
>  }
> +EXPORT_SYMBOL_GPL(synchronize_sched);
> +
> +void rcu_barrier(void)
> +{
> +	synchronize_sched();
> +	synchronize_sched();
> +}

This is still broken.  You need to wait until all pre-existing RCU
callbacks on all CPUs have been invoked.  Although this does guarantee
that all callbacks on the current CPU have been invoked, if one of the
other CPUs is busy, it might not yet have processed the callbacks from
earlier grace periods.  The usual way to take care of this is to post
a callback on each CPU, then wait for them all to be invoked.

							Thanx, Paul

>  EXPORT_SYMBOL_GPL(rcu_barrier);
> 
>  void rcu_force_quiescent_state(void)
> Index: b/include/linux/jrcu.h
> ===================================================================
> --- a/include/linux/jrcu.h
> +++ b/include/linux/jrcu.h
> @@ -39,12 +39,13 @@ extern void rcu_barrier(void);
>  #define rcu_barrier_sched			rcu_barrier
>  #define rcu_barrier_bh				rcu_barrier
> 
> -#define synchronize_rcu				rcu_barrier
> -#define synchronize_sched			rcu_barrier
> -#define synchronize_sched_expedited		rcu_barrier
> -#define synchronize_rcu_bh			rcu_barrier
> -#define synchronize_rcu_expedited		rcu_barrier
> -#define synchronize_rcu_bh_expedited		rcu_barrier
> +extern void synchronize_sched(void);
> +
> +#define synchronize_rcu				synchronize_sched
> +#define synchronize_sched_expedited		synchronize_sched
> +#define synchronize_rcu_bh			synchronize_sched
> +#define synchronize_rcu_expedited		synchronize_sched
> +#define synchronize_rcu_bh_expedited		synchronize_sched
> 
>  #define rcu_init(cpu)				do { } while (0)
>  #define rcu_init_sched()			do { } while (0)
> --
> 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/
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ