linux-kernel - Re: Re: [PATCH v1] pinctrl: ralink: rt2880: Check for return value of devm

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: <CAHp75Vcs+HG-e=BHhgWP6Ndh5nZWXXnqhZ2jfN33Fs0qu5U_Bw@mail.gmail.com>
Date:   Fri, 1 Apr 2022 12:13:27 +0300
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     unSimple <unsimple1993@....com>
Cc:     Linus Walleij <linus.walleij@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jason Yan <yanaijie@...wei.com>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        devicetree <devicetree@...r.kernel.org>,
        "open list:STAGING SUBSYSTEM" <devel@...verdev.osuosl.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Re: [PATCH v1] pinctrl: ralink: rt2880: Check for return value of devm_kcalloc()

On Fri, Apr 1, 2022 at 6:06 AM unSimple <unsimple1993@....com> wrote:

>
> The main consideration of the 'continue' in the patch is that those statements are inner a loop.
>
> The next allocation may be successful so I think it is better to use 'continue' here.

Please, do not top-post!

What you explained is logical from APIs point of view, what I was
asking is about functional point of view.
Why do you think the skipping iteration is fine?

You need to explain this in the code/commit message.

> At 2022-03-29 19:45:50, "Andy Shevchenko" <andy.shevchenko@...il.com> wrote:
> >On Tue, Mar 29, 2022 at 11:36 AM QintaoShen <unSimple1993@....com> wrote:
> >>
> >> The memory allocation function devm_kcalloc() may return NULL pointer,
> >
> >may --> might
> >
> >> so it is better to add a check for 'p->func[i]->pins' to avoid possible
> >> NULL pointer dereference.

...

> >> @@ -266,6 +266,10 @@ static int rt2880_pinmux_pins(struct rt2880_priv *p)
> >>                                                 p->func[i]->pin_count,
> >>                                                 sizeof(int),
> >>                                                 GFP_KERNEL);
> >
> >> +
> >
> >Stray change. Also it seems it has trailing space character(s).
> >
> >> +        if (!p->func[i]->pins)
> >
> >> +            continue;
> >
> >Why is 'continue' the proper choice here? No clarification is given in
> >the commit message.
> >
> >>                 for (j = 0; j < p->func[i]->pin_count; j++)
> >>                         p->func[i]->pins[j] = p->func[i]->pin_first + j;

-- 
With Best Regards,
Andy Shevchenko