Hi Peter, On Tuesday, July 5, 2016, Peter Maydell <peter.mayd...@linaro.org> wrote:
> On 2 July 2016 at 19:23, Peter Maydell <peter.mayd...@linaro.org > <javascript:;>> wrote: > > On 2 July 2016 at 17:25, Chanho Park <parkc...@gmail.com <javascript:;>> > wrote: > >> I've got a kpartx crash frin qemu-aarch64 user emulation. > >> The version of qemu-aarch64-static is 2.5.0 and it was also occurred > >> on 2.5.1 version. > >> > >> /usr/bin/qemu-aarch64-static --version > >> qemu-aarch64 version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.1), Copyright > >> (c) 2003-2008 Fabrice Bellard > >> > >> == Bug report == > >> kpartx -a -v test.img > >> Unsupported ioctl: cmd=0x4c82 > > > > That's QEMU saying we don't support the ioctl, which is > > LOOP_CTL_GET_FREE. > > > >> *** stack smashing detected ***: /usr/sbin/kpartx terminated > >> ======= Backtrace: ========= > >> /lib64/libc.so.6(+0x6e334)[0x400091d334] > >> /lib64/libc.so.6(__fortify_fail+0x48)[0x400099dd60] > >> /lib64/libc.so.6(+0xeed14)[0x400099dd14] > >> /usr/sbin/kpartx[0x40385c] > >> /usr/sbin/kpartx(read_gpt_pt+0x40)[0x404710] > >> /usr/sbin/kpartx[0x402794] > >> /lib64/libc.so.6(__libc_start_main+0xe8)[0x40008ce810] > >> /usr/sbin/kpartx[0x403100] > > > > This might be the result of kpartx's error handling > > code not reacting well to the ioctl failing, or it might > > be a different problem. > > I got round to testing this with current master myself. > It turns out to be a bug in our handling of the BSGSSZGET > ioctl; we were using the wrong type for it which meant > we would write to more memory than we should have if the > guest was a 64-bit one. I'll send a patch in a moment. > Thanks. I've checked your patch has been fixed the problem. Anyway, there is one more problem. When I tries to detach the loop device using "kpartx -d" command, it was not detached correctly. Below is my test sequence. dd if=/dev/zero of=test.img bs=1M count=32 fdisk test.img << __EOF__ n p w __EOF__ kpartx -a -v test4.img Unsupported ioctl: cmd=0x4c82 add map loop3p1 (252:2) 0 63488 linear /dev/loop3 2048 kpartx -d test4.img <- I expected the loop3 and loop3p1 are detached, but they weren't. Best regards, Chanho Park -- Best Regards, Chanho Park