On 9/12/19 12:40 AM, Davidlohr Bueso wrote: > > I also think that the right solution is within the mm instead of adding > a new api to rwsem and the extra complexity/overhead to osq _just_ for > this > case. We've managed to not need timeout extensions in our locking > primitives > thus far, which is a good thing imo. Adding a variant with timeout can be useful in resolving some potential deadlock issues found by lockdep. Anyway, there were talk about merging rt-mutex and regular mutex in the LPC last week. So we will need to have mutex_lock() variant with timeout for that to happen. Cheers, Longman
