diff options
author | 2015-06-25 15:02:46 -0700 | |
---|---|---|
committer | 2015-06-25 17:00:41 -0700 | |
commit | cb426e99ff9225e94fb56bd4c5cfcce8b78a3904 (patch) | |
tree | a7e47c66d32182613e9c9735ae32e48421b24b2e /tools/perf/scripts/python/call-graph-from-postgresql.py | |
parent | drivers/firmware/memmap.c: fix kernel-doc format (diff) | |
download | linux-dev-cb426e99ff9225e94fb56bd4c5cfcce8b78a3904.tar.xz linux-dev-cb426e99ff9225e94fb56bd4c5cfcce8b78a3904.zip |
checkpatch: check for uncommented waitqueue_active()
Linus sayeth:
: Pretty much every single time people use this "if
: (waitqueue_active())" model, it tends to be a bug, because it means
: that there is zero serialization with people who are just about to go
: to sleep. It's fundamentally racy against all the "wait_event()" loops
: that carefully do memory barriers between testing conditions and going
: to sleep, because the memory barriers now don't exist on the waking
: side.
:
: So I'm making a new rule: if you use waitqueue_active(), I want an
: explanation for why it's not racy with the waiter. A big comment about
: the memory ordering, or about higher-level locks that are held by the
: caller, or something.
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'tools/perf/scripts/python/call-graph-from-postgresql.py')
0 files changed, 0 insertions, 0 deletions