[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <563B23C3.5070406@iogearbox.net>
Date: Thu, 05 Nov 2015 10:39:15 +0100
From: Daniel Borkmann <daniel@...earbox.net>
To: Arnd Bergmann <arnd@...db.de>, David Miller <davem@...emloft.net>
CC: netdev@...r.kernel.org
Subject: Re: AF_PACKET mmap() v4...
On 11/05/2015 10:07 AM, Arnd Bergmann wrote:
> 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.
Right, I was just about to ask that. So we could just make a union in
AF_PACKET's UAPI for a single 64-bit variable (as in ktime_t) to fix that.
Best,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists