Thanks Jonas, and thanks Renan for assigning this. I noticed this may already be assigned, so I don't want to duplicate anyone's work. If there is an opportunity for me to help with the fix or packaging, I would be happy to contribute.
I have one point I'd appreciate some clarity on before proceeding. Based on my source-level verification, the fix is already present in 26.04 and the development release, while Noble is the only series that appears to need a patch: * 26.10 (stonking): qemu 1:11.0.3+ds-2ubuntu1 — contains the fix * 26.04 (resolute): qemu 1:10.2.1+ds-1ubuntu3.2 — contains the fix * 24.04 (noble): qemu 1:8.2.2+ds-0ubuntu1.18 — does not contain the fix So Noble appears to be the Ubuntu series that needs a change, and the requirement that the fix first land in the development release appears to already be satisfied. Should I target the Noble packaging branch directly, or would you still prefer merge proposals for 26.10 and 26.04 for process reasons? Either is fine with me; I just did not want to open two no-op MRs if they are not required. I also verified the above from the QEMU source rather than relying on version numbers or release notes. Kevin Wolf's original commit (4af976ef398e) did not have a `Cc: qemu- stable`, so it was not automatically selected for the stable branches. Michael Tokarev later cherry-picked the fix manually into stable-10.0 as a different commit (`d1a5c0c7a`). Because of that, checking whether the original SHA is present in a release is not sufficient. Instead, I checked the actual `block/rbd.c` contents at the relevant QEMU tags. In particular, I verified the removal of the `"cannot read image start for probe"` error and the addition of: `encryption_format = s->encryption_format` Based on those source checks: * First QEMU release containing the fix: 10.1.0 (2025-08-26) * Also fixed: 10.0.4 (2025-09-08, via the manual stable-10.0 cherry-pick) * Fixed in subsequent 10.1, 10.2, 11.0 and 11.1 releases * Not fixed in 8.2.x, 9.0.x, 9.1.x or 9.2.x For the Noble package specifically, I extracted the Ubuntu source package and checked the complete 134-patch series and changelog. I could not find this fix, nor another patch addressing the same `rbd`/`specific_info` issue. I also checked `-proposed` and `-backports`; neither contains the fix. The Ubuntu Cloud Archive does not currently provide a QEMU package for Noble. I also checked whether simply moving Noble to a later 8.2.x release would solve the issue. It would not: `block/rbd.c` is byte-identical from v8.2.0 through v8.2.10, so the relevant code was never changed on that branch. v8.2.10 was released on 2025-03-26, while the fix was authored on 2025-08-11. I also contacted the upstream QEMU maintainer to ask whether this fix could be considered for stable-8.2. The maintainer confirmed that the 8.2 branch is EOL and that the stable-8.2 line is now closed, so an upstream stable release containing this fix is not expected. The maintainer also explained that Ubuntu had previously asked for the 8.2 stable line to be maintained for longer, and the line was temporarily resumed, but the subsequent 8.2.x releases were apparently not consumed by Ubuntu 24.04. Based on that discussion, I don't think waiting for an upstream stable-8.2 release is a viable path for Noble. I also raised a stable-8.2 backport request upstream, but it was declined: https://gitlab.com/qemu-project/qemu/-/work_items/4451 Therefore, for Noble, a targeted Ubuntu patch appears to be the most straightforward route, unless the Ubuntu QEMU team would prefer to move Noble to a newer QEMU version. I have already built and tested the targeted patch locally: * It applies cleanly to `1:8.2.2+ds-0ubuntu1.16`: 9 hunks in `block/rbd.c` and 1 in `qapi/block-core.json`; the changes are only line-offset differences with no conflicts. * On real hardware, `virsh domstats --block` during the throttled- discard scenario went from 60.39 s, with the guest effectively frozen and `rcu_preempt` stalls, to 0.141–0.153 s across six runs. `block- rbd.so` was the only variable. * There is one packaging detail worth mentioning for anyone testing by replacing only the module. `util/module.c` requires the module to export `qemu_stamp<CONFIG_STAMP>`, and `scripts/qemu-stamp.py` derives this stamp from the Meson version, package version and `configure` contents. Building with `dch --local` changes the stamp, so QEMU rejects the individually replaced module with `"Only modules from the same build can be loaded."` / `"Unknown driver 'rbd'`. A normal Ubuntu version bump followed by a complete rebuild does not have this issue. So need clarity - Should we apply the patch only ? - should we upgrade qemu to the 10.x .x stable version? If this direction makes sense, I would be happy to prepare the Noble change and contribute whatever is useful. I would just appreciate some guidance on whether Noble should be targeted directly, or whether a newer QEMU version is preferred for Noble. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2166503 Title: rbd: blocking rbd_read() in .bdrv_get_specific_info freezes guests To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/2166503/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
