On Thu, Mar 5, 2026 at 12:30 PM Waiman Long <[email protected]> wrote: > > On 3/4/26 10:08 PM, Yafang Shao wrote: > > On Thu, Mar 5, 2026 at 11:00 AM Steven Rostedt <[email protected]> wrote: > >> On Thu, 5 Mar 2026 10:33:00 +0800 > >> Yafang Shao <[email protected]> wrote: > >> > >>> Other tools may also read available_filter_functions, requiring each > >>> one to be patched individually to avoid this flaw—a clearly > >>> impractical solution. > >> What exactly is the issue? > > It makes no sense to spin unnecessarily when it can be avoided. We > > continuously improve the kernel to do the right thing—and unnecessary > > spinning is certainly not the right thing. > > > >> If a task does a while 1 in user space, it > >> wouldn't be much different. > > The while loop in user space performs actual work, whereas useless > > spinning does nothing but burn CPU cycles. My point is simple: if this > > unnecessary spinning isn't already considered an issue, it should > > be—it's something that clearly needs improvement. > > The whole point of optimistic spinning is to reduce the lock acquisition > latency. If the waiter sleeps, the unlock operation will have to wake up > the waiter which can have a variable latency depending on how busy the > system is at the time. Yes, it is burning CPU cycles while spinning, > Most workloads will gain performance with this optimistic spinning > feature. You do have a point that for system monitoring tools that > observe the system behavior, they shouldn't burn that much CPU times > that affect performance of real workload that the tools are monitoring.
Exactly. ftrace is intended for debugging and should not significantly impact real workloads. Therefore, it's reasonable to make it sleep if it cannot acquire the lock immediately, rather than spinning and consuming CPU cycles. > > BTW, you should expand the commit log of patch 1 to include the > rationale of why we should add this feature to mutex as the information > in the cover letter won't get included in the git log if this patch > series is merged. You should also elaborate in comment on under what > conditions should this this new mutex API be used. Sure. I will update it. BTW, these issues are notably hard to find. I suspect there are other locks out there with the same problem. -- Regards Yafang
