From: Simon Horman <horms@kernel.org>
To: "D. Wythe" <alibuda@linux.alibaba.com>
Cc: "David S. Miller" <davem@davemloft.net>,
Dust Li <dust.li@linux.alibaba.com>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Sidraya Jayagond <sidraya@linux.ibm.com>,
Wenjia Zhang <wenjia@linux.ibm.com>,
Mahanta Jambigi <mjambigi@linux.ibm.com>,
Tony Lu <tonylu@linux.alibaba.com>,
Wen Gu <guwen@linux.alibaba.com>,
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: Re: [PATCH net-next v2] net/smc: cap allocation order for SMC-R physically contiguous buffers
Date: Tue, 14 Apr 2026 18:16:55 +0100 [thread overview]
Message-ID: <20260414171655.GB772670@horms.kernel.org> (raw)
In-Reply-To: <20260414021054.GA111420@j66a10360.sqa.eu95>
On Tue, Apr 14, 2026 at 10:10:54AM +0800, D. Wythe wrote:
> On Fri, Apr 10, 2026 at 04:16:31PM +0100, Simon Horman wrote:
> > On Tue, Apr 07, 2026 at 08:43:37PM +0800, D. Wythe wrote:
> > > 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 <alibuda@linux.alibaba.com>
> > > Reviewed-by: Dust Li <dust.li@linux.alibaba.com>
> > > ---
> > > 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.
> >
> > The nit below notwithstanding, this looks good to me.
> >
> > Reviewed-by: Simon Horman <horms@kernel.org>
> >
> > > ---
> > > 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));
> >
> > nit: I think min() is sufficient here, and the inner parentheses are
> > unnecessary
>
> Hi Simon,
>
> I think min_t is required here because min() triggers a signedness
> error:
>
> ././include/linux/compiler_types.h:706:38: error: call to
> ‘__compiletime_assert_950’ declared with attribute error: min(bufsize,
> ((1UL) << 12) << 10) signedness error
>
> The inner parentheses can be removed, though.
Ack, thanks for checking.
next prev parent reply other threads:[~2026-04-14 17:17 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-07 12:43 [PATCH net-next v2] net/smc: cap allocation order for SMC-R physically contiguous buffers D. Wythe
2026-04-10 15:16 ` Simon Horman
2026-04-14 2:10 ` D. Wythe
2026-04-14 17:16 ` Simon Horman [this message]
2026-04-16 11:41 ` Sidraya Jayagond
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260414171655.GB772670@horms.kernel.org \
--to=horms@kernel.org \
--cc=alibuda@linux.alibaba.com \
--cc=davem@davemloft.net \
--cc=dust.li@linux.alibaba.com \
--cc=edumazet@google.com \
--cc=guwen@linux.alibaba.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=mjambigi@linux.ibm.com \
--cc=netdev@vger.kernel.org \
--cc=oliver.yang@linux.alibaba.com \
--cc=pabeni@redhat.com \
--cc=pasic@linux.ibm.com \
--cc=sidraya@linux.ibm.com \
--cc=tonylu@linux.alibaba.com \
--cc=wenjia@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.