On 1/13/26 04:52, Honglei Huang wrote:
This series addresses error handling issues in virtio-gpu and improves code consistency across the virtio-gpu subsystem.The first patch fixes a critical bug in virgl_cmd_resource_create_blob() where an inverted error check causes the function to fail when it should succeed. This is a standalone bug fix that should be backported. The second patch improves code consistency by unifying the error checking style for virtio_gpu_create_mapping_iov() in if-statement contexts across virtio-gpu files, following the preferred QEMU coding convention. Changes since v5: - Reverted changes to virtio-gpu-rutabaga.c to keep CHECK macro usage consistent with other error checks in the same file - Updated patch 2 commit message to clarify that CHECK macro patterns in rutabaga.c are intentionally left unchanged Changes since v4: - Split the single patch into two separate patches for better clarity - Separated the critical bug fix from the style consistency improvements - The bug fix (patch 1) can now be easily identified and backported - The consistency improvements (patch 2) are clearly marked as cleanup Changes since v3: - Extended consistency improvements to virtio-gpu-rutabaga.c - Changed CHECK(!ret) to CHECK(ret >= 0) and CHECK(!result) to CHECK(result >= 0) in rutabaga functions for consistency - Now covers all virtio-gpu files that use virtio_gpu_create_mapping_iov() Changes since v2: - Use 'if (ret < 0)' instead of 'if (ret != 0)' following maintainer's feedback on preferred QEMU coding style for error checking functions that return 0 on success and negative on error - Updated all similar usages across virtio-gpu files for consistency - Expanded scope from single function fix to codebase-wide style consistency Honglei Huang (2): virtio-gpu: fix error handling in virgl_cmd_resource_create_blob virtio-gpu: use consistent error checking for virtio_gpu_create_mapping_iov hw/display/virtio-gpu-virgl.c | 4 ++-- hw/display/virtio-gpu.c | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-)
Is this a qemu-stable material? I'm a bit confused here. The first patch looks like it is, the second I can't decide. Please let me know if I should pick this up for qemu-stable or not. For now I'm picking up the first change. Thanks, /mjt
