Re: [PULL 00/23] 9p queue 2026-06-29

[Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>]

Hi Christian,

On 7/3/2026 7:36 AM, Christian Schoenebeck wrote:
> On Thursday, 2 July 2026 20:21:54 CEST Pierrick Bouvier wrote:
>> Hi Christian,
>>
>> On 7/1/2026 9:20 AM, Christian Schoenebeck wrote:
>>> On Tuesday, 30 June 2026 09:28:48 CEST Pierrick Bouvier wrote:
>>>> Hi Christian,
>>>
>>> Hi Pierrick,
>>>
>>>> This series brought a test regression:
>>>> $ ./build/pyvenv/bin/meson test -C build \
>>>> --setup thorough --print-errorlogs \
>>>> qemu:qtest-aarch64/qos-test
>>>> ...
>>>> ERROR:../tests/qtest/libqos/virtio-9p-client.c:280:v9fs_req_recv:
>>>> assertion failed (hdr.id == id): (7 == 121)
>>>>
>>>> It seems to come test added in patch 19
>>>> "tests/9p: add 3 xattr FID limit test cases (synth fs driver)"
>>>> This test runs only with slow setup, so I suspect it never worked and
>>>> was never ran.
>>>
>>> Of course I ran these slow tests.
>>
>> I should have added "in our CI" sorry. I'm sure you developed, tested
>> and ran those yourself.
>>
>>> I intentionally registered these tests as "slow" tests as they take a long
>>> time to complete and QEMU tests being notorious on exceeding the overall
>>> CI
>>> timeout limit. So these tests are exempted from running in the official CI
>>> pipeline, but not from mine.
>>>
>>> I just reran them with latest master head. However I am unable to
>>> reproduce
>>> your reported test error so far.
>>>
>>> You cropped the output too aggressively. I need to know:
>>>
>>> - Which test exactly failed? (especially whether it's really a synth
>>> backend> 
>>>   or a local backend test that failed)
>>
>> That's the complete log from the command given above.
>> Note: disk is not full, but the error "no space left on device" is very
>> weird.
> 
> OK, I was able to reproduce the test error. Root cause is that ext4 without 
> ea_inode enabled is limited to ~4KB per xattr block. I'll prepare a patch.
>

Just saw it, I'll test and review it. Thanks!

> For the next time: please note that the most important information is always 
> the name of the test case that failed! There are several ways to run the 
> tests. In the way you ran them, the name of the failed test is printed 
> *before* the stderr block:
> 
> ...
> # slow test /aarch64/virt/generic-pcihost/pci-bus-generic/pci-bus/virtio-9p-
> pci/virtio-9p/virtio-9p-tests/local/deep_absolute_path executed in 1.63 secs
> # Start of xattr_limit tests
> # starting QEMU: exec ./qemu-system-aarch64 -qtest unix:/tmp/qtest-22413.sock 
> -qtest-log /dev/null -chardev socket,path=/tmp/qtest-22413.qmp,id=char0 -mo
> n chardev=char0,mode=control -display none -audio none -run-with exit-with-
> parent=on -M virt, -cpu max -fsdev local,id=fsdev0,path='/src/bee/qemu/build/q
> test-9p-local-KKOMR3',security_model=mapped-xattr -device virtio-9p-
> pci,fsdev=fsdev0,addr=04.0,mount_tag=qtest  -accel qtest
> not ok /aarch64/virt/generic-pcihost/pci-bus-generic/pci-bus/virtio-9p-pci/
> virtio-9p/virtio-9p-tests/local/xattr_limit/default - ERROR:../tests/qtest/lib
> qos/virtio-9p-client.c:280:v9fs_req_recv: assertion failed (hdr.id == id): (7 
> == 121)
> Bail out!
> ----------------------------------- stderr -----------------------------------
> ...
> 
> So here the failing test name was /aarch64/virt/generic-pcihost/pci-bus-
> generic/pci-bus/virtio-9p-pci/virtio-9p/virtio-9p-tests/local/xattr_limit/
> default
> 
> Independent of this particular issue here, I wonder whether there is some way 
> to register a test such that it won't break other people's test pipeline. 
> Because these "local" backend xattr tests are sensible on underlying host 
> capabilities. They are useful for me, but that should not mean to stop the 
> world just because an unrelated test environment is missing a capability.
>

There is no mechanism to attach a criteria to run a test.
In this case, the only solution would be to check this attribute at
runtime (in the test itself), and return 0 to indicate success. IMHO,
that's a perfectly valid strategy. Also, it has the benefit to keep all
the information in the test itself, instead of spreading it across
multiple files.

Functional tests are a bit more evolved and offer some skip
possibilities, and I'm not sure it's worth extending this to other tests.

> /Christian
> 
> 
> 
> 

Thanks,
Pierrick.