On 08/16/2017 02:17 PM, Steven Rostedt wrote: > On Wed, 16 Aug 2017 14:14:36 -0400 > Waiman Long <longman@xxxxxxxxxx> wrote: > >>> You also just turned the mutex into a spinlock. What happens if we just >>> preempted the owner of bdev->bd_mutex and are an RT task with higher >>> priority? This will turn into a live lock. >>> >>>> + schedule(); >>>> + } >>>> >> That is OK because I used schedule() instead of cpu_relax() for >> inserting delay. > Please explain to me how that is OK? schedule is a nop if the current > task is the highest priority task running, and it preempted the owner > of the lock. Nothing will actually schedule. > > -- Steve I haven't been thinking about RT tasks. You are right that it can be a problem in this case. I think I will have to revert back to use mutex_lock() if a RT task is running. Though in this case, the lock inversion problem will still be there. However, it is highly unlikely that a RT task will need to read write the block trace sysfs files. Thanks for the input. Cheers, Longman
