linux-kernel - RE: [PATCH] RDMA/siw: work around clang stack size warning

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 for Android: free password hash cracker in your pocket

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

Message-ID:
 <BN8PR15MB25132E1DD3438A333004FF39997EA@BN8PR15MB2513.namprd15.prod.outlook.com>
Date: Sun, 22 Jun 2025 13:29:17 +0000
From: Bernard Metzler <BMT@...ich.ibm.com>
To: Arnd Bergmann <arnd@...db.de>, Zhu Yanjun <yanjun.zhu@...ux.dev>,
        Arnd
 Bergmann <arnd@...nel.org>, Jason Gunthorpe <jgg@...pe.ca>,
        Leon Romanovsky
	<leon@...nel.org>,
        Nathan Chancellor <nathan@...nel.org>
CC: Nick Desaulniers <nick.desaulniers+lkml@...il.com>,
        Bill Wendling
	<morbo@...gle.com>,
        Justin Stitt <justinstitt@...gle.com>,
        Potnuri Bharat
 Teja <bharat@...lsio.com>,
        Showrya M N <showrya@...lsio.com>, Eric Biggers
	<ebiggers@...gle.com>,
        "linux-rdma@...r.kernel.org"
	<linux-rdma@...r.kernel.org>,
        "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>,
        "llvm@...ts.linux.dev" <llvm@...ts.linux.dev>
Subject: RE: [PATCH] RDMA/siw: work around clang stack size warning



> -----Original Message-----
> From: Arnd Bergmann <arnd@...db.de>
> Sent: Saturday, June 21, 2025 10:43 AM
> To: Zhu Yanjun <yanjun.zhu@...ux.dev>; Arnd Bergmann <arnd@...nel.org>;
> Bernard Metzler <BMT@...ich.ibm.com>; Jason Gunthorpe <jgg@...pe.ca>; Leon
> Romanovsky <leon@...nel.org>; Nathan Chancellor <nathan@...nel.org>
> Cc: Nick Desaulniers <nick.desaulniers+lkml@...il.com>; Bill Wendling
> <morbo@...gle.com>; Justin Stitt <justinstitt@...gle.com>; Potnuri Bharat
> Teja <bharat@...lsio.com>; Showrya M N <showrya@...lsio.com>; Eric Biggers
> <ebiggers@...gle.com>; linux-rdma@...r.kernel.org; linux-
> kernel@...r.kernel.org; llvm@...ts.linux.dev
> Subject: [EXTERNAL] Re: [PATCH] RDMA/siw: work around clang stack size
> warning
> 
> On Sat, Jun 21, 2025, at 06:12, Zhu Yanjun wrote:
> > 在 2025/6/20 4:43, Arnd Bergmann 写道:
> >
> > Because the array of kvec structures in siw_tx_hdt consumes the majority
> > of the stack space, would it be possible to use kmalloc or a similar
> > dynamic memory allocation function instead of allocating this memory on
> > the stack?
> >
> > Would using kmalloc (or an equivalent) also effectively resolve the
> > stack usage issue?
> 
> Yes, moving the allocation somewhere else (kmalloc, static variable,
> per siw_sge, per siw_wqe) would avoid the high stack usage effectively,
> it's a tradeoff and I picked the solution that made the most sense
> to me, but there is a good chance another alternative is better here.
> 
> The main differences are:
> 
> - kmalloc() adds runtime overhead that may be expensive in a
>   fast path


doing kmalloc in the fast data send path is what I clearly wanted
to avoid. The current code is a performance optimization which tries
sending the complete iwarp packet in one kernel_sendmsg() call.
A packet may comprise multiple pages referencing user data of
multiple SGE's to be send plus a packet header and a trailer CRC.
The array size reflects the maximum number of packet fragments
possible.

In the long run, I shall refactor that code to avoid the issue.
I appreciate Arnd's fix for now. I'll test and come back soon.

Many thanks,
Bernard
> 
> - kmalloc() can fail, which adds complexity from error handling.
>   Note that small allocations with GFP_KERNEL do not fail but instead
>   wait for memory to become available
> 
> - If kmalloc() runs into a low-memory situation, it can go through
>   writeback, which in turn can use more stack space than the
>   on-stack allocation it was replacing
> 
> - static allocations bloat the kernel image and require locking that
>   may be expensive
> 
> - per-object preallocations can be wasteful if a lot of objects
>   are created, and can still require locking if the object is used
>   from multiple threads
> 
> As I wrote, I mainly picked the 'noinline_for_stack' approach
> here since that is how the code is known to work with gcc, so
> there is little risk of my patch causing problems.
> 
> Moving the both the kvec array and the page array into
> the siw_wqe is likely better here, I'm not familiar enough
> with the driver to tell whether that is an overall improvement.
> 
> A related change I would like to see is to remove the
> kmap_local_page() in this driver and instead make it
> depend on 64BIT or !CONFIG_HIGHMEM, to slowly chip away
> at the code that is highmem aware throughout the kernel.
> I'm not sure if that that would also help drop the array
> here.
> 
>      Arnd