aboutsummaryrefslogtreecommitdiff
path: root/tests/qemu-iotests/308.out
AgeCommit message (Collapse)Author
2024-01-26monitor: only run coroutine commands in qemu_aio_contextStefan Hajnoczi
monitor_qmp_dispatcher_co() runs in the iohandler AioContext that is not polled during nested event loops. The coroutine currently reschedules itself in the main loop's qemu_aio_context AioContext, which is polled during nested event loops. One known problem is that QMP device-add calls drain_call_rcu(), which temporarily drops the BQL, leading to all sorts of havoc like other vCPU threads re-entering device emulation code while another vCPU thread is waiting in device emulation code with aio_poll(). Paolo Bonzini suggested running non-coroutine QMP handlers in the iohandler AioContext. This avoids trouble with nested event loops. His original idea was to move coroutine rescheduling to monitor_qmp_dispatch(), but I resorted to moving it to qmp_dispatch() because we don't know if the QMP handler needs to run in coroutine context in monitor_qmp_dispatch(). monitor_qmp_dispatch() would have been nicer since it's associated with the monitor implementation and not as general as qmp_dispatch(), which is also used by qemu-ga. A number of qemu-iotests need updated .out files because the order of QMP events vs QMP responses has changed. Solves Issue #1933. Cc: qemu-stable@nongnu.org Fixes: 7bed89958bfbf40df9ca681cefbdca63abdde39d ("device_core: use drain_call_rcu in in qmp_device_add") Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=2215192 Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=2214985 Buglink: https://issues.redhat.com/browse/RHEL-17369 Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-ID: <20240118144823.1497953-4-stefanha@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Tested-by: Fiona Ebner <f.ebner@proxmox.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2023-03-10iotests/308: Add test for 'write -zu'Hanna Czenczek
Try writing zeroes to a FUSE export while allowing the area to be unmapped; block/file-posix.c generally implements writing zeroes with BDRV_REQ_MAY_UNMAP ('write -zu') by calling fallocate(PUNCH_HOLE). This used to lead to a blk_pdiscard() in the FUSE export, which may or may not lead to the area being zeroed. HEAD^ fixed this to use blk_pwrite_zeroes() instead (again with BDRV_REQ_MAY_UNMAP), so verify that running `qemu-io 'write -zu'` on a FUSE exports always results in zeroes being written. Signed-off-by: Hanna Czenczek <hreitz@redhat.com> Message-Id: <20230227104725.33511-3-hreitz@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2022-01-14iotests/308: Fix for CAP_DAC_OVERRIDEHanna Reitz
With CAP_DAC_OVERRIDE (which e.g. root generally has), permission checks will be bypassed when opening files. 308 in one instance tries to open a read-only file (FUSE export) with qemu-io as read/write, and expects this to fail. However, when running it as root, opening will succeed (thanks to CAP_DAC_OVERRIDE) and only the actual write operation will fail. Note this as "Case not run", but have the test pass in either case. Reported-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Fixes: 2c7dd057aa7bd7a875e9b1a53975c220d6380bc4 ("export/fuse: Pass default_permissions for mount") Signed-off-by: Hanna Reitz <hreitz@redhat.com> Message-Id: <20220103120014.13061-1-hreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2021-07-09iotests/308: Test +w on read-only FUSE exportsMax Reitz
Test that +w on read-only FUSE exports returns an EROFS error. u+x on the other hand should work. (There is no special reason to choose u+x here, it simply is like +w another flag that is not set by default.) Signed-off-by: Max Reitz <mreitz@redhat.com> Message-Id: <20210625142317.271673-6-mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2021-07-09export/fuse: Pass default_permissions for mountMax Reitz
We do not do any permission checks in fuse_open(), so let the kernel do them. We already let fuse_getattr() report the proper UNIX permissions, so this should work the way we want. This causes a change in 308's reference output, because now opening a non-writable export with O_RDWR fails already, instead of only actually attempting to write to it. (That is an improvement.) Signed-off-by: Max Reitz <mreitz@redhat.com> Message-Id: <20210625142317.271673-2-mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-12-18iotests: Fix _send_qemu_cmd with bash 5.1Max Reitz
With bash 5.1, the output of the following script changes: a=("double space") a=${a[@]:0:1} echo "$a" from "double space" to "double space", i.e. all white space is preserved as-is. This is probably what we actually want here (judging from the "...to accommodate pathnames with spaces" comment), but before 5.1, we would have to quote the ${} slice to get the same behavior. In any case, without quoting, the reference output of many iotests is different between bash 5.1 and pre-5.1, which is not very good. The output of 5.1 is what we want, so whatever we do to get pre-5.1 to the same result, it means we have to fix the reference output of basically all tests that invoke _send_qemu_cmd (except the ones that only use single spaces in the commands they invoke). Instead of quoting the ${} slice (cmd="${$@: 1:...}"), we can also just not use array slicing and replace the whole thing with a simple "cmd=$1; shift", which works because all callers quote the whole $cmd argument anyway. Signed-off-by: Max Reitz <mreitz@redhat.com> Message-Id: <20201217153803.101231-3-mreitz@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com>
2020-12-11iotests/308: Add test for FUSE exportsMax Reitz
We have good coverage of the normal I/O paths now, but what remains is a test that tests some more special cases: Exporting an image on itself (thus turning a formatted image into a raw one), some error cases, and non-writable and non-growable exports. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20201027190600.192171-21-mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>