netdev - Re: [PATCH net-next] devlink: Require devlink lock during device reload

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 8 Nov 2021 10:46:08 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Leon Romanovsky <leon@...nel.org>
Cc:     Ido Schimmel <idosch@...sch.org>, Jiri Pirko <jiri@...nulli.us>,
        "David S . Miller" <davem@...emloft.net>,
        Jiri Pirko <jiri@...dia.com>, linux-kernel@...r.kernel.org,
        netdev@...r.kernel.org, edwin.peer@...adcom.com
Subject: Re: [PATCH net-next] devlink: Require devlink lock during device
 reload

On Mon, 8 Nov 2021 20:24:37 +0200 Leon Romanovsky wrote:
> > I prefer my version. I think I asked you to show how the changes make
> > drivers simpler, which you failed to do.  
> 
> Why did I fail? My version requires **zero** changes to the drivers.
> Everything works without them changing anything. You can't ask for more.

For the last time.

"Your version" does require driver changes, but for better or worse
we have already committed them to the tree. All the re-ordering to make
sure devlink is registered last and more work is done at alloc,
remember?

The goal is to make the upstream drivers simpler. You failed to show
how your code does that.

Maybe you don't see the benefit because upstream simplifications are
hard to depend on in out-of-tree drivers?

> > 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.  
> 
> I don't enjoy it either.
> 
> > 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.  
> 
> Exactly why devlink should be fixed first.

If by "fixed first" you mean it needs 5 locks to be added and to remove
any guarantees on sub-object lifetime then no thanks.