diff options
author | Linus Torvalds <torvalds@linux-foundation.org> | 2015-02-11 21:42:10 +0100 |
---|---|---|
committer | Ingo Molnar <mingo@kernel.org> | 2015-04-17 09:57:52 +0200 |
commit | 8053871d0f7f67c7efb7f226ef031f78877d6625 (patch) | |
tree | e73fabcd5872b6b5d3d7591fd7a45ee825bfb641 /kernel/exec_domain.c | |
parent | lockdep: Make print_lock() robust against concurrent release (diff) | |
download | linux-8053871d0f7f67c7efb7f226ef031f78877d6625.tar.xz linux-8053871d0f7f67c7efb7f226ef031f78877d6625.zip |
smp: Fix smp_call_function_single_async() locking
The current smp_function_call code suffers a number of problems, most
notably smp_call_function_single_async() is broken.
The problem is that flush_smp_call_function_queue() does csd_unlock()
_after_ calling csd->func(). This means that a caller cannot properly
synchronize the csd usage as it has to.
Change the code to release the csd before calling ->func() for the
async case, and put a WARN_ON_ONCE(csd->flags & CSD_FLAG_LOCK) in
smp_call_function_single_async() to warn us of improper serialization,
because any waiting there can results in deadlocks when called with
IRQs disabled.
Rename the (currently) unused WAIT flag to SYNCHRONOUS and (re)use it
such that we know what to do in flush_smp_call_function_queue().
Rework csd_{,un}lock() to use smp_load_acquire() / smp_store_release()
to avoid some full barriers while more clearly providing lock
semantics.
Finally move the csd maintenance out of generic_exec_single() into its
callers for clearer code.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[ Added changelog. ]
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Rafael David Tinoco <inaddy@ubuntu.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/CA+55aFz492bzLFhdbKN-Hygjcreup7CjMEYk3nTSfRWjppz-OA@mail.gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Diffstat (limited to 'kernel/exec_domain.c')
0 files changed, 0 insertions, 0 deletions