Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1689173

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

Show all headers | View raw

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

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: [RFC PATCH] Bluetooth: btusb: Fix memory leak in play_deferred jeffy <jeffy.chen@rock-chips.com> - 2017-07-12 04:30 +0200
  Re: [RFC PATCH] Bluetooth: btusb: Fix memory leak in play_deferred Oliver Neukum <oneukum@suse.com> - 2017-07-17 17:30 +0200
    Re: [RFC PATCH] Bluetooth: btusb: Fix memory leak in play_deferred jeffy <jeffy.chen@rock-chips.com> - 2017-07-18 04:20 +0200

csiph-web