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

Hi Oliver, On 07/18/2017 08:29 PM, Oliver Neukum wrote: Am Dienstag, den 18.07.2017, 17:56 +0800 schrieb jeffy: Hi Oliver, I think that as soon as one URB fails, you should not even try to submit any other deferred URBs. You are taking one out from the middle of a sequence. That cannot be

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

Hi Oliver, On 07/18/2017 08:29 PM, Oliver Neukum wrote: Am Dienstag, den 18.07.2017, 17:56 +0800 schrieb jeffy: Hi Oliver, I think that as soon as one URB fails, you should not even try to submit any other deferred URBs. You are taking one out from the middle of a sequence. That cannot be

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

Am Dienstag, den 18.07.2017, 17:56 +0800 schrieb jeffy: > Hi Oliver, > > > I think that as soon as one URB fails, you should not even try > > to submit any other deferred URBs. You are taking one out from > > the middle of a sequence. That cannot be right. > ok, that make sense. > > new patch

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

Am Dienstag, den 18.07.2017, 17:56 +0800 schrieb jeffy: > Hi Oliver, > > > I think that as soon as one URB fails, you should not even try > > to submit any other deferred URBs. You are taking one out from > > the middle of a sequence. That cannot be right. > ok, that make sense. > > new patch

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

Hi Oliver, On 07/18/2017 05:41 PM, Oliver Neukum wrote: Am Dienstag, den 18.07.2017, 17:36 +0800 schrieb jeffy: Hi Oliver, On 07/18/2017 04:41 PM, Oliver Neukum wrote: Am Dienstag, den 18.07.2017, 16:08 +0800 schrieb jeffy: I am afraid not. We cannot silently drop one part of a

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

Hi Oliver, On 07/18/2017 05:41 PM, Oliver Neukum wrote: Am Dienstag, den 18.07.2017, 17:36 +0800 schrieb jeffy: Hi Oliver, On 07/18/2017 04:41 PM, Oliver Neukum wrote: Am Dienstag, den 18.07.2017, 16:08 +0800 schrieb jeffy: I am afraid not. We cannot silently drop one part of a

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

Am Dienstag, den 18.07.2017, 17:36 +0800 schrieb jeffy: > Hi Oliver, > > On 07/18/2017 04:41 PM, Oliver Neukum wrote: > > > > Am Dienstag, den 18.07.2017, 16:08 +0800 schrieb jeffy: > > > > > > > > > > > I am afraid not. We cannot silently drop one part of a transmission. > > > > I am afraid

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

Am Dienstag, den 18.07.2017, 17:36 +0800 schrieb jeffy: > Hi Oliver, > > On 07/18/2017 04:41 PM, Oliver Neukum wrote: > > > > Am Dienstag, den 18.07.2017, 16:08 +0800 schrieb jeffy: > > > > > > > > > > > I am afraid not. We cannot silently drop one part of a transmission. > > > > I am afraid

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

Hi Oliver, On 07/18/2017 04:41 PM, Oliver Neukum wrote: Am Dienstag, den 18.07.2017, 16:08 +0800 schrieb jeffy: I am afraid not. We cannot silently drop one part of a transmission. I am afraid that the correct algorithm, if we encounter an error at that stage, is to abort the operation and

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

Hi Oliver, On 07/18/2017 04:41 PM, Oliver Neukum wrote: Am Dienstag, den 18.07.2017, 16:08 +0800 schrieb jeffy: I am afraid not. We cannot silently drop one part of a transmission. I am afraid that the correct algorithm, if we encounter an error at that stage, is to abort the operation and

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

Am Dienstag, den 18.07.2017, 16:08 +0800 schrieb jeffy: > > I am afraid not. We cannot silently drop one part of a transmission. > > I am afraid that the correct algorithm, if we encounter an error at > > that stage, is to abort the operation and report an error. > > > so i should break the loop

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

Am Dienstag, den 18.07.2017, 16:08 +0800 schrieb jeffy: > > I am afraid not. We cannot silently drop one part of a transmission. > > I am afraid that the correct algorithm, if we encounter an error at > > that stage, is to abort the operation and report an error. > > > so i should break the loop

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

Hi Oliver, On 07/18/2017 03:30 PM, Oliver Neukum wrote: Am Dienstag, den 18.07.2017, 08:44 +0200 schrieb Marcel Holtmann: diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c index 0d533b2..a22a08b 100644 --- a/drivers/bluetooth/btusb.c +++ b/drivers/bluetooth/btusb.c @@ -3260,19

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

Hi Oliver, On 07/18/2017 03:30 PM, Oliver Neukum wrote: Am Dienstag, den 18.07.2017, 08:44 +0200 schrieb Marcel Holtmann: diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c index 0d533b2..a22a08b 100644 --- a/drivers/bluetooth/btusb.c +++ b/drivers/bluetooth/btusb.c @@ -3260,19

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

Am Dienstag, den 18.07.2017, 08:44 +0200 schrieb Marcel Holtmann: > > diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c > > index 0d533b2..a22a08b 100644 > > --- a/drivers/bluetooth/btusb.c > > +++ b/drivers/bluetooth/btusb.c > > @@ -3260,19 +3260,33 @@ static int

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

Am Dienstag, den 18.07.2017, 08:44 +0200 schrieb Marcel Holtmann: > > diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c > > index 0d533b2..a22a08b 100644 > > --- a/drivers/bluetooth/btusb.c > > +++ b/drivers/bluetooth/btusb.c > > @@ -3260,19 +3260,33 @@ static int

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

Hi Oliver, > Currently we are calling usb_submit_urb directly to submit deferred tx > urbs after unanchor them. > > So the usb_giveback_urb_bh would failed to unref it in usb_unanchor_urb > and cause memory leak: > unreferenced object 0xffc0ce0fa400 (size 256): > ... > backtrace: >[]

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

Hi Oliver, > Currently we are calling usb_submit_urb directly to submit deferred tx > urbs after unanchor them. > > So the usb_giveback_urb_bh would failed to unref it in usb_unanchor_urb > and cause memory leak: > unreferenced object 0xffc0ce0fa400 (size 256): > ... > backtrace: >[]

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

Currently we are calling usb_submit_urb directly to submit deferred tx urbs after unanchor them. So the usb_giveback_urb_bh would failed to unref it in usb_unanchor_urb and cause memory leak: unreferenced object 0xffc0ce0fa400 (size 256): ... backtrace: [] __save_stack_trace+0x48/0x6c

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

Currently we are calling usb_submit_urb directly to submit deferred tx urbs after unanchor them. So the usb_giveback_urb_bh would failed to unref it in usb_unanchor_urb and cause memory leak: unreferenced object 0xffc0ce0fa400 (size 256): ... backtrace: [] __save_stack_trace+0x48/0x6c

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

Currently we are calling usb_submit_urb directly to submit deferred tx urbs after unanchor them. So the usb_giveback_urb_bh would failed to unref it in usb_unanchor_urb and cause memory leak: unreferenced object 0xffc0ce0fa400 (size 256): ... backtrace: [] __save_stack_trace+0x48/0x6c

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

Currently we are calling usb_submit_urb directly to submit deferred tx urbs after unanchor them. So the usb_giveback_urb_bh would failed to unref it in usb_unanchor_urb and cause memory leak: unreferenced object 0xffc0ce0fa400 (size 256): ... backtrace: [] __save_stack_trace+0x48/0x6c