On Mon, Feb 03, 2025 at 11:45:37AM -0500, Steven Rostedt wrote: > > Lazy only applies to fair (and whatever bpf things end up using > > resched_curr_lazy()). > > Is that a problem? User spin locks for RT tasks are very dangerous. If an > RT task preempts the owner that is of lower priority, it can cause a > deadlock (if the two tasks are pinned to the same CPU). Which BTW, > Sebastion mentioned in the Stable RT meeting that glibc supplies a > pthread_spin_lock() and doesn't have in the man page anything about this > possible scenario. Yeah, we've known that for at least a decade if not longer. That's not new. Traditionally glibc people haven't been very RT minded -- the whole condvar thing comes to mind as well. And yes, you can still use the whole 'delay preemption' hint for RT tasks just fine. Spinlocks isn't the only thing. It can be used to make any RSEQ section more likely to succeed. > Patch 2 changes that to do what you wrote the last time. It has a max wait > time of 50us. I'm so confused, WTF do you then need the lazy crap? You're making things needlessly complicated again.
