linux-kernel - Re: [PATCH net-next] IB/hfi1: allocate dummy net

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240311112532.71f1cb35@kernel.org>
Date: Mon, 11 Mar 2024 11:25:32 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Leon Romanovsky <leon@...nel.org>
Cc: Breno Leitao <leitao@...ian.org>, Dennis Dalessandro
 <dennis.dalessandro@...nelisnetworks.com>, Jason Gunthorpe <jgg@...pe.ca>,
 keescook@...omium.org, "open list:HFI1 DRIVER"
 <linux-rdma@...r.kernel.org>, open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net-next] IB/hfi1: allocate dummy net_device dynamically

On Mon, 11 Mar 2024 12:22:51 +0200 Leon Romanovsky wrote:
> > From my experience, you can leverage all the helpers to deal with the
> > relationship between struct net_device and you private structure. Here
> > are some examples that comes to my mind:
> > 
> > * alloc_netdev() allocates the private structure for you
> > * netdev_priv() gets the private structure for you
> > * dev->priv_destructor sets the destructure to be called when the
> >   interface goes away or failures.  
> 
> Everything above is true, but it doesn't relevant to HFI1 devices which
> are not netdev devices.

Why are they abusing struct net_device then?
If you're willing to take care of removing the use of NAPI from this
driver completely, that'd be great.

> > > Will it create multiple "dummy" netdev in the system? Will all devices
> > > have the same "dummy" name?  
> > 
> > Are these devices visible to userspace?  
> 
> HFI devices yes, dummy device no.
> 
> > 
> > This allocation are using NET_NAME_UNKNOWN, which implies that the
> > device is not expose to userspace.  
> 
> Great
> 
> > 
> > Would you prefer a different name?  
> 
> I prefer to see some new wrapper over plain alloc_netdev, which will
> create this dummy netdevice. For example, alloc_dummy_netdev(...).

Nope, no bona fide APIs for hacky uses.