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? Thank you, Sumanth
