On Mon, Nov 11, 2019 at 10:55 AM Lucas Stach l.stach@pengutronix.de wrote:
If that's the case then we should never encounter a genuine 0 timeout and this change would be okay.
That's quite likely, I'd say any program passing {0,0} as a timeout without ETNA_WAIT_NONBLOCK is already broken, but if we leave it like that, it would be best to describe the reasoning in the changelog.
Should I change the changelog, or change the patch to restore the current behavior instead?
I guess I could fold the change below into my patch to make it transparent to the application again.
If we assume 0 to never be a valid timeout, due to monotonic clock starting at 0 and never wrapping then I think we shouldn't introduce any additional code complexity to fix up the return value for this specific case. I'm not aware of any etnaviv userspace being broken in this way to rely on the return value for an invalid timeout input.
Please just amend the commit message to mention the change in behavior and why we think it is safe to do.
Russell had some additional concerns that he raised on IRC, and I did a new simpler implementation of the patch, plus a related bugfix.
Please have a look at those.
Arnd