linux-mips
[Top] [All Lists]

Re: Fix some (maybe) missing syncs in bitops.h

To: Ralf Baechle <ralf@linux-mips.org>
Subject: Re: Fix some (maybe) missing syncs in bitops.h
From: Daniel Jacobowitz <dan@debian.org>
Date: Mon, 24 Jan 2005 16:21:25 -0500
Cc: linux-mips@linux-mips.org
In-reply-to: <20050124210535.GA2797@linux-mips.org>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <20050121010403.GA10371@nevyn.them.org> <20050124210535.GA2797@linux-mips.org>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.5.5.1+cvs20040105i
On Mon, Jan 24, 2005 at 09:05:35PM +0000, Ralf Baechle wrote:
> On Thu, Jan 20, 2005 at 08:04:03PM -0500, Daniel Jacobowitz wrote:
> 
> > If I'm reading the broadcom documentation right, the semantics of set_bit
> > and test_and_set_bit require a sync at the end on this architecture.
> 
> Linux semantics of the bit functions are less than obvious.  The functions
> set_bit, change_bit and clear_bit may be atomic but they don't have memory
> barrier semantics, that is memory accesses before the function call may be
> reordered to be executed after the function has been completed or vice
> versa.  The test_and_{set,clear,change}_bit functions however have memory
> barrier semantics.  The intended use is something like:
> 
>       if (!test_and_set_bit(bitnr, bitmap)) {
>               /* we got the bit */
> 
>               ... do something ...
> 
>               smp_mb__before_clear_bit();
>               clear_bit(bitnr, bitmap);
>               smp_mb__after_clear_bit();
>       } else
>               printk("Bit was already set by somebody else\n");

I know that clear_bit has these semantics.  But are you sure about
set_bit/change_bit?  The comments in clear_bit in every bitops.h
explicitly say it doesn't have a memory barrier, but those on set_bit
don't.  At least some platforms use acquire semantics.

I don't see where there might be a barrier on the signal_wake_up path
after the flag is set, but since the patch didn't fix my problems,
you're probably right that there is one somewhere :-)

-- 
Daniel Jacobowitz

<Prev in Thread] Current Thread [Next in Thread>