netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Leon Romanovsky <leon@kernel.org>
Cc: Ido Schimmel <idosch@idosch.org>, Jiri Pirko <jiri@resnulli.us>,
	"David S . Miller" <davem@davemloft.net>,
	Jiri Pirko <jiri@nvidia.com>,
	linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
	edwin.peer@broadcom.com
Subject: Re: [PATCH net-next] devlink: Require devlink lock during device reload
Date: Mon, 8 Nov 2021 10:16:46 -0800	[thread overview]
Message-ID: <20211108101646.0a4e5ca4@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> (raw)
In-Reply-To: <YYlfI4UgpEsMt5QI@unreal>

On Mon, 8 Nov 2021 19:32:19 +0200 Leon Romanovsky wrote:
> > I think it's common sense. We're just exporting something to make our
> > lives easier somewhere else in the three. Do you see a way in which
> > taking refs on devlink can help out-of-tree code?  
> 
> I didn't go such far in my thoughts. My main concern is that you ore
> exposing broken devlink internals in the hope that drivers will do better
> locking. I wanted to show that internal locking should be fixed first.
> 
> https://lore.kernel.org/netdev/cover.1636390483.git.leonro@nvidia.com/T/#m093f067d0cafcbe6c05ed469bcfd708dd1eb7f36
> 
> While this series fixes locking and after all my changes devlink started
> to be more secure, that works correctly for simple drivers.

I prefer my version. I think I asked you to show how the changes make
drivers simpler, which you failed to do.

I already told you how this is going to go, don't expect me to comment
too much.

> However for net namespace aware drivers it still stays DOA.
> 
> As you can see, devlink reload holds pernet_ops_rwsem, which drivers should
> take too in order to unregister_netdevice_notifier.
> 
> So for me, the difference between netdevsim and real device (mlx5) is
> too huge to really invest time into netdevsim-centric API, because it
> won't solve any of real world problems.

Did we not already go over this? Sorry, it feels like you're repeating
arguments which I replied to before. This is exhausting.

nfp will benefit from the simplified locking as well, and so will bnxt,
although I'm not sure the maintainers will opt for using devlink framework
due to the downstream requirements.

  reply	other threads:[~2021-11-08 18:16 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-31 17:35 [PATCH net-next] devlink: Require devlink lock during device reload Leon Romanovsky
2021-11-01  7:12 ` Ido Schimmel
2021-11-01 15:03 ` Jiri Pirko
2021-11-01 20:52   ` Ido Schimmel
2021-11-01 23:11     ` Jakub Kicinski
2021-11-07 17:16       ` Ido Schimmel
2021-11-07 17:54         ` Leon Romanovsky
2021-11-08 16:09           ` Jakub Kicinski
2021-11-08 17:32             ` Leon Romanovsky
2021-11-08 18:16               ` Jakub Kicinski [this message]
2021-11-08 18:24                 ` Leon Romanovsky
2021-11-08 18:46                   ` Jakub Kicinski
2021-11-08 19:58                     ` Leon Romanovsky
2021-11-08 23:31                       ` Jakub Kicinski
2021-11-09 14:12                         ` Leon Romanovsky
2021-11-09 14:17                           ` Jakub Kicinski
2021-11-09 14:30                             ` Leon Romanovsky
2021-11-09 14:49                               ` Jakub Kicinski
2021-11-09 16:29                           ` Jiri Pirko
2021-11-09 14:43                         ` Jason Gunthorpe
2021-11-09 15:07                           ` Jakub Kicinski
2021-11-09 15:33                             ` Jason Gunthorpe
2021-11-09 16:20                               ` Jakub Kicinski
2021-11-09 18:24                                 ` Jason Gunthorpe
2021-11-11 12:05                                   ` Jiri Pirko
2021-11-11 12:17                                     ` Leon Romanovsky
2021-11-12  7:38                                       ` Jiri Pirko
2021-11-14  6:19                                         ` Leon Romanovsky
2021-11-15 11:20                                           ` Jiri Pirko
2021-11-15 12:53                                             ` Jason Gunthorpe
2021-11-15 14:42                                               ` Jiri Pirko
2021-11-15 15:09                                                 ` Jason Gunthorpe
2021-11-15 15:22                                                   ` Jakub Kicinski
2021-11-16  7:00                                                     ` Jiri Pirko
2021-11-16 13:45                                                       ` Jakub Kicinski
2021-11-16  6:57                                                   ` Jiri Pirko
2021-11-16 12:44                                                     ` Jason Gunthorpe
2021-11-17 14:15                                                       ` Leon Romanovsky
2021-11-10  7:52                                 ` Leon Romanovsky
2021-11-09 16:15                             ` Jiri Pirko
2021-11-09 16:26                               ` Jakub Kicinski
2021-11-09 16:30                                 ` 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=20211108101646.0a4e5ca4@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com \
    --to=kuba@kernel.org \
    --cc=davem@davemloft.net \
    --cc=edwin.peer@broadcom.com \
    --cc=idosch@idosch.org \
    --cc=jiri@nvidia.com \
    --cc=jiri@resnulli.us \
    --cc=leon@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    /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).