_______________________________________________
kbuild mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Hi Dan
On Tuesday, June 23, 2020 2:20 AM, Dan Carpenter wrote:
<snip>
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot <[email protected]>
> Reported-by: Dan Carpenter <[email protected]>
>
> New smatch warnings:
> drivers/usb/gadget/udc/fsl_udc_core.c:1055 fsl_ep_fifo_status() error: we
> previously assumed '_ep->desc' could be null (see line 1055)
>
<snip>
>
> 2ea6698d7b9266 drivers/usb/gadget/fsl_udc_core.c Anatolij Gustschin
> 2011-04-18 1047 static int fsl_ep_fifo_status(struct usb_ep *_ep)
> 2ea6698d7b9266 drivers/usb/gadget/fsl_udc_core.c Anatolij Gustschin
> 2011-04-18 1048 {
> 2ea6698d7b9266 drivers/usb/gadget/fsl_udc_core.c Anatolij Gustschin
> 2011-04-18 1049 struct fsl_ep *ep;
> 2ea6698d7b9266 drivers/usb/gadget/fsl_udc_core.c Anatolij Gustschin
> 2011-04-18 1050 struct fsl_udc *udc;
> 2ea6698d7b9266 drivers/usb/gadget/fsl_udc_core.c Anatolij Gustschin
> 2011-04-18 1051 int size = 0;
> 2ea6698d7b9266 drivers/usb/gadget/fsl_udc_core.c Anatolij Gustschin
> 2011-04-18 1052 u32 bitmask;
> 6414e94c203d92 drivers/usb/gadget/fsl_udc_core.c Li Yang
> 2011-11-23 1053 struct ep_queue_head *qh;
> 2ea6698d7b9266 drivers/usb/gadget/fsl_udc_core.c Anatolij Gustschin
> 2011-04-18 1054
> 75eaa498c99eeb drivers/usb/gadget/udc/fsl_udc_core.c Nikhil Badola
> 2019-10-21 @1055 if (!_ep || _ep->desc || !(_ep->desc->bEndpointAddress&0xF))
> ^^^^^^^^^ Reversed NULL test. This will always return -ENODEV. (Or possibly crash. But I suspect it always returns -ENODEV instead of crashing).
So the kernel test reports warning in case of '_ep->desc is null', right?
My understanding is that this judgement would return -ENODEV when
executing '... || _ep-desc ||..' and never execute '_ep->desc->bEndpointAddress' part,
so crash would not happen, am I right?
> The container_of() macro doesn't dereference anything, btw. It just does
> pointer math. I think it would be cleaner to use ep_index() like the original
> code did. In other words, perhaps it would look best written like this:
Yes, I agree using ep_index() would be easier for reading, just feel a little bit
uncomfortable to mix checking on _ep and it's container (ep) in the same line.
> ep = container_of(_ep, struct fsl_ep, ep);
> if (!_ep || !_ep->desc || ep_index(ep) == 0)
>
>
BTW, Nikhil Badola has left NXP (Freesale), so his email address is invalid now.
Thanks & Regards,
Ran
On Tue, Jun 23, 2020 at 02:22:18AM +0000, Ran Wang wrote:
> Hi Dan
>
> On Tuesday, June 23, 2020 2:20 AM, Dan Carpenter wrote:
>
> <snip>
>
> >
> > If you fix the issue, kindly add following tag as appropriate
> > Reported-by: kernel test robot <[email protected]>
> > Reported-by: Dan Carpenter <[email protected]>
> >
> > New smatch warnings:
> > drivers/usb/gadget/udc/fsl_udc_core.c:1055 fsl_ep_fifo_status() error: we
> > previously assumed '_ep->desc' could be null (see line 1055)
> >
>
> <snip>
>
> >
> > 2ea6698d7b9266 drivers/usb/gadget/fsl_udc_core.c Anatolij Gustschin
> > 2011-04-18 1047 static int fsl_ep_fifo_status(struct usb_ep *_ep)
> > 2ea6698d7b9266 drivers/usb/gadget/fsl_udc_core.c Anatolij Gustschin
> > 2011-04-18 1048 {
> > 2ea6698d7b9266 drivers/usb/gadget/fsl_udc_core.c Anatolij Gustschin
> > 2011-04-18 1049 struct fsl_ep *ep;
> > 2ea6698d7b9266 drivers/usb/gadget/fsl_udc_core.c Anatolij Gustschin
> > 2011-04-18 1050 struct fsl_udc *udc;
> > 2ea6698d7b9266 drivers/usb/gadget/fsl_udc_core.c Anatolij Gustschin
> > 2011-04-18 1051 int size = 0;
> > 2ea6698d7b9266 drivers/usb/gadget/fsl_udc_core.c Anatolij Gustschin
> > 2011-04-18 1052 u32 bitmask;
> > 6414e94c203d92 drivers/usb/gadget/fsl_udc_core.c Li Yang
> > 2011-11-23 1053 struct ep_queue_head *qh;
> > 2ea6698d7b9266 drivers/usb/gadget/fsl_udc_core.c Anatolij Gustschin
> > 2011-04-18 1054
> > 75eaa498c99eeb drivers/usb/gadget/udc/fsl_udc_core.c Nikhil Badola
> > 2019-10-21 @1055 if (!_ep || _ep->desc || !(_ep->desc->bEndpointAddress&0xF))
> > ^^^^^^^^^ Reversed NULL test. This will always return -ENODEV. (Or possibly crash. But I suspect it always returns -ENODEV instead of crashing).
>
> So the kernel test reports warning in case of '_ep->desc is null', right?
>
> My understanding is that this judgement would return -ENODEV when
> executing '... || _ep-desc ||..' and never execute '_ep->desc->bEndpointAddress' part,
> so crash would not happen, am I right?
Yeah. I can't imagine how _ep->desc is NULL. It gets set to non-NULL
in fsl_ep_enable() and then set to NULL in fsl_ep_disable().
regards,
dan carpenter