All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Snitzer <snitzer@kernel.org>
To: Trond Myklebust <trondmy@kernel.org>
Cc: linux-nfs@vger.kernel.org
Subject: Re: [PATCH 3/4] NFS/localio: Handle short writes by retrying
Date: Mon, 5 Jan 2026 13:30:43 -0500	[thread overview]
Message-ID: <aVwDU3WuZfzIovt2@kernel.org> (raw)
In-Reply-To: <2a48660a6da0f53e5d36c4c34050c0f920a8b586.camel@kernel.org>

On Mon, Jan 05, 2026 at 01:09:50PM -0500, Trond Myklebust wrote:
> On Mon, 2026-01-05 at 13:04 -0500, Mike Snitzer wrote:
> > On Sat, Jan 03, 2026 at 12:14:59PM -0500, Trond Myklebust wrote:
> > > From: Trond Myklebust <trond.myklebust@hammerspace.com>
> > > 
> > > The current code for handling short writes in localio just
> > > truncates the
> > > I/O and then sets an error. While that is close to how the ordinary
> > > NFS
> > > code behaves, it does mean there is a chance the data that got
> > > written
> > > is lost because it isn't persisted.
> > > To fix this, change localio so that the upper layers can direct the
> > > behaviour to persist any unstable data by rewriting it, and then
> > > continuing writing until an ENOSPC is hit.
> > > 
> > > Fixes: 70ba381e1a43 ("nfs: add LOCALIO support")
> > > Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
> > 
> > This is a pretty subtle fix in that it depends on rpc_call_done
> > conditionally setting task->tk_action -- is it worth adding a
> > relevant
> > code comment in nfs_local_pgio_release()?
> > 
> 
> That's how restarts work in the RPC code: after the rpc_call_done
> callback is done, rpc_exit_task() will check for whether or not the
> task->tk_action got reset, and if so, it will prepare a new RPC call.
> 
> > Additional inline review comment below.
> > 
> > > ---
> > >  fs/nfs/localio.c | 64 +++++++++++++++++++++++++++++++++++---------
> > > ----
> > >  1 file changed, 47 insertions(+), 17 deletions(-)
> > > 
> > > diff --git a/fs/nfs/localio.c b/fs/nfs/localio.c
> > > index c5f975bb5a64..87abebbedbab 100644
> > > --- a/fs/nfs/localio.c
> > > +++ b/fs/nfs/localio.c
> > > @@ -58,6 +58,11 @@ struct nfs_local_fsync_ctx {
> > >  static bool localio_enabled __read_mostly = true;
> > >  module_param(localio_enabled, bool, 0644);
> > >  
> > > +static int nfs_local_do_read(struct nfs_local_kiocb *iocb,
> > > +			     const struct rpc_call_ops *call_ops);
> > > +static int nfs_local_do_write(struct nfs_local_kiocb *iocb,
> > > +			      const struct rpc_call_ops
> > > *call_ops);
> > > +
> > >  static inline bool nfs_client_is_local(const struct nfs_client
> > > *clp)
> > >  {
> > >  	return !!rcu_access_pointer(clp->cl_uuid.net);
> > > @@ -542,13 +547,50 @@ nfs_local_iocb_release(struct nfs_local_kiocb
> > > *iocb)
> > >  	nfs_local_iocb_free(iocb);
> > >  }
> > >  
> > > -static void
> > > -nfs_local_pgio_release(struct nfs_local_kiocb *iocb)
> > > +static void nfs_local_pgio_restart(struct nfs_local_kiocb *iocb,
> > > +				   struct nfs_pgio_header *hdr)
> > > +{
> > > +	int status = 0;
> > > +
> > > +	iocb->kiocb.ki_pos = hdr->args.offset;
> > > +	iocb->kiocb.ki_flags &= ~(IOCB_DSYNC | IOCB_SYNC |
> > > IOCB_DIRECT);
> > > +	iocb->kiocb.ki_complete = NULL;
> > > +	iocb->aio_complete_work = NULL;
> > > +	iocb->end_iter_index = -1;
> > > +
> > > +	switch (hdr->rw_mode) {
> > > +	case FMODE_READ:
> > > +		nfs_local_iters_init(iocb, ITER_DEST);
> > > +		status = nfs_local_do_read(iocb, hdr-
> > > >task.tk_ops);
> > > +		break;
> > > +	case FMODE_WRITE:
> > > +		nfs_local_iters_init(iocb, ITER_SOURCE);
> > > +		status = nfs_local_do_write(iocb, hdr-
> > > >task.tk_ops);
> > > +		break;
> > > +	default:
> > > +		status = -EOPNOTSUPP;
> > > +	}
> > 
> > If this is a restart, then hdr->rw_mode will never not be FMODE_READ
> > or FMODE_WRITE.  As such, hdr->task.tk_ops will have been initialized
> > (as a side-effect of the original nfs_local_do_{read,write}) _and_
> > reinitialized by the above new calls to them.
> > 
> > My point: "default" case shouldn't ever be possible.  So should a
> > comment be added?  Switch to BUG_ON?  Do nothing about it?
> > 
> 
> I considered a BUG_ON(), but it shouldn't really matter. All this does
> now is cancel the restart.

OK, thanks.

Reviewed-by: Mike Snitzer <snitzer@kernel.org>

  reply	other threads:[~2026-01-05 18:30 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-03 17:14 [PATCH 0/4] Fix misc localio issues Trond Myklebust
2026-01-03 17:14 ` [PATCH 1/4] NFS/localio: Stop further I/O upon hitting an error Trond Myklebust
2026-01-05 17:19   ` Mike Snitzer
2026-01-05 17:35     ` Trond Myklebust
2026-01-03 17:14 ` [PATCH 2/4] NFS/localio: Deal with page bases that are > PAGE_SIZE Trond Myklebust
2026-01-05 17:40   ` Mike Snitzer
2026-01-03 17:14 ` [PATCH 3/4] NFS/localio: Handle short writes by retrying Trond Myklebust
2026-01-05 18:04   ` Mike Snitzer
2026-01-05 18:09     ` Trond Myklebust
2026-01-05 18:30       ` Mike Snitzer [this message]
2026-01-03 17:15 ` [PATCH 4/4] NFS/localio: Cleanup the nfs_local_pgio_done() parameters Trond Myklebust
2026-01-05 17:24   ` Mike Snitzer
2026-01-07 16:08 ` [PATCH 0/4] NFS/localio: various improvements Mike Snitzer
2026-01-07 16:08   ` [PATCH 1/4] NFS/localio: prevent direct reclaim recursion into NFS via nfs_writepages Mike Snitzer
2026-01-07 16:08   ` [PATCH 2/4] NFS/localio: use GFP_NOIO and non-memreclaim workqueue in nfs_local_commit Mike Snitzer
2026-01-07 16:08   ` [PATCH 3/4] NFS/localio: remove -EAGAIN handling in nfs_local_doio() Mike Snitzer
2026-01-07 16:08   ` [PATCH 4/4] NFS/localio: switch nfs_local_do_read and nfs_local_do_write to return void Mike Snitzer

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=aVwDU3WuZfzIovt2@kernel.org \
    --to=snitzer@kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=trondmy@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.