linux-kernel - Re: [PATCH v10 01/16] iommu: Move iommu fault data to linux/iommu.h

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, 25 Jan 2024 19:21:53 +0800
From: Baolu Lu <baolu.lu@...ux.intel.com>
To: Joel Granados <j.granados@...sung.com>
Cc: baolu.lu@...ux.intel.com, Joerg Roedel <joro@...tes.org>,
 Will Deacon <will@...nel.org>, Robin Murphy <robin.murphy@....com>,
 Jason Gunthorpe <jgg@...pe.ca>, Kevin Tian <kevin.tian@...el.com>,
 Jean-Philippe Brucker <jean-philippe@...aro.org>,
 Nicolin Chen <nicolinc@...dia.com>, Yi Liu <yi.l.liu@...el.com>,
 Jacob Pan <jacob.jun.pan@...ux.intel.com>,
 Longfang Liu <liulongfang@...wei.com>, Yan Zhao <yan.y.zhao@...el.com>,
 iommu@...ts.linux.dev, kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
 Jason Gunthorpe <jgg@...dia.com>
Subject: Re: [PATCH v10 01/16] iommu: Move iommu fault data to linux/iommu.h

On 2024/1/25 17:17, Joel Granados wrote:
> On Mon, Jan 22, 2024 at 01:42:53PM +0800, Lu Baolu wrote:
>> The iommu fault data is currently defined in uapi/linux/iommu.h, but is
>> only used inside the iommu subsystem. Move it to linux/iommu.h, where it
>> will be more accessible to kernel drivers.
>>
>> With this done, uapi/linux/iommu.h becomes empty and can be removed from
>> the tree.
> The reason for removing this [1] is that it is only being used by
> internal code in the kernel. What happens with usespace code that have
> used these definitions? Should we deprecate instead of just removing?

The interfaces to deliver I/O page faults to user space have never been
implemented in the Linux kernel before. Therefore, from a uAPI point of
view, this definition is actually dead code.

Best regards,
baolu