linux-kernel - vfs_timespec64 merge into v4.18?

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

Message-ID: <CAK8P3a2M9RBKMXikFW2jZYwQnWXDjOJ6mzD6Jt85SVOnZkbXnQ@mail.gmail.com>
Date:   Tue, 5 Jun 2018 18:04:10 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Stephen Rothwell <sfr@...b.auug.org.au>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Al Viro <viro@...iv.linux.org.uk>,
        Trond Myklebust <trond.myklebust@...marydata.com>,
        Miklos Szeredi <mszeredi@...hat.com>,
        y2038 Mailman List <y2038@...ts.linaro.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux FS-devel Mailing List <linux-fsdevel@...r.kernel.org>,
        Deepa Dinamani <deepa.kernel@...il.com>
Subject: vfs_timespec64 merge into v4.18?

Hi everyone,

As I discussed with Thomas on IRC, I'd still like to try to get Deepa's series
merged to have 64-bit inode timestamps in VFS, as a prerequisite to fixing
the individual file systems for y2038 as the next step.

The orignal tree that I've been testing with is in
https://github.com/deepa-hub/vfs vfs_timespec64 (see description at [1]
Unfortunately this was never in linux-next so far, so it's definitely
against our
normal rules, and if there are any objections (or new issues getting found),
then we should defer it another merge window.

Until very recently, the branch worked fine with both linux-next and 4.17-rc,
but with some last minute changes to the NFS and Overlayfs trees, it
gained some nasty conflicts.

I've merged Trond's NFS branch and Miklos' Overlayfs branches into
it, fixed up those conflicts and now uploaded it to my tree at
git://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git
Obviously this will break if either of them rebases their trees once
more, in which case I assume Stephen will drop my branch from
linux-next.

Once those two are merged into mainline and nothing unexpected
has come up from linux-next testing, we could either send a pull request
to Linus for the merged branch, or regenerate the flag-day patch in it
using coccinelle, which should result in identical contents.

        Arnd

[1] https://lkml.org/lkml/2018/5/25/828