linux-kernel - Re: [PATCH] Changing the AMD IOMMU API path to work in an atomic context which is necessary for any custom drivers using the IOMMU API while holding a spinlock.

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: <24d3f04a-e6e2-ed8f-e2bd-b38144f33f26@arm.com>
Date:   Fri, 24 Aug 2018 16:24:49 +0100
From:   Robin Murphy <robin.murphy@....com>
To:     Christoph Hellwig <hch@...radead.org>, murphyt7@....ie
Cc:     iommu@...ts.linux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Changing the AMD IOMMU API path to work in an atomic
 context which is necessary for any custom drivers using the IOMMU API while
 holding a spinlock.

On 24/08/18 15:53, Christoph Hellwig wrote:
> On Fri, Aug 24, 2018 at 02:28:49PM +0000, murphyt7@....ie wrote:
>> From: Tom Murphy <murphyt7@....ie>
>>
>> ---
>>
>> This patch allows the IOMMU API path in the AMD driver to be called from an atomic context.
>> This is useful for anyone building a driver which needs to call the IOMMU API while holding a spinlock.
> 
> I don't think that is a good idea.  Please point to the code in the
> driver and we can't probably find a better solution.

Although IIRC the AMD driver is in fact the only one whose map/unmap 
callbacks aren't already spinlock-safe (or at least it was last time I 
was looking). Stuff like iommu-dma is already relying on this in order 
to implement streaming DMA API calls (which may be in atomic context) on 
top of the corresponding IOMMU API operations.

Robin.