[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <7996d21a-3e97-408b-82a3-3bad432095a2@app.fastmail.com>
Date: Sat, 09 Dec 2023 22:42:56 +0100
From: "Arnd Bergmann" <arnd@...db.de>
To: "Samuel Holland" <samuel.holland@...ive.com>,
"Nathan Chancellor" <nathan@...nel.org>,
"Conor.Dooley" <conor.dooley@...rochip.com>
Cc: "Palmer Dabbelt" <palmer@...belt.com>,
"Harry Wentland" <harry.wentland@....com>,
"Leo Li" <sunpeng.li@....com>,
"Rodrigo Siqueira" <Rodrigo.Siqueira@....com>,
linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org,
dri-devel@...ts.freedesktop.org, "Dave Airlie" <airlied@...il.com>,
Christian König <christian.koenig@....com>,
"Alex Deucher" <alexander.deucher@....com>,
"Pan Xinhui" <Xinhui.Pan@....com>,
"Daniel Vetter" <daniel@...ll.ch>, amd-gfx@...ts.freedesktop.org,
llvm@...ts.linux.dev
Subject: Re: [PATCH 3/3] drm/amd/display: Support DRM_AMD_DC_FP on RISC-V
On Sat, Dec 9, 2023, at 22:29, Samuel Holland wrote:
> On 2023-12-09 2:38 PM, Arnd Bergmann wrote:
>> On Fri, Dec 8, 2023, at 06:04, Samuel Holland wrote:
>>> On 2023-11-29 6:42 PM, Nathan Chancellor wrote:
>>>>
>>>> https://lore.kernel.org/20231019205117.GA839902@dev-arch.thelio-3990X/
>>>
>>> I also see one of these with clang 17 even with KASAN disabled:
>>>
>>> drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn32/display_mode_vba_32.c:37:6:
>>> warning: stack frame size (2208) exceeds limit (2048) in 'dml32_recalculate'
>>> [-Wframe-larger-than]
>>> void dml32_recalculate(struct display_mode_lib *mode_lib)
>>>
>>> ^
>>> 1532/2208 (69.38%) spills, 676/2208 (30.62%) variables
>>>
>>> So I'm in favor of just raising the limit for these files for clang, like you
>>> suggested in the linked thread.
>>
>> How about just adding a BUG_ON(IS_ENABLED(CONFIG_RISCV))
>> in that function? That should also avoid the build failure
>> but give a better indication of where the problem is
>> if someone actually runs into that function and triggers
>> a runtime stack overflow.
>
> Won't that break actual users of the driver, trading an unlikely but
> theoretically possible stack overflow for a guaranteed crash? The intent of this
> series is that I have one of these GPUs plugged in to a RISC-V board, and I want
> to use it.
Ah, I thought you just wanted to get it to compile cleanly
so you could use some of the more common cards. If you
are trying to run the dcn32 code specifically, then you
should definitely fix the stack usage of that function
instead.
Arnd
Powered by blists - more mailing lists