linux-kernel - Re: [PATCH] soc: qcom: mark pd-mapper as broken

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: <Z3z7sHn6yrUvsc6Y@hovoldconsulting.com>
Date: Tue, 7 Jan 2025 11:02:24 +0100
From: Johan Hovold <johan@...nel.org>
To: Frank Oltmanns <frank@...manns.dev>
Cc: Stephan Gerhold <stephan.gerhold@...aro.org>,
	Johan Hovold <johan+linaro@...nel.org>,
	Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
	Bjorn Andersson <andersson@...nel.org>,
	Konrad Dybcio <konradybcio@...nel.org>,
	Chris Lew <quic_clew@...cinc.com>, Abel Vesa <abel.vesa@...aro.org>,
	linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
	regressions@...ts.linux.dev, stable@...r.kernel.org
Subject: Re: [PATCH] soc: qcom: mark pd-mapper as broken

On Mon, Jan 06, 2025 at 08:10:52PM +0100, Frank Oltmanns wrote:
> On 2024-10-11 at 12:01:48 +0200, Stephan Gerhold <stephan.gerhold@...aro.org> wrote:
> > On Thu, Oct 10, 2024 at 09:42:46AM +0200, Johan Hovold wrote:
> >> When using the in-kernel pd-mapper on x1e80100, client drivers often
> >> fail to communicate with the firmware during boot, which specifically
> >> breaks battery and USB-C altmode notifications. This has been observed
> >> to happen on almost every second boot (41%) but likely depends on probe
> >> order:
> >>
> >>     pmic_glink_altmode.pmic_glink_altmode pmic_glink.altmode.0: failed to send altmode request: 0x10 (-125)
> >>     pmic_glink_altmode.pmic_glink_altmode pmic_glink.altmode.0: failed to request altmode notifications: -125
> >>
> >>     ucsi_glink.pmic_glink_ucsi pmic_glink.ucsi.0: failed to send UCSI read request: -125
> >>
> >>     qcom_battmgr.pmic_glink_power_supply pmic_glink.power-supply.0: failed to request power notifications
> >>
> >> In the same setup audio also fails to probe albeit much more rarely:
> >>
> >>     PDR: avs/audio get domain list txn wait failed: -110
> >>     PDR: service lookup for avs/audio failed: -110
> >>
> >> Chris Lew has provided an analysis and is working on a fix for the
> >> ECANCELED (125) errors, but it is not yet clear whether this will also
> >> address the audio regression.
> >>
> >> Even if this was first observed on x1e80100 there is currently no reason
> >> to believe that these issues are specific to that platform.
> >>
> >> Disable the in-kernel pd-mapper for now, and make sure to backport this
> >> to stable to prevent users and distros from migrating away from the
> >> user-space service.
> >>
> >> Fixes: 1ebcde047c54 ("soc: qcom: add pd-mapper implementation")
> >> Cc: stable@...r.kernel.org	# 6.11
> >> Link: https://lore.kernel.org/lkml/Zqet8iInnDhnxkT9@hovoldconsulting.com/
> >> Signed-off-by: Johan Hovold <johan+linaro@...nel.org>
> >> ---
> >>
> >> It's now been over two months since I reported this regression, and even
> >> if we seem to be making some progress on at least some of these issues I
> >> think we need disable the pd-mapper temporarily until the fixes are in
> >> place (e.g. to prevent distros from dropping the user-space service).
> >>
> >
> > This is just a random thought, but I wonder if we could insert a delay
> > somewhere as temporary workaround to make the in-kernel pd-mapper more
> > reliable. I just tried replicating the userspace pd-mapper timing on
> > X1E80100 CRD by:
> >
> >  1. Disabling auto-loading of qcom_pd_mapper
> >     (modprobe.blacklist=qcom_pd_mapper)
> >  2. Adding a systemd service that does nothing except running
> >     "modprobe qcom_pd_mapper" at the same point in time where the
> >     userspace pd-mapper would usually be started.
> 
> Thank you so much for this idea. I'm currently using this workaround on
> my sdm845 device (where the in-kernel pd-mapper is breaking the
> out-of-tree call audio functionality).

Thanks for letting us know that the audio issue affects sdm845 as well
(I don't seem to hit it on sc8280xp and the X13s).

> Is there any work going on on making the timing of the in-kernel
> pd-mapper more reliable?

The ECANCELLED regression has now been fixed, but the audio issue
remains to be addressed (I think Bjorn has done some preliminary
investigation).

There is also a NULL-deref in an MHI path that is triggered by the
in-kernel pd-mapper for which Chris has posted a workaround here:

	https://lore.kernel.org/r/20241104-qrtr_mhi-v1-1-79adf7e3bba5@quicinc.com

Johan