Re: AF_PACKET mmap() v4...

[Arnd Bergmann <arnd@arndb.de>]

On Thursday 05 November 2015 00:04:14 David Miller wrote:
> As part of fixing y2038 problems, Arnd is going to have to make a new
> version fo the AF_PACKET mmap() tpacker descriptors in order to extend
> the time values to 64-bit.
> 
> So I want everyone to think about whether there are any other changes
> we might want to make given that we have to make a v4 anyways.
> 
> Particularly, I am rather certain that the buffer management could be
> improved.  Some have complained that v3 is kinda awkward to use and/or
> suboptimal is various ways.

I have taken a closer look at the actual timestamp data now, and noticed
that we use __u32 for both tp_sec and ts_sec in the user visible data.
This means that once we fix the internal implementation to use 64-bit
timestamps, we actually won't overflow until 2106 because the 2038 overflow
is only for signed 32-bit numbers as we have in 'struct timespec'.

So the good news is that we can keep the existing v1 through v3 formats
beyond 2038, but only as long as all user space that cares about the
value also interprets it as unsigned.

If we want to have a v4 format anyway, there are a few consideration
for the format of the timestamps: I generally recommend using __u64
nanoseconds rather than split second/nanosecond, as that simplifies
the code in most cases and makes it more efficient, unless you
actually need the seconds portion on a system that does not have
a 64-bit divide instruction (most 32-bit architectures).

Also, most subsystems are moving to 'monotonic' (counting seconds
from boot, and not impacted by settimeofday(), leap seconds or
ntp jumps) timestamps, but it's not clear if that is the best choice
here, because it won't work for hardware timestamps that actually
use real time. If we do this, we probably also need a field to
store the clockid.

	Arnd