[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <34d9d8f7-384e-4447-90e2-7c6694ecbb05@huawei.com>
Date: Thu, 12 Jun 2025 21:09:40 +0800
From: Jijie Shao <shaojijie@...wei.com>
To: Arnd Bergmann <arnd@...db.de>, Arnd Bergmann <arnd@...nel.org>, Jian Shen
<shenjian15@...wei.com>, Salil Mehta <salil.mehta@...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>
CC: <shaojijie@...wei.com>, 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 <netdev@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, <llvm@...ts.linux.dev>
Subject: Re: [PATCH] hns3: work around stack size warning
on 2025/6/12 0:36, Arnd Bergmann wrote:
> On Wed, Jun 11, 2025, at 04:10, Jijie Shao wrote:
>> on 2025/6/10 17:21, Arnd Bergmann wrote:
>>> From: Arnd Bergmann <arnd@...db.de>
>>> Annotate hns3_dbg_tx_spare_info() as noinline_for_stack to force the
>>> behavior that gcc has, regardless of the compiler.
>>>
>>> Ideally all the functions in here would be changed to avoid on-stack
>>> output buffers.
>> Would you please help test whether the following changes have solved
>> your problem,
>> And I'm not sure if this patch should be sent to net or net-next...
> Your patch arrived with whitespace corruption here, so I could not
> try it, but I'm sure it would help avoid the warning.
>
> However, this is not what meant with my suggestion: you already
> allocate a temporary buffer in hns3_dbg_open() and I would
> expect it to be possible to read into that buffer directly
> without a second temporary buffer (on stack or kmalloc).
>
> The normal way of doing this would be to use the infrastructure
> from seq_file and then seq_printf() and not have any extra buffers
> on top of that.
>
> Arnd
Hi,
seq_file is good. But the change is quite big.
I need to discuss it internally, and it may not be completed so quickly.
I will also need consider the maintainer's suggestion.
Thanks,
Jijie Shao
Powered by blists - more mailing lists