linux-kernel - Re: [PATCH 3/3] staging: r8188eu: Reorganize error handling in rtw_drv

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: <24e15d45-40b8-b8a7-b633-9e538324a29b@kernel.org>
Date:   Thu, 12 Aug 2021 16:14:01 -0700
From:   Nathan Chancellor <nathan@...nel.org>
To:     "Fabio M. De Francesco" <fmdefrancesco@...il.com>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Phillip Potter <phil@...lpotter.co.uk>,
        Larry Finger <Larry.Finger@...inger.net>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        linux-staging@...ts.linux.dev, linux-kernel@...r.kernel.org,
        clang-built-linux@...glegroups.com
Subject: Re: [PATCH 3/3] staging: r8188eu: Reorganize error handling in
 rtw_drv_init()

On 8/12/2021 4:11 PM, Fabio M. De Francesco wrote:
> On Thursday, August 12, 2021 10:40:27 PM CEST Nathan Chancellor wrote:
>> [...]
>> Looking at the error function as a whole, the error handling is odd
>> compared to the rest of the kernel, which prefers to set error codes on
>> goto paths, rather than a global "status" variable which determines the
>> error code at the end of the function and function calls in the case of
>> error.
>>
> "status" is not a global variable, instead it is a local variable with only
> in-function visibility and it has an automatic storage duration (i.e., it is
> allocated on the stack frame of the function and is destroyed when the stack
> is unwound at the return from the function).
> 
> According to the above definition there's no difference in storage classes
> between the old "status" and the new "ret" (the latter being a merely rename
> of the former). However, "ret" is a more appropriate name for that variable.
> Furthermore, your handling of errors and return value is more consistent with
> best practices.

Sorry, I meant "global" with regards to the function (as in "was there 
an error in the function"), rather than "global" as a storage class.

> Therefore, apart that minor misuse of the "global" class in your commit
> message, it's a nice work and so...

I am happy to redo the commit message if you and others so desire.

> Acked-by: Fabio M. De Francesco <fmdefrancesco@...il.com>

Thank you for the review and ack!

Cheers,
Nathan