* [PATCH 3/3] Thermal: do thermal zone update after a cooling device registered
@ 2015-09-27 5:48 Chen Yu
2015-09-28 14:29 ` Javi Merino
0 siblings, 1 reply; 21+ messages in thread
From: Chen Yu @ 2015-09-27 5:48 UTC (permalink / raw)
To: linux-pm, edubezval, javi.merino; +Cc: rui.zhang, linux-kernel, stable
From: Zhang Rui <rui.zhang@intel.com>
When a new cooling device is registered, we need to update the
thermal zone to set the new registered cooling device to a proper
state.
This fixes a problem that the system is cool, while the fan devices
are left running on full speed after boot, if fan device is registered
after thermal zone device.
CC: <stable@vger.kernel.org> #3.18+
Reference:https://bugzilla.kernel.org/show_bug.cgi?id=92431
Tested-by: Manuel Krause <manuelkrause@netscape.net>
Tested-by: szegad <szegadlo@poczta.onet.pl>
Tested-by: prash <prash.n.rao@gmail.com>
Tested-by: amish <ammdispose-arch@yahoo.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Chen Yu <yu.c.chen@intel.com>
---
drivers/thermal/thermal_core.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index c3bdb48..09c78a4 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -1450,6 +1450,7 @@ __thermal_cooling_device_register(struct device_node *np,
const struct thermal_cooling_device_ops *ops)
{
struct thermal_cooling_device *cdev;
+ struct thermal_instance *pos, *next;
int result;
if (type && strlen(type) >= THERMAL_NAME_LENGTH)
@@ -1494,6 +1495,15 @@ __thermal_cooling_device_register(struct device_node *np,
/* Update binding information for 'this' new cdev */
bind_cdev(cdev);
+ list_for_each_entry_safe(pos, next, &cdev->thermal_instances, cdev_node) {
+ if (next->cdev_node.next == &cdev->thermal_instances) {
+ thermal_zone_device_update(next->tz);
+ break;
+ }
+ if (pos->tz != next->tz)
+ thermal_zone_device_update(pos->tz);
+ }
+
return cdev;
}
--
1.8.4.2
^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: [PATCH 3/3] Thermal: do thermal zone update after a cooling device registered
2015-09-27 5:48 [PATCH 3/3] Thermal: do thermal zone update after a cooling device registered Chen Yu
@ 2015-09-28 14:29 ` Javi Merino
2015-09-28 17:52 ` Chen, Yu C
0 siblings, 1 reply; 21+ messages in thread
From: Javi Merino @ 2015-09-28 14:29 UTC (permalink / raw)
To: Chen Yu; +Cc: linux-pm, edubezval, rui.zhang, linux-kernel, stable
On Sun, Sep 27, 2015 at 06:48:44AM +0100, Chen Yu wrote:
> From: Zhang Rui <rui.zhang@intel.com>
>
> When a new cooling device is registered, we need to update the
> thermal zone to set the new registered cooling device to a proper
> state.
>
> This fixes a problem that the system is cool, while the fan devices
> are left running on full speed after boot, if fan device is registered
> after thermal zone device.
>
> CC: <stable@vger.kernel.org> #3.18+
> Reference:https://bugzilla.kernel.org/show_bug.cgi?id=92431
> Tested-by: Manuel Krause <manuelkrause@netscape.net>
> Tested-by: szegad <szegadlo@poczta.onet.pl>
> Tested-by: prash <prash.n.rao@gmail.com>
> Tested-by: amish <ammdispose-arch@yahoo.com>
> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
> Signed-off-by: Chen Yu <yu.c.chen@intel.com>
> ---
> drivers/thermal/thermal_core.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
> index c3bdb48..09c78a4 100644
> --- a/drivers/thermal/thermal_core.c
> +++ b/drivers/thermal/thermal_core.c
> @@ -1450,6 +1450,7 @@ __thermal_cooling_device_register(struct device_node *np,
> const struct thermal_cooling_device_ops *ops)
> {
> struct thermal_cooling_device *cdev;
> + struct thermal_instance *pos, *next;
> int result;
>
> if (type && strlen(type) >= THERMAL_NAME_LENGTH)
> @@ -1494,6 +1495,15 @@ __thermal_cooling_device_register(struct device_node *np,
> /* Update binding information for 'this' new cdev */
> bind_cdev(cdev);
>
I think you need to hold cdev->lock here, to make sure that no thermal
zone is added or removed from cdev->thermal_instances while you are looping.
> + list_for_each_entry_safe(pos, next, &cdev->thermal_instances, cdev_node) {
Why list_for_each_entry_safe() ? You are not going to remove any
entry, so you can just use list_for_each_entry()
> + if (next->cdev_node.next == &cdev->thermal_instances) {
> + thermal_zone_device_update(next->tz);
> + break;
> + }
> + if (pos->tz != next->tz)
> + thermal_zone_device_update(pos->tz);
> + }
Why is this so complicated? Can't you just do:
list_for_each_entry(pos, &cdev->thermal_instances, cdev_node)
thermal_zone_device_update(pos->tz);
Cheers,
Javi
^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: [PATCH 3/3] Thermal: do thermal zone update after a cooling device registered
2015-09-28 14:29 ` Javi Merino
@ 2015-09-28 17:52 ` Chen, Yu C
0 siblings, 0 replies; 21+ messages in thread
From: Chen, Yu C @ 2015-09-28 17:52 UTC (permalink / raw)
To: Javi Merino; +Cc: linux-pm, edubezval, Zhang, Rui, linux-kernel, stable
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1471 bytes --]
Hi, Javi,
> -----Original Message-----
> From: Javi Merino [mailto:javi.merino@arm.com]
> Sent: Monday, September 28, 2015 10:29 PM
> To: Chen, Yu C
> Cc: linux-pm@vger.kernel.org; edubezval@gmail.com; Zhang, Rui; linux-
> kernel@vger.kernel.org; stable@vger.kernel.org
> Subject: Re: [PATCH 3/3] Thermal: do thermal zone update after a cooling
> device registered
>
> On Sun, Sep 27, 2015 at 06:48:44AM +0100, Chen Yu wrote:
> > From: Zhang Rui <rui.zhang@intel.com>
> >
> >
>
> I think you need to hold cdev->lock here, to make sure that no thermal zone
> is added or removed from cdev->thermal_instances while you are looping.
>
Ah right, will add. If I add the cdev ->lock here, will there be a AB-BA lock with
thermal_zone_unbind_cooling_device?
>
> Why list_for_each_entry_safe() ? You are not going to remove any entry, so
> you can just use list_for_each_entry()
>
>
> Why is this so complicated? Can't you just do:
>
> list_for_each_entry(pos, &cdev->thermal_instances, cdev_node)
> thermal_zone_device_update(pos->tz);
>
This is an optimization here:
Ignore thermal instance that refers to the same thermal zone in this loop,
this works because bind_cdev() always binds the cooling device to one
thermal zone first, and then binds to the next thermal zone.
Best Regards,
Yu
ÿôèº{.nÇ+·®+%Ëÿ±éݶ\x17¥wÿº{.nÇ+·¥{±þG«éÿ{ayº\x1dÊÚë,j\a¢f£¢·hïêÿêçz_è®\x03(éÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?¨èÚ&£ø§~á¶iOæ¬z·vØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?I¥
^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: [PATCH 3/3] Thermal: do thermal zone update after a cooling device registered
@ 2015-09-28 17:52 ` Chen, Yu C
0 siblings, 0 replies; 21+ messages in thread
From: Chen, Yu C @ 2015-09-28 17:52 UTC (permalink / raw)
To: Javi Merino; +Cc: linux-pm, edubezval, Zhang, Rui, linux-kernel, stable
Hi, Javi,
> -----Original Message-----
> From: Javi Merino [mailto:javi.merino@arm.com]
> Sent: Monday, September 28, 2015 10:29 PM
> To: Chen, Yu C
> Cc: linux-pm@vger.kernel.org; edubezval@gmail.com; Zhang, Rui; linux-
> kernel@vger.kernel.org; stable@vger.kernel.org
> Subject: Re: [PATCH 3/3] Thermal: do thermal zone update after a cooling
> device registered
>
> On Sun, Sep 27, 2015 at 06:48:44AM +0100, Chen Yu wrote:
> > From: Zhang Rui <rui.zhang@intel.com>
> >
> >
>
> I think you need to hold cdev->lock here, to make sure that no thermal zone
> is added or removed from cdev->thermal_instances while you are looping.
>
Ah right, will add. If I add the cdev ->lock here, will there be a AB-BA lock with
thermal_zone_unbind_cooling_device?
>
> Why list_for_each_entry_safe() ? You are not going to remove any entry, so
> you can just use list_for_each_entry()
>
>
> Why is this so complicated? Can't you just do:
>
> list_for_each_entry(pos, &cdev->thermal_instances, cdev_node)
> thermal_zone_device_update(pos->tz);
>
This is an optimization here:
Ignore thermal instance that refers to the same thermal zone in this loop,
this works because bind_cdev() always binds the cooling device to one
thermal zone first, and then binds to the next thermal zone.
Best Regards,
Yu
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH 3/3] Thermal: do thermal zone update after a cooling device registered
2015-09-28 17:52 ` Chen, Yu C
(?)
@ 2015-09-29 16:01 ` Javi Merino
2015-10-12 9:23 ` Chen, Yu C
-1 siblings, 1 reply; 21+ messages in thread
From: Javi Merino @ 2015-09-29 16:01 UTC (permalink / raw)
To: Chen, Yu C; +Cc: linux-pm, edubezval, Zhang, Rui, linux-kernel, stable
Hi Yu,
On Mon, Sep 28, 2015 at 06:52:00PM +0100, Chen, Yu C wrote:
> Hi, Javi,
>
> > -----Original Message-----
> > From: Javi Merino [mailto:javi.merino@arm.com]
> > Sent: Monday, September 28, 2015 10:29 PM
> > To: Chen, Yu C
> > Cc: linux-pm@vger.kernel.org; edubezval@gmail.com; Zhang, Rui; linux-
> > kernel@vger.kernel.org; stable@vger.kernel.org
> > Subject: Re: [PATCH 3/3] Thermal: do thermal zone update after a cooling
> > device registered
> >
> > On Sun, Sep 27, 2015 at 06:48:44AM +0100, Chen Yu wrote:
> > > From: Zhang Rui <rui.zhang@intel.com>
> > >
> > >
> >
> > I think you need to hold cdev->lock here, to make sure that no thermal zone
> > is added or removed from cdev->thermal_instances while you are looping.
> >
> Ah right, will add. If I add the cdev ->lock here, will there be a AB-BA lock with
> thermal_zone_unbind_cooling_device?
You're right, it could lead to a deadlock. The locks can't be
swapped because that won't work in step_wise.
The best way that I can think of accessing thermal_instances
atomically is by making it RCU protected instead of with mutexes.
What do you think?
> > Why list_for_each_entry_safe() ? You are not going to remove any entry, so
> > you can just use list_for_each_entry()
> >
> >
> > Why is this so complicated? Can't you just do:
> >
> > list_for_each_entry(pos, &cdev->thermal_instances, cdev_node)
> > thermal_zone_device_update(pos->tz);
> >
>
> This is an optimization here:
> Ignore thermal instance that refers to the same thermal zone in this loop,
> this works because bind_cdev() always binds the cooling device to one
> thermal zone first, and then binds to the next thermal zone.
It has taken me a while to understand this optimization. Please
document both "if"s in the code. For the first "if" maybe you can use
list_is_last() to make it easier to understand that you're looking for
the last element in the list:
if (list_is_last(&pos->cdev_node, &cdev->thermal_instances)) {
thermal_zone_device_update(pos->tz);
For the second "if" you can say that you only need to run
thermal_zone_device_update() once per thermal zone, even though
multiple thermal instances may refer to the same thermal zone.
Cheers,
Javi
^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: [PATCH 3/3] Thermal: do thermal zone update after a cooling device registered
2015-09-29 16:01 ` Javi Merino
@ 2015-10-12 9:23 ` Chen, Yu C
0 siblings, 0 replies; 21+ messages in thread
From: Chen, Yu C @ 2015-10-12 9:23 UTC (permalink / raw)
To: Javi Merino
Cc: linux-pm, edubezval, Zhang, Rui, linux-kernel, stable,
Pandruvada, Srinivas
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 3236 bytes --]
Hi, Javi
Sorry for my late response,
> -----Original Message-----
> From: Javi Merino [mailto:javi.merino@arm.com]
> Sent: Wednesday, September 30, 2015 12:02 AM
> To: Chen, Yu C
> Cc: linux-pm@vger.kernel.org; edubezval@gmail.com; Zhang, Rui; linux-
> kernel@vger.kernel.org; stable@vger.kernel.org
> Subject: Re: [PATCH 3/3] Thermal: do thermal zone update after a cooling
> device registered
>
> Hi Yu,
>
> On Mon, Sep 28, 2015 at 06:52:00PM +0100, Chen, Yu C wrote:
> > Hi, Javi,
> >
> > > -----Original Message-----
> > > From: Javi Merino [mailto:javi.merino@arm.com]
> > > Sent: Monday, September 28, 2015 10:29 PM
> > > To: Chen, Yu C
> > > Cc: linux-pm@vger.kernel.org; edubezval@gmail.com; Zhang, Rui;
> > > linux- kernel@vger.kernel.org; stable@vger.kernel.org
> > > Subject: Re: [PATCH 3/3] Thermal: do thermal zone update after a
> > > cooling device registered
> > >
> > > On Sun, Sep 27, 2015 at 06:48:44AM +0100, Chen Yu wrote:
> > > > From: Zhang Rui <rui.zhang@intel.com>
> > > >
> > > >
> > >
> > > I think you need to hold cdev->lock here, to make sure that no
> > > thermal zone is added or removed from cdev->thermal_instances while
> you are looping.
> > >
> > Ah right, will add. If I add the cdev ->lock here, will there be a
> > AB-BA lock with thermal_zone_unbind_cooling_device?
>
> You're right, it could lead to a deadlock. The locks can't be swapped because
> that won't work in step_wise.
>
> The best way that I can think of accessing thermal_instances atomically is by
> making it RCU protected instead of with mutexes.
> What do you think?
>
RCU would need extra spinlocks to protect the list, and need to sync_rcu after we delete
one instance from thermal_instance list, I think it is too complicated for me to rewrite: (
How about using thermal_list_lock instead of cdev ->lock?
This guy should be big enough to protect the device.thermal_instance list.
>
> > > Why list_for_each_entry_safe() ? You are not going to remove any
> > > entry, so you can just use list_for_each_entry()
> > >
> > >
> > > Why is this so complicated? Can't you just do:
> > >
> > > list_for_each_entry(pos, &cdev->thermal_instances, cdev_node)
> > > thermal_zone_device_update(pos->tz);
> > >
> >
> > This is an optimization here:
> > Ignore thermal instance that refers to the same thermal zone in this
> > loop, this works because bind_cdev() always binds the cooling device
> > to one thermal zone first, and then binds to the next thermal zone.
>
> It has taken me a while to understand this optimization. Please document
> both "if"s in the code. For the first "if" maybe you can use
> list_is_last() to make it easier to understand that you're looking for the last
> element in the list:
>
> if (list_is_last(&pos->cdev_node, &cdev-
> >thermal_instances)) {
> thermal_zone_device_update(pos->tz);
>
Sure, ok
> For the second "if" you can say that you only need to run
> thermal_zone_device_update() once per thermal zone, even though
> multiple thermal instances may refer to the same thermal zone.
>
OK
Best Regards,
Yu
ÿôèº{.nÇ+·®+%Ëÿ±éݶ\x17¥wÿº{.nÇ+·¥{±þG«éÿ{ayº\x1dÊÚë,j\a¢f£¢·hïêÿêçz_è®\x03(éÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?¨èÚ&£ø§~á¶iOæ¬z·vØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?I¥
^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: [PATCH 3/3] Thermal: do thermal zone update after a cooling device registered
@ 2015-10-12 9:23 ` Chen, Yu C
0 siblings, 0 replies; 21+ messages in thread
From: Chen, Yu C @ 2015-10-12 9:23 UTC (permalink / raw)
To: Javi Merino
Cc: linux-pm, edubezval, Zhang, Rui, linux-kernel, stable,
Pandruvada, Srinivas
Hi, Javi
Sorry for my late response,
> -----Original Message-----
> From: Javi Merino [mailto:javi.merino@arm.com]
> Sent: Wednesday, September 30, 2015 12:02 AM
> To: Chen, Yu C
> Cc: linux-pm@vger.kernel.org; edubezval@gmail.com; Zhang, Rui; linux-
> kernel@vger.kernel.org; stable@vger.kernel.org
> Subject: Re: [PATCH 3/3] Thermal: do thermal zone update after a cooling
> device registered
>
> Hi Yu,
>
> On Mon, Sep 28, 2015 at 06:52:00PM +0100, Chen, Yu C wrote:
> > Hi, Javi,
> >
> > > -----Original Message-----
> > > From: Javi Merino [mailto:javi.merino@arm.com]
> > > Sent: Monday, September 28, 2015 10:29 PM
> > > To: Chen, Yu C
> > > Cc: linux-pm@vger.kernel.org; edubezval@gmail.com; Zhang, Rui;
> > > linux- kernel@vger.kernel.org; stable@vger.kernel.org
> > > Subject: Re: [PATCH 3/3] Thermal: do thermal zone update after a
> > > cooling device registered
> > >
> > > On Sun, Sep 27, 2015 at 06:48:44AM +0100, Chen Yu wrote:
> > > > From: Zhang Rui <rui.zhang@intel.com>
> > > >
> > > >
> > >
> > > I think you need to hold cdev->lock here, to make sure that no
> > > thermal zone is added or removed from cdev->thermal_instances while
> you are looping.
> > >
> > Ah right, will add. If I add the cdev ->lock here, will there be a
> > AB-BA lock with thermal_zone_unbind_cooling_device?
>
> You're right, it could lead to a deadlock. The locks can't be swapped because
> that won't work in step_wise.
>
> The best way that I can think of accessing thermal_instances atomically is by
> making it RCU protected instead of with mutexes.
> What do you think?
>
RCU would need extra spinlocks to protect the list, and need to sync_rcu after we delete
one instance from thermal_instance list, I think it is too complicated for me to rewrite: (
How about using thermal_list_lock instead of cdev ->lock?
This guy should be big enough to protect the device.thermal_instance list.
>
> > > Why list_for_each_entry_safe() ? You are not going to remove any
> > > entry, so you can just use list_for_each_entry()
> > >
> > >
> > > Why is this so complicated? Can't you just do:
> > >
> > > list_for_each_entry(pos, &cdev->thermal_instances, cdev_node)
> > > thermal_zone_device_update(pos->tz);
> > >
> >
> > This is an optimization here:
> > Ignore thermal instance that refers to the same thermal zone in this
> > loop, this works because bind_cdev() always binds the cooling device
> > to one thermal zone first, and then binds to the next thermal zone.
>
> It has taken me a while to understand this optimization. Please document
> both "if"s in the code. For the first "if" maybe you can use
> list_is_last() to make it easier to understand that you're looking for the last
> element in the list:
>
> if (list_is_last(&pos->cdev_node, &cdev-
> >thermal_instances)) {
> thermal_zone_device_update(pos->tz);
>
Sure, ok
> For the second "if" you can say that you only need to run
> thermal_zone_device_update() once per thermal zone, even though
> multiple thermal instances may refer to the same thermal zone.
>
OK
Best Regards,
Yu
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH 3/3] Thermal: do thermal zone update after a cooling device registered
2015-10-12 9:23 ` Chen, Yu C
(?)
@ 2015-10-14 17:07 ` Javi Merino
2015-10-14 19:21 ` Chen, Yu C
2015-10-14 19:23 ` Chen, Yu C
-1 siblings, 2 replies; 21+ messages in thread
From: Javi Merino @ 2015-10-14 17:07 UTC (permalink / raw)
To: Chen, Yu C
Cc: linux-pm, edubezval, Zhang, Rui, linux-kernel, stable,
Pandruvada, Srinivas
On Mon, Oct 12, 2015 at 09:23:28AM +0000, Chen, Yu C wrote:
> Hi, Javi
> Sorry for my late response,
>
> > -----Original Message-----
> > From: Javi Merino [mailto:javi.merino@arm.com]
> > Sent: Wednesday, September 30, 2015 12:02 AM
> > To: Chen, Yu C
> > Cc: linux-pm@vger.kernel.org; edubezval@gmail.com; Zhang, Rui; linux-
> > kernel@vger.kernel.org; stable@vger.kernel.org
> > Subject: Re: [PATCH 3/3] Thermal: do thermal zone update after a cooling
> > device registered
> >
> > Hi Yu,
> >
> > On Mon, Sep 28, 2015 at 06:52:00PM +0100, Chen, Yu C wrote:
> > > Hi, Javi,
> > >
> > > > -----Original Message-----
> > > > From: Javi Merino [mailto:javi.merino@arm.com]
> > > > Sent: Monday, September 28, 2015 10:29 PM
> > > > To: Chen, Yu C
> > > > Cc: linux-pm@vger.kernel.org; edubezval@gmail.com; Zhang, Rui;
> > > > linux- kernel@vger.kernel.org; stable@vger.kernel.org
> > > > Subject: Re: [PATCH 3/3] Thermal: do thermal zone update after a
> > > > cooling device registered
> > > >
> > > > On Sun, Sep 27, 2015 at 06:48:44AM +0100, Chen Yu wrote:
> > > > > From: Zhang Rui <rui.zhang@intel.com>
> > > > >
> > > > >
> > > >
> > > > I think you need to hold cdev->lock here, to make sure that no
> > > > thermal zone is added or removed from cdev->thermal_instances while
> > you are looping.
> > > >
> > > Ah right, will add. If I add the cdev ->lock here, will there be a
> > > AB-BA lock with thermal_zone_unbind_cooling_device?
> >
> > You're right, it could lead to a deadlock. The locks can't be swapped because
> > that won't work in step_wise.
> >
> > The best way that I can think of accessing thermal_instances atomically is by
> > making it RCU protected instead of with mutexes.
> > What do you think?
> >
> RCU would need extra spinlocks to protect the list, and need to sync_rcu after we delete
> one instance from thermal_instance list, I think it is too complicated for me to rewrite: (
> How about using thermal_list_lock instead of cdev ->lock?
> This guy should be big enough to protect the device.thermal_instance list.
thermal_list_lock protects thermal_tz_list and thermal_cdev_list, but
it doesn't protect the thermal_instances list. For example,
thermal_zone_bind_cooling_device() adds a cooling device to the
cdev->thermal_instances list without taking thermal_tz_list.
To sum up, you have to protect accessing the cdev->thermal_instances
list but with the current locking scheme, you would create an AB-BA
deadlock. As I see it you would have to change the locking scheme to
either RCU or add a new mutex that protects the
cdev->thermal_instances and tz->thermal_instances lists and change all
accesses to them to make sure they comply with the new locking scheme.
Is there a better way of solving this? Cheers,
Javi
^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: [PATCH 3/3] Thermal: do thermal zone update after a cooling device registered
2015-10-14 17:07 ` Javi Merino
@ 2015-10-14 19:21 ` Chen, Yu C
2015-10-14 19:23 ` Chen, Yu C
1 sibling, 0 replies; 21+ messages in thread
From: Chen, Yu C @ 2015-10-14 19:21 UTC (permalink / raw)
To: Javi Merino
Cc: linux-pm, edubezval, Zhang, Rui, linux-kernel, stable,
Pandruvada, Srinivas
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 3521 bytes --]
Hi Javi,
> -----Original Message-----
> From: Javi Merino [mailto:javi.merino@arm.com]
> Sent: Thursday, October 15, 2015 1:08 AM
> To: Chen, Yu C
> Cc: linux-pm@vger.kernel.org; edubezval@gmail.com; Zhang, Rui; linux-
> kernel@vger.kernel.org; stable@vger.kernel.org; Pandruvada, Srinivas
> Subject: Re: [PATCH 3/3] Thermal: do thermal zone update after a cooling
> device registered
>
> On Mon, Oct 12, 2015 at 09:23:28AM +0000, Chen, Yu C wrote:
> > Hi, Javi
> > Sorry for my late response,
> >
> > > -----Original Message-----
> > > From: Javi Merino [mailto:javi.merino@arm.com]
> > > Sent: Wednesday, September 30, 2015 12:02 AM
> > > To: Chen, Yu C
> > > Cc: linux-pm@vger.kernel.org; edubezval@gmail.com; Zhang, Rui;
> > > linux- kernel@vger.kernel.org; stable@vger.kernel.org
> > > Subject: Re: [PATCH 3/3] Thermal: do thermal zone update after a
> > > cooling device registered
> > >
> > > Hi Yu,
> > >
> > > On Mon, Sep 28, 2015 at 06:52:00PM +0100, Chen, Yu C wrote:
> > > > Hi, Javi,
> > > >
> > > > > -----Original Message-----
> > > > > From: Javi Merino [mailto:javi.merino@arm.com]
> > > > > Sent: Monday, September 28, 2015 10:29 PM
> > > > > To: Chen, Yu C
> > > > > Cc: linux-pm@vger.kernel.org; edubezval@gmail.com; Zhang, Rui;
> > > > > linux- kernel@vger.kernel.org; stable@vger.kernel.org
> > > > > Subject: Re: [PATCH 3/3] Thermal: do thermal zone update after a
> > > > > cooling device registered
> > > > >
> > > > > On Sun, Sep 27, 2015 at 06:48:44AM +0100, Chen Yu wrote:
> > > > > > From: Zhang Rui <rui.zhang@intel.com>
> > > > > >
> > > > > >
> > > > >
> > > > > I think you need to hold cdev->lock here, to make sure that no
> > > > > thermal zone is added or removed from cdev->thermal_instances
> > > > > while
> > > you are looping.
> > > > >
> > > > Ah right, will add. If I add the cdev ->lock here, will there be a
> > > > AB-BA lock with thermal_zone_unbind_cooling_device?
> > >
> > > You're right, it could lead to a deadlock. The locks can't be
> > > swapped because that won't work in step_wise.
> > >
> > > The best way that I can think of accessing thermal_instances
> > > atomically is by making it RCU protected instead of with mutexes.
> > > What do you think?
> > >
> > RCU would need extra spinlocks to protect the list, and need to
> > sync_rcu after we delete one instance from thermal_instance list, I
> > think it is too complicated for me to rewrite: ( How about using
> thermal_list_lock instead of cdev ->lock?
> > This guy should be big enough to protect the device.thermal_instance list.
>
> thermal_list_lock protects thermal_tz_list and thermal_cdev_list, but it
> doesn't protect the thermal_instances list. For example,
> thermal_zone_bind_cooling_device() adds a cooling device to the
> cdev->thermal_instances list without taking thermal_tz_list.
>
Before thermal_zone_bind_cooling_device is invoked,
the thermal_list_lock will be firstly gripped:
static void bind_cdev(struct thermal_cooling_device *cdev)
{
mutex_lock(&thermal_list_lock);
either tz->ops->bind : thermal_zone_bind_cooling_device
or __bind() : thermal_zone_bind_cooling_device
mutex_unlock(&thermal_list_lock);
}
And it is the same as in passive_store.
So when code is trying to add/delete thermal_instance of cdev, he has
already hold thermal_list_lock IMO. Or do I miss anything?
Best Regards,
Yu
ÿôèº{.nÇ+·®+%Ëÿ±éݶ\x17¥wÿº{.nÇ+·¥{±þG«éÿ{ayº\x1dÊÚë,j\a¢f£¢·hïêÿêçz_è®\x03(éÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?¨èÚ&£ø§~á¶iOæ¬z·vØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?I¥
^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: [PATCH 3/3] Thermal: do thermal zone update after a cooling device registered
@ 2015-10-14 19:21 ` Chen, Yu C
0 siblings, 0 replies; 21+ messages in thread
From: Chen, Yu C @ 2015-10-14 19:21 UTC (permalink / raw)
To: Javi Merino
Cc: linux-pm, edubezval, Zhang, Rui, linux-kernel, stable,
Pandruvada, Srinivas
Hi Javi,
> -----Original Message-----
> From: Javi Merino [mailto:javi.merino@arm.com]
> Sent: Thursday, October 15, 2015 1:08 AM
> To: Chen, Yu C
> Cc: linux-pm@vger.kernel.org; edubezval@gmail.com; Zhang, Rui; linux-
> kernel@vger.kernel.org; stable@vger.kernel.org; Pandruvada, Srinivas
> Subject: Re: [PATCH 3/3] Thermal: do thermal zone update after a cooling
> device registered
>
> On Mon, Oct 12, 2015 at 09:23:28AM +0000, Chen, Yu C wrote:
> > Hi, Javi
> > Sorry for my late response,
> >
> > > -----Original Message-----
> > > From: Javi Merino [mailto:javi.merino@arm.com]
> > > Sent: Wednesday, September 30, 2015 12:02 AM
> > > To: Chen, Yu C
> > > Cc: linux-pm@vger.kernel.org; edubezval@gmail.com; Zhang, Rui;
> > > linux- kernel@vger.kernel.org; stable@vger.kernel.org
> > > Subject: Re: [PATCH 3/3] Thermal: do thermal zone update after a
> > > cooling device registered
> > >
> > > Hi Yu,
> > >
> > > On Mon, Sep 28, 2015 at 06:52:00PM +0100, Chen, Yu C wrote:
> > > > Hi, Javi,
> > > >
> > > > > -----Original Message-----
> > > > > From: Javi Merino [mailto:javi.merino@arm.com]
> > > > > Sent: Monday, September 28, 2015 10:29 PM
> > > > > To: Chen, Yu C
> > > > > Cc: linux-pm@vger.kernel.org; edubezval@gmail.com; Zhang, Rui;
> > > > > linux- kernel@vger.kernel.org; stable@vger.kernel.org
> > > > > Subject: Re: [PATCH 3/3] Thermal: do thermal zone update after a
> > > > > cooling device registered
> > > > >
> > > > > On Sun, Sep 27, 2015 at 06:48:44AM +0100, Chen Yu wrote:
> > > > > > From: Zhang Rui <rui.zhang@intel.com>
> > > > > >
> > > > > >
> > > > >
> > > > > I think you need to hold cdev->lock here, to make sure that no
> > > > > thermal zone is added or removed from cdev->thermal_instances
> > > > > while
> > > you are looping.
> > > > >
> > > > Ah right, will add. If I add the cdev ->lock here, will there be a
> > > > AB-BA lock with thermal_zone_unbind_cooling_device?
> > >
> > > You're right, it could lead to a deadlock. The locks can't be
> > > swapped because that won't work in step_wise.
> > >
> > > The best way that I can think of accessing thermal_instances
> > > atomically is by making it RCU protected instead of with mutexes.
> > > What do you think?
> > >
> > RCU would need extra spinlocks to protect the list, and need to
> > sync_rcu after we delete one instance from thermal_instance list, I
> > think it is too complicated for me to rewrite: ( How about using
> thermal_list_lock instead of cdev ->lock?
> > This guy should be big enough to protect the device.thermal_instance list.
>
> thermal_list_lock protects thermal_tz_list and thermal_cdev_list, but it
> doesn't protect the thermal_instances list. For example,
> thermal_zone_bind_cooling_device() adds a cooling device to the
> cdev->thermal_instances list without taking thermal_tz_list.
>
Before thermal_zone_bind_cooling_device is invoked,
the thermal_list_lock will be firstly gripped:
static void bind_cdev(struct thermal_cooling_device *cdev)
{
mutex_lock(&thermal_list_lock);
either tz->ops->bind : thermal_zone_bind_cooling_device
or __bind() : thermal_zone_bind_cooling_device
mutex_unlock(&thermal_list_lock);
}
And it is the same as in passive_store.
So when code is trying to add/delete thermal_instance of cdev, he has
already hold thermal_list_lock IMO. Or do I miss anything?
Best Regards,
Yu
^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: [PATCH 3/3] Thermal: do thermal zone update after a cooling device registered
2015-10-14 17:07 ` Javi Merino
@ 2015-10-14 19:23 ` Chen, Yu C
2015-10-14 19:23 ` Chen, Yu C
1 sibling, 0 replies; 21+ messages in thread
From: Chen, Yu C @ 2015-10-14 19:23 UTC (permalink / raw)
To: Javi Merino
Cc: linux-pm, edubezval, Zhang, Rui, linux-kernel, stable,
Pandruvada, Srinivas
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 3510 bytes --]
Hi,Javi
> -----Original Message-----
> From: Javi Merino [mailto:javi.merino@arm.com]
> Sent: Thursday, October 15, 2015 1:08 AM
> To: Chen, Yu C
> Cc: linux-pm@vger.kernel.org; edubezval@gmail.com; Zhang, Rui; linux-
> kernel@vger.kernel.org; stable@vger.kernel.org; Pandruvada, Srinivas
> Subject: Re: [PATCH 3/3] Thermal: do thermal zone update after a cooling
> device registered
>
> On Mon, Oct 12, 2015 at 09:23:28AM +0000, Chen, Yu C wrote:
> > Hi, Javi
> > Sorry for my late response,
> >
> > > -----Original Message-----
> > > From: Javi Merino [mailto:javi.merino@arm.com]
> > > Sent: Wednesday, September 30, 2015 12:02 AM
> > > To: Chen, Yu C
> > > Cc: linux-pm@vger.kernel.org; edubezval@gmail.com; Zhang, Rui;
> > > linux- kernel@vger.kernel.org; stable@vger.kernel.org
> > > Subject: Re: [PATCH 3/3] Thermal: do thermal zone update after a
> > > cooling device registered
> > >
> > > Hi Yu,
> > >
> > > On Mon, Sep 28, 2015 at 06:52:00PM +0100, Chen, Yu C wrote:
> > > > Hi, Javi,
> > > >
> > > > > -----Original Message-----
> > > > > From: Javi Merino [mailto:javi.merino@arm.com]
> > > > > Sent: Monday, September 28, 2015 10:29 PM
> > > > > To: Chen, Yu C
> > > > > Cc: linux-pm@vger.kernel.org; edubezval@gmail.com; Zhang, Rui;
> > > > > linux- kernel@vger.kernel.org; stable@vger.kernel.org
> > > > > Subject: Re: [PATCH 3/3] Thermal: do thermal zone update after a
> > > > > cooling device registered
> > > > >
> > > > > On Sun, Sep 27, 2015 at 06:48:44AM +0100, Chen Yu wrote:
> > > > > > From: Zhang Rui <rui.zhang@intel.com>
> > > > > >
> > > > > >
> > > > >
> > > > > I think you need to hold cdev->lock here, to make sure that no
> > > > > thermal zone is added or removed from cdev->thermal_instances
> > > > > while
> > > you are looping.
> > > > >
> > > > Ah right, will add. If I add the cdev ->lock here, will there be a
> > > > AB-BA lock with thermal_zone_unbind_cooling_device?
> > >
> > > You're right, it could lead to a deadlock. The locks can't be
> > > swapped because that won't work in step_wise.
> > >
> > > The best way that I can think of accessing thermal_instances
> > > atomically is by making it RCU protected instead of with mutexes.
> > > What do you think?
> > >
> > RCU would need extra spinlocks to protect the list, and need to
> > sync_rcu after we delete one instance from thermal_instance list, I
> > think it is too complicated for me to rewrite: ( How about using
> thermal_list_lock instead of cdev ->lock?
> > This guy should be big enough to protect the device.thermal_instance list.
>
> thermal_list_lock protects thermal_tz_list and thermal_cdev_list, but it
> doesn't protect the thermal_instances list. For example,
> thermal_zone_bind_cooling_device() adds a cooling device to the
> cdev->thermal_instances list without taking thermal_tz_list.
>
Before thermal_zone_bind_cooling_device is invoked,
the thermal_list_lock will be firstly gripped:
static void bind_cdev(struct thermal_cooling_device *cdev)
{
mutex_lock(&thermal_list_lock);
either tz->ops->bind : thermal_zone_bind_cooling_device
or __bind() : thermal_zone_bind_cooling_device
mutex_unlock(&thermal_list_lock);
}
And it is the same as in passive_store.
So when code is trying to add/delete thermal_instance of cdev,
he has already hold thermal_list_lock IMO. Or do I miss anything?
Best Regards,
Yu
ÿôèº{.nÇ+·®+%Ëÿ±éݶ\x17¥wÿº{.nÇ+·¥{±þG«éÿ{ayº\x1dÊÚë,j\a¢f£¢·hïêÿêçz_è®\x03(éÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?¨èÚ&£ø§~á¶iOæ¬z·vØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?I¥
^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: [PATCH 3/3] Thermal: do thermal zone update after a cooling device registered
@ 2015-10-14 19:23 ` Chen, Yu C
0 siblings, 0 replies; 21+ messages in thread
From: Chen, Yu C @ 2015-10-14 19:23 UTC (permalink / raw)
To: Javi Merino
Cc: linux-pm, edubezval, Zhang, Rui, linux-kernel, stable,
Pandruvada, Srinivas
Hi,Javi
> -----Original Message-----
> From: Javi Merino [mailto:javi.merino@arm.com]
> Sent: Thursday, October 15, 2015 1:08 AM
> To: Chen, Yu C
> Cc: linux-pm@vger.kernel.org; edubezval@gmail.com; Zhang, Rui; linux-
> kernel@vger.kernel.org; stable@vger.kernel.org; Pandruvada, Srinivas
> Subject: Re: [PATCH 3/3] Thermal: do thermal zone update after a cooling
> device registered
>
> On Mon, Oct 12, 2015 at 09:23:28AM +0000, Chen, Yu C wrote:
> > Hi, Javi
> > Sorry for my late response,
> >
> > > -----Original Message-----
> > > From: Javi Merino [mailto:javi.merino@arm.com]
> > > Sent: Wednesday, September 30, 2015 12:02 AM
> > > To: Chen, Yu C
> > > Cc: linux-pm@vger.kernel.org; edubezval@gmail.com; Zhang, Rui;
> > > linux- kernel@vger.kernel.org; stable@vger.kernel.org
> > > Subject: Re: [PATCH 3/3] Thermal: do thermal zone update after a
> > > cooling device registered
> > >
> > > Hi Yu,
> > >
> > > On Mon, Sep 28, 2015 at 06:52:00PM +0100, Chen, Yu C wrote:
> > > > Hi, Javi,
> > > >
> > > > > -----Original Message-----
> > > > > From: Javi Merino [mailto:javi.merino@arm.com]
> > > > > Sent: Monday, September 28, 2015 10:29 PM
> > > > > To: Chen, Yu C
> > > > > Cc: linux-pm@vger.kernel.org; edubezval@gmail.com; Zhang, Rui;
> > > > > linux- kernel@vger.kernel.org; stable@vger.kernel.org
> > > > > Subject: Re: [PATCH 3/3] Thermal: do thermal zone update after a
> > > > > cooling device registered
> > > > >
> > > > > On Sun, Sep 27, 2015 at 06:48:44AM +0100, Chen Yu wrote:
> > > > > > From: Zhang Rui <rui.zhang@intel.com>
> > > > > >
> > > > > >
> > > > >
> > > > > I think you need to hold cdev->lock here, to make sure that no
> > > > > thermal zone is added or removed from cdev->thermal_instances
> > > > > while
> > > you are looping.
> > > > >
> > > > Ah right, will add. If I add the cdev ->lock here, will there be a
> > > > AB-BA lock with thermal_zone_unbind_cooling_device?
> > >
> > > You're right, it could lead to a deadlock. The locks can't be
> > > swapped because that won't work in step_wise.
> > >
> > > The best way that I can think of accessing thermal_instances
> > > atomically is by making it RCU protected instead of with mutexes.
> > > What do you think?
> > >
> > RCU would need extra spinlocks to protect the list, and need to
> > sync_rcu after we delete one instance from thermal_instance list, I
> > think it is too complicated for me to rewrite: ( How about using
> thermal_list_lock instead of cdev ->lock?
> > This guy should be big enough to protect the device.thermal_instance list.
>
> thermal_list_lock protects thermal_tz_list and thermal_cdev_list, but it
> doesn't protect the thermal_instances list. For example,
> thermal_zone_bind_cooling_device() adds a cooling device to the
> cdev->thermal_instances list without taking thermal_tz_list.
>
Before thermal_zone_bind_cooling_device is invoked,
the thermal_list_lock will be firstly gripped:
static void bind_cdev(struct thermal_cooling_device *cdev)
{
mutex_lock(&thermal_list_lock);
either tz->ops->bind : thermal_zone_bind_cooling_device
or __bind() : thermal_zone_bind_cooling_device
mutex_unlock(&thermal_list_lock);
}
And it is the same as in passive_store.
So when code is trying to add/delete thermal_instance of cdev,
he has already hold thermal_list_lock IMO. Or do I miss anything?
Best Regards,
Yu
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH 3/3] Thermal: do thermal zone update after a cooling device registered
2015-10-14 19:23 ` Chen, Yu C
(?)
@ 2015-10-15 14:05 ` Javi Merino
2015-10-20 1:05 ` Chen, Yu C
2015-10-20 1:44 ` Chen, Yu C
-1 siblings, 2 replies; 21+ messages in thread
From: Javi Merino @ 2015-10-15 14:05 UTC (permalink / raw)
To: Chen, Yu C
Cc: linux-pm, edubezval, Zhang, Rui, linux-kernel, stable,
Pandruvada, Srinivas
On Wed, Oct 14, 2015 at 07:23:55PM +0000, Chen, Yu C wrote:
> > -----Original Message-----
> > From: Javi Merino [mailto:javi.merino@arm.com]
> > Sent: Thursday, October 15, 2015 1:08 AM
> > To: Chen, Yu C
> > Cc: linux-pm@vger.kernel.org; edubezval@gmail.com; Zhang, Rui; linux-
> > kernel@vger.kernel.org; stable@vger.kernel.org; Pandruvada, Srinivas
> > Subject: Re: [PATCH 3/3] Thermal: do thermal zone update after a cooling
> > device registered
> >
> > On Mon, Oct 12, 2015 at 09:23:28AM +0000, Chen, Yu C wrote:
> > > Hi, Javi
> > > Sorry for my late response,
> > >
> > > > -----Original Message-----
> > > > From: Javi Merino [mailto:javi.merino@arm.com]
> > > > Sent: Wednesday, September 30, 2015 12:02 AM
> > > > To: Chen, Yu C
> > > > Cc: linux-pm@vger.kernel.org; edubezval@gmail.com; Zhang, Rui;
> > > > linux- kernel@vger.kernel.org; stable@vger.kernel.org
> > > > Subject: Re: [PATCH 3/3] Thermal: do thermal zone update after a
> > > > cooling device registered
> > > >
> > > > Hi Yu,
> > > >
> > > > On Mon, Sep 28, 2015 at 06:52:00PM +0100, Chen, Yu C wrote:
> > > > > Hi, Javi,
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Javi Merino [mailto:javi.merino@arm.com]
> > > > > > Sent: Monday, September 28, 2015 10:29 PM
> > > > > > To: Chen, Yu C
> > > > > > Cc: linux-pm@vger.kernel.org; edubezval@gmail.com; Zhang, Rui;
> > > > > > linux- kernel@vger.kernel.org; stable@vger.kernel.org
> > > > > > Subject: Re: [PATCH 3/3] Thermal: do thermal zone update after a
> > > > > > cooling device registered
> > > > > >
> > > > > > On Sun, Sep 27, 2015 at 06:48:44AM +0100, Chen Yu wrote:
> > > > > > > From: Zhang Rui <rui.zhang@intel.com>
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > I think you need to hold cdev->lock here, to make sure that no
> > > > > > thermal zone is added or removed from cdev->thermal_instances
> > > > > > while
> > > > you are looping.
> > > > > >
> > > > > Ah right, will add. If I add the cdev ->lock here, will there be a
> > > > > AB-BA lock with thermal_zone_unbind_cooling_device?
> > > >
> > > > You're right, it could lead to a deadlock. The locks can't be
> > > > swapped because that won't work in step_wise.
> > > >
> > > > The best way that I can think of accessing thermal_instances
> > > > atomically is by making it RCU protected instead of with mutexes.
> > > > What do you think?
> > > >
> > > RCU would need extra spinlocks to protect the list, and need to
> > > sync_rcu after we delete one instance from thermal_instance list, I
> > > think it is too complicated for me to rewrite: ( How about using
> > thermal_list_lock instead of cdev ->lock?
> > > This guy should be big enough to protect the device.thermal_instance list.
> >
> > thermal_list_lock protects thermal_tz_list and thermal_cdev_list, but it
> > doesn't protect the thermal_instances list. For example,
> > thermal_zone_bind_cooling_device() adds a cooling device to the
> > cdev->thermal_instances list without taking thermal_tz_list.
> >
> Before thermal_zone_bind_cooling_device is invoked,
> the thermal_list_lock will be firstly gripped:
>
> static void bind_cdev(struct thermal_cooling_device *cdev)
> {
> mutex_lock(&thermal_list_lock);
> either tz->ops->bind : thermal_zone_bind_cooling_device
> or __bind() : thermal_zone_bind_cooling_device
> mutex_unlock(&thermal_list_lock);
> }
>
> And it is the same as in passive_store.
> So when code is trying to add/delete thermal_instance of cdev,
> he has already hold thermal_list_lock IMO. Or do I miss anything?
thermal_zone_bind_cooling_device() is exported, so you can't really
rely on the static thermal_list_lock being acquired in every single
call.
thermal_list_lock and protects the lists thermal_tz_list and
thermal_cdev_list. Making it implicitly protect the cooling device's
and thermal zone device's instances list because no sensible code
would call thermal_zone_bind_cooling_device() outside of a bind
function is just asking for trouble.
Locking is hard to understand and easy to get wrong so let's keep it
simple.
Cheers,
Javi
^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: [PATCH 3/3] Thermal: do thermal zone update after a cooling device registered
2015-10-15 14:05 ` Javi Merino
@ 2015-10-20 1:05 ` Chen, Yu C
2015-10-20 1:44 ` Chen, Yu C
1 sibling, 0 replies; 21+ messages in thread
From: Chen, Yu C @ 2015-10-20 1:05 UTC (permalink / raw)
To: Javi Merino
Cc: linux-pm, edubezval, Zhang, Rui, linux-kernel, stable,
Pandruvada, Srinivas, manuelkrause
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 5641 bytes --]
Hi,
> -----Original Message-----
> From: Javi Merino [mailto:javi.merino@arm.com]
> Sent: Thursday, October 15, 2015 10:05 PM
> To: Chen, Yu C
> Cc: linux-pm@vger.kernel.org; edubezval@gmail.com; Zhang, Rui; linux-
> kernel@vger.kernel.org; stable@vger.kernel.org; Pandruvada, Srinivas
> Subject: Re: [PATCH 3/3] Thermal: do thermal zone update after a cooling
> device registered
>
> On Wed, Oct 14, 2015 at 07:23:55PM +0000, Chen, Yu C wrote:
> > > -----Original Message-----
> > > From: Javi Merino [mailto:javi.merino@arm.com]
> > > Sent: Thursday, October 15, 2015 1:08 AM
> > > To: Chen, Yu C
> > > Cc: linux-pm@vger.kernel.org; edubezval@gmail.com; Zhang, Rui;
> > > linux- kernel@vger.kernel.org; stable@vger.kernel.org; Pandruvada,
> > > Srinivas
> > > Subject: Re: [PATCH 3/3] Thermal: do thermal zone update after a
> > > cooling device registered
> > >
> > > On Mon, Oct 12, 2015 at 09:23:28AM +0000, Chen, Yu C wrote:
> > > > Hi, Javi
> > > > Sorry for my late response,
> > > >
> > > > > -----Original Message-----
> > > > > From: Javi Merino [mailto:javi.merino@arm.com]
> > > > > Sent: Wednesday, September 30, 2015 12:02 AM
> > > > > To: Chen, Yu C
> > > > > Cc: linux-pm@vger.kernel.org; edubezval@gmail.com; Zhang, Rui;
> > > > > linux- kernel@vger.kernel.org; stable@vger.kernel.org
> > > > > Subject: Re: [PATCH 3/3] Thermal: do thermal zone update after a
> > > > > cooling device registered
> > > > >
> > > > > Hi Yu,
> > > > >
> > > > > On Mon, Sep 28, 2015 at 06:52:00PM +0100, Chen, Yu C wrote:
> > > > > > Hi, Javi,
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Javi Merino [mailto:javi.merino@arm.com]
> > > > > > > Sent: Monday, September 28, 2015 10:29 PM
> > > > > > > To: Chen, Yu C
> > > > > > > Cc: linux-pm@vger.kernel.org; edubezval@gmail.com; Zhang,
> > > > > > > Rui;
> > > > > > > linux- kernel@vger.kernel.org; stable@vger.kernel.org
> > > > > > > Subject: Re: [PATCH 3/3] Thermal: do thermal zone update
> > > > > > > after a cooling device registered
> > > > > > >
> > > > > > > On Sun, Sep 27, 2015 at 06:48:44AM +0100, Chen Yu wrote:
> > > > > > > > From: Zhang Rui <rui.zhang@intel.com>
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > I think you need to hold cdev->lock here, to make sure that
> > > > > > > no thermal zone is added or removed from
> > > > > > > cdev->thermal_instances while
> > > > > you are looping.
> > > > > > >
> > > > > > Ah right, will add. If I add the cdev ->lock here, will there
> > > > > > be a AB-BA lock with thermal_zone_unbind_cooling_device?
> > > > >
> > > > > You're right, it could lead to a deadlock. The locks can't be
> > > > > swapped because that won't work in step_wise.
> > > > >
> > > > > The best way that I can think of accessing thermal_instances
> > > > > atomically is by making it RCU protected instead of with mutexes.
> > > > > What do you think?
> > > > >
> > > > RCU would need extra spinlocks to protect the list, and need to
> > > > sync_rcu after we delete one instance from thermal_instance list,
> > > > I think it is too complicated for me to rewrite: ( How about using
> > > thermal_list_lock instead of cdev ->lock?
> > > > This guy should be big enough to protect the device.thermal_instance
> list.
> > >
> > > thermal_list_lock protects thermal_tz_list and thermal_cdev_list,
> > > but it doesn't protect the thermal_instances list. For example,
> > > thermal_zone_bind_cooling_device() adds a cooling device to the
> > > cdev->thermal_instances list without taking thermal_tz_list.
> > >
> > Before thermal_zone_bind_cooling_device is invoked, the
> > thermal_list_lock will be firstly gripped:
> >
> > static void bind_cdev(struct thermal_cooling_device *cdev) {
> > mutex_lock(&thermal_list_lock);
> > either tz->ops->bind : thermal_zone_bind_cooling_device
> > or __bind() : thermal_zone_bind_cooling_device
> > mutex_unlock(&thermal_list_lock);
> > }
> >
> > And it is the same as in passive_store.
> > So when code is trying to add/delete thermal_instance of cdev, he has
> > already hold thermal_list_lock IMO. Or do I miss anything?
>
> thermal_zone_bind_cooling_device() is exported, so you can't really rely on
> the static thermal_list_lock being acquired in every single call.
>
> thermal_list_lock and protects the lists thermal_tz_list and thermal_cdev_list.
> Making it implicitly protect the cooling device's and thermal zone device's
> instances list because no sensible code would call
> thermal_zone_bind_cooling_device() outside of a bind function is just asking
> for trouble.
>
Yes, from this point of view,it is true.
> Locking is hard to understand and easy to get wrong so let's keep it simple.
>
How about the following 2 methods:
1. avoid accessing device's thermal_instance,but
access all thermal_zone_device directly, although there might be some redundancy,
some thermal zones do not need to be updated, but we can avoid gripping dev->lock:
mutex_lock(&thermal_list_lock);
list_for_each_entry(pos, &thermal_tz_list, node)
thermal_zone_device_update(tz);
mutex_unlock(&thermal_list_lock);
or,
2. Once we bind the new device with the thermal_zone_device, we can record that
thermal_zone_device, and update that thermal_zone_device alone.
BTW, since thermal_zone_device_update is not atomic, we might need another patch
to make it into atomic or something like that, but for now, I think these three patches are
just for fixing the regressions.
Thanks
Best Regards,
Yu
ÿôèº{.nÇ+·®+%Ëÿ±éݶ\x17¥wÿº{.nÇ+·¥{±þG«éÿ{ayº\x1dÊÚë,j\a¢f£¢·hïêÿêçz_è®\x03(éÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?¨èÚ&£ø§~á¶iOæ¬z·vØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?I¥
^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: [PATCH 3/3] Thermal: do thermal zone update after a cooling device registered
@ 2015-10-20 1:05 ` Chen, Yu C
0 siblings, 0 replies; 21+ messages in thread
From: Chen, Yu C @ 2015-10-20 1:05 UTC (permalink / raw)
To: Javi Merino
Cc: linux-pm, edubezval, Zhang, Rui, linux-kernel, stable,
Pandruvada, Srinivas, manuelkrause
Hi,
> -----Original Message-----
> From: Javi Merino [mailto:javi.merino@arm.com]
> Sent: Thursday, October 15, 2015 10:05 PM
> To: Chen, Yu C
> Cc: linux-pm@vger.kernel.org; edubezval@gmail.com; Zhang, Rui; linux-
> kernel@vger.kernel.org; stable@vger.kernel.org; Pandruvada, Srinivas
> Subject: Re: [PATCH 3/3] Thermal: do thermal zone update after a cooling
> device registered
>
> On Wed, Oct 14, 2015 at 07:23:55PM +0000, Chen, Yu C wrote:
> > > -----Original Message-----
> > > From: Javi Merino [mailto:javi.merino@arm.com]
> > > Sent: Thursday, October 15, 2015 1:08 AM
> > > To: Chen, Yu C
> > > Cc: linux-pm@vger.kernel.org; edubezval@gmail.com; Zhang, Rui;
> > > linux- kernel@vger.kernel.org; stable@vger.kernel.org; Pandruvada,
> > > Srinivas
> > > Subject: Re: [PATCH 3/3] Thermal: do thermal zone update after a
> > > cooling device registered
> > >
> > > On Mon, Oct 12, 2015 at 09:23:28AM +0000, Chen, Yu C wrote:
> > > > Hi, Javi
> > > > Sorry for my late response,
> > > >
> > > > > -----Original Message-----
> > > > > From: Javi Merino [mailto:javi.merino@arm.com]
> > > > > Sent: Wednesday, September 30, 2015 12:02 AM
> > > > > To: Chen, Yu C
> > > > > Cc: linux-pm@vger.kernel.org; edubezval@gmail.com; Zhang, Rui;
> > > > > linux- kernel@vger.kernel.org; stable@vger.kernel.org
> > > > > Subject: Re: [PATCH 3/3] Thermal: do thermal zone update after a
> > > > > cooling device registered
> > > > >
> > > > > Hi Yu,
> > > > >
> > > > > On Mon, Sep 28, 2015 at 06:52:00PM +0100, Chen, Yu C wrote:
> > > > > > Hi, Javi,
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Javi Merino [mailto:javi.merino@arm.com]
> > > > > > > Sent: Monday, September 28, 2015 10:29 PM
> > > > > > > To: Chen, Yu C
> > > > > > > Cc: linux-pm@vger.kernel.org; edubezval@gmail.com; Zhang,
> > > > > > > Rui;
> > > > > > > linux- kernel@vger.kernel.org; stable@vger.kernel.org
> > > > > > > Subject: Re: [PATCH 3/3] Thermal: do thermal zone update
> > > > > > > after a cooling device registered
> > > > > > >
> > > > > > > On Sun, Sep 27, 2015 at 06:48:44AM +0100, Chen Yu wrote:
> > > > > > > > From: Zhang Rui <rui.zhang@intel.com>
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > I think you need to hold cdev->lock here, to make sure that
> > > > > > > no thermal zone is added or removed from
> > > > > > > cdev->thermal_instances while
> > > > > you are looping.
> > > > > > >
> > > > > > Ah right, will add. If I add the cdev ->lock here, will there
> > > > > > be a AB-BA lock with thermal_zone_unbind_cooling_device?
> > > > >
> > > > > You're right, it could lead to a deadlock. The locks can't be
> > > > > swapped because that won't work in step_wise.
> > > > >
> > > > > The best way that I can think of accessing thermal_instances
> > > > > atomically is by making it RCU protected instead of with mutexes.
> > > > > What do you think?
> > > > >
> > > > RCU would need extra spinlocks to protect the list, and need to
> > > > sync_rcu after we delete one instance from thermal_instance list,
> > > > I think it is too complicated for me to rewrite: ( How about using
> > > thermal_list_lock instead of cdev ->lock?
> > > > This guy should be big enough to protect the device.thermal_instance
> list.
> > >
> > > thermal_list_lock protects thermal_tz_list and thermal_cdev_list,
> > > but it doesn't protect the thermal_instances list. For example,
> > > thermal_zone_bind_cooling_device() adds a cooling device to the
> > > cdev->thermal_instances list without taking thermal_tz_list.
> > >
> > Before thermal_zone_bind_cooling_device is invoked, the
> > thermal_list_lock will be firstly gripped:
> >
> > static void bind_cdev(struct thermal_cooling_device *cdev) {
> > mutex_lock(&thermal_list_lock);
> > either tz->ops->bind : thermal_zone_bind_cooling_device
> > or __bind() : thermal_zone_bind_cooling_device
> > mutex_unlock(&thermal_list_lock);
> > }
> >
> > And it is the same as in passive_store.
> > So when code is trying to add/delete thermal_instance of cdev, he has
> > already hold thermal_list_lock IMO. Or do I miss anything?
>
> thermal_zone_bind_cooling_device() is exported, so you can't really rely on
> the static thermal_list_lock being acquired in every single call.
>
> thermal_list_lock and protects the lists thermal_tz_list and thermal_cdev_list.
> Making it implicitly protect the cooling device's and thermal zone device's
> instances list because no sensible code would call
> thermal_zone_bind_cooling_device() outside of a bind function is just asking
> for trouble.
>
Yes, from this point of view,it is true.
> Locking is hard to understand and easy to get wrong so let's keep it simple.
>
How about the following 2 methods:
1. avoid accessing device's thermal_instance,but
access all thermal_zone_device directly, although there might be some redundancy,
some thermal zones do not need to be updated, but we can avoid gripping dev->lock:
mutex_lock(&thermal_list_lock);
list_for_each_entry(pos, &thermal_tz_list, node)
thermal_zone_device_update(tz);
mutex_unlock(&thermal_list_lock);
or,
2. Once we bind the new device with the thermal_zone_device, we can record that
thermal_zone_device, and update that thermal_zone_device alone.
BTW, since thermal_zone_device_update is not atomic, we might need another patch
to make it into atomic or something like that, but for now, I think these three patches are
just for fixing the regressions.
Thanks
Best Regards,
Yu
^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: [PATCH 3/3] Thermal: do thermal zone update after a cooling device registered
2015-10-15 14:05 ` Javi Merino
@ 2015-10-20 1:44 ` Chen, Yu C
2015-10-20 1:44 ` Chen, Yu C
1 sibling, 0 replies; 21+ messages in thread
From: Chen, Yu C @ 2015-10-20 1:44 UTC (permalink / raw)
To: Javi Merino
Cc: linux-pm, edubezval, Zhang, Rui, linux-kernel, stable,
Pandruvada, Srinivas
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 5920 bytes --]
(resend for broken display)
Hi,
> -----Original Message-----
> From: Javi Merino [mailto:javi.merino@arm.com]
> Sent: Thursday, October 15, 2015 10:05 PM
> To: Chen, Yu C
> Cc: linux-pm@vger.kernel.org; edubezval@gmail.com; Zhang, Rui; linux-
> kernel@vger.kernel.org; stable@vger.kernel.org; Pandruvada, Srinivas
> Subject: Re: [PATCH 3/3] Thermal: do thermal zone update after a
> cooling device registered
>
> On Wed, Oct 14, 2015 at 07:23:55PM +0000, Chen, Yu C wrote:
> > > -----Original Message-----
> > > From: Javi Merino [mailto:javi.merino@arm.com]
> > > Sent: Thursday, October 15, 2015 1:08 AM
> > > To: Chen, Yu C
> > > Cc: linux-pm@vger.kernel.org; edubezval@gmail.com; Zhang, Rui;
> > > linux- kernel@vger.kernel.org; stable@vger.kernel.org; Pandruvada,
> > > Srinivas
> > > Subject: Re: [PATCH 3/3] Thermal: do thermal zone update after a
> > > cooling device registered
> > >
> > > On Mon, Oct 12, 2015 at 09:23:28AM +0000, Chen, Yu C wrote:
> > > > Hi, Javi
> > > > Sorry for my late response,
> > > >
> > > > > -----Original Message-----
> > > > > From: Javi Merino [mailto:javi.merino@arm.com]
> > > > > Sent: Wednesday, September 30, 2015 12:02 AM
> > > > > To: Chen, Yu C
> > > > > Cc: linux-pm@vger.kernel.org; edubezval@gmail.com; Zhang, Rui;
> > > > > linux- kernel@vger.kernel.org; stable@vger.kernel.org
> > > > > Subject: Re: [PATCH 3/3] Thermal: do thermal zone update after
> > > > > a cooling device registered
> > > > >
> > > > > Hi Yu,
> > > > >
> > > > > On Mon, Sep 28, 2015 at 06:52:00PM +0100, Chen, Yu C wrote:
> > > > > > Hi, Javi,
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Javi Merino [mailto:javi.merino@arm.com]
> > > > > > > Sent: Monday, September 28, 2015 10:29 PM
> > > > > > > To: Chen, Yu C
> > > > > > > Cc: linux-pm@vger.kernel.org; edubezval@gmail.com; Zhang,
> > > > > > > Rui;
> > > > > > > linux- kernel@vger.kernel.org; stable@vger.kernel.org
> > > > > > > Subject: Re: [PATCH 3/3] Thermal: do thermal zone update
> > > > > > > after a cooling device registered
> > > > > > >
> > > > > > > On Sun, Sep 27, 2015 at 06:48:44AM +0100, Chen Yu wrote:
> > > > > > > > From: Zhang Rui <rui.zhang@intel.com>
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > I think you need to hold cdev->lock here, to make sure
> > > > > > > that no thermal zone is added or removed from
> > > > > > > cdev->thermal_instances while
> > > > > you are looping.
> > > > > > >
> > > > > > Ah right, will add. If I add the cdev ->lock here, will
> > > > > > there be a AB-BA lock with thermal_zone_unbind_cooling_device?
> > > > >
> > > > > You're right, it could lead to a deadlock. The locks can't be
> > > > > swapped because that won't work in step_wise.
> > > > >
> > > > > The best way that I can think of accessing thermal_instances
> > > > > atomically is by making it RCU protected instead of with mutexes.
> > > > > What do you think?
> > > > >
> > > > RCU would need extra spinlocks to protect the list, and need to
> > > > sync_rcu after we delete one instance from thermal_instance
> > > > list, I think it is too complicated for me to rewrite: ( How
> > > > about using
> > > thermal_list_lock instead of cdev ->lock?
> > > > This guy should be big enough to protect the
> > > > device.thermal_instance
> list.
> > >
> > > thermal_list_lock protects thermal_tz_list and thermal_cdev_list,
> > > but it doesn't protect the thermal_instances list. For example,
> > > thermal_zone_bind_cooling_device() adds a cooling device to the
> > > cdev->thermal_instances list without taking thermal_tz_list.
> > >
> > Before thermal_zone_bind_cooling_device is invoked, the
> > thermal_list_lock will be firstly gripped:
> >
> > static void bind_cdev(struct thermal_cooling_device *cdev) {
> > mutex_lock(&thermal_list_lock);
> > either tz->ops->bind : thermal_zone_bind_cooling_device
> > or __bind() : thermal_zone_bind_cooling_device
> > mutex_unlock(&thermal_list_lock);
> > }
> >
> > And it is the same as in passive_store.
> > So when code is trying to add/delete thermal_instance of cdev, he
> > has already hold thermal_list_lock IMO. Or do I miss anything?
>
> thermal_zone_bind_cooling_device() is exported, so you can't really
> rely on the static thermal_list_lock being acquired in every single call.
>
> thermal_list_lock and protects the lists thermal_tz_list and thermal_cdev_list.
> Making it implicitly protect the cooling device's and thermal zone
> device's instances list because no sensible code would call
> thermal_zone_bind_cooling_device() outside of a bind function is just
> asking for trouble.
>
Yes, from this point of view,it is true.
> Locking is hard to understand and easy to get wrong so let's keep it simple.
>
How about the following 2 methods:
1. avoid accessing device's thermal_instance,
but access all thermal_zone_device directly,
although there might be some redundancy,
some thermal zones do not need to be updated,
but we can avoid gripping dev->lock:
mutex_lock(&thermal_list_lock);
list_for_each_entry(pos, &thermal_tz_list, node)
thermal_zone_device_update(tz);
mutex_unlock(&thermal_list_lock);
or,
2. Once we bind the new device with the thermal_zone_device,
we can record that thermal_zone_device,
and update that thermal_zone_device alone,the the code would be:
mutex_lock(&thermal_list_lock);
list_for_each_entry(pos, &thermal_tz_list, node){
if (tz->need_update)
thermal_zone_device_update(tz);
}
mutex_unlock(&thermal_list_lock);
BTW, since thermal_zone_device_update is not atomic,
we might need another patch to make it into atomic or
something like that, but for now, I think these three patches
are just for fixing the regressions.
Thanks
Best Regards,
Yu
ÿôèº{.nÇ+·®+%Ëÿ±éݶ\x17¥wÿº{.nÇ+·¥{±þG«éÿ{ayº\x1dÊÚë,j\a¢f£¢·hïêÿêçz_è®\x03(éÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?¨èÚ&£ø§~á¶iOæ¬z·vØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?I¥
^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: [PATCH 3/3] Thermal: do thermal zone update after a cooling device registered
@ 2015-10-20 1:44 ` Chen, Yu C
0 siblings, 0 replies; 21+ messages in thread
From: Chen, Yu C @ 2015-10-20 1:44 UTC (permalink / raw)
To: Javi Merino
Cc: linux-pm, edubezval, Zhang, Rui, linux-kernel, stable,
Pandruvada, Srinivas
(resend for broken display)
Hi,
> -----Original Message-----
> From: Javi Merino [mailto:javi.merino@arm.com]
> Sent: Thursday, October 15, 2015 10:05 PM
> To: Chen, Yu C
> Cc: linux-pm@vger.kernel.org; edubezval@gmail.com; Zhang, Rui; linux-
> kernel@vger.kernel.org; stable@vger.kernel.org; Pandruvada, Srinivas
> Subject: Re: [PATCH 3/3] Thermal: do thermal zone update after a
> cooling device registered
>
> On Wed, Oct 14, 2015 at 07:23:55PM +0000, Chen, Yu C wrote:
> > > -----Original Message-----
> > > From: Javi Merino [mailto:javi.merino@arm.com]
> > > Sent: Thursday, October 15, 2015 1:08 AM
> > > To: Chen, Yu C
> > > Cc: linux-pm@vger.kernel.org; edubezval@gmail.com; Zhang, Rui;
> > > linux- kernel@vger.kernel.org; stable@vger.kernel.org; Pandruvada,
> > > Srinivas
> > > Subject: Re: [PATCH 3/3] Thermal: do thermal zone update after a
> > > cooling device registered
> > >
> > > On Mon, Oct 12, 2015 at 09:23:28AM +0000, Chen, Yu C wrote:
> > > > Hi, Javi
> > > > Sorry for my late response,
> > > >
> > > > > -----Original Message-----
> > > > > From: Javi Merino [mailto:javi.merino@arm.com]
> > > > > Sent: Wednesday, September 30, 2015 12:02 AM
> > > > > To: Chen, Yu C
> > > > > Cc: linux-pm@vger.kernel.org; edubezval@gmail.com; Zhang, Rui;
> > > > > linux- kernel@vger.kernel.org; stable@vger.kernel.org
> > > > > Subject: Re: [PATCH 3/3] Thermal: do thermal zone update after
> > > > > a cooling device registered
> > > > >
> > > > > Hi Yu,
> > > > >
> > > > > On Mon, Sep 28, 2015 at 06:52:00PM +0100, Chen, Yu C wrote:
> > > > > > Hi, Javi,
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Javi Merino [mailto:javi.merino@arm.com]
> > > > > > > Sent: Monday, September 28, 2015 10:29 PM
> > > > > > > To: Chen, Yu C
> > > > > > > Cc: linux-pm@vger.kernel.org; edubezval@gmail.com; Zhang,
> > > > > > > Rui;
> > > > > > > linux- kernel@vger.kernel.org; stable@vger.kernel.org
> > > > > > > Subject: Re: [PATCH 3/3] Thermal: do thermal zone update
> > > > > > > after a cooling device registered
> > > > > > >
> > > > > > > On Sun, Sep 27, 2015 at 06:48:44AM +0100, Chen Yu wrote:
> > > > > > > > From: Zhang Rui <rui.zhang@intel.com>
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > I think you need to hold cdev->lock here, to make sure
> > > > > > > that no thermal zone is added or removed from
> > > > > > > cdev->thermal_instances while
> > > > > you are looping.
> > > > > > >
> > > > > > Ah right, will add. If I add the cdev ->lock here, will
> > > > > > there be a AB-BA lock with thermal_zone_unbind_cooling_device?
> > > > >
> > > > > You're right, it could lead to a deadlock. The locks can't be
> > > > > swapped because that won't work in step_wise.
> > > > >
> > > > > The best way that I can think of accessing thermal_instances
> > > > > atomically is by making it RCU protected instead of with mutexes.
> > > > > What do you think?
> > > > >
> > > > RCU would need extra spinlocks to protect the list, and need to
> > > > sync_rcu after we delete one instance from thermal_instance
> > > > list, I think it is too complicated for me to rewrite: ( How
> > > > about using
> > > thermal_list_lock instead of cdev ->lock?
> > > > This guy should be big enough to protect the
> > > > device.thermal_instance
> list.
> > >
> > > thermal_list_lock protects thermal_tz_list and thermal_cdev_list,
> > > but it doesn't protect the thermal_instances list. For example,
> > > thermal_zone_bind_cooling_device() adds a cooling device to the
> > > cdev->thermal_instances list without taking thermal_tz_list.
> > >
> > Before thermal_zone_bind_cooling_device is invoked, the
> > thermal_list_lock will be firstly gripped:
> >
> > static void bind_cdev(struct thermal_cooling_device *cdev) {
> > mutex_lock(&thermal_list_lock);
> > either tz->ops->bind : thermal_zone_bind_cooling_device
> > or __bind() : thermal_zone_bind_cooling_device
> > mutex_unlock(&thermal_list_lock);
> > }
> >
> > And it is the same as in passive_store.
> > So when code is trying to add/delete thermal_instance of cdev, he
> > has already hold thermal_list_lock IMO. Or do I miss anything?
>
> thermal_zone_bind_cooling_device() is exported, so you can't really
> rely on the static thermal_list_lock being acquired in every single call.
>
> thermal_list_lock and protects the lists thermal_tz_list and thermal_cdev_list.
> Making it implicitly protect the cooling device's and thermal zone
> device's instances list because no sensible code would call
> thermal_zone_bind_cooling_device() outside of a bind function is just
> asking for trouble.
>
Yes, from this point of view,it is true.
> Locking is hard to understand and easy to get wrong so let's keep it simple.
>
How about the following 2 methods:
1. avoid accessing device's thermal_instance,
but access all thermal_zone_device directly,
although there might be some redundancy,
some thermal zones do not need to be updated,
but we can avoid gripping dev->lock:
mutex_lock(&thermal_list_lock);
list_for_each_entry(pos, &thermal_tz_list, node)
thermal_zone_device_update(tz);
mutex_unlock(&thermal_list_lock);
or,
2. Once we bind the new device with the thermal_zone_device,
we can record that thermal_zone_device,
and update that thermal_zone_device alone,the the code would be:
mutex_lock(&thermal_list_lock);
list_for_each_entry(pos, &thermal_tz_list, node){
if (tz->need_update)
thermal_zone_device_update(tz);
}
mutex_unlock(&thermal_list_lock);
BTW, since thermal_zone_device_update is not atomic,
we might need another patch to make it into atomic or
something like that, but for now, I think these three patches
are just for fixing the regressions.
Thanks
Best Regards,
Yu
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH 3/3] Thermal: do thermal zone update after a cooling device registered
2015-10-20 1:44 ` Chen, Yu C
(?)
@ 2015-10-20 9:47 ` Javi Merino
-1 siblings, 0 replies; 21+ messages in thread
From: Javi Merino @ 2015-10-20 9:47 UTC (permalink / raw)
To: Chen, Yu C
Cc: linux-pm, edubezval, Zhang, Rui, linux-kernel, stable,
Pandruvada, Srinivas
Hi Yu,
On Tue, Oct 20, 2015 at 01:44:20AM +0000, Chen, Yu C wrote:
> > -----Original Message-----
> > From: Javi Merino [mailto:javi.merino@arm.com]
> > Sent: Thursday, October 15, 2015 10:05 PM
> > To: Chen, Yu C
> > Cc: linux-pm@vger.kernel.org; edubezval@gmail.com; Zhang, Rui; linux-
> > kernel@vger.kernel.org; stable@vger.kernel.org; Pandruvada, Srinivas
> > Subject: Re: [PATCH 3/3] Thermal: do thermal zone update after a
> > cooling device registered
> >
> > On Wed, Oct 14, 2015 at 07:23:55PM +0000, Chen, Yu C wrote:
> > > > -----Original Message-----
> > > > From: Javi Merino [mailto:javi.merino@arm.com]
> > > > Sent: Thursday, October 15, 2015 1:08 AM
> > > > To: Chen, Yu C
> > > > Cc: linux-pm@vger.kernel.org; edubezval@gmail.com; Zhang, Rui;
> > > > linux- kernel@vger.kernel.org; stable@vger.kernel.org; Pandruvada,
> > > > Srinivas
> > > > Subject: Re: [PATCH 3/3] Thermal: do thermal zone update after a
> > > > cooling device registered
> > > >
> > > > On Mon, Oct 12, 2015 at 09:23:28AM +0000, Chen, Yu C wrote:
> > > > > Hi, Javi
> > > > > Sorry for my late response,
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Javi Merino [mailto:javi.merino@arm.com]
> > > > > > Sent: Wednesday, September 30, 2015 12:02 AM
> > > > > > To: Chen, Yu C
> > > > > > Cc: linux-pm@vger.kernel.org; edubezval@gmail.com; Zhang, Rui;
> > > > > > linux- kernel@vger.kernel.org; stable@vger.kernel.org
> > > > > > Subject: Re: [PATCH 3/3] Thermal: do thermal zone update after
> > > > > > a cooling device registered
> > > > > >
> > > > > > Hi Yu,
> > > > > >
> > > > > > On Mon, Sep 28, 2015 at 06:52:00PM +0100, Chen, Yu C wrote:
> > > > > > > Hi, Javi,
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Javi Merino [mailto:javi.merino@arm.com]
> > > > > > > > Sent: Monday, September 28, 2015 10:29 PM
> > > > > > > > To: Chen, Yu C
> > > > > > > > Cc: linux-pm@vger.kernel.org; edubezval@gmail.com; Zhang,
> > > > > > > > Rui;
> > > > > > > > linux- kernel@vger.kernel.org; stable@vger.kernel.org
> > > > > > > > Subject: Re: [PATCH 3/3] Thermal: do thermal zone update
> > > > > > > > after a cooling device registered
> > > > > > > >
> > > > > > > > On Sun, Sep 27, 2015 at 06:48:44AM +0100, Chen Yu wrote:
> > > > > > > > > From: Zhang Rui <rui.zhang@intel.com>
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > I think you need to hold cdev->lock here, to make sure
> > > > > > > > that no thermal zone is added or removed from
> > > > > > > > cdev->thermal_instances while
> > > > > > you are looping.
> > > > > > > >
> > > > > > > Ah right, will add. If I add the cdev ->lock here, will
> > > > > > > there be a AB-BA lock with thermal_zone_unbind_cooling_device?
> > > > > >
> > > > > > You're right, it could lead to a deadlock. The locks can't be
> > > > > > swapped because that won't work in step_wise.
> > > > > >
> > > > > > The best way that I can think of accessing thermal_instances
> > > > > > atomically is by making it RCU protected instead of with mutexes.
> > > > > > What do you think?
> > > > > >
> > > > > RCU would need extra spinlocks to protect the list, and need to
> > > > > sync_rcu after we delete one instance from thermal_instance
> > > > > list, I think it is too complicated for me to rewrite: ( How
> > > > > about using
> > > > thermal_list_lock instead of cdev ->lock?
> > > > > This guy should be big enough to protect the
> > > > > device.thermal_instance
> > list.
> > > >
> > > > thermal_list_lock protects thermal_tz_list and thermal_cdev_list,
> > > > but it doesn't protect the thermal_instances list. For example,
> > > > thermal_zone_bind_cooling_device() adds a cooling device to the
> > > > cdev->thermal_instances list without taking thermal_tz_list.
> > > >
> > > Before thermal_zone_bind_cooling_device is invoked, the
> > > thermal_list_lock will be firstly gripped:
> > >
> > > static void bind_cdev(struct thermal_cooling_device *cdev) {
> > > mutex_lock(&thermal_list_lock);
> > > either tz->ops->bind : thermal_zone_bind_cooling_device
> > > or __bind() : thermal_zone_bind_cooling_device
> > > mutex_unlock(&thermal_list_lock);
> > > }
> > >
> > > And it is the same as in passive_store.
> > > So when code is trying to add/delete thermal_instance of cdev, he
> > > has already hold thermal_list_lock IMO. Or do I miss anything?
> >
> > thermal_zone_bind_cooling_device() is exported, so you can't really
> > rely on the static thermal_list_lock being acquired in every single call.
> >
> > thermal_list_lock and protects the lists thermal_tz_list and thermal_cdev_list.
> > Making it implicitly protect the cooling device's and thermal zone
> > device's instances list because no sensible code would call
> > thermal_zone_bind_cooling_device() outside of a bind function is just
> > asking for trouble.
> >
> Yes, from this point of view,it is true.
>
> > Locking is hard to understand and easy to get wrong so let's keep it simple.
> >
> How about the following 2 methods:
> 1. avoid accessing device's thermal_instance,
> but access all thermal_zone_device directly,
> although there might be some redundancy,
> some thermal zones do not need to be updated,
> but we can avoid gripping dev->lock:
>
> mutex_lock(&thermal_list_lock);
> list_for_each_entry(pos, &thermal_tz_list, node)
> thermal_zone_device_update(tz);
> mutex_unlock(&thermal_list_lock);
>
> or,
> 2. Once we bind the new device with the thermal_zone_device,
> we can record that thermal_zone_device,
> and update that thermal_zone_device alone,the the code would be:
>
> mutex_lock(&thermal_list_lock);
> list_for_each_entry(pos, &thermal_tz_list, node){
> if (tz->need_update)
> thermal_zone_device_update(tz);
> }
> mutex_unlock(&thermal_list_lock);
This sounds like a better alternative to me. I was thinking whether
we could add the thremal_zone_device_update() directly in bind_cdev()
to avoid the need_update field but I don't think it's any better: you
would have to put it in two places (for the bind() and tbp.match()
paths).
With the solution you propose above you only have to put it in
__thermal_cooling_device_register(), which is simpler. I vote for
your solution (2) above.
> BTW, since thermal_zone_device_update is not atomic,
> we might need another patch to make it into atomic or
> something like that, but for now, I think these three patches
> are just for fixing the regressions.
Yeah, we can fix that in another series.
Cheers,
Javi
^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: [PATCH 3/3] Thermal: do thermal zone update after a cooling device registered
2015-03-24 15:12 ` Eduardo Valentin
@ 2015-03-25 2:27 ` Zhang, Rui
0 siblings, 0 replies; 21+ messages in thread
From: Zhang, Rui @ 2015-03-25 2:27 UTC (permalink / raw)
To: Eduardo Valentin; +Cc: linux-pm, stable
> -----Original Message-----
> From: linux-pm-owner@vger.kernel.org [mailto:linux-pm-
> owner@vger.kernel.org] On Behalf Of Eduardo Valentin
> Sent: Tuesday, March 24, 2015 11:13 PM
> To: Zhang, Rui
> Cc: linux-pm@vger.kernel.org; stable@vger.kernel.org
> Subject: Re: [PATCH 3/3] Thermal: do thermal zone update after a cooling
> device registered
> Importance: High
>
> Hi,
>
> On Tue, Mar 24, 2015 at 01:21:30PM +0800, Zhang Rui wrote:
> > When a new cooling device is registered, we need to update the thermal
> > zone to set the new registered cooling device to a proper state.
> >
> > This fixes a problem that the system is cool, while the fan devices
> > are left running on full speed after boot, if fan device is registered
> > after thermal zone device.
> >
> > CC: <stable@vger.kernel.org> #3.18+
> > Reference:https://bugzilla.kernel.org/show_bug.cgi?id=92431
> > Tested-by: Manuel Krause <manuelkrause@netscape.net>
> > Tested-by: szegad <szegadlo@poczta.onet.pl>
> > Tested-by: prash <prash.n.rao@gmail.com>
> > Tested-by: amish <ammdispose-arch@yahoo.com>
> > Signed-off-by: Zhang Rui <rui.zhang@intel.com>
> > ---
> > drivers/thermal/thermal_core.c | 10 ++++++++++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/drivers/thermal/thermal_core.c
> > b/drivers/thermal/thermal_core.c index 9c03561..7cef579 100644
> > --- a/drivers/thermal/thermal_core.c
> > +++ b/drivers/thermal/thermal_core.c
> > @@ -1141,6 +1141,7 @@ __thermal_cooling_device_register(struct
> device_node *np,
> > const struct thermal_cooling_device_ops *ops)
> {
> > struct thermal_cooling_device *cdev;
> > + struct thermal_instance *pos, *next;
> > int result;
> >
> > if (type && strlen(type) >= THERMAL_NAME_LENGTH) @@ -1185,6
> +1186,15
> > @@ __thermal_cooling_device_register(struct device_node *np,
> > /* Update binding information for 'this' new cdev */
> > bind_cdev(cdev);
> >
> > + list_for_each_entry_safe(pos, next, &cdev->thermal_instances,
> cdev_node) {
> > + if (next->cdev_node.next == &cdev->thermal_instances)
> {
> > + thermal_zone_device_update(next->tz);
> > + break;
> > + }
> > + if (pos->tz != next->tz)
> > + thermal_zone_device_update(pos->tz);
>
> Shouldn't we simply trigger a thermal_zone_device_update(pos->tz) ? I mean,
> we are adding a new cooling device to the zone, so, it might make sense to
> update it anyway.
>
We may have a couple of themal instances for the same cdev and thermal zone, but for different trips.
And the code above ignore the duplicate thermal_zone_device_update() for the same thermal zone.
Thanks,
rui
> > + }
>
>
> > +
> > return cdev;
> > }
> >
> > --
> > 1.9.1
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> > the body of a message to majordomo@vger.kernel.org More majordomo info
> > at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH 3/3] Thermal: do thermal zone update after a cooling device registered
2015-03-24 5:21 ` [PATCH 3/3] Thermal: do thermal zone update after a cooling device registered Zhang Rui
@ 2015-03-24 15:12 ` Eduardo Valentin
2015-03-25 2:27 ` Zhang, Rui
0 siblings, 1 reply; 21+ messages in thread
From: Eduardo Valentin @ 2015-03-24 15:12 UTC (permalink / raw)
To: Zhang Rui; +Cc: linux-pm, stable
[-- Attachment #1: Type: text/plain, Size: 2243 bytes --]
Hi,
On Tue, Mar 24, 2015 at 01:21:30PM +0800, Zhang Rui wrote:
> When a new cooling device is registered, we need to update the
> thermal zone to set the new registered cooling device to a proper
> state.
>
> This fixes a problem that the system is cool, while the fan devices are left
> running on full speed after boot, if fan device is registered after
> thermal zone device.
>
> CC: <stable@vger.kernel.org> #3.18+
> Reference:https://bugzilla.kernel.org/show_bug.cgi?id=92431
> Tested-by: Manuel Krause <manuelkrause@netscape.net>
> Tested-by: szegad <szegadlo@poczta.onet.pl>
> Tested-by: prash <prash.n.rao@gmail.com>
> Tested-by: amish <ammdispose-arch@yahoo.com>
> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
> ---
> drivers/thermal/thermal_core.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
> index 9c03561..7cef579 100644
> --- a/drivers/thermal/thermal_core.c
> +++ b/drivers/thermal/thermal_core.c
> @@ -1141,6 +1141,7 @@ __thermal_cooling_device_register(struct device_node *np,
> const struct thermal_cooling_device_ops *ops)
> {
> struct thermal_cooling_device *cdev;
> + struct thermal_instance *pos, *next;
> int result;
>
> if (type && strlen(type) >= THERMAL_NAME_LENGTH)
> @@ -1185,6 +1186,15 @@ __thermal_cooling_device_register(struct device_node *np,
> /* Update binding information for 'this' new cdev */
> bind_cdev(cdev);
>
> + list_for_each_entry_safe(pos, next, &cdev->thermal_instances, cdev_node) {
> + if (next->cdev_node.next == &cdev->thermal_instances) {
> + thermal_zone_device_update(next->tz);
> + break;
> + }
> + if (pos->tz != next->tz)
> + thermal_zone_device_update(pos->tz);
Shouldn't we simply trigger a thermal_zone_device_update(pos->tz) ? I
mean, we are adding a new cooling device to the zone, so, it might make
sense to update it anyway.
> + }
> +
> return cdev;
> }
>
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCH 3/3] Thermal: do thermal zone update after a cooling device registered
2015-03-24 5:21 [PATCH 0/3] Thermal: thermal enhancements for boot and system sleep Zhang Rui
@ 2015-03-24 5:21 ` Zhang Rui
2015-03-24 15:12 ` Eduardo Valentin
0 siblings, 1 reply; 21+ messages in thread
From: Zhang Rui @ 2015-03-24 5:21 UTC (permalink / raw)
To: linux-pm; +Cc: Zhang Rui, stable
When a new cooling device is registered, we need to update the
thermal zone to set the new registered cooling device to a proper
state.
This fixes a problem that the system is cool, while the fan devices are left
running on full speed after boot, if fan device is registered after
thermal zone device.
CC: <stable@vger.kernel.org> #3.18+
Reference:https://bugzilla.kernel.org/show_bug.cgi?id=92431
Tested-by: Manuel Krause <manuelkrause@netscape.net>
Tested-by: szegad <szegadlo@poczta.onet.pl>
Tested-by: prash <prash.n.rao@gmail.com>
Tested-by: amish <ammdispose-arch@yahoo.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
---
drivers/thermal/thermal_core.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 9c03561..7cef579 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -1141,6 +1141,7 @@ __thermal_cooling_device_register(struct device_node *np,
const struct thermal_cooling_device_ops *ops)
{
struct thermal_cooling_device *cdev;
+ struct thermal_instance *pos, *next;
int result;
if (type && strlen(type) >= THERMAL_NAME_LENGTH)
@@ -1185,6 +1186,15 @@ __thermal_cooling_device_register(struct device_node *np,
/* Update binding information for 'this' new cdev */
bind_cdev(cdev);
+ list_for_each_entry_safe(pos, next, &cdev->thermal_instances, cdev_node) {
+ if (next->cdev_node.next == &cdev->thermal_instances) {
+ thermal_zone_device_update(next->tz);
+ break;
+ }
+ if (pos->tz != next->tz)
+ thermal_zone_device_update(pos->tz);
+ }
+
return cdev;
}
--
1.9.1
^ permalink raw reply related [flat|nested] 21+ messages in thread
end of thread, other threads:[~2015-10-20 9:48 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-09-27 5:48 [PATCH 3/3] Thermal: do thermal zone update after a cooling device registered Chen Yu
2015-09-28 14:29 ` Javi Merino
2015-09-28 17:52 ` Chen, Yu C
2015-09-28 17:52 ` Chen, Yu C
2015-09-29 16:01 ` Javi Merino
2015-10-12 9:23 ` Chen, Yu C
2015-10-12 9:23 ` Chen, Yu C
2015-10-14 17:07 ` Javi Merino
2015-10-14 19:21 ` Chen, Yu C
2015-10-14 19:21 ` Chen, Yu C
2015-10-14 19:23 ` Chen, Yu C
2015-10-14 19:23 ` Chen, Yu C
2015-10-15 14:05 ` Javi Merino
2015-10-20 1:05 ` Chen, Yu C
2015-10-20 1:05 ` Chen, Yu C
2015-10-20 1:44 ` Chen, Yu C
2015-10-20 1:44 ` Chen, Yu C
2015-10-20 9:47 ` Javi Merino
-- strict thread matches above, loose matches on Subject: below --
2015-03-24 5:21 [PATCH 0/3] Thermal: thermal enhancements for boot and system sleep Zhang Rui
2015-03-24 5:21 ` [PATCH 3/3] Thermal: do thermal zone update after a cooling device registered Zhang Rui
2015-03-24 15:12 ` Eduardo Valentin
2015-03-25 2:27 ` Zhang, Rui
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.