From: Reinette Chatre <reinette.chatre@intel.com>
To: Alex Williamson <alex.williamson@redhat.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 15/17] vfio/pci: Let enable and disable of interrupt types use same signature
Date: Wed, 14 Feb 2024 11:37:05 -0800 [thread overview]
Message-ID: <51e67264-27f5-4b66-8a08-eda47000bf9b@intel.com> (raw)
In-Reply-To: <20240208140836.76a212d3.alex.williamson@redhat.com>
Hi Alex,
Apologies for the delay. This was due to two parts:
* I studied these code paths more and I think there may be one more
flow that can be made more robust (more later),
* I spent a lot of time trying to trigger all the affected code paths but
here I did not have much luck. I would prefer to run tests that trigger
these flows so that I can get some help from the kernel lock debugging.
From what I can tell the irqfd flows can be triggered with the help of the
kernel-irqchip option to Qemu but on the hardware I have access to I
could only try kernel-irqchip=auto and that did not trigger the flows
(the irqfd is set up but the eventfd is never signaled).
I am not familiar with this area, do you perhaps have guidance on how
I can test these flows or do you perhaps have access to needed environments
to test this?
On 2/8/2024 1:08 PM, Alex Williamson wrote:
> On Wed, 7 Feb 2024 15:30:15 -0800
> Reinette Chatre <reinette.chatre@intel.com> wrote:
>> I studied the code more and have one more observation related to this portion
>> of the flow:
>> From what I can tell this change makes the INTx code more robust. If I
>> understand current implementation correctly it seems possible to enable
>> INTx but not have interrupt allocated. In this case the interrupt context
>> (ctx) will exist but ctx->trigger will be NULL. Current
>> vfio_pci_set_intx_trigger()->vfio_send_intx_eventfd() only checks if
>> ctx is valid. It looks like it may call eventfd_signal(NULL) where
>> pointer is dereferenced.
>>
>> If this is correct then I think a separate fix that can easily be
>> backported may be needed. Something like:
>
> Good find. I think it's a bit more complicated though. There are
> several paths to vfio_send_intx_eventfd:
>
> - vfio_intx_handler
>
> This can only be called between request_irq() and free_irq()
> where trigger is always valid. igate is not held.
>
> - vfio_pci_intx_unmask
>
> Callers hold igate, additional test of ctx->trigger makes this
> safe.
Two callers of vfio_pci_intx_unmask() do not seem to hold igate:
vfio_basic_config_write() and vfio_pci_core_runtime_resume().
Considering this I wonder if we could add something like below to the
solution you propose. On a high level the outside callers (VFIO PCI core)
will keep using vfio_pci_intx_unmask() that will now take igate while
the interrupt management code gets a new internal __vfio_pci_intx_unmask()
that should be called with igate held. This results in:
@@ -215,12 +223,20 @@ static int vfio_pci_intx_unmask_handler_virqfd(void *opaque, void *unused)
return ret;
}
-void vfio_pci_intx_unmask(struct vfio_pci_core_device *vdev)
+static void __vfio_pci_intx_unmask(struct vfio_pci_core_device *vdev)
{
+ lockdep_assert_held(&vdev->igate);
if (vfio_pci_intx_unmask_handler(vdev, NULL) > 0)
vfio_send_intx_eventfd(vdev, NULL);
}
+void vfio_pci_intx_unmask(struct vfio_pci_core_device *vdev)
+{
+ mutex_lock(&vdev->igate);
+ __vfio_pci_intx_unmask(vdev);
+ mutex_unlock(&vdev->igate);
+}
+
static irqreturn_t vfio_intx_handler(int irq, void *dev_id)
{
struct vfio_pci_core_device *vdev = dev_id;
@@ -581,11 +597,11 @@ static int vfio_pci_set_intx_unmask(struct vfio_pci_core_device *vdev,
return -EINVAL;
if (flags & VFIO_IRQ_SET_DATA_NONE) {
- vfio_pci_intx_unmask(vdev);
+ __vfio_pci_intx_unmask(vdev);
} else if (flags & VFIO_IRQ_SET_DATA_BOOL) {
uint8_t unmask = *(uint8_t *)data;
if (unmask)
- vfio_pci_intx_unmask(vdev);
+ __vfio_pci_intx_unmask(vdev);
} else if (flags & VFIO_IRQ_SET_DATA_EVENTFD) {
struct vfio_pci_irq_ctx *ctx = vfio_irq_ctx_get(vdev, 0);
int32_t fd = *(int32_t *)data;
>
> - vfio_pci_set_intx_trigger
>
> Same as above.
>
> - Through unmask eventfd (virqfd)
>
> Here be dragons.
>
> In the virqfd case, a write to the eventfd calls virqfd_wakeup() where
> we'll call the handler, vfio_pci_intx_unmask_handler(), and based on
> the result schedule the thread, vfio_send_intx_eventfd(). Both of
> these look suspicious. They're not called under igate, so testing
> ctx->trigger doesn't resolve the race.
>
> I think an option is to wrap the virqfd entry points in igate where we
> can then do something similar to your suggestion. I don't think we
> want to WARN_ON(!ctx->trigger) because that's then a user reachable
> condition. Instead we can just quietly follow the same exit paths.
>
> I think that means we end up with something like this:
>
> diff --git a/drivers/vfio/pci/vfio_pci_intrs.c b/drivers/vfio/pci/vfio_pci_intrs.c
> index 237beac83809..ace7e1dbc607 100644
> --- a/drivers/vfio/pci/vfio_pci_intrs.c
> +++ b/drivers/vfio/pci/vfio_pci_intrs.c
> @@ -92,12 +92,21 @@ static void vfio_send_intx_eventfd(void *opaque, void *unused)
> struct vfio_pci_irq_ctx *ctx;
>
> ctx = vfio_irq_ctx_get(vdev, 0);
> - if (WARN_ON_ONCE(!ctx))
> + if (WARN_ON_ONCE(!ctx) || !ctx->trigger)
> return;
> eventfd_signal(ctx->trigger);
> }
> }
>
> +static void vfio_send_intx_eventfd_virqfd(void *opaque, void *unused)
> +{
> + struct vfio_pci_core_device *vdev = opaque;
> +
> + mutex_lock(&vdev->igate);
> + vfio_send_intx_eventfd(opaque, unused);
> + mutex_unlock(&vdev->igate);
> +}
> +
> /* Returns true if the INTx vfio_pci_irq_ctx.masked value is changed. */
> bool vfio_pci_intx_mask(struct vfio_pci_core_device *vdev)
> {
> @@ -170,7 +179,7 @@ static int vfio_pci_intx_unmask_handler(void *opaque, void *unused)
> }
>
> ctx = vfio_irq_ctx_get(vdev, 0);
> - if (WARN_ON_ONCE(!ctx))
> + if (WARN_ON_ONCE(!ctx) || !ctx->trigger)
> goto out_unlock;
>
> if (ctx->masked && !vdev->virq_disabled) {
> @@ -194,6 +203,18 @@ static int vfio_pci_intx_unmask_handler(void *opaque, void *unused)
> return ret;
> }
>
> +static int vfio_pci_intx_unmask_handler_virqfd(void *opaque, void *unused)
> +{
> + struct vfio_pci_core_device *vdev = opaque;
> + int ret;
> +
> + mutex_lock(&vdev->igate);
> + ret = vfio_pci_intx_unmask_handler(opaque, unused);
> + mutex_unlock(&vdev->igate);
> +
> + return ret;
> +}
> +
> void vfio_pci_intx_unmask(struct vfio_pci_core_device *vdev)
> {
> if (vfio_pci_intx_unmask_handler(vdev, NULL) > 0)
> @@ -572,10 +593,10 @@ static int vfio_pci_set_intx_unmask(struct vfio_pci_core_device *vdev,
> if (WARN_ON_ONCE(!ctx))
> return -EINVAL;
> if (fd >= 0)
> - return vfio_virqfd_enable((void *) vdev,
> - vfio_pci_intx_unmask_handler,
> - vfio_send_intx_eventfd, NULL,
> - &ctx->unmask, fd);
> + return vfio_virqfd_enable((void *)vdev,
> + vfio_pci_intx_unmask_handler_virqfd,
> + vfio_send_intx_eventfd_virqfd, NULL,
> + &ctx->unmask, fd);
>
> vfio_virqfd_disable(&ctx->unmask);
> }
>
>
> WDYT?
This looks good to me. Thank you very much for taking the time to
write it.
Reinette
next prev parent reply other threads:[~2024-02-14 19:37 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
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 [this message]
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=51e67264-27f5-4b66-8a08-eda47000bf9b@intel.com \
--to=reinette.chatre@intel.com \
--cc=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=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
Powered by JetHome