qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Dmitry Osipenko <dmitry.osipenko@collabora.com>
To: Honglei Huang <honghuan@amd.com>, Markus Armbruster <armbru@redhat.com>
Cc: alex.bennee@linaro.org, odaki@rsg.ci.i.u-tokyo.ac.jp,
	mst@redhat.com, cohuck@redhat.com, pbonzini@redhat.com,
	qemu-devel@nongnu.org, Ray.Huang@amd.com
Subject: Re: [v4] virtio-gpu: use consistent error checking style for virtio_gpu_create_mapping_iov
Date: Thu, 20 Nov 2025 05:03:49 +0300	[thread overview]
Message-ID: <8ce3a9dc-e4a8-4dd7-99dc-30b02b07f4c9@collabora.com> (raw)
In-Reply-To: <cc80a97c-ca8c-4da6-bbd9-77f1c90a299d@collabora.com>

On 11/19/25 22:16, Dmitry Osipenko wrote:
> On 11/18/25 15:32, Honglei Huang wrote:
>>
>>
>> On 2025/11/18 09:48, Dmitry Osipenko wrote:
>>> On 11/17/25 16:22, Markus Armbruster wrote:
>>>> Dmitry Osipenko <dmitry.osipenko@collabora.com> writes:
>>>>
>>>>> On 11/17/25 13:51, Honglei Huang wrote:
>>>>>> diff --git a/hw/display/virtio-gpu-rutabaga.c b/hw/display/virtio-
>>>>>> gpu-rutabaga.c
>>>>>> index ed5ae52acb..ea2928b706 100644
>>>>>> --- a/hw/display/virtio-gpu-rutabaga.c
>>>>>> +++ b/hw/display/virtio-gpu-rutabaga.c
>>>>>> @@ -466,7 +466,7 @@ rutabaga_cmd_attach_backing(VirtIOGPU *g,
>>>>>> struct virtio_gpu_ctrl_command *cmd)
>>>>>>         ret = virtio_gpu_create_mapping_iov(g, att_rb.nr_entries,
>>>>>> sizeof(att_rb),
>>>>>>                                           cmd, NULL, &res->iov,
>>>>>> &res->iov_cnt);
>>>>>> -    CHECK(!ret, cmd);
>>>>>> +    CHECK(ret >= 0, cmd);
>>>>>
>>>>> virtio_gpu_create_mapping_iov() doesn't return positive values, don't
>>>>> see how this change improves anything. You now saying that ret > 0 is
>>>>> okay, while it shall never happen.
>>>>
>>>> Please see
>>>>
>>>>      Subject: Re: [PATCH] virtio-gpu-virgl: fix error handling in
>>>> virgl_cmd_resource_create_blob
>>>>      Date: Mon, 17 Nov 2025 08:49:42 +0100
>>>>      Message-ID: <87ms4lrtd5.fsf@pond.sub.org>
>>>>      https://lore.kernel.org/qemu-devel/87ms4lrtd5.fsf@pond.sub.org/
>>>
>>> It's a rather common bug when errno isn't negated by mistake and a
>>> positive error code is returned. Ignoring positive values when they
>>> aren't expected opens door to unnecessary problems, IMO.
>>>
>>
>> How about apply the v2 or v3 firstly to fix the
>> virtio_gpu_create_mapping_iov() block issue in virtio-gpu?
>>
>> I will create another thread for the `CHECK(!ret, cmd);` thing in rutabaga.
> 
> There was a precedent of virtio-gpu not handling positive error codes
> properly [1]. To me there is no problem that needs to be fixed when
> virtio_gpu_create_mapping_iov() is never expected to return positive
> values and doesn't return them.
> 
> [1]
> https://lore.kernel.org/qemu-devel/20240129073921.446869-1-dmitry.osipenko@collabora.com/
> 
> It's a common expectation that errors are negative. But in practice it's
> not always true, especially when interacting with external code.
> 
> Functionally this patch doesn't change anything. Will leave to Alex and
> Akihiko to decide on it.

Alright, I changed my mind after just typing a code where a fact of
error occurrence needs to be propagated. For a code that is internal to
QEMU, it should be fine to check for err < 0 because static analysis
tools should catch invalid error handling and using same style makes
code look more consistent and pleasant to read.

For errors originated externally, I'll continue to advocate for checking
of both pos and neg values.

-- 
Best regards,
Dmitry


  parent reply	other threads:[~2025-11-20  2:05 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-17 10:51 [v4] virtio-gpu: use consistent error checking style for virtio_gpu_create_mapping_iov Honglei Huang
2025-11-17 11:53 ` Markus Armbruster
2025-11-17 12:03 ` Dmitry Osipenko
2025-11-17 13:22   ` Markus Armbruster
2025-11-18  1:48     ` Dmitry Osipenko
2025-11-18  5:45       ` Markus Armbruster
2025-11-20  2:51         ` Dmitry Osipenko
2025-11-18 12:32       ` Honglei Huang
2025-11-19 19:16         ` Dmitry Osipenko
2025-11-20  1:29           ` Akihiko Odaki
2025-11-20  2:45             ` Dmitry Osipenko
2025-11-20  1:31           ` Honglei Huang
2025-11-20  2:03           ` Dmitry Osipenko [this message]
  -- strict thread matches above, loose matches on Subject: below --
2025-11-21  7:58 Honglei Huang
2025-11-21  8:14 ` Honglei Huang
2025-11-21 18:00   ` Dmitry Osipenko

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=8ce3a9dc-e4a8-4dd7-99dc-30b02b07f4c9@collabora.com \
    --to=dmitry.osipenko@collabora.com \
    --cc=Ray.Huang@amd.com \
    --cc=alex.bennee@linaro.org \
    --cc=armbru@redhat.com \
    --cc=cohuck@redhat.com \
    --cc=honghuan@amd.com \
    --cc=mst@redhat.com \
    --cc=odaki@rsg.ci.i.u-tokyo.ac.jp \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /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).