|
Revision tags: v6.15, v6.15-rc7, v6.15-rc6, v6.15-rc5, v6.15-rc4, v6.15-rc3, v6.15-rc2, v6.15-rc1, v6.14, v6.14-rc7, v6.14-rc6, v6.14-rc5, v6.14-rc4, v6.14-rc3, v6.14-rc2, v6.14-rc1, v6.13, v6.13-rc7, v6.13-rc6, v6.13-rc5, v6.13-rc4, v6.13-rc3, v6.13-rc2, v6.13-rc1, v6.12, v6.12-rc7, v6.12-rc6, v6.12-rc5, v6.12-rc4, v6.12-rc3, v6.12-rc2, v6.12-rc1, v6.11, v6.11-rc7, v6.11-rc6 |
|
| #
c51ea988 |
| 26-Aug-2024 |
Vasily Gorbik <[email protected]> |
s390: Allow to compile with z17 optimizations
Add config and compile options which allow to compile with z17 optimizations if the compiler supports it. Add the miscellaneous-instruction-extension 4
s390: Allow to compile with z17 optimizations
Add config and compile options which allow to compile with z17 optimizations if the compiler supports it. Add the miscellaneous-instruction-extension 4 facility to the list of facilities for z17.
Reviewed-by: Heiko Carstens <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]> Signed-off-by: Heiko Carstens <[email protected]>
show more ...
|
| #
24e3f9fb |
| 11-Mar-2025 |
Heiko Carstens <[email protected]> |
mseal sysmap: enable s390
Provide support for CONFIG_MSEAL_SYSTEM_MAPPINGS on s390, covering the vdso.
[[email protected]: update supported architectures] Link: https://lkml.kernel.org/r/20250317
mseal sysmap: enable s390
Provide support for CONFIG_MSEAL_SYSTEM_MAPPINGS on s390, covering the vdso.
[[email protected]: update supported architectures] Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Heiko Carstens <[email protected]> Reviewed-by: Lorenzo Stoakes <[email protected]> Cc: Alexander Gordeev <[email protected]> Cc: Christian Borntraeger <[email protected]> Cc: Jeff Xu <[email protected]> Cc: Liam Howlett <[email protected]> Cc: Sven Schnelle <[email protected]> Cc: Thomas Weißschuh <[email protected]> Cc: Vasily Gorbik <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
show more ...
|
| #
1018424a |
| 27-Mar-2025 |
Heiko Carstens <[email protected]> |
s390/smp: Add support for HOTPLUG_SMT
Add support for HOTPLUG_SMT. With this the s390 specific "nosmt" kernel command line parameter handling is replaced with common code handling.
This means that
s390/smp: Add support for HOTPLUG_SMT
Add support for HOTPLUG_SMT. With this the s390 specific "nosmt" kernel command line parameter handling is replaced with common code handling.
This means that just specifying "nosmt" still enables smt from an architectural point of view, however only the primary (base) cpu can be set online. Enabling smt during runtime via /sys/devices/system/cpu/smt/control allows to set secondary cpus online. This way "nosmt" works like on other architectures where enabling and disabling smt during runtime is possible.
If "nosmt=force" is specified smt is also still enabled from an architectural point of view, but there is no way to set secondary cpus online during runtime, also like on other architectures.
In order to disable smt from architectural point of view, which was previously achieved with the s390 specific "nosmt" command line option, "smt=1" can be used.
Tested-by: Mete Durlu <[email protected]> Reviewed-by: Mete Durlu <[email protected]> Acked-by: Christian Borntraeger <[email protected]> Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
show more ...
|
| #
aa9f168d |
| 26-Feb-2025 |
Niklas Schnelle <[email protected]> |
s390/pci: Support mmap() of PCI resources except for ISM devices
So far s390 does not allow mmap() of PCI resources to user-space via the usual mechanisms, though it does use it for RDMA. For the PC
s390/pci: Support mmap() of PCI resources except for ISM devices
So far s390 does not allow mmap() of PCI resources to user-space via the usual mechanisms, though it does use it for RDMA. For the PCI sysfs resource files and /proc/bus/pci it defines neither HAVE_PCI_MMAP nor ARCH_GENERIC_PCI_MMAP_RESOURCE. For vfio-pci s390 previously relied on disabled VFIO_PCI_MMAP and now relies on setting pdev->non_mappable_bars for all devices.
This is partly because access to mapped PCI resources from user-space requires special PCI load/store memory-I/O (MIO) instructions, or the special MMIO syscalls when these are not available. Still, such access is possible and useful not just for RDMA, in fact not being able to mmap() PCI resources has previously caused extra work when testing devices.
One thing that doesn't work with PCI resources mapped to user-space though is the s390 specific virtual ISM device. Not only because the BAR size of 256 TiB prevents mapping the whole BAR but also because access requires use of the legacy PCI instructions which are not accessible to user-space on systems with the newer MIO PCI instructions.
Now with the pdev->non_mappable_bars flag ISM can be excluded from mapping its resources while making this functionality available for all other PCI devices. To this end introduce a minimal implementation of PCI_QUIRKS and use that to set pdev->non_mappable_bars for ISM devices only. Then also set ARCH_GENERIC_PCI_MMAP_RESOURCE to take advantage of the generic implementation of pci_mmap_resource_range() enabling only the newer sysfs mmap() interface. This follows the recommendation in Documentation/PCI/sysfs-pci.rst.
Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Niklas Schnelle <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]>
show more ...
|
| #
174cb82a |
| 10-Mar-2025 |
Heiko Carstens <[email protected]> |
s390: Remove 2k vs 4k page table leftovers
Since commit d08d4e7cd6bf ("s390/mm: use full 4KB page for 2KB PTE") always 4k page tables are allocated, however there is still some (now) obsolete code l
s390: Remove 2k vs 4k page table leftovers
Since commit d08d4e7cd6bf ("s390/mm: use full 4KB page for 2KB PTE") always 4k page tables are allocated, however there is still some (now) obsolete code left which deals with switching from 2k to 4k page tables for qemu/kvm processes.
Reviewed-by: Alexander Gordeev <[email protected]> Remove the not needed code.
Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
show more ...
|
| #
f9aad622 |
| 26-Feb-2025 |
Anshuman Khandual <[email protected]> |
mm: rename GENERIC_PTDUMP and PTDUMP_CORE
Platforms subscribe into generic ptdump implementation via GENERIC_PTDUMP. But generic ptdump gets enabled via PTDUMP_CORE. These configs combination is co
mm: rename GENERIC_PTDUMP and PTDUMP_CORE
Platforms subscribe into generic ptdump implementation via GENERIC_PTDUMP. But generic ptdump gets enabled via PTDUMP_CORE. These configs combination is confusing as they sound very similar and does not differentiate between platform's feature subscription and feature enablement for ptdump. Rename the configs as ARCH_HAS_PTDUMP and PTDUMP making it more clear and improve readability.
Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Anshuman Khandual <[email protected]> Reviewed-by: Christophe Leroy <[email protected]> (powerpc) Acked-by: Catalin Marinas <[email protected]> [arm64] Cc: Will Deacon <[email protected]> Cc: Jonathan Corbet <[email protected]> Cc: Marc Zyngier <[email protected]> Cc: Michael Ellerman <[email protected]> Cc: Nicholas Piggin <[email protected]> Cc: Paul Walmsley <[email protected]> Cc: Palmer Dabbelt <[email protected]> Cc: Heiko Carstens <[email protected]> Cc: Vasily Gorbik <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Christophe Leroy <[email protected]> Cc: Madhavan Srinivasan <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Steven Price <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
show more ...
|
| #
9b400d17 |
| 11-Mar-2025 |
Ard Biesheuvel <[email protected]> |
kbuild: Introduce Kconfig symbol for linking vmlinux with relocations
Some architectures build vmlinux with static relocations preserved, but strip them again from the final vmlinux image. Arch spec
kbuild: Introduce Kconfig symbol for linking vmlinux with relocations
Some architectures build vmlinux with static relocations preserved, but strip them again from the final vmlinux image. Arch specific tools consume these static relocations in order to construct relocation tables for KASLR.
The fact that vmlinux is created, consumed and subsequently updated goes against the typical, declarative paradigm used by Make, which is based on rules and dependencies. So as a first step towards cleaning this up, introduce a Kconfig symbol to declare that the arch wants to consume the static relocations emitted into vmlinux. This will be wired up further in subsequent patches.
Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>
show more ...
|
| #
9bf39a65 |
| 04-Feb-2025 |
Thomas Weißschuh <[email protected]> |
s390/vdso: Switch to generic storage implementation
The generic storage implementation provides the same features as the custom one. However it can be shared between architectures, making maintenanc
s390/vdso: Switch to generic storage implementation
The generic storage implementation provides the same features as the custom one. However it can be shared between architectures, making maintenance easier.
Co-developed-by: Nam Cao <[email protected]> Signed-off-by: Nam Cao <[email protected]> Signed-off-by: Thomas Weißschuh <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Acked-by: Heiko Carstens <[email protected]> Link: https://lore.kernel.org/all/[email protected]
show more ...
|
| #
fa151887 |
| 13-Feb-2025 |
Heiko Carstens <[email protected]> |
s390: Sort mcount locations at build time
For s390 the mcount_loc section of the kernel image contains the addresses of the mcount locations. All addresses will be adjusted with the same offset by t
s390: Sort mcount locations at build time
For s390 the mcount_loc section of the kernel image contains the addresses of the mcount locations. All addresses will be adjusted with the same offset by the decompressor before the kernel is started.
Therefore select HAVE_BUILDTIME_MCOUNT_SORT so that the entries of this section are sorted at build time. Given that the same offset is applied to all entries the section will be sorted in any case.
Note that this was not possible before commit 778666df60f0 ("s390: compile relocatable kernel without -fPIE"). Since this commit all R_390_64 absolute relocations are handled in a special way: only the address of the to be changed location is put into a special section. For all those locations the same offset is applied as described above.
Without that change it would have been necessary to also adjust the addend of all relocations which correspond to the mcount_loc section, when sorting the mcount_loc section.
Reported-by: Steven Rostedt <[email protected]> Closes: https://lore.kernel.org/r/[email protected]/ Signed-off-by: Heiko Carstens <[email protected]> Acked-by: Vasily Gorbik <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
show more ...
|
| #
3bcc8a1a |
| 20-Jan-2025 |
Heiko Carstens <[email protected]> |
s390/sclp: Initialize sclp subsystem via arch_cpu_finalize_init()
With the switch to GENERIC_CPU_DEVICES an early call to the sclp subsystem was added to smp_prepare_cpus(). This will usually succee
s390/sclp: Initialize sclp subsystem via arch_cpu_finalize_init()
With the switch to GENERIC_CPU_DEVICES an early call to the sclp subsystem was added to smp_prepare_cpus(). This will usually succeed since the sclp subsystem is implicitly initialized early enough if an sclp based console is present.
If no such console is present the initialization happens with an arch_initcall(); in such cases calls to the sclp subsystem will fail. For CPU detection this means that the fallback sigp loop will be used permanently to detect CPUs instead of the preferred READ_CPU_INFO sclp request.
Fix this by adding an explicit early sclp_init() call via arch_cpu_finalize_init().
Reported-by: Sheshu Ramanandan <[email protected]> Fixes: 4a39f12e753d ("s390/smp: Switch to GENERIC_CPU_DEVICES") Reviewed-by: Peter Oberparleiter <[email protected]> Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Alexander Gordeev <[email protected]>
show more ...
|
| #
212c3a85 |
| 04-Dec-2024 |
David Hildenbrand <[email protected]> |
s390/kdump: virtio-mem kdump support (CONFIG_PROC_VMCORE_DEVICE_RAM)
Let's add support for including virtio-mem device RAM in the crash dump, setting NEED_PROC_VMCORE_DEVICE_RAM, and implementing el
s390/kdump: virtio-mem kdump support (CONFIG_PROC_VMCORE_DEVICE_RAM)
Let's add support for including virtio-mem device RAM in the crash dump, setting NEED_PROC_VMCORE_DEVICE_RAM, and implementing elfcorehdr_fill_device_ram_ptload_elf64().
To avoid code duplication, factor out the code to fill a PT_LOAD entry.
Signed-off-by: David Hildenbrand <[email protected]> Message-Id: <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]>
show more ...
|
| #
f340d270 |
| 13-Jan-2025 |
Heiko Carstens <[email protected]> |
s390: Introduce CC_HAS_ASM_AOR_FORMAT_FLAGS Kconfig option
Introduce CC_HAS_ASM_AOR_FORMAT_FLAGS Kconfig option. Use this option for inline assemblies where the A, O, or R format flags are used. Tho
s390: Introduce CC_HAS_ASM_AOR_FORMAT_FLAGS Kconfig option
Introduce CC_HAS_ASM_AOR_FORMAT_FLAGS Kconfig option. Use this option for inline assemblies where the A, O, or R format flags are used. Those flags are not available for Clang versions before 19.1.0.
Reviewed-by: Alexander Gordeev <[email protected]> Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Alexander Gordeev <[email protected]>
show more ...
|
| #
579a6633 |
| 13-Jan-2025 |
Heiko Carstens <[email protected]> |
s390: Rename GCC_ASM_FLAG_OUTPUT_BROKEN to CC_ASM_FLAG_OUTPUT_BROKEN
Config options which can be used to check for compiler bugs and features have the compiler independent CC prefix in order to avoi
s390: Rename GCC_ASM_FLAG_OUTPUT_BROKEN to CC_ASM_FLAG_OUTPUT_BROKEN
Config options which can be used to check for compiler bugs and features have the compiler independent CC prefix in order to avoid duplicating and having to check config options for multiple compilers. Therefore rename the config option accordingly.
Reviewed-by: Alexander Gordeev <[email protected]> Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Alexander Gordeev <[email protected]>
show more ...
|
| #
7495e179 |
| 26-Dec-2024 |
Sven Schnelle <[email protected]> |
s390/tracing: Enable HAVE_FTRACE_GRAPH_FUNC
Add ftrace_graph_func() which is required for fprobe to access registers. This also eliminates the need for calling prepare_ftrace_return() from ftrace_ca
s390/tracing: Enable HAVE_FTRACE_GRAPH_FUNC
Add ftrace_graph_func() which is required for fprobe to access registers. This also eliminates the need for calling prepare_ftrace_return() from ftrace_caller().
Cc: Alexei Starovoitov <[email protected]> Cc: Florent Revest <[email protected]> Cc: Martin KaFai Lau <[email protected]> Cc: bpf <[email protected]> Cc: Alexei Starovoitov <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Alan Maguire <[email protected]> Cc: Mark Rutland <[email protected]> Link: https://lore.kernel.org/173519002875.391279.7060964632119674159.stgit@devnote2 Signed-off-by: Sven Schnelle <[email protected]> Acked-by: Heiko Carstens <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]>
show more ...
|
| #
762abbc0 |
| 26-Dec-2024 |
Masami Hiramatsu (Google) <[email protected]> |
fprobe: Use ftrace_regs in fprobe exit handler
Change the fprobe exit handler to use ftrace_regs structure instead of pt_regs. This also introduce HAVE_FTRACE_REGS_HAVING_PT_REGS which means the ftr
fprobe: Use ftrace_regs in fprobe exit handler
Change the fprobe exit handler to use ftrace_regs structure instead of pt_regs. This also introduce HAVE_FTRACE_REGS_HAVING_PT_REGS which means the ftrace_regs is including the pt_regs so that ftrace_regs can provide pt_regs without memory allocation. Fprobe introduces a new dependency with that.
Signed-off-by: Masami Hiramatsu (Google) <[email protected]> Acked-by: Heiko Carstens <[email protected]> # s390 Cc: Huacai Chen <[email protected]> Cc: Alexei Starovoitov <[email protected]> Cc: Florent Revest <[email protected]> Cc: bpf <[email protected]> Cc: Alan Maguire <[email protected]> Cc: Heiko Carstens <[email protected]> Cc: WANG Xuerui <[email protected]> Cc: Vasily Gorbik <[email protected]> Cc: Alexander Gordeev <[email protected]> Cc: Christian Borntraeger <[email protected]> Cc: Sven Schnelle <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Dave Hansen <[email protected]> Cc: [email protected] Cc: "H. Peter Anvin" <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Mathieu Desnoyers <[email protected]> Cc: Song Liu <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: KP Singh <[email protected]> Cc: Matt Bobrowski <[email protected]> Cc: Alexei Starovoitov <[email protected]> Cc: Daniel Borkmann <[email protected]> Cc: Andrii Nakryiko <[email protected]> Cc: Martin KaFai Lau <[email protected]> Cc: Eduard Zingerman <[email protected]> Cc: Yonghong Song <[email protected]> Cc: John Fastabend <[email protected]> Cc: Stanislav Fomichev <[email protected]> Cc: Hao Luo <[email protected]> Cc: Andrew Morton <[email protected]> Link: https://lore.kernel.org/173518995092.391279.6765116450352977627.stgit@devnote2 Signed-off-by: Steven Rostedt (Google) <[email protected]>
show more ...
|
| #
a3ed4157 |
| 26-Dec-2024 |
Masami Hiramatsu (Google) <[email protected]> |
fgraph: Replace fgraph_ret_regs with ftrace_regs
Use ftrace_regs instead of fgraph_ret_regs for tracing return value on function_graph tracer because of simplifying the callback interface.
The CONF
fgraph: Replace fgraph_ret_regs with ftrace_regs
Use ftrace_regs instead of fgraph_ret_regs for tracing return value on function_graph tracer because of simplifying the callback interface.
The CONFIG_HAVE_FUNCTION_GRAPH_RETVAL is also replaced by CONFIG_HAVE_FUNCTION_GRAPH_FREGS.
Signed-off-by: Masami Hiramatsu (Google) <[email protected]> Acked-by: Heiko Carstens <[email protected]> Acked-by: Will Deacon <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Alexei Starovoitov <[email protected]> Cc: Florent Revest <[email protected]> Cc: Martin KaFai Lau <[email protected]> Cc: bpf <[email protected]> Cc: Alexei Starovoitov <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Alan Maguire <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Huacai Chen <[email protected]> Cc: WANG Xuerui <[email protected]> Cc: Paul Walmsley <[email protected]> Cc: Palmer Dabbelt <[email protected]> Cc: Albert Ou <[email protected]> Cc: Vasily Gorbik <[email protected]> Cc: Alexander Gordeev <[email protected]> Cc: Heiko Carstens <[email protected]> Cc: Christian Borntraeger <[email protected]> Cc: Sven Schnelle <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Dave Hansen <[email protected]> Cc: [email protected] Cc: "H. Peter Anvin" <[email protected]> Cc: Mathieu Desnoyers <[email protected]> Link: https://lore.kernel.org/173518991508.391279.16635322774382197642.stgit@devnote2 Signed-off-by: Steven Rostedt (Google) <[email protected]>
show more ...
|
| #
27939d6c |
| 02-Dec-2024 |
Heiko Carstens <[email protected]> |
s390/Kconfig: Select VMAP_STACK unconditionally
There is no point in supporting !VMAP_STACK kernel builds. VMAP_STACK has proven to work since many years. Also, since KASAN_VMALLOC is supported, ker
s390/Kconfig: Select VMAP_STACK unconditionally
There is no point in supporting !VMAP_STACK kernel builds. VMAP_STACK has proven to work since many years. Also, since KASAN_VMALLOC is supported, kernels built with !VMAP_STACK are completely untested.
Therefore select VMAP_STACK unconditionally and remove all config options and code required for !VMAP_STACK builds.
Acked-by: Christian Borntraeger <[email protected]> Reviewed-by: Vasily Gorbik <[email protected]> Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Alexander Gordeev <[email protected]>
show more ...
|
| #
e7256aca |
| 02-Dec-2024 |
Heiko Carstens <[email protected]> |
s390/Kconfig: Select KASAN_VMALLOC if KASAN is enabled
Reduce the number of to be considered config options and select KASAN_VMALLOC if KASAN is enabled.
Reviewed-by: Christian Borntraeger <borntra
s390/Kconfig: Select KASAN_VMALLOC if KASAN is enabled
Reduce the number of to be considered config options and select KASAN_VMALLOC if KASAN is enabled.
Reviewed-by: Christian Borntraeger <[email protected]> Reviewed-by: Vasily Gorbik <[email protected]> Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Alexander Gordeev <[email protected]>
show more ...
|
| #
00807191 |
| 02-Dec-2024 |
Eric Biggers <[email protected]> |
s390/crc32: expose CRC32 functions through lib
Move the s390 CRC32 assembly code into the lib directory and wire it up to the library interface. This allows it to be used without going through the
s390/crc32: expose CRC32 functions through lib
Move the s390 CRC32 assembly code into the lib directory and wire it up to the library interface. This allows it to be used without going through the crypto API. It remains usable via the crypto API too via the shash algorithms that use the library interface. Thus all the arch-specific "shash" code becomes unnecessary and is removed.
Note: to see the diff from arch/s390/crypto/crc32-vx.c to arch/s390/lib/crc32-glue.c, view this commit with 'git show -M10'.
Reviewed-by: Ard Biesheuvel <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Eric Biggers <[email protected]>
show more ...
|
| #
b5f46348 |
| 27-Nov-2024 |
Heiko Carstens <[email protected]> |
s390: Support PREEMPT_DYNAMIC
Select HAVE_PREEMPT_DYNAMIC_KEY and add the pieces which are required to support PREEMPT_DYNAMIC.
See commit 99cf983cc8bc ("sched/preempt: Add PREEMPT_DYNAMIC using st
s390: Support PREEMPT_DYNAMIC
Select HAVE_PREEMPT_DYNAMIC_KEY and add the pieces which are required to support PREEMPT_DYNAMIC.
See commit 99cf983cc8bc ("sched/preempt: Add PREEMPT_DYNAMIC using static keys") and commit 1b2d3451ee50 ("arm64: Support PREEMPT_DYNAMIC") for more details.
Signed-off-by: Heiko Carstens <[email protected]>
show more ...
|
| #
9de3e4bf |
| 21-Nov-2024 |
Heiko Carstens <[email protected]> |
s390: Add ARCH_HAS_PREEMPT_LAZY support
Just add the required TIF bit for ARCH_HAS_PREEMPT_LAZY support.
Shuffle TIF bits to get TIF_NEED_RESCHED_LAZY next to TIF_NEED_RESCHED.
Signed-off-by: Heik
s390: Add ARCH_HAS_PREEMPT_LAZY support
Just add the required TIF bit for ARCH_HAS_PREEMPT_LAZY support.
Shuffle TIF bits to get TIF_NEED_RESCHED_LAZY next to TIF_NEED_RESCHED.
Signed-off-by: Heiko Carstens <[email protected]>
show more ...
|
| #
31daa343 |
| 17-Sep-2024 |
Dave Vasilevsky <[email protected]> |
crash, powerpc: default to CRASH_DUMP=n on PPC_BOOK3S_32
Fixes boot failures on 6.9 on PPC_BOOK3S_32 machines using Open Firmware. On these machines, the kernel refuses to boot from non-zero PHYSIC
crash, powerpc: default to CRASH_DUMP=n on PPC_BOOK3S_32
Fixes boot failures on 6.9 on PPC_BOOK3S_32 machines using Open Firmware. On these machines, the kernel refuses to boot from non-zero PHYSICAL_START, which occurs when CRASH_DUMP is on.
Since most PPC_BOOK3S_32 machines boot via Open Firmware, it should default to off for them. Users booting via some other mechanism can still turn it on explicitly.
Does not change the default on any other architectures for the time being.
Link: https://lkml.kernel.org/r/[email protected] Fixes: 75bc255a7444 ("crash: clean up kdump related config items") Signed-off-by: Dave Vasilevsky <[email protected]> Reported-by: Reimar Döffinger <[email protected]> Closes: https://lists.debian.org/debian-powerpc/2024/07/msg00001.html Acked-by: Michael Ellerman <[email protected]> [powerpc] Acked-by: Baoquan He <[email protected]> Cc: "Eric W. Biederman" <[email protected]> Cc: John Paul Adrian Glaubitz <[email protected]> Cc: Reimar Döffinger <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
show more ...
|
| #
e7583c5f |
| 07-Nov-2024 |
Heiko Carstens <[email protected]> |
s390/asm: Helper macros for flag output operand handling
Since gcc supports flag out operands for inline assemblies there is always the question when this feature should be used and if it is worth a
s390/asm: Helper macros for flag output operand handling
Since gcc supports flag out operands for inline assemblies there is always the question when this feature should be used and if it is worth all the ifdefs that come with that.
In order to avoid that provide similar macros like x86 which can be used for all inline assemblies which extract the condition code. Depending on compiler features the generated code will either always contain an ipm+srl instruction pair, which extracts the condition code, or alternatively let the compiler handle this completely.
Suggested-by: Juergen Christ <[email protected]> Reviewed-by: Juergen Christ <[email protected]> Signed-off-by: Heiko Carstens <[email protected]>
show more ...
|
| #
a812eee0 |
| 10-Oct-2024 |
Nam Cao <[email protected]> |
vdso: Rename struct arch_vdso_data to arch_vdso_time_data
The struct arch_vdso_data is only about vdso time data. So rename it to arch_vdso_time_data to make it obvious. Non time-related data will b
vdso: Rename struct arch_vdso_data to arch_vdso_time_data
The struct arch_vdso_data is only about vdso time data. So rename it to arch_vdso_time_data to make it obvious. Non time-related data will be migrated out of these structs soon.
Signed-off-by: Nam Cao <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Acked-by: Heiko Carstens <[email protected]> # s390 Link: https://lore.kernel.org/all/[email protected]
show more ...
|
| #
57d1da4f |
| 22-Oct-2024 |
Heiko Carstens <[email protected]> |
s390/mm: Convert to LOCK_MM_AND_FIND_VMA
With the gmap code gone s390 can be easily converted to LOCK_MM_AND_FIND_VMA like it has been done for most other architectures.
Reviewed-by: Gerald Schaefe
s390/mm: Convert to LOCK_MM_AND_FIND_VMA
With the gmap code gone s390 can be easily converted to LOCK_MM_AND_FIND_VMA like it has been done for most other architectures.
Reviewed-by: Gerald Schaefer <[email protected]> Reviewed-by: Alexander Gordeev <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Heiko Carstens <[email protected]>
show more ...
|