From nobody Sun May 24 22:35:56 2026 Received: from mail-qk1-f180.google.com (mail-qk1-f180.google.com [209.85.222.180]) (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 5507C30F547 for ; Wed, 20 May 2026 15:47:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.180 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779292044; cv=none; b=POlCBbfm+S8emjDtjhhteS/v8he5Mou4JtiFgS2yN4xXm2ykv9qr8V8uQf4pJEXrLuZDJrzeZAVQcR2SAMmgWK6oeNjGmVqHcE61KsxnoWEDOsunsqaPrsz5mlhEFK9afe2fVOUzdmECZrB5OTl1BF6TNGRS9i6o6AItJpFjk2g= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779292044; c=relaxed/simple; bh=/qBHlQUH0EWQ0nV7VPwajE+a+zB+kJLU/RQ4QphprPM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=XDYi69kkXDcRpUcst5WUw/Q8bDIlg4tlSnfqt7ZF88IGtqr9EeUDMme5CSIPu7D1KfrEW+GUd70U27whHGwJdSnOCAZDSHTOv6MIShgWoi/2nYPeAytqE3gMJqEUJR+vl9DPZfMon7vkDvaEnLbYZyaMKTpLpRrtaqAFuUUGwPE= 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=laOD+KBs; arc=none smtp.client-ip=209.85.222.180 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="laOD+KBs" Received: by mail-qk1-f180.google.com with SMTP id af79cd13be357-90d042fa745so863739485a.1 for ; Wed, 20 May 2026 08:47:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779292041; x=1779896841; 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=V9E8Z4P+2CqRGClc1by3kV59mWAyA9/b2lfXQSp7x+w=; b=laOD+KBszjtQhcuMJR51d5BRJx5ooqT5L4L4wV418wx+VlypO0x7uGdQF+uYMyyMIP dIMJYGXf4+gSw82pVHU8ZLyvvDZLXfIUKAVwcdTT1GUn2Uajy7doma4j1w1e0ARwySFl k3iJf9N8N+izclFDm/jP8VZgLcTIPEyEkd/FkQo6/Gre8DXwuGc9IdpbcKpNLka1n4Gw BnoLIQU1zGKJWZprAbjRWIclzRsxDAgIQVKMGEFMnARi8oyKDUje4z3M/4+5p9RprFeZ MA/OKaEUK6kFGNZWC0svWH8KZ0CCAm50WkYkYWDBt9y1WQ4cvT+XX3nZvwNPPMaYDRrr Jixw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779292041; x=1779896841; 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=V9E8Z4P+2CqRGClc1by3kV59mWAyA9/b2lfXQSp7x+w=; b=Odj/VrK7nDgl35dMLHSTVB/hmjCq/3xeX9f+OOwJ3EjgmdgwyR2wLpKuBVl5rUZAce NztKYM7iEp18O7ppmqpT8ARsNS+pt/xpKvZ2Rjv52PA4EXD4tYnDNlBJtJI4detvQP/9 F67fQvpZnZmWCSii/S71Gvtv/zfWTltJ8+qSPBmX3ingqIG9cm0OEmPjSTGOu8zXXW/2 HFHhMl3el2GQDEfGL1stU8viqRDskYOb83Qg54RnHLlbCETWuv2JBcZ9YmfX6dun1vx9 TsorRLedMochkjqnWm8kBahEsvftww2JWh0vP9S8h1Yq79orrSTIB1Fbx9BARjAwzOGN KEwA== X-Forwarded-Encrypted: i=1; AFNElJ9ORMv9FrC9OAqlud5FWZrsfIFYdvc9HgSAVVf1cpDyiMt92f6FizUnDdvSwqvXgS16eBM5yHyfikhCfrw=@vger.kernel.org X-Gm-Message-State: AOJu0YySgRqsAgbvl2naDnxjobzBBIJdzp05wx1iAe2vtreA6LTvpAiX TlXUsAW8Il785WOll7CVyh5x54P03V4n5JJ/o+NdTWNlzsreokh5Dovj X-Gm-Gg: Acq92OHGHwlF3FUTTz5GYJP1a9sgq8RBBGYWEzccBXxIvgzHA/89BnlpXxqzFZ1Z3iZ hXSEfUmJNvEGd2B3qXH3ADzKZH6gzjmOSM8bEw85BFlDnzTiTvXHXw/VyLi6MYkz9xt0qmk7+mJ rQtrvhsDnLJ9zXs9qi9wD8m5/w+ac3aEfyIvVTJSP5Y6380dPHphufPL8xHtFHH7ApKKwsSIQGb Ewaj9ahYtSI0Vrmux9sz0VxjX6yB7mKRqjdF4r0+PY32YWlfzzlNlFmTGHkRwzzl2cSqwOMa0vv ErTCGOcGidYOesR7OkFdI43KcFq9FlN6ez63u9oqclPKJIUN6yr3fFA1HQlZQDJ+t3mu88U8tHP xojUjtEVDRIDS8yFw9ii8BvT4qAKjg1YSI1563qQxZTUnWPpHB/uToEtSbKnF6XcBbEF/TktyAE cGsjV5BhBt0TJipBxN1WdTS6LqbyS93J/pw+S5AKK+Cap0kVBB+caGmUK+nApWwXupECBOCYen9 q7zDuBmbaep0DHZ2IWF X-Received: by 2002:a05:620a:2890:b0:911:449d:98c0 with SMTP id af79cd13be357-911cdd435cdmr3621704885a.7.1779292040928; Wed, 20 May 2026 08:47:20 -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 6a1803df08f44-8ca3618fe0bsm124812016d6.25.2026.05.20.08.47.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 May 2026 08:47:20 -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 v2] IB/mad: cap RMPP reassembly window size Date: Wed, 20 May 2026 11:47:15 -0400 Message-ID: <20260520154715.1457495-1-michael.bommarito@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260518212336.337104-1-michael.bommarito@gmail.com> References: <20260518212336.337104-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" find_seg_location() inserts reordered RMPP DATA segments into a per-transaction list by walking that list in reverse. The walk runs under rmpp_recv->lock in the MAD receive worker, so a large receive window makes a reversed RMPP burst expensive. The receive window comes from recv_queue.max_active. With the default recv_queue_size of 512, the window is 64. Larger tuned queues can raise the window to 1024, turning one reordered transaction into repeated long list walks and keeping the target port's MAD worker busy for milliseconds. Cap the RMPP window at 64, matching the current default. This keeps existing behavior for default configurations and prevents larger receive queues from increasing the worst-case insertion walk. 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 segments can keep the targeted port's MAD worker busy with reordered RMPP bursts, delaying other MAD processing on that port. I tested this on v7.1-rc2 under x86_64 QEMU/KVM with rxe and raw RoCEv2 packets carrying descending RMPP segment numbers. With recv_queue_size=3D8192, the unpatched kernel spent at least 1.5 ms per F=3D1024 burst in the insertion walk; the patched kernel dropped the same run to about 0.28 ms because segments outside the capped window are rejected before the list grows. A normal in-window F=3D32 RMPP exchange still completed; there are no in-tree selftests for QP1 GMP RMPP reassembly in tools/testing/selftests/drivers/net/rdma. Changes in v2: - Rewrite the commit message in shorter, plain language. - Trim the code comment to the local reason for the cap. drivers/infiniband/core/mad_rmpp.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/drivers/infiniband/core/mad_rmpp.c b/drivers/infiniband/core/m= ad_rmpp.c index 17c4c52a19e4c..0db645eb2e29b 100644 --- a/drivers/infiniband/core/mad_rmpp.c +++ b/drivers/infiniband/core/mad_rmpp.c @@ -391,9 +391,18 @@ static inline struct ib_mad_recv_buf *get_next_seg(str= uct list_head *rmpp_list, return container_of(seg->list.next, struct ib_mad_recv_buf, list); } =20 +/* + * find_seg_location() is linear in the number of queued segments. + * Keep the RMPP window at the default size so a larger receive queue + * does not also enlarge the reordered DATA insertion walk. + */ +#define IB_MAD_RMPP_MAX_WINDOW 64 + static inline int window_size(struct ib_mad_agent_private *agent) { - return max(agent->qp_info->recv_queue.max_active >> 3, 1); + int wsize =3D agent->qp_info->recv_queue.max_active >> 3; + + return clamp(wsize, 1, IB_MAD_RMPP_MAX_WINDOW); } =20 static struct ib_mad_recv_buf *find_seg_location(struct list_head *rmpp_li= st, --=20 2.53.0