Hello.
On 09-01-2011 14:28, Felipe Balbi wrote:
I see no dereference here... Felipe, could you elaborate?
request would have been dereferenced even if request was NULL, see the
return statement:
return&request->request;
There is no actual dereference here -- we're just taking the address of
the field. This code works well unless the offset of the 'request' field is
not 0 (in which case the caller will oops) but it is 0. So this is only a
potential error...
look at the code before making such comments, seriously:
I have looked at this code long enough -- I have actually copied this code
to another driver, and this was noticed/fixed there as a bug, but only
potential bug.
1133 struct usb_request *musb_alloc_request(struct usb_ep *ep, gfp_t
gfp_flags)
1134 {
1135 struct musb_ep *musb_ep = to_musb_ep(ep);
1136 struct musb_request *request = NULL;
1137
1138 request = kzalloc(sizeof *request, gfp_flags);
1139 if (request) {
1140 INIT_LIST_HEAD(&request->request.list);
1141 request->request.dma = DMA_ADDR_INVALID;
1142 request->epnum = musb_ep->current_epnum;
1143 request->ep = musb_ep;
1144 }
1145
1146 return&request->request;
1147 }
See that struct musb_request *request is the one which is being
allocated. If it ends up being NULL (kzalloc() failed) we will still
dereference it to pass down the pointer to struct usb_request to gadget
driver, so we will be doing:
return &NULL->request;
I can only repeat what I've said: there is no actual dereference here as
we're not following the NULL pointer. Mind the & operator -- we're only
adding offset of the field (0) to NULL which doesn't change it, so we still
return NULL.
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
