[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <31bac00f-7903-46f7-a5a0-1e8f5fd8b9ab@arm.com>
Date: Wed, 13 Aug 2025 15:49:15 +0100
From: Ada Couprie Diaz <ada.coupriediaz@....com>
To: Maciej Wieczor-Retman <maciej.wieczor-retman@...el.com>
Cc: nathan@...nel.org, arnd@...db.de, broonie@...nel.org,
Liam.Howlett@...cle.com, urezki@...il.com, will@...nel.org,
kaleshsingh@...gle.com, rppt@...nel.org, leitao@...ian.org, coxu@...hat.com,
surenb@...gle.com, akpm@...ux-foundation.org, luto@...nel.org,
jpoimboe@...nel.org, changyuanl@...gle.com, hpa@...or.com,
dvyukov@...gle.com, kas@...nel.org, corbet@....net,
vincenzo.frascino@....com, smostafa@...gle.com,
nick.desaulniers+lkml@...il.com, morbo@...gle.com, andreyknvl@...il.com,
alexander.shishkin@...ux.intel.com, thiago.bauermann@...aro.org,
catalin.marinas@....com, ryabinin.a.a@...il.com, jan.kiszka@...mens.com,
jbohac@...e.cz, dan.j.williams@...el.com, joel.granados@...nel.org,
baohua@...nel.org, kevin.brodsky@....com, nicolas.schier@...ux.dev,
pcc@...gle.com, andriy.shevchenko@...ux.intel.com, wei.liu@...nel.org,
bp@...en8.de, xin@...or.com, pankaj.gupta@....com, vbabka@...e.cz,
glider@...gle.com, jgross@...e.com, kees@...nel.org, jhubbard@...dia.com,
joey.gouly@....com, ardb@...nel.org, thuth@...hat.com,
pasha.tatashin@...een.com, kristina.martsenko@....com,
bigeasy@...utronix.de, lorenzo.stoakes@...cle.com, jason.andryuk@....com,
david@...hat.com, graf@...zon.com, wangkefeng.wang@...wei.com,
ziy@...dia.com, mark.rutland@....com, dave.hansen@...ux.intel.com,
samuel.holland@...ive.com, kbingham@...nel.org, trintaeoitogc@...il.com,
scott@...amperecomputing.com, justinstitt@...gle.com,
kuan-ying.lee@...onical.com, maz@...nel.org, tglx@...utronix.de,
samitolvanen@...gle.com, mhocko@...e.com, nunodasneves@...ux.microsoft.com,
brgerst@...il.com, willy@...radead.org, ubizjak@...il.com,
peterz@...radead.org, mingo@...hat.com, sohil.mehta@...el.com,
linux-mm@...ck.org, linux-kbuild@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, x86@...nel.org, llvm@...ts.linux.dev,
kasan-dev@...glegroups.com, linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org, Ada Couprie Diaz <ada.coupriediaz@....com>
Subject: Re: [PATCH v4 13/18] kasan: arm64: x86: Handle int3 for inline KASAN
reports
Hi,
On 12/08/2025 14:23, Maciej Wieczor-Retman wrote:
> [...]
>
> Make part of that hook - which decides whether to die or recover from a
> tag mismatch - arch independent to avoid duplicating a long comment on
> both x86 and arm64 architectures.
>
> Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman@...el.com>
> ---
> [...]
> diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
> index f528b6041f6a..b9bdabc14ad1 100644
> --- a/arch/arm64/kernel/traps.c
> +++ b/arch/arm64/kernel/traps.c
> @@ -1068,22 +1068,7 @@ int kasan_brk_handler(struct pt_regs *regs, unsigned long esr)
>
> kasan_report(addr, size, write, pc);
>
> - /*
> - * The instrumentation allows to control whether we can proceed after
> - * a crash was detected. This is done by passing the -recover flag to
> - * the compiler. Disabling recovery allows to generate more compact
> - * code.
> - *
> - * Unfortunately disabling recovery doesn't work for the kernel right
> - * now. KASAN reporting is disabled in some contexts (for example when
> - * the allocator accesses slab object metadata; this is controlled by
> - * current->kasan_depth). All these accesses are detected by the tool,
> - * even though the reports for them are not printed.
> - *
> - * This is something that might be fixed at some point in the future.
> - */
> - if (!recover)
> - die("Oops - KASAN", regs, esr);
> + kasan_inline_recover(recover, "Oops - KASAN", regs, esr);
It seems that `die` is missing as the last argument, otherwise
CONFIG_KASAN_SW_TAGS will not build on arm64.
With the fix, it builds fully without further issues.
Thanks,
Ada
Powered by blists - more mailing lists