linux-kernel - Problem with WARN_ON in mutex

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 05 Dec 2019 12:02:24 +0000
From:   David Howells <dhowells@...hat.com>
To:     Davidlohr Bueso <dave@...olabs.net>,
        Peter Zijlstra (Intel) <peterz@...radead.org>,
        Ingo Molnar <mingo@...nel.org>
cc:     dhowells@...hat.com, linux-kernel@...r.kernel.org
Subject: Problem 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))
		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