linux-kernel - Re: [git pull] IOMMU Updates for Linux v6.4

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]

Date:   Fri, 5 May 2023 13:10:30 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Jason Gunthorpe <jgg@...pe.ca>
Cc:     Kevin Tian <kevin.tian@...el.com>, Joerg Roedel <joro@...tes.org>,
        Will Deacon <will@...nel.org>, linux-kernel@...r.kernel.org,
        iommu@...ts.linux.dev
Subject: Re: [git pull] IOMMU Updates for Linux v6.4

On Fri, May 5, 2023 at 12:57 PM Jason Gunthorpe <jgg@...pe.ca> wrote:
>
> At least with the current situation CONFIG_INTEL_ENQCMD might be an
> appropriate name, split out from the IOMMU kconfig and put in arch
> kconfig?

That would at least somewhat clarify the use. I find IOMMU_SVA to be a
particularly opaque name.

Admittedly I probably find it opaque because I come at it as somebody
much more familiar with the MM side, not from the IOMMU side (and the
_other_ conditional fields there make sense from that standpoint), but
even so I think it would be good to clarify.

Of course, making clear it's architecture-specific would also be an
argument for having an actual architecture-specific part of 'struct
mm_struct' (the same way we have 'struct thread_info' in task_struct),
but with only one single field I suspect that's just not worth it.

And who knows - maybe other architectures will pick something like this up?

But yes, it might be good to really pin down what the rules are. Right
now IOMMU_SVA has *no* real help-text (there's a comment saying "#
Shared Virtual Addressing"), and is also enabled by ARM_SMMU_V3_SVA,
which apparently doesn't actually want pasid support at all.

I dunno. I don't think this is a huge deal, but it did cause some
confusion during the merge.

                 Linus