qemu-block
[Top][All Lists]
Advanced

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

[Qemu-block] QEMU seg-fault with intermediate image streaming -- bdrv_re


From: Kashyap Chamarthy
Subject: [Qemu-block] QEMU seg-fault with intermediate image streaming -- bdrv_reopen() in stream_start()
Date: Sat, 13 May 2017 00:45:36 +0200
User-agent: Mutt/1.6.0.1 (2016-04-01)

Reproducer
----------

[Disk image chain: disk1.qcow2 <- b.qcow2 <- c.qcow2]

$ qemu-system-x86_64 -display none -nodefconfig -nodefaults \
    -m 512 -device virtio-scsi-pci,id=scsi \
    -device virtio-serial-pci  \
    -drive driver=qcow2,file.driver=file,file.filename=./disk1.qcow2,id=virtio0 
\
    -monitor stdio -qmp unix:./qmp-sock,server,nowait

Create two overlays (I used `qmp-shell`):

    (QEMU) blockdev-snapshot-sync device=virtio0 snapshot-file=b.qcow2
    (QEMU) blockdev-snapshot-sync device=virtio0 snapshot-file=c.qcow2


[Figure out the (format) 'node-name' of 'b.qcow2', from the output of
QMP `query-named-block-nodes` so that it can be supplied to the 'device'
parameter]

Try to perform intermediate streaming (pull clusters from 'disk1.qcow2'
into 'b.qcow2':

    (QEMU) block-stream device=#block832 base=disk1.qcow2


Result
------

QEMU crashes with SIGSEGV:

[...]
Thread 1 "qemu-system-x86" received signal SIGSEGV, Segmentation fault.
0x000055555593d8f7 in stream_start (job_id=0x0, bs=0x555558646e20, 
base=0x5555568548c0, backing_file_str=0x55555863d710 "disk1.qcow2", speed=0, 
on_error=BLOCKDEV_ON_ERROR_REPORT, 
    errp=0x7fffffffbcf8) at /home/kashyapc/tinker-space/qemu/block/stream.c:283
283             bdrv_reopen(bs, s->bs_flags, NULL);
[...]

* * *

NOTE: Of course, streaming to active layer works.


Stack traces
------------

I've attached the stack traces from GDB to this email.


Version
-------

v2.9.0-304-gca7305b


`git blame` seems to point to this commit:
------------------------------------------------------------------------
commit a170a91fd3eab6155da39e740381867e80bcc93e
[...]
    stream: Use real permissions in streaming block job
    
    The correct permissions are relatively obvious here (and explained in
    code comments). For intermediate streaming, we need to reopen the top
    node read-write before creating the job now because the permissions
    system catches attempts to get the BLK_PERM_WRITE_UNCHANGED permission
    on a read-only node.
------------------------------------------------------------------------

-- 
/kashyap

Attachment: gdb-output-of-intermediate-block-stream-crash.txt
Description: Text document


reply via email to

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