From: Andrew Morton <akpm@linux-foundation.org>
To: Zhen Lei <thunder.leizhen@huawei.com>
Cc: Shuah Khan <skhan@linuxfoundation.org>,
Vitor Massaru Iha <vitor@massaru.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
Brendan Higgins <brendanhiggins@google.com>
Subject: Re: [PATCH 1/1] lib: kunit: Suppress a compilation warning of frame size
Date: Tue, 18 May 2021 14:38:18 -0700 [thread overview]
Message-ID: <20210518143818.51564964d8f6fe228cb055ee@linux-foundation.org> (raw)
In-Reply-To: <20210518094533.7652-1-thunder.leizhen@huawei.com>
On Tue, 18 May 2021 17:45:33 +0800 Zhen Lei <thunder.leizhen@huawei.com> wrote:
> lib/bitfield_kunit.c: In function ‘test_bitfields_constants’:
> lib/bitfield_kunit.c:93:1: warning: the frame size of 7456 bytes is larger than 2048 bytes [-Wframe-larger-than=]
> }
> ^
>
> As the description of BITFIELD_KUNIT in lib/Kconfig.debug, it "Only useful
> for kernel devs running the KUnit test harness, and not intended for
> inclusion into a production build". Therefore, it is not worth modifying
> variable 'test_bitfields_constants' to clear this warning. Just suppress
> it.
Well, it would be better to fix this rather than hiding it. The
warning is there for a reason!
Firstly, why is this happening? Do those macros end up generating a
vast number of `kunit_assert' instances and gcc dumbly fails to reuse
the same stack slots?
It would be trivial to split test_bitfields_constants() into four
functions. Probably those should use noinline_for_stack to prevent gcc
from just inlining everything into the caller.
Also, what's up with this?
/*
* NOTE
* This whole function compiles (or at least should, if everything
* is going according to plan) to nothing after optimisation.
*/
If that's the case then why did the function use all this stack?
> diff --git a/lib/Makefile b/lib/Makefile
> index e11cfc18b6c0826..2cc359ec1fdd3e1 100644
> --- a/lib/Makefile
> +++ b/lib/Makefile
> @@ -348,6 +348,7 @@ obj-$(CONFIG_OBJAGG) += objagg.o
> obj-$(CONFIG_PLDMFW) += pldmfw/
>
> # KUnit tests
> +CFLAGS_bitfield_kunit.o := $(call cc-option,-Wframe-larger-than=10240)
> obj-$(CONFIG_BITFIELD_KUNIT) += bitfield_kunit.o
> obj-$(CONFIG_LIST_KUNIT_TEST) += list-test.o
> obj-$(CONFIG_LINEAR_RANGES_TEST) += test_linear_ranges.o
prev parent reply other threads:[~2021-05-18 21:38 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-18 9:45 [PATCH 1/1] lib: kunit: Suppress a compilation warning of frame size Zhen Lei
2021-05-18 21:38 ` Andrew Morton [this message]
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=20210518143818.51564964d8f6fe228cb055ee@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=brendanhiggins@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=skhan@linuxfoundation.org \
--cc=thunder.leizhen@huawei.com \
--cc=vitor@massaru.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.