[Qemu-devel] Re: Endless loop in qcow2_alloc_cluster_offset

[Marcelo Tosatti]

On Fri, May 07, 2010 at 09:37:22AM +0200, Kevin Wolf wrote:
> Am 07.05.2010 03:19, schrieb Marcelo Tosatti:
> > On Thu, Nov 19, 2009 at 01:19:55PM +0100, Jan Kiszka wrote:
> >> Hi,
> >>
> >> I just managed to push a qemu-kvm process (git rev. b496fe3431) into an
> >> endless loop in qcow2_alloc_cluster_offset, namely over
> >> QLIST_FOREACH(old_alloc, &s->cluster_allocs, next_in_flight):
> >>
> >> (gdb) bt
> >> #0  0x000000000048614b in qcow2_alloc_cluster_offset (bs=0xc4e1d0, 
> >> offset=7417184256, n_start=0, n_end=16, num=0xcb351c, m=0xcb3568) at 
> >> /data/qemu-kvm/block/qcow2-cluster.c:750
> >> #1  0x00000000004828d0 in qcow_aio_write_cb (opaque=0xcb34d0, ret=0) at 
> >> /data/qemu-kvm/block/qcow2.c:587
> >> #2  0x0000000000482a44 in qcow_aio_writev (bs=<value optimized out>, 
> >> sector_num=<value optimized out>, qiov=<value optimized out>, 
> >> nb_sectors=<value optimized out>, cb=<value optimized out>, opaque=<value 
> >> optimized out>) at /data/qemu-kvm/block/qcow2.c:645
> >> #3  0x0000000000470e89 in bdrv_aio_writev (bs=0xc4e1d0, sector_num=2, 
> >> qiov=0x7f48a9010ed0, nb_sectors=16, cb=0x470d20 <bdrv_rw_em_cb>, 
> >> opaque=0x7f48a9010f0c) at /data/qemu-kvm/block.c:1362
> >> #4  0x0000000000472991 in bdrv_write_em (bs=0xc4e1d0, sector_num=14486688, 
> >> buf=0xd67200 "H\a", nb_sectors=16) at /data/qemu-kvm/block.c:1736
> >> #5  0x0000000000435581 in ide_sector_write (s=0xc92650) at 
> >> /data/qemu-kvm/hw/ide/core.c:622
> >> #6  0x0000000000425fc2 in kvm_handle_io (env=<value optimized out>) at 
> >> /data/qemu-kvm/kvm-all.c:553
> >> #7  kvm_run (env=<value optimized out>) at /data/qemu-kvm/qemu-kvm.c:964
> >> #8  0x0000000000426049 in kvm_cpu_exec (env=0x1000) at 
> >> /data/qemu-kvm/qemu-kvm.c:1651
> >> #9  0x000000000042627d in kvm_main_loop_cpu (_env=<value optimized out>) 
> >> at /data/qemu-kvm/qemu-kvm.c:1893
> >> #10 ap_main_loop (_env=<value optimized out>) at 
> >> /data/qemu-kvm/qemu-kvm.c:1943
> >> #11 0x00007f48ae89d070 in start_thread () from /lib64/libpthread.so.0
> >> #12 0x00007f48abf0711d in clone () from /lib64/libc.so.6
> >> #13 0x0000000000000000 in ?? ()
> >> (gdb) print ((BDRVQcowState *)bs->opaque)->cluster_allocs.lh_first 
> >> $5 = (struct QCowL2Meta *) 0xcb3568
> >> (gdb) print *((BDRVQcowState *)bs->opaque)->cluster_allocs.lh_first 
> >> $6 = {offset = 7417176064, n_start = 0, nb_available = 16, nb_clusters = 
> >> 0, depends_on = 0xcb3568, dependent_requests = {lh_first = 0x0}, 
> >> next_in_flight = {le_next = 0xcb3568, le_prev = 0xc4ebd8}}
> >>
> >> So next == first.
> >>
> > 
> > Seen the exact same bug twice in a row while installing FC12 with IDE
> > disk, current qemu-kvm.git. 
> > 
> > qemu-system-x86_64 -drive file=/root/images/fc12-ide.img,cache=writeback \
> > -m 1000  -vnc :1 \
> > -net nic,model=virtio \
> > -net tap,script=/root/ifup.sh -serial stdio \
> > -cdrom /root/iso/linux/Fedora-12-x86_64-DVD.iso -monitor
> > telnet::4445,server,nowait -usbdevice tablet
> > 
> > Can't reproduce though.
> 
> In current git master? That's interesting news. I had kind of expected
> it would be fixed with c644db3d.

Yes, with 31b460256 more precisely. And the symptom was the same as Jan
reported, cluster_allocs.lh_first had le_next pointing to itself.

Perhaps you can add an assert there, so it abort()'s in that case along
with some useful information? I'll try to reproduce.