- 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" - this needs a
better 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.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEuNNh8scc2k/wOAE+9OeQG+StrGQFAmg9k5MACgkQ9OeQG+St
rGTsIg//R8AysyZIHWCzO+j7UFZPQ+jUZ0Qf0NMA3Ss/Bh724BtDWIMRo30/ADtX
nwJhGnFVenr9jdGuUBmE8R25QyfZIz2U45hGVqUgSL9W96A8PPsuaR7oXhvezq68
Wj+UUTzem4l1bgK416qEROPgY/dtYCL5AbPA+SdH+LSMvS9phkhT6PkGJRC14tZ9
kLNR4PyA9/DC6N6wIU8v9pWezSoOBn/ISBpb67BB0OzZPlmgoJJOXbSNzIHaJc4C
YjjJCHRmZL2w/U4HyEc8qXyHMPggEKtDas6mwrpxV/fjoReC/vk3tvuRxy1Mt1Ny
BIIOA/Hauz8O9+aqfdqABK92tMiLx7NA9bWQDndIisfD/nRFyrpFDUbw1+d4EemU
qzDmKSNWK9nsC28kE8F5M4XLacHu4AQN10Ktjr5LXGoMmPfDz0xssd2uDJkbL4Zq
wHVea4HPX8Ykrv6yg+iRZp54z25+ckD+kf93zhutabaa/zVdAHAU9Lk/Uqm2G1R2
5huER0vvLJF3+mYu9mRjodssOUsEVwPbBuGiwJ7DY2a6faexuJv/sU5ZyHhwHb/B
TjaYbektcllYWly+KN33XzZXuVVpY9DbRq/2MCFbxMYjHxGjj7QiytTm8tI6VX26
yi8CQ+8/0SXoBPaDjb2y4n6qIxcjiBcdQ8DxDbA9Od0glzJQUhE=
=V4ew
-----END PGP SIGNATURE-----
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/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()
Commit
c79f816311 ("ARM: 9283/1: permit non-nested kernel mode NEON in softirq context")
relaxed the rules around the use of SIMD instructions in kernel mode on
ARM, to allow such use when serving a softirq. 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.
However, the fact that the softirq API does not allow unmasking of
softirqs with interrupts disabled was overlooked, resulting in a WARN()
in some cases, as reported by Guenter:
WARNING: CPU: 0 PID: 1145 at kernel/softirq.c:369 __local_bh_enable_ip+0x118/0x194
Call trace:
unwind_backtrace from show_stack+0x10/0x14
show_stack from dump_stack_lvl+0x7c/0xac
dump_stack_lvl from __warn+0x7c/0x1b8
__warn from warn_slowpath_fmt+0x19c/0x1a4
warn_slowpath_fmt from __local_bh_enable_ip+0x118/0x194
__local_bh_enable_ip from crc_t10dif_arch+0xd4/0xe8
crc_t10dif_arch from crc_t10dif_wrapper+0x14/0x1c
crc_t10dif_wrapper from crc_main_test+0x178/0x360
crc_main_test from kunit_try_run_case+0x78/0x1e0
kunit_try_run_case from kunit_generic_run_threadfn_adapter+0x1c/0x34
kunit_generic_run_threadfn_adapter from kthread+0x118/0x254
kthread from ret_from_fork+0x14/0x28
While disabling softirqs is not really needed when running with IRQs
disabled (given that the only way a softirq can be delivered
asynchrously is over the back of an IRQ), let's not complicate this
logic more than needed, and simply disallow use of the NEON in kernel
mode when IRQs are disabled.
Another approach might be to only disable and re-enable softirqs if IRQs
are enabled, but other than the test case above, there are no clear use
cases for doing non-trivial arithmetic processing (hence using an
accelerated SIMD implementation) with IRQs disabled.
Reported-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/all/389b899f-893c-4855-9e30-d8920a5d6f91@roeck-us.net
Reviewed-by: Eric Biggers <ebiggers@kernel.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
We currently only permit kernel mode NEON in process context, to avoid
the need to preserve/restore the NEON register file when taking an
exception while running in the kernel.
Like we did on arm64, we can relax this restriction substantially, by
permitting kernel mode NEON from softirq context, while ensuring that
softirq processing is disabled when the NEON is being used in task
context. This guarantees that only NEON context belonging to user space
needs to be preserved and restored, which is already taken care of.
This is especially relevant for network encryption, where incoming
frames are typically handled in softirq context, and deferring software
decryption to a kernel thread or falling back to C code are both
undesirable from a performance PoV.
Tested-by: Martin Willi <martin@strongswan.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Linus Torvalds
Ard Biesheuvel
Herbert Xu