linux-kernel - Re: [PATCH 5/7] dt-bindings: remoteproc: qcom,pas: Add hwlocks

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: <c9882ba0-bbbf-44ec-9606-ebe68bcb8866@kernel.org>
Date: Tue, 21 May 2024 09:36:03 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Chris Lew <quic_clew@...cinc.com>, Bjorn Andersson
 <andersson@...nel.org>, Baolin Wang <baolin.wang@...ux.alibaba.com>,
 Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...hat.com>,
 Will Deacon <will@...nel.org>, Waiman Long <longman@...hat.com>,
 Boqun Feng <boqun.feng@...il.com>, Jonathan Corbet <corbet@....net>,
 Mathieu Poirier <mathieu.poirier@...aro.org>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>,
 Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>,
 Konrad Dybcio <konrad.dybcio@...aro.org>
Cc: linux-remoteproc@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-doc@...r.kernel.org, linux-arm-msm@...r.kernel.org,
 devicetree@...r.kernel.org
Subject: Re: [PATCH 5/7] dt-bindings: remoteproc: qcom,pas: Add hwlocks

On 21/05/2024 06:08, Chris Lew wrote:
> 
> 
> On 5/19/2024 10:36 AM, Krzysztof Kozlowski wrote:
>> On 17/05/2024 00:58, Chris Lew wrote:
>>> Add hwlocks property to describe the hwspinlock that remoteproc can try
>>> to bust on behalf of the remoteproc's smem.
>>
>> Sorry, as you wrote, the lock is part of smem, not here. Drivers do not
>> crash, so if your crashes as you imply in the cover letter, then first
>> fix the driver.
>>
> 
> Hi Krzysztof,
> 
> Sorry for the confusion, I dont think I meant that the smem driver will 
> ever crash. The referred to crash in the cover letter is a crash in the 
> firmware running on the remoteproc. The remoteproc could crash for any 
> unexpected reason, related or unrelated to smem, while holding the tcsr 
> mutex. I want to ensure that all resources that a remoteproc might be 
> using are released as part of remoteproc stop.
> 
> The SMEM driver manages the lock/unlock operations on the tcsr mutex 
> from the Linux CPU's perspective. This case is for cleaning up from the 
> remote side's perspective.
> 
> In this case it's the hwspinlock used to synchronize SMEM, but it's 
> conceivable that firmware running on the remoteproc has additional locks 
> that need to be busted in order for the system to continue executing 
> until the firmware is reinitialized.
> 
> We did consider tying this to the SMEM instance, but the entitiy 
> relating to firmware is the remoteproc instance.

I still do not understand why you have to add hwlock to remoteproc, even
though it is not directly used. Your driver problem looks like lack of
proper driver architecture - you want to control the locks not from the
layer took the lock, but one layer up. Sorry, no, fix the driver
architecture.

Best regards,
Krzysztof