I'd ask @paulmckrcu
That's trivial to solve in kernel because disabling irqs takes at most a couple cycles. OTOH sigprocmask is syscall.
-
-
BTW any tips on debugging RCU stalls (not perm, just long, >20s) in idle task with dyntick? :-)
-
(1) https://www.kernel.org/doc/Documentation/RCU/stallwarn.txt … (2) but please email me dmesg + .config + version
-
New SoC support going upstream, stalls introduced by Linus's in-progress-merge-window pulls. Want to find/report/fix.
-
I've read that doc but it's not helping me figure out why the stall is happening. Guess is bad timing of infreq wakes
-
Please email me dmesg+.config+version (for example, SHA1). Maybe someone broke something, maybe me. :-)
-
Will do. I don't know if it's easily reproducible on hw you'd have access to, though. :-P
-
I will be cranking up tests soon, but yes, irreproducibility is much of the story of my life. :-)
End of conversation
New conversation -
-
-
In theory. But in practice, you can't acquire a non-irq-disable spinlock while holding an irq-disable spinlock.
-
Right. But really any spinlock should be irq-disabling. Otherwise waiters can spin way too long.
-
Preemption disabling, yes. On irq-disabling, there are thousands of Linux-kernel lock acquisitions saying otherwise.
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.