summaryrefslogtreecommitdiffstats
path: root/crypto/scatterwalk.c
diff options
context:
space:
mode:
authorArnd Bergmann <arnd@arndb.de>2010-02-27 19:49:37 +0100
committerFrederic Weisbecker <fweisbec@gmail.com>2010-04-10 15:34:21 +0200
commit5534ecb2dda04345e8243901e0e49599228b4273 (patch)
tree1d09ca0bcc6fcac12310300a306c233e350151c7 /crypto/scatterwalk.c
parent2eaa9cfdf33b8d7fb7aff27792192e0019ae8fc6 (diff)
downloadop-kernel-dev-5534ecb2dda04345e8243901e0e49599228b4273.zip
op-kernel-dev-5534ecb2dda04345e8243901e0e49599228b4273.tar.gz
ptrace: kill BKL in ptrace syscall
The comment suggests that this usage is stale. There is no bkl in the exec path so if there is a race lurking there, the bkl in ptrace is not going to help in this regard. Overview of the possibility of "accidental" races this bkl might protect: - ptrace_traceme() is protected against task removal and concurrent read/write on current->ptrace as it locks write tasklist_lock. - arch_ptrace_attach() is serialized by ptrace_traceme() against concurrent PTRACE_TRACEME or PTRACE_ATTACH - ptrace_attach() is protected the same way ptrace_traceme() and in turn serializes arch_ptrace_attach() - ptrace_check_attach() does its own well described serializing too. There is no obvious race here. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com> Acked-by: Oleg Nesterov <oleg@redhat.com> Acked-by: Roland McGrath <roland@redhat.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Roland McGrath <roland@redhat.com>
Diffstat (limited to 'crypto/scatterwalk.c')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud