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 784433BB44; Thu, 2 Oct 2025 21:32: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=1759440772; cv=none; b=FCUtGzxpGKLRFCLwcrgUYO5K5pmnbEtFRLZpF1o6dbW6YdDBvSoLnVD1E7jJ+NgJsH4sIkIGSALuWva3gNhk2MxAM/TW+cSMzUC1fX+2DNKzHyGCh+GrCnL9BZTcuSL9XW+vuuG4+resRzPGhoqEeX758e013zvClNFMVByMKqk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759440772; c=relaxed/simple; bh=L6sLUDYC2mIpeZa6zlf8RaB7dU8gXnHoIwa5yefwsIA=; h=Mime-Version:Content-Type:Date:Message-Id:From:Subject:Cc:To: References:In-Reply-To; b=K/2AsPUhZoUyuCeEUrVJRIvjffQFkIFNKJkIPJdX78VCDKhmCXhRYmpjtqDfQpa4Lso+2atF6rdl68NXBFgkhbGONT5t6xgpYWpHYzC+74V0J39m7wgiJyAvGipyKzsflvl0ilkcMysRPFsQ9np7wxoYsRpnKrckF2HXYQWqZpI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=FT5tGjTv; 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="FT5tGjTv" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 080D4C4CEF4; Thu, 2 Oct 2025 21:32:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1759440771; bh=L6sLUDYC2mIpeZa6zlf8RaB7dU8gXnHoIwa5yefwsIA=; h=Date:From:Subject:Cc:To:References:In-Reply-To:From; b=FT5tGjTvx9anXGJJZpqlUnzmhZVCLjbzfE1uMbfa+yvW3vpSEUISyuS3xg1dIv2zB Ug/A9nye/60ZJHaC8Uur30OfmfTXXctJ/1NcI44k4R4hvj/AJXhAaiSuorhoDFRSzg K9Th1cKcBjuyTQq7fO6ceOe+M2R2LClT7qdM5r5J8uQX+PCI/JnexJVt70S2IEbqdg qNhAsrYT2DTFuZKHGKRhGPLXESxvX0EGGlpmzE7dRWFotM7v8pyO9vjQe8HliEYrRr DjrXdwtBp408hV864FHu2X+RvVsJeccvNzVqD+zpe/JQrNnZc4cRLBfKF/Sc6zUfZy fjviCRYDin/ZQ== Precedence: bulk X-Mailing-List: linux-pci@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Thu, 02 Oct 2025 23:32:44 +0200 Message-Id: From: "Danilo Krummrich" Subject: Re: [PATCH v2 1/2] rust: pci: skip probing VFs if driver doesn't support VFs Cc: "John Hubbard" , "Alexandre Courbot" , "Joel Fernandes" , "Timur Tabi" , "Alistair Popple" , "Zhi Wang" , "Surath Mitra" , "David Airlie" , "Simona Vetter" , "Alex Williamson" , "Bjorn Helgaas" , =?utf-8?q?Krzysztof_Wilczy=C5=84ski?= , "Miguel Ojeda" , "Alex Gaynor" , "Boqun Feng" , "Gary Guo" , =?utf-8?q?Bj=C3=B6rn_Roy_Baron?= , "Benno Lossin" , "Andreas Hindborg" , "Alice Ryhl" , "Trevor Gross" , , , , "LKML" To: "Jason Gunthorpe" References: <20251002170506.GA3299207@nvidia.com> <20251002180525.GC3299207@nvidia.com> <3ab338fb-3336-4294-bd21-abd26bc18392@kernel.org> <20251002183114.GD3299207@nvidia.com> <56daf2fe-5554-4d52-94b3-feec4834c5be@kernel.org> <20251002185616.GG3299207@nvidia.com> <20251002210433.GH3299207@nvidia.com> In-Reply-To: On Thu Oct 2, 2025 at 11:14 PM CEST, Danilo Krummrich wrote: > On 10/2/25 11:04 PM, Jason Gunthorpe wrote: >> On Thu, Oct 02, 2025 at 09:36:17PM +0200, Danilo Krummrich wrote: >>> If we want to obtain the driver's private data from a device outside th= e scope >>> of bus callbacks, we always need to ensure that the device is guarantee= d to be >>> bound and we also need to prove the type of the private data, since a d= evice >>> structure can't be generic over its bound driver. >>=20 >> pci_iov_get_pf_drvdata() does both of these things - this is what it >> is for. Please don't open code it :( > > It makes no sense to use it, both of those things will be ensured in a mo= re > generic way in the base device implementation already (which is what I me= ant > with layering). > > Both requirements are not specific to PCI, or the specific VF -> PF use-c= ase. > > In order to guarantee soundness both of those things have to be guarantee= d for > any access to the driver's private data. Actually, let me elaborate a bit more on this: In C when a driver calls dev_get_drvdata() it asserts two things: (1) The device is bound to the driver calling this function. (2) It casts the returned void * to the correct type. Obviously, relying on this in Rust would be fundamentally unsafe. Hence, the idea is to implement Device::drvdata_borrow::(), which takes = a &Device as argument, which proves that the device must be bound. The T must be the driver specific driver type, i.e. the type that implement= s e.g. the pci::Driver trait. With that, Device::drvdata_borrow() can internally check whether the assert= ed type T matches the unique type ID that we store in the device in probe(). This way we can prove that the device is actually bound and that we cast to= the correct type. Furthermore, the returned reference to the driver's private data can't out-= live the lifetime of the given &Device, so we're also guaranteed that the device won't be unbound while we still have a reference to the driver's pri= vate data. So, when we call pdev.physfn().drvdata_borrow::() the checks are included already. > I will send some patches soon, I think this will make it obvious. :) >>>> Certain conditions may be workable, some drivers seem to have >>>> preferences not to call disable, though I think that is wrong :\ >>> >>> I fully agree! I was told that this is because apparently some PF drive= rs are >>> only loaded to enable SR-IOV and then removed to shrink the potential a= ttack >>> surface. Personally, I think that's slightly paranoid, if the driver wo= uld not >>> do anything else than enable / disable SR-IOV, but I think we can work = around >>> this use-case if people really want it. >>=20 >> I've heard worse reasons than that. If that is the interest I'd >> suggest they should just use VFIO and leave a userspace stub >> process.. > > I'm not sure I follow your proposal, can you elaborate?