linux-kernel - Re: [RFC PATCH] rtmutex: Do not prio boost when timeout is used

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

Message-ID: <20140427144852.389311e6@gandalf.local.home>
Date:	Sun, 27 Apr 2014 14:48:52 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	linux-rt-users <linux-rt-users@...r.kernel.org>,
	Ingo Molnar <mingo@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>
Subject: Re: [RFC PATCH] rtmutex: Do not prio boost when timeout is used

Glad I put on my shark repellent.

On Sun, 27 Apr 2014 20:20:26 +0200 (CEST)
Thomas Gleixner <tglx@...utronix.de> wrote:
> 
> We really have better things to do, than changing the rules just to
> please some random (probably commercial) application which has been
> programmed along the coding rules from hell.
> 

Peter had already pointed out that the current behavior is actually
specified by the standards. This patch is thus NULL and void. I only
posted this patch because you haven't bitched at me in a while and I
figured I was due.

I just noticed this when we were trying to debug why an application is
reporting EDEADLOCK on a lock. This was a side discussion as there were
no timeout locks in the application.

It looks more like a bug in the glibc implementation, as they have
both RECURSIVE and PRIO_INHERIT set on the mutex, and it seems that it
is deadlocking on a lock it already owns when it tries to retake it.

-- Steve
--
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/