From: zhang.yi20@zte.com.cn
To: Darren Hart <dvhart@linux.intel.com>
Cc: linux-kernel@vger.kernel.org, Ingo Molnar <mingo@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: Re: [PATCH] futex: bugfix for robust futex deadlock when waking only one thread in handle_futex_death
Date: Wed, 17 Apr 2013 18:40:41 +0800 [thread overview]
Message-ID: <OFD68395F8.51EA74C8-ON48257B50.00324CEE-48257B50.003AB601@zte.com.cn> (raw)
In-Reply-To: <516D84D8.6090407@linux.intel.com>
Darren Hart <dvhart@linux.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.
next prev parent reply other threads:[~2013-04-17 10:41 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-16 3:02 [PATCH] futex: bugfix for robust futex deadlock when waking only one thread in handle_futex_death zhang.yi20
2013-04-16 17:05 ` Darren Hart
2013-04-17 10:40 ` zhang.yi20 [this message]
2013-04-17 19:42 ` Darren Hart
[not found] <OF1AAB4598.9A9CCAE8-ON48257B51.000416F3-48257B51.0009DE5A@zte.com.cn>
2013-04-18 14:54 ` Darren Hart
2013-04-19 7:03 ` zhang.yi20
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=OFD68395F8.51EA74C8-ON48257B50.00324CEE-48257B50.003AB601@zte.com.cn \
--to=zhang.yi20@zte.com.cn \
--cc=dvhart@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).