From: Ingo Molnar <mingo@kernel.org>
To: Davidlohr Bueso <dave@stgolabs.net>
Cc: peterz@infradead.org, dhowells@redhat.com,
linux-afs@lists.infradead.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, mingo@redhat.com,
tglx@linutronix.de, will@kernel.org,
Davidlohr Bueso <dbueso@suse.de>
Subject: Re: [PATCH] Revert "locking/mutex: Complain upon mutex API misuse in IRQ contexts"
Date: Wed, 11 Dec 2019 00:26:55 +0100 [thread overview]
Message-ID: <20191210232655.GA80975@gmail.com> (raw)
In-Reply-To: <20191210220523.28540-1-dave@stgolabs.net>
* Davidlohr Bueso <dave@stgolabs.net> 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.
Not sure where that SHA1 came from (it's not in Linus's tree), the right
one is:
a0855d24fc22: ("locking/mutex: Complain upon mutex API misuse in IRQ contexts")
I've fixed the changelog accordingly.
Thanks,
Ingo
next prev parent reply other threads:[~2019-12-10 23:27 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-10 17:32 [PATCH] rxrpc: Mutexes are unusable from softirq context, so use rwsem instead David Howells
2019-12-10 19:10 ` Peter Zijlstra
2019-12-10 19:30 ` Peter Zijlstra
2019-12-10 22:05 ` [PATCH] Revert "locking/mutex: Complain upon mutex API misuse in IRQ contexts" Davidlohr Bueso
2019-12-10 22:32 ` David Howells
2019-12-10 23:26 ` Ingo Molnar [this message]
2019-12-10 23:35 ` [tip: locking/urgent] " tip-bot2 for Davidlohr Bueso
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191210232655.GA80975@gmail.com \
--to=mingo@kernel.org \
--cc=dave@stgolabs.net \
--cc=dbueso@suse.de \
--cc=dhowells@redhat.com \
--cc=linux-afs@lists.infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.