From: Nathan Chancellor <nathan@kernel.org>
To: Harry Wentland <harry.wentland@amd.com>,
Greg KH <gregkh@linuxfoundation.org>
Cc: "Alex Deucher" <alexdeucher@gmail.com>,
"Chaitanya Dhere" <chaitanya.dhere@amd.com>,
"Jun Lei" <jun.lei@amd.com>, "Leo Li" <sunpeng.li@amd.com>,
"Rodrigo Siqueira" <Rodrigo.Siqueira@amd.com>,
"Alex Deucher" <alexander.deucher@amd.com>,
"Christian König" <christian.koenig@amd.com>,
"Xinhui Pan" <Xinhui.Pan@amd.com>,
amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
llvm@lists.linux.dev, patches@lists.linux.dev,
"kernel test robot" <lkp@intel.com>
Subject: Re: [PATCH] drm/amd/display: Increase sanitizer frame larger than limit when compile testing with clang
Date: Thu, 30 Jan 2025 10:51:03 -0700 [thread overview]
Message-ID: <20250130175103.GA3394637@ax162> (raw)
In-Reply-To: <5d1cfcee-b575-4e01-8ec0-dd1bcbba9bc0@amd.com>
Hey Greg and Harry,
On Thu, Jan 30, 2025 at 11:02:37AM -0500, Harry Wentland wrote:
> On 2025-01-30 02:04, Greg KH wrote:
> > On Thu, Jan 30, 2025 at 07:47:59AM +0100, Greg KH wrote:
> > > Thanks, but I am still getting this error on Linus's current tree right
> > > now, with this commit applied:
> > >
> > > CC [M] drivers/gpu/drm/amd/amdgpu/../display/dc/dml2/display_mode_core.o
> > > drivers/gpu/drm/amd/amdgpu/../display/dc/dml2/display_mode_core.c:6713:12: error: stack frame size (2056) exceeds limit (2048) in 'dml_core_mode_support' [-Werror,-Wframe-larger-than]
> > > 6713 | dml_bool_t dml_core_mode_support(struct display_mode_lib_st *mode_lib)
> > > | ^
> > > 1 error generated.
Bummer, that means that commit a8d42cd228ec ("drm/amd/display: mark
static functions noinline_for_stack") did not help this case like I had
hoped that it would.
> > > I think the issue is:
> > >
> > > > > --- a/drivers/gpu/drm/amd/display/dc/dml2/Makefile
> > > > > +++ b/drivers/gpu/drm/amd/display/dc/dml2/Makefile
> > > > > @@ -29,7 +29,11 @@ dml2_rcflags := $(CC_FLAGS_NO_FPU)
> > > > >
> > > > > ifneq ($(CONFIG_FRAME_WARN),0)
> > > > > ifeq ($(filter y,$(CONFIG_KASAN)$(CONFIG_KCSAN)),y)
> > >
> > > I do not have CONFIG_KASAN or CONFIG_KCSAN enabled, but I do have:
> > >
> > > > > +ifeq ($(CONFIG_CC_IS_CLANG)$(CONFIG_COMPILE_TEST),yy)
> > >
> > > These two options enabled, and for some reason:
> > > CONFIG_FRAME_WARN=2048
> > > as well.
> > >
> > > Ah, 2048 is the default value, that's how.
> > >
> > > So this warning triggers even without KASAN or KCSAN being enabled, is
> > > that to be expected? Is the stack really being used that much here?
It is entirely possible. Look at how many parameters there are to some
of these functions, which have to be passed on the stack when the
compiler runs out of registers. When I looked into this at one point,
GCC was barely doing better than Clang in certain configurations. What
version of clang is this and would you mind sharing your configuration?
> > > I'll go bump FRAME_WARN up to get some local testing working again, but
> > > odds are others are going to hit this if I am in my "normal" build
> > > tests.
> >
> > Ick, no, bumping CONFIG_FRAME_WARN=8192 doesn't fix this here either.
> > Any hints?
> >
>
> It looks like we always override CONFIG_FRAME_WARN...
>
> > ifneq ($(CONFIG_FRAME_WARN),0)
> > ifeq ($(filter y,$(CONFIG_KASAN)$(CONFIG_KCSAN)),y)
> > ifeq ($(CONFIG_CC_IS_CLANG)$(CONFIG_COMPILE_TEST),yy)
> > frame_warn_flag := -Wframe-larger-than=4096
> > else
> > frame_warn_flag := -Wframe-larger-than=3072
> > endif
> > else
> > frame_warn_flag := -Wframe-larger-than=2048
>
> ... right here for the default case.
>
> You could bump that locally.
>
> A more robust solution would be to do a greater-than check here
> (for all the cases) and only set -Wframe-larger-than if the value
> is greater than the one defined by CONFIG_FRAME_WARN. There are
> a few "-gt" uses in other Makefiles, so I would think it's fine
> to use that.
>
> I'm no Makefile expert but if this seems like a reasonable course
> of action I can take a stab at it.
Something like this would work I think? I added indentation because it
was getting a little gnarly. I am happy to write a formal patch and send
it off if this looks acceptable.
diff --git a/drivers/gpu/drm/amd/display/dc/dml/Makefile b/drivers/gpu/drm/amd/display/dc/dml/Makefile
index 46f9c05de16e..e1d500633dfa 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dml/Makefile
@@ -29,11 +29,15 @@ dml_ccflags := $(CC_FLAGS_FPU)
dml_rcflags := $(CC_FLAGS_NO_FPU)
ifneq ($(CONFIG_FRAME_WARN),0)
-ifeq ($(filter y,$(CONFIG_KASAN)$(CONFIG_KCSAN)),y)
-frame_warn_flag := -Wframe-larger-than=3072
-else
-frame_warn_flag := -Wframe-larger-than=2048
-endif
+ ifeq ($(filter y,$(CONFIG_KASAN)$(CONFIG_KCSAN)),y)
+ frame_warn_limit := 3072
+ else
+ frame_warn_limit := 2048
+ endif
+
+ ifeq ($(call test-lt, $(CONFIG_FRAME_WARN), $(frame_warn_limit)),y)
+ frame_warn_flag := -Wframe-larger-than=$(frame_warn_limit)
+ endif
endif
CFLAGS_$(AMDDALPATH)/dc/dml/display_mode_lib.o := $(dml_ccflags)
diff --git a/drivers/gpu/drm/amd/display/dc/dml2/Makefile b/drivers/gpu/drm/amd/display/dc/dml2/Makefile
index 91c4f3b4bd5f..21fd466dba26 100644
--- a/drivers/gpu/drm/amd/display/dc/dml2/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dml2/Makefile
@@ -28,15 +28,19 @@ dml2_ccflags := $(CC_FLAGS_FPU)
dml2_rcflags := $(CC_FLAGS_NO_FPU)
ifneq ($(CONFIG_FRAME_WARN),0)
-ifeq ($(filter y,$(CONFIG_KASAN)$(CONFIG_KCSAN)),y)
-ifeq ($(CONFIG_CC_IS_CLANG)$(CONFIG_COMPILE_TEST),yy)
-frame_warn_flag := -Wframe-larger-than=4096
-else
-frame_warn_flag := -Wframe-larger-than=3072
-endif
-else
-frame_warn_flag := -Wframe-larger-than=2048
-endif
+ ifeq ($(filter y,$(CONFIG_KASAN)$(CONFIG_KCSAN)),y)
+ ifeq ($(CONFIG_CC_IS_CLANG)$(CONFIG_COMPILE_TEST),yy)
+ frame_warn_limit := 4096
+ else
+ frame_warn_limit := 3072
+ endif
+ else
+ frame_warn_limit := 2048
+ endif
+
+ ifeq ($(call test-lt, $(CONFIG_FRAME_WARN), $(frame_warn_limit)),y)
+ frame_warn_flag := -Wframe-larger-than=$(frame_warn_limit)
+ endif
endif
subdir-ccflags-y += -I$(FULL_AMD_DISPLAY_PATH)/dc/dml2
next prev parent reply other threads:[~2025-01-30 17:51 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-19 23:46 [PATCH] drm/amd/display: Increase sanitizer frame larger than limit when compile testing with clang Nathan Chancellor
2025-01-06 17:29 ` Alex Deucher
2025-01-30 6:47 ` Greg KH
2025-01-30 7:04 ` Greg KH
2025-01-30 16:02 ` Harry Wentland
2025-01-30 17:51 ` Nathan Chancellor [this message]
2025-01-30 19:16 ` Harry Wentland
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250130175103.GA3394637@ax162 \
--to=nathan@kernel.org \
--cc=Rodrigo.Siqueira@amd.com \
--cc=Xinhui.Pan@amd.com \
--cc=alexander.deucher@amd.com \
--cc=alexdeucher@gmail.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=chaitanya.dhere@amd.com \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=gregkh@linuxfoundation.org \
--cc=harry.wentland@amd.com \
--cc=jun.lei@amd.com \
--cc=lkp@intel.com \
--cc=llvm@lists.linux.dev \
--cc=patches@lists.linux.dev \
--cc=sunpeng.li@amd.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox