linux-hardening - Re: [PATCH v4 1/4] interconnect: qcom: icc-rpmh: Add QoS configuration support

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: <0a58e05a-7bf5-459a-b202-66d88c095b45@linaro.org>
Date: Sat, 13 Apr 2024 21:31:47 +0200
From: Konrad Dybcio <konrad.dybcio@...aro.org>
To: Odelu Kukatla <quic_okukatla@...cinc.com>,
 Bjorn Andersson <andersson@...nel.org>, Georgi Djakov <djakov@...nel.org>,
 Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
 Conor Dooley <conor+dt@...nel.org>
Cc: Kees Cook <keescook@...omium.org>, cros-qcom-dts-watchers@...omium.org,
 "Gustavo A . R . Silva" <gustavoars@...nel.org>,
 linux-arm-msm@...r.kernel.org, linux-pm@...r.kernel.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-hardening@...r.kernel.org, quic_rlaggysh@...cinc.com,
 quic_mdtipton@...cinc.com
Subject: Re: [PATCH v4 1/4] interconnect: qcom: icc-rpmh: Add QoS
 configuration support

On 3.04.2024 10:45 AM, Odelu Kukatla wrote:
> 
> 
> On 3/27/2024 2:26 AM, Konrad Dybcio wrote:
>> On 25.03.2024 7:16 PM, Odelu Kukatla wrote:
>>> It adds QoS support for QNOC device and includes support for
>>> configuring priority, priority forward disable, urgency forwarding.
>>> This helps in priortizing the traffic originating from different
>>> interconnect masters at NoC(Network On Chip).
>>>
>>> Signed-off-by: Odelu Kukatla <quic_okukatla@...cinc.com>
>>> ---

[...]

>>> @@ -70,6 +102,7 @@ struct qcom_icc_node {
>>>  	u64 max_peak[QCOM_ICC_NUM_BUCKETS];
>>>  	struct qcom_icc_bcm *bcms[MAX_BCM_PER_NODE];
>>>  	size_t num_bcms;
>>> +	const struct qcom_icc_qosbox *qosbox;
>>
>> I believe I came up with a better approach for storing this.. see [1]
>>
>> Konrad
>>
>> [1] https://lore.kernel.org/linux-arm-msm/20240326-topic-rpm_icc_qos_cleanup-v1-4-357e736792be@linaro.org/
>>
> 
> I see in this series, QoS parameters are moved into struct qcom_icc_desc. 
> Even though we program QoS at Provider/Bus level, it is property of the node/master connected to a Bus/NoC.

I don't see how it could be the case, we're obviously telling the controller which
endpoints have priority over others, not telling nodes whether the data they
transfer can omit the queue.

> It will be easier later to know which master's QoS we are programming if we add in node data.
> Readability point of view,  it might be good to keep QoS parameters in node data.  

I don't agree here either, with the current approach we've made countless mistakes
when converting the downstream data (I have already submitted some fixes with more
in flight), as there's tons of jumping around the code to find what goes where.

Konrad