linux-kernel - Re: [PATCH v4] iommu: Optimise PCI SAC address trick

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:   Thu, 15 Jun 2023 10:04:47 +0100
From:   Robin Murphy <robin.murphy@....com>
To:     John Garry <john.g.garry@...cle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Joerg Roedel <joro@...tes.org>
Cc:     will@...nel.org, iommu@...ts.linux.dev,
        linux-kernel@...r.kernel.org,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH v4] iommu: Optimise PCI SAC address trick

On 2023-06-15 08:49, John Garry wrote:
> On 13/06/2023 18:58, Jakub Kicinski wrote:
>> On Fri, 14 Apr 2023 13:45:34 +0200 Joerg Roedel wrote:
>>> Thanks for working on this, I think this is good to go. But given the
>>> issues we had with last attempt I'd like to have this in linux-next for
>>> a few weeks before sending it upstream. Therefore I will defer this
>>> patch and merge it early in the next cycle.
>> Is this patch queued up? I don't see it in linux-next and we keep
>> hitting this issue in production. After a few NIC reconfigurations
>> IOMMU starts consuming 90+% of CPU time.
>>
> 
> Since we're at rc6 time and a cautious approach was wanted to merge this 
> change, I doubt that this will be merged for this cycle. That's quite 
> unfortunate.
> 
> Please note what I mentioned earlier about using dma_opt_mapping_size(). 
> This API is used by some block storage drivers to avoid your same 
> problem, by clamping max_sectors_kb at this size - see sysfs-block Doc 
> for info there. Maybe it can be used similarly for network drivers.

It's not the same problem - in this case the mappings are already small 
enough to use the rcaches, and it seems more to do with the total number 
of unusable cached IOVAs being enough to keep the 32-bit space 
almost-but-not-quite full most of the time, defeating the 
max32_alloc_size optimisation whenever the caches run out of the right 
size entries.

The manual workaround for now would be to boot with "iommu.forcedac=1" 
and hope that no other devices break because of it.

Thanks,
Robin.