Project

General

Profile

Actions

Bug #7123

open

timestamp encoding required in rfs4_op_readdir()

Added by Jan Schlien over 7 years ago. Updated over 7 years ago.

Status:
In Progress
Priority:
Normal
Assignee:
Category:
nfs - NFS server and client
Start date:
2016-06-21
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage
Gerrit CR:
External Bug:

Description

Timestamps returned from rfs4_op_readdir() should be encoded like timestamps returned by rfs4_op_getattr(). The former sends out timestamps directly from vattr_t, which gives incorrect values for negative timestamps.

The attached reproducer sets mtime to -604800.001000. Output:

stat-0 mtime: -604799.-999999000
stat-1 mtime: 8208203.867263749
stat-2 mtime: -604799.-999999000
stat-3 mtime: -604799.-999999000

The representation is a bit strange, but I am not familiar with representation of negative timestamps in vattr_t and will just assume this is correct for now. What I'm worried about is the wrong result for stat-1. In a getattr request as for stat-0, this timestamp will be converted on the server by nfs4_time_vton() which produces -604800.001000:

NFS:  Op = 9 (GETATTR)
NFS:  Status = 0 (NFS4_OK)
NFS:    0x1a   SIZE CHANGE TYPE
NFS:    0x01   FSID
NFS:    0x10   FILEID
NFS:    0x00  
NFS:    0x3a   OWNER_GROUP OWNER NUMLINKS MODE
NFS:    0xa2   TIME_ACCESS SPACE_USED RAWDEV
NFS:    0xb0   MOUNTED_ON_FILEID TIME_MODIFY TIME_METADATA
NFS:    0x00  
NFS:  Type = REG
NFS:  Change ID = 0x57692eed0510a592
NFS:  Size = 0
NFS:  FS ID: Major = 546bdc0842154d96, Minor = 0
NFS:  File ID = 11
NFS:  Mode = 0644
NFS:  Number of Links = 1
NFS:  Owner = root@iata
NFS:  Group = root@iata
NFS:  Raw Device ID = 4294967295, 4294967295
NFS:  Space Used (this object) = 512
NFS:  Last Access Time = 0.000000
NFS:  Last Metadata Change Time = 21-Jun-16 12:11:25.084977042 GMT
NFS:  Last Modification Time = -604800.001000
NFS:  Mounted On File ID = 11

rfs4_op_readdir(), however, never calls nfs4_time_vton() to convert negative time stamps to nfs format and thus this timestamp is sent as-is, violating the rules stated in RFC3530 about struct nfstime4.

NFS:  Cookie = 309428268
NFS:  Name = f_neg
NFS:    0x1a   SIZE CHANGE TYPE
NFS:    0x09   RDATTR_ERROR FSID
NFS:    0x18   FILEID FILEHANDLE
NFS:    0x00  
NFS:    0x3a   OWNER_GROUP OWNER NUMLINKS MODE
NFS:    0xa2   TIME_ACCESS SPACE_USED RAWDEV
NFS:    0xb0   MOUNTED_ON_FILEID TIME_MODIFY TIME_METADATA
NFS:    0x00  
NFS:  Type = REG
NFS:  Change ID = 0x57692eed0510a592
NFS:  Size = 0
NFS:  FS ID: Major = 546bdc0842154d96, Minor = 0
NFS:  Rdattr Error = 0 (NFS4_OK)
NFS:  File handle = [805F]
NFS:  (36) 964d154208dc6b540a000b0000000000563bf3000a000300000000006520f200
NFS:  00000000
NFS:  File ID = 11
NFS:  Mode = 0644
NFS:  Number of Links = 1
NFS:  Owner = root@iata
NFS:  Group = root@iata
NFS:  Raw Device ID = 4294967295, 4294967295
NFS:  Space Used (this object) = 512
NFS:  Last Access Time = 0.000000
NFS:  Last Metadata Change Time = 21-Jun-16 12:11:25.084977042 GMT
NFS:  Last Modification Time = -604799.-999999000
NFS:  Mounted On File ID = 11
NFS:  EOF = TRUE
NFS:  Verifer = 0000000000000000

This is sent through the conversion function nfs4_time_ntov(), which sees unsigned ntime->nseconds > 1000000000 and returns EOVERFLOW. The caller xdr_ga_fattr_res_inline continues and finally returns uninitialized data to user mode.

I am going to submit a patch for the server to call nfs4_time_vton() from rfs4_op_readdir().


Files

bug-readdir.c (2.1 KB) bug-readdir.c Jan Schlien, 2016-06-21 12:28 PM
Actions #1

Updated by Jan Schlien over 7 years ago

Actions #2

Updated by Marcel Telka over 7 years ago

  • Category set to nfs - NFS server and client
Actions

Also available in: Atom PDF