All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Mukesh R" <mrathor@linux.microsoft.com>
Cc: linux-hyperv@vger.kernel.org, linux-pci@vger.kernel.org
Subject: Re: [PATCH V3 05/11] mshv: Implement mshv bridge device for VFIO
Date: Wed, 13 May 2026 05:09:31 +0000	[thread overview]
Message-ID: <20260513050931.BE056C2BCB7@smtp.kernel.org> (raw)
In-Reply-To: <20260512020259.1678627-6-mrathor@linux.microsoft.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Unprotected access to `pt_devices` list and missing lockdep assertion.
- [Low] The `mshv_vfio_device_ops` structure is missing the `const` qualifier.
--

commit 96ab470ecc51b095ed8b1538e4abdf37d030b039
Author: Mukesh R <mrathor@linux.microsoft.com>
Subject: mshv: Implement mshv bridge device for VFIO

This commit introduces a new VFIO-MSHV bridge pseudo device file, adapted
from KVM's VFIO bridge. It provides the necessary device operations to link
VFIO files with an MSHV partition.

> diff --git a/drivers/hv/mshv_vfio.c b/drivers/hv/mshv_vfio.c
> new file mode 100644
> index 0000000000000..00a97920e25ba
> --- /dev/null
> +++ b/drivers/hv/mshv_vfio.c
[ ... ]
> +static long mshv_vfio_create_device(struct mshv_device *mshvdev)
> +{
> +	struct mshv_device *tmp;
> +	struct mshv_vfio *mshv_vfio;
> +
> +	/* Only one VFIO "device" per VM */
> +	hlist_for_each_entry(tmp, &mshvdev->device_pt->pt_devices,
> +			     device_ptnode)
> +		if (tmp->device_ops == &mshv_vfio_device_ops)
> +			return -EBUSY;

Are we missing a lockdep assertion here to ensure the partition lock is held?

Since this iterates over the pt_devices list to enforce a singleton device,
could concurrent ioctl calls bypass this check and corrupt the hlist if the
caller doesn't acquire the lock?

[ ... ]

> +struct mshv_device_ops mshv_vfio_device_ops = {
> +	.device_name = "mshv-vfio",
> +	.device_create = mshv_vfio_create_device,
> +	.device_release = mshv_vfio_release_device,
> +	.device_set_attr = mshv_vfio_set_attr,
> +	.device_has_attr = mshv_vfio_has_attr,
> +};

Should mshv_vfio_device_ops be declared as const?

The structure consists entirely of function pointers and is never modified
after initialization. Making it const would place it in read-only memory.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260512020259.1678627-1-mrathor@linux.microsoft.com?part=5

  reply	other threads:[~2026-05-13  5:09 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-12  2:02 [PATCH V3 00/11] PCI passthru on Hyper-V (Part I) Mukesh R
2026-05-12  2:02 ` [PATCH V3 01/11] iommu/hyperv: Rename hyperv-iommu.c to hyperv-irq.c Mukesh R
2026-05-12 10:26   ` Souradeep Chakrabarti
2026-05-12 23:46   ` Jacob Pan
2026-05-13  1:31     ` Mukesh R
2026-05-13  3:15     ` Michael Kelley
2026-05-15 13:58       ` Yu Zhang
2026-05-12  2:02 ` [PATCH V3 02/11] x86/hyperv: Cosmetic changes in irqdomain.c for readability Mukesh R
2026-05-12 10:27   ` Souradeep Chakrabarti
2026-05-13  3:26   ` sashiko-bot
2026-05-12  2:02 ` [PATCH V3 03/11] mshv: Provide a way to get partition ID if running in a VMM process Mukesh R
2026-05-13  3:47   ` sashiko-bot
2026-05-12  2:02 ` [PATCH V3 04/11] mshv: Declarations and definitions for VFIO-MSHV bridge device Mukesh R
2026-05-12 10:26   ` Souradeep Chakrabarti
2026-05-12  2:02 ` [PATCH V3 05/11] mshv: Implement mshv bridge device for VFIO Mukesh R
2026-05-13  5:09   ` sashiko-bot [this message]
2026-05-12  2:02 ` [PATCH V3 06/11] mshv: Add ioctl support for MSHV-VFIO bridge device Mukesh R
2026-05-13  5:27   ` sashiko-bot
2026-05-12  2:02 ` [PATCH V3 07/11] mshv: Import data structs around device passthru from hyperv headers Mukesh R
2026-05-12  2:02 ` [PATCH V3 08/11] PCI: hv: VMBus and PCI device IDs for PCI passthru Mukesh R
2026-05-12 17:41   ` Bjorn Helgaas
2026-05-13  6:43   ` sashiko-bot
2026-05-13 15:08   ` Souradeep Chakrabarti
2026-05-13 15:17     ` Souradeep Chakrabarti
2026-05-12  2:02 ` [PATCH V3 09/11] x86/hyperv: Implement Hyper-V virtual IOMMU Mukesh R
2026-05-13 12:41   ` sashiko-bot
2026-05-15 18:23   ` Jason Gunthorpe
2026-05-12  2:02 ` [PATCH V3 10/11] mshv: Populate mmio mappings for PCI passthru Mukesh R
2026-05-13 19:23   ` sashiko-bot
2026-05-12  2:02 ` [PATCH V3 11/11] mshv: Mark mem regions as non-movable upfront if device passthru Mukesh R
2026-05-13 20:00   ` sashiko-bot

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=20260513050931.BE056C2BCB7@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-hyperv@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mrathor@linux.microsoft.com \
    --cc=sashiko-reviews@lists.linux.dev \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.