netdev - Re: [PATCH net-next 0/5] devlink: hold the instance lock in eswitch callbacks

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]

Date:   Fri, 18 Mar 2022 09:12:37 +0100
From:   Simon Horman <simon.horman@...igine.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     davem@...emloft.net, netdev@...r.kernel.org, jiri@...nulli.us,
        leonro@...dia.com, saeedm@...dia.com, idosch@...sch.org,
        michael.chan@...adcom.com
Subject: Re: [PATCH net-next 0/5] devlink: hold the instance lock in eswitch
 callbacks

On Wed, Mar 16, 2022 at 09:20:18PM -0700, Jakub Kicinski wrote:
> Series number 2 in the effort to hold the devlink instance lock
> in call driver callbacks. We have the following drivers using
> this API:
> 
>  - bnxt, nfp, netdevsim - their own locking is removed / simplified
>    by this series; all of them needed a lock to protect from changes
>    to the number of VFs while switching modes, now the VF config bus
>    callback takes the devlink instance lock via devl_lock();
>  - ice - appears not to allow changing modes while SR-IOV enabled,
>    so nothing to do there;
>  - liquidio - does not contain any locking;
>  - octeontx2/af - is very special but at least doesn't have locking
>    so doesn't get in the way either;
>  - mlx5 has a wealth of locks - I chickened out and dropped the lock
>    in the callbacks so that I can leave the driver be, for now.
> 
> The last one is obviously not ideal, but I would prefer to transition
> the API already as it make take longer.
> 
> LMK if it's an abuse of power / I'm not thinking straight.

Thanks Jakub,

we have reviewed this from an NFP driver perspective and are happy
with this change - it looks quite straightforward from that perspective.