public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Christoph Lameter <clameter@sgi.com>
Cc: akpm@osdl.org, Zoltan.Menyhart@free.fr,
	linux-kernel@vger.kernel.org, linux-ia64@vger.kernel.org
Subject: Re: Fix unlock_buffer() to work the same way as bit_unlock()
Date: Tue, 28 Mar 2006 18:10:51 +1000	[thread overview]
Message-ID: <4428EF8B.7040202@yahoo.com.au> (raw)
In-Reply-To: <Pine.LNX.4.64.0603271953150.7469@schroedinger.engr.sgi.com>

Christoph Lameter wrote:
> Currently unlock_buffer() contains a smb_mb__after_clear_bit() which is 
> weird because bit_spin_unlock() uses smb_mb__before_clear_bit():
> 
>>From include/linux/bit_spinlock.h:
> 
> static inline void bit_spin_unlock(int bitnum, unsigned long *addr)
> {
>         smp_mb__before_clear_bit();
>         clear_bit(bitnum, addr);
>         preempt_enable();
>         __release(bitlock);
> }
> 
> For most architectures there is no difference because both
> smp_mb__after_clear_bit() and smp_mb__before_clear_bit() are both
> memory barriers and clear_buffer_locked() is an atomic operation.
> However, they differ under IA64.
> 
> Note that this potential race has never been seen under IA64. It was 
> discovered by inspection by Zoltan Menyhart <Zoltan.Menyhart@free.fr>. 
> 
> Regardless if this is a true race or not, I think the unlock sequence 
> needs to be the same for bit locks and unlock_buffer(). Maybe 
> unlock_buffer and lock_buffer better use bit spinlock operations?
> 
> Change unlock_buffer() to work the same way as bit_spin_unlock.
> 

OK, that's fair enough and I guess you do need a barrier there.
However, should the mb__after barrier still remain? The comment
in wake_up_bit suggests yes, and there is similar code in
unlock_page.

Let's see... I guess the race is that the waitqueue load could be
completed the clearing of the bit becomes visible, so it may
appear to be empty, but another CPU may find the bit locked after
it has added the task to the waitqueue. I think?

Also, I think there is still the issue of ia64 not having the
correct memory consistency semantics. To start with, all the bitops
and atomic ops which both modify their operand and return a value
should be full memory barriers before and after the operation,
according to Documentation/atomic_ops.txt.

Secondly, I don't think smp_mb__before/after are just defined to
have aquire or relese semantics, but should be full barriers.

> Signed-off-by: Christoph Lameter <clameter@sgi.com>
> 
> Index: linux-2.6/fs/buffer.c
> ===================================================================
> --- linux-2.6.orig/fs/buffer.c	2006-03-27 14:09:54.000000000 -0800
> +++ linux-2.6/fs/buffer.c	2006-03-27 19:40:32.000000000 -0800
> @@ -78,8 +78,8 @@ EXPORT_SYMBOL(__lock_buffer);
>  
>  void fastcall unlock_buffer(struct buffer_head *bh)
>  {
> +	smp_mb__before_clear_bit();
>  	clear_buffer_locked(bh);
> -	smp_mb__after_clear_bit();
>  	wake_up_bit(&bh->b_state, BH_Lock);
>  }
>  
> 


-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 

  reply	other threads:[~2006-03-28 10:40 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-28  3:59 Fix unlock_buffer() to work the same way as bit_unlock() Christoph Lameter
2006-03-28  8:10 ` Nick Piggin [this message]
2006-03-28 18:53   ` Chen, Kenneth W
2006-03-28 21:42     ` Zoltan Menyhart
2006-03-28 23:48       ` Christoph Lameter
2006-03-29  0:07         ` Nick Piggin
2006-03-29  2:23           ` Christoph Lameter
2006-03-29  2:35             ` Nick Piggin
2006-03-29  6:46               ` Chen, Kenneth W
2006-03-29  7:11                 ` Christoph Lameter
2006-03-30  1:34                 ` Nick Piggin
2006-03-29  0:12         ` Chen, Kenneth W
2006-03-29  0:27         ` Chen, Kenneth W
2006-03-29  0:47           ` Christoph Lameter
2006-03-29  1:39             ` Chen, Kenneth W
2006-03-29 12:16               ` Zoltan Menyhart
2006-03-30  1:56                 ` Nick Piggin
2006-03-29 10:57         ` Zoltan Menyhart
2006-03-29  6:50   ` Chen, Kenneth W
2006-03-30  1:36     ` Nick Piggin
     [not found] ` <442AA13B.3050104@bull.net>
2006-03-30  1:57   ` Nick Piggin
  -- strict thread matches above, loose matches on Subject: below --
2006-03-29 18:33 Boehm, Hans
2006-03-29 19:11 ` Grant Grundler
2006-03-29 19:31 Boehm, Hans
2006-03-29 22:17 ` Christoph Lameter
2006-03-29 22:56 Boehm, Hans
2006-03-29 23:33 ` Christoph Lameter
2006-03-29 23:49   ` Chen, Kenneth W
2006-03-29 23:50     ` Christoph Lameter
2006-03-29 23:50     ` Grant Grundler
2006-03-30  8:43   ` Zoltan Menyhart
2006-03-30  8:55     ` Nick Piggin
2006-03-30 19:11       ` Christoph Lameter
2006-03-30 17:17     ` Christoph Lameter
2006-03-30 17:57 Boehm, Hans
2006-03-30 18:17 ` Christoph Lameter
2006-03-30 22:26 Boehm, Hans

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=4428EF8B.7040202@yahoo.com.au \
    --to=nickpiggin@yahoo.com.au \
    --cc=Zoltan.Menyhart@free.fr \
    --cc=akpm@osdl.org \
    --cc=clameter@sgi.com \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox