From: Matthew Wilcox <willy@infradead.org>
To: Jeff Layton <jlayton@kernel.org>
Cc: Dave Wysochanski <dwysocha@redhat.com>,
Anna Schumaker <anna.schumaker@netapp.com>,
Trond Myklebust <trond.myklebust@hammerspace.com>,
David Howells <dhowells@redhat.com>,
linux-nfs@vger.kernel.org, linux-cachefs@redhat.com,
Benjamin Maynard <benmaynard@google.com>,
Daire Byrne <daire.byrne@gmail.com>
Subject: Re: [PATCH v3 3/3] NFS: Convert buffered read paths to use netfs when fscache is enabled
Date: Wed, 31 Aug 2022 19:58:20 +0100 [thread overview]
Message-ID: <Yw+vTFdk4gAoNR27@casper.infradead.org> (raw)
In-Reply-To: <2c4f4fae20c702e805162f7fa780fc09f7f05aaa.camel@kernel.org>
On Wed, Aug 31, 2022 at 02:21:23PM -0400, Jeff Layton wrote:
> > +static int nfs_netfs_init_request(struct netfs_io_request *rreq, struct file *file)
> > {
> > - struct netfs_cache_resources cres;
> > - struct fscache_cookie *cookie = netfs_i_cookie(&NFS_I(inode)->netfs);
> > - struct iov_iter iter;
> > - struct bio_vec bvec[1];
> > - int ret;
> > -
> > - memset(&cres, 0, sizeof(cres));
> > - bvec[0].bv_page = page;
> > - bvec[0].bv_offset = 0;
> > - bvec[0].bv_len = PAGE_SIZE;
> > - iov_iter_bvec(&iter, READ, bvec, ARRAY_SIZE(bvec), PAGE_SIZE);
> > -
> > - ret = fscache_begin_read_operation(&cres, cookie);
> > - if (ret < 0)
> > - return ret;
> > -
> > - ret = fscache_read(&cres, page_offset(page), &iter, NETFS_READ_HOLE_FAIL,
> > - NULL, NULL);
> > - fscache_end_operation(&cres);
> > - return ret;
> > + struct nfs_open_context *ctx;
> > +
> > + if (file == NULL) {
> > + ctx = nfs_find_open_context(rreq->inode, NULL, FMODE_READ);
> > + if (!ctx)
> > + return -ENOMEM;
>
> That error return seems like an odd choice. A NULL return here just
> means that we don't have a suitable open file, not that we're out of
> memory.
>
> I think a NULL file pointer from netfs can only happen in readahead, and
> the comments over readahead_control say:
>
> * @file: The file, used primarily by network filesystems for authentication.
> * May be NULL if invoked internally by the filesystem.
>
> AFAICT though, only f2fs and ext4 invoke it internally.
>
> Maybe instead of doing this, it ought to just throw a WARN if we get a
> NULL file pointer and return -EINVAL or something?
>
> Willy, am I correct on when ractl->file can be NULL?
Yes. Just to quickly verify it:
$ git grep -w DEFINE_READAHEAD
fs/ext4/verity.c: DEFINE_READAHEAD(ractl, NULL, NULL, inode->i_mapping, index);
fs/f2fs/file.c: DEFINE_READAHEAD(ractl, NULL, NULL, inode->i_mapping, page_idx);
fs/f2fs/verity.c: DEFINE_READAHEAD(ractl, NULL, NULL, inode->i_mapping, index);
fs/netfs/buffered_read.c: DEFINE_READAHEAD(ractl, file, NULL, mapping, index);
fs/verity/enable.c: DEFINE_READAHEAD(ractl, file, ra, file->f_mapping, index);
include/linux/pagemap.h:#define DEFINE_READAHEAD(ractl, f, r, m, i) \
include/linux/pagemap.h: DEFINE_READAHEAD(ractl, file, ra, mapping, index);
include/linux/pagemap.h: DEFINE_READAHEAD(ractl, file, ra, mapping, index);
mm/filemap.c: DEFINE_READAHEAD(ractl, file, &file->f_ra, mapping, folio->index);
mm/filemap.c: DEFINE_READAHEAD(ractl, file, ra, mapping, vmf->pgoff);
mm/filemap.c: DEFINE_READAHEAD(ractl, file, ra, file->f_mapping, vmf->pgoff);
mm/internal.h: DEFINE_READAHEAD(ractl, file, &file->f_ra, mapping, index);
Those two uses in pagemap.h are wrappers, so we need to check their
callers too:
$ git grep 'page_cache_\(a\)*sync_readahead'
mm/filemap.c: page_cache_sync_readahead(mapping, ra, filp, index,
mm/khugepaged.c: page_cache_sync_readahead(mapping, &file->f_ra,
(ignoring the ones inside filesystems)
So yes, they all pass in a real struct file. I wouldn't even check
whether the file pointer is NULL; just assume that it's not and the
crash will be obvious to debug.
prev parent reply other threads:[~2022-08-31 18:59 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-31 0:50 [PATCH v3 0/3] Convert NFS with fscache to the netfs API Dave Wysochanski
2022-08-31 0:50 ` [PATCH v3 1/3] NFS: Rename readpage_async_filler to nfs_pageio_add_page Dave Wysochanski
2022-08-31 16:31 ` Jeff Layton
2022-08-31 0:50 ` [PATCH v3 2/3] NFS: Configure support for netfs when NFS fscache is configured Dave Wysochanski
2022-08-31 16:43 ` Jeff Layton
2022-08-31 0:50 ` [PATCH v3 3/3] NFS: Convert buffered read paths to use netfs when fscache is enabled Dave Wysochanski
2022-08-31 2:35 ` kernel test robot
2022-08-31 18:21 ` Jeff Layton
2022-08-31 18:58 ` Matthew Wilcox [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Yw+vTFdk4gAoNR27@casper.infradead.org \
--to=willy@infradead.org \
--cc=anna.schumaker@netapp.com \
--cc=benmaynard@google.com \
--cc=daire.byrne@gmail.com \
--cc=dhowells@redhat.com \
--cc=dwysocha@redhat.com \
--cc=jlayton@kernel.org \
--cc=linux-cachefs@redhat.com \
--cc=linux-nfs@vger.kernel.org \
--cc=trond.myklebust@hammerspace.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox