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  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:   Wed, 14 Sep 2022 09:19:22 +1000
From:   "NeilBrown" <>
To:     "J. Bruce Fields" <>
Cc:     "Dave Chinner" <>,
        "Jeff Layton" <>,
        "Theodore Ts'o" <>, "Jan Kara" <>,,,,,,,,,,,,,,,,,,,
Subject: Re: [man-pages RFC PATCH v4] statx, inode: document the new

On Wed, 14 Sep 2022, J. Bruce Fields wrote:
> On Tue, Sep 13, 2022 at 11:49:03AM +1000, NeilBrown wrote:
> > Invalidating the client cache on EVERY unmount/mount could impose
> > unnecessary cost.  Imagine a client that caches a lot of data (several
> > large files) from a server which is expected to fail-over from one
> > cluster node to another from time to time.  Adding extra delays to a
> > fail-over is not likely to be well received.
> > 
> > I don't *know* this cost would be unacceptable, and I *would* like to
> > leave it to the filesystem to decide how to manage its own i_version
> > values.  So maybe XFS can use the LSN for a salt.  If people notice the
> > extra cost, they can complain.
> I'd expect complaints.
> NFS is actually even worse than this: it allows clients to reacquire
> file locks across server restart and unmount/remount, even though
> obviously the kernel will do nothing to prevent someone else from
> locking (or modifying) the file in between.

I don't understand this comment.  You seem to be implying that changing
the i_version during a server restart would stop a client from
reclaiming locks.  Is that correct?
I would have thought that the client would largely ignore i_version
while it has a lock or open or delegation, as these tend to imply some
degree of exclusive access ("open" being least exclusive).


> Administrators are just supposed to know not to allow other applications
> access to the filesystem until nfsd's started.  It's always been this
> way.
> You can imagine all sorts of measures to prevent that, and if anyone
> wants to work on ways to prevent people from shooting themselves in the
> foot here, great.
> Just taking away the ability to cache or lock across reboots wouldn't
> make people happy, though....
> --b.

Powered by blists - more mailing lists