diff options
author | Suresh Siddha <suresh.b.siddha@intel.com> | 2012-09-17 10:37:26 -0700 |
---|---|---|
committer | Herbert Xu <herbert@gondor.apana.org.au> | 2012-09-27 13:32:15 +0800 |
commit | b6f3fefe1fa1e8ea8f6b654e7d552253373cd1c0 (patch) | |
tree | 756ea912317e9a04fe5a5b4dfeb996e2511f10e9 /fs/namei.c | |
parent | 35c41db8f9ca76d7ca3cdc9003ac5a53292026be (diff) | |
download | op-kernel-dev-b6f3fefe1fa1e8ea8f6b654e7d552253373cd1c0.zip op-kernel-dev-b6f3fefe1fa1e8ea8f6b654e7d552253373cd1c0.tar.gz |
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 'fs/namei.c')
0 files changed, 0 insertions, 0 deletions