Re: Re: [PATCH v1] pinctrl: ralink: rt2880: Check for return value of devm_kcalloc()
On Fri, Apr 1, 2022 at 6:06 AM unSimple 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" wrote: > >On Tue, Mar 29, 2022 at 11:36 AM QintaoShen 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 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v1] pinctrl: ralink: rt2880: Check for return value of devm_kcalloc()
On Tue, Mar 29, 2022 at 11:36 AM QintaoShen 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 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v1] pinctrl: ralink: rt2880: Check for return value of devm_kcalloc()
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 > --- > 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 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel