On Tue, Jan 21, 2020 at 5:10 PM Lucas Stach l.stach@pengutronix.de wrote:
Hi Guido,
On Di, 2020-01-21 at 13:55 +0100, Guido Günther wrote:
Hi, On Tue, Jan 21, 2020 at 12:45:25PM +0100, Arnd Bergmann wrote:
As Guido Günther reported, get_abs_timeout() in the etnaviv user space sometimes passes timeouts with nanosecond values larger than 1000000000, which gets rejected after my first patch.
To avoid breaking this, while also not allowing completely arbitrary values, set the limit to 1999999999 and use set_normalized_timespec64() to get the correct format before comparing it.
I'm seeing values up to 5 seconds so I need
if (args->timeout.tv_nsec > (5 * NSEC_PER_SEC))to unbreak rendering. Which seems to match what mesa's get_abs_timeout() does and how it's invoked.
I have not tested this myself yet, only looked at the code. From the code I quoted earlier, I don't see how we end up with 5 * NSEC_PER_SEC in the tv_nsec member, even if the timeout passed to get_abs_timeout() is 5 seconds.
I can think of two different ways you'd end up with around five seconds here:
a) you have a completely arbitrary 32-bit number through truncation, which is up to 4.2 seconds b) you have the same kind of 32-bit number, but add up to another 999999999 nanoseconds, so you get up to 5.2 seconds in the 64-bit field.
It could of course be something completely different. If this works correctly today, we may need to allow any 64-bit input for the nanoseconds and do an expensive 64-bit div/mod in the kernel for normalization rather than the cheaper set_normalized_timespec64() from my patch.
Arnd