The patch titled
doc: atomic_add_unless() doesn't imply mb() on failure
has been added to the -mm tree. Its filename is
doc-atomic_add_unless-doesnt-imply-mb-on-failure.patch
See http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt to find
out what to do about this
------------------------------------------------------
Subject: doc: atomic_add_unless() doesn't imply mb() on failure
From: Oleg Nesterov <oleg@xxxxxxxxxx>
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.
Signed-off-by: Oleg Nesterov <oleg@xxxxxxxxxx>
Cc: David Howells <dhowells@xxxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxx>
---
Documentation/atomic_ops.txt | 3 ++-
Documentation/memory-barriers.txt | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff -puN Documentation/atomic_ops.txt~doc-atomic_add_unless-doesnt-imply-mb-on-failure Documentation/atomic_ops.txt
--- a/Documentation/atomic_ops.txt~doc-atomic_add_unless-doesnt-imply-mb-on-failure
+++ a/Documentation/atomic_ops.txt
@@ -137,7 +137,8 @@ If the atomic value v is not equal to u,
returns non zero. If v is equal to u then it returns zero. This is done as
an atomic operation.
-atomic_add_unless requires explicit memory barriers around the operation.
+atomic_add_unless requires explicit memory barriers around the operation
+unless it fails (returns 0).
atomic_inc_not_zero, equivalent to atomic_add_unless(v, 1, 0)
diff -puN Documentation/memory-barriers.txt~doc-atomic_add_unless-doesnt-imply-mb-on-failure Documentation/memory-barriers.txt
--- a/Documentation/memory-barriers.txt~doc-atomic_add_unless-doesnt-imply-mb-on-failure
+++ a/Documentation/memory-barriers.txt
@@ -1492,7 +1492,7 @@ about the state (old or new) implies an
atomic_dec_and_test();
atomic_sub_and_test();
atomic_add_negative();
- atomic_add_unless();
+ atomic_add_unless(); /* when succeeds (returns 1) */
test_and_set_bit();
test_and_clear_bit();
test_and_change_bit();
_
Patches currently in -mm which might be from oleg@xxxxxxxxxx are
taskstats_exit_alloc-optimize-simplify.patch
taskstats-cleanup-do_exit-path.patch
taskstats-cleanup-signal-stats-allocation.patch
taskstats-factor-out-reply-assembling.patch
taskstats-use-nla_reserve-for-reply-assembling.patch
taskstats-cleanup-reply-assembling.patch
doc-atomic_add_unless-doesnt-imply-mb-on-failure.patch
tty-signal-tty-locking.patch
do_task_stat-dont-take-tty_mutex.patch
do_acct_process-dont-take-tty_mutex.patch
trivial-make-set_special_pids-static.patch
sys_unshare-remove-a-broken-clone_sighand-code.patch
sys_setpgid-eliminate-unnecessary-do_each_task_pidpidtype_pgid.patch
session_of_pgrp-kill-unnecessary-do_each_task_pidpidtype_pgid.patch
pidhash-temporary-debug-checks.patch
-
To unsubscribe from this list: send the line "unsubscribe mm-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
