linux-kernel - Re: [PATCH v2 18/19] netfs: Keep track of the actual remote file size

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:   Wed, 09 Mar 2022 22:27:51 +0000
From:   David Howells <dhowells@...hat.com>
To:     Jeff Layton <jlayton@...nel.org>
Cc:     dhowells@...hat.com, linux-cachefs@...hat.com,
        Anna Schumaker <anna.schumaker@...app.com>,
        Steve French <sfrench@...ba.org>,
        Dominique Martinet <asmadeus@...ewreck.org>,
        David Wysochanski <dwysocha@...hat.com>,
        Ilya Dryomov <idryomov@...il.com>,
        Jeffle Xu <jefflexu@...ux.alibaba.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        linux-afs@...ts.infradead.org, linux-nfs@...r.kernel.org,
        linux-cifs@...r.kernel.org, ceph-devel@...r.kernel.org,
        v9fs-developer@...ts.sourceforge.net,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 18/19] netfs: Keep track of the actual remote file size

Jeff Layton <jlayton@...nel.org> wrote:

> This seems like something useful, but I wonder if it'll need some sort
> of serialization vs. concurrent updates.

Quite possibly, though that may be something that we have to delegate to the
network filesystem.  kafs, for instance, performs local serialisation of
StoreData RPCs to any given inode because the server will exclusively lock the
remote vnode around the write-to-disk and callback break (ie. change
notification) phases.  This does not preclude, however, another client making
a change whilst the local lock is held.  Of course, in such a case, we're into
conflict resolution and may end up invalidating the local copy.

> Can we assume that netfs itself will never call netfs_resize_file?

Probably.  Depends on how truncation gets handled.

> Ceph already has some pretty complicated size tracking, since it can get
> async notifications of size changes from the MDS. We'll have to consider
> how to integrate this with what it does. Probably this will replace one
> (or more?) of its fields.

ceph's i_reported_size maybe?  cifs has server_eof.

> We may need to offer up some guidance wrt locking.

i_lock may be a good fit.  I wonder if it's worth at some point moving i_lock
to being a seqlock so that various values ordinarily protected by it are
accessible using read_seqbegin().

David