netdev - Re: [RFC v1 17/22] netdev: add support for setting rx-buf-len per queue

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: <20250801163723.1c0facf9@kernel.org>
Date: Fri, 1 Aug 2025 16:37:23 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Mina Almasry <almasrymina@...gle.com>
Cc: Pavel Begunkov <asml.silence@...il.com>, netdev@...r.kernel.org,
 io-uring@...r.kernel.org, Eric Dumazet <edumazet@...gle.com>, Willem de
 Bruijn <willemb@...gle.com>, Paolo Abeni <pabeni@...hat.com>,
 andrew+netdev@...n.ch, horms@...nel.org, davem@...emloft.net,
 sdf@...ichev.me, dw@...idwei.uk, michael.chan@...adcom.com,
 dtatulea@...dia.com, ap420073@...il.com
Subject: Re: [RFC v1 17/22] netdev: add support for setting rx-buf-len per
 queue

On Mon, 28 Jul 2025 16:10:36 -0700 Mina Almasry wrote:
> I don't see this used anywhere.

Good catch, I think I was planning to reuse the full structs from
ethtool. And when I gave up I forgot to re-implement the checks.

> But more generally, I'm a bit concerned about protecting drivers that
> don't support configuring one particular queue config. I think likely
> supported_ring_params needs to be moved earlier to the patch which
> adds per queue netdev_configs to the queue API, and probably as part
> of that patch core needs to make sure it's never asking a driver that
> doesn't support changing a netdev_queue_config to do so?

I may be missing your point, but the "supported_params" flags are just
an internal kernel thing. Based on our rich experience of drivers not
validating inputs the "supported" flags just tell the core that a driver
will pay attention to the member of a struct. We can add new members
without having to go over all existing drivers to add input validation.

The flag doesn't actually say anything about particular configuration
being... well.. supported. It's just that the driver promises to
interpret it.

> Some thought may be given to moving the entire configuration story
> outside of queue_mem_alloc/free queue_start/stop altogether to new
> ndos where core can easily check if the ndo is supported otherwise
> per-queue config is not supported. Otherwise core needs to be careful
> never to attempt a config that is not supported?

The configuration is of the queues. The queue configuration belongs in
the queue APIs.