From nobody Mon Jun 8 05:25:49 2026 Received: from mail-vs1-f54.google.com (mail-vs1-f54.google.com [209.85.217.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5588430D401 for ; Sat, 6 Jun 2026 20:02:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.217.54 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780776123; cv=none; b=DAvEgkQlQ3ZDe/JisUp1x9gwotz7tvoRFkjr/y48yvBV4ZXo1B/5o3cQ7ACD+bg32EN9Dtr2DzmlyMyMv2WeUEwjL+o6fT2wbx/SzoxshPhjWWzdzsnMz6k/VtOI5bHxv9ak9id0L6FE6Tah78XkwxzlJks1ADmvzHgBVu9kCF4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780776123; c=relaxed/simple; bh=UOHxgAF8eZ5R1jJ5qHXlGxP4p63cxPu0NB/XWI5KxNc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=VFopgCfWwsUD2mcYvI4DRd6MdEtqiqN70LP1HgtrS1e1h9MBnidUGdhXyRVwaRcY5uerP4cRyK9+S26QllX/avw+uFkBqoDi1LPOmQNujy2AMsiXsApigBhrMTitm7a3hqz18t6H1ha/+KOx8ZYoVbR8NXL6+38OmYDo95UKU9s= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=UdmBrRWE; arc=none smtp.client-ip=209.85.217.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="UdmBrRWE" Received: by mail-vs1-f54.google.com with SMTP id ada2fe7eead31-6cfd2b2e7b1so1091612137.2 for ; Sat, 06 Jun 2026 13:02:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780776120; x=1781380920; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=OpNv6A+DNZ1EjUzABqGpmlmVejxr2D6SXF7qHtjHT7A=; b=UdmBrRWE5gLSI8arSFmBFB7RXgzL1tw+/OFjoqBkI8q4y181RLG5mPVOGB8oiIkqpN qB68rTjGfiU8onWXgd5x7U2Jjrxzr5ZR7lICISQ4Fsnz8ZRaNWKaOtNaH1CnWnXb86Ss 3T5NEWJBpfaVrNjkdvvybzBYC/suLwNpC+9zB3j1XdNp76RpOQex8Qs2L74juQ+qkcpl L4iCHS7gCgG8CLXHks2Ge3X/Ffd45Hs4qykdUH9G90XRiaefctRbBfNKjS6kMXl+TbuA jfq18C7JJxU32ntiFvqaIi3bVVKGgYJ6qeOj6NzR8eDAPYS/TqApvfm0sX/TiRG7cCnb HC0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780776120; x=1781380920; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=OpNv6A+DNZ1EjUzABqGpmlmVejxr2D6SXF7qHtjHT7A=; b=TSRE17R43xNXZaUVljWdolhyAk+qJWAjhtrcswKOh9In22TxZLqpM0zStgy4IYauG5 Cof/LRlUi/eJAk/ntwoeG/fw+Nj2+dy/VJdCTEV0RCSjSCcnK6LcfsKc3+AHxr63UQev N6XNX22b+HXGv84/s3N7ekcVeyfHF9IRhVGMBNO2kzN+CUO7mJQ8hurN0NB3CY5uVMXS ohBPxqszEVFaDEVUZC92P/rqnK8wpMaJv2Hg/uZJD/lJOxsFgZtQdIatswiVzS1UNrWC C1IdYhXWoEI/FqkCZ3or/yY7+O/+m7/V/pJ6kIBPpg13+OPW0CjCvzYh7VIu/fb6vpdF IFOg== X-Forwarded-Encrypted: i=1; AFNElJ/orkWi9GlsN/jLO9O43COKrvLAZ+VUYcNSrknOtNOJ78y75XTNpUrks9D1G7BYXNJ/LtXN5uDnEBxvQrk=@vger.kernel.org X-Gm-Message-State: AOJu0Yyx/mXsdQX4LCwcEOQmjKPhhBXcpLVNmRZtRLMJ/tFJmK4flsU/ ujoeLeEt86SL5uNWGNjLTOh4MqObhmARlV/qwor7rkJ0w5TRhk40/h/3 X-Gm-Gg: Acq92OE6M8awsKGoo1gFUVEem8yTRhg5rGsmJWjfjqoCMxThb16GUJAGNOSOcih7bWp D23TozrRLA/vnz+NxffLPiYzemZfrZ/JL34ZoIaPMEbiWoSdIqwAXQkqG8uFNwnmxvd4cjTwjiL yux//pjV89jGqiS9AkcdiXUvLQdSUy+gOBIQPTiA84l1ITWWMKtWz4iyaXCiv8xkIUMg8D6GspW sT6l09Nvedx8hIRU7on2/oYac7ovRUTWVkTgREX4wJ6ViWNkDiypBTcl/S9Uikj+URROTF4DlRX pcoSlOeNQuI9oOS1R1ULEYCGOVxFzLwNFf91VPreg249UzM/GpevUgr3DnNiVikKGyp8fLeD+RQ Csh7hLOx0Vt6rc9uzLlPxmxpYrkri8W7z2y9ep+OIm7sXL14rcrdz2LjFbxmGg7KC4dkAAfQWsv 4YpcMGPzXzNFjsliqk42X0lLpTUTloP2TChpGsG6S8EJRSNPHz0hqsAQWxGYjHDi+v6rECa20gU iTrRmo/qTSFW13qNGAchdkdgjFmw/aeQOkT1sVjDw== X-Received: by 2002:a05:6102:2923:b0:631:4580:6a42 with SMTP id ada2fe7eead31-6ff05674bfcmr4385697137.22.1780776120001; Sat, 06 Jun 2026 13:02:00 -0700 (PDT) Received: from server0 (c-68-48-65-54.hsd1.mi.comcast.net. [68.48.65.54]) by smtp.gmail.com with ESMTPSA id af79cd13be357-9158a3d2384sm1240898485a.39.2026.06.06.13.01.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 06 Jun 2026 13:01:59 -0700 (PDT) From: Michael Bommarito To: Jason Gunthorpe , Leon Romanovsky Cc: linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, Vlad Dumitrescu , Or Har-Toov , Bob Pearson , Sean Hefty , Kees Cook Subject: [PATCH v3] IB/mad: drop unmatched RMPP responses before reassembly Date: Sat, 6 Jun 2026 16:01:55 -0400 Message-ID: <3170ff3bc389a930bb1641f2caa394a0b2241579.1780774907.git.michael.bommarito@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260520154715.1457495-1-michael.bommarito@gmail.com> References: <20260520154715.1457495-1-michael.bommarito@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Kernel-handled RMPP receive processing starts reassembly for active DATA responses before the response is matched to an outstanding send. The normal match happens later, after ib_process_rmpp_recv_wc() has either assembled a complete message or consumed the segment. That ordering lets an unsolicited response that routes to a kernel RMPP agent by the high TID bits allocate or extend RMPP receive state before the full TID and source address are checked against a real request. A reordered burst can therefore reach the receive-side insertion path even though the response would not match any send. For kernel-handled RMPP DATA responses, require the existing ib_find_send_mad() match before entering RMPP reassembly. The matcher already checks the full TID, management class and source address/GID against the agent wait, backlog and in-flight send lists. If there is no match, drop the response without creating RMPP state. This leaves the RMPP window behavior unchanged and only rejects responses that have no corresponding request. Fixes: fa619a77046b ("[PATCH] IB: Add RMPP implementation") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5-5-xhigh Signed-off-by: Michael Bommarito --- Impact: a fabric peer that can send QP1 GMP RMPP DATA responses to a kernel RMPP agent can create receive-side RMPP reassembly work before the response is matched to an outstanding send, delaying other MAD processing on that port. I tested this on v7.1-rc6 under x86_64 QEMU/KVM with rxe plus debug-only patches that host the in-kernel SA agent on soft-RoCE. A descending F=3D1024 burst to the SA agent hi_tid reached RX/MAD completion (1023 packets) but, with this patch, did not enter RMPP receive processing or the insertion walker: walks=3D0 and no continue_rmpp samples. There are no in-tree selftests for QP1 GMP RMPP reassembly in tools/testing/selftests/rdma. Changes in v3: - Replace the RMPP window cap with a pre-reassembly response match. - Leave the accepted RMPP reordering window unchanged. drivers/infiniband/core/mad.c | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git a/drivers/infiniband/core/mad.c b/drivers/infiniband/core/mad.c index 8d19613179e3e..e0b3b36b8b149 100644 --- a/drivers/infiniband/core/mad.c +++ b/drivers/infiniband/core/mad.c @@ -2031,6 +2031,24 @@ void ib_mark_mad_done(struct ib_mad_send_wr_private = *mad_send_wr) change_mad_state(mad_send_wr, IB_MAD_STATE_EARLY_RESP); } =20 +static bool is_kernel_rmpp_data_response(struct ib_mad_agent_private *agen= t, + struct ib_mad_recv_wc *mad_recv_wc) +{ + const struct ib_mad_hdr *mad_hdr =3D &mad_recv_wc->recv_buf.mad->mad_hdr; + struct ib_rmpp_mad *rmpp_mad; + + if (!ib_mad_kernel_rmpp_agent(&agent->agent) || + !ib_response_mad(mad_hdr) || + !ib_is_mad_class_rmpp(mad_hdr->mgmt_class)) + return false; + + rmpp_mad =3D (struct ib_rmpp_mad *)mad_recv_wc->recv_buf.mad; + + return (ib_get_rmpp_flags(&rmpp_mad->rmpp_hdr) & + IB_MGMT_RMPP_FLAG_ACTIVE) && + rmpp_mad->rmpp_hdr.rmpp_type =3D=3D IB_MGMT_RMPP_TYPE_DATA; +} + static void ib_mad_complete_recv(struct ib_mad_agent_private *mad_agent_pr= iv, struct ib_mad_recv_wc *mad_recv_wc) { @@ -2050,6 +2068,18 @@ static void ib_mad_complete_recv(struct ib_mad_agent= _private *mad_agent_priv, } =20 list_add(&mad_recv_wc->recv_buf.list, &mad_recv_wc->rmpp_list); + if (is_kernel_rmpp_data_response(mad_agent_priv, mad_recv_wc)) { + spin_lock_irqsave(&mad_agent_priv->lock, flags); + mad_send_wr =3D ib_find_send_mad(mad_agent_priv, mad_recv_wc); + spin_unlock_irqrestore(&mad_agent_priv->lock, flags); + + if (!mad_send_wr) { + ib_free_recv_mad(mad_recv_wc); + deref_mad_agent(mad_agent_priv); + return; + } + } + if (ib_mad_kernel_rmpp_agent(&mad_agent_priv->agent)) { mad_recv_wc =3D ib_process_rmpp_recv_wc(mad_agent_priv, mad_recv_wc); --=20 2.53.0