Linux PCI subsystem development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Mukesh R" <mrathor@linux.microsoft.com>
Cc: linux-pci@vger.kernel.org, linux-hyperv@vger.kernel.org
Subject: Re: [PATCH v5 3/9] mshv: Introduce basic mshv bridge device for VFIO to build upon
Date: Fri, 31 Jul 2026 22:49:23 +0000	[thread overview]
Message-ID: <20260731224923.9406A1F00ACA@smtp.kernel.org> (raw)
In-Reply-To: <20260731223427.2554388-4-mrathor@linux.microsoft.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The `mshv_vfio` structure is allocated without `__GFP_ACCOUNT`, allowing a container to allocate kernel memory without being charged to its memory cgroup limit.
--

--- Patch [3]: [PATCH v5 3/9] mshv: Introduce basic mshv bridge device for VFIO to build upon ---
commit c0b4902f22a48f131a914dbd4da4237e2be4826b
Author: Mukesh R <mrathor@linux.microsoft.com>

mshv: Introduce basic mshv bridge device for VFIO to build upon

This commit adds a new file to implement a basic VFIO-MSHV bridge pseudo
device. It provides the foundation for VFIO integration in the MSHV
framework, adapting concepts from the KVM-VFIO bridge.

> diff --git a/drivers/hv/mshv_vfio.c b/drivers/hv/mshv_vfio.c
> new file mode 100644
> index 0000000000000..92cfbaef0328d
> --- /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;
> +
> +	mshv_vfio = kzalloc_obj(*mshv_vfio);

[Severity: Medium]
Should this allocation include __GFP_ACCOUNT?

When a user space process creates a new MSHV VFIO device, it triggers
mshv_vfio_create_device(). The kzalloc_obj() macro defaults to GFP_KERNEL,
which omits the necessary accounting flags.

This allows a container to allocate kernel memory without being charged to
its memory cgroup limit.

> +	if (mshv_vfio == NULL)
> +		return -ENOMEM;
> +
> +	INIT_LIST_HEAD(&mshv_vfio->file_list);
> +	mutex_init(&mshv_vfio->lock);
> +
> +	mshvdev->device_private = mshv_vfio;
> +
> +	return 0;
> +}

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

  reply	other threads:[~2026-07-31 22:49 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-31 22:34 [PATCH v5 0/9] PCI passthru on Hyper-V Mukesh R
2026-07-31 22:34 ` [PATCH v5 1/9] mshv: Provide a way to get partition ID if running in a VMM process Mukesh R
2026-07-31 22:47   ` sashiko-bot
2026-07-31 22:34 ` [PATCH v5 2/9] mshv: Add declarations and definitions for VFIO-MSHV bridge device Mukesh R
2026-07-31 22:42   ` sashiko-bot
2026-07-31 22:34 ` [PATCH v5 3/9] mshv: Introduce basic mshv bridge device for VFIO to build upon Mukesh R
2026-07-31 22:49   ` sashiko-bot [this message]
2026-07-31 22:34 ` [PATCH v5 4/9] mshv: Add ioctl support for MSHV-VFIO bridge device Mukesh R
2026-07-31 22:49   ` sashiko-bot
2026-07-31 22:34 ` [PATCH v5 5/9] mshv: Import data structs around device passthru from hyperv headers Mukesh R
2026-07-31 22:45   ` sashiko-bot
2026-07-31 22:34 ` [PATCH v5 6/9] PCI: hv: Export hv_build_devid_type_pci() and change return type Mukesh R
2026-07-31 22:47   ` sashiko-bot
2026-07-31 22:34 ` [PATCH v5 7/9] x86/hyperv: Implement Hyper-V virtual IOMMU Mukesh R
2026-07-31 22:48   ` sashiko-bot
2026-07-31 22:34 ` [PATCH v5 8/9] mshv: Populate mmio mappings for PCI passthru Mukesh R
2026-07-31 22:54   ` sashiko-bot
2026-07-31 22:34 ` [PATCH v5 9/9] mshv: Disable movable regions upfront if device passthru Mukesh R
2026-07-31 22:57   ` 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=20260731224923.9406A1F00ACA@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox