linux-kernel - mutex ownership (was: Re: [PATCH 19/24] Unionfs: Helper macros/inlines)

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-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1168333376.12503.22.camel@twins>
Date:	Tue, 09 Jan 2007 10:02:56 +0100
From:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
To:	Andrew Morton <akpm@...l.org>, Ingo Molnar <mingo@...e.hu>
Cc:	linux-kernel <linux-kernel@...r.kernel.org>,
	arjan <arjan@...radead.org>
Subject: mutex ownership (was: Re: [PATCH 19/24] Unionfs: Helper
	macros/inlines)

On Mon, 2007-01-08 at 13:28 -0800, Andrew Morton wrote:

> Please use mutexes where possible.  Semaphores should only be used when
> their counting feature is employed.  And, arguably, in situations where a
> lock is locked and unlocked from different threads, because this presently
> triggers mutex debugging warnings, although we should find a way of fixing
> this in the mutex code.

Its a fundamental property of a mutex, not a shortcoming. A mutex has an
owner, the one that takes and releases the resource. This allows things
such as Priority Inheritance to boost owners.

'fixing' this takes away much of what a mutex is.

That said, it seems some folks really want this to happen, weird as it
may be. I'm not sure if all these cases are because of wrong designs. A
possible extension to the mutex interface might be something like this:

  mutex_pass_owner(struct task_struct *task);

which would be an atomic unlock/lock pair where the current task
releases the resource and the indicated task gains it. However it must
be understood that from the POV of 'current' this should be treated as
an unlock action.

Ingo, I'd much rather see something like this than the proposed

  mutex_unlock_dont_warn_if_a_different_task_did_it()

wart. Esp. since it preserves the mutex semantics and properties.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/