summaryrefslogtreecommitdiffstats
path: root/security/tomoyo
diff options
context:
space:
mode:
authorBenjamin Herrenschmidt <benh@kernel.crashing.org>2014-04-24 16:14:25 +1000
committerBenjamin Herrenschmidt <benh@kernel.crashing.org>2014-04-28 13:08:50 +1000
commit298b34d7d578c3b4325248b823f3d83a8ea1541c (patch)
tree3b77b3f53752ad216a822a706d0a3ac80949f92d /security/tomoyo
parent63aecfb20a6629f1ca91d7a052f87988ceb6dd53 (diff)
downloadlinux-298b34d7d578c3b4325248b823f3d83a8ea1541c.tar.gz
linux-298b34d7d578c3b4325248b823f3d83a8ea1541c.tar.bz2
linux-298b34d7d578c3b4325248b823f3d83a8ea1541c.zip
powerpc/powernv: Fix kexec races going back to OPAL
We have a subtle race when sending CPUs back to OPAL on kexec. We mark them as "in real mode" right before we send them down. Once we've booted the new kernel, it might try to call opal_reinit_cpus() to change endianness, and that requires all CPUs to be spinning inside OPAL. However there is no synchronization here and we've observed cases where the returning CPUs hadn't established their new state inside OPAL before opal_reinit_cpus() is called, causing it to fail. The proper fix is to actually wait for them to go down all the way from the kexec'ing kernel. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Diffstat (limited to 'security/tomoyo')
0 files changed, 0 insertions, 0 deletions