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 <[email protected]> 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/[email protected]?part=3
