From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
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: Fri, 5 Dec 2014 16:37:16 -0800 [thread overview]
Message-ID: <20141206003716.GB3376@kroah.com> (raw)
In-Reply-To: <20141205231313.GA4854@linutronix.de>
On Sat, Dec 06, 2014 at 12:13:13AM +0100, Sebastian Andrzej Siewior wrote:
> * 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?
If you hot unplug the HCD and this is an issue, yes, that's something to
fix. If you can only trigger this by unloading a kernel module, no,
it's not a big issue at all. It's pretty trivial to cause kernel oopses
by unloading kernel modules if you know what you are doing.
> >> 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.
My point is this isn't needed for this patch.
greg k-h
next prev parent reply other threads:[~2014-12-06 0:37 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
2014-12-06 0:37 ` Greg Kroah-Hartman [this message]
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=20141206003716.GB3376@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=balbi@ti.com \
--cc=bigeasy@linutronix.de \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).