[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c4d4dec1-73e1-41bc-3b6c-e35a7121f419@intel.com>
Date: Wed, 18 Jan 2023 13:16:23 -0800
From: Jacob Keller <jacob.e.keller@...el.com>
To: Jiri Pirko <jiri@...nulli.us>, <netdev@...r.kernel.org>
CC: <davem@...emloft.net>, <kuba@...nel.org>, <pabeni@...hat.com>,
<edumazet@...gle.com>, <michael.chan@...adcom.com>,
<yisen.zhuang@...wei.com>, <salil.mehta@...wei.com>,
<jesse.brandeburg@...el.com>, <anthony.l.nguyen@...el.com>,
<tariqt@...dia.com>, <saeedm@...dia.com>, <leon@...nel.org>,
<idosch@...dia.com>, <petrm@...dia.com>,
<mailhol.vincent@...adoo.fr>, <gal@...dia.com>
Subject: Re: [patch net-next v5 03/12] net/mlx5e: Create separate devlink
instance for ethernet auxiliary device
On 1/18/2023 7:21 AM, Jiri Pirko wrote:
> From: Jiri Pirko <jiri@...dia.com>
>
> The fact that devlink instance lock is held over mlx5 auxiliary devices
> probe and remove routines brought a need to conditionally take devlink
> instance lock there. The code is checking a MLX5E_LOCKED_FLOW flag
> in mlx5 priv struct.
>
> This is racy and may lead to access devlink objects without holding
> instance lock or deadlock.
>
> To avoid this, the only lock-wise sane solution is to make the
> devlink entities created by the auxiliary device independent on
> the original pci devlink instance. Create devlink instance for the
> auxiliary device and put the uplink port instance there alongside with
> the port health reporters.
>
So this would make the port appear independent of the main PCI devlink.
I think that's ok, they are a separate driver and managing the
connection would be really difficult.
Ok.
Reviewed-by: Jacob Keller <jacob.e.keller@...el.com>
Powered by blists - more mailing lists