History log of /linux-6.15/arch/s390/Kconfig (Results 1 – 25 of 587)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
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 ...


12345678910>>...24