netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Lucero Palau, Alejandro" <alejandro.lucero-palau@amd.com>
To: Jiri Pirko <jiri@resnulli.us>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Cc: "davem@davemloft.net" <davem@davemloft.net>,
	"kuba@kernel.org" <kuba@kernel.org>,
	"pabeni@redhat.com" <pabeni@redhat.com>,
	"edumazet@google.com" <edumazet@google.com>,
	"dmichail@fungible.com" <dmichail@fungible.com>,
	"jesse.brandeburg@intel.com" <jesse.brandeburg@intel.com>,
	"anthony.l.nguyen@intel.com" <anthony.l.nguyen@intel.com>,
	"snelson@pensando.io" <snelson@pensando.io>,
	"drivers@pensando.io" <drivers@pensando.io>,
	"f.fainelli@gmail.com" <f.fainelli@gmail.com>,
	"yangyingliang@huawei.com" <yangyingliang@huawei.com>
Subject: Re: [patch net-next 0/3] devlink: fix order of port and netdev register in drivers
Date: Tue, 4 Oct 2022 15:31:10 +0000	[thread overview]
Message-ID: <6dd32faa-2651-31bf-da2e-e768b9966e36@amd.com> (raw)
In-Reply-To: 20220926110938.2800005-1-jiri@resnulli.us

Hi Jiri,

I think we have another issue with devlink_unregister and related 
devlink_port_unregister. It is likely not an issue with current drivers 
because the devlink ports are managed by netdev register/unregister 
code, and with your patch that will be fine.

But by definition, devlink does exist for those things not matching 
smoothly to netdevs, so it is expected devlink ports not related to 
existing netdevs at all. That is the case in a patch I'm working on for 
sfc ef100, where devlink ports are created at PF initialization, so 
related netdevs will not be there at that point, and they can not exist 
when the devlink ports are removed when the driver is removed.

So the question in this case is, should the devlink ports unregister 
before or after their devlink unregisters?

Since the ports are in a list owned by the devlink struct, I think it 
seems logical to unregister the ports first, and that is what I did. It 
works but there exists a potential concurrency issue with devlink user 
space operations. The devlink code takes care of race conditions involving the 
devlink struct with rcu plus get/put operations, but that is not the 
case for devlink ports.

Interestingly, unregistering the devlink first, and doing so with the 
ports without touching/releasing the devlink struct would solve the 
problem, but not sure this is the right approach here. It does not seem 
clean, and it would require documenting the right unwinding order and 
to add a check for DEVLINK_REGISTERED in devlink_port_unregister.

I think the right solution would be to add protection to devlink ports 
and likely other devlink objects with similar concurrency issues.


Let me know what you think about it.



On 9/26/22 13:09, Jiri Pirko wrote:
> CAUTION: This message has originated from an External Source. Please use proper judgment and caution when opening attachments, clicking links, or responding to this email.
>
>
> From: Jiri Pirko <jiri@nvidia.com>
>
> Some of the drivers use wrong order in registering devlink port and
> netdev, registering netdev first. That was not intended as the devlink
> port is some sort of parent for the netdev. Fix the ordering.
>
> Note that the follow-up patchset is going to make this ordering
> mandatory.
>
> Jiri Pirko (3):
>    funeth: unregister devlink port after netdevice unregister
>    ice: reorder PF/representor devlink port register/unregister flows
>    ionic: change order of devlink port register and netdev register
>
>   .../net/ethernet/fungible/funeth/funeth_main.c   |  2 +-
>   drivers/net/ethernet/intel/ice/ice_lib.c         |  6 +++---
>   drivers/net/ethernet/intel/ice/ice_main.c        | 12 ++++++------
>   drivers/net/ethernet/intel/ice/ice_repr.c        |  2 +-
>   .../net/ethernet/pensando/ionic/ionic_bus_pci.c  | 16 ++++++++--------
>   5 files changed, 19 insertions(+), 19 deletions(-)
>
> --
> 2.37.1
>


  parent reply	other threads:[~2022-10-04 15:31 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-26 11:09 [patch net-next 0/3] devlink: fix order of port and netdev register in drivers Jiri Pirko
2022-09-26 11:09 ` [patch net-next 1/3] funeth: unregister devlink port after netdevice unregister Jiri Pirko
2022-09-26 11:09 ` [patch net-next 2/3] ice: reorder PF/representor devlink port register/unregister flows Jiri Pirko
2022-09-26 11:09 ` [patch net-next 3/3] ionic: change order of devlink port register and netdev register Jiri Pirko
2022-09-26 19:49   ` Shannon Nelson
2022-09-27 15:00 ` [patch net-next 0/3] devlink: fix order of port and netdev register in drivers patchwork-bot+netdevbpf
2022-10-04 15:31 ` Lucero Palau, Alejandro [this message]
2022-10-05  7:49   ` Jiri Pirko
2022-10-05  8:18     ` Lucero Palau, Alejandro
2022-10-06 12:44       ` Jiri Pirko
2022-10-06 13:45         ` Lucero Palau, Alejandro
2022-10-06 15:53           ` Jiri Pirko

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=6dd32faa-2651-31bf-da2e-e768b9966e36@amd.com \
    --to=alejandro.lucero-palau@amd.com \
    --cc=anthony.l.nguyen@intel.com \
    --cc=davem@davemloft.net \
    --cc=dmichail@fungible.com \
    --cc=drivers@pensando.io \
    --cc=edumazet@google.com \
    --cc=f.fainelli@gmail.com \
    --cc=jesse.brandeburg@intel.com \
    --cc=jiri@resnulli.us \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=snelson@pensando.io \
    --cc=yangyingliang@huawei.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).