[lkml]   [2019]   [Dec]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectProblem with WARN_ON in mutex_trylock() and rxrpc
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))

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.


 \ /
  Last update: 2019-12-05 13:02    [W:0.046 / U:1.436 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site