[PATCH v1] pinctrl: ralink: rt2880: Check for return value of devm_kcalloc()

[PATCH v1] pinctrl: ralink: rt2880: Check for return value of devm_kcalloc()

[QintaoShen]

The memory allocation function devm_kcalloc() may return NULL pointer,
so it is better to add a check for 'p->func[i]->pins' to avoid possible
NULL pointer dereference.

Signed-off-by: QintaoShen <unSimple1993@163.com>
---
 drivers/pinctrl/ralink/pinctrl-rt2880.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/pinctrl/ralink/pinctrl-rt2880.c b/drivers/pinctrl/ralink/pinctrl-rt2880.c
index 96fc06d..308610e 100644
--- a/drivers/pinctrl/ralink/pinctrl-rt2880.c
+++ b/drivers/pinctrl/ralink/pinctrl-rt2880.c
@@ -266,6 +266,10 @@ static int rt2880_pinmux_pins(struct rt2880_priv *p)
 						p->func[i]->pin_count,
 						sizeof(int),
 						GFP_KERNEL);
+        
+        if (!p->func[i]->pins)
+            continue;
+
 		for (j = 0; j < p->func[i]->pin_count; j++)
 			p->func[i]->pins[j] = p->func[i]->pin_first + j;
 
-- 
2.7.4

Re: [PATCH v1] pinctrl: ralink: rt2880: Check for return value of devm_kcalloc()

[Greg KH]

On Tue, Mar 29, 2022 at 03:50:12PM +0800, QintaoShen wrote:
> The memory allocation function devm_kcalloc() may return NULL pointer,
> so it is better to add a check for 'p->func[i]->pins' to avoid possible
> NULL pointer dereference.
> 
> Signed-off-by: QintaoShen <unSimple1993@163.com>
> ---
>  drivers/pinctrl/ralink/pinctrl-rt2880.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/pinctrl/ralink/pinctrl-rt2880.c b/drivers/pinctrl/ralink/pinctrl-rt2880.c
> index 96fc06d..308610e 100644
> --- a/drivers/pinctrl/ralink/pinctrl-rt2880.c
> +++ b/drivers/pinctrl/ralink/pinctrl-rt2880.c
> @@ -266,6 +266,10 @@ static int rt2880_pinmux_pins(struct rt2880_priv *p)
>  						p->func[i]->pin_count,
>  						sizeof(int),
>  						GFP_KERNEL);
> +        
> +        if (!p->func[i]->pins)
> +            continue;
> +
>  		for (j = 0; j < p->func[i]->pin_count; j++)
>  			p->func[i]->pins[j] = p->func[i]->pin_first + j;
>  
> -- 
> 2.7.4
> 


Hi,

This is the friendly patch-bot of Greg Kroah-Hartman.  You have sent him
a patch that has triggered this response.  He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created.  Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.

You are receiving this message because of the following common error(s)
as indicated below:

- Your patch contains warnings and/or errors noticed by the
  scripts/checkpatch.pl tool.

If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.

thanks,

greg k-h's patch email bot

Re: [PATCH v1] pinctrl: ralink: rt2880: Check for return value of devm_kcalloc()

[Andy Shevchenko]

On Tue, Mar 29, 2022 at 11:36 AM QintaoShen <unSimple1993@163.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

Re: Re: [PATCH v1] pinctrl: ralink: rt2880: Check for return value of devm_kcalloc()

[Andy Shevchenko]

On Fri, Apr 1, 2022 at 6:06 AM unSimple <unsimple1993@163.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@gmail.com> wrote:
> >On Tue, Mar 29, 2022 at 11:36 AM QintaoShen <unSimple1993@163.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