From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (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 302892DCC13 for ; Thu, 4 Dec 2025 21:07:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764882472; cv=none; b=G14BfIw6Fv7tHQGIvTUDTGnq6r//iU5POTDQ9xNOMit9c5rdifhAgJSnYyJULxuEdEvxu2w5biLEyPWMqF/T+23PDnJUt68UDUQ+iDMHZ6l/4Ww8lmzfcvjrjojabM8sSSFkNOUbkAly9ngGttSGjip5UWWI/QcsPZQ4wz463ws= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764882472; c=relaxed/simple; bh=NW9cQQoEAaaq3AA9nc6mb/b5UPvD+lPeMPRsPYxJB4c=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=DrDnlo8PjD5sagi8WJt1n3/5k4YserhdFNDwmSRmZ4d9xraNHEwgFHPFBXcKYc+EUbX+0DoF0249gy2kegnCGanX8plmQN4Gj8aCxnNVz38OoOhAlmwHsHdcltvGGQKAVgTYYjwjiiHP7MA8RnQwb/nDwMFRZRhTRZ4nWQFImRI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=S0TOghw2; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=NY6C1llK; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="S0TOghw2"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="NY6C1llK" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1764882466; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Utloqd78xIty0AP3e9N1+0oedDpwpptC21lH5x2/t7g=; b=S0TOghw2s7GXjQTgb4HjaZKJzmM6eJnrQ8h39y5+KcGWz+sqgFI+Z18LV1UbLeltQ7XClS Yl1xxPoHSASL0p6TjEW3ws2h28QAIJ3kuYhL2NSc9LCgT8zsEFLrdWVyVJVtybopzHqeLg eOUgkKgYsA36kt06RPtkH2oJFH/47ls= Received: from mail-yw1-f198.google.com (mail-yw1-f198.google.com [209.85.128.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-583--UMqTV95N9GF9qwHsbwjcg-1; Thu, 04 Dec 2025 16:07:45 -0500 X-MC-Unique: -UMqTV95N9GF9qwHsbwjcg-1 X-Mimecast-MFC-AGG-ID: -UMqTV95N9GF9qwHsbwjcg_1764882464 Received: by mail-yw1-f198.google.com with SMTP id 00721157ae682-7881cff41b7so18725407b3.2 for ; Thu, 04 Dec 2025 13:07:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1764882464; x=1765487264; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:cc:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=Utloqd78xIty0AP3e9N1+0oedDpwpptC21lH5x2/t7g=; b=NY6C1llKcFZU4lpB7Ky26vProTmAssitVaxaRYty7JGkBpyvIlbLeWGlwv3aYxzeb3 Wa+3HLbiXSdYRCrl6mDzh59YPmV4nHJje2NJ+g5X+LG+x3KR3eqq/ZnevjVpMishaWX+ gj1HNYKCNTMsyVEfdCAhrZsF3eNzaOWKsac0gEuw7McJkFtrk50ws4CgmnhQpuhesDNt iCzZNfel5lRGE81pibVyYV01LSEx1bWYGS8KDGBpY3mt5RO0tFJIFOAfp0XULI1Fto20 4LKE233AmeGU8rzoEyPDf8QIz9RI8HVPak+ak7r/9KTNrXTpUB9HFn52u2c6cd11B/Cj XhaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764882464; x=1765487264; h=in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Utloqd78xIty0AP3e9N1+0oedDpwpptC21lH5x2/t7g=; b=gpHc2/j61NVqzLVq5gia9EoftGAxywubLqkM2lx1r7/m3dchI5KMxBqADz+zgfmHz+ TkP5699zDIwBMmbk54Sb+dAAgb+/5K0Cl4tyKgjn/y9gS0kAQZnItiYvnTQiIP162V3y J7BlAUHVRu0dcSpCOPB3n3Rz9FkYpzZeR9az2v9rKq9mVDKj0HmRXcRphE5aQz56py38 /sGpXg6O4nI6VIBpqZ5pSUiW0OLZP6kqvasLGvQ4LJQMVkKaggmAiHzeg7QAvEOMBIfD XRAgTkWS+8T7XnfsVzYkgULWYs3l3msrjk+ihAm39oISWqk1zJSuVfGlFrB3/n/WCc3K dztA== X-Forwarded-Encrypted: i=1; AJvYcCVvED0IcmGP9WmEf7bDXaKXTNLk1l0NeT2HcF9EYi/fZsU8fXcQdb2nxRVJswdxUDquxvXtqVTVdF316MI=@vger.kernel.org X-Gm-Message-State: AOJu0YwL4er1MrH7TtHLseV2KvRbkf1Haq5a6ixaXhe6VHtp1Ex3R/1U j+++7VIgxsVdCL3F5J18KI/cF+o94+aBrgnX6wGQvg4jC774rKRPNsLWyNxQgFRijE6NuRd/0mM VYuUIzW5Ks2WXoXsheifxBxVIUcA39r5s7zb9sabhx/5ZA7qJIjGy7klPH6tBIEHhWw== X-Gm-Gg: ASbGncthT5UEve4aGSI8mrHqCrz+Os3gMBo/R3VFdKOowgZPb0tLIZcNtuuAq8T7hkB iuNn6uuTWed+UqJXWGZ/72BiuQcNb6QHwZF38X1LpF8JLcJjwpU7RidU9zSJ0BbYTp55VeF/F/+ wz5DuLH+cVe5H1DztABzJA7PsDSePm8mk1ORt8JueMB/RpYQzRejaNUg140GIVb0KPA3ZyBiKB2 hnF7Quof8IZADVHDbiCfQv8oHgAtQr1P8UDyCK0U/vG7hHR/f9gdOVRW6p81gJ2Ww5WXfmMbakg av9H/4pAOPqB9a2czBnCfo1z64wLOuQeqrrE9KfmLjec0aAW8H1DPipTuKQiohNZwWh5uk5f6eO uH+nFCBcixw== X-Received: by 2002:a05:690c:1e:b0:786:5789:57ce with SMTP id 00721157ae682-78c0bffa67bmr64181297b3.43.1764882464272; Thu, 04 Dec 2025 13:07:44 -0800 (PST) X-Google-Smtp-Source: AGHT+IHm82XKkqw4kfk5U49CAGJ/i+43HgaWocHH822ewl7ru2nz49+bzl9Zv11OSszH0Ut14YtklA== X-Received: by 2002:a05:690c:1e:b0:786:5789:57ce with SMTP id 00721157ae682-78c0bffa67bmr64180817b3.43.1764882463673; Thu, 04 Dec 2025 13:07:43 -0800 (PST) Received: from localhost ([2607:f2c0:b021:e700:58e4:f7ce:31b9:7841]) by smtp.gmail.com with UTF8SMTPSA id 00721157ae682-78c1b7a72dcsm9479027b3.52.2025.12.04.13.07.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 04 Dec 2025 13:07:43 -0800 (PST) Date: Thu, 4 Dec 2025 16:07:42 -0500 From: Peter Colberg To: Jason Gunthorpe Cc: Danilo Krummrich , Bjorn Helgaas , Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= , Miguel Ojeda , Alex Gaynor , Boqun Feng , Gary Guo , =?utf-8?B?QmrDtnJu?= Roy Baron , Benno Lossin , Andreas Hindborg , Alice Ryhl , Trevor Gross , Abdiel Janulgue , Daniel Almeida , Robin Murphy , Greg Kroah-Hartman , Dave Ertman , Ira Weiny , Leon Romanovsky , linux-pci@vger.kernel.org, rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org, Alexandre Courbot , Alistair Popple , Joel Fernandes , John Hubbard , Zhi Wang Subject: Re: [PATCH 7/8] rust: pci: add physfn(), to return PF device for VF device Message-ID: Mail-Followup-To: Jason Gunthorpe , Danilo Krummrich , Bjorn Helgaas , Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= , Miguel Ojeda , Alex Gaynor , Boqun Feng , Gary Guo , =?utf-8?B?QmrDtnJu?= Roy Baron , Benno Lossin , Andreas Hindborg , Alice Ryhl , Trevor Gross , Abdiel Janulgue , Daniel Almeida , Robin Murphy , Greg Kroah-Hartman , Dave Ertman , Ira Weiny , Leon Romanovsky , linux-pci@vger.kernel.org, rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org, Alexandre Courbot , Alistair Popple , Joel Fernandes , John Hubbard , Zhi Wang References: <20251119-rust-pci-sriov-v1-0-883a94599a97@redhat.com> <20251119-rust-pci-sriov-v1-7-883a94599a97@redhat.com> <20251121232642.GG233636@ziepe.ca> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20251121232642.GG233636@ziepe.ca> On Fri, Nov 21, 2025 at 07:26:42PM -0400, Jason Gunthorpe wrote: > On Wed, Nov 19, 2025 at 05:19:11PM -0500, Peter Colberg wrote: > > Add a method to return the Physical Function (PF) device for a Virtual > > Function (VF) device in the bound device context. > > > > Unlike for a PCI driver written in C, guarantee that when a VF device is > > bound to a driver, the underlying PF device is bound to a driver, too. > > You can't do this as an absolutely statement from rust code alone, > this statement is confused. > > > When a device with enabled VFs is unbound from a driver, invoke the > > sriov_configure() callback to disable SR-IOV before the unbind() > > callback. To ensure the guarantee is upheld, call disable_sriov() > > to remove all VF devices if the driver has not done so already. > > This doesn't seem like it should be in this patch. > > Good drivers using the PCI APIs should be calling pci_disable_sriov() > during their unbind. > > The prior patch #3 should not have added "safe" bindings for > enable_sriov that allow this lifetime rule to be violated. > > > + #[cfg(CONFIG_PCI_IOV)] > > + pub fn physfn(&self) -> Result<&Device> { > > + if !self.is_virtfn() { > > + return Err(EINVAL); > > + } > > + // SAFETY: > > + // `self.as_raw` returns a valid pointer to a `struct pci_dev`. > > + // > > + // `physfn` is a valid pointer to a `struct pci_dev` since self.is_virtfn() is `true`. > > + // > > + // `physfn` may be cast to a `Device` since `pci::Driver::remove()` calls > > + // `disable_sriov()` to remove all VF devices, which guarantees that the underlying > > + // PF device is always bound to a driver when the VF device is bound to a driver. > > Wrong safety statement. There are drivers that don't call > disable_sriov(). You need to also check that the driver attached to > the PF is actually working properly. Thank you for the review. I missed the obvious case where the PF driver is a C driver that does not disable SR-IOV on unbind and the VF driver is a Rust driver that invokes physfn(). > I do not like to see this attempt to open code the tricky login of > pci_iov_get_pf_drvdata() in rust without understanding the issues :( I will work on a proper solution based on Danilo's proposal [1]. [1] https://lore.kernel.org/all/DEFL4TG0WX1C.2GLH4417EPU3V@kernel.org/ Thanks, Peter