From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
paulus@samba.org, shaggy@austin.ibm.com, adaplas@gmail.com,
"Morton, Andrew" <akpm@linux-foundation.org>,
xfs-masters@oss.sgi.com
Subject: Re: [interesting] smattering of possible memory ordering bugs
Date: Fri, 26 Oct 2007 13:35:17 +1000 [thread overview]
Message-ID: <1193369717.7018.56.camel@pasglop> (raw)
In-Reply-To: <200710261209.58519.nickpiggin@yahoo.com.au>
> Index: linux-2.6/arch/powerpc/mm/hash_native_64.c
> ===================================================================
> --- linux-2.6.orig/arch/powerpc/mm/hash_native_64.c
> +++ linux-2.6/arch/powerpc/mm/hash_native_64.c
> @@ -113,7 +113,7 @@ static inline void native_lock_hpte(stru
> unsigned long *word = &hptep->v;
>
> while (1) {
> - if (!test_and_set_bit(HPTE_LOCK_BIT, word))
> + if (!test_and_set_bit_lock(HPTE_LOCK_BIT, word))
> break;
> while(test_bit(HPTE_LOCK_BIT, word))
> cpu_relax();
> @@ -124,8 +124,7 @@ static inline void native_unlock_hpte(st
> {
> unsigned long *word = &hptep->v;
>
> - asm volatile("lwsync":::"memory");
> - clear_bit(HPTE_LOCK_BIT, word);
> + clear_bit_unlock(HPTE_LOCK_BIT, word);
> }
Ack.
> Index: linux-2.6/arch/ppc/xmon/start.c
> ===================================================================
> --- linux-2.6.orig/arch/ppc/xmon/start.c
> +++ linux-2.6/arch/ppc/xmon/start.c
> @@ -92,16 +92,15 @@ xmon_write(void *handle, void *ptr, int
> {
> char *p = ptr;
> int i, c, ct;
> -
> -#ifdef CONFIG_SMP
> - static unsigned long xmon_write_lock;
> - int lock_wait = 1000000;
> + static DEFINE_SPINLOCK(xmon_write_lock);
> + int lock_udelay = 10000;
> int locked;
>
> - while ((locked = test_and_set_bit(0, &xmon_write_lock)) != 0)
> - if (--lock_wait == 0)
> + while (!(locked = spin_trylock(&xmon_write_lock))) {
> + udelay(1);
> + if (--lock_udelay == 0)
> break;
> -#endif
> + }
>
> if (!scc_initialized)
> xmon_init_scc();
> @@ -122,10 +121,9 @@ xmon_write(void *handle, void *ptr, int
> eieio();
> }
>
> -#ifdef CONFIG_SMP
> - if (!locked)
> - clear_bit(0, &xmon_write_lock);
> -#endif
> + if (locked)
> + spin_unlock(&xmon_write_lock);
> +
> return nb;
> }
Ah yeah, some dirt in xmon... ;-) ack.
> Index: linux-2.6/drivers/net/ibm_newemac/mal.c
> ===================================================================
> --- linux-2.6.orig/drivers/net/ibm_newemac/mal.c
> +++ linux-2.6/drivers/net/ibm_newemac/mal.c
> @@ -318,7 +318,7 @@ static irqreturn_t mal_rxde(int irq, voi
> void mal_poll_disable(struct mal_instance *mal, struct mal_commac *commac)
> {
> /* Spinlock-type semantics: only one caller disable poll at a time */
> - while (test_and_set_bit(MAL_COMMAC_POLL_DISABLED, &commac->flags))
> + while (test_and_set_bit_lock(MAL_COMMAC_POLL_DISABLED, &commac->flags))
> msleep(1);
>
> /* Synchronize with the MAL NAPI poller */
> @@ -327,8 +327,7 @@ void mal_poll_disable(struct mal_instanc
>
> void mal_poll_enable(struct mal_instance *mal, struct mal_commac *commac)
> {
> - smp_wmb();
> - clear_bit(MAL_COMMAC_POLL_DISABLED, &commac->flags);
> + clear_bit_unlock(MAL_COMMAC_POLL_DISABLED, &commac->flags);
>
> /* Feels better to trigger a poll here to catch up with events that
> * may have happened on this channel while disabled. It will most
Ack.
> Index: linux-2.6/include/asm-powerpc/mmu_context.h
> ===================================================================
> --- linux-2.6.orig/include/asm-powerpc/mmu_context.h
> +++ linux-2.6/include/asm-powerpc/mmu_context.h
> @@ -129,7 +129,7 @@ static inline void get_mmu_context(struc
> steal_context();
> #endif
> ctx = next_mmu_context;
> - while (test_and_set_bit(ctx, context_map)) {
> + while (test_and_set_bit_lock(ctx, context_map)) {
> ctx = find_next_zero_bit(context_map, LAST_CONTEXT+1, ctx);
> if (ctx > LAST_CONTEXT)
> ctx = 0;
> @@ -158,7 +158,7 @@ static inline void destroy_context(struc
> {
> preempt_disable();
> if (mm->context.id != NO_CONTEXT) {
> - clear_bit(mm->context.id, context_map);
> + clear_bit_unlock(mm->context.id, context_map);
> mm->context.id = NO_CONTEXT;
> #ifdef FEW_CONTEXTS
> atomic_inc(&nr_free_contexts);
I don't think the previous code was wrong... it's not a locked section
and we don't care about ordering previous stores. It's an allocation, it
should be fine. In general, bitmap allocators should be allright.
Ignore the FEW_CONTEXTS stuff for now :-) At this point, it's UP only
and will be replaced sooner or later.
> Index: linux-2.6/include/asm-ppc/mmu_context.h
> ===================================================================
> --- linux-2.6.orig/include/asm-ppc/mmu_context.h
> +++ linux-2.6/include/asm-ppc/mmu_context.h
> @@ -128,7 +128,7 @@ static inline void get_mmu_context(struc
> steal_context();
> #endif
> ctx = next_mmu_context;
> - while (test_and_set_bit(ctx, context_map)) {
> + while (test_and_set_bit_lock(ctx, context_map)) {
> ctx = find_next_zero_bit(context_map, LAST_CONTEXT+1, ctx);
> if (ctx > LAST_CONTEXT)
> ctx = 0;
> @@ -157,7 +157,7 @@ static inline void destroy_context(struc
> {
> preempt_disable();
> if (mm->context.id != NO_CONTEXT) {
> - clear_bit(mm->context.id, context_map);
> + clear_bit_unlock(mm->context.id, context_map);
> mm->context.id = NO_CONTEXT;
> #ifdef FEW_CONTEXTS
> atomic_inc(&nr_free_contexts);
Same as above.
Cheers,
Ben.
next prev parent reply other threads:[~2007-10-26 3:36 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-26 2:09 [interesting] smattering of possible memory ordering bugs Nick Piggin
2007-10-26 3:35 ` Benjamin Herrenschmidt [this message]
2007-10-26 3:47 ` Nick Piggin
2007-10-26 4:32 ` Benjamin Herrenschmidt
2007-10-26 13:45 ` Dave Kleikamp
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=1193369717.7018.56.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=adaplas@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nickpiggin@yahoo.com.au \
--cc=paulus@samba.org \
--cc=shaggy@austin.ibm.com \
--cc=xfs-masters@oss.sgi.com \
/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.