On Wed, Jul 11, 2018 at 09:19:44AM -0400, Steven Rostedt wrote:
protection to prevent something like the following case: a spin_lock is taken. Then lockdep_acquired is called. That does a raw_local_irq_save and then sets lockdep_recursion, and then calls __lockdep_acquired. In this function, a call to get_lock_stats happens which calls preempt_disable, which calls trace IRQS off somewhere which enters my tracepoint code and sets the tracing_irq_cpu flag to prevent recursion. This flag is then never cleared causing lockdep paths to never be entered and thus causing splats and other bad things.
Would it not be much easier to avoid that entirely, afaict all get/put_lock_stats() callers already have IRQs disabled, so that (traced) preempt fiddling is entirely superfluous.
Agreed. Looks like a good clean up.
So actually with or without the clean up, I don't see any issues with dropping lockdep_recursing in my tests at the moment. I'm not sure something else changed between then and now causing the issue to go away. I can include Peter's clean up in my series though if he's Ok with it since you guys agree its a good clean up anyway. Would you prefer I did that, and then also dropped the lockdep_recursing checks? Or should I keep the lockdep_recursing() checks just to be safe? Do you see cases where you want irqsoff tracing while lockdep_recursing() is true?
thanks,
- Joel
-- To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html