From: Felipe Balbi <balbi@kernel.org>
To: Johan Hovold <johan@kernel.org>
Cc: Roger Quadros <rogerq@ti.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Alan Stern <stern@rowland.harvard.edu>,
linux-usb@vger.kernel.org
Subject: usb: dwc3: of-simple: fix use-after-free on remove
Date: Mon, 18 Jun 2018 11:15:41 +0300 [thread overview]
Message-ID: <87h8m0zf0y.fsf@linux.intel.com> (raw)
Hi,
Johan Hovold <johan@kernel.org> writes:
> On Wed, Jun 13, 2018 at 12:39:18PM +0300, Felipe Balbi wrote:
>> Roger Quadros <rogerq@ti.com> writes:
>
>> > I'm still trying to get my head around this.
>> >
>> > in probe() we do
>> > {
>> > enable all clocks;
>> > pm_runtime_set_active(dev);
>> > pm_runtime_enable(dev);
>> > pm_runtime_get_sync(dev);
>> > }
>> >
>> > How will runtime suspend work at all?
>> > We're holding a positive RPM count in probe().
>>
>> echo auto > /path/to/dwc3/power/control
>
> That makes no difference, user space cannot modify the always-active
> behaviour given that probe returns with a positive usage count.
>
>> Granted, that get_sync() would've been better as a pm_runtime_forbid()
>
> Yeah, that would allow user space some control, albeit in a way that
> may override a user space configuration (as the platform device would
> already have been registered).
>
> Why are you trying to prevent runtime pm in the first place? Shouldn't
> the device be allowed to suspend when it has no active child by
> default?
I don't use this glue layer, actually. As long as there are no
regressions, you can change it to your heart's content. I still it's
best to start with pm runtime blocked and let userspace decide what and
when should have pm runtime enabled.
next reply other threads:[~2018-06-18 8:15 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-18 8:15 Felipe Balbi [this message]
-- strict thread matches above, loose matches on Subject: below --
2018-06-21 15:15 usb: dwc3: of-simple: fix use-after-free on remove Alan Stern
2018-06-21 10:11 Johan Hovold
2018-06-21 9:52 Johan Hovold
2018-06-21 8:27 Johan Hovold
2018-06-21 8:17 Roger Quadros
2018-06-20 22:55 Rafael J. Wysocki
2018-06-20 22:32 Rafael J. Wysocki
2018-06-20 15:46 Johan Hovold
2018-06-20 12:54 Rafael J. Wysocki
2018-06-20 12:23 Johan Hovold
2018-06-20 12:17 Rafael J. Wysocki
2018-06-20 11:05 Felipe Balbi
2018-06-20 9:54 Rafael J. Wysocki
2018-06-20 9:27 Felipe Balbi
2018-06-20 9:16 Tony Lindgren
2018-06-20 4:34 Tony Lindgren
2018-06-19 12:10 Tero Kristo
2018-06-19 8:18 Felipe Balbi
2018-06-18 14:32 Roger Quadros
2018-06-18 12:21 Felipe Balbi
2018-06-18 11:11 Roger Quadros
2018-06-18 9:51 Felipe Balbi
2018-06-18 9:47 Johan Hovold
2018-06-18 9:33 Felipe Balbi
2018-06-18 8:34 Johan Hovold
2018-06-13 10:59 Johan Hovold
2018-06-13 9:39 Felipe Balbi
2018-06-13 8:34 Roger Quadros
2018-06-13 8:05 Felipe Balbi
2018-06-13 7:49 Roger Quadros
2018-05-31 14:58 Johan Hovold
2018-05-31 14:45 Johan Hovold
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=87h8m0zf0y.fsf@linux.intel.com \
--to=balbi@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=johan@kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=rogerq@ti.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.