netdev - Re: [Intel-wired-lan] [PATCH iwl-next v1] iavf: fix proper type for error code in iavf

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <015b02e3-a9b7-4f4f-99da-fdf9bd1f8202@molgen.mpg.de>
Date: Mon, 15 Sep 2025 12:12:03 +0200
From: Paul Menzel <pmenzel@...gen.mpg.de>
To: Przemek Kitszel <przemyslaw.kitszel@...el.com>
Cc: Aleksandr Loktionov <aleksandr.loktionov@...el.com>,
 intel-wired-lan@...ts.osuosl.org, anthony.l.nguyen@...el.com,
 netdev@...r.kernel.org
Subject: Re: [Intel-wired-lan] [PATCH iwl-next v1] iavf: fix proper type for
 error code in iavf_resume()

Dear Przemek,


Thank you for your quick reply.

Am 15.09.25 um 11:58 schrieb Przemek Kitszel:
> On 9/15/25 11:12, Paul Menzel wrote:

>> Am 12.09.25 um 10:02 schrieb Aleksandr Loktionov:
>>> The variable 'err' in iavf_resume() is used to store the return value
>>> of different functions, which return an int. Currently, 'err' is
>>> declared as u32, which is semantically incorrect and misleading.
>>>
>>> In the Linux kernel, u32 is typically reserved for fixed-width data
>>> used in hardware interfaces or protocol structures. Using it for a
>>> generic error code may confuse reviewers or developers into thinking
>>> the value is hardware-related or size-constrained.
>>>
>>> Replace u32 with int to reflect the actual usage and improve code
>>> clarity and semantic correctness.
>>
>> Why not use `unsigned int`?
> 
> I don't think we need to provide rationale for "kernel has adopted
> a long standing practice of encoding errors as negative integer codes"
> each time we change a type, IOW it's too basic thing to mention.

Well, if it was unsigned before, than apparently no negative values were 
ever returned.

>>> No functional change.
>>>
>>> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@...el.com>
>>> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@...el.com>
>>> ---
>>>   drivers/net/ethernet/intel/iavf/iavf_main.c | 2 +-
>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/net/ethernet/intel/iavf/iavf_main.c b/drivers/ 
>>> net/ethernet/intel/iavf/iavf_main.c
>>> index 69054af..c2fbe44 100644
>>> --- a/drivers/net/ethernet/intel/iavf/iavf_main.c
>>> +++ b/drivers/net/ethernet/intel/iavf/iavf_main.c
>>> @@ -5491,7 +5491,7 @@ static int iavf_resume(struct device *dev_d)
>>>   {
>>>       struct pci_dev *pdev = to_pci_dev(dev_d);
>>>       struct iavf_adapter *adapter;
>>> -    u32 err;
>>> +    int err;
>>>       adapter = iavf_pdev_to_adapter(pdev);
>>
>> Reviewed-by: Paul Menzel <pmenzel@...gen.mpg.de>
> 
> Thank you

Actually looking at the involved functions

     err = iavf_set_interrupt_capability(adapter);
     […]
     err = iavf_request_misc_irq(adapter);

they return (signed) integer, so in my opinion, this is the actual 
motivation for the change, and it’d be great, if the commit message 
could be amended accordingly.


Kind regards,

Paul