lkml.org 
[lkml]   [2003]   [Aug]   [27]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateWed, 27 Aug 2003 08:50:16 +0200
FromAlex Riesen <>
SubjectRe: [PATCH 1/2] Futex minor fixes
Rusty Russell, Wed, Aug 27, 2003 04:40:14 +0200:
> In message <20030826092631.GN16080@Synopsys.COM> you write:
> > Rusty Russell, Tue, Aug 26, 2003 05:05:56 +0200:
> > > Hi Andrew, Ingo,
> > > 
> > > 	This was posted before, but dropped.
> > > 
> > > Name: Minor futex comment tweaks and cleanups
> > > Author: Rusty Russell
> > > Status: Tested on 2.6.0-test4-bk2
> > > 
> > > D: Changes:
> > > D: 
> > > D: (1) don't return 0 from futex_wait if we are somehow
> > > D: spuriously woken up, return -EINTR on any such case,
> > 
> > Here. EINTR is often (if not always) assumed to be caused by a signal.
> > And someone may rightfully depend on it being that way.
> 
> Yes.  Changed code to loop in this case.  I don't know of anyone who
> actually randomly wakes processes, but just in case.  Returning "0"
> always means as "you were woken up by someone using FUTEX_WAKE", and
> some callers *need to know*.
> 
> How's this?

Now it's consistent with what EINTR conventionally mean :)

> Rusty.
> --
...
> +
> +	/* Were we woken up (and removed from queue)?  Always return
> +	 * success when this happens. */
>  	if (!unqueue_me(&q))
>  		ret = 0;
> -	put_page(q.page);
> +	else if (time == 0)
> +		ret = -ETIMEDOUT;
> +	else if (signal_pending(current))
> +		ret = -EINTR;
> +	else
> +		/* Spurious wakeup somehow.  Loop. */
> +		goto again;
> 
>  	return ret;

Btw, what could that spurious wakeups be?
It set to loop unconditionally, so if the source of wakeup insists on
wakeing up the code could result in endless loop, right?

-alex

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:48    [from the cache]
©2003-2008