All of lore.kernel.org
 help / color / mirror / Atom feed
From: Darren Hart <dvhart@linux.intel.com>
To: zhang.yi20@zte.com.cn
Cc: linux-kernel@vger.kernel.org, Ingo Molnar <mingo@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH] futex: bugfix for robust futex deadlock when waking only one thread in handle_futex_death
Date: Thu, 18 Apr 2013 07:54:30 -0700	[thread overview]
Message-ID: <51700926.8020309@linux.intel.com> (raw)
In-Reply-To: <OF1AAB4598.9A9CCAE8-ON48257B51.000416F3-48257B51.0009DE5A@zte.com.cn>



On 04/17/2013 06:47 PM, zhang.yi20@zte.com.cn wrote:
> 
> 
> Darren Hart <dvhart@linux.intel.com> wrote on 2013/04/18 03:42:07:
> 
>> 
>> 
>> On 04/17/2013 03:40 AM, zhang.yi20@zte.com.cn wrote:
>> > 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.
>> 
>> Indeed they *should*. :-)
>> 
>> > 
>> >> 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.
>> 
>> If I understood the point of your change, it was to ensure all tasks
>> would be woken because tasks that were exiting wouldn't propogate the
>> wake. If there are nothing but exiting tasks available.... does it even
>> matter?
>> 
> 
> I mean that there may be some processes (more than 2) waitting for the
> lock, we can't choose the one which is exiting or it will exit later.
> It's difficult to accomplish this.
> 

"or it will exit later" .... I don't follow you there, it sounds like
you are saying if we try to wake the exiting process, that process will
be delayed and take longer to exit.... I don't think that is what you
meant. Can you elaborate please?

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel

       reply	other threads:[~2013-04-18 14:54 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <OF1AAB4598.9A9CCAE8-ON48257B51.000416F3-48257B51.0009DE5A@zte.com.cn>
2013-04-18 14:54 ` Darren Hart [this message]
2013-04-19  7:03   ` Re: [PATCH] futex: bugfix for robust futex deadlock when waking only one thread in handle_futex_death zhang.yi20
2013-04-17 10:40 zhang.yi20
2013-04-17 19:42 ` Darren Hart
  -- strict thread matches above, loose matches on Subject: below --
2013-04-16  3:02 zhang.yi20
2013-04-16 17:05 ` Darren Hart
2013-04-08  7:57 jiang.biao2

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=51700926.8020309@linux.intel.com \
    --to=dvhart@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=zhang.yi20@zte.com.cn \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.