On 2016-09-19 10:14, Peter Zijlstra wrote: > On Mon, Sep 19, 2016 at 10:01:49AM +0200, Peter Rosin wrote: >> Or, do what the i2c-mux code is doing and use an rt_mutex instead >> of an ordinary mutex. That way you are very sure to not get any >> lockdep splat ... at all. Ok, sorry, that was not a serious >> suggestion, but it would be a tad bit simpler to implement... > > So I find it weird that people use rt_mutex as a locking primitive, > since its only that one lock that then does PI and all the other locks > that are related still create inversions. So, someone took the bait :-) Yes, I too find it weird, and would like to get rid of it. It's just odd. It's been some years since the start though, waaay before me entering kernel space. https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=194684e596af4b But it's hard to argue with the numbers given in the discussion: http://linux-i2c.vger.kernel.narkive.com/nokldJcc/patch-1-1-i2c-prevent-priority-inversion-on-top-of-bus-lock Has anything happened to the regular mutex implementation that might have changed the picture? *crosses fingers* > In any case, since people have started doing this, adding lockdep > support for rt_mutex is on the todo _somewhere_, so don't expect that to > avoid splats forever. I was actually looking quite hard to find out how I should declare the lockdep class for the rt_mutex in order to prevent future splats, before I realized that it wasn't even possible... Cheers, Peter -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
