-
Mr NeilBrown authored
If l_wait_event() is passed an lwi initialised with one of LWI_TIMEOUT_INTR( time, NULL, NULL, NULL) LWI_TIMEOUT_INTR( time, NULL, LWI_ON_SIGNAL_NOOP, NULL) LWI_TIMEOUT( time, NULL, NULL) where time != 0, then it behaves much like wait_event_idle_timeout(). All signals are blocked, and it waits either for the condition to be true, or for the timeout (in jiffies). Note that LWI_ON_SIGNAL_NOOP has no effect here. l_wait_event() returns 0 when the condition is true, or -ETIMEDOUT when the timeout occurs. wait_event_idle_timeout() instead returns a positive number when the condition is true, and 0 when the timeout occurs. So in the cases where return value is used, handling needs to be adjusted accordingly. Note that in some cases where cfs_fail_val gives the time to wait for, the current code re-tests the wait time against zero as cfs_fail_val can change asynchronously. This is because l_wait_event() behaves quite differently if the timeout is zero. The new code doesn't need to do that as wait_event_idle_timeout() treat 0 just as a very short wait, which is exactly the correct behavior here. This patch also removes a comment which is no longer meaningful (CAN_MATCH) and corrects a debug message which reported the wait time as "seconds" rather than the correct "jiffies". This patch doesn't change the timed wait in cl_sync_io_wait(). That is a bit more complicated, so it left to a separate patch. Change-Id: I632afc290935e321926f45b144d5367799a01381 Signed-off-by:
Mr NeilBrown <neilb@suse.com> Reviewed-on: https://review.whamcloud.com/35977 Tested-by:
jenkins <devops@whamcloud.com> Reviewed-by:
Shaun Tancheff <stancheff@cray.com> Reviewed-by:
James Simmons <jsimmons@infradead.org> Tested-by:
Maloo <maloo@whamcloud.com> Reviewed-by:
Petros Koutoupis <pkoutoupis@cray.com> Reviewed-by:
Oleg Drokin <green@whamcloud.com>
a7ff5d05