ARM: 9443/1: Require linker to support KEEP within OVERLAY for DCE

ld.lld prior to 21.0.0 does not support using the KEEP keyword within an
overlay description, which may be needed to avoid discardi

ARM: 9443/1: Require linker to support KEEP within OVERLAY for DCE

ld.lld prior to 21.0.0 does not support using the KEEP keyword within an
overlay description, which may be needed to avoid discarding necessary
sections within an overlay with '--gc-sections', which can be enabled
for the kernel via CONFIG_LD_DEAD_CODE_DATA_ELIMINATION.

Disallow CONFIG_LD_DEAD_CODE_DATA_ELIMINATION without support for KEEP
within OVERLAY and introduce a macro, OVERLAY_KEEP, that can be used to
conditionally add KEEP when it is properly supported to avoid breaking
old versions of ld.lld.

Cc: [email protected]
Link: https://github.com/llvm/llvm-project/commit/381599f1fe973afad3094e55ec99b1620dba7d8c
Reviewed-by: Linus Walleij <[email protected]>
Signed-off-by: Nathan Chancellor <[email protected]>
Signed-off-by: Russell King (Oracle) <[email protected]>

show more ...

ARM: 9441/1: rust: Enable Rust support for ARMv7

This commit allows building ARMv7 kernels with Rust support.

The rust core library expects some __eabi_... functions
that are not implemented in the

ARM: 9441/1: rust: Enable Rust support for ARMv7

This commit allows building ARMv7 kernels with Rust support.

The rust core library expects some __eabi_... functions
that are not implemented in the kernel.
Those functions are some float operations and __aeabi_uldivmod.
For now those are implemented with define_panicking_intrinsics!.

This is based on the code by Sven Van Asbroeck from the original
rust branch and inspired by the AArch version by Jamie Cunliffe.

I have tested the rust samples and a custom simple MMIO module
on hardware (De1SoC FPGA + Arm A9 CPU).

Tested-by: Rudraksha Gupta <[email protected]>
Reviewed-by: Alice Ryhl <[email protected]>
Acked-by: Miguel Ojeda <[email protected]>
Tested-by: Miguel Ojeda <[email protected]>
Acked-by: Ard Biesheuvel <[email protected]>
Signed-off-by: Christian Schrefl <[email protected]>
Signed-off-by: Russell King (Oracle) <[email protected]>

show more ...

ARM: 9433/2: implement cacheinfo support

On ARMv7 / v7m machines read CTR and CLIDR registers to provide
information regarding the cache topology. Earlier machines should
describe full cache topolog

ARM: 9433/2: implement cacheinfo support

On ARMv7 / v7m machines read CTR and CLIDR registers to provide
information regarding the cache topology. Earlier machines should
describe full cache topology in the device tree.

Note, this follows the ARM64 cacheinfo support and provides only minimal
support required to bootstrap cache info. All useful properties should
be decribed in Device Tree.

Reviewed-by: Linus Walleij <[email protected]>
Signed-off-by: Dmitry Baryshkov <[email protected]>
Signed-off-by: Russell King (Oracle) <[email protected]>

show more ...

ARM: 9438/1: assembler: Drop obsolete VFP accessor fallback

Now that the minimum supported binutils version is 2.25, we no longer
need a workaround for binutils older than 2.24 for accessing VFP con

ARM: 9438/1: assembler: Drop obsolete VFP accessor fallback

Now that the minimum supported binutils version is 2.25, we no longer
need a workaround for binutils older than 2.24 for accessing VFP control
registers from assembler.

Reviewed-by: Linus Walleij <[email protected]>
Reviewed-by: Nathan Chancellor <[email protected]>
Signed-off-by: Ard Biesheuvel <[email protected]>
Signed-off-by: Russell King (Oracle) <[email protected]>

show more ...

arm/crc-t10dif: expose CRC-T10DIF function through lib

Move the arm CRC-T10DIF assembly code into the lib directory and wire it
up to the library interface. This allows it to be used without going

arm/crc-t10dif: expose CRC-T10DIF function through lib

Move the arm CRC-T10DIF 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/arm/crypto/crct10dif-ce-glue.c to
arch/arm/lib/crc-t10dif-glue.c, view this commit with 'git show -M10'.

Reviewed-by: Ard Biesheuvel <[email protected]>
Reviewed-by: Martin K. Petersen <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Eric Biggers <[email protected]>

show more ...

arm/crc32: expose CRC32 functions through lib

Move the arm 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 cr

arm/crc32: expose CRC32 functions through lib

Move the arm 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/arm/crypto/crc32-ce-glue.c to
arch/arm/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 ...

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 ...

ARM: 9414/1: Fix build issue with LD_DEAD_CODE_DATA_ELIMINATION

There is a build issue with LD segmentation fault, while
CONFIG_LD_DEAD_CODE_DATA_ELIMINATION is not enabled, as bellow.

scripts/link

ARM: 9414/1: Fix build issue with LD_DEAD_CODE_DATA_ELIMINATION

There is a build issue with LD segmentation fault, while
CONFIG_LD_DEAD_CODE_DATA_ELIMINATION is not enabled, as bellow.

scripts/link-vmlinux.sh: line 49: 3796 Segmentation fault
(core dumped) ${ld} ${ldflags} -o ${output} ${wl}--whole-archive
${objs} ${wl}--no-whole-archive ${wl}--start-group
${libs} ${wl}--end-group ${kallsymso} ${btf_vmlinux_bin_o} ${ldlibs}

The error occurs in older versions of the GNU ld with version earlier
than 2.36. It makes most sense to have a minimum LD version as
a dependency for HAVE_LD_DEAD_CODE_DATA_ELIMINATION and eliminate
the impact of ".reloc .text, R_ARM_NONE, ." when
CONFIG_LD_DEAD_CODE_DATA_ELIMINATION is not enabled.

Fixes: ed0f94102251 ("ARM: 9404/1: arm32: enable HAVE_LD_DEAD_CODE_DATA_ELIMINATION")
Reported-by: Harith George <[email protected]>
Tested-by: Harith George <[email protected]>
Suggested-by: Arnd Bergmann <[email protected]>
Acked-by: Arnd Bergmann <[email protected]>
Signed-off-by: Yuntao Liu <[email protected]>
Link: https://lore.kernel.org/all/[email protected]/
Signed-off-by: Russell King (Oracle) <[email protected]>

show more ...

dma-mapping: clearly mark DMA ops as an architecture feature

DMA ops are a helper for architectures and not for drivers to override
the DMA implementation.

Unfortunately driver authors keep ignorin

dma-mapping: clearly mark DMA ops as an architecture feature

DMA ops are a helper for architectures and not for drivers to override
the DMA implementation.

Unfortunately driver authors keep ignoring this. Make the fact more
clear by renaming the symbol to ARCH_HAS_DMA_OPS and having the two drivers
overriding their dma_ops depend on that. These drivers should probably be
marked broken, but we can give them a bit of a grace period for that.

Signed-off-by: Christoph Hellwig <[email protected]>
Reviewed-by: Thomas Gleixner <[email protected]>
Acked-by: Sakari Ailus <[email protected]> # for IPU6
Acked-by: Robin Murphy <[email protected]>

show more ...

ARM: 9411/1: Switch over to GENERIC_CPU_DEVICES using arch_register_cpu()

Currently, almost all architectures have switched to GENERIC_CPU_DEVICES,
except for arm32. Also switch over to GENERIC_CPU_

ARM: 9411/1: Switch over to GENERIC_CPU_DEVICES using arch_register_cpu()

Currently, almost all architectures have switched to GENERIC_CPU_DEVICES,
except for arm32. Also switch over to GENERIC_CPU_DEVICES, and provide an
arch_register_cpu() that populates the hotpluggable flag for arm32.

The struct cpu in struct cpuinfo_arm is never used directly, remove
it to use the one GENERIC_CPU_DEVICES provides.

This also has the effect of moving the registration of CPUs from subsys to
driver core initialisation, prior to any initcalls running.

Signed-off-by: Jinjie Ruan <[email protected]>
Signed-off-by: Russell King (Oracle) <[email protected]>

show more ...

treewide: change conditional prompt for choices to 'depends on'

While Documentation/kbuild/kconfig-language.rst provides a brief
explanation, there are recurring confusions regarding the usage of a

treewide: change conditional prompt for choices to 'depends on'

While Documentation/kbuild/kconfig-language.rst provides a brief
explanation, there are recurring confusions regarding the usage of a
prompt followed by 'if <expr>'. This conditional controls _only_ the
prompt.

A typical usage is as follows:

menuconfig BLOCK
bool "Enable the block layer" if EXPERT
default y

When EXPERT=n, the prompt is hidden, but this config entry is still
active, and BLOCK is set to its default value 'y'. This is reasonable
because you are likely want to enable the block device support. When
EXPERT=y, the prompt is shown, allowing you to toggle BLOCK.

Please note that it is different from 'depends on EXPERT', which would
enable and disable the entire config entry.

However, this conditional prompt has never worked in a choice block.

The following two work in the same way: when EXPERT is disabled, the
choice block is entirely disabled.

[Test Code 1]

choice
prompt "choose" if EXPERT

config A
bool "A"

config B
bool "B"

endchoice

[Test Code 2]

choice
prompt "choose"
depends on EXPERT

config A
bool "A"

config B
bool "B"

endchoice

I believe the first case should hide only the prompt, producing the
default:

CONFIG_A=y
# CONFIG_B is not set

The next commit will change (fix) the behavior of the conditional prompt
in choice blocks.

I see several choice blocks wrongly using a conditional prompt, where
'depends on' makes more sense.

To preserve the current behavior, this commit converts such misuses.

I did not touch the following entry in arch/x86/Kconfig:

choice
prompt "Memory split" if EXPERT
default VMSPLIT_3G

This is truly the correct use of the conditional prompt; when EXPERT=n,
this choice block should silently select the reasonable VMSPLIT_3G,
although the resulting PAGE_OFFSET will not be affected anyway.

Presumably, the one in fs/jffs2/Kconfig is also correct, but I converted
it to 'depends on' to avoid any potential behavioral change.

Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

ARM: Emulate one-byte cmpxchg

Use the new cmpxchg_emu_u8() to emulate one-byte cmpxchg() on ARM systems
with ARCH == ARMv6K.

[ paulmck: Apply Arnd Bergmann and Nathan Chancellor feedback. ]
[ paulm

ARM: Emulate one-byte cmpxchg

Use the new cmpxchg_emu_u8() to emulate one-byte cmpxchg() on ARM systems
with ARCH == ARMv6K.

[ paulmck: Apply Arnd Bergmann and Nathan Chancellor feedback. ]
[ paulmck: Apply Linus Walleij feedback. ]

Reported-by: Mark Brown <[email protected]>
Closes: https://lore.kernel.org/all/[email protected]/
Reported-by: Naresh Kamboju <[email protected]>
Closes: https://lore.kernel.org/all/CA+G9fYuZ+pf6p8AXMZWtdFtX-gbG8HMaBKp=XbxcdzA_QeLkxQ@mail.gmail.com/
Signed-off-by: Paul E. McKenney <[email protected]>
Tested-by: Nathan Chancellor <[email protected]>
Reviewed-by: Linus Walleij <[email protected]>
Cc: "Russell King (Oracle)" <[email protected]>
Cc: Arnd Bergmann <[email protected]>
Cc: Andrew Davis <[email protected]>
Cc: Andrew Morton <[email protected]>
Cc: Eric DeVolder <[email protected]>
Cc: Rob Herring <[email protected]>
Cc: <[email protected]>

show more ...

ARM: 9407/1: Add support for STACKLEAK gcc plugin

Add the STACKLEAK gcc plugin to arm32 by adding the helper used by
stackleak common code: on_thread_stack(). It initialize the stack with the
poison

ARM: 9407/1: Add support for STACKLEAK gcc plugin

Add the STACKLEAK gcc plugin to arm32 by adding the helper used by
stackleak common code: on_thread_stack(). It initialize the stack with the
poison value before returning from system calls which improves the kernel
security. Additionally, this disables the plugin in EFI stub code and
decompress code, which are out of scope for the protection.

Before the test on Qemu versatilepb board:
# echo STACKLEAK_ERASING > /sys/kernel/debug/provoke-crash/DIRECT
lkdtm: Performing direct entry STACKLEAK_ERASING
lkdtm: XFAIL: stackleak is not supported on this arch (HAVE_ARCH_STACKLEAK=n)

After:
# echo STACKLEAK_ERASING > /sys/kernel/debug/provoke-crash/DIRECT
lkdtm: Performing direct entry STACKLEAK_ERASING
lkdtm: stackleak stack usage:
high offset: 80 bytes
current: 280 bytes
lowest: 696 bytes
tracked: 696 bytes
untracked: 192 bytes
poisoned: 7220 bytes
low offset: 4 bytes
lkdtm: OK: the rest of the thread stack is properly erased

Signed-off-by: Jinjie Ruan <[email protected]>
Acked-by: Ard Biesheuvel <[email protected]>
Reviewed-by: Linus Walleij <[email protected]>
Signed-off-by: Russell King (Oracle) <[email protected]>

show more ...

ARM: 9404/1: arm32: enable HAVE_LD_DEAD_CODE_DATA_ELIMINATION

The current arm32 architecture does not yet support the
HAVE_LD_DEAD_CODE_DATA_ELIMINATION feature. arm32 is widely used in
embedded sce

ARM: 9404/1: arm32: enable HAVE_LD_DEAD_CODE_DATA_ELIMINATION

The current arm32 architecture does not yet support the
HAVE_LD_DEAD_CODE_DATA_ELIMINATION feature. arm32 is widely used in
embedded scenarios, and enabling this feature would be beneficial for
reducing the size of the kernel image.

In order to make this work, we keep the necessary tables by annotating
them with KEEP, also it requires further changes to linker script to KEEP
some tables and wildcard compiler generated sections into the right place.
When using ld.lld for linking, KEEP is not recognized within the OVERLAY
command, and Ard proposed a concise method to solve this problem.

It boots normally with defconfig, vexpress_defconfig and tinyconfig.

The size comparison of zImage is as follows:
defconfig vexpress_defconfig tinyconfig
5137712 5138024 424192 no dce
5032560 4997824 298384 dce
2.0% 2.7% 29.7% shrink

When using smaller config file, there is a significant reduction in the
size of the zImage.

We also tested this patch on a commercially available single-board
computer, and the comparison is as follows:
a15eb_config
2161384 no dce
2092240 dce
3.2% shrink

The zImage size has been reduced by approximately 3.2%, which is 70KB on
2.1M.

Signed-off-by: Yuntao Liu <[email protected]>
Tested-by: Arnd Bergmann <[email protected]>
Reviewed-by: Arnd Bergmann <[email protected]>
Reviewed-by: Linus Walleij <[email protected]>
Signed-off-by: Russell King (Oracle) <[email protected]>

show more ...

ARM: 9402/1: Kconfig: Spelling s/Cortex A-/Cortex-A/

Fix a misspelling of "Cortex-A9", to make it easier to find which errata
are applicable to Cortex-A9 CPU cores.

Signed-off-by: Geert Uytterhoeve

ARM: 9402/1: Kconfig: Spelling s/Cortex A-/Cortex-A/

Fix a misspelling of "Cortex-A9", to make it easier to find which errata
are applicable to Cortex-A9 CPU cores.

Signed-off-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Russell King (Oracle) <[email protected]>

show more ...

ARM: 9392/2: Support CLANG CFI

Support Control Flow Integrity (CFI) when compiling with
CLANG.

In the as-of-writing LLVM CLANG implementation (v17)
the 32-bit ARM platform is supported by the gener

ARM: 9392/2: Support CLANG CFI

Support Control Flow Integrity (CFI) when compiling with
CLANG.

In the as-of-writing LLVM CLANG implementation (v17)
the 32-bit ARM platform is supported by the generic CFI
implementation, which isn't tailored specifically for ARM32
but works well enough to enable the feature.

Tested-by: Kees Cook <[email protected]>
Reviewed-by: Sami Tolvanen <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
Signed-off-by: Russell King (Oracle) <[email protected]>

show more ...

mm/treewide: rename CONFIG_HAVE_FAST_GUP to CONFIG_HAVE_GUP_FAST

Nowadays, we call it "GUP-fast", the external interface includes functions
like "get_user_pages_fast()", and we renamed all internal

mm/treewide: rename CONFIG_HAVE_FAST_GUP to CONFIG_HAVE_GUP_FAST

Nowadays, we call it "GUP-fast", the external interface includes functions
like "get_user_pages_fast()", and we renamed all internal functions to
reflect that as well.

Let's make the config option reflect that.

Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: David Hildenbrand <[email protected]>
Reviewed-by: Mike Rapoport (IBM) <[email protected]>
Reviewed-by: Jason Gunthorpe <[email protected]>
Reviewed-by: John Hubbard <[email protected]>
Cc: Peter Xu <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

show more ...

ARM: 9358/2: Implement PAN for LPAE by TTBR0 page table walks disablement

With LPAE enabled, privileged no-access cannot be enforced using CPU
domains as such feature is not available. This patch im

ARM: 9358/2: Implement PAN for LPAE by TTBR0 page table walks disablement

With LPAE enabled, privileged no-access cannot be enforced using CPU
domains as such feature is not available. This patch implements PAN
by disabling TTBR0 page table walks while in kernel mode.

The ARM architecture allows page table walks to be split between TTBR0
and TTBR1. With LPAE enabled, the split is defined by a combination of
TTBCR T0SZ and T1SZ bits. Currently, an LPAE-enabled kernel uses TTBR0
for user addresses and TTBR1 for kernel addresses with the VMSPLIT_2G
and VMSPLIT_3G configurations. The main advantage for the 3:1 split is
that TTBR1 is reduced to 2 levels, so potentially faster TLB refill
(though usually the first level entries are already cached in the TLB).

The PAN support on LPAE-enabled kernels uses TTBR0 when running in user
space or in kernel space during user access routines (TTBCR T0SZ and
T1SZ are both 0). When running user accesses are disabled in kernel
mode, TTBR0 page table walks are disabled by setting TTBCR.EPD0. TTBR1
is used for kernel accesses (including loadable modules; anything
covered by swapper_pg_dir) by reducing the TTBCR.T0SZ to the minimum
(2^(32-7) = 32MB). To avoid user accesses potentially hitting stale TLB
entries, the ASID is switched to 0 (reserved) by setting TTBCR.A1 and
using the ASID value in TTBR1. The difference from a non-PAN kernel is
that with the 3:1 memory split, TTBR1 always uses 3 levels of page
tables.

As part of the change we are using preprocessor elif definied() clauses
so balance these clauses by converting relevant precedingt ifdef
clauses to if defined() clauses.

Signed-off-by: Catalin Marinas <[email protected]>
Reviewed-by: Kees Cook <[email protected]>
Tested-by: Florian Fainelli <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
Signed-off-by: Russell King (Oracle) <[email protected]>

show more ...

arch: define CONFIG_PAGE_SIZE_*KB on all architectures

Most architectures only support a single hardcoded page size. In order
to ensure that each one of these sets the corresponding Kconfig symbols,

arch: define CONFIG_PAGE_SIZE_*KB on all architectures

Most architectures only support a single hardcoded page size. In order
to ensure that each one of these sets the corresponding Kconfig symbols,
change over the PAGE_SHIFT definition to the common one and allow
only the hardware page size to be selected.

Acked-by: Guo Ren <[email protected]>
Acked-by: Heiko Carstens <[email protected]>
Acked-by: Stafford Horne <[email protected]>
Acked-by: Johannes Berg <[email protected]>
Acked-by: Geert Uytterhoeven <[email protected]>
Reviewed-by: Thomas Gleixner <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>

show more ...

ARM: 9352/1: iwmmxt: Remove support for PJ4/PJ4B cores

PJ4 is a v7 core that incorporates a iWMMXt coprocessor. However, GCC
does not support this combination (its iWMMXt configuration always
implie

ARM: 9352/1: iwmmxt: Remove support for PJ4/PJ4B cores

PJ4 is a v7 core that incorporates a iWMMXt coprocessor. However, GCC
does not support this combination (its iWMMXt configuration always
implies v5te), and so there is no v6/v7 user space that actually makes
use of this, beyond generic support for things like setjmp() that
preserve/restore the iWMMXt register file using generic LDC/STC
instructions emitted in assembler. As [0] appears to imply, this logic
is triggered for the init process at boot, and so most user threads will
have a iWMMXt register context associated with it, even though it is
never used.

At this point, it is highly unlikely that such GCC support will ever
materialize (and Clang does not implement support for iWMMXt to begin
with).

This means that advertising iWMMXt support on these cores results in
context switch overhead without any associated benefit, and so it is
better to simply ignore the iWMMXt unit on these systems. So rip out the
support. Doing so also fixes the issue reported in [0] related to UNDEF
handling of co-processor #0/#1 instructions issued from user space
running in Thumb2 mode.

The PJ4 cores are used in four platforms: Armada 370/xp, Dove (Cubox,
d2plug), MMP2 (xo-1.75) and Berlin (Google TV). Out of these, only the
first is still widely used, but that one actually doesn't have iWMMXt
but instead has only VFPV3-D16, and so it is not impacted by this
change.

Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218427 [0]

Fixes: 8bcba70cb5c22 ("ARM: entry: Disregard Thumb undef exception ...")
Acked-by: Linus Walleij <[email protected]>
Acked-by: Arnd Bergmann <[email protected]>
Acked-by: Nicolas Pitre <[email protected]>
Reviewed-by: Jisheng Zhang <[email protected]>
Signed-off-by: Ard Biesheuvel <[email protected]>
Signed-off-by: Russell King (Oracle) <[email protected]>

show more ...

Introduce cpu_dcache_is_aliasing() across all architectures

Introduce a generic way to query whether the data cache is virtually
aliased on all architectures. Its purpose is to ensure that subsystem

Introduce cpu_dcache_is_aliasing() across all architectures

Introduce a generic way to query whether the data cache is virtually
aliased on all architectures. Its purpose is to ensure that subsystems
which are incompatible with virtually aliased data caches (e.g. FS_DAX)
can reliably query this.

For data cache aliasing, there are three scenarios dependending on the
architecture. Here is a breakdown based on my understanding:

A) The data cache is always aliasing:

* arc
* csky
* m68k (note: shared memory mappings are incoherent ? SHMLBA is missing there.)
* sh
* parisc

B) The data cache aliasing is statically known or depends on querying CPU
state at runtime:

* arm (cache_is_vivt() || cache_is_vipt_aliasing())
* mips (cpu_has_dc_aliases)
* nios2 (NIOS2_DCACHE_SIZE > PAGE_SIZE)
* sparc32 (vac_cache_size > PAGE_SIZE)
* sparc64 (L1DCACHE_SIZE > PAGE_SIZE)
* xtensa (DCACHE_WAY_SIZE > PAGE_SIZE)

C) The data cache is never aliasing:

* alpha
* arm64 (aarch64)
* hexagon
* loongarch (but with incoherent write buffers, which are disabled since
commit d23b7795 ("LoongArch: Change SHMLBA from SZ_64K to PAGE_SIZE"))
* microblaze
* openrisc
* powerpc
* riscv
* s390
* um
* x86

Require architectures in A) and B) to select ARCH_HAS_CPU_CACHE_ALIASING and
implement "cpu_dcache_is_aliasing()".

Architectures in C) don't select ARCH_HAS_CPU_CACHE_ALIASING, and thus
cpu_dcache_is_aliasing() simply evaluates to "false".

Note that this leaves "cpu_icache_is_aliasing()" to be implemented as future
work. This would be useful to gate features like XIP on architectures
which have aliasing CPU dcache-icache but not CPU dcache-dcache.

Use "cpu_dcache" and "cpu_cache" rather than just "dcache" and "cache"
to clarify that we really mean "CPU data cache" and "CPU cache" to
eliminate any possible confusion with VFS "dentry cache" and "page
cache".

Link: https://lore.kernel.org/lkml/[email protected]/
Link: https://lkml.kernel.org/r/[email protected]
Fixes: d92576f1167c ("dax: does not work correctly with virtual aliasing caches")
Signed-off-by: Mathieu Desnoyers <[email protected]>
Cc: Dan Williams <[email protected]>
Cc: Vishal Verma <[email protected]>
Cc: Dave Jiang <[email protected]>
Cc: Matthew Wilcox <[email protected]>
Cc: Arnd Bergmann <[email protected]>
Cc: Russell King <[email protected]>
Cc: Alasdair Kergon <[email protected]>
Cc: Christoph Hellwig <[email protected]>
Cc: Dave Chinner <[email protected]>
Cc: Heiko Carstens <[email protected]>
Cc: kernel test robot <[email protected]>
Cc: Michael Sclafani <[email protected]>
Cc: Mike Snitzer <[email protected]>
Cc: Mikulas Patocka <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

show more ...

ubsan: Remove CONFIG_UBSAN_SANITIZE_ALL

For simplicity in splitting out UBSan options into separate rules,
remove CONFIG_UBSAN_SANITIZE_ALL, effectively defaulting to "y", which
is how it is general

ubsan: Remove CONFIG_UBSAN_SANITIZE_ALL

For simplicity in splitting out UBSan options into separate rules,
remove CONFIG_UBSAN_SANITIZE_ALL, effectively defaulting to "y", which
is how it is generally used anyway. (There are no ":= y" cases beyond
where a specific file is enabled when a top-level ":= n" is in effect.)

Cc: Andrey Konovalov <[email protected]>
Cc: Marco Elver <[email protected]>
Cc: [email protected]
Cc: [email protected]
Signed-off-by: Kees Cook <[email protected]>

show more ...

mm, treewide: rename MAX_ORDER to MAX_PAGE_ORDER

commit 23baf831a32c ("mm, treewide: redefine MAX_ORDER sanely") has
changed the definition of MAX_ORDER to be inclusive. This has caused
issues with

mm, treewide: rename MAX_ORDER to MAX_PAGE_ORDER

commit 23baf831a32c ("mm, treewide: redefine MAX_ORDER sanely") has
changed the definition of MAX_ORDER to be inclusive. This has caused
issues with code that was not yet upstream and depended on the previous
definition.

To draw attention to the altered meaning of the define, rename MAX_ORDER
to MAX_PAGE_ORDER.

Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Kirill A. Shutemov <[email protected]>
Cc: Linus Torvalds <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

show more ...

ARM: mach-nspire: Rework support and directory structure

Having a platform need a mach-* directory should be seen as a negative,
it means the platform needs special non-standard handling. ARM64 supp

ARM: mach-nspire: Rework support and directory structure

Having a platform need a mach-* directory should be seen as a negative,
it means the platform needs special non-standard handling. ARM64 support
does not allow mach-* directories at all. While we may not get to that
given all the non-standard architectures we support, we should still try
to get as close as we can and reduce the number of mach directories.

The mach-nspire/ directory and files, provides just one "feature":
having the kernel print the machine name if the DTB does not also contain
a "model" string (which they always do). To reduce the number of mach-*
directories let's do without that feature and remove this directory.

NOTE: The default l2c_aux_mask is now ~0 but these devices never have
this type of cache controller so this is safe.

Signed-off-by: Andrew Davis <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>

show more ...

ARM: mach-sunplus: Rework support and directory structure

Having a platform need a mach-* directory should be seen as a negative,
it means the platform needs special non-standard handling. ARM64 sup

ARM: mach-sunplus: Rework support and directory structure

Having a platform need a mach-* directory should be seen as a negative,
it means the platform needs special non-standard handling. ARM64 support
does not allow mach-* directories at all. While we may not get to that
given all the non-standard architectures we support, we should still try
to get as close as we can and reduce the number of mach directories.

The mach-sunplus/ directory and files, provides just one "feature":
having the kernel print the machine name if the DTB does not also contain
a "model" string (which they always do). To reduce the number of mach-*
directories let's do without that feature and remove this directory.

NOTE: The default l2c_aux_mask is now ~0 but these devices never have
this type of cache controller so this is safe.

Signed-off-by: Andrew Davis <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>

show more ...