linux-kernel - [RFC 02/15] vfs: Change all structures to support 64 bit time

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 18 Jan 2016 09:40:12 -0800
From:	Deepa Dinamani <deepa.kernel@...il.com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	Andreas Dilger <adilger@...ger.ca>,
	"y2038@...ts.linaro.org" <y2038@...ts.linaro.org>,
	Dave Chinner <david@...morbit.com>,
	"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: [RFC 02/15] vfs: Change all structures to support 64 bit time

On Mon, Jan 18, 2016 at 2:56 AM, Arnd Bergmann <arnd@...db.de> wrote:
> On Sunday 17 January 2016 22:09:26 Deepa Dinamani wrote:
>> Based on the discussion, here is how I propose to proceed:
>>
>> 1. Series for timestamp range check and clamping
>> 2. 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