Re: [PATCH 3/3] x86/fpu: Don't support kernel-mode FPU when irqs_disabled()

[Ingo Molnar]

* Ard Biesheuvel <ardb@xxxxxxxxxx> wrote:

> On Mon, 19 May 2025 at 10:06, Ingo Molnar <mingo@xxxxxxxxxx> wrote:
> >
> >
> > * Eric Biggers <ebiggers@xxxxxxxxxx> wrote:
> >
> > > > # echo PANIC > /sys/kernel/debug/provoke-crash/DIRECT
> > > >
> > > > Another case that likely executes with IRQs disabled (but I haven't
> > > > double checked) is reset_system(), which may return with an error, or
> > > > reboot/poweroff the machine and never return.
> > >
> > > That makes sense to me.  preempt_disable() and preempt_enable() are already
> > > allowed when IRQs are disabled, and I'm not sure why local_bh_disable() and
> > > local_bh_enable() are different.
> >
> > Because local_bh_enable() may run softirq handlers immediately if
> > there's pending softirqs, which shouldn't be done in hardirq context.
> >
> 
> Sure, but why is that mandatory?
>
> 
> preempt_disable() has preempt_enable() and preempt_enable_no_resched()
> counterparts.

> [...] Could we have a local_bh_enable_no_xxx() version that 
> re-enables async softirq processing on the current CPU but does not 
> kick off a synchronous processing run?

Yes, that's what __local_bh_enable() does, but if used it for 
kernel_fpu_end() we'd be introducing random softirq processing 
latencies. The softirq execution model is for softirqs to be 
immediately executed after local_bh_enable(), and various networking 
code is tuned to that behavior.

You can try talking the networking folks into an asynchronous 
local_bh_enable() executed on the next IRQ or the next scheduler tick 
or so, but it's a non-trivial behavioral change. It would probably also 
need user-return callback activation.

I'm pretty sure that the naive implementation would increase LAN ping 
latencies by +4 msecs on a typical distro kernel.

Thanks,

	Ingo