Buildresult: powerpc-next/x86_64-allmodconfig/x86_64-gcc8 built on May 30 2020, 06:51

kisskb

Revisions | Branches | Compilers | Configs | Build Results | Build Failures |

Status:	OK
Date/Time:	May 30 2020, 06:51
Duration:	0:31:52.213390
Builder:	blade4b
Revision:	powerpc/module_64: Use special stub for _mcount() with -mprofile-kernel (`e376ca093587eafd840bb0f9df04090e2a54249c)`
Target:	powerpc-next/x86_64-allmodconfig/x86_64-gcc8
Branch:	powerpc-next
Compiler:	x86_64-gcc8 (x86_64-linux-gcc (GCC) 8.1.0 / GNU ld (GNU Binutils) 2.30)
Config:	allmodconfig (download)
Log:	Download original Possible warnings (1) drivers/net/ethernet/mellanox/mlx5/core/en/tc_ct.c:1133:27: warning: 'rule' may be used uninitialized in this function [-Wmaybe-uninitialized] Full Log # git rev-parse -q --verify e376ca093587eafd840bb0f9df04090e2a54249c^{commit} e376ca093587eafd840bb0f9df04090e2a54249c already have revision, skipping fetch # git checkout -q -f -B kisskb e376ca093587eafd840bb0f9df04090e2a54249c # git clean -qxdf # < git log -1 # commit e376ca093587eafd840bb0f9df04090e2a54249c # Author: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> # Date: Tue Apr 21 23:05:45 2020 +0530 # # powerpc/module_64: Use special stub for _mcount() with -mprofile-kernel # # Since commit c55d7b5e64265f ("powerpc: Remove STRICT_KERNEL_RWX # incompatibility with RELOCATABLE"), powerpc kernels with # -mprofile-kernel can crash in certain scenarios with a trace like below: # # BUG: Unable to handle kernel instruction fetch (NULL pointer?) # Faulting instruction address: 0x00000000 # Oops: Kernel access of bad area, sig: 11 [#1] # LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=256 DEBUG_PAGEALLOC NUMA PowerNV # <snip> # NIP [0000000000000000] 0x0 # LR [c0080000102c0048] ext4_iomap_end+0x8/0x30 [ext4] # Call Trace: # iomap_apply+0x20c/0x920 (unreliable) # iomap_bmap+0xfc/0x160 # ext4_bmap+0xa4/0x180 [ext4] # bmap+0x4c/0x80 # jbd2_journal_init_inode+0x44/0x1a0 [jbd2] # ext4_load_journal+0x440/0x860 [ext4] # ext4_fill_super+0x342c/0x3ab0 [ext4] # mount_bdev+0x25c/0x290 # ext4_mount+0x28/0x50 [ext4] # legacy_get_tree+0x4c/0xb0 # vfs_get_tree+0x4c/0x130 # do_mount+0xa18/0xc50 # sys_mount+0x158/0x180 # system_call+0x5c/0x68 # # The NIP points to NULL, or a random location (data even), while the LR # always points to the LEP of a function (with an offset of 8), indicating # that something went wrong with ftrace. However, ftrace is not # necessarily active when such crashes occur. # # The kernel OOPS sometimes follows a warning from ftrace indicating that # some module functions could not be patched with a nop. Other times, if a # module is loaded early during boot, instruction patching can fail due to # a separate bug, but the error is not reported due to missing error # reporting. # # In all the above cases when instruction patching fails, ftrace will be # disabled but certain kernel module functions will be left with default # calls to _mcount(). This is not a problem with ELFv1. However, with # -mprofile-kernel, the default stub is problematic since it depends on a # valid module TOC in r2. If the kernel (or a different module) calls into # a function that does not use the TOC, the function won't have a prologue # to setup the module TOC. When that function calls into _mcount(), we # will end up in the relocation stub that will use the previous TOC, and # end up trying to jump into a random location. From the above trace: # # iomap_apply+0x20c/0x920 [kernel TOC] # \| # V # ext4_iomap_end+0x8/0x30 [no GEP == kernel TOC] # \| # V # _mcount() stub # [uses kernel TOC -> random entry] # # To address this, let's change over to using the special stub that is # used for ftrace_[regs_]caller() for _mcount(). This ensures that we are # not dependent on a valid module TOC in r2 for default _mcount() # handling. # # Reported-by: Qian Cai <cai@lca.pw> # Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> # Tested-by: Qian Cai <cai@lca.pw> # Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> # Link: https://lore.kernel.org/r/8affd4298d22099bbd82544fab8185700a6222b1.1587488954.git.naveen.n.rao@linux.vnet.ibm.com # < /opt/cross/kisskb/korg/gcc-8.1.0-nolibc/x86_64-linux/bin/x86_64-linux-gcc --version # < /opt/cross/kisskb/korg/gcc-8.1.0-nolibc/x86_64-linux/bin/x86_64-linux-ld --version # < git log --format=%s --max-count=1 e376ca093587eafd840bb0f9df04090e2a54249c # < make -s -j 24 ARCH=x86 O=/kisskb/build/powerpc-next_x86-allmodconfig_x86_64-gcc8 CROSS_COMPILE=/opt/cross/kisskb/korg/gcc-8.1.0-nolibc/x86_64-linux/bin/x86_64-linux- allmodconfig # Added to kconfig CONFIG_BUILD_DOCSRC=n # Added to kconfig CONFIG_MODULE_SIG=n # Added to kconfig CONFIG_SAMPLES=n # < make -s -j 24 ARCH=x86 O=/kisskb/build/powerpc-next_x86-allmodconfig_x86_64-gcc8 CROSS_COMPILE=/opt/cross/kisskb/korg/gcc-8.1.0-nolibc/x86_64-linux/bin/x86_64-linux- help # make -s -j 24 ARCH=x86 O=/kisskb/build/powerpc-next_x86-allmodconfig_x86_64-gcc8 CROSS_COMPILE=/opt/cross/kisskb/korg/gcc-8.1.0-nolibc/x86_64-linux/bin/x86_64-linux- olddefconfig # make -s -j 24 ARCH=x86 O=/kisskb/build/powerpc-next_x86-allmodconfig_x86_64-gcc8 CROSS_COMPILE=/opt/cross/kisskb/korg/gcc-8.1.0-nolibc/x86_64-linux/bin/x86_64-linux- /kisskb/src/drivers/net/ethernet/mellanox/mlx5/core/en/tc_ct.c: In function 'mlx5_tc_ct_flow_offload': /kisskb/src/drivers/net/ethernet/mellanox/mlx5/core/en/tc_ct.c:1133:27: warning: 'rule' may be used uninitialized in this function [-Wmaybe-uninitialized] struct mlx5_flow_handle *rule; ^~~~ Completed OK # rm -rf /kisskb/build/powerpc-next_x86-allmodconfig_x86_64-gcc8 # Build took: 0:31:52.213390

© Michael Ellerman 2006-2018.