Re: [PATCH v2] IB/mad: cap RMPP reassembly window size

[Jason Gunthorpe <jgg@nvidia.com>]

On Wed, Jun 03, 2026 at 02:20:03PM -0400, Michael Bommarito wrote:
> On Wed, Jun 3, 2026 at 1:55 PM Jason Gunthorpe <jgg@nvidia.com> wrote:
> > Why do you think it is OK to only search back 64? Where do these
> > numbers come from?
> 
> 512 >> 3 from IB_MAD_QP_RECV_SIZE in mad_priv.h and max_active.

I mean from the real world - the purpose of this window is to deal
with network re-ordering, by changing it like this we are reducing the
kinds of re-ordering the network can perform.

I think reordering is basically something that should never happen on
IB, yet 20 years ago someone decided to have huge reorder windows..

> > Is this a real issue?  It looks to me like all this code is gated by
> > IB_USER_MAD_USER_RMPP and no in-kernel user makes use of RMPP.
> 
> I originally found these issues looking for reachable quadratic
> runtimes with libclang+Claude, and these are in my notes on
> reachability.
> <CLAUDE>
>   - sa_query.c:2436: the in-kernel SA client registers its GSI agent
> with rmpp_version = IB_MGMT_RMPP_VERSION and flags = 0. So
> ib_mad_kernel_rmpp_agent() (mad.c:856) is true for it, and
> ib_process_rmpp_recv_wc()
>   → find_seg_location runs on its receive path. ib_sa is always
> loaded. Not a umad-only path.
> </CLAUDE>
> 
> So I think the reachability is wider than you expect.  Perhaps that's
> the real fix you'd prefer.

Hmmm, I didn't remember SA left it turned on. AI says it is only used
by SA IB CM service resolution which is so obscure and rarely used in
modern systems. Yet it opens this whole scary bit of code.

> > So I don't see why we should be changing this and risking regressions
> > with the window reduction?
> 
> It's obviously your choice as maintainers, but I'd encourage you to
> test the pathological worst case from an unprivileged peer to see the
> impact before totally writing it off.

I'm sure the pathological case is bad, but I don't know if lowering
the window size will somehow break something someone is using.

If it could be fixed without changing the behavior that would be more
interesting..

Also the way this works the peer sending into this isn't
unpriviledged.  On IB it is using a restricted qkey so it is supposed
to be trusted software under the 1990's security model IB uses..

Jason