qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Huth <thuth@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: QEMU Developers <qemu-devel@nongnu.org>,
	hreitz@redhat.com, Maxim Levitsky <mlevitsk@redhat.com>,
	Hyman Huang <yong.huang@smartx.com>
Subject: Re: Some iotests are failing with -luks
Date: Thu, 11 Sep 2025 13:21:35 +0200	[thread overview]
Message-ID: <58d82de4-25ac-48f5-ae80-181faf2bf8cf@redhat.com> (raw)
In-Reply-To: <aMGijXg9XIpbbn-v@redhat.com>

On 10/09/2025 18.08, Kevin Wolf wrote:
> Am 10.09.2025 um 17:16 hat Thomas Huth geschrieben:
>>
>>   Hi,
>>
>> when running "./check -luks" in the qemu-iotests directory,
>> some tests are failing for me:
>>
>> 295 296 inactive-node-nbd luks-detached-header
>>
>> Is that a known problem already?
> 
> Not to me anyway.
> 
>> FWIW, 295 is failing with the following output:
>>
>> 295   fail       [17:03:01] [17:03:17]   15.7s                failed, exit status 1
>> [...]
>> +EWARNING:qemu.machine.machine:qemu received signal 6; command: "/home/thuth/tmp/qemu-build/qemu-system-x86_64 -display none -vga none -chardev socket,id=mon,fd=5 -mon chardev=mon,mode=control -chardev socket,id=qtest,fd=3 -qtest chardev:qtest -accel qtest -nodefaults -display none -accel qtest"
>> +EEWARNING:qemu.machine.machine:qemu received signal 6; command: "/home/thuth/tmp/qemu-build/qemu-system-x86_64 -display none -vga none -chardev socket,id=mon,fd=6 -mon chardev=mon,mode=control -chardev socket,id=qtest,fd=3 -qtest chardev:qtest -accel qtest -nodefaults -display none -accel qtest"
>> +EEWARNING:qemu.machine.machine:qemu received signal 6; command: "/home/thuth/tmp/qemu-build/qemu-system-x86_64 -display none -vga none -chardev socket,id=mon,fd=10 -mon chardev=mon,mode=control -chardev socket,id=qtest,fd=3 -qtest chardev:qtest -accel qtest -nodefaults -display none -accel qtest"
>> +E
>> [...]
>>
>> etc.
>>
>> 296 looks very similar (also a "qemu received signal 6" error),
>> but the others look like this:
> 
> When it gets signal 6 (i.e. SIGABRT), that usually means that you should
> have a look at the coredump.

With "-p" I additionally get this error message in the log:

qemu-system-x86_64: ../../devel/qemu/block/graph-lock.c:294:
  bdrv_graph_rdlock_main_loop: Assertion `!qemu_in_coroutine()' failed.

With -gdb I can get a back trace that looks like this:

Thread 1 "qemu-system-x86" received signal SIGABRT, Aborted.
0x00007ffff4ba7e9c in __pthread_kill_implementation () from target:/lib64/libc.so.6
--Type <RET> for more, q to quit, c to continue without paging--
#0  0x00007ffff4ba7e9c in __pthread_kill_implementation () from target:/lib64/libc.so.6
#1  0x00007ffff4b4df3e in raise () from target:/lib64/libc.so.6
#2  0x00007ffff4b356d0 in abort () from target:/lib64/libc.so.6
#3  0x00007ffff4b35639 in __assert_fail_base.cold () from target:/lib64/libc.so.6
#4  0x0000555555574eae in bdrv_graph_rdlock_main_loop () at ../../devel/qemu/block/graph-lock.c:294
#5  0x0000555555aa2f43 in graph_lockable_auto_lock_mainloop (x=<optimized out>) at /home/thuth/devel/qemu/include/block/graph-lock.h:275
#6  block_crypto_read_func (block=<optimized out>, offset=4096, buf=0x555558324100 "", buflen=256000, opaque=0x555558a259d0, errp=0x555558a8c370)
     at ../../devel/qemu/block/crypto.c:71
#7  0x0000555555a5a308 in qcrypto_block_luks_load_key (block=block@entry=0x555558686ec0, slot_idx=slot_idx@entry=0,
     password=password@entry=0x555558626050 "hunter0", masterkey=masterkey@entry=0x55555886b2a0 "",
     readfunc=readfunc@entry=0x555555aa2f10 <block_crypto_read_func>, opaque=opaque@entry=0x555558a259d0, errp=0x555558a8c370)
     at ../../devel/qemu/crypto/block-luks.c:927
#8  0x0000555555a5ba7e in qcrypto_block_luks_find_key (block=0x555558686ec0, password=0x555558626050 "hunter0", masterkey=0x55555886b2a0 "",
     readfunc=0x555555aa2f10 <block_crypto_read_func>, opaque=0x555558a259d0, errp=0x555558a8c370) at ../../devel/qemu/crypto/block-luks.c:1045
#9  qcrypto_block_luks_amend_add_keyslot (block=0x555558686ec0, readfunc=0x555555aa2f10 <block_crypto_read_func>,
     writefunc=0x555555aa2e50 <block_crypto_write_func>, opaque=0x555558a259d0, opts_luks=0x7fffec5fff38, force=<optimized out>, errp=0x555558a8c370)
     at ../../devel/qemu/crypto/block-luks.c:1673
#10 qcrypto_block_luks_amend_options (block=0x555558686ec0, readfunc=0x555555aa2f10 <block_crypto_read_func>,
     writefunc=0x555555aa2e50 <block_crypto_write_func>, opaque=0x555558a259d0, options=0x7fffec5fff30, force=<optimized out>, errp=0x555558a8c370)
     at ../../devel/qemu/crypto/block-luks.c:1865
#11 0x0000555555aa3852 in block_crypto_amend_options_generic_luks (bs=<optimized out>, amend_options=<optimized out>, force=<optimized out>,
     errp=<optimized out>) at ../../devel/qemu/block/crypto.c:949
#12 0x0000555555aa38e9 in block_crypto_co_amend_luks (bs=<optimized out>, opts=<optimized out>, force=<optimized out>, errp=<optimized out>)
     at ../../devel/qemu/block/crypto.c:1008
#13 0x0000555555a96030 in blockdev_amend_run (job=0x555558a8c2b0, errp=0x555558a8c370) at ../../devel/qemu/block/amend.c:52
#14 0x0000555555a874ad in job_co_entry (opaque=0x555558a8c2b0) at ../../devel/qemu/job.c:1112
#15 0x0000555555bdc41b in coroutine_trampoline (i0=<optimized out>, i1=<optimized out>) at ../../devel/qemu/util/coroutine-ucontext.c:175
#16 0x00007ffff4b68f70 in ?? () from target:/lib64/libc.so.6
#17 0x00007fffffffc310 in ?? ()
#18 0x0000000000000000 in ?? ()

>> inactive-node-nbd   fail       [17:13:56] [17:14:04]   7.5s                 failed, exit status 1
>> --- /home/thuth/devel/qemu/tests/qemu-iotests/tests/inactive-node-nbd.out
>> +++ /home/thuth/tmp/qemu-build/tests/qemu-iotests/scratch/luks-file-inactive-node-nbd/inactive-node-nbd.out.bad
>> @@ -1,239 +1,64 @@
>>   Preparing disk...
>>   Launching VM...
>> -{"execute": "nbd-server-start", "arguments": {"addr": {"data": {"path": "SOCK_DIR/PID-nbd.sock"}, "type": "unix"}}}
>> -{"return": {}}
>> +ERROR:qemu.qmp.qmp_client.qemu-223907:Failed to receive Greeting: EOFError
>> +ERROR:qemu.qmp.qmp_client.qemu-223907:Failed to establish session: EOFError
>> +Traceback (most recent call last):
>> +  File "/home/thuth/devel/qemu/python/qemu/qmp/protocol.py", line 425, in _session_guard
>> +    await coro
>> +  File "/home/thuth/devel/qemu/python/qemu/qmp/qmp_client.py", line 250, in _establish_session
>> +    self._greeting = await self._get_greeting()
>> +                     ^^^^^^^^^^^^^^^^^^^^^^^^^^
>> +  File "/home/thuth/devel/qemu/python/qemu/qmp/qmp_client.py", line 270, in _get_greeting
>> +    msg = await self._recv()
>> +          ^^^^^^^^^^^^^^^^^^
>> +  File "/home/thuth/devel/qemu/python/qemu/qmp/protocol.py", line 1009, in _recv
>> +    message = await self._do_recv()
>> +              ^^^^^^^^^^^^^^^^^^^^^
>> +  File "/home/thuth/devel/qemu/python/qemu/qmp/qmp_client.py", line 402, in _do_recv
>> +    msg_bytes = await self._readline()
>> +                ^^^^^^^^^^^^^^^^^^^^^^
>> +  File "/home/thuth/devel/qemu/python/qemu/qmp/protocol.py", line 977, in _readline
>> +    raise EOFError
>> +EOFError
> 
> Not sure what this is. It looks like the QEMU process failed to start,
> maybe it didn't like some command line option. I would expect an error
> message on stderr, but I'm not sure if qemu-iotests automatically
> displays that in such cases. I thought that yes, but maybe I'm confusing
> it with a different case.

With "-p" I'm getting this additional error message:

qemu-system-x86_64: -blockdev luks,file=disk-file,node-name=disk-fmt,active=off: Parameter 'key-secret' is required for cipher

  HTH,
   Thomas



  parent reply	other threads:[~2025-09-11 11:22 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-10 15:16 Some iotests are failing with -luks Thomas Huth
2025-09-10 16:08 ` Kevin Wolf
2025-09-10 18:38   ` Kevin Wolf
2025-09-11  2:33     ` Yong Huang
2025-09-11 10:04       ` Kevin Wolf
2025-09-11 10:38         ` Daniel P. Berrangé
2025-09-15 13:18           ` Kevin Wolf
2025-09-11  8:43     ` Daniel P. Berrangé
2025-09-11 11:21   ` Thomas Huth [this message]
2025-09-11 12:13     ` Kevin Wolf
2025-09-12 14:23       ` Daniel P. Berrangé
2025-09-12 14:53         ` Kevin Wolf
2025-09-12 18:35           ` Daniel P. Berrangé
2025-09-15 12:45             ` Kevin Wolf

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=58d82de4-25ac-48f5-ae80-181faf2bf8cf@redhat.com \
    --to=thuth@redhat.com \
    --cc=hreitz@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mlevitsk@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=yong.huang@smartx.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).