All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Nick Piggin <npiggin@suse.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Hugh Dickins <hugh@veritas.com>,
	linux-arch@vger.kernel.org,
	Linux Memory Management List <linux-mm@kvack.org>
Subject: Re: [patch 1/2] read_barrier_depends fixlets
Date: Mon, 5 May 2008 07:27:46 -0700	[thread overview]
Message-ID: <20080505142746.GC14809@linux.vnet.ibm.com> (raw)
In-Reply-To: <20080505112021.GC5018@wotan.suse.de>

On Mon, May 05, 2008 at 01:20:21PM +0200, Nick Piggin wrote:
> While considering the impact of read_barrier_depends, it occurred to
> me that it should really be really a noop for the compiler. At least, it is
> better to have every arch the same than to have a few that are slightly
> different. (Does this mean SMP Alpha's read_barrier_depends could drop the
> "memory" clobber too?)

SMP Alpha's read_barrier_depends() needs the "memory" clobber
because the compiler is otherwise free to move code across the
smp_read_barrier_depends(), which would defeat its purpose.

> --
> It would be a highly unusual compiler that might try to issue a load of
> data1 before it loads a data2 which is data-dependant on data1.

A bit unusual, perhaps, but not unprecedented.  Value speculating
compilers, for example.

> There is the problem of the compiler trying to reload data1 _after_
> loading data2, and thus having a newer data1 than data2. However if the
> compiler is so inclined, then it could perform such a load at any point
> after the barrier, so the barrier itself will not guarantee correctness.
> 
> I think we've mostly hoped the compiler would not to do that.

Well, this does point me at one thing I missed with preemptable RCU,
namely all the open-coded sequences using smp_read_barrier_depends().
Quite embarrassing!!!  But a lot easier having you point me at it than
however long it would have taken me to figure it out on my own, so thank
you very much!!!

> This brings alpha and frv into line with all other architectures.

Assuming that we apply ACCESS_ONCE() as needed to the uses of
smp_read_barrier_depends():

Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

> Signed-off-by: Nick Piggin <npiggin@suse.de>
> 
> Index: linux-2.6/include/asm-alpha/barrier.h
> ===================================================================
> --- linux-2.6.orig/include/asm-alpha/barrier.h
> +++ linux-2.6/include/asm-alpha/barrier.h
> @@ -24,7 +24,7 @@ __asm__ __volatile__("mb": : :"memory")
>  #define smp_mb()	barrier()
>  #define smp_rmb()	barrier()
>  #define smp_wmb()	barrier()
> -#define smp_read_barrier_depends()	barrier()
> +#define smp_read_barrier_depends()	do { } while (0)
>  #endif
> 
>  #define set_mb(var, value) \
> Index: linux-2.6/include/asm-frv/system.h
> ===================================================================
> --- linux-2.6.orig/include/asm-frv/system.h
> +++ linux-2.6/include/asm-frv/system.h
> @@ -179,7 +179,7 @@ do {							\
>  #define mb()			asm volatile ("membar" : : :"memory")
>  #define rmb()			asm volatile ("membar" : : :"memory")
>  #define wmb()			asm volatile ("membar" : : :"memory")
> -#define read_barrier_depends()	barrier()
> +#define read_barrier_depends()	do { } while (0)
> 
>  #ifdef CONFIG_SMP
>  #define smp_mb()			mb()

WARNING: multiple messages have this Message-ID (diff)
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Nick Piggin <npiggin@suse.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Hugh Dickins <hugh@veritas.com>,
	linux-arch@vger.kernel.org,
	Linux Memory Management List <linux-mm@kvack.org>
Subject: Re: [patch 1/2] read_barrier_depends fixlets
Date: Mon, 5 May 2008 07:27:46 -0700	[thread overview]
Message-ID: <20080505142746.GC14809@linux.vnet.ibm.com> (raw)
In-Reply-To: <20080505112021.GC5018@wotan.suse.de>

On Mon, May 05, 2008 at 01:20:21PM +0200, Nick Piggin wrote:
> While considering the impact of read_barrier_depends, it occurred to
> me that it should really be really a noop for the compiler. At least, it is
> better to have every arch the same than to have a few that are slightly
> different. (Does this mean SMP Alpha's read_barrier_depends could drop the
> "memory" clobber too?)

SMP Alpha's read_barrier_depends() needs the "memory" clobber
because the compiler is otherwise free to move code across the
smp_read_barrier_depends(), which would defeat its purpose.

> --
> It would be a highly unusual compiler that might try to issue a load of
> data1 before it loads a data2 which is data-dependant on data1.

A bit unusual, perhaps, but not unprecedented.  Value speculating
compilers, for example.

> There is the problem of the compiler trying to reload data1 _after_
> loading data2, and thus having a newer data1 than data2. However if the
> compiler is so inclined, then it could perform such a load at any point
> after the barrier, so the barrier itself will not guarantee correctness.
> 
> I think we've mostly hoped the compiler would not to do that.

Well, this does point me at one thing I missed with preemptable RCU,
namely all the open-coded sequences using smp_read_barrier_depends().
Quite embarrassing!!!  But a lot easier having you point me at it than
however long it would have taken me to figure it out on my own, so thank
you very much!!!

> This brings alpha and frv into line with all other architectures.

Assuming that we apply ACCESS_ONCE() as needed to the uses of
smp_read_barrier_depends():

Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

> Signed-off-by: Nick Piggin <npiggin@suse.de>
> 
> Index: linux-2.6/include/asm-alpha/barrier.h
> ===================================================================
> --- linux-2.6.orig/include/asm-alpha/barrier.h
> +++ linux-2.6/include/asm-alpha/barrier.h
> @@ -24,7 +24,7 @@ __asm__ __volatile__("mb": : :"memory")
>  #define smp_mb()	barrier()
>  #define smp_rmb()	barrier()
>  #define smp_wmb()	barrier()
> -#define smp_read_barrier_depends()	barrier()
> +#define smp_read_barrier_depends()	do { } while (0)
>  #endif
> 
>  #define set_mb(var, value) \
> Index: linux-2.6/include/asm-frv/system.h
> ===================================================================
> --- linux-2.6.orig/include/asm-frv/system.h
> +++ linux-2.6/include/asm-frv/system.h
> @@ -179,7 +179,7 @@ do {							\
>  #define mb()			asm volatile ("membar" : : :"memory")
>  #define rmb()			asm volatile ("membar" : : :"memory")
>  #define wmb()			asm volatile ("membar" : : :"memory")
> -#define read_barrier_depends()	barrier()
> +#define read_barrier_depends()	do { } while (0)
> 
>  #ifdef CONFIG_SMP
>  #define smp_mb()			mb()

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  parent reply	other threads:[~2008-05-05 14:27 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-05 11:20 [patch 1/2] read_barrier_depends fixlets Nick Piggin
2008-05-05 11:20 ` Nick Piggin
2008-05-05 11:20 ` Nick Piggin
2008-05-05 12:12 ` [patch 2/2] fix SMP data race in pagetable setup vs walking Nick Piggin
2008-05-05 12:12   ` Nick Piggin
2008-05-05 12:12   ` Nick Piggin
2008-05-05 14:35   ` Paul E. McKenney
2008-05-05 14:35     ` Paul E. McKenney
2008-05-06  9:38     ` Nick Piggin
2008-05-06  9:38       ` Nick Piggin
2008-05-06 13:32       ` Paul E. McKenney
2008-05-06 13:32         ` Paul E. McKenney
2008-05-13  7:55         ` Nick Piggin
2008-05-13  7:55           ` Nick Piggin
2008-05-13 13:26           ` Paul E. McKenney
2008-05-13 13:26             ` Paul E. McKenney
2008-05-05 15:32   ` Linus Torvalds
2008-05-05 15:32     ` Linus Torvalds
2008-05-05 16:37     ` Hugh Dickins
2008-05-05 16:37       ` Hugh Dickins
2008-05-06  9:51     ` Nick Piggin
2008-05-06  9:51       ` Nick Piggin
2008-05-06 14:53       ` Linus Torvalds
2008-05-06 14:53         ` Linus Torvalds
2008-05-06 19:11         ` Paul E. McKenney
2008-05-06 19:11           ` Paul E. McKenney
2008-05-14  4:27           ` Nick Piggin
2008-05-14  4:27             ` Nick Piggin
2008-05-13  8:01         ` Nick Piggin
2008-05-13  8:01           ` Nick Piggin
2008-05-13 15:45           ` Linus Torvalds
2008-05-13 15:45             ` Linus Torvalds
2008-05-14  0:34             ` Nick Piggin
2008-05-14  0:34               ` Nick Piggin
2008-05-14  0:55               ` Linus Torvalds
2008-05-14  0:55                 ` Linus Torvalds
2008-05-14  1:18                 ` Nick Piggin
2008-05-14  1:18                   ` Nick Piggin
2008-05-14  4:35                 ` [patch 1/2] read_barrier_depends arch fixlets Nick Piggin
2008-05-14  4:35                   ` Nick Piggin
2008-05-14  4:37                   ` [patch 2/2] fix SMP data race in pagetable setup vs walking Nick Piggin
2008-05-14  4:37                     ` Nick Piggin
2008-05-14 13:26                   ` [patch 1/2] read_barrier_depends arch fixlets Paul E. McKenney
2008-05-14 13:26                     ` Paul E. McKenney
2008-05-05 16:57   ` [patch 2/2] fix SMP data race in pagetable setup vs walking Hugh Dickins
2008-05-05 16:57     ` Hugh Dickins
2008-05-06  9:52     ` Nick Piggin
2008-05-06  9:52       ` Nick Piggin
2008-05-06  7:08   ` David Miller
2008-05-06  7:08     ` David Miller, Nick Piggin
2008-05-06  9:56     ` Nick Piggin
2008-05-06  9:56       ` Nick Piggin
2008-05-05 14:27 ` Paul E. McKenney [this message]
2008-05-05 14:27   ` [patch 1/2] read_barrier_depends fixlets Paul E. McKenney
2008-05-06  9:01   ` Nick Piggin
2008-05-06  9:01     ` Nick Piggin
2008-05-06 14:06     ` Paul E. McKenney
2008-05-06 14:06       ` Paul E. McKenney
2008-05-06 15:29 ` David Howells
2008-05-06 15:29   ` David Howells
2008-05-06 19:09   ` Paul E. McKenney
2008-05-06 19:09     ` Paul E. McKenney
2008-05-13  8:05   ` Nick Piggin
2008-05-13  8:05     ` Nick Piggin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080505142746.GC14809@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=hugh@veritas.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=npiggin@suse.de \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.