From: Marcel Apfelbaum <marcel@redhat.com>
To: Mao Zhongyi <maozy.fnst@cn.fujitsu.com>,
Markus Armbruster <armbru@redhat.com>
Cc: qemu-devel@nongnu.org, mst@redhat.com
Subject: Re: [Qemu-devel] [PATCH] pci: Fix unreasonable return value check
Date: Thu, 1 Jun 2017 10:43:55 +0300 [thread overview]
Message-ID: <d33d02ea-ee73-e03d-3bb9-1f9851b3265a@redhat.com> (raw)
In-Reply-To: <67ee539b-1298-635f-cde5-e06397795813@cn.fujitsu.com>
On 01/06/2017 5:51, Mao Zhongyi wrote:
> Hi, Markus
>
> On 05/31/2017 07:07 PM, Markus Armbruster wrote:
>> This is cleanup, not a bug fix, so:
>>
>> pci: Clean up error checking in pci_add_capability()
>>
>> Mao Zhongyi <maozy.fnst@cn.fujitsu.com> writes:
>>
>>> The return value of pci_add_capability2() is only 2 cases, positive
>>> on success, nagetive on failure and set error message to Error. In
>>
>> negative
>>
>>> other worlds, If Error is filled, the return value must be nagetive.
>>
>> words, if
>>
>>> There is no case where errp is set but the return value is a positive.
>>> But pci_add_capability() does. So the return value check is illogical.
>>
>> pci_add_capability2() could use a function comment explaining its return
>> value. Not this patch's job.
>>
>
> Thanks, will make a separated patch to explain it.
>
>>> Meanwhile, all other callers of pci_add_capability2() do the same
>>> check as this patch. So fix it.
>>
>> Suggest:
>>
>> pci: Clean up error checking in pci_add_capability()
>>
>> On success, pci_add_capability2() returns a positive value. On
>> failure, it sets an error and returns a negative value.
>>
>> pci_add_capability() laboriously checks this behavior. No other
>> caller does. Drop the checks from pci_add_capability().
>
> Thanks for your perfect suggestion.
>
>>
>>> Signed-off-by: Mao Zhongyi <maozy.fnst@cn.fujitsu.com>
>>> ---
>>> hw/pci/pci.c | 6 +-----
>>> 1 file changed, 1 insertion(+), 5 deletions(-)
>>>
>>> diff --git a/hw/pci/pci.c b/hw/pci/pci.c
>>> index 259483b..1faf060 100644
>>> --- a/hw/pci/pci.c
>>> +++ b/hw/pci/pci.c
>>> @@ -2269,12 +2269,8 @@ int pci_add_capability(PCIDevice *pdev,
>>> uint8_t cap_id,
>>> Error *local_err = NULL;
>>>
>>> ret = pci_add_capability2(pdev, cap_id, offset, size, &local_err);
>>> - if (local_err) {
>>> - assert(ret < 0);
>>> + if (ret < 0) {
>>> error_report_err(local_err);
>>> - } else {
>>> - /* success implies a positive offset in config space */
>>> - assert(ret > 0);
>>> }
>>> return ret;
>>> }
>>
>> Many functions return distinct error values in addition to setting an
>> error. We usually check one of the two, and assume the other is sane.
>> This is one of the few places where we assert it is. Not wrong, just
>> cumbersome. I'd prefer to drop the assertions, i.e. take this patch.
>> But it's up to the PCI maintainers.
>
> Yes, I also think it really is not necessary. Keeping code as simple as
> practical is desirable. So drop the assertions. Of course, I will listen
> to the views of Marcel and Michael.
>
I have nothing against it.
Thanks for the patch!
With Markus comments:
Reviewed-by: Marcel Apfelbaum <marcel@redhat.com>
Thanks,
Marcel
> Thanks
> Mao
>
>
>
prev parent reply other threads:[~2017-06-01 7:44 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-31 7:04 [Qemu-devel] [PATCH] pci: Fix unreasonable return value check Mao Zhongyi
2017-05-31 11:07 ` Markus Armbruster
2017-06-01 2:51 ` Mao Zhongyi
2017-06-01 7:43 ` Marcel Apfelbaum [this message]
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=d33d02ea-ee73-e03d-3bb9-1f9851b3265a@redhat.com \
--to=marcel@redhat.com \
--cc=armbru@redhat.com \
--cc=maozy.fnst@cn.fujitsu.com \
--cc=mst@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).