netdev - Re: [RFT net-next 0/6] devlink: expose instance locking and simplify port splitting

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] [day] [month] [year] [list]

Message-ID: <YjDS5P/qCR0krMYI@unreal>
Date:   Tue, 15 Mar 2022 19:54:44 +0200
From:   Leon Romanovsky <leonro@...dia.com>
To:     Jakub Kicinski <kuba@...nel.org>
CC:     Ido Schimmel <idosch@...sch.org>, <idosch@...dia.com>,
        <petrm@...dia.com>, <simon.horman@...igine.com>,
        <netdev@...r.kernel.org>, <jiri@...nulli.us>,
        Michael Chan <michael.chan@...adcom.com>
Subject: Re: [RFT net-next 0/6] devlink: expose instance locking and simplify
 port splitting

On Tue, Mar 15, 2022 at 08:58:29AM -0700, Jakub Kicinski wrote:
> On Tue, 15 Mar 2022 09:39:31 +0200 Leon Romanovsky wrote:
> > > I have the eswitch mode conversion patches almost ready with the
> > > "almost" being mlx5.   
> > 
> > I wonder why do you need to change eswitch locking in mlx5?
> 
> I want DEVLINK_CMD_ESWITCH_SET to drop the DEVLINK_NL_FLAG_NO_LOCK
> marking.

+1

> 
> Other drivers are rather simple in terms of locking (bnxt, nfp,
> netdevsim) and I can replace driver locking completely with a few 
> minor changes. Other drivers have no locking (insert cry/laugh emoji).

I saw it too :)

> 
> mlx5 has layers and multiple locks, 

I would say that mlx5 has too many locks.

> if you're okay with devl_unlock() / devl_lock() inside the callback that's perfect for me.

The need of DEVLINK_NL_FLAG_NO_LOCK for eswitch is because of
questionable locking in devlink_rate_*() calls. 

If you success to remove mutex_lock from devlink_rate_nodes_check()
and devlink_rate_nodes_destroy(), you won't need devl_unlock/devl_lock
for eswitch.

Right now, the eswitch set flow doesn't suffer from races and/or other
bugs, just because of global devlink_mutex that protects unlocked parts
of devlink_nl_cmd_eswitch_set_doit().

Thanks