linux-kernel - Re: [PATCH] iommu/iova: Fix module config properly

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: <YyRCatyU+CWEcDkt@orome>
Date:   Fri, 16 Sep 2022 11:31:22 +0200
From:   Thierry Reding <thierry.reding@...il.com>
To:     John Garry <john.garry@...wei.com>
Cc:     Robin Murphy <robin.murphy@....com>, joro@...tes.org,
        will@...nel.org, iommu@...ts.linux.dev,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] iommu/iova: Fix module config properly

On Thu, Sep 15, 2022 at 12:45:43PM +0100, John Garry wrote:
> On 14/09/2022 10:47, Thierry Reding wrote:
> > On Tue, Sep 13, 2022 at 03:15:18PM +0100, Robin Murphy wrote:
> > > On 2022-09-13 14:01, John Garry wrote:
> > > > On 13/09/2022 12:47, Robin Murphy wrote:
> > > > > IOMMU_IOVA is intended to be an optional library for users to select as
> > > > > and when they desire. Since it can be a module now, this means that
> > > > > built-in code which has chosen not to select it should not fail to link
> > > > > if it happens to have selected as a module by someone else. Replace
> > > > > IS_ENABLED() with IS_REACHABLE() to do the right thing.
> > > > 
> > > > Hi Robin,
> > > > 
> > > > Recently you mentioned "I wonder if we couldn't replace the IS_ENABLED()
> > > > with IS_REACHABLE() and restore some of the previously-conditional
> > > > selects", and pointed me to 84db889e6d82 as an example of when a
> > > > conditional select was made unconditional.
> > > > 
> > > > So will you also restore some previously-conditional selects next?
> > > 
> > > I figured I'd leave that up to Thierry (and/or anyone else with a vested
> > > interest), but having mulled it over since that previous thread, there's
> > > really no excuse for the API itself not to do the right thing either way, so
> > > I felt compelled to write up this much.
> > 
> > On Tegra specifically, as the commit message says, we don't really care
> > about the conditional selection because practically we always want IOMMU
> > support enabled. So instead of adding back the conditional select it
> > would make more sense to select IOMMU_API instead and then get rid of
> > the handful of #ifdef blocks we have for that.
> 
> Out of curiosity, does the same go to host1x, whose kconfig got the same
> treatment as tegra with regards to selecting IOMMU_IOVA? I mean, will you
> not go back to conditionally selecting IOMMU_IOVA, and instead select
> IOMMU_API and IOMMU_IOVA always?

Yeah, I suspect that that will happen eventually. People would still
have the option of disabling runtime IOMMU support by disabling the
IOMMU via DT, for example, so if they really care about that last bit
of performance, they do have that option.

Thierry

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)