Messages in this thread |  | | Subject | Re: [PATCH] blktrace: Fix potentail deadlock between delete & sysfs ops | From | Waiman Long <> | Date | Wed, 16 Aug 2017 14:46:42 -0400 |
| |
On 08/16/2017 02:17 PM, Steven Rostedt wrote: > On Wed, 16 Aug 2017 14:14:36 -0400 > Waiman Long <longman@redhat.com> 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
|  |