linux-kernel - Re: [PATCH] iommu/dma: Resurrect the "forcedac" option

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1f7198b6-bbed-1494-19ee-3453217d12a6@huawei.com>
Date:   Mon, 8 Mar 2021 14:54:11 +0000
From:   John Garry <john.garry@...wei.com>
To:     Robin Murphy <robin.murphy@....com>, <joro@...tes.org>
CC:     <iommu@...ts.linux-foundation.org>, <dwmw2@...radead.org>,
        <baolu.lu@...ux.intel.com>, <murphyt7@....ie>,
        <thunder.leizhen@...wei.com>, <will@...nel.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] iommu/dma: Resurrect the "forcedac" option

On 08/03/2021 13:08, Robin Murphy wrote:
> On 2021-03-05 17:41, John Garry wrote:
>> On 05/03/2021 16:32, Robin Murphy wrote:
>>> In converting intel-iommu over to the common IOMMU DMA ops, it quietly
>>> lost the functionality of its "forcedac" option. Since this is a handy
>>> thing both for testing and for performance optimisation on certain
>>> platforms, reimplement it under the common IOMMU parameter namespace.
>>>
>>> For the sake of fixing the inadvertent breakage of the Intel-specific
>>> parameter, remove the dmar_forcedac remnants and hook it up as an alias
>>> while documenting the transition to the new common parameter.
>>>
>>
>> Do you think that having a kconfig option to control the default for 
>> this can help identify the broken platforms which rely on forcedac=0? 
>> But seems a bit trivial for that, though.
> 
> I think it's still a sizeable can of worms - unlike, say, 
> ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT, we can't actually tell when things 
> have gone awry and explicitly call it out. While I was getting the 
> dma-ranges right on my Juno, everything broke differently - the SATA 
> controller fails gracefully; the ethernet controller got the kernel tied 
> up somewhere (to the point that the USB keyboard died) once it tried to 
> brink up the link, but was at least spewing regular timeout backtraces 
> that implicated the networking layer; having an (unused) NVMe plugged in 
> simply wedged the boot process early on with no hint whatsoever of why.
> 
> TBH I'm not really sure what the best way forward is in terms of trying 
> to weed out platforms that would need quirking.

I was more thinking of an unstable TEST config, like 
DEBUG_TEST_DRIVER_REMOVE. So we know that this particular config breaks 
many platforms. But at least those in the know can turn it on locally 
and detect and fix issues, and strive towards having a platform for 
which it works.

But then it does become a little harder to justify such a config when we 
can enable via commadline.

> Our discussion just 
> reminded me of this option and that it had gone AWOL, so bringing it 
> back to be potentially *some* use to everyone seems justifiable on its own.

Of course.

Cheers,
John