linux-kernel - Re: [PATCH] vfio/pci: print vfio-device name to fdinfo

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: <20250624005605.GA72557@ziepe.ca>
Date: Mon, 23 Jun 2025 21:56:05 -0300
From: Jason Gunthorpe <jgg@...pe.ca>
To: Alex Williamson <alex.williamson@...hat.com>
Cc: Alex Mastro <amastro@...com>, peterx@...hat.com, kbusch@...nel.org,
	kvm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] vfio/pci: print vfio-device name to fdinfo

On Mon, Jun 23, 2025 at 04:18:31PM -0600, Alex Williamson wrote:
> > Alternatively, if we wanted to normalize show_fdinfo formatting, this
> > could instead hoist the print formatting up into vfio_main.c, and call
> > an optional vfio_device_ops->instance_name() to get the name. I opted
> > not to do this here due to unfamiliarity with other vfio drivers, but am
> > open to changing it.
> 
> TBH, I don't think we need a callback, just use dev_name() in
> vfio_main.

IMHO this should really be the name of /dev/vfio/XX file and not
something made up like event fd uses.

The file was opened via /dev/vfio/XX, that is what lsof should report..

For the legacy route this effectively gives you the iommu group.

For the new route this will give you the struct device.

The userspace can deduce more information, like the actual PCI BDF, by
mapping the name through sysfs.

I would have guessed this is already happening automatically as part
of the cdev mechanism? Maybe we broken it when we changed the inode to
use unmap mapping range?

> The group interface always requires the name, in some cases
> it can require further information, but we seem to have forgotten that
> in the cdev interface anyway :-\

?

Jason