On Mon, Jan 18, 2016 at 2:56 AM, Arnd Bergmann arnd@arndb.de wrote:
On Sunday 17 January 2016 22:09:26 Deepa Dinamani wrote:
Based on the discussion, here is how I propose to proceed:
- Series for timestamp range check and clamping
- Bug fixing patches like change all CURRENT_TIME use cases to
current_fs_time() 3. Patches for vfs to use timespec64 internally (maybe a series, if required) 4. Patches that change all fs that use vfs APIs using timestamp arguments (not a series) 5. Change individual fs to use timespec64 (not a series) 6. Change back whatever time conversion APIs left in vfs or individual fs (maybe a series, if required)
So, I don't see a need for submitting another series as all the changes now are handled on a case by case basis and no longer have a generic theme.
If everyone's in sync then I can proceed with the above plan.
Sounds good to me. Step 3 of course is the hard one, and you may run into further problems with it, as we both have in our previous attempts to crack this nut, but with step 2 before it that may become manageable.
Right, I don't agree with this approach and it will get very ugly. I was just proposing a way to move forward because it looked like we are at a stalemate.
Maybe xfs doesn't have these problems but some of the other fs-es do. And, these will need changing twice: before(to use 64 bit arithmetic like cifs, use current_fs_time() like fat etc) and along with vfs.
It will unnecessarily bloat the vfs switching to timespec64 code. Below are 3 example filesystem changes that illustrates this problem:
Ext4: 1. cr_time 2. Encode and Decode api's
Both these ext4 changes need to made along with vfs change to ext4. Many such fs exists and will make the vfs switch over very ugly.
FAT: 1. fat_time_fat2unix, fat_time_unix2fat
Both the above 2 functions also will have to be modified along with vfs.
CIFS: 1. struct cifs_fscache_inode_auxdata - last_write_time, last_change_time 2. cifs_fattr 3. cifs_NTtimeToUnix, cifs_UnixTimeToNT, cnvrtDosUnixTm
All the above cifs changes also need to be changed in the same patch as vfs switch to timespec64.
I don't think there is any nicer way to do this without having an encapsulation layer like inode_timespec or accessors you mentioned to change the underlying data type in the vfs.
Also, this scheme is so outrageously ugly that you can easily miss some change. There is no way of verifying the approach theoretically. Of course, I will be using kernel tests like in other cases.
-Deepa