error: the frame size of 1552 bytes is larger than 1280 bytes when building bcachefs

error: the frame size of 1552 bytes is larger than 1280 bytes when building bcachefs

[Peng Fan]

Hi Kent, Arnd

There is below build error with "make ARCH=arm randconfig; make"

fs/bcachefs/data_update.c: In function '__bch2_data_update_index_update':
fs/bcachefs/data_update.c:439:1: error: the frame size of 1552 bytes is larger than 1280 bytes [-Werror=frame-larger-than=]
  439 | }
      | ^
cc1: all warnings being treated as errors
make[4]: *** [scripts/Makefile.build:203: fs/bcachefs/data_update.o] Error 1
make[3]: *** [scripts/Makefile.build:461: fs/bcachefs] Error 2
make[2]: *** [scripts/Makefile.build:461: fs] Error 2
make[1]: *** [/home/nxa18884/linux/linux-next/Makefile:2006: .] Error 2
make: *** [Makefile:248: __sub-make] Error 2


Toolchain:
arm-poky-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-poky-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/opt/fsl-imx-internal-xwayland/6.6-scarthgap/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/13.3.0/lto-wrapper
Target: arm-poky-linux-gnueabi
Configured with: ../../../../../../work-shared/gcc-13.3.0-r0/gcc-13.3.0/configure --build=x86_64-linux --host=x86_64-pokysdk-linux --target=arm-poky-linux-gnueabi --prefix=/usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-pokysdk-linux/usr --exec_prefix=/usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-pokysdk-linux/usr --bindir=/usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi --sbindir=/usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi --libexecdir=/usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi --datadir=/usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-pokysdk-linux/usr/share --sysconfdir=/usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-pokysdk-linux/etc --sharedstatedir=/usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-pokysdk-linux/com --localstatedir=/usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-pokysdk-linux/var --libdir=/usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-pokysdk-linux/usr/lib/arm-poky-linux-gnueabi --includedir=/usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-pokysdk-linux/usr/include --oldincludedir=/usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-pokysdk-linux/usr/include --infodir=/usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-pokysdk-linux/usr/share/info --mandir=/usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-pokysdk-linux/usr/share/man --disable-silent-rules --disable-dependency-tracking --with-libtool-sysroot=/home/bamboo/bamboo-agent-home/xml-data/build-dir/IMXYOCTO-SDK-MX6QPDL/112/build/tmp/work/x86_64-nativesdk-pokysdk-linux/gcc-cross-canadian-arm/13.3.0/recipe-sysroot --with-gnu-ld --enable-shared --enable-languages=c,c++ --enable-threads=posix --enable-multilib --enable-default-pie --enable-c99 --enable-long-long --enable-symvers=gnu --enable-libstdcxx-pch --program-prefix=arm-poky-linux-gnueabi- --without-local-prefix --disable-install-libiberty --disable-libssp --enable-libitm --enable-lto --disable-bootstrap --with-system-zlib --with-linker-hash-style=gnu --enable-linker-build-id --with-ppl=no --with-cloog=no --enable-checking=release --enable-cheaders=c_global --without-isl --with-gxx-include-dir=/not/exist/usr/include/c++/13.3.0 --with-build-time-tools=/home/bamboo/bamboo-agent-home/xml-data/build-dir/IMXYOCTO-SDK-MX6QPDL/112/build/tmp/work/x86_64-nativesdk-pokysdk-linux/gcc-cross-canadian-arm/13.3.0/recipe-sysroot-native/usr/arm-poky-linux-gnueabi/bin --with-sysroot=/not/exist --with-build-sysroot=/home/bamboo/bamboo-agent-home/xml-data/build-dir/IMXYOCTO-SDK-MX6QPDL/112/build/tmp/work/x86_64-nativesdk-pokysdk-linux/gcc-cross-canadian-arm/13.3.0/recipe-sysroot --with-plugin-ld=ld --enable-poison-system-directories --disable-static --enable-nls --with-glibc-version=2.28 --enable-initfini-array
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.3.0 (GCC)

Regards,
Peng.

Re: error: the frame size of 1552 bytes is larger than 1280 bytes when building bcachefs

[Arnd Bergmann]

On Thu, May 22, 2025, at 08:39, Peng Fan wrote:
> Hi Kent, Arnd
>
> There is below build error with "make ARCH=arm randconfig; make"
>
> fs/bcachefs/data_update.c: In function 
> '__bch2_data_update_index_update':
> fs/bcachefs/data_update.c:439:1: error: the frame size of 1552 bytes is 
> larger than 1280 bytes [-Werror=frame-larger-than=]

Right, I think that's been the case with bcachefs since the start,
and I see it with allmodconfig as well, the problem being mostly
CONFIG_KASAN_STACK.

There are a couple of bcachefs functions that have an unusual number
of local struct variables in them, and KASAN_STACK adds a redzone
around each one of them, further increasing the size.

When I add "depends on !KASAN_STACK" to bcachefs, I see all
randconfig builds succeeding, but that may not be the best
solution.

     Arnd

Re: error: the frame size of 1552 bytes is larger than 1280 bytes when building bcachefs

[Kent Overstreet]

On Thu, May 22, 2025 at 01:23:56PM +0200, Arnd Bergmann wrote:
> On Thu, May 22, 2025, at 08:39, Peng Fan wrote:
> > Hi Kent, Arnd
> >
> > There is below build error with "make ARCH=arm randconfig; make"
> >
> > fs/bcachefs/data_update.c: In function 
> > '__bch2_data_update_index_update':
> > fs/bcachefs/data_update.c:439:1: error: the frame size of 1552 bytes is 
> > larger than 1280 bytes [-Werror=frame-larger-than=]
> 
> Right, I think that's been the case with bcachefs since the start,
> and I see it with allmodconfig as well, the problem being mostly
> CONFIG_KASAN_STACK.
> 
> There are a couple of bcachefs functions that have an unusual number
> of local struct variables in them, and KASAN_STACK adds a redzone
> around each one of them, further increasing the size.
> 
> When I add "depends on !KASAN_STACK" to bcachefs, I see all
> randconfig builds succeeding, but that may not be the best
> solution.

Post 6.16, all the bcachefs functions I know of with high stack usage
run with nearly the full stack available - they're running from a
workqueue, or they're fsck, so this should be a non issue - I recently
did some testing with max stack tracing usage enabled and our stack
usage looks ok now.