Davidlohr Bueso <dave@xxxxxxxxxxxx> wrote: > This ended up causing some noise in places such as rxrpc running in softirq. > > The warning is misleading in this case as the mutex trylock and unlock > operations are done within the same context; and therefore we need not > worry about the PI-boosting issues that comes along with no single-owner > lock guarantees. > > While we don't want to support this in mutexes, there is no way out of > this yet; so lets get rid of the WARNs for now, as it is only fair to > code that has historically relied on non-preemptible softirq guarantees. > In addition, changing the lock type is also unviable: exclusive rwsems > have the same issue (just not the WARN_ON) and counting semaphores > would introduce a performance hit as mutexes are a lot more optimized. > > This reverts commit 5d4ebaa87329ef226e74e52c80ac1c62e4948987. > > Signed-off-by: Davidlohr Bueso <dbueso@xxxxxxx> Tested-by: David Howells <dhowells@xxxxxxxxxx>
