Re: [PATCH] doc: atomic_add_unless() doesn't imply mb() on failure

Oleg Nesterov <[email protected]> wrote:

> Most implementations of atomic_add_unless() can fail (return 0) after the
> first atomic_read() (before cmpxchg). In that case we have a compiler
> barrier only.

Ummm...  I wonder if we should instead change the behaviour of
atomic_add_unless() to include an explicit smp_rmb() between the read and the
conditional jump on all archs where this isn't already implied.  Otherwise,
what governs when the initial test going to be done by the CPU?

Note that not all archs do cmpxchg() here, though I don't think that affects
your argument.

David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

---

• References:
  • [PATCH] doc: atomic_add_unless() doesn't imply mb() on failure
    • From: Oleg Nesterov <[email protected]>

• Prev by Date: Re: [PATCH 1/4] [x86] Add command line option to enable/disable hyper-threading.
• Next by Date: Re: CPUFREQ-CPUHOTPLUG: Possible circular locking dependency
• Previous by thread: [PATCH] doc: atomic_add_unless() doesn't imply mb() on failure
• Next by thread: hrtimer.h
• Index(es):
  • Date
  • Thread

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]