On 6/21/24 03:14, Sumanth Korikkar wrote: > On Wed, Jun 19, 2024 at 02:23:49PM -0400, Joe Lawrence wrote: >> On 6/19/24 13:01, Sumanth Korikkar wrote: >>> On Tue, Jun 18, 2024 at 04:37:16PM -0400, Joe Lawrence wrote: >>>> On Mon, Feb 19, 2024 at 02:27:30PM +0100, Sumanth Korikkar wrote: >>>>> Hi All, >>>>> >>>>> This is a rebased version of Josh's patch series with a few fixups. >>>>> https://git.kernel.org/pub/scm/linux/kernel/git/jpoimboe/linux.git/log/?h=s390 >>>>> >>>>> This introduces the capability to compile the s390 relocatable kernel >>>>> with and without the -fPIE option. >>>>> >>>>> When utilizing the kpatch functionality, it is advisable to compile the >>>>> kernel without the -fPIE option. This is particularly important if the >>>>> kernel is built with the -ffunction-sections and -fdata-sections flags. >>>>> The linker imposes a restriction on the number of sections (limited to >>>>> 64k), necessitating the omission of -fPIE. >>>>> >>>>> [1] https://gcc.gnu.org/pipermail/gcc-patches/2023-June/622872.html >>>>> [2] https://gcc.gnu.org/pipermail/gcc-patches/2023-August/625986.html >>>>> >>>>> Gcc recently implemented an optimization [1] for loading symbols without >>>>> explicit alignment, aligning with the IBM Z ELF ABI. This ABI mandates >>>>> symbols to reside on a 2-byte boundary, enabling the use of the larl >>>>> instruction. However, kernel linker scripts may still generate unaligned >>>>> symbols. To address this, a new -munaligned-symbols option has been >>>>> introduced [2] in recent gcc versions. This option has to be used with >>>>> future gcc versions. >>>>> >>>>> Older Clang lacks support for handling unaligned symbols generated >>>>> by kernel linker scripts when the kernel is built without -fPIE. However, >>>>> future versions of Clang will include support for the -munaligned-symbols >>>>> option. When the support is unavailable, compile the kernel with -fPIE >>>>> to maintain the existing behavior. >>>>> >>>>> Patch 1 filters out -munaligned-symbol flag for vdso code. This is beneficial >>>>> when compiling kernel with -fno-PIE and -munaligned-symbols combination. >>>>> >>>>> Patch 2 introduces the 'relocs' tool, which reads the vmlinux file and >>>>> generates a vmlinux.relocs_64 section, containing offsets for all >>>>> R_390_64 relocations. >>>>> >>>>> Patch 3 enables the compilation of a relocatable kernel with or without >>>>> the -fPIE option. It allows for building the relocatable kernel without >>>>> -fPIE. However, if compiler cannot handle unaligned symbols, the kernel >>>>> is built with -fPIE. >>>>> >>>>> Patch 4 handles orphan .rela sections when kernel is built with >>>>> -fno-PIE. >>>>> >>>>> kpatch tools changes: >>>>> * -mno-pic-data-is-text-relative prevents relative addressing between >>>>> code and data. This is needed to avoid relocation error when klp text >>>>> and data are too far apart. kpatch already includes this flag. >>>>> However, with these changes, ARCH_KFLAGS+="-fPIC" should be added to >>>>> s390 kpatch tools, As -mno-pic-data-is-text-relative can be used only >>>>> with -fPIC. The corresponding pull request will be sent to kpatch >>>>> tools. >>>> >>>> Hi Sumanth, >>>> >>>> I noticed interesting compiler differences when adding -fPIC build >>>> option and not. The difference in resulting output can confuse >>>> kpatch-build when it tries to verify that its reference build (with the >>>> mentioned options, plus --ffunction-sections and -fdata-sections), >>>> doesn't line up closely enough with the original vmlinux source (sans >>>> all these options). >>> >>> Hi Joe, >>> >>> kpatch for s390 already uses extra compiler flag -mno-pic-data-is-text-relative >>> inorder to prevent relative addressing between code and data. Also, >>> includes -ffunction-sections and -fdata-sections along with it to identify >>> modified functions and its relocations. >>> >>> Both the source code and modified code are built with the same >>> options during kpatch-build (-fPIC added to >>> -mno-pic-data-is-text-relative). kpatch-build was able to identify >>> modified functions and its associated relocations and include these >>> changes in the final kpatch module. >>> >>> May be I am missing some info: Does this deviation cause confusion to kpatch? >>> >> >> Hi Sumanth, >> >> Yes, in the example I provided, the __mmput() function is only inlined >> in kpatch builds, but not the builds that create the target vmlinux. >> Here is a reproducer tarball that you can try against a local >> create-diff-object binary: >> >> https://file.rdu.redhat.com/~jolawren/repro-s390x-shadow-newpid.tar.gz >> >> create-diff-object: ERROR: fork.ORIG.o: find_local_syms: 222: couldn't >> find matching fork.c local symbols in vmlinux symbol table. > > Hi Joe, > > I tried to download the tarball and rhel config. Both are unreachable. > Failed to resolve 'file.rdu.redhat.com' (Name or service not known) > > Could you please provide alternative link to it? > D'oh, I uploaded them to our internal filespace. Try these links, they should be visible to everyone: https://people.redhat.com/~jolawren/kernel-s390x-rhel.config https://people.redhat.com/~jolawren/repro-s390x-special-static.tar.gz -- Joe
