From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-112.freemail.mail.aliyun.com (out30-112.freemail.mail.aliyun.com [115.124.30.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8B5163947A9; Tue, 7 Apr 2026 12:43:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.112 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775565836; cv=none; b=W/bkfn/coqpHAvkQQ9jfw8RUQ6mStHDzxU5idIyeXcvfPD+aLmrK9VaB1QwOlQ9/ZPCwvtBGp/iWRhHSr/DUKo1wVYekSKVLfpWaC59MP7K70tqJB4VJWdzauLqvQoKWI5c1dRQP/2eerWthXycWl0npUkdiGF5ICKm0suoC1Qc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775565836; c=relaxed/simple; bh=jK2MvLGx29j9EQQ0DP63tStfQnBg8ZPc1l9iRZmgfAA=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=HCDtf8YLDvExF/oePV8p7TBPBzYnff/DzIhcUrp4Aa1tqU03DCnHVlrrpn90zUwrfNWpjti3YyxKW2Q8yug6RUYXuJQfJsIxguW3XRJH0gUlXWzON9iAvGSqS4ow5QrAXCktUtOndxoAJOR8fLkQ4TnEym4WY3EtaVDpaO+v2PE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=h+d7RXO1; arc=none smtp.client-ip=115.124.30.112 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="h+d7RXO1" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1775565830; h=From:To:Subject:Date:Message-ID:MIME-Version; bh=zbxmp0ZDStE2fex5F62p/4oiNfr/O/bKD9728qyhF9s=; b=h+d7RXO1EHO1bmtXsZbHuQDeu+SFPnLvNO/92ck/w/6YoqToxO1y8ktpHlwwMklCuuEq6ZV0BliNq5roW1MBlYAiTf6cBN+OUNFTXMaSvrr9o55I9OevF7uyslAT1OyxYOwG0pWosEm16JoiBlfWE90FmFHvp35c5xz8lvhoZcg= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R181e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033045098064;MF=alibuda@linux.alibaba.com;NM=1;PH=DS;RN=17;SR=0;TI=SMTPD_---0X0boJT7_1775565817; Received: from j66a10360.sqa.eu95.tbsite.net(mailfrom:alibuda@linux.alibaba.com fp:SMTPD_---0X0boJT7_1775565817 cluster:ay36) by smtp.aliyun-inc.com; Tue, 07 Apr 2026 20:43:49 +0800 From: "D. Wythe" To: "David S. Miller" , Dust Li , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Sidraya Jayagond , Wenjia Zhang Cc: Mahanta Jambigi , Simon Horman , Tony Lu , Wen Gu , linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org, linux-s390@vger.kernel.org, netdev@vger.kernel.org, oliver.yang@linux.alibaba.com, pasic@linux.ibm.com Subject: [PATCH net-next v2] net/smc: cap allocation order for SMC-R physically contiguous buffers Date: Tue, 7 Apr 2026 20:43:37 +0800 Message-ID: <20260407124337.88128-1-alibuda@linux.alibaba.com> X-Mailer: git-send-email 2.45.0 Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit The alloc_pages() cannot satisfy requests exceeding MAX_PAGE_ORDER, and attempting such allocations will lead to guaranteed failures and potential kernel warnings. For SMCR_PHYS_CONT_BUFS, cap the allocation order to MAX_PAGE_ORDER. This ensures the attempts to allocate the largest possible physically contiguous chunk succeed, instead of failing with an invalid order. This also avoids redundant "try-fail-degrade" cycles in __smc_buf_create(). For SMCR_MIXED_BUFS, no cap is needed: if the order exceeds MAX_PAGE_ORDER, alloc_pages() will silently fail (__GFP_NOWARN) and automatically fall back to virtual memory. Signed-off-by: D. Wythe Reviewed-by: Dust Li --- Changes v1 -> v2: https://lore.kernel.org/netdev/20260312082154.36971-1-alibuda@linux.alibaba.com/ - Move the bufsize cap from smcr_new_buf_create() up to __smc_buf_create(), which is simpler and avoids touching the allocation logic itself. --- net/smc/smc_core.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/net/smc/smc_core.c b/net/smc/smc_core.c index e2d083daeb7e..cdd881746e21 100644 --- a/net/smc/smc_core.c +++ b/net/smc/smc_core.c @@ -2440,6 +2440,10 @@ static int __smc_buf_create(struct smc_sock *smc, bool is_smcd, bool is_rmb) /* use socket send buffer size (w/o overhead) as start value */ bufsize = smc->sk.sk_sndbuf / 2; + /* limit bufsize for physically contiguous buffers */ + if (!is_smcd && lgr->buf_type == SMCR_PHYS_CONT_BUFS) + bufsize = min_t(int, bufsize, (PAGE_SIZE << MAX_PAGE_ORDER)); + for (bufsize_comp = smc_compress_bufsize(bufsize, is_smcd, is_rmb); bufsize_comp >= 0; bufsize_comp--) { if (is_rmb) { -- 2.45.0