From: Leon Romanovsky <leon@kernel.org>
To: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Cc: netdev@vger.kernel.org,
Jesse Brandeburg <jesse.brandeburg@intel.com>,
intel-wired-lan@lists.osuosl.org,
Mateusz Polchlopek <mateusz.polchlopek@intel.com>,
Tony Nguyen <anthony.l.nguyen@intel.com>
Subject: Re: [Intel-wired-lan] [PATCH iwl-next] ice: store VF's pci_dev ptr in ice_vf
Date: Mon, 21 Aug 2023 14:01:46 +0300 [thread overview]
Message-ID: <20230821110146.GA6583@unreal> (raw)
In-Reply-To: <12025d38-a5e2-5ddd-721f-c1c083785d22@intel.com>
On Mon, Aug 21, 2023 at 12:48:40PM +0200, Przemek Kitszel wrote:
> On 8/18/23 20:20, Leon Romanovsky wrote:
> > 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,
>
> that's correct that the driver is PF/ice
>
> > and you are subjected to PF lifetime
> > and not VF lifetime.
>
> this belongs to struct ice_vf, which should have VF lifetime,
> otherwise it's already at risk
I'm not so sure about it. ICE used to use devm_* API and not explicit
kalloc/kfree calls, it is not clear anymore the lifetime scope of VF
structure.
Thanks
>
> >
> > Thanks
>
> Thank you!
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
next prev parent reply other threads:[~2023-08-21 11:01 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-16 8:54 [Intel-wired-lan] [PATCH iwl-next] ice: store VF's pci_dev ptr in ice_vf Przemek Kitszel
2023-08-16 14:31 ` Leon Romanovsky
2023-08-18 12:20 ` Przemek Kitszel
2023-08-18 18:20 ` Leon Romanovsky
2023-08-21 10:48 ` Przemek Kitszel
2023-08-21 11:01 ` Leon Romanovsky [this message]
2023-08-22 20:46 ` Keller, Jacob E
2023-08-23 9:55 ` Leon Romanovsky
2023-08-17 7:54 ` kernel test robot
2023-08-17 7:54 ` kernel test robot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230821110146.GA6583@unreal \
--to=leon@kernel.org \
--cc=anthony.l.nguyen@intel.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=jesse.brandeburg@intel.com \
--cc=mateusz.polchlopek@intel.com \
--cc=netdev@vger.kernel.org \
--cc=przemyslaw.kitszel@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.