netdev - Re: [PATCH 3/8] fwctl: FWCTL_INFO to return basic information about the device

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: <20240613234002.GH19897@nvidia.com>
Date: Thu, 13 Jun 2024 20:40:02 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: Dave Jiang <dave.jiang@...el.com>
Cc: Jonathan Corbet <corbet@....net>, Itay Avraham <itayavr@...dia.com>,
	Jakub Kicinski <kuba@...nel.org>, Leon Romanovsky <leon@...nel.org>,
	linux-doc@...r.kernel.org, linux-rdma@...r.kernel.org,
	netdev@...r.kernel.org, Paolo Abeni <pabeni@...hat.com>,
	Saeed Mahameed <saeedm@...dia.com>,
	Tariq Toukan <tariqt@...dia.com>,
	Andy Gospodarek <andrew.gospodarek@...adcom.com>,
	Aron Silverton <aron.silverton@...cle.com>,
	Dan Williams <dan.j.williams@...el.com>,
	David Ahern <dsahern@...nel.org>,
	Christoph Hellwig <hch@...radead.org>, Jiri Pirko <jiri@...dia.com>,
	Leonid Bloch <lbloch@...dia.com>,
	Leon Romanovsky <leonro@...dia.com>, linux-cxl@...r.kernel.org,
	patches@...ts.linux.dev
Subject: Re: [PATCH 3/8] fwctl: FWCTL_INFO to return basic information about
 the device

On Thu, Jun 13, 2024 at 04:32:44PM -0700, Dave Jiang wrote:

> Are you open to pass in potential user input for the info query? I'm
> working on plumbing fwctl for CXL. 

Neat!

> The current CXL query command [1] takes a number of commands as
> input for its ioctl. For fwctl_cmd_info(), the current
> implementation is when ->info() is called no information about the
> user buffer length or an input buffer is provided. 

Right, the purpose of info is to report information about the fwctl
driver. It is to allow the userspace to connect to the correct
userspace driver. It shouldn't be doing much with the device.

If you want to execute a info command *to the fw* then I'd expect
you'd execute the command through the normal RPC channel? Does
something prevent this?

This is how the mlx5 driver is working where there are many info
(called CAP) commands that return data, and they all run over the rpc
channel.

Thanks,
Jason