[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2a565f22-b8ba-409a-8551-91cf86788657@lunn.ch>
Date: Tue, 10 Jun 2025 18:08:41 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Arnd Bergmann <arnd@...nel.org>
Cc: Jian Shen <shenjian15@...wei.com>, Salil Mehta <salil.mehta@...wei.com>,
Jijie Shao <shaojijie@...wei.com>,
Andrew Lunn <andrew+netdev@...n.ch>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
Nathan Chancellor <nathan@...nel.org>,
Arnd Bergmann <arnd@...db.de>,
Nick Desaulniers <nick.desaulniers+lkml@...il.com>,
Bill Wendling <morbo@...gle.com>,
Justin Stitt <justinstitt@...gle.com>, Hao Lan <lanhao@...wei.com>,
Guangwei Zhang <zhangwangwei6@...wei.com>, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, llvm@...ts.linux.dev
Subject: Re: [PATCH] hns3: work around stack size warning
On Tue, Jun 10, 2025 at 11:21:08AM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@...db.de>
>
> The hns3 debugfs functions all use an extra on-stack buffer to store
> temporary text output before copying that to the debugfs file.
>
> In some configurations with clang, this can trigger the warning limit
> for the total stack size:
>
> drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c:788:12: error: stack frame size (1456) exceeds limit (1280) in 'hns3_dbg_tx_queue_info' [-Werror,-Wframe-larger-than]
>
> The problem here is that both hns3_dbg_tx_spare_info() and
> hns3_dbg_tx_queue_info() have a large on-stack buffer, and clang decides
> to inline them into a single function.
>
> Annotate hns3_dbg_tx_spare_info() as noinline_for_stack to force the
> behavior that gcc has, regardless of the compiler.
This warning is about the potential to exceed the stack space. That
potential still exists because of the tail call from
hns3_dbg_tx_queue_info() to hns3_dbg_tx_spare_info(), preventing the
compile from inlining does nothing against that.
> Ideally all the functions in here would be changed to avoid on-stack
> output buffers.
That would be my preference as well. Lets give Huawei a bit of time to
rewrite this code.
Andrew
Powered by blists - more mailing lists