From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-usb@vger.kernel.org, linux-media@vger.kernel.org,
Alan Stern <stern@rowland.harvard.edu>,
Felipe Balbi <balbi@ti.com>,
Sarah Sharp <sarah.a.sharp@linux.intel.com>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Subject: Re: [PATCH] usb: hcd: get/put device and hcd for hcd_buffers()
Date: Sat, 6 Dec 2014 00:13:13 +0100 [thread overview]
Message-ID: <20141205231313.GA4854@linutronix.de> (raw)
In-Reply-To: <20141205211932.GA24249@kroah.com>
* Greg Kroah-Hartman | 2014-12-05 13:19:32 [-0800]:
>On Fri, Dec 05, 2014 at 09:03:57PM +0100, Sebastian Andrzej Siewior wrote:
>> Consider the following scenario:
>> - plugin a webcam
>> - play the stream via gst-launch-0.10 v4l2src device=/dev/video0…
>> - remove the USB-HCD during playback via "rmmod $HCD"
>>
>> and now wait for the crash
>
>Which you deserve, why did you ever remove a kernel module? That's racy
its been found by the testing team and looks legitimate.
>and _never_ recommended, which is why it never happens automatically and
>only root can do it.
I beg your pardon. So it is okay to remove the UVC-driver / plug the
cable and expect that things continue to work but removing the HCD is a
no no? I always assumed that kernel should BUG() no matter what the user
does unless he really begs for it. If there is a race then it is a bug
that deserves to be fixed, right?
>> diff --git a/drivers/usb/core/buffer.c b/drivers/usb/core/buffer.c
>> index 506b969ea7fd..01e080a61519 100644
>> --- a/drivers/usb/core/buffer.c
>> +++ b/drivers/usb/core/buffer.c
>> @@ -107,7 +107,7 @@ void hcd_buffer_destroy(struct usb_hcd *hcd)
>> * better sharing and to leverage mm/slab.c intelligence.
>> */
>>
>> -void *hcd_buffer_alloc(
>> +static void *_hcd_buffer_alloc(
>
>Looks like this isn't really needed here, right?
either this or I would have the tree callers if the allocation succeded
or not in order not to take a reference if the allocation failed.
>> struct usb_bus *bus,
>> size_t size,
>> gfp_t mem_flags,
>> @@ -131,7 +131,19 @@ void *hcd_buffer_alloc(
>> return dma_alloc_coherent(hcd->self.controller, size, dma, mem_flags);
>> }
>>
>> -void hcd_buffer_free(
>> +void *hcd_buffer_alloc(struct usb_bus *bus, size_t size, gfp_t mem_flags,
>> + dma_addr_t *dma)
>> +{
>> + struct usb_hcd *hcd = bus_to_hcd(bus);
>> + void *ret;
>> +
>> + ret = _hcd_buffer_alloc(bus, size, mem_flags, dma);
>> + if (ret)
>> + usb_get_hcd(hcd);
>
>I'm all for some good reference counting, but this is going to cause a
>_lot_ of churn on this reference count, what is the performance issue
>with doing this for every buffer?
The UVC allocates the buffers once and reuses them. If a driver does
any kind of high-performance transfers and allocates new buffers on each
transfer then I would expect this kref_get() is in the noise area. But
if you want real numbers I would have to go ahead and test it.
A single get() on first allocation and its counter part on cleanup would
be enough if you are too concerned about it on every allocation (it
would be transparent to the user).
>thanks,
>
>greg k-h
Sebastian
next prev parent reply other threads:[~2014-12-05 23:13 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-05 20:03 [PATCH] usb: hcd: get/put device and hcd for hcd_buffers() Sebastian Andrzej Siewior
2014-12-05 21:19 ` Greg Kroah-Hartman
2014-12-05 23:13 ` Sebastian Andrzej Siewior [this message]
2014-12-06 0:37 ` Greg Kroah-Hartman
2014-12-08 9:44 ` David Laight
2014-12-09 15:24 ` 'Greg Kroah-Hartman'
2014-12-09 16:01 ` Sebastian Andrzej Siewior
2014-12-09 16:54 ` 'Greg Kroah-Hartman'
2014-12-10 18:25 ` Sebastian Andrzej Siewior
2014-12-05 21:21 ` Alan Stern
2014-12-05 23:23 ` Sebastian Andrzej Siewior
2014-12-08 8:43 ` Sebastian Andrzej Siewior
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20141205231313.GA4854@linutronix.de \
--to=bigeasy@linutronix.de \
--cc=balbi@ti.com \
--cc=gregkh@linuxfoundation.org \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-media@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mchehab@osg.samsung.com \
--cc=sarah.a.sharp@linux.intel.com \
--cc=stern@rowland.harvard.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.