linux-kernel - Re: [PATCH] fs: ext4: inode->i

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, 07 Jul 2017 12:13:36 -0400
From:   Jeff Layton <jlayton@...hat.com>
To:     Theodore Ts'o <tytso@....edu>
Cc:     "Darrick J. Wong" <darrick.wong@...cle.com>,
        "J. Bruce Fields" <bfields@...ldses.org>,
        William Koh <kkc6196@...com>,
        Andreas Dilger <adilger@...ger.ca>,
        linux-ext4 <linux-ext4@...r.kernel.org>,
        lkml <linux-kernel@...r.kernel.org>,
        Kernel Team <Kernel-team@...com>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        Trond Myklebust <trond.myklebust@...marydata.com>,
        xfs <linux-xfs@...r.kernel.org>
Subject: Re: [PATCH] fs: ext4: inode->i_generation not assigned 0.

On Fri, 2017-07-07 at 11:51 -0400, Theodore Ts'o wrote:
> On Fri, Jul 07, 2017 at 06:51:37AM -0400, Jeff Layton wrote:
> > 
> > Right. That's the case today if we don't remove support for old
> > filehandles. If we were to remove them, the clients would get back
> > -ESTALE there if they tried to use the old 2.2-style fh's that they saw
> > before the upgrade.
> > 
> > The main takeaway here is that NFS filehandle lifetime is really only
> > bounded by the boot time of the oldest clients.
> 
> Well, and how long an NFS server is still up.  So one could construct
> a use case where a (hypothetical) system administrator had a RHEL 7.0
> system with a 2.2.16-22 kernel, and they try to update it to a
> (hypothetical) RHEL 10 kernel in one fell swoop with a 4.13+ kernel
> that no longer supports the 2-2-style fh's.  A client that had the
> server mounted when it was running the 2.2 kernel might only be up for
> a few hours, before the upgrade to RHEL 10 happened, and then the
> client would get ESTALE errors.
> 
> Of course, I've stopped carrying about enterprise kernel support a
> long time ago, so I just think that scenario is funny.  I recognize
> that folks who work at Red Hat have to worry about such things --- and
> I'm sorry.  :-)
> 
> In reality a server installed with RHEL 7.0 has probably died of old
> age by now --- unless someone crazy is running it in a VMware VM
> because they had some enterprise software package or some bar-code
> printing module for which they don't have source code[1], and so they are
> stuck on RHEL 7.0, even in 2017.  Have I mentioned I'm so glad I don't
> have to worry these sorts of things any more?
> 
> 					- Ted
> 
> [1] That wasn't a made up example; I once visited a customer on site,
> back in the day, that had that exact problem, and so they were stuck
> on some antique version of RHEL, and they expected me to help them.

Yep, exactly. An abrupt upgrade like that is always a possibility, but
it's pretty unlikely, and I don't have a ton of sympathy for anyone who
does that.

I guess another thing we could do as an interim step is to add a
scary-looking printk that fires when someone sends us one of these
really old-style filehandles.

That won't help the poor bastard who updates the host directly from
v2.2-era kernel to the version that eventually removes support for the
old filehandles. It might give us an idea of whether there are still
clients in the field that are still using them though.

-- 
Jeff Layton <jlayton@...hat.com>