From: Alex Williamson <alex.williamson@redhat.com>
To: Reinette Chatre <reinette.chatre@intel.com>
Cc: jgg@nvidia.com, yishaih@nvidia.com,
shameerali.kolothum.thodi@huawei.com, kevin.tian@intel.com,
kvm@vger.kernel.org, dave.jiang@intel.com, ashok.raj@intel.com,
linux-kernel@vger.kernel.org, patches@lists.linux.dev
Subject: Re: [PATCH 03/17] vfio/pci: Consistently acquire mutex for interrupt management
Date: Mon, 5 Feb 2024 15:34:52 -0700 [thread overview]
Message-ID: <20240205153452.4a9bddfd.alex.williamson@redhat.com> (raw)
In-Reply-To: <e7d35d7730f3f83417e757bc264a470f8c2671ed.1706849424.git.reinette.chatre@intel.com>
On Thu, 1 Feb 2024 20:56:57 -0800
Reinette Chatre <reinette.chatre@intel.com> wrote:
> vfio_pci_set_irqs_ioctl() is the entrypoint for interrupt management
> via the VFIO_DEVICE_SET_IRQS ioctl(). The igate mutex is obtained
> before calling vfio_pci_set_irqs_ioctl() for management of all interrupt
> types to protect against concurrent changes to the eventfds associated
> with device request notification and error interrupts.
>
> The igate mutex is not acquired consistently. The mutex is always
> (for all interrupt types) acquired from within vfio_pci_ioctl_set_irqs()
> before calling vfio_pci_set_irqs_ioctl(), but vfio_pci_set_irqs_ioctl() is
> called via vfio_pci_core_disable() without the mutex held. The latter
> is expected to be correct if the code flow can be guaranteed that
> the provided interrupt type is not a device request notification or error
> interrupt.
The latter is correct because it's always a physical interrupt type
(INTx/MSI/MSIX), vdev->irq_type dictates this, and the interrupt code
prevents the handler from being called after the interrupt is disabled.
It's intentional that we don't acquire igate here since we only need to
prevent a race with concurrent user access, which cannot occur in the
fd release path. The igate mutex is acquired consistently, where it's
required.
It would be more forthcoming to describe that potential future emulated
device interrupts don't make the same guarantees, but if that's true,
why can't they?
> Move igate mutex acquire and release into vfio_pci_set_irqs_ioctl()
> to make the locking consistent irrespective of interrupt type.
> This is one step closer to contain the interrupt management locking
> internals within the interrupt management code so that the VFIO PCI
> core can trigger management of the eventfds associated with device
> request notification and error interrupts without needing to access
> and manipulate VFIO interrupt management locks and data.
If all we want to do is move the mutex into vfio_pci_intr.c then we
could rename to __vfio_pci_set_irqs_ioctl() and create a wrapper around
it that grabs the mutex. The disable path could use the lockless
version and we wouldn't need to clutter the exit path unlocking the
mutex as done below. Thanks,
Alex
> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
> ---
> Note to maintainers:
> Originally formed part of the IMS submission below, but is not
> specific to IMS.
> https://lore.kernel.org/lkml/cover.1696609476.git.reinette.chatre@intel.com
>
> drivers/vfio/pci/vfio_pci_core.c | 3 ---
> drivers/vfio/pci/vfio_pci_intrs.c | 10 ++++++++--
> 2 files changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c
> index 1cbc990d42e0..d2847ca2f0cb 100644
> --- a/drivers/vfio/pci/vfio_pci_core.c
> +++ b/drivers/vfio/pci/vfio_pci_core.c
> @@ -1214,12 +1214,9 @@ static int vfio_pci_ioctl_set_irqs(struct vfio_pci_core_device *vdev,
> return PTR_ERR(data);
> }
>
> - mutex_lock(&vdev->igate);
> -
> ret = vfio_pci_set_irqs_ioctl(vdev, hdr.flags, hdr.index, hdr.start,
> hdr.count, data);
>
> - mutex_unlock(&vdev->igate);
> kfree(data);
>
> return ret;
> diff --git a/drivers/vfio/pci/vfio_pci_intrs.c b/drivers/vfio/pci/vfio_pci_intrs.c
> index 69ab11863282..97a3bb22b186 100644
> --- a/drivers/vfio/pci/vfio_pci_intrs.c
> +++ b/drivers/vfio/pci/vfio_pci_intrs.c
> @@ -793,7 +793,9 @@ int vfio_pci_set_irqs_ioctl(struct vfio_pci_core_device *vdev, uint32_t flags,
> int (*func)(struct vfio_pci_core_device *vdev, unsigned int index,
> unsigned int start, unsigned int count, uint32_t flags,
> void *data) = NULL;
> + int ret = -ENOTTY;
>
> + mutex_lock(&vdev->igate);
> switch (index) {
> case VFIO_PCI_INTX_IRQ_INDEX:
> switch (flags & VFIO_IRQ_SET_ACTION_TYPE_MASK) {
> @@ -838,7 +840,11 @@ int vfio_pci_set_irqs_ioctl(struct vfio_pci_core_device *vdev, uint32_t flags,
> }
>
> if (!func)
> - return -ENOTTY;
> + goto out_unlock;
> +
> + ret = func(vdev, index, start, count, flags, data);
> +out_unlock:
> + mutex_unlock(&vdev->igate);
> + return ret;
>
> - return func(vdev, index, start, count, flags, data);
> }
next prev parent reply other threads:[~2024-02-05 22:36 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-02 4:56 [PATCH 00/17] vfio/pci: Remove duplicate code and logic from VFIO PCI interrupt management Reinette Chatre
2024-02-02 4:56 ` [PATCH 01/17] vfio/pci: Use unsigned int instead of unsigned Reinette Chatre
2024-02-02 4:56 ` [PATCH 02/17] vfio/pci: Remove duplicate check from vfio_pci_set_ctx_trigger_single() wrappers Reinette Chatre
2024-02-02 4:56 ` [PATCH 03/17] vfio/pci: Consistently acquire mutex for interrupt management Reinette Chatre
2024-02-05 22:34 ` Alex Williamson [this message]
2024-02-06 21:44 ` Reinette Chatre
2024-02-02 4:56 ` [PATCH 04/17] vfio/pci: Remove duplicate interrupt management from core VFIO PCI Reinette Chatre
2024-02-02 4:56 ` [PATCH 05/17] vfio/pci: Limit eventfd signaling to interrupt management code Reinette Chatre
2024-02-02 4:57 ` [PATCH 06/17] vfio/pci: Remove interrupt index interpretation from wrappers Reinette Chatre
2024-02-05 22:35 ` Alex Williamson
2024-02-06 21:44 ` Reinette Chatre
2024-02-02 4:57 ` [PATCH 07/17] vfio/pci: Preserve per-interrupt contexts Reinette Chatre
2024-02-05 22:35 ` Alex Williamson
2024-02-06 21:45 ` Reinette Chatre
2024-02-06 22:03 ` Alex Williamson
2024-02-06 22:21 ` Reinette Chatre
2024-02-02 4:57 ` [PATCH 08/17] vfio/pci: Extract MSI/MSI-X specific code from common flow Reinette Chatre
2024-02-02 4:57 ` [PATCH 09/17] vfio/pci: Converge similar code flows Reinette Chatre
2024-02-02 4:57 ` [PATCH 10/17] vfio/pci: Extract INTx specific code from vfio_intx_set_signal() Reinette Chatre
2024-02-02 4:57 ` [PATCH 11/17] vfio/pci: Perform MSI/MSI-X interrupt management via callbacks Reinette Chatre
2024-02-02 4:57 ` [PATCH 12/17] vfio/pci: Remove msi term from generic code Reinette Chatre
2024-02-05 22:35 ` Alex Williamson
2024-02-06 21:45 ` Reinette Chatre
2024-02-02 4:57 ` [PATCH 13/17] vfio/pci: Remove vfio_intx_set_signal() Reinette Chatre
2024-02-02 4:57 ` [PATCH 14/17] vfio/pci: Add utility to trigger INTx eventfd knowing interrupt context Reinette Chatre
2024-02-02 4:57 ` [PATCH 15/17] vfio/pci: Let enable and disable of interrupt types use same signature Reinette Chatre
2024-02-05 22:35 ` Alex Williamson
2024-02-06 21:46 ` Reinette Chatre
2024-02-06 22:03 ` Alex Williamson
2024-02-06 22:22 ` Reinette Chatre
2024-02-06 23:19 ` Alex Williamson
2024-02-07 23:30 ` Reinette Chatre
2024-02-08 21:08 ` Alex Williamson
2024-02-14 19:37 ` Reinette Chatre
2024-02-02 4:57 ` [PATCH 16/17] vfio/pci: Move vfio_msi_disable() to be with other MSI/MSI-X management code Reinette Chatre
2024-02-02 4:57 ` [PATCH 17/17] vfio/pci: Remove duplicate interrupt management flow Reinette Chatre
2024-02-05 22:35 ` Alex Williamson
2024-02-06 21:46 ` Reinette Chatre
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=20240205153452.4a9bddfd.alex.williamson@redhat.com \
--to=alex.williamson@redhat.com \
--cc=ashok.raj@intel.com \
--cc=dave.jiang@intel.com \
--cc=jgg@nvidia.com \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=patches@lists.linux.dev \
--cc=reinette.chatre@intel.com \
--cc=shameerali.kolothum.thodi@huawei.com \
--cc=yishaih@nvidia.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;
as well as URLs for NNTP newsgroup(s).