Re: [PATCH] poll: allow f_op->poll to sleep, take#5

From: Tejun Heo
Date: Wed Nov 26 2008 - 01:39:00 EST


Hello,

Davide Libenzi wrote:
> Look, pollwake() does:
>
> w1) WR triggered (1)
> w2) WMB
> w3) WR task->state (RUNNING)
>
> While poll_schedule_timeout() does:
>
> s1) WR task->state (TASK_INTERRUPTIBLE)
> s2) MB
> s3) RD triggered
> s4) IF0 => RD task->state (if !RUNNING -> sleep)
s5) after waking up, WR triggered to zero

> The only risk is that w3 preceed s1, so that we go to sleep even though a
> wakeup has been issued. But if w3 is visible, w1 is visible too, that
> means that 'triggered' is visible in s3 (there's a MB in s2). So we skip
> the schedule_hrtimeout_range(). So IMO you need no barriers on 'triggered'.
> If you feel you need barriers, do you mind explaning a sequence of events
> that makes a barrier-free version break?

s5 from the previous iteration could happen after w1 during the next
iteration and the test in s4 of the next iteration will miss the
event, so the event could get lost on the iterations which is not the
first one, no?

Thanks.

--
tejun
--
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/