Re: [tip: locking/core] locking/mutex: Document that mutex_unlock() is non-atomic
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- Subject: Re: [tip: locking/core] locking/mutex: Document that mutex_unlock() is non-atomic
- From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
- Date: Fri, 1 Dec 2023 13:18:08 +0100
- Cc: linux-tip-commits@xxxxxxxxxxxxxxx, Jann Horn <jannh@xxxxxxxxxx>, Ingo Molnar <mingo@xxxxxxxxxx>, x86@xxxxxxxxxx
- In-reply-to: <170142744948.398.4203675877225809071.tip-bot2@tip-bot2>
- References: <20231130204817.2031407-1-jannh@google.com> <170142744948.398.4203675877225809071.tip-bot2@tip-bot2>
On Fri, Dec 01, 2023 at 10:44:09AM -0000, tip-bot2 for Jann Horn wrote:
> --- a/Documentation/locking/mutex-design.rst
> +++ b/Documentation/locking/mutex-design.rst
> @@ -101,6 +101,12 @@ features that make lock debugging easier and faster:
> - Detects multi-task circular deadlocks and prints out all affected
> locks and tasks (and only those tasks).
>
> +Releasing a mutex is not an atomic operation: Once a mutex release operation
I still object to this confusing usage of atomic. Also all this also
applies to all sleeping locks, rwsem etc. I don't see why we need to
special case mutex here.
Also completion_done() has an explicit lock+unlock on wait.lock to
deal with this there.
[Index of Archives]
[Linux Stable Commits]
[Linux Stable Kernel]
[Linux Kernel]
[Linux USB Devel]
[Linux Video &Media]
[Linux Audio Users]
[Yosemite News]
[Linux SCSI]