Re: [PATCH 1/2] CIFS: Fix a bug with re-sending wdata when transport returning -EAGAIN

From: Pavel Shilovsky
Date: Tue Mar 05 2019 - 14:47:49 EST


ÐÑ, 1 ÐÐÑ. 2019 Ð. Ð 19:04, Long Li <longli@xxxxxxxxxxxxxxxxx>:
>
> From: Long Li <longli@xxxxxxxxxxxxx>
>
> When sending a wdata, transport may return -EAGAIN. In this case
> we should re-obtain credits because the session may have been
> reconnected.
>
> Signed-off-by: Long Li <longli@xxxxxxxxxxxxx>
> ---
> fs/cifs/file.c | 61 +++++++++++++++++++++++++-------------------------
> 1 file changed, 31 insertions(+), 30 deletions(-)
>
> diff --git a/fs/cifs/file.c b/fs/cifs/file.c
> index 9b53f33137b3..08e73759d6ec 100644
> --- a/fs/cifs/file.c
> +++ b/fs/cifs/file.c
> @@ -2620,43 +2620,44 @@ cifs_resend_wdata(struct cifs_writedata *wdata, struct list_head *wdata_list,
> struct TCP_Server_Info *server =
> tlink_tcon(wdata->cfile->tlink)->ses->server;
>
> - /*
> - * Wait for credits to resend this wdata.
> - * Note: we are attempting to resend the whole wdata not in segments
> - */
> do {
> - rc = server->ops->wait_mtu_credits(server, wdata->bytes, &wsize,
> - &credits);
> -
> - if (rc)
> - goto out;
> -
> - if (wsize < wdata->bytes) {
> - add_credits_and_wake_if(server, &credits, 0);
> - msleep(1000);
> - }
> - } while (wsize < wdata->bytes);
> + /*
> + * Wait for credits to resend this wdata.
> + * Note: we are attempting to resend the whole wdata not in
> + * segments
> + */
> + do {
> + rc = server->ops->wait_mtu_credits(server, wdata->bytes,
> + &wsize, &credits);

The steps in write/read codepaths have been recently re-ordered: now
we need to first check the open handle, re-open it if needed and then
attempt to get credits. This approach avoid a possibility to be stuck
waiting for credits because generally cifs_reopen_file() may need a
lot of credits to complete (up to 2 SMB2_CREATE commands and arbitrary
number of SMB2_LOCK commands).

Please look at this loop as an example:
https://git.samba.org/?p=sfrench/cifs-2.6.git;a=blob;f=fs/cifs/file.c;h=bf864123093162c7ef5cd49ee08d8b40ad7938c8;hb=778d81b65e4d596251943002522d94a7c6fbcf69#l2690

> + if (rc)
> + goto fail;
> +
> + if (wsize < wdata->bytes) {
> + add_credits_and_wake_if(server, &credits, 0);
> + msleep(1000);
> + }
> + } while (wsize < wdata->bytes);
>
> - wdata->credits = credits;
> - rc = -EAGAIN;
> - while (rc == -EAGAIN) {
> + wdata->credits = credits;

let's call adjust_credits before calling async_writev() as in the example above.

> rc = 0;
> if (wdata->cfile->invalidHandle)
> rc = cifs_reopen_file(wdata->cfile, false);
> if (!rc)
> rc = server->ops->async_writev(wdata,
> - cifs_uncached_writedata_release);
> - }
> + cifs_uncached_writedata_release);
>
> - if (!rc) {
> - list_add_tail(&wdata->list, wdata_list);
> - return 0;
> - }
> + /* If the write was successfully sent, we are done */
> + if (!rc) {
> + list_add_tail(&wdata->list, wdata_list);
> + return 0;
> + }
>
> - add_credits_and_wake_if(server, &wdata->credits, 0);
> -out:
> - kref_put(&wdata->refcount, cifs_uncached_writedata_release);
> + /* Roll back credits and retry if needed */
> + add_credits_and_wake_if(server, &wdata->credits, 0);
> + } while (rc == -EAGAIN);

I don't think there is a need for the nested loop here. How about just do:

do {
if (wdata->cfile->invalidHandle) {
rc = cifs_reopen_file(...);
if (rc) break;
}

// get_credits
// if not enough credits - wait and continue the loop.

rc = adjust_credits(...);
if (!rc) {
if (wdata->cfile->invalidHandle)
// set rc, put credits and continue the loop.
else
// send async write
}
// handle write errors
} while(rc == -EAGAIN);


>
> +fail:
> + kref_put(&wdata->refcount, cifs_uncached_writedata_release);
> return rc;
> }
>
> @@ -2884,12 +2885,12 @@ static void collect_uncached_write_data(struct cifs_aio_ctx *ctx)
> wdata->bytes, &tmp_from,
> ctx->cfile, cifs_sb, &tmp_list,
> ctx);
> +
> + kref_put(&wdata->refcount,
> + cifs_uncached_writedata_release);
> }
>
> list_splice(&tmp_list, &ctx->list);
> -
> - kref_put(&wdata->refcount,
> - cifs_uncached_writedata_release);
> goto restart_loop;
> }
> }
> --
> 2.17.1
>

The similar concepts applies for async reads as well.

--
Best regards,
Pavel Shilovsky