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]
Message-ID: <2841426.1697473872@warthog.procyon.org.uk>
Date: Mon, 16 Oct 2023 17:31:12 +0100
From: David Howells <dhowells@...hat.com>
To: Jeff Layton <jlayton@...nel.org>
Cc: dhowells@...hat.com, Steve French <smfrench@...il.com>,
    Matthew Wilcox <willy@...radead.org>,
    Marc Dionne <marc.dionne@...istor.com>,
    Paulo Alcantara <pc@...guebit.com>,
    Ronnie Sahlberg <lsahlber@...hat.com>,
    Shyam Prasad N <sprasad@...rosoft.com>, Tom Talpey <tom@...pey.com>,
    Dominique Martinet <asmadeus@...ewreck.org>,
    Ilya Dryomov <idryomov@...il.com>,
    Christian Brauner <christian@...uner.io>,
    linux-afs@...ts.infradead.org, linux-cifs@...r.kernel.org,
    linux-nfs@...r.kernel.org, ceph-devel@...r.kernel.org,
    v9fs@...ts.linux.dev, linux-fsdevel@...r.kernel.org,
    linux-mm@...ck.org, netdev@...r.kernel.org,
    linux-kernel@...r.kernel.org, linux-cachefs@...hat.com
Subject: Re: [RFC PATCH 02/53] netfs: Track the fpos above which the server has no data

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

> >  (7) If stored data is culled from the local cache, we must set zero_point
> >      above that if the data also got written to the server.
> 
> When you say culled here, it sounds like you're just throwing out the
> dirty cache without writing the data back. That shouldn't be allowed
> though, so I must be misunderstanding what you mean here. Can you
> explain?

I meant fscache specifically.  Too many caches - and some of them with the
same names!

> >  (8) If dirty data is written back to the server, but not the local cache,
> >      we must set zero_point above that.
> 
> How do you write back without writing to the local cache? I'm guessing
> this means you're doing a non-buffered write?

I meant fscache.  fscache can decline to honour a request to store data.

> > +		if (size != i_size) {
> > +			truncate_pagecache(&vnode->netfs.inode, size);
> > +			netfs_resize_file(&vnode->netfs, size);
> > +			fscache_resize_cookie(afs_vnode_cache(vnode), size);
> > +		}
> 
> Isn't this an existing bug? AFS is not setting remote_i_size in the
> setattr path currently? I think this probably ought to be done in a
> preliminary AFS patch.

It is being set.  afs_apply_status() sets it.  This is called by
afs_vnode_commit_status() which is called from afs_setattr_success().  The
value isn't updated until we get the return status from the server that
includes the new value.

> > +	loff_t			zero_point;	/* Size after which we assume there's no data
> > +						 * on the server */
> 
> While I understand the concept, I'm not yet sure I understand how this
> new value will be used. It might be better to merge this patch in with
> the patch that adds the first user of this data.

I'll consider it.  At least it might make sense to move them adjacent to each
other in the series.

David


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ