From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4311E33CEA7; Wed, 13 May 2026 05:09:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778648972; cv=none; b=Wf/f1H1oso7OxOak8b+tJ1ONiSltdxsT6ykeg2lfgGsTB9UYQVN0iqpQQX4Z47yw9JpF5cQaIKrCNWCbDHs/1eVTh3aRAVgFkOGkoaRRIV/ZCSVg9P8C1v8Cb/gYM9WzM/BxPjp+sxMnYDve7WdAlEZoaMwIiocHdr9cL+7oGiE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778648972; c=relaxed/simple; bh=vSpNICj8FRQIEEplzSitQ31XDKoymAyfswGV6NdN8H4=; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Date: Message-Id; b=OVaLTQzIOCugWzHRYwju0MzgbtJa8tEBJfFlaRvgvyAHlSee+sojh+thAKhJPfmR85Gq9/CMi7JB/2kB8J58vdPCwjDxl7087WKDhhGPmpUZ6uI4vDtUCamQXTYRdwHvkTS3VDGnjxJ5VC6zySKl/8D0rTCoVp/XzA0jgqTPYeI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=TnA+kn23; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="TnA+kn23" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BE056C2BCB7; Wed, 13 May 2026 05:09:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1778648971; bh=vSpNICj8FRQIEEplzSitQ31XDKoymAyfswGV6NdN8H4=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date:From; b=TnA+kn23Tskn9jdTf6JaNOmtSa4ZcyDVXVu39JvahSuh8a+7EfknI0Eh118ou/9aV bXWprt+JgzLYqxv7kRmlvPfOkrzLhRAoLzd0aZPT/sFR1UyR8gzJxZ5xklxiJBMXTF FanGiPEi837LDXZBJObxaDKgE34Q6CnVP2ttNa9icNamOLNjgiNl/tCAmZOZ8NNp6e VvI0gVmfSBkG6urFvbhmidgJ2I8IjWpcbmFmuz+FqsWLs9ri8C2nbSYqsFr5oIP0R/ 1zrYgja/oM2igPV8MDSJrhXyKtHQlz/SZ76C7ZEmCF4KnmO4bBmAyMVlwC0TZjk6WZ TzZqisJ58yzCA== From: sashiko-bot@kernel.org Subject: Re: [PATCH V3 05/11] mshv: Implement mshv bridge device for VFIO Reply-To: sashiko-reviews@lists.linux.dev To: "Mukesh R" Cc: linux-hyperv@vger.kernel.org, linux-pci@vger.kernel.org In-Reply-To: <20260512020259.1678627-6-mrathor@linux.microsoft.com> References: <20260512020259.1678627-6-mrathor@linux.microsoft.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Wed, 13 May 2026 05:09:31 +0000 Message-Id: <20260513050931.BE056C2BCB7@smtp.kernel.org> Precedence: bulk X-Mailing-List: linux-pci@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: 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 assert= ion. - [Low] The `mshv_vfio_device_ops` structure is missing the `const` qualifi= er. -- commit 96ab470ecc51b095ed8b1538e4abdf37d030b039 Author: Mukesh R 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 =3D=3D &mshv_vfio_device_ops) > + return -EBUSY; Are we missing a lockdep assertion here to ensure the partition lock is hel= d? 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 =3D { > + .device_name =3D "mshv-vfio", > + .device_create =3D mshv_vfio_create_device, > + .device_release =3D mshv_vfio_release_device, > + .device_set_attr =3D mshv_vfio_set_attr, > + .device_has_attr =3D 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. --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260512020259.1678= 627-1-mrathor@linux.microsoft.com?part=3D5