Re: [PATCH v4 1/6] PM / devfreq: Don't take lock in devfreq_add_device

Re: [PATCH v4 1/6] PM / devfreq: Don't take lock in devfreq_add_device

[MyungJoo Ham]

>A device usually doesn't need to lock itself during initialization
>because it is not yet reachable from other threads.
>
>This simplifies the code and helps avoid recursive lock warnings.
>
>Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
>---



From the line of 

> err = device_register(&devfreq->dev);

Other threads may access the protected values.
Thus, if there are recursive lock warnings, we need to resolve it without eliminating lock usages.

 
--
MyungJoo Ham (함명주), Ph.D.
On-Device Lab, Platform Team, Samsung Research.
Cell: +82-10-6714-2858

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v4 1/6] PM / devfreq: Don't take lock in devfreq_add_device

[Leonard Crestez]

On 2019-09-17 8:01 AM, MyungJoo Ham wrote:
>> A device usually doesn't need to lock itself during initialization
>> because it is not yet reachable from other threads.
>>
>> This simplifies the code and helps avoid recursive lock warnings.
>>
>> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
>> ---
> 
> 
> 
>  From the line of
> 
>> err = device_register(&devfreq->dev);
> 
> Other threads may access the protected values.
> Thus, if there are recursive lock warnings, we need to resolve it without eliminating lock usages.

The following fields are initialized after device_register:
   * trans_table
   * time_in_stable
   * last_stat_updated
   * transition_notifier_list

The transition_notifier_list initialization could be easily moved higher.

The rest are for transition statistics and in theory if a transition 
happens his early (how?) or trans_stat_show is called then something bad 
could happen. It seems that trans_stat_show doesn't even take 
devfreq->lock anyway?

The code allocating transition stats could be moved higher by dropping 
devm usage or spliting device_register into device_initialize and 
device_add (but that's more complicated).

Further on the governor is initialized and started after device 
registration but (even before my change). This seems fine, a NULL 
governor is explicitly checked against in various update functions.

--
Regards,
Leonard

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v4 1/6] PM / devfreq: Don't take lock in devfreq_add_device

[Leonard Crestez]

A device usually doesn't need to lock itself during initialization
because it is not yet reachable from other threads.

This simplifies the code and helps avoid recursive lock warnings.

Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
---
 drivers/devfreq/devfreq.c | 10 ----------
 1 file changed, 10 deletions(-)

diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index afbe2a8f7529..15270293bea9 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -636,11 +636,10 @@ struct devfreq *devfreq_add_device(struct device *dev,
 		err = -ENOMEM;
 		goto err_out;
 	}
 
 	mutex_init(&devfreq->lock);
-	mutex_lock(&devfreq->lock);
 	devfreq->dev.parent = dev;
 	devfreq->dev.class = devfreq_class;
 	devfreq->dev.release = devfreq_dev_release;
 	devfreq->profile = profile;
 	strncpy(devfreq->governor_name, governor_name, DEVFREQ_NAME_LEN);
@@ -648,28 +647,24 @@ struct devfreq *devfreq_add_device(struct device *dev,
 	devfreq->last_status.current_frequency = profile->initial_freq;
 	devfreq->data = data;
 	devfreq->nb.notifier_call = devfreq_notifier_call;
 
 	if (!devfreq->profile->max_state && !devfreq->profile->freq_table) {
-		mutex_unlock(&devfreq->lock);
 		err = set_freq_table(devfreq);
 		if (err < 0)
 			goto err_dev;
-		mutex_lock(&devfreq->lock);
 	}
 
 	devfreq->scaling_min_freq = find_available_min_freq(devfreq);
 	if (!devfreq->scaling_min_freq) {
-		mutex_unlock(&devfreq->lock);
 		err = -EINVAL;
 		goto err_dev;
 	}
 	devfreq->min_freq = devfreq->scaling_min_freq;
 
 	devfreq->scaling_max_freq = find_available_max_freq(devfreq);
 	if (!devfreq->scaling_max_freq) {
-		mutex_unlock(&devfreq->lock);
 		err = -EINVAL;
 		goto err_dev;
 	}
 	devfreq->max_freq = devfreq->scaling_max_freq;
 
@@ -678,42 +673,37 @@ struct devfreq *devfreq_add_device(struct device *dev,
 
 	dev_set_name(&devfreq->dev, "devfreq%d",
 				atomic_inc_return(&devfreq_no));
 	err = device_register(&devfreq->dev);
 	if (err) {
-		mutex_unlock(&devfreq->lock);
 		put_device(&devfreq->dev);
 		goto err_out;
 	}
 
 	devfreq->trans_table = devm_kzalloc(&devfreq->dev,
 			array3_size(sizeof(unsigned int),
 				    devfreq->profile->max_state,
 				    devfreq->profile->max_state),
 			GFP_KERNEL);
 	if (!devfreq->trans_table) {
-		mutex_unlock(&devfreq->lock);
 		err = -ENOMEM;
 		goto err_devfreq;
 	}
 
 	devfreq->time_in_state = devm_kcalloc(&devfreq->dev,
 			devfreq->profile->max_state,
 			sizeof(unsigned long),
 			GFP_KERNEL);
 	if (!devfreq->time_in_state) {
-		mutex_unlock(&devfreq->lock);
 		err = -ENOMEM;
 		goto err_devfreq;
 	}
 
 	devfreq->last_stat_updated = jiffies;
 
 	srcu_init_notifier_head(&devfreq->transition_notifier_list);
 
-	mutex_unlock(&devfreq->lock);
-
 	mutex_lock(&devfreq_list_lock);
 
 	governor = try_then_request_governor(devfreq->governor_name);
 	if (IS_ERR(governor)) {
 		dev_err(dev, "%s: Unable to find governor for the device\n",
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel