netdev - Re: [PATCH net-next V7 02/14] devlink: introduce shared devlink instance for PFs on same chip

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: <20260204180636.7ae26cb6@kernel.org>
Date: Wed, 4 Feb 2026 18:06:36 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Jiri Pirko <jiri@...nulli.us>
Cc: Tariq Toukan <tariqt@...dia.com>, Eric Dumazet <edumazet@...gle.com>,
 Paolo Abeni <pabeni@...hat.com>, Andrew Lunn <andrew+netdev@...n.ch>,
 "David S. Miller" <davem@...emloft.net>, Donald Hunter
 <donald.hunter@...il.com>, Jonathan Corbet <corbet@....net>, Saeed Mahameed
 <saeedm@...dia.com>, Leon Romanovsky <leon@...nel.org>, Mark Bloch
 <mbloch@...dia.com>, netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-doc@...r.kernel.org, linux-rdma@...r.kernel.org, Gal Pressman
 <gal@...dia.com>, Moshe Shemesh <moshe@...dia.com>, Carolina Jubran
 <cjubran@...dia.com>, Cosmin Ratiu <cratiu@...dia.com>, Jiri Pirko
 <jiri@...dia.com>, Randy Dunlap <rdunlap@...radead.org>, Simon Horman
 <horms@...nel.org>, Krzysztof Kozlowski <krzk@...nel.org>
Subject: Re: [PATCH net-next V7 02/14] devlink: introduce shared devlink
 instance for PFs on same chip

On Wed, 4 Feb 2026 08:15:21 +0100 Jiri Pirko wrote:
> >> String gives drivers flexibility to use anything. Perhaps I'm missing
> >> your point. Are you againts free-form or just string and buf+buf_len
> >> would be fine?  
> >
> >I was thinking binary buf+len is fine, and we shouldn't really expose
> >this to user space in any shape or form (hence no concern about free
> >form).  
> 
> How you imagine to name faux device then? I'm sensing that you want to
> get rid of busname/devname handle for things like this and rely on some
> randomly generated index. But the whole ecosystem is bases on
> busname/devname handle. Any idea how to overcome that?

Quoting myself form the other sub-thread:

  FWIW using devlink day to day, the bus/device is not at all useful as
  an identifier. Most of code touching devlink at Meta either matches
  on devlink dev info or assumes there's one instance on the system.

IOW I think you over-estimate the value of the bus/dev in real life
systems. And that's for instances that have a real bus/dev. Having
a faux bus/dev is completely pointless, right? The only question is
whether some code will straight up crash when seeing a device without
bus/dev.