Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rmk/linux
authorLinus Torvalds <torvalds@linux-foundation.org>
Thu, 5 Jun 2025 18:33:09 +0000 (11:33 -0700)
committerLinus Torvalds <torvalds@linux-foundation.org>
Thu, 5 Jun 2025 18:33:09 +0000 (11:33 -0700)
commitaef7457540e0407c66a93491cffccd2a6979987c
tree8bc4cc845d6ee5523fd64c7f7232c6cc049bbced
parent7fdaba912981e6fe7585517ccf3b5da59e17592e
parent293bb049380e14a176e98d3701b85b6b5d3140fd
Merge tag 'for-linus' of git://git./linux/kernel/git/rmk/linux

Pull ARM fixes from Russell King:

 - Fix arch_memremap_can_ram_remap() which incorrectly passed a PFN to
   memblock_is_map_memory rather than the actual address.

 - Disallow kernel mode NEON when IRQs are disabled

   Explanation:

     "To avoid having to preserve/restore kernel mode NEON state when
      such a softirq is taken softirqs are now disabled when using the
      NEON from task context."

   should explain that it's nested kernel mode.

   In other words, softirqs from user mode are fine, because the context
   will be preserved. softirqs from kernel mode may be from a context
   that has already saved the user NEON state, and thus we would need to
   preserve the NEON state for the parent kernel mode context, and this
   we don't allow.

   The problem occurs when the kernel context disables hard IRQs, and
   then uses NEON. When it's finished, and restores the userspace NEON
   state, we call local_bh_enable() with hard IRQs disabled, which
   causes a warning.

   This commit addresses that by disallowing the use of NEON with hard
   IRQs disabled.

https://lore.kernel.org/all/20250516231858.27899-4-ebiggers@kernel.org/T/#m104841b6e9346b1814c8b0fb9f2340551b0cd3e8

   has some further context

* tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rmk/linux:
  ARM: 9446/1: Disallow kernel mode NEON when IRQs are disabled
  ARM: 9447/1: arm/memremap: fix arch_memremap_can_ram_remap()
arch/arm/include/asm/simd.h