Messages in this thread | | | Date | Tue, 3 May 2022 11:06:22 +0200 | From | Peter Zijlstra <> | Subject | Re: [patch 3/3] x86/fpu: Make FPU protection more robust |
| |
On Mon, May 02, 2022 at 05:58:40PM +0200, Thomas Gleixner wrote:
> >> +void fpregs_lock(void) > >> +{ > >> + if (!IS_ENABLED(CONFIG_PREEMPT_RT)) > >> + local_bh_disable(); > >> + else > >> + preempt_disable(); > > > > So I'm wondering: can we get rid of this distinction and simply do > > preempt_disable()? > > > > Or can FPU be used in softirq processing too so we want to block that > > there? > > Yes, FPU can be used legitimately in softirq processing context. > > > But even if, fpu_in_use will already state that fact... > > Right, though currently it's guaranteed that softirq processing context > can use the FPU. Quite some of the network crypto work runs in softirq > context, so this might cause a regression. If so, then this needs to be > an explicit commit on top which is easy to revert. Let me stare at it > some more.
Right, so with the:
preempt_disable(); this_cpu_write(fpu_in_use, true); barrier();
sequence it is safe against both softirq and hardirq fpu usage. The only concern is performance not correctness when dropping that local_bh_disable() thing.
So what Thomas proposes makes sense to me.
| |