summaryrefslogtreecommitdiffstats
path: root/fs/befs
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 /fs/befs
parent35c41db8f9ca76d7ca3cdc9003ac5a53292026be (diff)
downloadop-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/befs')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud