linux-kernel - Re: [ANNOUNCE] 3.2.9-rt17

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]

Date:	Thu, 08 Mar 2012 19:28:07 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	LKML <linux-kernel@...r.kernel.org>,
	linux-rt-users <linux-rt-users@...r.kernel.org>
Subject: Re: [ANNOUNCE] 3.2.9-rt17

On Thu, 2012-03-08 at 13:23 -0500, Steven Rostedt wrote:
> So basically what you tried to do was just set the owner of the lock to
> have the priority of the task that wants the lock, until it releases it?
> But by doing it without having this task sleep? 

No, by having it sleep ;-)

So you do the full PI sleeping lock thing, except you return fail if you
loose the acquisition race on wakeup and you mark this waiter as
'special'.

Then on every rt_mutex block you have to do a deadlock analysis on the
PI blocking chain (preferably shared with PI boost traversal of said
chain), during that scan you collect all special tagged waiters.

If you find a deadlock, wake all these special waiters and have them
return -EDEADLK.

I guess you could also do the full spin_deadlock() and do away with the
try part and purely rely on the deadlock detection.
--
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/