aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/crypto
diff options
context:
space:
mode:
authorSuresh Siddha <suresh.b.siddha@intel.com>2012-09-17 10:37:26 -0700
committerHerbert Xu <herbert@gondor.apana.org.au>2012-09-27 13:32:15 +0800
commitb6f3fefe1fa1e8ea8f6b654e7d552253373cd1c0 (patch)
tree756ea912317e9a04fe5a5b4dfeb996e2511f10e9 /drivers/crypto
parentcrypto: tegra-aes - fix error return code (diff)
downloadlinux-dev-b6f3fefe1fa1e8ea8f6b654e7d552253373cd1c0.tar.xz
linux-dev-b6f3fefe1fa1e8ea8f6b654e7d552253373cd1c0.zip
crypto, tcrypt: remove local_bh_disable/enable() around local_irq_disable/enable()
Ran into this while looking at some new crypto code using FPU hitting a WARN_ON_ONCE(!irq_fpu_usable()) in the kernel_fpu_begin() on a x86 kernel that uses the new eagerfpu model. In short, current eagerfpu changes return 0 for interrupted_kernel_fpu_idle() and the in_interrupt() thinks it is in the interrupt context because of the local_bh_disable(). Thus resulting in the WARN_ON(). Remove the local_bh_disable/enable() calls around the existing local_irq_disable/enable() calls. local_irq_disable/enable() already disables the BH. [ If there are any other legitimate users calling kernel_fpu_begin() from the process context but with BH disabled, then we can look into fixing the irq_fpu_usable() in future. ] Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> Cc: Tim Chen <tim.c.chen@linux.intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Diffstat (limited to 'drivers/crypto')
0 files changed, 0 insertions, 0 deletions