summaryrefslogtreecommitdiffstats
path: root/arch/sparc/kernel/entry.S
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@g5.osdl.org>2006-11-04 22:03:00 +0100
committerLinus Torvalds <torvalds@g5.osdl.org>2006-11-04 22:03:00 +0100
commit10b1fbdb0a0ca91847a534ad26d0bc250c25b74f (patch)
tree67a3e6d7069e9281b0f5819f4acf91d7150a5d74 /arch/sparc/kernel/entry.S
parentFix unlikely (but possible) race condition on task->user access (diff)
downloadlinux-10b1fbdb0a0ca91847a534ad26d0bc250c25b74f.tar.xz
linux-10b1fbdb0a0ca91847a534ad26d0bc250c25b74f.zip
Make sure "user->sigpending" count is in sync
The previous commit (45c18b0bb579b5c1b89f8c99f1b6ffa4c586ba08, aka "Fix unlikely (but possible) race condition on task->user access") fixed a potential oops due to __sigqueue_alloc() getting its "user" pointer out of sync with switch_user(), and accessing a user pointer that had been de-allocated on another CPU. It still left another (much less serious) problem, where a concurrent __sigqueue_alloc and swich_user could cause sigqueue_alloc to do signal pending reference counting for a _different_ user than the one it then actually ended up using. No oops, but we'd end up with the wrong signal accounting. Another case of Oleg's eagle-eyes picking up the problem. This is trivially fixed by just making sure we load whichever "user" structure we decide to use (it doesn't matter _which_ one we pick, we just need to pick one) just once. Acked-by: Oleg Nesterov <oleg@tv-sign.ru> Cc: Andrew Morton <akpm@osdl.org> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Diffstat (limited to 'arch/sparc/kernel/entry.S')
0 files changed, 0 insertions, 0 deletions