Re: [PATCH v5 00/24] Migrate to hfi2 driver

[Jason Gunthorpe <jgg@ziepe.ca>]

On Thu, Sep 03, 2026 at 02:22:05PM -0400, Dennis Dalessandro wrote:
> On 9/3/26 1:59 PM, Jason Gunthorpe wrote:
> > On Thu, Sep 03, 2026 at 01:54:27PM -0400, Dennis Dalessandro wrote:
> > > While sharing similar bones, the chip for the Cornelis Networks next
> > > generation fabric technology has some fundamental differences that
> > > resulted in a near complete re-write of the driver. It also does not
> > > use the private cdev interface that the hfi1 driver exposes. After
> > > discussing this with the RDMA maintainers we have decided to go with
> > > the approach of moving to a new driver and declaring hfi1 obsolete.
> > > 
> > > It is desirable to keep hfi1 around temporarily to let user APIs
> > > catch up to support access through the uverbs device rather than the
> > > private hfi1 cdev.
> > > 
> > > This driver is designed to support future products as well.
> > > 
> > > Portions of this series were developed with the assistance of a large
> > > language model (LLM), reviewed and verified by the author. Each
> > > commit affected carries an "Assisted-by: LLM" trailer per
> > > Documentation/process/coding-assistants.rst.
> > > 
> > > This series applies on top of the rdma/for-next branch.
> > > 
> > > Changes since v4:
> > > - cport.c: rate-limit the "Op N SS failed" error log in cport_req_fn() and fix a
> > >    use-after-free where msg->req->hdr fields were read after cwput(msg) had
> > >    already freed msg, by moving the error log before the cwput() call.
> > > - mad.c: treat undersized CH_OP_UMAD_9B/16B payloads in cport_umad_handler() as
> > >    a normal, expected occurrence (e.g. periodic SM keep-alive/poll probes)
> > >    rather than a protocol error; count them via n_vl15_dropped and silently
> > >    drop instead of returning MSG_RSP_STATUS_INVALID_STATE, to avoid flooding
> > >    the console.
> > > - Updated the AI attribution trailer on all commits from
> > >    "Assisted-by: AGENT:MODEL" to the simplified "Assisted-by: LLM" per updated
> > >    upstream guidance.
> > 
> > There are over a hundred sashiko messages, this change log seems far
> > to small. Are you addressing them?
> 
> Those were corrected in v3. See the "Changes since v2" or is there another
> Sashiko report I need to look in to?

Yeah, you need to check every time. v4 got hundreds more. This series
got hundreds of comments too.

https://sashiko.dev/#/patchset/178845806706.2825126.2210865708266527909.stgit%40awdrv-04

You probably need to run it locally to handle something so big

Like this for example looks pretty obviously right:

 This file contains structures like diag_pkt that are meant to communicate
 between kernel and user code. Should this file be exported to include/uapi/
 instead of remaining in the internal driver directory? Keeping it in the
 internal driver directory prevents it from being exported to userspace by
 the headers_install targets.

This looks kinda serious:

 This is a pre-existing issue, but does this code allow unprivileged users to
 spoof hardware job keys via user namespaces?
 If an attacker creates a new user namespace, their global UID maps to local
 UID 0 and they gain CAP_SYS_ADMIN locally. When generate_jkey() evaluates
 from_kuid(current_user_ns(), uid), it would resolve to 0. Additionally,
 capable(CAP_SYS_ADMIN) would evaluate to true against the attacker's namespace.
 Should this use init_user_ns rather than current_user_ns() to properly
 enforce hardware tenant isolation and prevent bypassing administrative
 bounds?

And so on.

If you don't fix them now, we will be deluged by bug fix patches and I
don't want to deal with that.

Jason