Hey, Op 14-01-15 om 03:16 schreef Zhou, Jammy: >>> I think it would be best to leave timeout=0 returning 0. Not handling it >>> differently gives the same semantics as used by fence_wait_time and >>> wait_event_timeout. >>> Are there really many cases in which you don't know if timeout = 0 before >>> or not? >> Yeah I think with this it's more important to be consistent with all the >> other wait_something primitives the kernel exposes. > Okay. I think we can live with that from driver perspective by handling > timeout==0 and timeout>0 differently. > But it should still be worth adding some notes for > reservation_object_wait_timeout_rcu that the return value cannot be used to > judge if the fences are signaled or not when timeout==0. > Oops it looks like I was wrong here..
Looking more closely at wait_event_timeout, ___wait_cond_timeout modifies __ret which makes it explicitly handle timeout = 0 by testing. If you resend your patch I will ack it, but can you send a patch for fixing fence_wait_timeout too to clear any possible confusion? ~Maarten
