On Mon, Nov 11, 2019 at 10:55 AM Lucas Stach <l.st...@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
_______________________________________________
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
