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: <198a73b0-d7c0-57d6-5ef9-4e9dddb6365b@arm.com>
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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ