linux-kernel - Re: [Y2038] [PATCH v2 07/24] fs: ubifs: Replace CURRENT_TIME_SEC with current

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:	Fri, 24 Jun 2016 23:14:06 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	y2038@...ts.linaro.org
Cc:	Deepa Dinamani <deepa.kernel@...il.com>,
	Theodore Ts'o <tytso@....edu>,
	Artem Bityutskiy <dedekind1@...il.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Adrian Hunter <adrian.hunter@...el.com>,
	linux-mtd <linux-mtd@...ts.infradead.org>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	Linux FS-devel Mailing List <linux-fsdevel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [Y2038] [PATCH v2 07/24] fs: ubifs: Replace CURRENT_TIME_SEC with current_time

On Friday, June 24, 2016 2:05:11 PM CEST Deepa Dinamani wrote:
> > This part of the patch seems independent of the rest, as you don't actually
> > use current_time() here, or assign the timespec to an inode.
> >
> > I'd suggest either leaving this part out of the patch series for now,
> > or making it a separate patch that uses timespec64 directly.
> 
> This is actually the root inode which is created and written to disk.
> We actually want to use current_time() here, but this is not cached.
> So we don't have a vfs inode.
> 
> struct ubifs_ino_node represents inode format on the disk.
> I thought it would be odd to fill this with timespec64 only here.
> My plan was to switch it over to timespec64 when all of ubifs changes
> to use timespec64.

It is a bit odd, but I can't think of why that would be a problem.
All the other instances have to wait until the inode timestamps
are converted but this one does not.

> This also was helping the current series as it let me delete
> CURRENT_TIME macros.
> I can add a comment to suggest this in code.
> 
> But, what you suggest should also work fine since the on disk
> representation is big enough to use timespec64 already.
> Let me know if you want me to drop this change for now as we delete
> CURRENT_TIME macros after rc1 now.

I'd leave it in.

	Arnd