Bug 102361 - Errors compiling Linux kernel 5.14 with CONFIG_FORTIFY=y
Summary: Errors compiling Linux kernel 5.14 with CONFIG_FORTIFY=y
Status: RESOLVED DUPLICATE of bug 101941
Alias: None
Product: gcc
Classification: Unclassified
Component: ipa (show other bugs)
Version: 12.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on: 94818 101941
Blocks:
  Show dependency treegraph
 
Reported: 2021-09-16 09:59 UTC by DAC324
Modified: 2021-09-17 07:41 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2021-09-16 00:00:00


Attachments
File mm/memcontrol.c saved with -save-temps option (1/2) (13.80 KB, text/plain)
2021-09-16 13:41 UTC, DAC324
Details
File mm/memcontrol.c saved with -save-temps option (2/2) (617.57 KB, application/gzip)
2021-09-16 13:42 UTC, DAC324
Details

Note You need to log in before you can comment on or make changes to this bug.
Description DAC324 2021-09-16 09:59:51 UTC
GCC version: gcc (GCC) 12.0.0 20210910 (experimental)

With this version, it is not possible to compile the Linux kernel sources (tested with both 5.14.1 and 5.14.4). 

Problem is that GCC 12 conflicts with CONFIG_FORTIFY=y.

Errors thrown with the 5.14.1 kernel sources:

In function 'memset',
    inlined from 'init_rock_state.part.0' at fs/isofs/rock.c:74:2:
./include/linux/fortify-string.h:172:17: error: call to '__write_overflow' declared with attribute error: detected write beyond size of object passed as 1st parameter
  172 |                 __write_overflow();
      |                 ^~~~~~~~~~~~~~~~~~
make[2]: *** [scripts/Makefile.build:271: fs/isofs/rock.o] Error 1
make[1]: *** [scripts/Makefile.build:514: fs/isofs] Error 2

In function 'memcpy',
    inlined from 'tl_to_darg.part.0' at fs/ext4/fast_commit.c:1295:2:
./include/linux/fortify-string.h:187:25: error: call to '__read_overflow2' declared with attribute error: detected read beyond size of object passed as 2nd parameter
  187 |                         __read_overflow2();
      |                         ^~~~~~~~~~~~~~~~~~
make[2]: *** [scripts/Makefile.build:271: fs/ext4/fast_commit.o] Error 1
make[1]: *** [scripts/Makefile.build:514: fs/ext4] Error 2


Error thrown with the 5.14.4 kernel sources:

In Function »memcpy«,
    inserted from von »tl_to_darg.part.0« bei fs/ext4/fast_commit.c:1295:2:
./include/linux/fortify-string.h:187:25: Error: call to »__read_overflow2« declared with attribute error: detected read beyond size of object passed as 2nd parameter
  187 |                         __read_overflow2();
      |                         ^~~~~~~~~~~~~~~~~~


With GCC 11, these errors do not occur. Hence, I must assume that they are related to the compiler version.
Comment 1 Martin Liška 2021-09-16 10:38:26 UTC
Please isolate a pre-processed source file (-E) option and attach it here together with the used command line.
Comment 2 DAC324 2021-09-16 12:34:24 UTC
Please let me kindly ask you for instructions on how to do that. 
As described in the introduction, I was trying to compile the Linux kernel from the usual source tarball available on kernel.org.

What I did after extracting the sources was:

make menuconfig
make

If I understand correctly, I will have to interrupt the make process to extract a pre-processed source file?

Please let me kindly ask for additional guidance.

Thank you very much and kind regards.
Comment 3 Jakub Jelinek 2021-09-16 12:36:16 UTC
See https://gcc.gnu.org/bugs/
On the kernel side, I guess you want to use make V=1 so that it shows the compiler command lines, then copy & paste relevant command both here and into command line where you add -save-temps to it to get preprocessed source.
Comment 4 DAC324 2021-09-16 13:29:01 UTC
Please let me kindly ask you for instructions on how to do that. 
As described in the introduction, I was trying to compile the Linux kernel from the usual source tarball available on kernel.org.

What I did after extracting the sources was:

make menuconfig
make

If I understand correctly, I will have to interrupt the make process to extract a pre-processed source file?

Please let me kindly ask for additional guidance.

Thank you very much and kind regards.
Comment 5 DAC324 2021-09-16 13:29:56 UTC
OK, here we go:

make -f ./scripts/Makefile.build obj=mm/kfence \
 \
need-builtin=1 \
need-modorder=1
  gcc -Wp,-MMD,mm/.memcontrol.o.d -nostdinc -isystem /usr/lib/gcc/x86_64-pc-linux-gnu/12.0.0/include -I./arch/x86/include -I./arch/x86/include/generated  -I./include -I./arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/compiler-version.h -include ./include/linux/kconfig.h -include ./include/linux/compiler_types.h -D__KERNEL__ -fmacro-prefix-map=./= -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE -Werror=implicit-function-declaration -Werror=implicit-int -Werror=return-type -Wno-format-security -std=gnu89 -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -fcf-protection=none -m64 -falign-jumps=1 -falign-loops=1 -mno-80387 -mno-fp-ret-in-387 -mpreferred-stack-boundary=3 -mskip-rax-setup -march=sandybridge -mno-red-zone -mcmodel=kernel -Wno-sign-compare -fno-asynchronous-unwind-tables -mindirect-branch=thunk-extern -mindirect-branch-register -fno-jump-tables -fno-delete-null-pointer-checks -Wno-frame-address -Wno-format-truncation -Wno-format-overflow -Wno-address-of-packed-member -O2 -fno-allow-store-data-races -Wframe-larger-than=2048 -fstack-protector-strong -Wimplicit-fallthrough=5 -Wno-unused-but-set-variable -Wno-unused-const-variable -fno-stack-clash-protection -g -gdwarf-4 -pg -mrecord-mcount -mfentry -DCC_USING_FENTRY -Wdeclaration-after-statement -Wvla -Wno-pointer-sign -Wno-stringop-truncation -Wno-zero-length-bounds -Wno-array-bounds -Wno-stringop-overflow -Wno-restrict -Wno-maybe-uninitialized -fno-strict-overflow -fno-stack-check -fconserve-stack -Werror=date-time -Werror=incompatible-pointer-types -Werror=designated-init -Wno-packed-not-aligned -fplugin=./scripts/gcc-plugins/structleak_plugin.so -fplugin-arg-structleak_plugin-byref-all -DSTRUCTLEAK_PLUGIN    -DKBUILD_MODFILE='"mm/memcontrol"' -DKBUILD_BASENAME='"memcontrol"' -DKBUILD_MODNAME='"memcontrol"' -D__KBUILD_MODNAME=kmod_memcontrol -c -o mm/memcontrol.o mm/memcontrol.c
In file included from ./include/linux/string.h:262,
                 from ./include/linux/bitmap.h:10,
                 from ./include/linux/cpumask.h:12,
                 from ./arch/x86/include/asm/paravirt.h:17,
                 from ./arch/x86/include/asm/irqflags.h:63,
                 from ./include/linux/irqflags.h:16,
                 from ./include/linux/rcupdate.h:26,
                 from ./include/linux/rculist.h:11,
                 from ./include/linux/pid.h:5,
                 from ./include/linux/sched.h:14,
                 from ./include/linux/cgroup.h:12,
                 from ./include/linux/memcontrol.h:13,
                 from mm/memcontrol.c:29:
In function 'memset',
    inlined from 'uncharge_gather_clear.part.0' at mm/memcontrol.c:6835:2:
./include/linux/fortify-string.h:172:17: error: call to '__write_overflow' declared with attribute error: detected write beyond size of object passed as 1st parameter
  172 |                 __write_overflow();
      |                 ^~~~~~~~~~~~~~~~~~
make[1]: *** [scripts/Makefile.build:271: mm/memcontrol.o] Error 1
make: *** [Makefile:1851: mm] Error 2
Comment 6 DAC324 2021-09-16 13:41:12 UTC
Created attachment 51469 [details]
File mm/memcontrol.c saved with -save-temps option (1/2)
Comment 7 DAC324 2021-09-16 13:42:44 UTC
Created attachment 51470 [details]
File mm/memcontrol.c saved with -save-temps option (2/2)
Comment 8 DAC324 2021-09-16 13:45:05 UTC
This is the first error; if make is used with -j greater than 1, several of those errors occur (see introduction).
Comment 9 Andrew Pinski 2021-09-16 22:57:33 UTC
  <bb 20> [local count: 329188777]:
  uncharge_batch (ug_26(D));
  p_size_95 = __builtin_object_size (ug_26(D), 0);
  if (p_size_95 <= 39)
    goto <bb 22>; [0.00%]
  else
    goto <bb 21>; [100.00%]

  <bb 21> [local count: 329188777]:
  __builtin_memset (ug_26(D), 0, 40);
  goto <bb 23>; [100.00%]

  <bb 22> [count: 0]:
  uncharge_gather_clear.part.0 ();


uncharge_gather_clear.part.0 has

;; Function uncharge_gather_clear.part.0 (uncharge_gather_clear.part.0, funcdef_no=6447, decl_uid=102103, cgraph_uid=6834, symbol_order=7294) (unlikely executed)

__attribute__((no_instrument_function, unused, gnu_inline))
void uncharge_gather_clear.part.0 ()
{
  <bb 2> [count: 0]:
  __write_overflow ();
  fortify_panic (&__func__);

}

I Knew I had saw this before.
Comment 10 Andrew Pinski 2021-09-16 22:59:15 UTC
Similar to PR 94818 and 92497.
Comment 11 Andrew Pinski 2021-09-16 22:59:57 UTC
(In reply to Andrew Pinski from comment #9)
> I Knew I had saw this before.

Yes I did, PR 101941.
Comment 12 Andrew Pinski 2021-09-16 23:00:18 UTC
Actually this is an exact dup of bug 101941.

*** This bug has been marked as a duplicate of bug 101941 ***
Comment 13 DAC324 2021-09-17 07:24:45 UTC
Sorry for duplicate reporting. For me, the error message 

'__write_overflow' declared with attribute error: detected write beyond size of object passed as 1st parameter

and its counterpart 

'__read_overflow2' declared with attribute error: detected read beyond size of object passed as 2nd parameter

did not point me to using 

fnsplit fragment with __attribute__((__error__))

as a correct search term, in the first instance.
Please apologize for the inconvenience. 

Just FYI (although I assume you know this already):

With CONFIG_FORTIFY=n, you will be able to build the kernel but it will not run satisfactorily, if able to boot at all.
Comment 14 Andrew Pinski 2021-09-17 07:41:26 UTC
(In reply to DAC324 from comment #13)
> Sorry for duplicate reporting. For me, the error message 
> Please apologize for the inconvenience. 
It is ok, it is good that you filed the bug.  I have been doing a lot of cleanup of GCC's bugzilla lately so I have some memory of some of the more recent bugs filed.  Searching bugzilla to know if there was a dup filed is a huge task even so I don't think most people will be doing it.