linux-kernel - Re: [PATCH 4/5] iommu: Separate IOVA rcache memories from iova

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] [day] [month] [year] [list]

Date:   Wed, 22 Dec 2021 11:53:11 +0000
From:   John Garry <john.garry@...wei.com>
To:     Robin Murphy <robin.murphy@....com>, <joro@...tes.org>,
        <will@...nel.org>, <mst@...hat.com>, <jasowang@...hat.com>
CC:     <xieyongji@...edance.com>, <linux-kernel@...r.kernel.org>,
        <iommu@...ts.linux-foundation.org>,
        <virtualization@...ts.linux-foundation.org>, <linuxarm@...wei.com>,
        <thunder.leizhen@...wei.com>, <baolu.lu@...ux.intel.com>
Subject: Re: [PATCH 4/5] iommu: Separate IOVA rcache memories from iova_domain
 structure

On 20/12/2021 13:57, Robin Murphy wrote:
>> Do you have any thoughts on this patch? The decision is whether we 
>> stick with a single iova domain structure or support this super 
>> structure for iova domains which support the rcache. I did not try the 
>> former - it would be do-able but I am not sure on how it would look.
> 
> TBH I feel inclined to take the simpler approach of just splitting the 
> rcache array to a separate allocation, making init_iova_rcaches() public 
> (with a proper return value), and tweaking put_iova_domain() to make 
> rcache cleanup conditional. A residual overhead of 3 extra pointers in 
> iova_domain doesn't seem like *too* much for non-DMA-API users to bear. 

OK, fine. So I tried as you suggested and it looks ok to me.

I'll send something out at rc1.

> Unless you want to try generalising the rcache mechanism completely away 
> from IOVA API specifics, it doesn't seem like there's really enough to 
> justify the bother of having its own distinct abstraction layer.

Yeah, I don't see that as necessary.

However something which could be useful is to separate the magazine code 
out for other possible users.

Thanks!
John