Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH] usb: u132-hcd: fix potential NULL pointer dereference
To:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc:     pakki001@umn.edu, Colin Ian King <colin.king@canonical.com>,
        Jia-Ju Bai <baijiaju1990@gmail.com>, linux-usb@vger.kernel.org,
        linux-kernel@vger.kernel.org
References: <20190314072713.20666-1-kjlu@umn.edu>
 <20190319135609.GA16254@kroah.com>
From:   Kangjie Lu <kjlu@umn.edu>
Message-ID: <440c18a2-aa7c-9253-0ad8-27ac0a0440d6@umn.edu>
Date:   Tue, 19 Mar 2019 12:20:05 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.5.1
MIME-Version: 1.0
In-Reply-To: <20190319135609.GA16254@kroah.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


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