[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1014264.1667587643@warthog.procyon.org.uk>
Date: Fri, 04 Nov 2022 18:47:23 +0000
From: David Howells <dhowells@...hat.com>
To: Al Viro <viro@...iv.linux.org.uk>
Cc: dhowells@...hat.com, Christoph Hellwig <hch@...radead.org>,
willy@...radead.org, dchinner@...hat.com,
Steve French <smfrench@...il.com>,
Shyam Prasad N <nspmangalore@...il.com>,
Rohith Surabattula <rohiths.msft@...il.com>,
Jeff Layton <jlayton@...nel.org>,
Ira Weiny <ira.weiny@...el.com>, torvalds@...ux-foundation.org,
linux-cifs@...r.kernel.org, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org, jlayton@...hat.com
Subject: Re: How to convert I/O iterators to iterators, sglists and RDMA lists
David Howells <dhowells@...hat.com> wrote:
> > What protects pages involved in ITER_XARRAY iterator created by
> > afs_read_dir()? Note that we are not guaranteed inode_lock() on
> > the directory in question...
>
> Yeah - that needs fixing. The size of the data can change, but I don't update
> the iterator.
Actually, no. The iterator is the output buffer for afs_fetch_data(). If the
buffer turned out to be too small we drop the validate_lock and go round and
try again.
req->actual_len and req->file_size are updated by afs_fetch_data() from the
RPC reply. req->len tells the RPC delivery code how big the buffer is (which
we don't have to fill if there's less data available than we have buffer
space).
David
Powered by blists - more mailing lists