Re: [PATCH v3 01/12] lib/kasan: introduce CONFIG_ARCH_DEFER_KASAN option

On Tue, 22 Jul 2025 01:18:52 +0200 Andrey Ryabinin wrote: > >> Architectures that need deferred KASAN should select this option. > >> Architectures that can enable KASAN early will get compile-time > >> optimizations instead of runtime checks. > > > > Looks nice and appears quite mature. I'm r

Re: [PATCH v3 01/12] lib/kasan: introduce CONFIG_ARCH_DEFER_KASAN option

On 7/18/25 12:10 AM, Andrew Morton wrote: > 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 Power

Re: [PATCH v3 08/12] kasan/um: select ARCH_DEFER_KASAN and call kasan_init_generic

On 7/17/25 4:27 PM, Sabyrzhan Tasbolatov wrote: > 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 mecha

Re: [PATCH v3 07/12] kasan/loongarch: select ARCH_DEFER_KASAN and call kasan_init_generic

On 7/17/25 4:27 PM, Sabyrzhan Tasbolatov wrote: > diff --git a/arch/loongarch/include/asm/kasan.h > b/arch/loongarch/include/asm/kasan.h > index 62f139a9c87..0e50e5b5e05 100644 > --- a/arch/loongarch/include/asm/kasan.h > +++ b/arch/loongarch/include/asm/kasan.h > @@ -66,7 +66,6 @@ > #define

Re: [PATCH v3 02/12] kasan: unify static kasan_flag_enabled across modes

On 7/17/25 4:27 PM, Sabyrzhan Tasbolatov wrote: > 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 uncondition

Re: [PATCH v3 01/12] lib/kasan: introduce CONFIG_ARCH_DEFER_KASAN option

On 7/17/25 4:27 PM, 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 memory mappings befo

Re: [PATCH v3 00/12] kasan: unify kasan_arch_is_ready() and remove arch-specific implementations

On 7/17/25 4:27 PM, Sabyrzhan Tasbolatov wrote: > === Testing with patches > > Testing in v3: > > - Compiled every affected arch with no errors: > > $ make CC=clang LD=ld.lld AR=llvm-ar NM=llvm-nm STRIP=llvm-strip \ > OBJCOPY=llvm-objcopy OBJDUMP=llvm-objdump READELF=llvm-readelf \ >

Re: [PATCH v2] vmcoreinfo: Track and log recoverable hardware errors

Hi Breno, kernel test robot noticed the following build warnings: [auto build test WARNING on 97987520025658f30bb787a99ffbd9bbff9ffc9d] url: https://github.com/intel-lab-lkp/linux/commits/Breno-Leitao/vmcoreinfo-Track-and-log-recoverable-hardware-errors/20250721-181439 base

Re: [PATCH v2] vmcoreinfo: Track and log recoverable hardware errors

Hello Borislav, On Mon, Jul 21, 2025 at 03:57:18PM +0200, Borislav Petkov wrote: > On Mon, Jul 21, 2025 at 03:13:40AM -0700, Breno Leitao wrote: > > Introduce a generic infrastructure for tracking recoverable hardware > > errors (HW errors that did not cause a panic) and record them for vmcore > >

Re: [PATCH v2] vmcoreinfo: Track and log recoverable hardware errors

On Mon, Jul 21, 2025 at 03:13:40AM -0700, Breno Leitao wrote: > Introduce a generic infrastructure for tracking recoverable hardware > errors (HW errors that did not cause a panic) and record them for vmcore > consumption. This aids post-mortem crash analysis tools by preserving > a count and times

Re: [PATCH v2] vmcoreinfo: Track and log recoverable hardware errors

Hi Breno, kernel test robot noticed the following build errors: [auto build test ERROR on 97987520025658f30bb787a99ffbd9bbff9ffc9d] url: https://github.com/intel-lab-lkp/linux/commits/Breno-Leitao/vmcoreinfo-Track-and-log-recoverable-hardware-errors/20250721-181439 base

[PATCH] soc: fsl: qe: convert set_multiple() to returning an integer

From: Bartosz Golaszewski The conversion to using the new GPIO line setter callbacks missed the set_multiple() in this file. Convert it to using the new callback. Fixes: 52ccf19527fd ("soc: fsl: qe: use new GPIO line value setter callbacks") Signed-off-by: Bartosz Golaszewski --- This is a foll

[PATCH v2] vmcoreinfo: Track and log recoverable hardware errors

Introduce a generic infrastructure for tracking recoverable hardware errors (HW errors that did not cause a panic) and record them for vmcore consumption. This aids post-mortem crash analysis tools by preserving a count and timestamp for the last occurrence of such errors. This patch adds centrali

Re: [PATCH] ghes: Track number of recovered hardware errors

Hello Tony, On Fri, Jul 18, 2025 at 05:36:50PM +, Luck, Tony wrote: > > I found that I don't need to expose the metrics in vmcore info at all to > > be able to read them from vmcore, given crash/drgn can read those > > symbols. > > > > Global variable hwerror_tracking will be write-only during

[PATCH] powerpc : fix resource leak in holly_init_IRQ()

From: Siyang Liu <1972843...@qq.com> When the 'pic-router' device node lookup fails in holly_init_IRQ(), the function returns without releasing the previously acquired 'tsi_pci' node. This violates the device tree reference counting rules and causes a resource leak. This issue was detected by rul