On Aug 22, 2017, at 9:18 AM, Arnd Bergmann [off-list ref] wrote:

On Fri, Aug 18, 2017 at 6:09 PM, Andreas Dilger [off-list ref] wrote:

quoted

quoted

quoted

quoted

So moving to the case of a 32 bit machine:

get_seconds() can return values until year 2106. And, recentcy at max
can only be 35. Analyzing the current line:

if (dtime && (dtime < now) && (now < dtime + recentcy))

The above equation should work fine at least until 35 seconds before
y2038 deadline.

Since it's all unsigned arithmetic, it should be fine until 2106.
However, we should get rid of get_seconds() long before then
and use ktime_get_real_seconds() instead, as most other users
of get_seconds() are (more) broken.

Dtime on disk representation again breaks this for certain values in
2038 even though everything is unsigned.

I was just saying that whatever we do here depends on how dtime on
disk is interpreted.

Agree that ktime_get_real_seconds() should be used here. But, the way
we handle new values would rely on this new interpretation of dtime.
Also, using time64_t variables on stack only matters after this. Once
the types are corrected, maybe the comparison expression need not
change at all (after new dtime interpretation is in place).

There will not be a new dtime format on disk, but since the calculation
here only depends on relative times (within a few minutes), then it would
be fine to use only 32-bit timestamps, and truncate off the high bits
from get_seconds()/ktime_get_real_seconds().

Agreed.

Are you planning to apply your fix for it then? I think your first
suggestion is all we need, aside from the three  minor comments
I had.

Do you think it is worthwhile to introduce a "time_after32()" helper for this?
I suspect that this will also be useful for other parts of the kernel that
deal with relative 32-bit timestamps.


Cheers, Andreas