linux-kernel - Re: [PATCH 0/4] firmware: arm_scmi: Add xfer inflight debug and trace

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: <20250630020036.GA13878@nxa18884-linux>
Date: Mon, 30 Jun 2025 10:00:36 +0800
From: Peng Fan <peng.fan@....nxp.com>
To: Cristian Marussi <cristian.marussi@....com>
Cc: Philip Radford <Philip.Radford@....com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>,
	"arm-scmi@...r.kernel.org" <arm-scmi@...r.kernel.org>,
	Sudeep Holla <Sudeep.Holla@....com>,
	Luke Parkin <Luke.Parkin@....com>
Subject: Re: [PATCH 0/4] firmware: arm_scmi: Add xfer inflight debug and trace

Hi Cristian,

On Thu, Jun 26, 2025 at 12:37:49PM +0100, Cristian Marussi wrote:
>> > Just a general question, is this counter count in flight messages
>> > for a scmi instance or it is per transport? I ask because
>> > one scmi instance could have multiple mailboxes. If counting based
>> > on scmi instance, it may not be that accurate.
>> > 
>
>... so that is a good point ...
>...thanks Peng for pointing out this first of all...
>
>So, in general all of these counters are per-instance, we don't have any
>finer per-channel granularity....we could in the future split them out
>to be per-channel counters, but I wonder if it would be worth the
>effort: because, as I see it, errors reported by these counters are more
>of a alarm-bell than a triage tool, in the sense that I would expect
>that seeing a lot of errors of some kind on an instance should just act
>as a warning that something is NOT right somewhere, so that you can
>investigate further by enabling the already existent and more comprehensive
>SCMI trace events to fully inveestigate the problem...since SCMI full event
>traces DO also include the used-channel beside a lot of other info about
>the xfer transactions.
>
>Moreover, in the specific case of tracking inflight xfers, note that
>the counter added in this series tracks the pool of xfers allocated in
>tx_minfo(A2P) free-lists (i.e. commands...P2A msgs hardly can be lost),
>BUT this structure is per-instance (NOT per-channel), so even if you had
>say a few more dedicated per-protocol channels defined on a system,
>all the A2P transactions will pick their xfers from the same per-instance
>pool... (..because the max_inflights is meant to cap the maximum number
>of outstanding transactions that the server has to cope with...)

Thanks for explaining this. It is clear that there is no need finer
granularity. Just leave as it is.

Thanks,
Peng

>
>Thanks,
>Cristian