linux-kernel - Re: [PATCH 4/3] rtmutex: Avoid barrier in rt_mutex_handle

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20160314134038.GZ6356@twins.programming.kicks-ass.net>
Date:	Mon, 14 Mar 2016 14:40:38 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	Davidlohr Bueso <dave@...olabs.net>
Cc:	tglx@...utronix.de, mingo@...nel.org, bigeasy@...utronix.de,
	umgwanakikbuti@...il.com, paulmck@...ux.vnet.ibm.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/3] rtmutex: Avoid barrier in rt_mutex_handle_deadlock

On Tue, Mar 08, 2016 at 02:05:39PM -0800, Davidlohr Bueso wrote:
> The very nature of rt_mutex_handle_deadlock() implies that this
> patch is merely a formality, as in practice the saved barrier
> is of little use. That said, we can relax setting the task state
> and be done with it; blocking unconditionally... this is a deadlock!
> 
> Signed-off-by: Davidlohr Bueso <dbueso@...e.de>
> ---
>  kernel/locking/rtmutex.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c
> index 8eb99b7f1ac8..c3d3c8e8ea5c 100644
> --- a/kernel/locking/rtmutex.c
> +++ b/kernel/locking/rtmutex.c
> @@ -1216,7 +1216,7 @@ static void rt_mutex_handle_deadlock(int res, int detect_deadlock,
>  	 */
>  	rt_mutex_print_deadlock(w);
>  	while (1) {
> -		set_current_state(TASK_INTERRUPTIBLE);
> +		__set_current_state(TASK_INTERRUPTIBLE);
>  		schedule();

So you're right that it doesn't matter here, however for that very
reason I would suggest not using __set_current_state() before schedule()
unless there is a _really_ good reason, and then with an extensive
comment to go with.

Otherwise people will manage to pick this as an example to copy and who
all knows what kind of borkage will result from that.