| Message ID | 20240902054959.28073-1-00107082@163.com (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
| Series | PM: add: move warn message out of mutex lock. | expand |
On Mon, Sep 02, 2024 at 01:49:59PM +0800, David Wang wrote: > dpm_list_mtx does not protect any data used by > dev_warn for checking parent's power, move > dev_warn out of mutex lock block make the > lock more efficient, especially when the warn > is triggered. This can happen on some HW when > resume from suspend with USB camera opened: Please wrap changelog lines at 72 columns if possible. > >usb 3-1.1: reset high-speed USB device number 4 using xhci_hcd > >.. > >ep_81: PM: parent 3-1.1:1.1 should not be sleeping > > Signed-off-by: David Wang <00107082@163.com> > --- > drivers/base/power/main.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c > index 4a67e83300e1..934e5bb61f13 100644 > --- a/drivers/base/power/main.c > +++ b/drivers/base/power/main.c > @@ -134,10 +134,10 @@ void device_pm_add(struct device *dev) > pr_debug("Adding info for %s:%s\n", > dev->bus ? dev->bus->name : "No Bus", dev_name(dev)); > device_pm_check_callbacks(dev); > - mutex_lock(&dpm_list_mtx); > if (dev->parent && dev->parent->power.is_prepared) > dev_warn(dev, "parent %s should not be sleeping\n", > dev_name(dev->parent)); > + mutex_lock(&dpm_list_mtx); I do not understand how this change will remove the offending log message. It should be safe to hold the lock while the check happens and the message is printed out, you should not see any functional change at all. So are you sure this is needed? thanks, greg k-h
Hi, Thanks for reviewing~ At 2024-09-02 14:31:35, "Greg KH" <gregkh@linuxfoundation.org> wrote: >On Mon, Sep 02, 2024 at 01:49:59PM +0800, David Wang wrote: >> dpm_list_mtx does not protect any data used by >> dev_warn for checking parent's power, move >> dev_warn out of mutex lock block make the >> lock more efficient, especially when the warn >> is triggered. This can happen on some HW when >> resume from suspend with USB camera opened: > >Please wrap changelog lines at 72 columns if possible. > >> >usb 3-1.1: reset high-speed USB device number 4 using xhci_hcd >> >.. >> >ep_81: PM: parent 3-1.1:1.1 should not be sleeping >> >> Signed-off-by: David Wang <00107082@163.com> >> --- >> drivers/base/power/main.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c >> index 4a67e83300e1..934e5bb61f13 100644 >> --- a/drivers/base/power/main.c >> +++ b/drivers/base/power/main.c >> @@ -134,10 +134,10 @@ void device_pm_add(struct device *dev) >> pr_debug("Adding info for %s:%s\n", >> dev->bus ? dev->bus->name : "No Bus", dev_name(dev)); >> device_pm_check_callbacks(dev); >> - mutex_lock(&dpm_list_mtx); >> if (dev->parent && dev->parent->power.is_prepared) >> dev_warn(dev, "parent %s should not be sleeping\n", >> dev_name(dev->parent)); >> + mutex_lock(&dpm_list_mtx); > >I do not understand how this change will remove the offending log >message. It should be safe to hold the lock while the check happens and >the message is printed out, you should not see any functional change at >all. > >So are you sure this is needed? This patch does not fix anything, the warning is still there and indeed no functional change at all. It is more of a code refactor: when I follow the kernel warn on my system and check the code, I feel its better to move dev_warn out of the lock section since the lock is not meant to protect it, right? And I mention the warning message in the commit log because I think it would make the lock-holding unnecessarily longer when the warning do happen. > >thanks, > >greg k-h
On Mon, Sep 2, 2024 at 7:50 AM David Wang <00107082@163.com> wrote: > > dpm_list_mtx does not protect any data used by > dev_warn for checking parent's power, move > dev_warn out of mutex lock block make the > lock more efficient, especially when the warn > is triggered. It does protect the power.is_prepared flag of the parent.
On Tue, Sep 3, 2024 at 3:01 PM Rafael J. Wysocki <rafael@kernel.org> wrote: > > On Mon, Sep 2, 2024 at 7:50 AM David Wang <00107082@163.com> wrote: > > > > dpm_list_mtx does not protect any data used by > > dev_warn for checking parent's power, move > > dev_warn out of mutex lock block make the > > lock more efficient, especially when the warn > > is triggered. > > It does protect the power.is_prepared flag of the parent. In fact, the update of it in device_resume() is racy with respect to the check in device_pm_add(), but the purpose of it is mostly to allow the device driver's resume callback to add children without triggering the warning.
Hi, At 2024-09-03 22:10:16, "Rafael J. Wysocki" <rafael@kernel.org> wrote: >On Tue, Sep 3, 2024 at 3:01 PM Rafael J. Wysocki <rafael@kernel.org> wrote: >> >> On Mon, Sep 2, 2024 at 7:50 AM David Wang <00107082@163.com> wrote: >> > >> > dpm_list_mtx does not protect any data used by >> > dev_warn for checking parent's power, move >> > dev_warn out of mutex lock block make the >> > lock more efficient, especially when the warn >> > is triggered. >> >> It does protect the power.is_prepared flag of the parent. > >In fact, the update of it in device_resume() is racy with respect to >the check in device_pm_add(), but the purpose of it is mostly to allow >the device driver's resume callback to add children without triggering >the warning. Kind of confused by this... if dpm_list_mtx could protect power.is_prepared, then codes that change power.is_prepared should also hold this lock, but normally they only use device_lock(dev); David
On Tue, Sep 3, 2024 at 6:16 PM David Wang <00107082@163.com> wrote: > > Hi, > > At 2024-09-03 22:10:16, "Rafael J. Wysocki" <rafael@kernel.org> wrote: > >On Tue, Sep 3, 2024 at 3:01 PM Rafael J. Wysocki <rafael@kernel.org> wrote: > >> > >> On Mon, Sep 2, 2024 at 7:50 AM David Wang <00107082@163.com> wrote: > >> > > >> > dpm_list_mtx does not protect any data used by > >> > dev_warn for checking parent's power, move > >> > dev_warn out of mutex lock block make the > >> > lock more efficient, especially when the warn > >> > is triggered. > >> > >> It does protect the power.is_prepared flag of the parent. > > > >In fact, the update of it in device_resume() is racy with respect to > >the check in device_pm_add(), but the purpose of it is mostly to allow > >the device driver's resume callback to add children without triggering > >the warning. > > > Kind of confused by this... if dpm_list_mtx could protect power.is_prepared, > then codes that change power.is_prepared should also hold this lock, but normally > they only use device_lock(dev); It is confusing, sorry about that. The bottom line though is that you want to get rid of the spurious warning in device_pm_add() AFAICS. To that end, can you please try the patch I sent in the other thread: https://lore.kernel.org/linux-pm/CAJZ5v0hMnnDjKJLMgcT_p1nnejyyAyaqaA_AF5t+_=PsSMfceQ@mail.gmail.com/
At 2024-09-04 00:23:57, "Rafael J. Wysocki" <rafael@kernel.org> wrote: >On Tue, Sep 3, 2024 at 6:16 PM David Wang <00107082@163.com> wrote: >> >> Hi, >> >> At 2024-09-03 22:10:16, "Rafael J. Wysocki" <rafael@kernel.org> wrote: >> >On Tue, Sep 3, 2024 at 3:01 PM Rafael J. Wysocki <rafael@kernel.org> wrote: >> >> >> >> On Mon, Sep 2, 2024 at 7:50 AM David Wang <00107082@163.com> wrote: >> >> > >> >> > dpm_list_mtx does not protect any data used by >> >> > dev_warn for checking parent's power, move >> >> > dev_warn out of mutex lock block make the >> >> > lock more efficient, especially when the warn >> >> > is triggered. >> >> >> >> It does protect the power.is_prepared flag of the parent. >> > >> >In fact, the update of it in device_resume() is racy with respect to >> >the check in device_pm_add(), but the purpose of it is mostly to allow >> >the device driver's resume callback to add children without triggering >> >the warning. >> >> >> Kind of confused by this... if dpm_list_mtx could protect power.is_prepared, >> then codes that change power.is_prepared should also hold this lock, but normally >> they only use device_lock(dev); > >It is confusing, sorry about that. > >The bottom line though is that you want to get rid of the spurious >warning in device_pm_add() AFAICS. > >To that end, can you please try the patch I sent in the other thread: > >https://lore.kernel.org/linux-pm/CAJZ5v0hMnnDjKJLMgcT_p1nnejyyAyaqaA_AF5t+_=PsSMfceQ@mail.gmail.com/ Sure, I will try it and update later. But this patch is just about code-refactor, not about the warn itself..... David
diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c index 4a67e83300e1..934e5bb61f13 100644 --- a/drivers/base/power/main.c +++ b/drivers/base/power/main.c @@ -134,10 +134,10 @@ void device_pm_add(struct device *dev) pr_debug("Adding info for %s:%s\n", dev->bus ? dev->bus->name : "No Bus", dev_name(dev)); device_pm_check_callbacks(dev); - mutex_lock(&dpm_list_mtx); if (dev->parent && dev->parent->power.is_prepared) dev_warn(dev, "parent %s should not be sleeping\n", dev_name(dev->parent)); + mutex_lock(&dpm_list_mtx); list_add_tail(&dev->power.entry, &dpm_list); dev->power.in_dpm_list = true; mutex_unlock(&dpm_list_mtx);