linux-kernel - Re: [PATCH v2 2/8] iommu/arm-smmu-v3: Replace s1_cfg with cdtab

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: <ZMiGs5dR6IKF855y@Asurada-Nvidia>
Date:   Mon, 31 Jul 2023 21:14:43 -0700
From:   Nicolin Chen <nicolinc@...dia.com>
To:     Michael Shavit <mshavit@...gle.com>
CC:     <iommu@...ts.linux.dev>, <linux-arm-kernel@...ts.infradead.org>,
        <linux-kernel@...r.kernel.org>, <will@...nel.org>,
        <robin.murphy@....com>, <jgg@...dia.com>,
        <jean-philippe@...aro.org>
Subject: Re: [PATCH v2 2/8] iommu/arm-smmu-v3: Replace s1_cfg with cdtab_cfg

On Mon, Jul 31, 2023 at 06:48:12PM +0800, Michael Shavit wrote:

> arm_smmu_ctx_desc_cfg is renamed to arm_smmu_cdtab_cfg to make it more

There seems to be no change of renaming "arm_smmu_ctx_desc_cfg" to
"arm_smmu_cdtab_cfg". Even PATCH-8 only renames the local variable
"cdcfg" to "cd_table". Also, we should not use PATCH-8 to justify
this change, because it makes this patch less convincing since the
PATCH-8 might not get applied at all.

> obvious that it represents a cd table. The max number of CDs that can be
> represented by the CD table is stored in this truct in its log2 form
> since it is more useful for users of the CD table, and replaces the
> s1cdmax field in s1_cfg. Instead of storing s1_cfg.s1fmt, it can also be
> trivially computed from the cdtab_cfg, and is therefore removed from
> s1_cfg.

The commit message does not quite well describe why "replace s1_cfg
with cd_table" in the subject. It could mention that the goal here
is to move cdtab to the master structure. And "unwrap s1_cfg" might
be more fitting in the subject, IMHO.

Thanks
Nicolin