All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiri Pirko <jiri@resnulli.us>
To: Jakub Kicinski <kuba@kernel.org>
Cc: Jason Gunthorpe <jgg@nvidia.com>,
	Leon Romanovsky <leon@kernel.org>, Jiri Pirko <jiri@nvidia.com>,
	Ido Schimmel <idosch@idosch.org>,
	"David S . Miller" <davem@davemloft.net>,
	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: Tue, 16 Nov 2021 08:00:10 +0100	[thread overview]
Message-ID: <YZNW+mtcXe2kjJlY@nanopsycho> (raw)
In-Reply-To: <20211115072206.72435d60@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>

Mon, Nov 15, 2021 at 04:22:06PM CET, kuba@kernel.org wrote:
>On Mon, 15 Nov 2021 11:09:31 -0400 Jason Gunthorpe wrote:
>> On Mon, Nov 15, 2021 at 03:42:58PM +0100, Jiri Pirko wrote:
>> > >Sorry, I don't agree that registering a net notifier in an aux device
>> > >probe function is non-standard or wrong.  
>> > 
>> > Listening to events which happen in different namespaces and react to
>> > them is the non-standard behaviour which I refered to. If you would not
>> > need to do it, you could just use netns notofier which would solve your
>> > issue. You know it.  
>> 
>> Huh?
>> 
>> It calls the bog standard
>> 
>>  register_netdevice_notifier() 
>> 
>> Like hundreds of other drivers do from their probe functions
>> 
>> Which does:
>> 
>> int register_netdevice_notifier(struct notifier_block *nb)
>> {
>> 	struct net *net;
>> 	int err;
>> 
>> 	/* Close race with setup_net() and cleanup_net() */
>> 	down_write(&pernet_ops_rwsem);
>> 
>> And deadlocks because devlink hols the pernet_ops_rwsem when it
>> triggers reload in some paths.
>> 
>> There is nothing wrong with a driver doing this standard pattern.
>> 
>> There is only one place in the entire kernel calling the per-ns
>> register_netdevice_notifier_dev_net() and it is burred inside another
>> part of mlx5 for some reason..
>> 
>> I believe Parav already looked at using that in rdma and it didn't
>> work for some reason I've forgotten. 
>> 
>> It is not that we care about events in different namespaces, it is
>> that rdma, like everything else, doesn't care about namespaces and
>> wants events from the netdev no matter where it is located.
>
>devlink now allows drivers to be net ns-aware, and they should 
>obey if they declare support.  Can we add a flag / capability 
>to devlink and make it an explicit opt-in for drivers who care?

Looks kind of odd to me. It is also not possible for netdevice to say if
it should be net namespace aware or not. The driver should not be the
one to decide this.


  reply	other threads:[~2021-11-16  7:00 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
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 [this message]
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=YZNW+mtcXe2kjJlY@nanopsycho \
    --to=jiri@resnulli.us \
    --cc=davem@davemloft.net \
    --cc=edwin.peer@broadcom.com \
    --cc=idosch@idosch.org \
    --cc=jgg@nvidia.com \
    --cc=jiri@nvidia.com \
    --cc=kuba@kernel.org \
    --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 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.