On Fri, Dec 13, 2024 at 1:00 PM Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: > > Again, allowing spin_locks being taken in hard irq context in RT, even with > trylock is going to open a nasty can of worms that will make this less > deterministic and determinism is the entire point of RT. If we allow one > user to have spin_lock_trylock() in hard irq context, we have to allow > anyone to do it. The boosting mess is a concern indeed, but looks like it's happening already. See netpoll_send_udp() -> netpoll_send_skb() that does local_irq_save() and then __netpoll_send_skb() -> HARD_TX_TRYLOCK() -> __netif_tx_trylock() -> spin_trylock() netconsole is the key mechanism for some hyperscalers. It's not a niche feature. Sounds like it's sort-of broken or rather not-working correctly by RT standards, but replacing _xmit_lock with raw_spin_lock is probably not an option. So either netpoll needs to be redesigned somehow, since it has to printk->netcons->udp->skb->tx_lock->xmit on the wire, otherwise dmesg messages will be lost. or make PI aware of this. local_irq_save() is not an issue per-se, it's printk->necons that can be called from any context including hard irq. For the purpose of this patch set I think I have to if (IS_ENABLED(CONFIG_PREEMPT_RT) && (in_hardirq() || in_nmi())) goto out; Looks like it's safe to call spin_trylock() on RT after local_irq_save() and/or when irqs_disabled(). It's a hardirq/nmi context that is a problem.
