| Message ID | 1465448705-25055-19-git-send-email-deepa.kernel@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 6/9/16, 01:05, "Deepa Dinamani" <deepa.kernel@gmail.com> wrote: >boot_time is represented as a struct timespec. >struct timespec and CURRENT_TIME are not y2038 safe. >Overall, the plan is to use timespec64 for all internal >kernel representation of timestamps. >CURRENT_TIME will also be removed. >Use struct timespec64 to represent boot_time. >And, ktime_get_real_ts64() for the boot_time value. > >boot_time is used to construct the nfs client boot verifier. >This will now wrap in 2106 instead of 2038 on 32-bit systems. >The server only relies on the value being persistent until >reboot so the wrapping should be fine. We really do not give a damn about wraparound here, since the boot time is only ever compared for an exact match, and the odds of two reboots occurring exactly 2^32 * 10^9 nanoseconds apart are cosmically small... If struct timespec is going away, can we just convert this into a ktime_t? Trond
>>boot_time is represented as a struct timespec. >>struct timespec and CURRENT_TIME are not y2038 safe. >>Overall, the plan is to use timespec64 for all internal >>kernel representation of timestamps. >>CURRENT_TIME will also be removed. >>Use struct timespec64 to represent boot_time. >>And, ktime_get_real_ts64() for the boot_time value. >> >>boot_time is used to construct the nfs client boot verifier. >>This will now wrap in 2106 instead of 2038 on 32-bit systems. >>The server only relies on the value being persistent until >>reboot so the wrapping should be fine. > > We really do not give a damn about wraparound here, since the boot time is > only ever compared for an exact match, and the odds of two reboots occurring > exactly 2^32 * 10^9 nanoseconds apart are cosmically small... > If struct timespec is going away, can we just convert this into a ktime_t? timespec64 is the same as timespec already on 64 bit machines. But, yes, we can use ktime_t here. Did you mean the internal storage value or the wire boo_time used for verifier? In case you don't want to change the wire value, then we will have a division operation, every time the verifier needs to be sent. -Deepa -Deepa -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 06/09/2016 05:10 PM, Deepa Dinamani wrote: >>> boot_time is represented as a struct timespec. >>> struct timespec and CURRENT_TIME are not y2038 safe. >>> Overall, the plan is to use timespec64 for all internal >>> kernel representation of timestamps. >>> CURRENT_TIME will also be removed. >>> Use struct timespec64 to represent boot_time. >>> And, ktime_get_real_ts64() for the boot_time value. >>> >>> boot_time is used to construct the nfs client boot verifier. >>> This will now wrap in 2106 instead of 2038 on 32-bit systems. >>> The server only relies on the value being persistent until >>> reboot so the wrapping should be fine. >> >> We really do not give a damn about wraparound here, since the boot time is >> only ever compared for an exact match, and the odds of two reboots occurring >> exactly 2^32 * 10^9 nanoseconds apart are cosmically small... >> If struct timespec is going away, can we just convert this into a ktime_t? > > timespec64 is the same as timespec already on 64 bit machines. > But, yes, we can use ktime_t here. > > Did you mean the internal storage value or the wire boo_time used for verifier? > In case you don't want to change the wire value, then we will have a division > operation, every time the verifier needs to be sent. The verifier is mostly used during mounting, so we don't send too many of them. I don't think we need to worry about adding an extra division operation here, they're pretty cheap compared to making RPC calls! :) Anna > > -Deepa > > -Deepa > -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
DQoNCk9uIDYvMTAvMTYsIDA5OjEyLCAiQW5uYSBTY2h1bWFrZXIiIDxBbm5hLlNjaHVtYWtlckBu ZXRhcHAuY29tPiB3cm90ZToNCg0KPk9uIDA2LzA5LzIwMTYgMDU6MTAgUE0sIERlZXBhIERpbmFt YW5pIHdyb3RlOg0KPj4+PiBib290X3RpbWUgaXMgcmVwcmVzZW50ZWQgYXMgYSBzdHJ1Y3QgdGlt ZXNwZWMuDQo+Pj4+IHN0cnVjdCB0aW1lc3BlYyBhbmQgQ1VSUkVOVF9USU1FIGFyZSBub3QgeTIw Mzggc2FmZS4NCj4+Pj4gT3ZlcmFsbCwgdGhlIHBsYW4gaXMgdG8gdXNlIHRpbWVzcGVjNjQgZm9y IGFsbCBpbnRlcm5hbA0KPj4+PiBrZXJuZWwgcmVwcmVzZW50YXRpb24gb2YgdGltZXN0YW1wcy4N Cj4+Pj4gQ1VSUkVOVF9USU1FIHdpbGwgYWxzbyBiZSByZW1vdmVkLg0KPj4+PiBVc2Ugc3RydWN0 IHRpbWVzcGVjNjQgdG8gcmVwcmVzZW50IGJvb3RfdGltZS4NCj4+Pj4gQW5kLCBrdGltZV9nZXRf cmVhbF90czY0KCkgZm9yIHRoZSBib290X3RpbWUgdmFsdWUuDQo+Pj4+DQo+Pj4+IGJvb3RfdGlt ZSBpcyB1c2VkIHRvIGNvbnN0cnVjdCB0aGUgbmZzIGNsaWVudCBib290IHZlcmlmaWVyLg0KPj4+ PiBUaGlzIHdpbGwgbm93IHdyYXAgaW4gMjEwNiBpbnN0ZWFkIG9mIDIwMzggb24gMzItYml0IHN5 c3RlbXMuDQo+Pj4+IFRoZSBzZXJ2ZXIgb25seSByZWxpZXMgb24gdGhlIHZhbHVlIGJlaW5nIHBl cnNpc3RlbnQgdW50aWwNCj4+Pj4gcmVib290IHNvIHRoZSB3cmFwcGluZyBzaG91bGQgYmUgZmlu ZS4NCj4+Pg0KPj4+IFdlIHJlYWxseSBkbyBub3QgZ2l2ZSBhIGRhbW4gYWJvdXQgd3JhcGFyb3Vu ZCBoZXJlLCBzaW5jZSB0aGUgYm9vdCB0aW1lIGlzDQo+Pj4gb25seSBldmVyIGNvbXBhcmVkIGZv ciBhbiBleGFjdCBtYXRjaCwgYW5kIHRoZSBvZGRzIG9mIHR3byByZWJvb3RzIG9jY3VycmluZw0K Pj4+IGV4YWN0bHkgMl4zMiAqIDEwXjkgbmFub3NlY29uZHMgYXBhcnQgYXJlIGNvc21pY2FsbHkg c21hbGwuLi4NCj4+PiBJZiBzdHJ1Y3QgdGltZXNwZWMgaXMgZ29pbmcgYXdheSwgY2FuIHdlIGp1 c3QgY29udmVydCB0aGlzIGludG8gYSBrdGltZV90Pw0KPj4gDQo+PiB0aW1lc3BlYzY0IGlzIHRo ZSBzYW1lIGFzIHRpbWVzcGVjIGFscmVhZHkgb24gNjQgYml0IG1hY2hpbmVzLg0KPj4gQnV0LCB5 ZXMsIHdlIGNhbiB1c2Uga3RpbWVfdCBoZXJlLg0KPj4gDQo+PiBEaWQgeW91IG1lYW4gdGhlIGlu dGVybmFsIHN0b3JhZ2UgdmFsdWUgb3IgdGhlIHdpcmUgYm9vX3RpbWUgdXNlZCBmb3IgdmVyaWZp ZXI/DQo+PiBJbiBjYXNlIHlvdSBkb24ndCB3YW50IHRvIGNoYW5nZSB0aGUgd2lyZSB2YWx1ZSwg dGhlbiB3ZSB3aWxsIGhhdmUgYSBkaXZpc2lvbg0KPj4gb3BlcmF0aW9uLCBldmVyeSB0aW1lIHRo ZSB2ZXJpZmllciBuZWVkcyB0byBiZSBzZW50Lg0KPg0KPlRoZSB2ZXJpZmllciBpcyBtb3N0bHkg dXNlZCBkdXJpbmcgbW91bnRpbmcsIHNvIHdlIGRvbid0IHNlbmQgdG9vIG1hbnkgb2YgdGhlbS4g IEkgZG9uJ3QgdGhpbmsgd2UgbmVlZCB0byB3b3JyeSBhYm91dCBhZGRpbmcgYW4gZXh0cmEgZGl2 aXNpb24gb3BlcmF0aW9uIGhlcmUsIHRoZXkncmUgcHJldHR5IGNoZWFwIGNvbXBhcmVkIHRvIG1h a2luZyBSUEMgY2FsbHMhIDopDQo+DQoNClRoZSBvbmx5IHJlcXVpcmVtZW50IGZvciB0aGUgdmVy aWZpZXIgaXMgdGhhdCBpdCBiZSB1bmlxdWUsIHNvIGNoYW5naW5nIHRoZSBmb3JtYXQgaXMgbm90 IGEgcHJvYmxlbSBlaXRoZXIuIA0KDQpDaGVlcnMNCiAgVHJvbmQNCg0K -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/fs/nfs/client.c b/fs/nfs/client.c index 0c96528..406972e 100644 --- a/fs/nfs/client.c +++ b/fs/nfs/client.c @@ -1080,7 +1080,7 @@ void nfs_clients_init(struct net *net) idr_init(&nn->cb_ident_idr); #endif spin_lock_init(&nn->nfs_client_lock); - nn->boot_time = CURRENT_TIME; + ktime_get_real_ts64(&nn->boot_time); } #ifdef CONFIG_PROC_FS diff --git a/fs/nfs/netns.h b/fs/nfs/netns.h index f0e06e4..48d6b95 100644 --- a/fs/nfs/netns.h +++ b/fs/nfs/netns.h @@ -29,7 +29,7 @@ struct nfs_net { int cb_users[NFS4_MAX_MINOR_VERSION + 1]; #endif spinlock_t nfs_client_lock; - struct timespec boot_time; + struct timespec64 boot_time; #ifdef CONFIG_PROC_FS struct proc_dir_entry *proc_nfsfs; #endif
boot_time is represented as a struct timespec. struct timespec and CURRENT_TIME are not y2038 safe. Overall, the plan is to use timespec64 for all internal kernel representation of timestamps. CURRENT_TIME will also be removed. Use struct timespec64 to represent boot_time. And, ktime_get_real_ts64() for the boot_time value. boot_time is used to construct the nfs client boot verifier. This will now wrap in 2106 instead of 2038 on 32-bit systems. The server only relies on the value being persistent until reboot so the wrapping should be fine. Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com> Cc: Trond Myklebust <trond.myklebust@primarydata.com> Cc: Anna Schumaker <anna.schumaker@netapp.com> Cc: linux-nfs@vger.kernel.org --- fs/nfs/client.c | 2 +- fs/nfs/netns.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)