linux-kernel - Re: [PATCH v2] thermal: core: Call monitor_thermal

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] [day] [month] [year] [list]
Message-ID: <CAJZ5v0hHV8VfLd7pi2pP2TyJ3ghc0bMnodfVC00kxv6bBTDEfw@mail.gmail.com>
Date: Thu, 4 Jul 2024 11:55:59 +0200
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: neil.armstrong@...aro.org
Cc: Daniel Lezcano <daniel.lezcano@...aro.org>, "Rafael J. Wysocki" <rjw@...ysocki.net>, 
	Linux PM <linux-pm@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>, 
	Lukasz Luba <lukasz.luba@....com>, 
	Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>, Zhang Rui <rui.zhang@...el.com>, 
	linux-arm-msm <linux-arm-msm@...r.kernel.org>
Subject: Re: [PATCH v2] thermal: core: Call monitor_thermal_zone() if zone
 temperature is invalid

On Thu, Jul 4, 2024 at 9:39 AM <neil.armstrong@...aro.org> wrote:
>
> On 03/07/2024 17:12, Daniel Lezcano wrote:
> > On 03/07/2024 16:42, neil.armstrong@...aro.org wrote:
> >> On 03/07/2024 16:00, Daniel Lezcano wrote:
> >>> On 03/07/2024 14:43, neil.armstrong@...aro.org wrote:
> >>>> Hi,
> >>>>
> >>>> On 03/07/2024 14:25, Daniel Lezcano wrote:
> >>>>>
> >>>>> Hi Neil,
> >>>>>
> >>>>> it seems there is something wrong with the driver actually.
> >>>>>
> >>>>> There can be a moment where the sensor is not yet initialized for different reason, so reading the temperature fails. The routine will just retry until the sensor gets ready.
> >>>>>
> >>>>> Having these errors seem to me that the sensor for this specific thermal zone is never ready which may be the root cause of your issue. The change is spotting this problem IMO.
> >>>>
> >>>> Probably, but it gets printed every second until system shutdown, but only for a single thermal_zone.
> >>>>
> >>>> Using v1 of Rafael's patch makes the message disappear completely.
> >>>
> >>> Yes, because you have probably the thermal zone polling delay set to zero, thus it fails the first time and does no longer try to set it up again. The V1 is an incomplete fix.
> >>>
> >>> Very likely the problem is in the sensor platform driver, or in the thermal zone description in the device tree which describes a non functional thermal zone.
> >>>
> >>
> >> It was at 0 but the delay was removed recently:
> >> https://lore.kernel.org/all/20240510-topic-msm-polling-cleanup-v2-0-436ca4218da2@linaro.org/
> >
> > Yes, these changes are because another change did:
> >
> > commit 488164006a281986d95abbc4b26e340c19c4c85b
> > Author: Konrad Dybcio <konrad.dybcio@...aro.org>
> >
> >      thermal/of: Assume polling-delay(-passive) 0 when absent
> >
> > diff --git a/drivers/thermal/thermal_of.c b/drivers/thermal/thermal_of.c
> >
> >> That doesn't explain it because only the last platforms have this error message printed.
> >
> > Let me recap.
> >
> > It has been reported if a thermal-zone with zero delay fails to initialize because the sensor returns an error, then there is no more attempt to initialize it and the thermal zone won't be functional.
> >
> > The provided fix will periodically read the sensor temperature until there is a valid temperature. When there is a valid temperature, then the interrupts are set for the previous and the next temperature thresholds. That leads to the end of the routine of initializing the thermal zone and cancels the timer.
> >
> > The platforms you reported, the delay is zero (before and after the 'polling cleanup').
> >
> > My hypothesis is the following:
> >
> > The thermal-zone29 describes a sensor which does not operate.
> >
> > Before the patch:
> >
> > First attempt to initialize it, the temperature is invalid, then because the delay is zero, the routine stops, and there is no more attempts to initialize it. Nothing will happen to this thermal zone and it will stay stuck silently. So at this point, the thermal zone is broken and you don't notice it.
> >
> > After the patch:
> >
> > The initialization routine is constantly retrying to init the thermal zone.
> >
> > -------------------
> >
> > If you revert the fix and you try to read the thermal zone 29, it should always fail to return an error.
> >
> > If I'm correct, then I suggest to identify what thermal zone is 29 (type file), identify the node name in the DT, find the tsens channel and double check if it really describes an existing sensor
> >
> >
> >
> OK I just found out, it's the `qcom-battmgr-bat` thermal zone, and in CI we do not have the firmwares so the
> temperature is never available, this is why it fails in a loop.
>
> Before this patch it would fail silently, but would be useless if we start the firmware too late.
>
> So since it's firmware based, valid data could arrive very late in the boot stage, and sending an
> error message in a loop until the firmware isn't started doesn't seem right.
>
> I think Rafael's new patch is good, but perhaps it should send an error when it finally stops monitoring.

Do you mean do something in addition to printing the message?  It can
do a couple of things.  For instance, it could disable the thermal
zone which would also cause a netlink message to be sent.  However,
I'd rather send another patch for this for the next cycle because we
are late in the current one and I'd rather stay on the conservative
side of things ATM.

Or do you mean the pr_info() log level is too low for this message?

Anyway, I'm going to submit the patch officially as is and please feel
free to send comments on that submission.