From: Ming Lei <ming.lei@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>, Jens Axboe <axboe@kernel.dk>
Cc: linux-block@vger.kernel.org, josef@toxicpanda.com,
nbd@other.debian.org, eblake@redhat.com, vincent.chen@sifive.com,
Leon Schuermann <leon@is.currently.online>,
Bart Van Assche <bvanassche@acm.org>
Subject: Re: [PATCH V3] nbd: fix partial sending
Date: Mon, 13 Jan 2025 09:14:14 +0800 [thread overview]
Message-ID: <Z4Ro5sggod4WIJN0@fedora> (raw)
In-Reply-To: <ZyolmjfJvYWmhcbS@redhat.com>
On Tue, Nov 05, 2024 at 03:03:06PM +0100, Kevin Wolf wrote:
> Am 29.10.2024 um 02:19 hat Ming Lei geschrieben:
> > nbd driver sends request header and payload with multiple call of
> > sock_sendmsg, and partial sending can't be avoided. However, nbd driver
> > returns BLK_STS_RESOURCE to block core in this situation. This way causes
> > one issue: request->tag may change in the next run of nbd_queue_rq(), but
> > the original old tag has been sent as part of header cookie, this way
> > confuses nbd driver reply handling, since the real request can't be
> > retrieved any more with the obsolete old tag.
> >
> > Fix it by retrying sending directly in per-socket work function,
> > meantime return BLK_STS_OK to block layer core.
> >
> > Cc: vincent.chen@sifive.com
> > Cc: Leon Schuermann <leon@is.currently.online>
> > Cc: Bart Van Assche <bvanassche@acm.org>
> > Reported-by: Kevin Wolf <kwolf@redhat.com>
> > Signed-off-by: Ming Lei <ming.lei@redhat.com>
>
> > @@ -770,6 +798,14 @@ static blk_status_t nbd_send_cmd(struct nbd_device *nbd, struct nbd_cmd *cmd,
> > return BLK_STS_OK;
> >
> > requeue:
> > + /*
> > + * Can't requeue in case we are dealing with partial send
> > + *
> > + * We must run from pending work function.
> > + * */
> > + if (test_bit(NBD_CMD_PARTIAL_SEND, &cmd->flags))
> > + return BLK_STS_OK;
> > +
> > /* retry on a different socket */
> > dev_err_ratelimited(disk_to_dev(nbd->disk),
> > "Request send failed, requeueing\n");
>
> This hunk doesn't feel ideal: The assumption in the normal code path
> here is that the socket is dead, i.e. the error isn't recoverable. With
> this way to handle it, nbd_pending_cmd_work() will keep retrying until
> the request finally times out. We could probably return an error right
> away.
>
> In fact, I think even requeuing (and ideally still completing the
> request successfully in the end) would be fine in this case because
> we'll shut down the socket and never send any additional data on it, so
> the server will never see a complete command. We would just have to make
> sure that nbd_pending_cmd_work() doesn't try to complete sending the
> command any more.
>
> But even though this error path isn't optimal, I feel it might be
> acceptable. Let's see if someone else has an opinion on it.
>
> Tested-by: Kevin Wolf <kwolf@redhat.com>
> Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Hello Jens,
Can you make this fix into v6.14 if you are fine?
Thanks,
Ming
next prev parent reply other threads:[~2025-01-13 1:14 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-29 1:19 [PATCH V3] nbd: fix partial sending Ming Lei
2024-11-05 14:03 ` Kevin Wolf
2025-01-08 18:04 ` Kevin Wolf
2025-01-13 1:14 ` Ming Lei [this message]
2025-01-13 14:46 ` Jens Axboe
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=Z4Ro5sggod4WIJN0@fedora \
--to=ming.lei@redhat.com \
--cc=axboe@kernel.dk \
--cc=bvanassche@acm.org \
--cc=eblake@redhat.com \
--cc=josef@toxicpanda.com \
--cc=kwolf@redhat.com \
--cc=leon@is.currently.online \
--cc=linux-block@vger.kernel.org \
--cc=nbd@other.debian.org \
--cc=vincent.chen@sifive.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 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.