[RESEND] coda: stop using 'struct timespec' in user API
We exchange file timestamps with user space using psdev device
read/write operations with a fixed but architecture specific binary
layout.
On 32-bit systems, this uses a 'timespec' structure that is defined by
the C library to contain two 32-bit values for seconds and nanoseconds.
As we get ready for the year 2038 overflow of the 32-bit signed seconds,
the kernel now uses 64-bit timestamps internally, and user space will
do the same change by changing the 'timespec' definition in the future.
Unfortunately, this breaks the layout of the coda_vattr structure, so
we need to redefine that in terms of something that does not change.
I'm introducing a new 'struct vtimespec' structure here that keeps
the existing layout, and the same change has to be done in the coda
user space copy of linux/coda.h before anyone can use that on a 32-bit
architecture with 64-bit time_t.
An open question is what should happen to actual times past y2038,
as they are now truncated to the last valid date when sent to user
space, and interpreted as pre-1970 times when a timestamp with the
MSB set is read back into the kernel. Alternatively, we could
change the new timespec64_to_coda()/coda_to_timespec64() functions
to use a different interpretation and extend the available range
further to the future by disallowing past timestamps. This would
require more changes in the user space side though.
Acked-by: Jan Harkes <jaharkes@cs.cmu.edu>
Link: https://patchwork.kernel.org/patch/10474735/
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
Originally sent on June 19, which lead to a short discussion
and an Ack, but the patch did not get picked up for 4.19 yet.
I'd still like to get a reply on my last point:
On Tue, Jun 19, 2018 at 9:13 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tue, Jun 19, 2018 at 6:56 PM, Jan Harkes <jaharkes@cs.cmu.edu> wrote:
>> That is definitely quite a hard problem because this propagates all the
>> way back to the Coda file servers and how they store metadata.
>> In fact the existing client-server protocol only uses 32-bit time in
>> seconds, so we already lose the nanosecond resolution and 64-bit systems
>> don't actually benefit from having the extra bits in their struct timespec.
>
> I couldn't find out enough background for this, maybe you can fill it
> in: I see that there is a user space component and a server component,
> but I'm not sure if there is exactly one of each, or if there are multiple
> implementations that are written against the same interface.
>
> If we only have one code base, it should be fairly straightforward to
> make it deal with 'unsigned' timestamps consistently, which would
> let the code work fine until 2106 rather than wrapping around from
> 2038 to 1902.
3 files changed
