All of lore.kernel.org
 help / color / mirror / Atom feed
From: Trond Myklebust <trondmy@hammerspace.com>
To: "dwysocha@redhat.com" <dwysocha@redhat.com>
Cc: "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
	"anna.schumaker@netapp.com" <anna.schumaker@netapp.com>
Subject: Re: [PATCH 2/4] NFS: Ensure nfs_readpage returns promptly when internal error occurs
Date: Mon, 28 Jun 2021 22:00:17 +0000	[thread overview]
Message-ID: <c4ca239850c7b265ae857ea34cf167e13874adbc.camel@hammerspace.com> (raw)
In-Reply-To: <CALF+zOn7jTduKYRX_fpNjV+qRat+4qqocVLa=dMfQeUU+RmVaw@mail.gmail.com>

On Mon, 2021-06-28 at 16:00 -0400, David Wysochanski wrote:
> On Mon, Jun 28, 2021 at 3:17 PM Trond Myklebust
> <trondmy@hammerspace.com> wrote:
> > 
> > On Mon, 2021-06-28 at 13:39 -0400, Dave Wysochanski wrote:
> > > A previous refactoring of nfs_readpage() might end up calling
> > > wait_on_page_locked_killable() even if readpage_async_filler()
> > > failed
> > > with an internal error and pg_error was non-zero (for example, if
> > > nfs_create_request() failed).  In the case of an internal error,
> > > skip over wait_on_page_locked_killable() as this is only needed
> > > when the read is sent and an error occurs during completion
> > > handling.
> > > 
> > > Signed-off-by: Dave Wysochanski <dwysocha@redhat.com>
> > > ---
> > >  fs/nfs/read.c | 21 ++++++++++++---------
> > >  1 file changed, 12 insertions(+), 9 deletions(-)
> > > 
> > > diff --git a/fs/nfs/read.c b/fs/nfs/read.c
> > > index 684a730f6670..b0680351df23 100644
> > > --- a/fs/nfs/read.c
> > > +++ b/fs/nfs/read.c
> > > @@ -74,7 +74,7 @@ void nfs_pageio_init_read(struct
> > > nfs_pageio_descriptor *pgio,
> > >  }
> > >  EXPORT_SYMBOL_GPL(nfs_pageio_init_read);
> > > 
> > > -static void nfs_pageio_complete_read(struct
> > > nfs_pageio_descriptor
> > > *pgio)
> > > +static int nfs_pageio_complete_read(struct nfs_pageio_descriptor
> > > *pgio)
> > >  {
> > >         struct nfs_pgio_mirror *pgm;
> > >         unsigned long npages;
> > > @@ -88,6 +88,8 @@ static void nfs_pageio_complete_read(struct
> > > nfs_pageio_descriptor *pgio)
> > >         NFS_I(pgio->pg_inode)->read_io += pgm->pg_bytes_written;
> > >         npages = (pgm->pg_bytes_written + PAGE_SIZE - 1) >>
> > > PAGE_SHIFT;
> > >         nfs_add_stats(pgio->pg_inode, NFSIOS_READPAGES, npages);
> > > +
> > > +       return pgio->pg_error < 0 ? pgio->pg_error : 0;
> > >  }
> > > 
> > > 
> > > @@ -373,16 +375,17 @@ int nfs_readpage(struct file *file, struct
> > > page
> > > *page)
> > >                              &nfs_async_read_completion_ops);
> > > 
> > >         ret = readpage_async_filler(&desc, page);
> > > +       if (ret)
> > > +               goto out;
> > > 
> > > -       if (!ret)
> > 
> > Can't this patch basically be reduced to the above 2 changes? The
> > rest
> > appears just to be shifting code around. I'm seeing nothing in the
> > remaining patches that actually depends on
> > nfs_pageio_complete_read()
> > returning a value.
> > 
> 
> Originally I was thinking there was a benefit to having
> nfs_pageio_complete_read return a success/failure
> similar to readpage_async_filler() which is why I moved
> it.
> 
> You mean just this right?  If so, yes I agree this would be a minimal
> patch.
> Want this as a v2?
> 
> diff --git a/fs/nfs/read.c b/fs/nfs/read.c
> index 684a730f6670..eb390eb618b3 100644
> --- a/fs/nfs/read.c
> +++ b/fs/nfs/read.c
> @@ -373,10 +373,10 @@ int nfs_readpage(struct file *file, struct page
> *page)
>                              &nfs_async_read_completion_ops);
> 
>         ret = readpage_async_filler(&desc, page);
> +       if (ret)
> +               goto out;
> 
> -       if (!ret)
> -               nfs_pageio_complete_read(&desc.pgio);
> -
> +       nfs_pageio_complete_read(&desc.pgio);
>         ret = desc.pgio.pg_error < 0 ? desc.pgio.pg_error : 0;
>         if (!ret) {
>                 ret = wait_on_page_locked_killable(page);
> 

Yep. This what what I had in mind. Thanks!

-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com



  reply	other threads:[~2021-06-28 22:00 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-28 17:38 [PATCH 0/4] Fix a few error paths in nfs_readpage and fscache Dave Wysochanski
2021-06-28 17:39 ` [PATCH 1/4] NFS: Remove unnecessary inode parameter from nfs_pageio_complete_read() Dave Wysochanski
2021-06-28 17:39 ` [PATCH 2/4] NFS: Ensure nfs_readpage returns promptly when internal error occurs Dave Wysochanski
2021-06-28 19:17   ` Trond Myklebust
2021-06-28 20:00     ` David Wysochanski
2021-06-28 22:00       ` Trond Myklebust [this message]
2021-06-28 17:39 ` [PATCH 3/4] NFS: Allow internal use of read structs and functions Dave Wysochanski
2021-06-28 17:39 ` [PATCH 4/4] NFS: Fix fscache read from NFS after cache error Dave Wysochanski
2021-06-28 19:09   ` Trond Myklebust
2021-06-28 20:15     ` David Wysochanski
2021-06-28 21:12     ` David Wysochanski
2021-06-28 21:59       ` Trond Myklebust
2021-06-28 23:46         ` David Wysochanski
2021-06-29  0:39           ` Trond Myklebust
2021-06-29  9:17             ` David Wysochanski
2021-06-29 12:45               ` Trond Myklebust
2021-06-29 13:20                 ` David Wysochanski
2021-06-29 14:54                   ` Trond Myklebust
2021-06-29 15:29                     ` David Wysochanski
2021-06-29 15:50                       ` Trond Myklebust
2021-06-29 15:54                         ` Trond Myklebust

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=c4ca239850c7b265ae857ea34cf167e13874adbc.camel@hammerspace.com \
    --to=trondmy@hammerspace.com \
    --cc=anna.schumaker@netapp.com \
    --cc=dwysocha@redhat.com \
    --cc=linux-nfs@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.