This patch series addresses the fragmentation in KASAN initialization
across architectures by introducing a unified approach that eliminates
duplicate static keys and arch-specific kasan_arch_is_ready()
implementations.
The core issue is that different architectures have inconsistent approaches
to
Introduce CONFIG_ARCH_DEFER_KASAN to identify architectures that need
to defer KASAN initialization until shadow memory is properly set up.
Some architectures (like PowerPC with radix MMU) need to set up their
shadow memory mappings before KASAN can be safely enabled, while others
(like s390, x86,
This patch completes:
1. Adding kasan_shadow_initialized() checks to existing wrapper functions
2. Replacing kasan_arch_is_ready() calls with kasan_shadow_initialized()
3. Creating wrapper functions for internal functions that need shadow
readiness checks
4. Removing the kasan_arch_is_ready() fa
Call kasan_init_generic() which handles Generic KASAN initialization
and prints the banner. Since s390 doesn't select ARCH_DEFER_KASAN,
kasan_enable() will be a no-op, and kasan_enabled() will return
IS_ENABLED(CONFIG_KASAN) for optimal compile-time behavior.
s390 sets up KASAN mappings in the dec
Call kasan_init_generic() which handles Generic KASAN initialization
and prints the banner. Since riscv doesn't select ARCH_DEFER_KASAN,
kasan_enable() will be a no-op, and kasan_enabled() will return
IS_ENABLED(CONFIG_KASAN) for optimal compile-time behavior.
Closes: https://bugzilla.kernel.org/s
UserMode Linux needs deferred KASAN initialization as it has a custom
kasan_arch_is_ready() implementation that tracks shadow memory readiness
via the kasan_um_is_ready flag.
Select ARCH_DEFER_KASAN to enable the unified static key mechanism
for runtime KASAN control. Call kasan_init_generic() whi
Call kasan_init_generic() which handles Generic KASAN initialization
and prints the banner. Since x86 doesn't select ARCH_DEFER_KASAN,
kasan_enable() will be a no-op, and kasan_enabled() will return
IS_ENABLED(CONFIG_KASAN) for optimal compile-time behavior.
Closes: https://bugzilla.kernel.org/sho
PowerPC with radix MMU is the primary architecture that needs deferred
KASAN initialization, as it requires complex shadow memory setup before
KASAN can be safely enabled.
Select ARCH_DEFER_KASAN for PPC_RADIX_MMU to enable the static key
mechanism for runtime KASAN control. Other PowerPC configur
LoongArch needs deferred KASAN initialization as it has a custom
kasan_arch_is_ready() implementation that tracks shadow memory
readiness via the kasan_early_stage flag.
Select ARCH_DEFER_KASAN to enable the unified static key mechanism
for runtime KASAN control. Call kasan_init_generic() which ha
Historically, the runtime static key kasan_flag_enabled existed only for
CONFIG_KASAN_HW_TAGS mode. Generic and SW_TAGS modes either relied on
architecture-specific kasan_arch_is_ready() implementations or evaluated
KASAN checks unconditionally, leading to code duplication.
This patch implements t
Call kasan_init_generic() which handles Generic KASAN initialization.
Since arm64 doesn't select ARCH_DEFER_KASAN, this will be a no-op for
the runtime flag but will print the initialization banner.
For SW_TAGS and HW_TAGS modes, their respective init functions will
handle the flag enabling.
Clos
Call kasan_init_generic() which handles Generic KASAN initialization
and prints the banner. Since xtensa doesn't select ARCH_DEFER_KASAN,
kasan_enable() will be a no-op.
Note that arch/xtensa still uses "current" instead of "init_task" pointer
in `current->kasan_depth = 0;` to enable error message
Call kasan_init_generic() which handles Generic KASAN initialization
and prints the banner. Since arm doesn't select ARCH_DEFER_KASAN,
kasan_enable() will be a no-op, but kasan_enabled() will return
IS_ENABLED(CONFIG_KASAN) for optimal compile-time behavior.
Closes: https://bugzilla.kernel.org/sho
On 7/8/2025 4:35 AM, Nayna Jain wrote:
>
> On 7/2/25 10:07 PM, GONG Ruiqi wrote:
>>
>> ...
>>
>> "We encountered a boot failure issue in an in-house testing, where the
>> kernel refused to load its modules since it couldn't verify their
>> signature. The root cause turned out to be the early re
On Thu, Jul 17, 2025 at 12:32:34PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> Hi,
>
> Something that's been bugging me over the years is how some drivers have
> had to adopt file-scoped variables to pass data into something like the
> syscore operations. This is often harmless, but
Thanks, Richard.
I've opened an issue for the SPDX License List
https://github.com/spdx/license-list-XML/issues/2785 and if no one else reacts
faster, I plan to submit a PR to implement this next week.
-- zvr --
From: Richard Fontana
Sent: Sunday, July 13, 2025
From: Thierry Reding
Pass a pointer to the syscore_ops structure that was registered to the
callbacks. This enables callbacks to act on instance data (syscore_ops
can be embedded into other structures, and driver-specific data can be
obtained using container_of()) rather than the current practice
From: Thierry Reding
Hi,
Something that's been bugging me over the years is how some drivers have
had to adopt file-scoped variables to pass data into something like the
syscore operations. This is often harmless, but usually leads to drivers
not being able to deal with multiple instances, or ad
From: Thierry Reding
This enables the syscore callbacks to obtain the PCI context without
relying on a separate global variable.
Signed-off-by: Thierry Reding
---
arch/mips/pci/pci-alchemy.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/mip
From: Thierry Reding
This enables the syscore callbacks to obtain the mbus context without
relying on a separate global variable.
Signed-off-by: Thierry Reding
---
drivers/bus/mvebu-mbus.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/bus/mve
From: Thierry Reding
This enables the syscore callbacks to obtain the TCU context without
relying on a separate global variable.
Signed-off-by: Thierry Reding
---
drivers/clk/ingenic/tcu.c | 54 ++-
1 file changed, 25 insertions(+), 29 deletions(-)
diff --g
From: Thierry Reding
This enables the syscore callbacks to obtain the clock context without
relying on a separate global variable.
Signed-off-by: Thierry Reding
---
drivers/clk/mvebu/common.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/clk
From: Thierry Reding
This enables the syscore callbacks to obtain the IRQ chip context
without relying on a separate global variable.
Signed-off-by: Thierry Reding
---
drivers/irqchip/irq-imx-gpcv2.c | 29 +++--
1 file changed, 11 insertions(+), 18 deletions(-)
diff --
From: Thierry Reding
Rather than relying on a global variable, make use of the fact that the
syscore ops are embedded in the PMC context and can be obtained via
container_of().
Signed-off-by: Thierry Reding
---
drivers/soc/tegra/pmc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/driv
Add JIT support for the load_acquire and store_release instructions. The
implementation is similar to the kernel where:
load_acquire => plain load -> lwsync
store_release => lwsync -> plain store
To test the correctness of the implementation, following selftests were
run:
[fed
On 7/15/2025 7:51 PM, Manivannan Sadhasivam via B4 Relay wrote:
Hi,
Currently, in the event of AER/DPC, PCI core will try to reset the slot (Root
Port) and its subordinate devices by invoking bridge control reset and FLR. But
in some cases like AER Fatal error, it might be necessary to reset
On Tue, Jul 15, 2025 at 07:51:05PM +0530, Manivannan Sadhasivam via B4 Relay
wrote:
> From: Manivannan Sadhasivam
>
> The PCI link, when down, needs to be recovered to bring it back. But on
> some platforms, that cannot be done in a generic way as link recovery
> procedure is platform specific. S
- Original Message -
> From: "Bjorn Helgaas"
> To: "Timothy Pearson"
> Cc: "linuxppc-dev" , "linux-kernel"
> , "linux-pci"
> , "Madhavan Srinivasan" ,
> "Michael Ellerman" ,
> "christophe leroy" , "Naveen N Rao"
> , "Bjorn Helgaas"
> , "Shawn Anastasio"
> Sent: Thursday, July 17, 2
On Tue, Jul 15, 2025 at 07:51:04PM +0530, Manivannan Sadhasivam via B4 Relay
wrote:
> From: Manivannan Sadhasivam
>
> Some host bridge devices require resetting the Root Ports in a platform
> specific way to recover them from error conditions such as Fatal AER
> errors, Link Down etc... So introd
Add JIT support for the load_acquire and store_release instructions. The
implementation is similar to the kernel where:
load_acquire => plain load -> lwsync
store_release => lwsync -> plain store
To test the correctness of the implementation, following selftests were
run:
[fed
Puranjay Mohan writes:
Somehow the cover letter for this patch was missed, adding it here:
To test the functionality of these special instructions, a tool called
blitmus[0] was used to convert the following baseline litmus test[1] to bpf
programs:
C MP+poonceonces
(*
* Result: Sometimes
On Thu, 17 Jul 2025 19:27:21 +0500 Sabyrzhan Tasbolatov
wrote:
> Introduce CONFIG_ARCH_DEFER_KASAN to identify architectures that need
> to defer KASAN initialization until shadow memory is properly set up.
>
> Some architectures (like PowerPC with radix MMU) need to set up their
> shadow memor
This patch enables batched RX buffer replenishment in ibmveth by
using the new firmware-supported h_add_logical_lan_buffers() hcall
to submit up to 8 RX buffers in a single call, instead of repeatedly
calling the single-buffer h_add_logical_lan_buffer() hcall.
During the probe, with the patch, th
On Tue, Jul 15, 2025 at 04:39:06PM -0500, Timothy Pearson wrote:
> The existing PowerNV hotplug code did not handle surprise plug events
> correctly, leading to a complete failure of the hotplug system after
> device removal and a required reboot to detect new devices.
> +++ b/drivers/pci/hotplug/
On Tue, Jul 15, 2025 at 04:31:49PM -0500, Timothy Pearson wrote:
> Hello all,
>
> This series includes several fixes for bugs in the PowerNV PCIe hotplug
> driver that were discovered in testing with a Microsemi Switchtec PM8533
> PFX 48xG3 PCIe switch on a PowerNV system, as well as one workaroun
35 matches
Mail list logo
