linux-kernel - Re: [PATCH] ravb: Use common error handling code in ravb

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 for Android: free password hash cracker in your pocket

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

Message-ID: <3b700d27-2da5-b7d0-13f0-e55a7df4a24d@users.sourceforge.net>
Date:   Sun, 29 Oct 2017 12:50:37 +0100
From:   SF Markus Elfring <elfring@...rs.sourceforge.net>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Linux-Renesas <linux-renesas-soc@...r.kernel.org>
Cc:     Dan Carpenter <dan.carpenter@...cle.com>,
        "David S. Miller" <davem@...emloft.net>,
        Eugeniu Rosca <erosca@...adit-jv.com>,
        Kazuya Mizuguchi <kazuya.mizuguchi.ks@...esas.com>,
        Masaru Nagai <masaru.nagai.vx@...esas.com>,
        Niklas Söderlund 
        <niklas.soderlund+renesas@...natech.se>,
        Sergei Shtylyov <sergei.shtylyov@...entembedded.com>,
        Simon Horman <horms+renesas@...ge.net.au>,
        Yuval Shaia <yuval.shaia@...cle.com>,
        LKML <linux-kernel@...r.kernel.org>,
        "kernel-janitors@...r.kernel.org" <kernel-janitors@...r.kernel.org>
Subject: Re: [PATCH] ravb: Use common error handling code in ravb_probe()

>> @@ -2069,10 +2069,9 @@ static int ravb_probe(struct platform_device *pdev)
>>                 irq = platform_get_irq_byname(pdev, "ch22");
>>         else
>>                 irq = platform_get_irq(pdev, 0);
>> -       if (irq < 0) {
>> -               error = irq;
>> -               goto out_release;
>> -       }
>> +       if (irq < 0)
>> +               goto failure_indication;
> 
> IMHO, it's really confusing that "irq" contains the error code, not "error".
> Especially when jumping to a meaningless label named "failure_indication"
> ("irq_failure" would be more intuitive).

Thanks for your constructive feedback.


> So I prefer the original code, regardless of the label name.

Can another attempt make sense to concentrate the setting of a variable
at the end of this function with more pleasing identifiers?

Regards,
Markus