From: Michael Ellerman <mpe@ellerman.id.au>
To: Christophe Leroy <christophe.leroy@csgroup.eu>,
Mathieu Malaterre <malat@debian.org>,
Nick Desaulniers <ndesaulniers@google.com>
Cc: linuxppc-dev@lists.ozlabs.org, Paul Mackerras <paulus@samba.org>,
linux-kernel@vger.kernel.org, Joel Stanley <joel@jms.id.au>
Subject: Re: [PATCH] powerpc/lib/xor_vmx: Relax frame size for clang
Date: Thu, 08 Sep 2022 10:27:19 +1000 [thread overview]
Message-ID: <87v8pyemmw.fsf@mpe.ellerman.id.au> (raw)
In-Reply-To: <7cb1285a-42e6-2b67-664f-7d206bc9fd80@csgroup.eu>
Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> Le 21/06/2019 à 10:58, Mathieu Malaterre a écrit :
>> When building with clang-8 the frame size limit is hit:
>>
>> ../arch/powerpc/lib/xor_vmx.c:119:6: error: stack frame size of 1200 bytes in function '__xor_altivec_5' [-Werror,-Wframe-larger-than=]
>>
>> Follow the same approach as commit 9c87156cce5a ("powerpc/xmon: Relax
>> frame size for clang") until a proper fix is implemented upstream in
>> clang and relax requirement for clang.
>
> With Clang 14 I get the following errors, but only with KASAN selected.
>
> CC arch/powerpc/lib/xor_vmx.o
> arch/powerpc/lib/xor_vmx.c:95:6: error: stack frame size (1040) exceeds
> limit (1024) in '__xor_altivec_4' [-Werror,-Wframe-larger-than]
> void __xor_altivec_4(unsigned long bytes,
> ^
> arch/powerpc/lib/xor_vmx.c:124:6: error: stack frame size (1312) exceeds
> limit (1024) in '__xor_altivec_5' [-Werror,-Wframe-larger-than]
> void __xor_altivec_5(unsigned long bytes,
> ^
That's a 32-bit build?
> Is this patch still relevant ?
The clang issue was closed because a different change fixed the issue:
https://github.com/ClangBuiltLinux/linux/issues/563
> Or should frame size be relaxed when KASAN is selected ? After all the
> stack size is multiplied by 2 when we have KASAN, so maybe the warning
> limit should be increased as well ?
Yeah that would make some sense.
On 64-bit the largest frame in that file is 1424, which is below the
default 2048 byte limit.
So maybe just increase it for 32-bit && KASAN.
What would be nice is if the FRAME_WARN value could be calculated as a
percentage of the THREAD_SHIFT, but that's not easily doable with the
way things are structured in Kconfig.
cheers
WARNING: multiple messages have this Message-ID (diff)
From: Michael Ellerman <mpe@ellerman.id.au>
To: Christophe Leroy <christophe.leroy@csgroup.eu>,
Mathieu Malaterre <malat@debian.org>,
Nick Desaulniers <ndesaulniers@google.com>
Cc: linux-kernel@vger.kernel.org, Paul Mackerras <paulus@samba.org>,
Joel Stanley <joel@jms.id.au>,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH] powerpc/lib/xor_vmx: Relax frame size for clang
Date: Thu, 08 Sep 2022 10:27:19 +1000 [thread overview]
Message-ID: <87v8pyemmw.fsf@mpe.ellerman.id.au> (raw)
In-Reply-To: <7cb1285a-42e6-2b67-664f-7d206bc9fd80@csgroup.eu>
Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> Le 21/06/2019 à 10:58, Mathieu Malaterre a écrit :
>> When building with clang-8 the frame size limit is hit:
>>
>> ../arch/powerpc/lib/xor_vmx.c:119:6: error: stack frame size of 1200 bytes in function '__xor_altivec_5' [-Werror,-Wframe-larger-than=]
>>
>> Follow the same approach as commit 9c87156cce5a ("powerpc/xmon: Relax
>> frame size for clang") until a proper fix is implemented upstream in
>> clang and relax requirement for clang.
>
> With Clang 14 I get the following errors, but only with KASAN selected.
>
> CC arch/powerpc/lib/xor_vmx.o
> arch/powerpc/lib/xor_vmx.c:95:6: error: stack frame size (1040) exceeds
> limit (1024) in '__xor_altivec_4' [-Werror,-Wframe-larger-than]
> void __xor_altivec_4(unsigned long bytes,
> ^
> arch/powerpc/lib/xor_vmx.c:124:6: error: stack frame size (1312) exceeds
> limit (1024) in '__xor_altivec_5' [-Werror,-Wframe-larger-than]
> void __xor_altivec_5(unsigned long bytes,
> ^
That's a 32-bit build?
> Is this patch still relevant ?
The clang issue was closed because a different change fixed the issue:
https://github.com/ClangBuiltLinux/linux/issues/563
> Or should frame size be relaxed when KASAN is selected ? After all the
> stack size is multiplied by 2 when we have KASAN, so maybe the warning
> limit should be increased as well ?
Yeah that would make some sense.
On 64-bit the largest frame in that file is 1424, which is below the
default 2048 byte limit.
So maybe just increase it for 32-bit && KASAN.
What would be nice is if the FRAME_WARN value could be calculated as a
percentage of the THREAD_SHIFT, but that's not easily doable with the
way things are structured in Kconfig.
cheers
next prev parent reply other threads:[~2022-09-08 0:28 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-21 8:58 [PATCH] powerpc/lib/xor_vmx: Relax frame size for clang Mathieu Malaterre
2019-06-21 8:58 ` Mathieu Malaterre
2022-09-07 17:21 ` Christophe Leroy
2022-09-07 17:21 ` Christophe Leroy
2022-09-08 0:27 ` Michael Ellerman [this message]
2022-09-08 0:27 ` Michael Ellerman
2022-09-08 6:00 ` Christophe Leroy
2022-09-08 6:00 ` Christophe Leroy
2022-09-08 13:48 ` Segher Boessenkool
2022-09-08 13:48 ` Segher Boessenkool
2022-09-09 5:01 ` Christophe Leroy
2022-09-09 5:01 ` Christophe Leroy
2022-09-08 15:07 ` Arnd Bergmann
2022-09-08 15:07 ` Arnd Bergmann
2022-09-08 22:40 ` Segher Boessenkool
2022-09-08 22:40 ` Segher Boessenkool
2025-08-27 17:15 ` Christophe Leroy
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=87v8pyemmw.fsf@mpe.ellerman.id.au \
--to=mpe@ellerman.id.au \
--cc=christophe.leroy@csgroup.eu \
--cc=joel@jms.id.au \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=malat@debian.org \
--cc=ndesaulniers@google.com \
--cc=paulus@samba.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.