Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx> wrote: > > Not sure this is correct. If RT allows to migrate in BH before > > the local lock is taken, then the if (unlikely(!irq_fpu_usable())) > > check needs to be done after the local lock was taken, no? > > Looking at this again, that irq_fpu_usable() itself looks slightly > placed at the wrong spot. It should be > | if (!irq_fpu_usable()) > | return fallback_variant(); > | local_bh_disable(); > > The reason is that if you expect calls from hardirq context then you > shouldn't disable BH. Lockdep enabled kernels should complain in this > case. But then this is networking and I would expect everything here > should be injected via NAPI/ softirq (either via driver's NAPI or > backlog's). This is never called from hardirq context, its always process context or softirq. Are you saying that the irq_fpu_usable() is bogus and can be axed? > I've just started rebasing this patch on top of the testing branch. I > see that you moved that code a bit around. I can't acquire the > local_lock_t within kernel_fpu_begin(). I would need to move this back > to pipapo_get_avx2(). Sure, I don't see why it can't be moved back to pipapo_get_avx2(). You can also just resubmit vs. nf-next main and I can rebase my patches on top of the local_lock changes, up to you.
