linux-kernel - Re: [PATCH v4 3/5] thermal: qcom-spmi-temp-alarm: Prepare to support additional Temp Alarm subtypes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4bb5cec9-2c3c-44de-af55-158fadb97acc@linaro.org>
Date: Thu, 29 May 2025 11:48:12 +0100
From: Bryan O'Donoghue <bryan.odonoghue@...aro.org>
To: Anjelique Melendez <anjelique.melendez@....qualcomm.com>,
 amitk@...nel.org, thara.gopinath@...il.com, rafael@...nel.org,
 daniel.lezcano@...aro.org
Cc: rui.zhang@...el.com, lukasz.luba@....com, david.collins@....qualcomm.com,
 srinivas.kandagatla@...aro.org, stefan.schmidt@...aro.org,
 quic_tsoni@...cinc.com, linux-arm-msm@...r.kernel.org,
 linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
 dmitry.baryshkov@...aro.org, dmitry.baryshkov@....qualcomm.com
Subject: Re: [PATCH v4 3/5] thermal: qcom-spmi-temp-alarm: Prepare to support
 additional Temp Alarm subtypes

On 29/05/2025 00:50, Anjelique Melendez wrote:
> @@ -356,16 +378,12 @@ static int qpnp_tm_init(struct qpnp_tm_chip *chip)
> 
>   	mutex_unlock(&chip->lock);
> 
> -	ret = thermal_zone_get_crit_temp(chip->tz_dev, &crit_temp);
> -	if (ret)
> -		crit_temp = THERMAL_TEMP_INVALID;
> +	ret = chip->data->configure_trip_temps(chip);
> +	if (ret < 0)
> +		return ret;
> 
>   	mutex_lock(&chip->lock);

Could we just drop the mutex lock in tm_init ();

probe()
   tm_init();
     mutex_lock();
     do stuff;
     mutex_unlock();
     ->configure_trip_temps();
         mutex_lock();
         do other stuff
         mutex_unlock();
     mutex_lock();
     back to doing stuff in tm_init();
     mutex_unlock();

There's little rationality to tm_init() being a critical section but 
also doing lock/unlock three times inside of that critical section.

Since tm_init() is only called during probe() what exactly is the 
parallel context we are premepting with the lock ?

If we can't answer that question the tm_init() mutex should be dropped.

---
bod