All of lore.kernel.org
 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 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.