Messages in this thread | | | From | Arnd Bergmann <> | Date | Wed, 20 Jun 2018 14:00:17 +0200 | Subject | Re: [PATCH] afs: use a consistent interpretation of time values |
| |
On Wed, Jun 20, 2018 at 12:53 PM, David Howells <dhowells@redhat.com> wrote: > Arnd Bergmann <arnd@arndb.de> wrote: > >> which avoids the y2038 overflow > > No it doesn't. The AFS protocol is limited. > >> + time64_t mtime_client; /* last time client changed data */ >> + time64_t mtime_server; /* last time server changed data */ >> ... >> - time_t creation; /* volume creation time */ >> + time64_t creation; /* volume creation time */ > > Unless you can change the AFS protocol, this is a waste of memory. It might > be better to change them to u32 as they are protocol values rather than system > values.
AFS uses 'unsigned' seconds, right? What I was trying to say there is that with the patch, the 32-bit overflow gets moved from 2038 to 2106, so at least the nearer problem is solved.
On 64-bit machines, we already waste a little memory here, the usual tradeoff I took was to use time64_t for all time storage when possible for clarity reasons, but that is easily changed if you prefer.
>> - inode->i_ctime.tv_sec = get_seconds(); >> - inode->i_ctime.tv_nsec = 0; >> - inode->i_atime = inode->i_mtime = inode->i_ctime; >> + inode->i_ctime = inode->i_atime = inode->i_mtime = current_time(inode); > > Surely, the tv_nsec should be zero since anything else cannot be represented > in the AFS protocol.
current_time() truncates the nanoseconds to the granularity of the filesystem. Since AFS doesn't set s_time_gran, it gets the default 1000000000 value leads to tv_nsec being zero. Once Deepa's patch to truncate the tv_sec range lands, it will also ensure that this is within the range (this is less of a problem for setting the current time than it is for utimensat() which can set arbitrary future timestamps of course).
> I will grant, however, I should be consistently using them as unsigned values. > > Note that the answers to the above may change if and when I start supporting > the YFS protocol extensions, but for the AFS protocol, this is simply not > there.
Ok, good to know this exists.
Arnd
| |