linux-kernel - Re: [PATCH -v5][RFC]: mutex: implement adaptive spinning

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]

Date:	Wed, 07 Jan 2009 22:27:19 -0500
From:	Gregory Haskins <ghaskins@...ell.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	Andi Kleen <andi@...stfloor.org>, Matthew Wilcox <matthew@....cx>,
	Steven Rostedt <rostedt@...dmis.org>,
	Peter Zijlstra <peterz@...radead.org>,
	paulmck@...ux.vnet.ibm.com, Ingo Molnar <mingo@...e.hu>,
	Chris Mason <chris.mason@...cle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	linux-btrfs <linux-btrfs@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Nick Piggin <npiggin@...e.de>,
	Peter Morreale <pmorreale@...ell.com>,
	Sven Dietrich <SDietrich@...ell.com>
Subject: Re: [PATCH -v5][RFC]: mutex: implement adaptive spinning

[resend: i fat fingered the reply-to-all for a few messages]

>>> Linus Torvalds <torvalds@...ux-foundation.org> 01/07/09 6:20 PM >>>

>On Wed, 7 Jan 2009, Linus Torvalds wrote:
>> >
>> > "Is get_task_struct() really that bad?"
>>
>> Yes. It's an atomic access (two, in fact, since you need to release it
>> too), which is a huge deal if we're talking about a timing-critical
>> section of code.
>
>There's another issue: you also need to lock the thing that gives you the
>task pointer in the first place. So it's not sufficient to do
>get_task_struct(), you also need to do it within a context where you know
>that the pointer is not going away _while_ you do it.

In my defense, the -rt versions of the patches guarantee this is ok
based on a little hack:

"if the owner holds the mutex, and you old the wait-lock, you guarantee
owner cannot exit". Therefore get_task_struct is guaranteed not to race
if you take it while holding wait-lock. (This is, in fact, why the
original design had a loop within a loop...the inner loop would break
when it wanted the outer-loop to reacquire wait-lock for things such as
re-acquiring owner/get-task

This is in part enforced by the fact that in -rt, pending pending
waiters force the mutex-release to hit the slow path (and therefore
require that the wait-lock be reacquired by the releaser). I am under
the impression (because I havent had a chance to really review the new
patches yet) that this is not necessarily the case here for the mainline
patch, since the owner field is not managed atomically IIUC

Again, not advocating get/put task per se. Just wanted to point out that
I didnt flub this up on the original -rt design ;)

-Greg

Download attachment "signature.asc" of type "application/pgp-signature" (258 bytes)