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 AE1043DDDA3; Mon, 30 Mar 2026 17:38:52 +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=1774892332; cv=none; b=LkbEgkd3oYeTgAdP3a+TledJGBDEkkFkdCC3u0LX6FiMRENwPCI1wr/g0VlHl6HEonO7NJKpASu1Rpf0jClPjD/r8w05Ih95V9hzZ/DjI9+yxSRUgR/iTxwGNpYhAkHwySHaoJdyEiIJycbXYkB9CH0cIQZndNAhjkLypOR+RS8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774892332; c=relaxed/simple; bh=/8RwifExta3hi9wb0UAvoCzja5DI/LlE9XUZDEKtDlU=; h=Content-Type:Date:Message-Id:From:Subject:Cc:To:Mime-Version: References:In-Reply-To; b=SD8/xN6VvQvaqrPz4qfgFA7f66EYFReohMjCkweFjH6MvN3fnm090XKAjsbU3JPrdnHUPk+NJ79ISrUX+5fuZMtNyd2BaYa5JuSOgsiIL6QsTw4+A5K57JMivfJlh2eXmh1HXIEnwOKknpQKb7Gj4xj90Bg3eU+1OtFq9Vk1KiA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=S56YWHrx; 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="S56YWHrx" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 39967C2BCB5; Mon, 30 Mar 2026 17:38:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1774892332; bh=/8RwifExta3hi9wb0UAvoCzja5DI/LlE9XUZDEKtDlU=; h=Date:From:Subject:Cc:To:References:In-Reply-To:From; b=S56YWHrxhwHLS+EfSzEoW6H9YreN8wrQZ/7HEDAWqAjDAvn6rNoi6jXsbwo3fyTXv TjHIGPt2qRPbkCCC5yCfSjAbtAw6BzXCZXCaq/yn658JrR6/xBRJ7/mYaDQNBA9Pmv wsEtOTKeR8oMh9VC6LyR87wz4W/9tT1+Zpl9oixkuOSdi9YZxoGPEs7WRJpEIUF6YP QT3eMcBSThXdTkmokN7Q16p5we5dG5K2/LjDkgP9NUYvkxjgwB7vubbfIKhxuyu2dj oq30Tych+FNSMtuze99IC0ZOa+AcROHbp3uZujJVXn+3TGN1ylZ7O8WH21Mk5oRMNX /gBaIKRkeOGJg== Content-Type: text/plain; charset=UTF-8 Date: Mon, 30 Mar 2026 19:38:41 +0200 Message-Id: From: "Danilo Krummrich" Subject: Re: [PATCH 05/12] PCI: use generic driver_override infrastructure Cc: "Russell King" , "Greg Kroah-Hartman" , "Rafael J. Wysocki" , "Ioana Ciornei" , "Nipun Gupta" , "Nikhil Agarwal" , "K. Y. Srinivasan" , "Haiyang Zhang" , "Wei Liu" , "Dexuan Cui" , "Long Li" , "Bjorn Helgaas" , "Armin Wolf" , "Bjorn Andersson" , "Mathieu Poirier" , "Vineeth Vijayan" , "Peter Oberparleiter" , "Heiko Carstens" , "Vasily Gorbik" , "Alexander Gordeev" , "Christian Borntraeger" , "Sven Schnelle" , "Harald Freudenberger" , "Holger Dengler" , "Mark Brown" , "Michael S. Tsirkin" , "Jason Wang" , "Xuan Zhuo" , =?utf-8?q?Eugenio_P=C3=A9rez?= , "Juergen Gross" , "Stefano Stabellini" , "Oleksandr Tyshchenko" , "Christophe Leroy (CS GROUP)" , , , , , , , , , , , , , , , "Danilo Krummrich" , "Gui-Dong Han" To: "Alex Williamson" , "Jason Gunthorpe" Content-Transfer-Encoding: quoted-printable Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260324005919.2408620-1-dakr@kernel.org> <20260324005919.2408620-6-dakr@kernel.org> In-Reply-To: <20260324005919.2408620-6-dakr@kernel.org> (Cc: Jason) On Tue Mar 24, 2026 at 1:59 AM CET, Danilo Krummrich wrote: > diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci= _core.c > index d43745fe4c84..460852f79f29 100644 > --- a/drivers/vfio/pci/vfio_pci_core.c > +++ b/drivers/vfio/pci/vfio_pci_core.c > @@ -1987,9 +1987,8 @@ static int vfio_pci_bus_notifier(struct notifier_bl= ock *nb, > pdev->is_virtfn && physfn =3D=3D vdev->pdev) { > pci_info(vdev->pdev, "Captured SR-IOV VF %s driver_override\n", > pci_name(pdev)); > - pdev->driver_override =3D kasprintf(GFP_KERNEL, "%s", > - vdev->vdev.ops->name); > - WARN_ON(!pdev->driver_override); > + WARN_ON(device_set_driver_override(&pdev->dev, > + vdev->vdev.ops->name)); Technically, this is a change in behavior. If vdev->vdev.ops->name is NULL,= it will trigger the WARN_ON(), whereas before it would have just written "(nul= l)" into driver_override. I assume that vfio_pci_core drivers are expected to set the name in struct vfio_device_ops in the first place and this code (silently) relies on this invariant? Alex, Jason: Should we keep this hunk above as is and check for a proper na= me in struct vfio_device_ops in vfio_pci_core_register_device() with a subsequent patch? > } else if (action =3D=3D BUS_NOTIFY_BOUND_DRIVER && > pdev->is_virtfn && physfn =3D=3D vdev->pdev) { > struct pci_driver *drv =3D pci_dev_driver(pdev);