[RFC PATCH] Bluetooth: btusb: Fix memory leak in play_deferred

[RFC PATCH] Bluetooth: btusb: Fix memory leak in play_deferred

[Jeffy Chen]

Currently in play_deferred, we are calling usb_submit_urb directly to
submit deferred tx urb after unanchor it.

So the usb_giveback_urb_bh would failed to unref it in usb_unanchor_urb
and cause memory leak:
unreferenced object 0xffffffc0ce0fa400 (size 256):
...
  backtrace:
    [<ffffffc00034a9a8>] __save_stack_trace+0x48/0x6c
    [<ffffffc00034b088>] create_object+0x138/0x254
    [<ffffffc0009d5504>] kmemleak_alloc+0x58/0x8c
    [<ffffffc000345f78>] __kmalloc+0x1d4/0x2a0
    [<ffffffc0006765bc>] usb_alloc_urb+0x30/0x60
    [<ffffffbffc128598>] alloc_ctrl_urb+0x38/0x120 [btusb]
    [<ffffffbffc129e7c>] btusb_send_frame+0x64/0xf8 [btusb]

Use submit_tx_urb instead for better error handling and avoid the leak.

Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
---

 drivers/bluetooth/btusb.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 278e811..b469f9b 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -3254,11 +3254,12 @@ static int btusb_suspend(struct usb_interface *intf, pm_message_t message)
 
 static void play_deferred(struct btusb_data *data)
 {
+	struct hci_dev *hdev = data->hdev;
 	struct urb *urb;
 	int err;
 
 	while ((urb = usb_get_from_anchor(&data->deferred))) {
-		err = usb_submit_urb(urb, GFP_ATOMIC);
+		err = submit_tx_urb(hdev, urb);
 		if (err < 0)
 			break;
 
-- 
2.1.4

Re: [RFC PATCH] Bluetooth: btusb: Fix memory leak in play_deferred

[Marcel Holtmann]

Hi Jeffy,

> Currently in play_deferred, we are calling usb_submit_urb directly to
> submit deferred tx urb after unanchor it.
> 
> So the usb_giveback_urb_bh would failed to unref it in usb_unanchor_urb
> and cause memory leak:
> unreferenced object 0xffffffc0ce0fa400 (size 256):
> ...
>  backtrace:
>    [<ffffffc00034a9a8>] __save_stack_trace+0x48/0x6c
>    [<ffffffc00034b088>] create_object+0x138/0x254
>    [<ffffffc0009d5504>] kmemleak_alloc+0x58/0x8c
>    [<ffffffc000345f78>] __kmalloc+0x1d4/0x2a0
>    [<ffffffc0006765bc>] usb_alloc_urb+0x30/0x60
>    [<ffffffbffc128598>] alloc_ctrl_urb+0x38/0x120 [btusb]
>    [<ffffffbffc129e7c>] btusb_send_frame+0x64/0xf8 [btusb]
> 
> Use submit_tx_urb instead for better error handling and avoid the leak.
> 
> Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
> ---
> 
> drivers/bluetooth/btusb.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> index 278e811..b469f9b 100644
> --- a/drivers/bluetooth/btusb.c
> +++ b/drivers/bluetooth/btusb.c
> @@ -3254,11 +3254,12 @@ static int btusb_suspend(struct usb_interface *intf, pm_message_t message)
> 
> static void play_deferred(struct btusb_data *data)
> {
> +	struct hci_dev *hdev = data->hdev;
> 	struct urb *urb;
> 	int err;
> 
> 	while ((urb = usb_get_from_anchor(&data->deferred))) {
> -		err = usb_submit_urb(urb, GFP_ATOMIC);
> +		err = submit_tx_urb(hdev, urb);
> 		if (err < 0)
> 			break;

so why not just fix the memory leak here and instead call submit_tx_urb. I am not sure that is actually the right approach. Why anchor this URB now to the TX anchor now? Is that actually safe?

Regards

Marcel

Re: [RFC PATCH] Bluetooth: btusb: Fix memory leak in play_deferred

[jeffy]

Hi Oliver,

Thanx for your comments, and sorry for reply late.

On 07/04/2017 07:38 PM, Oliver Neukum wrote:
> Am Freitag, den 23.06.2017, 11:46 +0800 schrieb jeffy:
>>
>>>> ---
>>>>
>>>> drivers/bluetooth/btusb.c | 3 ++-
>>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
>>>> index 278e811..b469f9b 100644
>>>> --- a/drivers/bluetooth/btusb.c
>>>> +++ b/drivers/bluetooth/btusb.c
>>>> @@ -3254,11 +3254,12 @@ static int btusb_suspend(struct usb_interface *intf, pm_message_t message)
>>>>
>>>> static void play_deferred(struct btusb_data *data)
>>>> {
>>>> +	struct hci_dev *hdev = data->hdev;
>>>> 	struct urb *urb;
>>>> 	int err;
>>>>
>>>> 	while ((urb = usb_get_from_anchor(&data->deferred))) {
>>>> -		err = usb_submit_urb(urb, GFP_ATOMIC);
>>>> +		err = submit_tx_urb(hdev, urb);
>
> If you do that you have to change submit_tx_urb() to be called under a
> spinlock.

sorry, why we need that? since submit_tx_urb is basically 
usb_anchor_urb/usb_submit_urb/usb_free_urb

>
>>>> 		if (err < 0)
>>>> 			break;
>>>
>>> so why not just fix the memory leak here and instead call submit_tx_urb. I am not sure that is actually the right approach. Why anchor this URB now to the TX anchor now? Is that actually safe?
>>>
>> the current flow is:
>>     submit_or_queue_tx_urb
>>       if (!suspending)
>>         submit_tx_urb
>>       else
>>         put into deferred anchor
>>         wake btusb
>>
>>     retry the deferred urbs in deferred anchor(using usb_submit_urb)
>> after resumed
>>
>> so i think there are 2 problems here:
>> 1/ error handling, compare submit_tx_urb to usb_submit_urb, it freed
>> urb->setup_packet when failed to submit
>
> In theory yes. If we ever put control URBs on the deferred anchor.
>
>> 2/ memory leak:
>> in usb_submit_urb, we ref that urb
>> in __usb_hcd_giveback_urb, we unanchor it, and then unref it.
>>
>> so i think the usb_submit_urb expected the urb not just be referenced,
>> but also anchored?
>
> It expects that in the sense that it reacts to anchorings, but they are
> not required.
>
>> or referenced, but the caller would unref it himself
>> later?
>
> The caller is responsible for its own references.
hmm, maybe unref it in the complete callback(btusb_tx_complete?), and if 
we do so, we may need to detect which urb came from here...
>
>> and for tx_anchor, we put urb in it, and kill them all during suspending
>> to prevent transfer. so i guess it would be safe to put deferred urb in
>> to it after resume too?
>> but i don't know much about usb/btusb, so i could be wrong all about that :)
>
> IIRC the reason for directly submitting them was the spinlock.
sorry, i'm not clear about this, could you help to explain more? do you 
mean txlock?

the current play_deferred is called under txlock locked, and 
submit_tx_urb not:

         spin_lock_irq(&data->txlock);
         play_deferred(data);
         clear_bit(BTUSB_SUSPENDING, &data->flags);
         spin_unlock_irq(&data->txlock);


         spin_unlock_irqrestore(&data->txlock, flags);

         if (!suspending)
                 return submit_tx_urb(hdev, urb);


>
> 	Regards
> 		Oliver
>
>
>
>

Re: [RFC PATCH] Bluetooth: btusb: Fix memory leak in play_deferred

[Oliver Neukum]

Am Mittwoch, den 12.07.2017, 10:27 +0800 schrieb jeffy:
> Hi Oliver,
> 
> Thanx for your comments, and sorry for reply late.
> 
> 
> > If you do that you have to change submit_tx_urb() to be called under a
> > spinlock.
> 
> sorry, why we need that? since submit_tx_urb is basically 
> usb_anchor_urb/usb_submit_urb/usb_free_urb

You need to fix the GFP_KERNEL therein.

> > > or referenced, but the caller would unref it himself
> > > later?
> > 
> > The caller is responsible for its own references.
> hmm, maybe unref it in the complete callback(btusb_tx_complete?), and if 
> we do so, we may need to detect which urb came from here...

I do not get your reasoning there. If an URB has executed, it belongs
onto the anchor for URBs to be used again. 

> > > and for tx_anchor, we put urb in it, and kill them all during suspending
> > > to prevent transfer. so i guess it would be safe to put deferred urb in
> > > to it after resume too?
> > > but i don't know much about usb/btusb, so i could be wrong all about that :)
> > 
> > IIRC the reason for directly submitting them was the spinlock.
> sorry, i'm not clear about this, could you help to explain more? do you 
> mean txlock?

Yes

	Regards
		Oliver

Re: [RFC PATCH] Bluetooth: btusb: Fix memory leak in play_deferred

[jeffy]

Hi Oliver,
Thanks for your reply.

On 07/17/2017 11:26 PM, Oliver Neukum wrote:
> Am Mittwoch, den 12.07.2017, 10:27 +0800 schrieb jeffy:
>> Hi Oliver,
>>
>> Thanx for your comments, and sorry for reply late.
>>
>>
>>> If you do that you have to change submit_tx_urb() to be called under a
>>> spinlock.
>>
>> sorry, why we need that? since submit_tx_urb is basically
>> usb_anchor_urb/usb_submit_urb/usb_free_urb
>
> You need to fix the GFP_KERNEL therein.
oh, i see the problem.
>
>>>> or referenced, but the caller would unref it himself
>>>> later?
>>>
>>> The caller is responsible for its own references.
>> hmm, maybe unref it in the complete callback(btusb_tx_complete?), and if
>> we do so, we may need to detect which urb came from here...
>
> I do not get your reasoning there. If an URB has executed, it belongs
> onto the anchor for URBs to be used again.
the urbs we submit here are referenced but unanchored, so i think we can:
1/ unreference it here and put it in tx_anchor, and let urb core to do 
the unachor(and unreference)
or
2/ we unreference it in the complete callback.

i'll send a new version for 2/
>
>>>> and for tx_anchor, we put urb in it, and kill them all during suspending
>>>> to prevent transfer. so i guess it would be safe to put deferred urb in
>>>> to it after resume too?
>>>> but i don't know much about usb/btusb, so i could be wrong all about that :)
>>>
>>> IIRC the reason for directly submitting them was the spinlock.
>> sorry, i'm not clear about this, could you help to explain more? do you
>> mean txlock?
>
> Yes
>
> 	Regards
> 		Oliver
>
>
>
>