- 14 Feb, 2024 7 commits
-
-
Nathan Chancellor authored
When building with CONFIG_LD_ORPHAN_WARN after selecting CONFIG_ARCH_HAS_LD_ORPHAN_WARN, there are several series of warnings for each file in arch/s390/boot due to the boot linker script not handling the DWARF debug sections: s390-linux-ld: warning: orphan section `.debug_line' from `arch/s390/boot/head.o' being placed in section `.debug_line' s390-linux-ld: warning: orphan section `.debug_info' from `arch/s390/boot/head.o' being placed in section `.debug_info' s390-linux-ld: warning: orphan section `.debug_abbrev' from `arch/s390/boot/head.o' being placed in section `.debug_abbrev' s390-linux-ld: warning: orphan section `.debug_aranges' from `arch/s390/boot/head.o' being placed in section `.debug_aranges' s390-linux-ld: warning: orphan section `.debug_str' from `arch/s390/boot/head.o' being placed in section `.debug_str' include/asm-generic/vmlinux.lds.h has a macro for DWARF debug sections named DWARF_DEBUG, use it to clear up the warnings. Signed-off-by:
Nathan Chancellor <nathan@kernel.org> Tested-by:
Justin Stitt <justinstitt@google.com> Reviewed-by:
Fangrui Song <maskray@google.com> Link: https://lore.kernel.org/r/20240207-s390-lld-and-orphan-warn-v1-7-8a665b3346ab@kernel.orgSigned-off-by:
Heiko Carstens <hca@linux.ibm.com>
-
Nathan Chancellor authored
When building with CONFIG_LD_ORPHAN_WARN after selecting CONFIG_ARCH_HAS_LD_ORPHAN_WARN, there are several warnings from arch/s390/boot/head.o due to the unhandled presence of '.rela' sections: s390-linux-ld: warning: orphan section `.rela.iplt' from `arch/s390/boot/head.o' being placed in section `.rela.dyn' s390-linux-ld: warning: orphan section `.rela.head.text' from `arch/s390/boot/head.o' being placed in section `.rela.dyn' s390-linux-ld: warning: orphan section `.rela.got' from `arch/s390/boot/head.o' being placed in section `.rela.dyn' s390-linux-ld: warning: orphan section `.rela.data' from `arch/s390/boot/head.o' being placed in section `.rela.dyn' s390-linux-ld: warning: orphan section `.rela.data.rel.ro' from `arch/s390/boot/head.o' being placed in section `.rela.dyn' s390-linux-ld: warning: orphan section `.rela.iplt' from `arch/s390/boot/head.o' being placed in section `.rela.dyn' s390-linux-ld: warning: orphan section `.rela.head.text' from `arch/s390/boot/head.o' being placed in section `.rela.dyn' s390-linux-ld: warning: orphan section `.rela.got' from `arch/s390/boot/head.o' being placed in section `.rela.dyn' s390-linux-ld: warning: orphan section `.rela.data' from `arch/s390/boot/head.o' being placed in section `.rela.dyn' s390-linux-ld: warning: orphan section `.rela.data.rel.ro' from `arch/s390/boot/head.o' being placed in section `.rela.dyn' These sections are unneeded for the decompressor and they are not emitted in the binary currently. In a manner similar to other architectures, coalesce the sections into '.rela.dyn' and ensure it is zero sized, which is a safe/tested approach versus full discard. Signed-off-by:
-
Nathan Chancellor authored
When building with CONFIG_LD_ORPHAN_WARN after selecting CONFIG_ARCH_HAS_LD_ORPHAN_WARN, there is a warning about the presence of an '.init.text' section in arch/s390/boot: s390-linux-ld: warning: orphan section `.init.text' from `arch/s390/boot/sclp_early_core.o' being placed in section `.init.text' arch/s390/boot/sclp_early_core.c includes a file from the main kernel build, which picks up a usage of '__init' somewhere. For the decompressed image, this section can just be coalesced into '.text'. Signed-off-by:
-
Nathan Chancellor authored
When building with CONFIG_LD_ORPHAN_WARN after selecting CONFIG_ARCH_HAS_LD_ORPHAN_WARN, there are some warnings around certain ELF sections: s390-linux-ld: warning: orphan section `.dynstr' from `arch/s390/kernel/head64.o' being placed in section `.dynstr' s390-linux-ld: warning: orphan section `.dynamic' from `arch/s390/kernel/head64.o' being placed in section `.dynamic' s390-linux-ld: warning: orphan section `.hash' from `arch/s390/kernel/head64.o' being placed in section `.hash' s390-linux-ld: warning: orphan section `.gnu.hash' from `arch/s390/kernel/head64.o' being placed in section `.gnu.hash' Explicitly keep those sections like other architectures when CONFIG_RELOCATABLE is enabled, which is always true for s390. [hca@linux.ibm.com: keep sections instead of discarding] Signed-off-by:
-
Nathan Chancellor authored
When building with CONFIG_LD_ORPHAN_WARN after selecting CONFIG_ARCH_HAS_LD_ORPHAN_WARN, there are a lot of warnings around the GOT and PLT sections: s390-linux-ld: warning: orphan section `.plt' from `arch/s390/kernel/head64.o' being placed in section `.plt' s390-linux-ld: warning: orphan section `.got' from `arch/s390/kernel/head64.o' being placed in section `.got' s390-linux-ld: warning: orphan section `.got.plt' from `arch/s390/kernel/head64.o' being placed in section `.got.plt' s390-linux-ld: warning: orphan section `.iplt' from `arch/s390/kernel/head64.o' being placed in section `.iplt' s390-linux-ld: warning: orphan section `.igot.plt' from `arch/s390/kernel/head64.o' being placed in section `.igot.plt' s390-linux-ld: warning: orphan section `.iplt' from `arch/s390/boot/head.o' being placed in section `.iplt' s390-linux-ld: warning: orphan section `.igot.plt' from `arch/s390/boot/head.o' being placed in section `.igot.plt' s390-linux-ld: warning: orphan section `.got' from `arch/s390/boot/head.o' being placed in section `.got' Currently, only the '.got' section is actually emitted in the final binary. In a manner similar to other architectures, put the '.got' section near the '.data' section and coalesce the PLT sections, checking that the final section is zero sized, which is a safe/tested approach versus full discard. Signed-off-by:
-
Nathan Chancellor authored
When building with CONFIG_LD_ORPHAN_WARN after selecting CONFIG_ARCH_HAS_LD_ORPHAN_WARN, there are a lot of warnings around '.data.rel' sections: s390-linux-ld: warning: orphan section `.data.rel' from `kernel/sched/build_utility.o' being placed in section `.data.rel' s390-linux-ld: warning: orphan section `.data.rel.local' from `kernel/sched/build_utility.o' being placed in section `.data.rel.local' s390-linux-ld: warning: orphan section `.data.rel.ro' from `kernel/sched/build_utility.o' being placed in section `.data.rel.ro' s390-linux-ld: warning: orphan section `.data.rel.ro.local' from `kernel/sched/build_utility.o' being placed in section `.data.rel.ro.local' Describe these in vmlinux.lds.S so there is no more warning and the sections are placed consistently between linkers. Signed-off-by:
-
Nathan Chancellor authored
arch/s390/boot/vmlinux uses a different linker script and build rules than the main vmlinux, so the '--orphan-handling' flag is not applied to it. Add support for '--orphan-handling' so that all sections are properly described in the linker script, which helps eliminate bugs between linker implementations having different orphan section heuristics. Signed-off-by:
-
- 12 Feb, 2024 2 commits
-
-
Heiko Carstens authored
Move the switch_to() implementation to process.c and use the generic switch_to.h header file instead, like some other architectures. This addresses also the oddity that the old switch_to() implementation assigns the return value of __switch_to() to 'prev' instead of 'last', like it should. Remove also all includes of switch_to.h from C files, except process.c. Acked-by:
Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by:
-
Heiko Carstens authored
save_access_regs() and restore_access_regs() are only available by including switch_to.h. This is done by a couple of C files, which have nothing to do with switch_to(), but only need these functions. Move both functions to a new header file and improve the implementation: - Get rid of typedef - Add memory access instrumentation support - Use long displacement instructions lamy/stamy instead of lam/stam - all current users end up with better code because of this Reviewed-by:
-
- 09 Feb, 2024 30 commits
-
-
Alexander Gordeev authored
Fix virtual vs physical address confusion. This does not fix a bug since virtual and physical address spaces are currently the same. Acked-by:
-
Heiko Carstens authored
Code sections in s390 specific kernel code which use floating point or vector registers all come with a 520 byte stack variable to save already in use registers, if required. With INIT_STACK_ALL_PATTERN or INIT_STACK_ALL_ZERO enabled this variable will always be initialized on function entry in addition to saving register contents, which contradicts the intention (performance improvement) of such code sections. Therefore provide a DECLARE_KERNEL_FPU_ONSTACK() macro which provides struct kernel_fpu variables with an __uninitialized attribute, and convert all existing code to use this. This way only this specific type of stack variable will not be initialized, regardless of config options. Reviewed-by:
Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20240205154844.3757121-3-hca@linux.ibm.comSigned-off-by:
-
Heiko Carstens authored
With INIT_STACK_ALL_PATTERN or INIT_STACK_ALL_ZERO enabled the kernel will be compiled with -ftrivial-auto-var-init=<...> which causes initialization of stack variables at function entry time. In order to avoid the performance impact that comes with this users can use the "uninitialized" attribute to prevent such initialization. Therefore provide the __uninitialized macro which can be used for cases where INIT_STACK_ALL_PATTERN or INIT_STACK_ALL_ZERO is enabled, but only selected variables should not be initialized. Acked-by:
-
Ricardo B. Marliere authored
Now that the driver core can properly handle constant struct bus_type, move the matrix_bus variable to be a constant structure as well, placing it into read-only memory which can not be modified at runtime. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Suggested-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
"Ricardo B. Marliere" <ricardo@marliere.net> Acked-by:
Halil Pasic <pasic@linux.ibm.com> Reviewed-by:
Anthony Krowiak <akrowiak@linux.ibm.com> Reviewed-by:
"Jason J. Herne" <jjherne@linux.ibm.com> Reviewed-by:
-
Ricardo B. Marliere authored
Now that the driver core can properly handle constant struct bus_type, move the ap_bus_type variable to be a constant structure as well, placing it into read-only memory which can not be modified at runtime. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Suggested-by:
Harald Freudenberger <freude@linux.ibm.com> Reviewed-by:
-
Ricardo B. Marliere authored
Now that the driver core can properly handle constant struct bus_type, move the scm_bus_type variable to be a constant structure as well, placing it into read-only memory which can not be modified at runtime. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Suggested-by:
-
Ricardo B. Marliere authored
Now that the driver core can properly handle constant struct bus_type, move the ccw_bus_type variable to be a constant structure as well, placing it into read-only memory which can not be modified at runtime. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Suggested-by:
-
Ricardo B. Marliere authored
Now that the driver core can properly handle constant struct bus_type, move the css_bus_type variable to be a constant structure as well, placing it into read-only memory which can not be modified at runtime. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Suggested-by:
-
Ricardo B. Marliere authored
Now that the driver core can properly handle constant struct bus_type, move the ccwgroup_bus_type variable to be a constant structure as well, placing it into read-only memory which can not be modified at runtime. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Suggested-by:
-
Ricardo B. Marliere authored
Now that the driver core can properly handle constant struct bus_type, move the stp_subsys variable to be a constant structure as well, placing it into read-only memory which can not be modified at runtime. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Suggested-by:
-
Nathan Chancellor authored
'-fPIC' as an option to the linker does not do what it seems like it should. With ld.bfd, it is treated as '-f PIC', which does not make sense based on the meaning of '-f': -f SHLIB, --auxiliary SHLIB Auxiliary filter for shared object symbol table When building with ld.lld (currently under review in a GitHub pull request), it just errors out because '-f' means nothing and neither does '-fPIC': ld.lld: error: unknown argument '-fPIC' '-fPIC' was blindly copied from CFLAGS when the vDSO stopped being linked with '$(CC)', it should not be needed. Remove it to clear up the build failure with ld.lld. Fixes: 2b2a2584 ("s390/vdso: Use $(LD) instead of $(CC) to link vDSO") Link: https://github.com/llvm/llvm-project/pull/75643Signed-off-by:
-
Heiko Carstens authored
The measurement block origin address is an absolute address; therefore add a missing virt_to_phys() translation to the cmf_activate() inline assembly. This doesn't fix a bug, since virtual and physical addresses are currently identical. Acked-by:
Vineeth Vijayan <vneethv@linux.ibm.com> Signed-off-by:
-
Heiko Carstens authored
The address of the measurement block can be anywhere in 64 bit absolute space. See description of the schm instruction in the Principles of Operation. Therefore remove the GFP_DMA flag when allocating the block. Acked-by:
-
Peter Oberparleiter authored
Remove GFP_DMA flag when allocating memory to be used for CHSC control blocks. The CHSC instruction can access memory beyond the DMA zone. Suggested-by:
Peter Oberparleiter <oberpar@linux.ibm.com> Signed-off-by:
-
Sven Schnelle authored
Stefan reported a test case fail in libc. The test runs with randomize_va_space set to zero, i.e. disabled randomization. Additionally, it runs the program with the dynamic loader. Looking at the failure showed that the heap was placed right before some pages mapped from the binary. This made memory allocation fail after a few allocations. Normally, when address randomization is switched off and the binary is loaded from the dynamic loader, the kernel places the binary below the 128MB top gap. So the address map would look like this: 3fff7fd1000-3fff7fd2000 r--p 00000000 5e:01 1447115 /lib/ld64.so.1 3fff7fd2000-3fff7ff2000 r-xp 00001000 5e:01 1447115 /lib/ld64.so.1 3fff7ff2000-3fff7ffc000 r--p 00021000 5e:01 1447115 /lib/ld64.so.1 3fff7ffc000-3fff7ffe000 r--p 0002a000 5e:01 1447115 /lib/ld64.so.1 3fff7ffe000-3fff8000000 rw-p 0002c000 5e:01 1447115 /lib/ld64.so.1 3fff8000000-3fff8021000 rw-p 00000000 00:00 0 [heap] 3fffffda000-3ffffffb000 rw-p 00000000 00:00 0 [stack] 3ffffffc000-3ffffffe000 r--p 00000000 00:00 0 [vvar] 3ffffffe000-40000000000 r-xp 00000000 00:00 0 [vdso] However, commit 1f6b83e5 ("s390: avoid z13 cache aliasing") introduced a mmap alignment mask of 8MB. With this commit, the memory map now looks like this: 3fff7f80000-3fff7f81000 r--p 00000000 5e:01 1447115 /lib/ld64.so.1 3fff7f81000-3fff7fa1000 r-xp 00001000 5e:01 1447115 /lib/ld64.so.1 3fff7fa1000-3fff7fab000 r--p 00021000 5e:01 1447115 /lib/ld64.so.1 3fff7fab000-3fff7fad000 r--p 0002a000 5e:01 1447115 /lib/ld64.so.1 3fff7fad000-3fff7faf000 rw-p 0002c000 5e:01 1447115 /lib/ld64.so.1 3fff7faf000-3fff7fd0000 rw-p 00000000 00:00 0 [heap] 3fff7fdc000-3fff8000000 rw-p 00000000 00:00 0 3fffffda000-3ffffffb000 rw-p 00000000 00:00 0 [stack] 3ffffffc000-3ffffffe000 r--p 00000000 00:00 0 [vvar] 3ffffffe000-40000000000 r-xp 00000000 00:00 0 [vdso] The reason for this placement is that the elf loader loads the binary to end at mmap_base (0x3fff8000000 on s390). This would result in a start address of 0x3fff7fd1000, but due to the alignment requirement of 8MB, mmap chooses 0x3fff7f80000. This causes a gap between the end of the mapped binary and mmap_base. When the next non-shared and non-file pages are mapped, mmap searches from top to bottom and the first free space it finds is the gap which is now present. This leaves only a few pages for the heap. With enabled address space randomization this doesn't happen because the binary is mapped to a completely different memory area. Fix this by disabling the mmap alignment when address space randomization is disabled. This is in line with what other architectures are doing. Reported-by:
Stefan Liebler <stli@linux.ibm.com> Tested-by:
Sven Schnelle <svens@linux.ibm.com> Signed-off-by:
-
Heiko Carstens authored
Remove GFP_DMA flag when allocating memory to be used for diagnose 304. Diagnose 304 can access memory beyond the DMA zone. Suggested-by:
-
Thomas Richter authored
diag14() is currently only used by the vmur device driver. The third parameter, called subcommand, determines the type of the first parameter. For some subcommands the value of the first parameter is an address to a memory buffer and needs virtual to physical address conversion. Other subcommands interpret the first parameter is an integer. This doesn't fix a bug since virtual and physical addresses are currently the same. Suggested-by:
Thomas Richter <tmricht@linux.ibm.com> Signed-off-by:
-
Thomas Richter authored
Add missing virt_to_phys() / phys_to_virt() translation to alloc_chan_prog() and free_chan_prog(). This doesn't fix a bug since virtual and physical addresses are currently the same. Signed-off-by:
-
Sven Schnelle authored
The common timekeeping code steers the clock by adjusting the multiplier value of the clock. With the current value of 1000 precision is lost when the clock is steered with a userspace daemon. Increase the multiplier and the shift values to increase precision. Signed-off-by:
-
Thomas Richter authored
paicrypt_init() return incorrect error code in case the number of PAI crypto counters is too high. Change the return code to -E2BIG. Please merge with d0b0efedc7fe Reported-by:
-
Thomas Richter authored
The number of sysfs files to be exported by the PAI device drivers depends on the hardware version level. Use the value returned by the hardware as the maximum number of counters to be exported in the sysfs attribute tree. Without the fix, older machine generation export counter names based on paiXXXX_ctrnames static array info, which can be inaccurate, as this array could also contain newer counter names in the future. This ensures proper pai counter sysfs attributes for both newer generation and older generation processors. Signed-off-by:
Sumanth Korikkar <sumanthk@linux.ibm.com> Signed-off-by:
-
Thomas Richter authored
When the device driver is initialized, it checks the number of possible counters. Should this number be too high, emit an error and return. Reported-by:
-
Thomas Richter authored
When the device drivers are initialized, a sysfs directory is created. This contains many attributes which are allocated with kzalloc(). Should it fail, the memory for the attributes already created is freed in attr_event_free(). Its second parameter is number of attribute elements to delete. This parameter is off by one. When i. e. the 10th attribute fails to get created, attributes numbered 0 to 9 should be deleted. Currently only attributes numbered 0 to 8 are deleted. Fixes: 39d62336 ("s390/pai: add support for cryptography counters") Reported-by:
-
Heiko Carstens authored
Add missing virt_to_phys() translation to diag0c(). This doesn't fix a bug since virtual and physical addresses are currently the same. Reviewed-by:
-
Heiko Carstens authored
Add missing virt_to_phys() translation to __hypfs_sprp_diag304(). This doesn't fix a bug since virtual and physical addresses are currently the same. Reviewed-by:
-
Gerald Schaefer authored
Fix virtual vs physical address confusion (which currently are the same). Reviewed-by:
Gerald Schaefer <gerald.schaefer@linux.ibm.com> Signed-off-by:
-
Alexander Gordeev authored
Fix virtual vs physical address confusion (which currently are the same). Reviewed-by:
-
Heiko Carstens authored
Signed-off-by: -
Heiko Carstens authored
It looks like all distributions will enable INIT_STACK_ALL_ZERO. Reflect that in the default configurations. Acked-by:
-
Heiko Carstens authored
CONFIG_COMPAT is disabled by default, however compat code still needs to be compile tested. Add a compat topic configuration target which allows to enable it easily. Acked-by:
-
- 04 Feb, 2024 1 commit
-
-
Linus Torvalds authored
-
