qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] QEMU segfault: Booting an overlay with backing_file ove


From: Max Reitz
Subject: Re: [Qemu-devel] QEMU segfault: Booting an overlay with backing_file over NBD: nbd.c:nbd_receive_request():L756: read failed
Date: Fri, 30 Jan 2015 14:32:25 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0

On 2015-01-30 at 13:41, Kashyap Chamarthy wrote:
On Fri, Jan 30, 2015 at 06:15:21PM +0100, Kevin Wolf wrote:
Am 29.01.2015 um 17:25 hat Kashyap Chamarthy geschrieben:
   $ qemu-system-x86_64               \
      -nographic                      \
      -nodefconfig                    \
      -nodefaults                     \
      -m 2048                         \
      -device virtio-scsi-pci,id=scsi \
      -device virtio-serial-pci       \
      -serial stdio                   \
      -drive file=./overlay1.qcow2,format=qcow2,if=virtio,cache=writeback
   Segmentation fault (core dumped)


On the shell where `qemu-nbd` is running, I notice this

   nbd.c:nbd_receive_request():L756: read failed


Haven't investigated further with GDB, thought I'd bring it up here
first.


Versions
--------

   $ rpm -q qemu; uname -r
   qemu-2.1.2-7.fc21.x86_64
   3.17.8-300.fc21.x86_64
Copying Stefan because he's the master of AIO contexts and it is
bs->aio_context that becomes NULL. I couldn't see anything obvious.


In the meantime, could you retest on git master?
Just tested from git, and I can still reproduce it.

That's the commit I'm at:

   $ git describe
   v2.2.0-682-g16017c4


Run the NBD server, from git:

   $ /home/kashyapc/build/qemu/qemu-nbd -f qcow2 \
       -p10809 ./f21vm.qcow2 -t


Create the overlay:

   $ /home/kashyapc/build/qemu/qemu-img create \
       -f qcow2 -F nbd -o backing_file=nbd://localhost overlay2-of-f21vm.qcow2
   Segmentation fault (core dumped)

You want to use -F raw. The file format is raw, not nbd (nbd is the protocol over which the data is read, which is in format raw).

Anyway, -F nbd shouldn't result in a segfault. One way to prevent this is to check whether the backing file format specified (or any format given to qemu-img in general) is a real format or the name of a protocol driver and then error out if it's the latter; but that would be more of a hotfix.

Kevin, Stefan: The real problem is that block/nbd.c stores a BDRVNBDState object in bs->opaque and passes &BDRVNBDState.client (an NbdClientSession object) to the block/nbd-client.c functions. Those functions then receive the BDS pointer from client->bs. If an NBD BDS is a root BDS (as in this case), at some point a bdrv_swap() may happen (and it does happen here) which leads to ((BDRVNBDState *)bs->opaque)->client.bs != bs, and that's where the segfault comes from (bdrv_get_aio_context() returns NULL).

One way to fix this real problem is to remove the BDS pointer from the NbdClientSession and to always pass the BDS explicitly to the block/nbd-client.c functions; the other is to always update the BDS pointer in NbdClientSession in block/nbd.c. I'll try the former, and if it doesn't work, will do the latter (if you don't object).

Max

Creating the overlay from the  git-compiled `qemu-img` binary fails.

So, let's create the overlay using the `qemu-img` binary from the system
(RPM version noted above) and boot the overlay from the just compiled
QEMU x86_64 binary from git, still core dumps:

   $ /home/kashyapc/build/qemu/x86_64-softmmu/qemu-system-x86_64 \
       -nographic                      \
       -nodefconfig                    \
       -nodefaults                     \
       -m 2048                         \
       -device virtio-scsi-pci,id=scsi \
       -device virtio-serial-pci       \
       -serial stdio                   \
       -drive file=./overlay2-f21vm.qcow2,format=qcow2,if=virtio,cache=writeback
   Segmentation fault (core dumped)


PS: I'm traveling, so I'll be a little slow to respond here, but can
provide more debugging info from the coredump of `qemu-img` binary as I
have access to a real computer.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]