From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f181.google.com (mail-qt1-f181.google.com [209.85.160.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A05773009C0 for ; Fri, 21 Nov 2025 23:26:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.181 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763767611; cv=none; b=d3u3kAL4n/6BTiXkIcW3wlQtDWggCthb/pK14WUVwSJxpeKivG4ixsDvbfThRrjL7Cel2EJI664oOX2casMDAHMmUEpTTazJG8NKIoeNafENO3u7vI4GNawfsfs5CWLBqwPRtbMrTjb/WTFEXyE73tQM5ASrAKTSvkiV8gfe9Ks= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763767611; c=relaxed/simple; bh=dkzSuWHp15c23lNS7aZJijZKSIKGzqZHYrTdBoTsqTU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ZHAA6ph7aUVFzO/n2Ysl8sULfFmCyJbrWJjijRtlwPFAsy9tYbqkjjbGnM9l86QXeB25LNkTw3qH3mF1ymWunxvq4NTWIH59enn6Yw83kCUB1SjRexq2YAdvsS3kYcCJpjoNoocJtuPZ9aAdFiNA9qrRbiVDrp3WsbmH0VhyHGM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca; spf=pass smtp.mailfrom=ziepe.ca; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b=eEdF+tth; arc=none smtp.client-ip=209.85.160.181 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="eEdF+tth" Received: by mail-qt1-f181.google.com with SMTP id d75a77b69052e-4ee13dc0c52so21116331cf.2 for ; Fri, 21 Nov 2025 15:26:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1763767604; x=1764372404; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=MNnBy71IqEFL4I7Cf2sjCK+m56XgwY3bFvivIuJmmCs=; b=eEdF+tth7aIGG0IwToEIlqmY4mmOiTfCRlcbGXFAat35pVaQl4DI1ss+OiLeP1Ks7Q MALmb6b3ndvXm3eU/UbJYaWwVuSCwsah1zPXsoYrBMMuUSf9+d5PCw8awQVAZq4o/PNX SYrqudaRFgoWpa8p99M95Hpren9rHkVF3VvYsqtkcbyqSY4EOK5LiSisSVkSxX8P3OEI 9eABOkEdPlC+27YTPQS4Zb+OLMp8vDLF3M6FkpboohkssxGrmuc9R6XfC7TtQh2PwVdB FIbzCSejZ+GNiCqPsWJ0nxdSyVuB6KAZu7n1aHFvnsXb3Y41ydymVepESLYk6rNeNJVG FM8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763767604; x=1764372404; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=MNnBy71IqEFL4I7Cf2sjCK+m56XgwY3bFvivIuJmmCs=; b=tLJFsNuk0MWFfDwKUMtuy9FkUx8mIUIFWwTYZ1o05NczVYkLS2jWXc3e/IuhZh70/q Fjk6GPe6MfMWcQ2nT9VQv7X+rqmOaaBXcklGwhS05GiNFcXKG4RjjnRnQpsG35Wek0k8 bTPim9navaGfRBd/VlCQ7gc4VoK9Ac+pPfExtbQC5ydx9DNi07pek7eJaxLMHzinQ7v2 0qlA/akUGn6QmWbGLJB1JRBmK2zYakLyJWvNSOs4l2GtU31ugWz/U+iOyMMu/vz11Dcd bO6wAhOVQT9bllbAGBPHxbiC4n2DiVY/I95o96osVMvkLYDtPWusrZ62DMiMZ5MIQ8mC 8/nQ== X-Forwarded-Encrypted: i=1; AJvYcCUilog3VNXiMitltriHipDDnHy9m2AEzUO/xXORHCZfZGw0pmWMeCjroKVD4CKp5nOltQWdUAIdl8O83qI=@vger.kernel.org X-Gm-Message-State: AOJu0YxB7A7BIJoaHbAr6rmcjVrOXhnaMldiC/gUE37jetOHMfQNAqKI fbpKBS3PgrokTpBMRSyQP+jBhd1XAWND7/jYv0m4a9/oyxRZrCr7wqPlIBwHZriGPS0= X-Gm-Gg: ASbGnctUkR01XFeKc3khi0a6UnZGARa6FN0e5hJHVsQtAGKW8a2Bkeuim5+9kMFtsbT ZiUQtiMp25kIj2vxm0SA+SYX2EQ2wPtHvNk2xeaWoxa/dp5csotby/YU0KTvWM92Fa1tQIj2cL1 5us7ZPDqMvYae9gMpI5VH+iUah/J4e2dlanDNnzCebp9WX0mUr9e+49nXyWhjDJ5fwjZzmbh4WB BITo2RANeEph7p1bCGIF9xwDJliJkX13x+QqCAVYGYoFt2FVcI7n+/hDCQTuFAMbSu2bgLf9sub kz5mRDS5lm/qVUiP7TTB/jWsV4/5DvhrPlTacTr+1Wetqs57EnI0Sw7fCPO/R8vB8ISv2CKIUHJ +FuSqT2GnbnbUy0UVhTLTadPb9CUZSN3F/rYnQHBl6z4Vp+vcwuhziIYiS1k8lSEbPAZTNwyDmH kGoR9e7NPyXvLlQOchT5vS5Wl/D16B2IbipraqS0GzPzUdJVrfomFRdHlM X-Google-Smtp-Source: AGHT+IFjEleDYxww7zzdvBQdwe8PidrLr18zan1i0bYdCXFl2tvvNG6hLd40H4FO0sVjJlEv/KopjA== X-Received: by 2002:ac8:7fce:0:b0:4ee:62e:c1eb with SMTP id d75a77b69052e-4ee58aaa08amr51321841cf.26.1763767604320; Fri, 21 Nov 2025 15:26:44 -0800 (PST) Received: from ziepe.ca (hlfxns017vw-47-55-120-4.dhcp-dynamic.fibreop.ns.bellaliant.net. [47.55.120.4]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-4ee48e69dfbsm43448061cf.24.2025.11.21.15.26.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 21 Nov 2025 15:26:43 -0800 (PST) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1vMaWY-00000001bZ4-0ogb; Fri, 21 Nov 2025 19:26:42 -0400 Date: Fri, 21 Nov 2025 19:26:42 -0400 From: Jason Gunthorpe To: Peter Colberg 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: <20251121232642.GG233636@ziepe.ca> References: <20251119-rust-pci-sriov-v1-0-883a94599a97@redhat.com> <20251119-rust-pci-sriov-v1-7-883a94599a97@redhat.com> 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: <20251119-rust-pci-sriov-v1-7-883a94599a97@redhat.com> 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. 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 :( Jason