| Message ID | 6543936.FbWAdBN1tG@kreacher (mailing list archive) |
|---|---|
| Headers | show |
| Series | PM: runtime: Fixes related to device links management | expand |
On Friday, October 23, 2020 5:50:04 AM CEST chenxiang (M) wrote: > Hi Rafael, > > 在 2020/10/22 3:10, Rafael J. Wysocki 写道: > > Hi Greg & all, > > > > Commit d12544fb2aa9 ("PM: runtime: Remove link state checks in > > rpm_get/put_supplier()") merged recently introduced a weakness > > in the handling of device links in the runtime PM framework that > > may be confusing and even harmful. > > > > Namely, the checks removed by that commit prevented PM-runtime from > > getting or dropping references to the supplier device whose driver > > was going away via its links to consumers, which specifically allowed > > the pm_runtime_clean_up_links() called from __device_release_driver() > > to run without interfering with runtime suspend/resume of consumer > > devices (which still might happen even though the drivers had been > > unbound from them by that time). > > > > After the above commit, calling pm_runtime_clean_up_links() from > > __device_release_driver() makes a little sense and it may be interfering > > destructively with regular PM-runtime suspend/resume control flows, so > > it needs to be either fixed or dropped altogether. I prefer the latter, > > because among other things this removes an arbitrary difference in the > > handling of managed device links with respect to the stateless ones, > > so patch [2/3] is doing just that. > > > > However, in some rare cases pm_runtime_clean_up_links() may help to clean > > up leftover PM-runtime references, so if that function goes away, they > > need to be cleaned up elsewhere. That's why patch [1/3] modifies > > __device_link_del() to drop them upon device link removal (which also > > needs to be done for stateless device links and that's why I'm regarding > > this patch as a fix). > > > > Finally, to avoid pointless overhead related to suspending and resuming > > the target device for multiple times in a row in __device_release_driver(), > > it is better to resume it upfront before checking its links to consumers, > > which is done by patch [3/3]. > > > I have tested the patchset, and it solves my reported issue, so please > feel free to add : > Tested-by: Xiang Chen <chenxiang66@hisilicon.com> Thank you!
Hi Greg, On Wed, Oct 21, 2020 at 9:14 PM Rafael J. Wysocki <rjw@rjwysocki.net> wrote: > > Hi Greg & all, > > Commit d12544fb2aa9 ("PM: runtime: Remove link state checks in > rpm_get/put_supplier()") merged recently introduced a weakness > in the handling of device links in the runtime PM framework that > may be confusing and even harmful. > > Namely, the checks removed by that commit prevented PM-runtime from > getting or dropping references to the supplier device whose driver > was going away via its links to consumers, which specifically allowed > the pm_runtime_clean_up_links() called from __device_release_driver() > to run without interfering with runtime suspend/resume of consumer > devices (which still might happen even though the drivers had been > unbound from them by that time). > > After the above commit, calling pm_runtime_clean_up_links() from > __device_release_driver() makes a little sense and it may be interfering > destructively with regular PM-runtime suspend/resume control flows, so > it needs to be either fixed or dropped altogether. I prefer the latter, > because among other things this removes an arbitrary difference in the > handling of managed device links with respect to the stateless ones, > so patch [2/3] is doing just that. > > However, in some rare cases pm_runtime_clean_up_links() may help to clean > up leftover PM-runtime references, so if that function goes away, they > need to be cleaned up elsewhere. That's why patch [1/3] modifies > __device_link_del() to drop them upon device link removal (which also > needs to be done for stateless device links and that's why I'm regarding > this patch as a fix). > > Finally, to avoid pointless overhead related to suspending and resuming > the target device for multiple times in a row in __device_release_driver(), > it is better to resume it upfront before checking its links to consumers, > which is done by patch [3/3]. > > While this series touches the driver core, it really is mostly related to > runtime PM, so I can apply it if that's OK. Any concerns regarding this series? If not, I'd like to queue it up for -rc3, because the current behavior in there is quite confusing (or worse). Cheers!
On Wed, Oct 21, 2020 at 09:10:08PM +0200, Rafael J. Wysocki wrote: > Hi Greg & all, > > Commit d12544fb2aa9 ("PM: runtime: Remove link state checks in > rpm_get/put_supplier()") merged recently introduced a weakness > in the handling of device links in the runtime PM framework that > may be confusing and even harmful. > > Namely, the checks removed by that commit prevented PM-runtime from > getting or dropping references to the supplier device whose driver > was going away via its links to consumers, which specifically allowed > the pm_runtime_clean_up_links() called from __device_release_driver() > to run without interfering with runtime suspend/resume of consumer > devices (which still might happen even though the drivers had been > unbound from them by that time). > > After the above commit, calling pm_runtime_clean_up_links() from > __device_release_driver() makes a little sense and it may be interfering > destructively with regular PM-runtime suspend/resume control flows, so > it needs to be either fixed or dropped altogether. I prefer the latter, > because among other things this removes an arbitrary difference in the > handling of managed device links with respect to the stateless ones, > so patch [2/3] is doing just that. > > However, in some rare cases pm_runtime_clean_up_links() may help to clean > up leftover PM-runtime references, so if that function goes away, they > need to be cleaned up elsewhere. That's why patch [1/3] modifies > __device_link_del() to drop them upon device link removal (which also > needs to be done for stateless device links and that's why I'm regarding > this patch as a fix). > > Finally, to avoid pointless overhead related to suspending and resuming > the target device for multiple times in a row in __device_release_driver(), > it is better to resume it upfront before checking its links to consumers, > which is done by patch [3/3]. > > While this series touches the driver core, it really is mostly related to > runtime PM, so I can apply it if that's OK. Please do, sorry for the delay in reviewing them: Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hi Greg & all, Commit d12544fb2aa9 ("PM: runtime: Remove link state checks in rpm_get/put_supplier()") merged recently introduced a weakness in the handling of device links in the runtime PM framework that may be confusing and even harmful. Namely, the checks removed by that commit prevented PM-runtime from getting or dropping references to the supplier device whose driver was going away via its links to consumers, which specifically allowed the pm_runtime_clean_up_links() called from __device_release_driver() to run without interfering with runtime suspend/resume of consumer devices (which still might happen even though the drivers had been unbound from them by that time). After the above commit, calling pm_runtime_clean_up_links() from __device_release_driver() makes a little sense and it may be interfering destructively with regular PM-runtime suspend/resume control flows, so it needs to be either fixed or dropped altogether. I prefer the latter, because among other things this removes an arbitrary difference in the handling of managed device links with respect to the stateless ones, so patch [2/3] is doing just that. However, in some rare cases pm_runtime_clean_up_links() may help to clean up leftover PM-runtime references, so if that function goes away, they need to be cleaned up elsewhere. That's why patch [1/3] modifies __device_link_del() to drop them upon device link removal (which also needs to be done for stateless device links and that's why I'm regarding this patch as a fix). Finally, to avoid pointless overhead related to suspending and resuming the target device for multiple times in a row in __device_release_driver(), it is better to resume it upfront before checking its links to consumers, which is done by patch [3/3]. While this series touches the driver core, it really is mostly related to runtime PM, so I can apply it if that's OK. Thanks!