Re: [PATCH 1/2] Futex minor fixes

From: Alex Riesen
Date: Wed Aug 27 2003 - 01:51:39 EST


Rusty Russell, Wed, Aug 27, 2003 04:40:14 +0200:
> In message <20030826092631.GN16080@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/