Messages in this thread | | | From | David Howells <> | Subject | Problem with WARN_ON in mutex_trylock() and rxrpc | Date | Thu, 05 Dec 2019 12:02:24 +0000 |
| |
Hi Davidlohr,
commit a0855d24fc22d49cdc25664fb224caee16998683 ("locking/mutex: Complain upon mutex API misuse in IRQ contexts") is a bit of a problem for rxrpc, though nothing that shouldn't be reasonably easy to solve, I think.
What happens is that rxrpc_new_incoming_call(), which is called in softirq context, calls mutex_trylock() to prelock a new incoming call:
/* Lock the call to prevent rxrpc_kernel_send/recv_data() and * sendmsg()/recvmsg() inconveniently stealing the mutex once the * notification is generated. * * The BUG should never happen because the kernel should be well * behaved enough not to access the call before the first notification * event and userspace is prevented from doing so until the state is * appropriate. */ if (!mutex_trylock(&call->user_mutex)) BUG();
before publishing it. This used to work fine, but now there are big splashy warnings every time a new call comes in.
No one else can see the lock at this point, but I need to lock it so that lockdep doesn't complain later. However, I can't lock it in the preallocator - again because that upsets lockdep.
David
| |