linux-mips
[Top] [All Lists]

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

To: Daniel Jacobowitz <dan@debian.org>
Subject: Re: Fix some (maybe) missing syncs in bitops.h
From: Ralf Baechle <ralf@linux-mips.org>
Date: Mon, 24 Jan 2005 21:05:35 +0000
Cc: linux-mips@linux-mips.org
In-reply-to: <20050121010403.GA10371@nevyn.them.org>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <20050121010403.GA10371@nevyn.them.org>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.4.1i
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've been trying to track down a nasty signal delivery bug that I thought
> was a TIF_SIGPENDING not being visible on the other CPU early enough.  Turns
> out that wasn't the problem, but I still think the syncs are correct, so I'm
> posting the patch.

And the code indeed seems to be ok as it is.

  Ralf

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