linux-kernel - Re: [GIT PULL] y2038 changes for vfs

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] [day] [month] [year] [list]

Date:	Thu, 26 May 2016 07:33:24 +1000
From:	Dave Chinner <david@...morbit.com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linux FS Devel <linux-fsdevel@...r.kernel.org>,
	Deepa Dinamani <deepa.kernel@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Al Viro <viro@...iv.linux.org.uk>
Subject: Re: [GIT PULL] y2038 changes for vfs

On Wed, May 25, 2016 at 06:03:19PM +0200, Arnd Bergmann wrote:
> On Tuesday, May 24, 2016 3:23:39 PM CEST Linus Torvalds wrote:
> > On Tue, May 24, 2016 at 1:11 PM, Arnd Bergmann <arnd@...db.de> wrote:
> > > The following changes since commit bf16200689118d19de1b8d2a3c314fc21f5dc7bb:
> > >
> > >   Linux 4.6-rc3 (2016-04-10 17:58:30 -0700)
> > >
> > > are available in the git repository at:
> > >
> > >   git://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git tags/y2038-4.7
> > 
> > The more I look at this, the less I like it.
> > 
> > There doesn't even seem to be any *point* to the preparatory patches.
> > I'm not seeing what any of those patches actually help prepare. The
> > two new superblock fields that it adds, for example, should likely
> > never be touched directly by any code in the first place, so adding
> > them only encourages people to add more "preparatory" patches to
> > filesystems that simply don't seem sensible.
....
> > It's not like it's hard to compile-test the pretty mechanical
> > conversion. There are no architecture-specific users, so I suspect
> > that a trivial "make allmodconfig" build will catch all the cases.
> > 
> > Why drag something like this out, in other words?

Good question, indeed.

> The vfs_time_to_timespec/timespec_to_vfs_time accessors and the
> s_time_min/s_time_max patch are really the ones that make most
> sense doing per file system. These are still all really simple
> patches, but it seemed logical to keep all three together and then
> go through each file system one by one. The hard part here is
> really catching the attention of the file system maintainers,
> not doing the patches.

I was the only filesystem person who attempted to the review your
changes 3 months ago. After the amount of shit you and Deepa dragged
me through as I tried to get you to restructure the patchset
*exactly* like Linus us now suggesting, I walked away and haven't
looked at your patches since.  Is it any wonder that no other
filesystem maintainer has bothered to waste their time on this
since?

Linus - I'd suggest these VFS timestamp patches need to go through
Al's VFS tree. That way we don't get unreviewed VFS infrastructure
changes going into your tree via a door that nobody was paying
attention to...

Cheers,

Dave.
-- 
Dave Chinner
david@...morbit.com