netdev - Re: [PATCH net-next v2 08/15] net: page_pool: add nlspec for basic access to page pools

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]

Date: Tue, 21 Nov 2023 16:33:25 -0500
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: Jakub Kicinski <kuba@...nel.org>, 
 Willem de Bruijn <willemdebruijn.kernel@...il.com>
Cc: davem@...emloft.net, 
 netdev@...r.kernel.org, 
 edumazet@...gle.com, 
 pabeni@...hat.com, 
 almasrymina@...gle.com, 
 hawk@...nel.org, 
 ilias.apalodimas@...aro.org, 
 dsahern@...il.com, 
 dtatulea@...dia.com
Subject: Re: [PATCH net-next v2 08/15] net: page_pool: add nlspec for basic
 access to page pools

Jakub Kicinski wrote:
> On Tue, 21 Nov 2023 13:24:07 -0500 Willem de Bruijn wrote:
> > Do you want to introduce a separate ID for page pools? That brings some
> > issues regarding network namespace isolation.
> > 
> > As a user API, it is also possible (and intuitive?) to refer to a
> > page_pool by (namespacified) ifindex plus netdev_rx_queue index,
> > or napi_id.
> 
> That does not work for "destroyed" pools. In general, there is
> no natural key for a page pool I can think of.

Pools for destroyed devices are attached to the loopback device.
If the netns is also destroyed, would it make sense to attach
them to the loopback device in the init namespace?

> > In fairness, napi_id is also global, not per netns.
> > 
> > By iterating over "for_each_netdev(net, ..", dump already limits
> > output to pools in the same netns and get only reports pools that
> > match the netns.
> > 
> > So it's only a minor matter of visible numbering, and perhaps
> > superfluous new id.
> 
> The IDs are not stable. Any reconfiguration of a device will create
> a new page pool and therefore assign a new ID. So applications can't
> hold onto the ID long term.
> 
> That said the only use case for exposing the ID right now is to
> implement do/GET (since there is no other unique key). And manual debug
> with drgn, but that doesn't require uAPI. So if you prefer strongly
> I can drop the ID from the uAPI and do/GET support.

No, this is fine. I just wanted to make sure that the alternative api
and netns details were considered beforehand, since it's uapi.