[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <fdce9233-b547-43c9-aea9-3038a1a84a1d@app.fastmail.com>
Date: Fri, 25 Nov 2022 11:09:48 +0100
From: "Arnd Bergmann" <arnd@...db.de>
To: "Lee Jones" <lee@...nel.org>,
"Andrew Morton" <akpm@...ux-foundation.org>,
"Nathan Chancellor" <nathan@...nel.org>,
"Maarten Lankhorst" <maarten.lankhorst@...ux.intel.com>,
mripard@...nel.org, "Thomas Zimmermann" <tzimmermann@...e.de>,
"Dave Airlie" <airlied@...il.com>,
"Daniel Vetter" <daniel@...ll.ch>,
"Nick Desaulniers" <ndesaulniers@...gle.com>,
"Tom Rix" <trix@...hat.com>,
"Harry Wentland" <harry.wentland@....com>,
"Leo Li" <sunpeng.li@....com>,
"Rodrigo Siqueira" <Rodrigo.Siqueira@....com>,
"Alex Deucher" <alexander.deucher@....com>,
Christian König <christian.koenig@....com>,
Xinhui.Pan@....com
Cc: linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
llvm@...ts.linux.dev, amd-gfx@...ts.freedesktop.org,
dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH 1/3] drm/amd/display/dc/calcs/dce_calcs: Break-out a stack-heavy
chunk of code
On Fri, Nov 25, 2022, at 10:25, Lee Jones wrote:
> bw_calcs() presently blows the stack-frame limit by calling functions
> inside a argument list which return quite a bit of data to be passed
> onto sub-functions. Simply breaking out this hunk reduces the
> stack-frame use by 500 Bytes, preventing the following compiler
> warning:
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/dml/calcs/dce_calcs.c:3285:6:
> warning: stack frame size (1384) exceeds limit (1024)
> in 'bw_calcs' [-Wframe-larger-than]
> bool bw_calcs(struct dc_context *ctx,
> ^
> 1 warning generated.
>
> This resolves the issue and takes us one step closer towards a
> successful allmodconfig WERROR build.
>
> Signed-off-by: Lee Jones <lee@...nel.org>
Is this still needed with the patch to turn off the display engine
on most architectures? On which architecture and with which compiler
do you still observe the problem?
Note that this probably doesn't actually solve the potential stack
overflow by itself, since the function that is now split out
is still called with the parent stack active. Splitting out multiple
smaller bits however would solve it since then the stack frames
could overlap.
Arnd
Powered by blists - more mailing lists