The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Nick Piggin <npiggin@suse.de>
To: Ingo Molnar <mingo@elte.hu>
Cc: Roland McGrath <roland@redhat.com>,
	akpm@linux-foundation.org, mm-commits@vger.kernel.org,
	drepper@redhat.com, oleg@tv-sign.ru, sebastien.dugue@bull.net,
	linux-kernel@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [patch] change futex_wait() to hrtimers
Date: Mon, 12 Mar 2007 12:29:55 +0100	[thread overview]
Message-ID: <20070312112955.GH28546@wotan.suse.de> (raw)
In-Reply-To: <20070312111958.GA14573@elte.hu>

On Mon, Mar 12, 2007 at 12:19:58PM +0100, Ingo Molnar wrote:
> 
> * Nick Piggin <npiggin@suse.de> wrote:
> 
> > > even if this means more work for you (i'm sorry about that!) i'm 
> > > quite sure we should take Sebastien's hrtimers based implementation 
> > > of futex_wait(), and use the nanosleep method to restart it. There's 
> > > no point in further tweaking the imprecise approach: whenever some 
> > > timeout needs to be restarted, it's a candidate for hrtimers.
> > 
> > Absolute timeout is needed, sure. But once that is done, hrtimers does 
> > not fix a bug, does it?
> 
> the issue is this: your fix reduces the effects of the bug but it is 
> still fundamentally incomplete because of the use of timer_list. So 

But using schedule_timeout is not a bug. Userspace timeouts are always
defined to be "at least".

> instead of trying to fix the bug the wrong way, please try to fix it the 
> right way, ontop of an already existing and tested patch, ok? That also 
> enables the other neat stuff Thomas talked about.

Well that's nice, but I have a bugfix here which probably needs to
get backported to stable kernels and distro kernels.

It should be just as easy to rebase the hrtimer patch on top of my
fix. Considering that you've had it for a year, I don't think it 
needs to be added right before my fix.

> > > until then, glibc already handles timeouts and restarts it manually.
> > 
> > It isn't timeout handling that is buggy, but EINTR behaviour. And 
> > glibc does not handle that here.
> 
> hm. I'm wondering how this wasnt noticed sooner - this futex_wait 
> behavior has been there for like forever.

People ignore LTP test failures, and programs probably try to avoid
exercising the nuances of the unix signal API, I guess.

  reply	other threads:[~2007-03-12 11:29 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200703110814.l2B8EaI1007615@shell0.pdx.osdl.net>
     [not found] ` <20070312011259.3834A1801C4@magilla.sf.frob.com>
2007-03-12  9:10   ` [patch] change futex_wait() to hrtimers Ingo Molnar
2007-03-12  9:16     ` Nick Piggin
2007-03-12 11:02       ` Ingo Molnar
2007-03-12 11:13         ` Nick Piggin
2007-03-12 11:19           ` Ingo Molnar
2007-03-12 11:29             ` Nick Piggin [this message]
2007-03-12 11:38               ` Ingo Molnar
2007-03-12 11:52                 ` Nick Piggin
2007-03-12 12:21                   ` Ingo Molnar
2007-03-12 12:36                     ` Nick Piggin
2007-03-12 11:19         ` Thomas Gleixner
2007-03-12 11:27     ` Andi Kleen
2007-03-12 11:00       ` Thomas Gleixner
2007-03-12 10:58         ` Andi Kleen
2007-03-12 11:04           ` Ingo Molnar
2007-03-12 11:20             ` Andi Kleen
2007-03-12 11:28               ` Ingo Molnar
2007-03-12 14:12           ` Theodore Tso
2007-03-12 14:22             ` Andi Kleen
2007-03-12 14:31             ` Ingo Molnar
2007-03-12 14:32             ` Nick Piggin
2007-03-15  0:03 linux

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=20070312112955.GH28546@wotan.suse.de \
    --to=npiggin@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=drepper@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=mm-commits@vger.kernel.org \
    --cc=oleg@tv-sign.ru \
    --cc=roland@redhat.com \
    --cc=sebastien.dugue@bull.net \
    --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