netdev - Re: [patch net-next 0/7] devlink: sanitize per-port region creation/destruction

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: <YwnKOvs3xtIyDxiS@nanopsycho>
Date:   Sat, 27 Aug 2022 09:39:38 +0200
From:   Jiri Pirko <jiri@...nulli.us>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     netdev@...r.kernel.org, davem@...emloft.net, pabeni@...hat.com,
        edumazet@...gle.com, andrew@...n.ch, vivien.didelot@...il.com,
        f.fainelli@...il.com, olteanv@...il.com, tariqt@...dia.com,
        moshe@...dia.com, saeedm@...dia.com
Subject: Re: [patch net-next 0/7] devlink: sanitize per-port region
 creation/destruction

Sat, Aug 27, 2022 at 02:22:43AM CEST, kuba@...nel.org wrote:
>On Fri, 26 Aug 2022 10:21:25 +0200 Jiri Pirko wrote:
>>> The point of exposing the devlink lock was to avoid forcing drivers 
>>> to order object registration in a specific way. I don't like.  
>> 
>> Well for params, we are also forcing them in a specific way. The
>> regions, with the DSA exception which is not voluntary, don't need to be
>> created/destroyed during devlink/port being registered.
>> 
>> I try to bring some order to the a bit messy devlink world. The
>> intention is to make everyone's live happier :)
>
>The way I remember it - we had to keep the ordering on resources for
>mlx4 because of complicated locking/async nature of events, and since
>it's a driver for a part which is much EoL we won't go back now and do
>major surgery, that's fine.
>
>But that shouldn't mean that the recommended way of using resources is
>"hook them up before register". The overall devlink locking ordering
>should converge towards the "hold devl_lock() around registration of
>your components, or whenever the device goes out of consistent state".

As you wish.