summaryrefslogtreecommitdiffstats
path: root/kernel/stacktrace.c
diff options
context:
space:
mode:
authorAndrew Morton <akpm@linux-foundation.org>2009-04-09 09:50:37 -0600
committerRusty Russell <rusty@rustcorp.com.au>2009-04-09 09:50:37 +0930
commit6b44003e5ca66a3fffeb5bc90f40ada2c4340896 (patch)
treed9dce0a39b5e66d8e760344a51ffb6de9594cd2f /kernel/stacktrace.c
parent1c99315bb36b5d776210546d438ca928dc9b1f22 (diff)
downloadlinux-stable-6b44003e5ca66a3fffeb5bc90f40ada2c4340896.tar.gz
linux-stable-6b44003e5ca66a3fffeb5bc90f40ada2c4340896.tar.bz2
linux-stable-6b44003e5ca66a3fffeb5bc90f40ada2c4340896.zip
work_on_cpu(): rewrite it to create a kernel thread on demand
Impact: circular locking bugfix The various implemetnations and proposed implemetnations of work_on_cpu() are vulnerable to various deadlocks because they all used queues of some form. Unrelated pieces of kernel code thus gained dependencies wherein if one work_on_cpu() caller holds a lock which some other work_on_cpu() callback also takes, the kernel could rarely deadlock. Fix this by creating a short-lived kernel thread for each work_on_cpu() invokation. This is not terribly fast, but the only current caller of work_on_cpu() is pci_call_probe(). It would be nice to find some other way of doing the node-local allocations in the PCI probe code so that we can zap work_on_cpu() altogether. The code there is rather nasty. I can't think of anything simple at this time... Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Diffstat (limited to 'kernel/stacktrace.c')
0 files changed, 0 insertions, 0 deletions