linux-kernel - Re: [PATCH v4 1/3] iommu: Sort out domain user data

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

Message-ID: <20250307153217.GS354511@nvidia.com>
Date: Fri, 7 Mar 2025 11:32:17 -0400
From: Jason Gunthorpe <jgg@...dia.com>
To: Robin Murphy <robin.murphy@....com>
Cc: Baolu Lu <baolu.lu@...ux.intel.com>, Nicolin Chen <nicolinc@...dia.com>,
	kevin.tian@...el.com, joro@...tes.org, will@...nel.org,
	iommu@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 1/3] iommu: Sort out domain user data

On Fri, Mar 07, 2025 at 11:49:36AM +0000, Robin Murphy wrote:
 
> TBH at this point I view the fault_handler stuff as a legacy interface which
> we don't really want to encourage use of anyway - it's already proven not to
> be great for any true fault handling since many drivers can only call
> report_iommu_fault() in IRQ context. If some new case does come up in future
> where this mutual exclusion gets in the way, I would say that's the point
> where we then look at reworking the whole thing into a dedicated "fault
> notifier" mechanism instead, which could then logically be orthogonal to the
> IOVA-space-owner cookie.

I was under the impression we would go forward with the PRI focused
interface we already have:

	int (*iopf_handler)(struct iopf_group *group);

And this olld iommu_fault_handler_t is just because nobody wanted to
go in any update the old drivers and DRM to use the new scheme?

Is there something fundamental that would prevent iommu drivers from
using the new reporting path?

Jason