Buildresult: powerpc-next/ppc64le_defconfig/powerpc-gcc9 built on May 30 2020, 07:32

kisskb

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

Status:	OK
Date/Time:	May 30 2020, 07:32
Duration:	0:03:28.813447
Builder:	ka3
Revision:	powerpc/module_64: Use special stub for _mcount() with -mprofile-kernel (`e376ca093587eafd840bb0f9df04090e2a54249c)`
Target:	powerpc-next/ppc64le_defconfig/powerpc-gcc9
Branch:	powerpc-next
Compiler:	powerpc-gcc9 (powerpc64-linux-gcc (GCC) 9.2.0 / GNU ld (GNU Binutils) 2.32)
Config:	ppc64le_defconfig (download)
Log:	Download original No warnings found in log. 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-9.2.0-nolibc/powerpc64-linux/bin/powerpc64-linux-gcc --version # < /opt/cross/kisskb/korg/gcc-9.2.0-nolibc/powerpc64-linux/bin/powerpc64-linux-ld --version # < git log --format=%s --max-count=1 e376ca093587eafd840bb0f9df04090e2a54249c # < make -s -j 80 ARCH=powerpc O=/kisskb/build/powerpc-next_ppc64le_defconfig_powerpc-gcc9 CROSS_COMPILE=/opt/cross/kisskb/korg/gcc-9.2.0-nolibc/powerpc64-linux/bin/powerpc64-linux- ppc64le_defconfig # < make -s -j 80 ARCH=powerpc O=/kisskb/build/powerpc-next_ppc64le_defconfig_powerpc-gcc9 CROSS_COMPILE=/opt/cross/kisskb/korg/gcc-9.2.0-nolibc/powerpc64-linux/bin/powerpc64-linux- help # make -s -j 80 ARCH=powerpc O=/kisskb/build/powerpc-next_ppc64le_defconfig_powerpc-gcc9 CROSS_COMPILE=/opt/cross/kisskb/korg/gcc-9.2.0-nolibc/powerpc64-linux/bin/powerpc64-linux- olddefconfig # make -s -j 80 ARCH=powerpc O=/kisskb/build/powerpc-next_ppc64le_defconfig_powerpc-gcc9 CROSS_COMPILE=/opt/cross/kisskb/korg/gcc-9.2.0-nolibc/powerpc64-linux/bin/powerpc64-linux- Completed OK # rm -rf /kisskb/build/powerpc-next_ppc64le_defconfig_powerpc-gcc9 # Build took: 0:03:28.813447

© Michael Ellerman 2006-2018.