linux-kernel - 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]

Message-ID: <20211108080918.2214996c@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date:   Mon, 8 Nov 2021 08:09:18 -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 Sun, 7 Nov 2021 19:54:20 +0200 Leon Romanovsky wrote:
> > >  (3) should we let drivers take refs on the devlink instance?  
> > 
> > I think it's fine mainly because I don't expect it to be used by too
> > many drivers other than netdevsim which is somewhat special. Looking at
> > the call sites of devlink_get() in netdevsim, it is only called from
> > places (debugfs and trap workqueue) that shouldn't be present in real
> > drivers.  
> 
> Sorry, I'm obligated to ask. In which universe is it ok to create new
> set of API that no real driver should use?

I think it's common sense. We're just exporting something to make our
lives easier somewhere else in the three. Do you see a way in which
taking refs on devlink can help out-of-tree code?

BTW we can put the symbols in a namespace or under a kconfig, to aid
reviews of drivers using them if you want.