[RFC] Is wait_event_interruptible_timeout() broken ?

[Laurent Pinchart]

Hello,

While working on a driver for an I2C device I noticed that a call to 
wait_event_interruptible_timeout() would wait much longer than expected 
(2s-10s instead of 200ms). I've started by the obvious and checked the jiffies 
counter, which runs fine at the expected rate.

Further investigation showed that the schedule_timeout() call inside 
wait_event_interruptible_timeout() returns immediately. As the wait condition 
involves I2C access and thus takes significantly more time to run than 
schedule_timeout(), the probability of schedule_timeout() crossing a jiffies 
boundary is relatively small. The function thus returns the timeout value it 
received unchanged, and the jiffies boundary crossed by the condition check 
remains unnoticed. The actual timeout is thus much longer than requested.

I still need to investigate why schedule_timeout() returns immediately (help 
would be appreciated, I'm not familiar with the scheduler), but regardless of 
that I believe that wait_event_interruptible_timeout() should behave properly. 
Shouldn't it store the target jiffies before the loop and compare the current 
jiffies as part of the exit condition instead of relying on schedule_timeout() 
to update the timeout ?

I don't want to break the recent effort to consolidate all wait macros around 
___wait_event, so I'd appreciate both opinions on whether this should be 
considered as a wait_event_interruptible_timeout() bug, and hints regarding 
the preferred way to fix it.

-- 
Regards,

Laurent Pinchart

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