linux-kernel - Re: [0/2] md/raid: Adjustments for two function implementations

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>] [day] [month] [year] [list]

Message-ID: <CAPhsuW6pEK6mQbo=F7DWPhCW1ePkKP2WM8saoeAfMOCSF3CdOA@mail.gmail.com>
Date:   Wed, 29 Mar 2023 12:03:30 -0700
From:   Song Liu <song@...nel.org>
To:     Markus Elfring <Markus.Elfring@....de>
Cc:     kernel-janitors@...r.kernel.org, linux-raid@...r.kernel.org,
        Coly Li <colyli@...e.de>, Jens Axboe <axboe@...nel.dk>,
        Kent Overstreet <kent.overstreet@...il.com>,
        Maciej Trela <Maciej.Trela@...el.com>,
        Neil Brown <neilb@...e.de>, Shaohua Li <shli@...com>,
        cocci@...ia.fr, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [0/2] md/raid: Adjustments for two function implementations

On Tue, Mar 28, 2023 at 10:32 PM Markus Elfring <Markus.Elfring@....de> wrote:
>
> >>   raid1: Fix exception handling in setup_conf()
> >>   raid10: Fix exception handling in setup_conf()
> >
> > The two functions look good to me as-is. I don't think anything is
> > broken except that the code analysis tool complains. I don't think
> > it is necessary to make these changes.
>
> Will development interests ever grow also for advice from another information source?
> https://wiki.sei.cmu.edu/confluence/display/c/MEM12-C.+Consider+using+a+goto+chain+when+leaving+a+function+on+error+when+using+and+releasing+resources#MEM12C.Considerusingagotochainwhenleavingafunctiononerrorwhenusingandreleasingresources-CompliantSolution%28POSIX,GotoChain%29

While I understand "goto chain" is a good pattern for error handling, I am
not convinced it is a better approach here. Specifically, the goto chain is so
long that it is hard to maintain. This also adds overhead for users of
git-blame. Therefore, I would rather keep these two functions as-is.

Thanks,
Song