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
| ||
|
Message-ID: <9b406a7c-57b8-4b5f-8fbc-714560cce8cf@quicinc.com> Date: Fri, 17 Nov 2023 10:57:19 +0530 From: Bibek Kumar Patro <quic_bibekkum@...cinc.com> To: Robin Murphy <robin.murphy@....com>, <will@...nel.org>, <joro@...tes.org>, <dmitry.baryshkov@...aro.org>, <a39.skl@...il.com>, <konrad.dybcio@...aro.org>, <quic_pkondeti@...cinc.com>, <quic_molvera@...cinc.com> CC: <linux-arm-msm@...r.kernel.org>, <linux-arm-kernel@...ts.infradead.org>, <iommu@...ts.linux.dev>, <linux-kernel@...r.kernel.org>, <qipl.kernel.upstream@...cinc.com> Subject: Re: [PATCH v2 1/3] iommu/arm-smmu: introduction of ACTLR for custom prefetcher settings On 11/15/2023 8:23 PM, Robin Murphy wrote: > On 2023-11-15 1:54 pm, Bibek Kumar Patro wrote: >> >>>> @@ -467,6 +505,9 @@ static struct arm_smmu_device >>>> *qcom_smmu_create(struct arm_smmu_device *smmu, >>>> qsmmu->smmu.impl = impl; >>>> qsmmu->cfg = data->cfg; >>>> >>>> + if (data->actlrcfg && (data->actlrcfg->size)) >>>> + qsmmu->actlrcfg = data->actlrcfg; >>> >>> Do we really need to replicate multiple parts of the data, or would >>> it be sensible to just replace qsmmu->cfg with qsmmu->data and handle >>> the further dereferences in the places that want them? >>> >> >> Mm, could not understand this properly. :( Could you help explain more >> please? >> As per my understanding aren't data and qsmmu different structures. >> qcom_smmu is a superset of arm_smmu housing additonal properties >> and qcom_smmu_match_data is kind of a superset of arm_smmu_impl with >> additional specific implmentations, so both needs to be in place? >> Apologies if I understood your statement incorrectly. > > My point is that the data is static and constant, so there's really no > point storing multiple pointers into different bits of it. So rather than: > > qsmmu->cfg = data->cfg; > qssmu->actlrcfg = data->actlrcfg; > ... > do_something(qsmmu->cfg); > ... > do_other_thing(qsmmu->actlrcfg); > > we can just store the one pointer and have: > > qsmmu->data = data; > ... > do_something(qsmmu->data->cfg); > ... > do_other_thing(qsmmu->data->actlrcfg); > > Thanks, > Robin. > I see, this looks like probably we need a separate patch altogether for this cleanup, as "cfg" is used in other fault handling places as well as i can see and is introduced as a part of different patch. Should we scope this work for a separate patch if it's okay? Thanks, Bibek >>>> + >>>> return &qsmmu->smmu; >>>> } >>>> >>>> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h >>>> b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h >>>> index 593910567b88..4b6862715070 100644 >>>> --- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h >>>> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h >>>> @@ -9,6 +9,7 @@ >>>> struct qcom_smmu { >>>> struct arm_smmu_device smmu; >>>> const struct qcom_smmu_config *cfg; >>>> + const struct actlr_config *actlrcfg; >>>> bool bypass_quirk; >>>> u8 bypass_cbndx; >>>> u32 stall_enabled; >>>> @@ -25,6 +26,7 @@ struct qcom_smmu_config { >>>> }; >>>>
Powered by blists - more mailing lists