lkml.org 
[lkml]   [2023]   [Oct]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v8 2/4] usb: gadget: uvc: Allocate uvc_requests one at a time
On Fri, Oct 27, 2023 at 01:31:26PM -0700, Avichal Rakesh wrote:
> >> @@ -322,6 +325,7 @@ uvc_video_free_requests(struct uvc_video *video)
> >>   static int
> >>   uvc_video_alloc_requests(struct uvc_video *video)
> >>   {
> >> +    struct uvc_request *ureq;
> >>       unsigned int req_size;
> >>       unsigned int i;
> >>       int ret = -ENOMEM;
> >> @@ -332,29 +336,34 @@ uvc_video_alloc_requests(struct uvc_video *video)
> >>            * max_t(unsigned int, video->ep->maxburst, 1)
> >>            * (video->ep->mult);
> >>
> >> -    video->ureq = kcalloc(video->uvc_num_requests, sizeof(struct uvc_request), GFP_KERNEL);
> >> -    if (video->ureq == NULL)
> >> -        return -ENOMEM;
> >> +    INIT_LIST_HEAD(&video->ureqs);
> >
> >
> > Probably unecessary here; it's done in uvc_video_free_requests() and uvcg_video_init() already
>
> Ah, that is fair. Added a BUG_ON instead, like we do for video->req_size
> so we still catch cases where the state might be inconsistent.

Please no, that means you just crashed a machine and all data is lost
and the user will get very mad.

Either handle the error properly or it's something that can never happen
and so you don't need to handle it.

thanks,

greg k-h

\
 
 \ /
  Last update: 2023-10-28 07:31    [W:1.667 / U:0.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site