public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Yi Liu <yi.l.liu@intel.com>
To: Yan Zhao <yan.y.zhao@intel.com>
Cc: Jason Gunthorpe <jgg@nvidia.com>,
	"Tian, Kevin" <kevin.tian@intel.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"alex.williamson@redhat.com" <alex.williamson@redhat.com>,
	"peterx@redhat.com" <peterx@redhat.com>,
	"ajones@ventanamicro.com" <ajones@ventanamicro.com>
Subject: Re: [PATCH] vfio: Reuse file f_inode as vfio device inode
Date: Sun, 30 Jun 2024 15:06:05 +0800	[thread overview]
Message-ID: <f588f627-2593-4e89-ae13-df9bb64143c4@intel.com> (raw)
In-Reply-To: <Zn7WofbKsjhlN41U@yzhao56-desk.sh.intel.com>

On 2024/6/28 23:28, Yan Zhao wrote:
> On Fri, Jun 28, 2024 at 05:48:11PM +0800, Yi Liu wrote:
>> On 2024/6/28 13:21, Yan Zhao wrote:
>>> On Thu, Jun 27, 2024 at 09:42:09AM -0300, Jason Gunthorpe wrote:
>>>> On Thu, Jun 27, 2024 at 05:51:01PM +0800, Yan Zhao wrote:
>>>>
>>>>>>>> This doesn't seem right.. There is only one device but multiple file
>>>>>>>> can be opened on that device.
>>>>> Maybe we can put this assignment to vfio_df_ioctl_bind_iommufd() after
>>>>> vfio_df_open() makes sure device->open_count is 1.
>>>>
>>>> Yeah, that seems better.
>>>>
>>>> Logically it would be best if all places set the inode once the
>>>> inode/FD has been made to be the one and only way to access it.
>>> For group path, I'm afraid there's no such a place ensuring only one active fd
>>> in kernel.
>>> I tried modifying QEMU to allow two openings and two assignments of the same
>>> device. It works and appears to guest that there were 2 devices, though this
>>> ultimately leads to device malfunctions in guest.
>>>
>>>>> BTW, in group path, what's the benefit of allowing multiple open of device?
>>>>
>>>> I don't know, the thing that opened the first FD can just dup it, no
>>>> idea why two different FDs would be useful. It is something we removed
>>>> in the cdev flow
>>>>
>>> Thanks. However, from the code, it reads like a drawback of the cdev flow :)
>>> I don't understand why the group path is secure though.
>>>
>>>           /*
>>>            * Only the group path allows the device to be opened multiple
>>>            * times.  The device cdev path doesn't have a secure way for it.
>>>            */
>>>           if (device->open_count != 0 && !df->group)
>>>                   return -EINVAL;
>>>
>>>
>>
>> The group path only allow single group open, so the device FDs retrieved
>> via the group is just within the opener of the group. This secure is built
>> on top of single open of group.
> What if the group is opened for only once but VFIO_GROUP_GET_DEVICE_FD
> ioctl is called for multiple times?

this should happen within the process context that has opened the group. it
should be safe, and that would be tracked by the open_count.

-- 
Regards,
Yi Liu

  reply	other threads:[~2024-06-30  7:02 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-17  9:53 [PATCH] vfio: Reuse file f_inode as vfio device inode Yan Zhao
2024-06-20 10:14 ` Yan Zhao
2024-06-26  8:36   ` Tian, Kevin
2024-06-26  9:11     ` Yan Zhao
2024-06-26 13:35 ` Jason Gunthorpe
2024-06-26 23:55   ` Tian, Kevin
2024-06-27 12:26     ` Jason Gunthorpe
2024-06-27  0:17   ` Tian, Kevin
2024-06-27  9:51     ` Yan Zhao
2024-06-27 12:42       ` Jason Gunthorpe
2024-06-28  5:21         ` Yan Zhao
2024-06-28  9:48           ` Yi Liu
2024-06-28 15:28             ` Yan Zhao
2024-06-30  7:06               ` Yi Liu [this message]
2024-07-01  1:47                 ` Yan Zhao
2024-07-01  5:44                   ` Yi Liu
2024-07-01  5:48                     ` Yan Zhao
2024-07-10 14:40                       ` Jason Gunthorpe
2024-07-12  5:19                         ` Yan Zhao
2024-07-12  6:14                           ` Yi Liu
2024-07-01  7:54 ` Yi Liu
2024-07-01 11:29   ` Yan Zhao

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f588f627-2593-4e89-ae13-df9bb64143c4@intel.com \
    --to=yi.l.liu@intel.com \
    --cc=ajones@ventanamicro.com \
    --cc=alex.williamson@redhat.com \
    --cc=jgg@nvidia.com \
    --cc=kevin.tian@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterx@redhat.com \
    --cc=yan.y.zhao@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox