Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <f9303bdc-b1a7-be5e-56c6-dfa8232b8b55@web.de> <6ee3b703-2161-eacd-c12f-7fa3bedf82dc@web.de>
 <49adf0c8-825a-018f-6d95-ce613944fc9b@web.de> <CAPhsuW7JZDps_fTHyCabjfG4YjzDVEW_41u6d+9mdc2CAJv_Kw@mail.gmail.com>
 <2fbfc20a-71ee-ddaa-19d8-7beed559b491@web.de>
In-Reply-To: <2fbfc20a-71ee-ddaa-19d8-7beed559b491@web.de>
From:   Song Liu <song@kernel.org>
Date:   Wed, 29 Mar 2023 12:03:30 -0700
Message-ID: <CAPhsuW6pEK6mQbo=F7DWPhCW1ePkKP2WM8saoeAfMOCSF3CdOA@mail.gmail.com>
Subject: Re: [0/2] md/raid: Adjustments for two function implementations
To:     Markus Elfring <Markus.Elfring@web.de>
Cc:     kernel-janitors@vger.kernel.org, linux-raid@vger.kernel.org,
        Coly Li <colyli@suse.de>, Jens Axboe <axboe@kernel.dk>,
        Kent Overstreet <kent.overstreet@gmail.com>,
        Maciej Trela <Maciej.Trela@intel.com>,
        Neil Brown <neilb@suse.de>, Shaohua Li <shli@fb.com>,
        cocci@inria.fr, LKML <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Tue, Mar 28, 2023 at 10:32=E2=80=AFPM Markus Elfring <Markus.Elfring@web=
.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 informa=
tion source?
> https://wiki.sei.cmu.edu/confluence/display/c/MEM12-C.+Consider+using+a+g=
oto+chain+when+leaving+a+function+on+error+when+using+and+releasing+resourc=
es#MEM12C.Considerusingagotochainwhenleavingafunctiononerrorwhenusingandrel=
easingresources-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