[Top] [All Lists]

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

To: Ralf Baechle <>
Subject: Re: Fix some (maybe) missing syncs in bitops.h
From: Daniel Jacobowitz <>
Date: Mon, 24 Jan 2005 16:21:25 -0500
In-reply-to: <>
Original-recipient: rfc822;
References: <> <>
User-agent: Mutt/
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>