linux-kernel - Re: Re: [PATCH] futex: bugfix for robust futex deadlock when waking only one thread in handle_futex

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: <OFD68395F8.51EA74C8-ON48257B50.00324CEE-48257B50.003AB601@zte.com.cn>
Date:	Wed, 17 Apr 2013 18:40:41 +0800
From:	zhang.yi20@....com.cn
To:	Darren Hart <dvhart@...ux.intel.com>
Cc:	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: Re: [PATCH] futex: bugfix for robust futex deadlock when waking only
 one thread in handle_futex_death

Darren Hart <dvhart@...ux.intel.com> wrote on 2013/04/17 01:05:28:


> 
> Performance isn't an issue here as this is an error path. The question
> is if the
> changed behavior will constitute a problem for existing applications. 
Rather
> than a serialized cascading wake, we have them all wake at once. If an
> application depended on the first waker after owner death to do some 
cleanup
> before the rest came along, I could imagine some potential for failure
> there.
> 

I don't find out there are any APIs can wake all waiters at once, so still 
use futex_wake.
When waiter return form futex_wait syscall, glibc check the futex's value 
and try to modify it by using atomic instructions, and let the waiter 
return only if successed.
The applications which not use the glibc's library should follow this.

> One possible alternative would be to wake waiters for a different
> process group
> when OWNER_DEAD is set, and leave it as a single wake.
> 

To wake one waiter of other process cannot slove this problem , because it 
can be exiting too.
--
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/