From: Kevin Wolf <kwolf@redhat.com>
To: Max Reitz <mreitz@redhat.com>
Cc: Kangjie Xi <imxikangjie@gmail.com>,
qemu-devel@nongnu.org, John Snow <jsnow@redhat.com>
Subject: Re: [Qemu-devel] About [PULL 20/25] block: Guard against NULL bs->drv
Date: Fri, 8 Dec 2017 14:51:39 +0100 [thread overview]
Message-ID: <20171208135139.GC4217@localhost.localdomain> (raw)
In-Reply-To: <cd42e58f-4a00-de18-446f-7e2275421992@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2129 bytes --]
Am 08.12.2017 um 14:39 hat Max Reitz geschrieben:
> On 2017-12-06 10:12, Kevin Wolf wrote:
> > Am 06.12.2017 um 08:28 hat Kangjie Xi geschrieben:
> >> Hi,
> >>
> >> I encountered a qemu-nbd segfault, finally I found it was caused by
> >> NULL bs-drv, which is located in block/io.c function bdrv_co_flush
> >> line 2377:
> >>
> >> https://git.qemu.org/?p=qemu.git;a=blob;f=block/io.c;h=4fdf93a0144fa4761a14b8cc6b2a9a6b6e5d5bec;hb=d470ad42acfc73c45d3e8ed5311a491160b4c100#l2377
> >>
> >> It is before the patch at line 2402, so the patch needs to be updated
> >> to fix NULL bs-drv at line 2337.
> >>
> >> https://lists.gnu.org/archive/html/qemu-devel/2017-11/msg03425.html
> >
> > Can you please post a full backtrace? Do you see any error message
> > on stderr before the process crashes?
> >
> > I don't see at the moment how this can happen, except the case that Max
> > mentioned where bs->drv = NULL is set when an image corruption is
> > detected - this involves an error message, though.
> >
> > We check bdrv_is_inserted() as the first thing, which includes a NULL
> > check for bs->drv. So it must have been non-NULL at the start of the
> > function and then become NULL. I suppose this can theoretically happen
> > in qemu_co_queue_wait() if another flush request detects image
> > corruption.
> >
> > Max: I think bs->drv = NULL in the middle of a request was a stupid
> > idea. In fact, it's already a stupid idea to have any BDS with
> > bs->drv = NULL. Maybe it would be better to schedule a BH that replaces
> > the qcow2 node with a dummy node (null-co?) and properly closes the
> > qcow2 one.
>
> Yes, that is an idea John had, too. It sounded good to me (we'd just
> need to add a new flag to null-co so it would respond with -ENOMEDIUM to
> all requests or something)... The only issue I had is how that would
> work together with the GRAPH_MOD op blocker.
In order to answer this question, I'd first have to understand what
GRAPH_MOD is even supposed to mean and which operations it needs to
protect. There aren't currently any users of GRAPH_MOD.
Kevin
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
next prev parent reply other threads:[~2017-12-08 13:51 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-06 7:28 [Qemu-devel] About [PULL 20/25] block: Guard against NULL bs->drv Kangjie Xi
2017-12-06 9:12 ` Kevin Wolf
2017-12-06 10:08 ` Kangjie Xi
2017-12-08 13:39 ` Max Reitz
2017-12-08 13:51 ` Kevin Wolf [this message]
2017-12-08 14:02 ` 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=20171208135139.GC4217@localhost.localdomain \
--to=kwolf@redhat.com \
--cc=imxikangjie@gmail.com \
--cc=jsnow@redhat.com \
--cc=mreitz@redhat.com \
--cc=qemu-devel@nongnu.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.