From: Kevin Wolf <kwolf@redhat.com>
To: Max Reitz <mreitz@redhat.com>
Cc: vsementsov@virtuozzo.com, qemu-block@nongnu.org,
s.reiter@proxmox.com, qemu-devel@nongnu.org,
t.lamprecht@proxmox.com, stefanha@redhat.com,
dietmar@proxmox.com
Subject: Re: [PATCH for-5.0 2/2] block: Fix blk->in_flight during blk_wait_while_drained()
Date: Fri, 3 Apr 2020 16:50:17 +0200 [thread overview]
Message-ID: <20200403145017.GE5336@linux.fritz.box> (raw)
In-Reply-To: <30e7194e-afbc-2822-f086-9891539c0e3a@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1916 bytes --]
Am 03.04.2020 um 14:42 hat Max Reitz geschrieben:
> On 03.04.20 12:44, Kevin Wolf wrote:
> > Calling blk_wait_while_drained() while blk->in_flight is increased for
> > the current request is wrong because it will cause the drain operation
> > to deadlock.
> >
> > Many callers of blk_wait_while_drained() have already increased
> > blk->in_flight when called in a blk_aio_*() path, but can also be called
> > in synchonous code paths where blk->in_flight isn't increased. This
> > means that these calls of blk_wait_while_drained() are wrong at least in
> > some cases.
> >
> > In order to fix this, increase blk->in_flight even for synchronous
> > operations and temporarily decrease the counter again in
> > blk_wait_while_drained().
> >
> > Fixes: cf3129323f900ef5ddbccbe86e4fa801e88c566e
> > Signed-off-by: Kevin Wolf <kwolf@redhat.com>
> > ---
> > block/block-backend.c | 8 ++++----
> > 1 file changed, 4 insertions(+), 4 deletions(-)
>
> blk_co_pdiscard() and blk_co_flush() are called from outside of
> block-backend.c (namely from mirror.c and nbd/server.c). Is that OK?
Hm... I think you're right that the NBD server has a problem now because
we might now decrease blk->in_flight without having increased it.
(Mirror should be fine anyway because it sets disable_request_queuing.)
At first I was going to suggest that we could do the opposite of this
patch and just move the dec/wait/inc sequence (which this patch removes
for read/write) to all coroutine entry functions, so direct calls
wouldn't incorrectly decrease the counter.
But this is not what we want either, we do want to queue requests for
drained BlockBackends even in the blk_co_*() API.
Do you have another idea or do we have to turn blk_co_*() into wrappers
around the existing functions, which would gain an additional bool
parameter that tells whether we need to dec/inc or not?
Kevin
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
next prev parent reply other threads:[~2020-04-03 14:51 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-03 10:44 [PATCH for-5.0 0/2] block: Fix blk->in_flight during blk_wait_while_drained() Kevin Wolf
2020-04-03 10:44 ` [PATCH for-5.0 1/2] block: Don't blk_wait_while_drained() in blk_co_preadv/pwritev Kevin Wolf
2020-04-03 12:40 ` Max Reitz
2020-04-03 10:44 ` [PATCH for-5.0 2/2] block: Fix blk->in_flight during blk_wait_while_drained() Kevin Wolf
2020-04-03 12:42 ` Max Reitz
2020-04-03 14:50 ` Kevin Wolf [this message]
2020-04-06 9:41 ` Max Reitz
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=20200403145017.GE5336@linux.fritz.box \
--to=kwolf@redhat.com \
--cc=dietmar@proxmox.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=s.reiter@proxmox.com \
--cc=stefanha@redhat.com \
--cc=t.lamprecht@proxmox.com \
--cc=vsementsov@virtuozzo.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;
as well as URLs for NNTP newsgroup(s).