Messages in this thread | | | Subject | Re: [PATCH] usb: u132-hcd: fix potential NULL pointer dereference | From | Kangjie Lu <> | Date | Tue, 19 Mar 2019 12:20:05 -0500 |
| |
On 3/19/19 8:56 AM, Greg Kroah-Hartman wrote: > On Thu, Mar 14, 2019 at 02:27:11AM -0500, Kangjie Lu wrote: >> In case create_singlethread_workqueue fails, the fix notifies >> callers the error to avoid potential NULL pointer dereferences. >> >> Signed-off-by: Kangjie Lu <kjlu@umn.edu> >> --- >> drivers/usb/host/u132-hcd.c | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/drivers/usb/host/u132-hcd.c b/drivers/usb/host/u132-hcd.c >> index 934584f0a20a..6d5b532b03f8 100644 >> --- a/drivers/usb/host/u132-hcd.c >> +++ b/drivers/usb/host/u132-hcd.c >> @@ -3203,6 +3203,8 @@ static int __init u132_hcd_init(void) >> return -ENODEV; >> printk(KERN_INFO "driver %s\n", hcd_name); >> workqueue = create_singlethread_workqueue("u132"); >> + if (unlikely(!workqueue)) > You only ever use unlikely/likely if you can actually measure the > difference with and without it. For stuff like this, it is not needed > at all, and in fact, the compiler and CPU already know this type of > thing, so it is going to be faster without it. > > And are you sure you properly unwound from anything that was > created/initialized above these lines? I didn't see what resources require release in this case. Given the existing error paths for usb_disabled() and platform_driver_register(), returning -ENOMEM looks like a consistent error handling. Let me know if it isn't.
> > thanks, > > greg k-h
| |