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 C8F5163A0 for ; Fri, 18 Aug 2023 18:21:04 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 884BBC433CA; Fri, 18 Aug 2023 18:21:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1692382864; bh=5fxqgQEkZHL6btJ4/Au0C0GLYzcSoQRp1lYvf5OMydU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=tuQYz5if+ijqMRJwbHBOnMHfraDlqs9NUUkc1TnPej4p5XJgz1qSzQzZJGocMaYWV j6Q4bZww5+8VBScmlvzqoV+aNUVxK90By8eOgRY6Uh5YBbPtjh9rjV5+AjY20VuLPV 6UPAPgGebVn5YtbloV1ZgIUoyotS8hxCZFYc81m6BDKPmnbGwvr0qHyf6qAPZ3z5Yq MrKoAnqEKhmDQlyAnuQZN8R4R6L4WT0rQmWvOkU7V5Kz0RIOKgoCsWziTvWZOEF+Ty kPmQ07HrdgGM9ysbz2xXxqpDvUA2agamctMdAZ6DtDWnY5rhdE72HU+SmDlKkjGfU+ b35pI6Fpp5edg== Date: Fri, 18 Aug 2023 21:20:59 +0300 From: Leon Romanovsky To: Przemek Kitszel Cc: Tony Nguyen , Jesse Brandeburg , intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org, Mateusz Polchlopek , Jacob Keller Subject: Re: [PATCH iwl-next] ice: store VF's pci_dev ptr in ice_vf Message-ID: <20230818182059.GZ22185@unreal> References: <20230816085454.235440-1-przemyslaw.kitszel@intel.com> <20230816143148.GX22185@unreal> Precedence: bulk X-Mailing-List: netdev@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: On Fri, Aug 18, 2023 at 02:20:51PM +0200, Przemek Kitszel wrote: > On 8/16/23 16:31, Leon Romanovsky wrote: > > On Wed, Aug 16, 2023 at 04:54:54AM -0400, Przemek Kitszel wrote: > > > Extend struct ice_vf by vfdev. > > > Calculation of vfdev falls more nicely into ice_create_vf_entries(). > > > > > > Caching of vfdev enables simplification of ice_restore_all_vfs_msi_state(). > > > > I see that old code had access to pci_dev * of VF without any locking > > from concurrent PCI core access. How is it protected? How do you make > > sure that vfdev is valid? > > > > Generally speaking, it is rarely good idea to cache VF pci_dev pointers > > inside driver. > > > > Thanks > > Overall, I do agree that ice driver, as a whole, has room for improvement in > terms of synchronization, objects lifetime, and similar. > > In this particular case, I don't see any reason of PCI reconfiguration > during VF lifetime, but likely I'm missing something? You are caching VF pointer in PF, and you are subjected to PF lifetime and not VF lifetime. Thanks