linux-kernel - Re: [PATCH net-next v6 2/2] net/smc: handle -ENOMEM from smc_wr_alloc_link

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <c1c8f18f-a74e-40c1-8090-985d31cabd1b@linux.ibm.com>
Date: Tue, 28 Oct 2025 15:04:04 +0530
From: Mahanta Jambigi <mjambigi@...ux.ibm.com>
To: Halil Pasic <pasic@...ux.ibm.com>,
        "David S. Miller"
 <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>, Simon Horman <horms@...nel.org>,
        Jonathan Corbet <corbet@....net>,
        "D. Wythe" <alibuda@...ux.alibaba.com>,
        Dust Li <dust.li@...ux.alibaba.com>,
        Sidraya Jayagond <sidraya@...ux.ibm.com>,
        Wenjia Zhang
 <wenjia@...ux.ibm.com>,
        Tony Lu <tonylu@...ux.alibaba.com>, netdev@...r.kernel.org,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-rdma@...r.kernel.org, linux-s390@...r.kernel.org
Cc: Wen Gu <guwen@...ux.alibaba.com>,
        Guangguan Wang <guangguan.wang@...ux.alibaba.com>,
        Bagas Sanjaya <bagasdotme@...il.com>
Subject: Re: [PATCH net-next v6 2/2] net/smc: handle -ENOMEM from
 smc_wr_alloc_link_mem gracefully



On 28/10/25 4:18 am, Halil Pasic wrote:
> Currently if a -ENOMEM from smc_wr_alloc_link_mem() is handled by
> giving up and going the way of a TCP fallback. This was reasonable
> before the sizes of the allocations there were compile time constants
> and reasonably small. But now those are actually configurable.
> 
> So instead of giving up, keep retrying with half of the requested size
> unless we dip below the old static sizes -- then give up! In terms of
> numbers that means we give up when it is certain that we at best would
> end up allocating less than 16 send WR buffers or less than 48 recv WR
> buffers. This is to avoid regressions due to having fewer buffers
> compared the static values of the past.
> 
> Please note that SMC-R is supposed to be an optimisation over TCP, and
> falling back to TCP is superior to establishing an SMC connection that
> is going to perform worse. If the memory allocation fails (and we
> propagate -ENOMEM), we fall back to TCP.
> 
> Preserve (modulo truncation) the ratio of send/recv WR buffer counts.
> 
> Signed-off-by: Halil Pasic <pasic@...ux.ibm.com>
> Reviewed-by: Wenjia Zhang <wenjia@...ux.ibm.com>
> Reviewed-by: Mahanta Jambigi <mjambigi@...ux.ibm.com>
> Reviewed-by: Sidraya Jayagond <sidraya@...ux.ibm.com>
> Reviewed-by: Dust Li <dust.li@...ux.alibaba.com>


Tested-by: Mahanta Jambigi <mjambigi@...ux.ibm.com>