Message-ID: <cfz7zprwfird7gf5fl36zdpmv3lmht2ibcfwkeulqocw3kokpl@u6snlpuqcc5k>
Date: Mon, 8 Sep 2025 15:02:32 +0200
From: Maciej Wieczor-Retman <maciej.wieczor-retman@...el.com>
To: Andrey Konovalov <andreyknvl@...il.com>
CC: <sohil.mehta@...el.com>, <baohua@...nel.org>, <david@...hat.com>,
	<kbingham@...nel.org>, <weixugc@...gle.com>, <Liam.Howlett@...cle.com>,
	<alexandre.chartre@...cle.com>, <kas@...nel.org>, <mark.rutland@....com>,
	<trintaeoitogc@...il.com>, <axelrasmussen@...gle.com>, <yuanchu@...gle.com>,
	<joey.gouly@....com>, <samitolvanen@...gle.com>, <joel.granados@...nel.org>,
	<graf@...zon.com>, <vincenzo.frascino@....com>, <kees@...nel.org>,
	<ardb@...nel.org>, <thiago.bauermann@...aro.org>, <glider@...gle.com>,
	<thuth@...hat.com>, <kuan-ying.lee@...onical.com>,
	<pasha.tatashin@...een.com>, <nick.desaulniers+lkml@...il.com>,
	<vbabka@...e.cz>, <kaleshsingh@...gle.com>, <justinstitt@...gle.com>,
	<catalin.marinas@....com>, <alexander.shishkin@...ux.intel.com>,
	<samuel.holland@...ive.com>, <dave.hansen@...ux.intel.com>, <corbet@....net>,
	<xin@...or.com>, <dvyukov@...gle.com>, <tglx@...utronix.de>,
	<scott@...amperecomputing.com>, <jason.andryuk@....com>, <morbo@...gle.com>,
	<nathan@...nel.org>, <lorenzo.stoakes@...cle.com>, <mingo@...hat.com>,
	<brgerst@...il.com>, <kristina.martsenko@....com>, <bigeasy@...utronix.de>,
	<luto@...nel.org>, <jgross@...e.com>, <jpoimboe@...nel.org>,
	<urezki@...il.com>, <mhocko@...e.com>, <ada.coupriediaz@....com>,
	<hpa@...or.com>, <leitao@...ian.org>, <peterz@...radead.org>,
	<wangkefeng.wang@...wei.com>, <surenb@...gle.com>, <ziy@...dia.com>,
	<smostafa@...gle.com>, <ryabinin.a.a@...il.com>, <ubizjak@...il.com>,
	<jbohac@...e.cz>, <broonie@...nel.org>, <akpm@...ux-foundation.org>,
	<guoweikang.kernel@...il.com>, <rppt@...nel.org>, <pcc@...gle.com>,
	<jan.kiszka@...mens.com>, <nicolas.schier@...ux.dev>, <will@...nel.org>,
	<jhubbard@...dia.com>, <bp@...en8.de>, <x86@...nel.org>,
	<linux-doc@...r.kernel.org>, <linux-mm@...ck.org>, <llvm@...ts.linux.dev>,
	<linux-kbuild@...r.kernel.org>, <kasan-dev@...glegroups.com>,
	<linux-kernel@...r.kernel.org>, <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v5 15/19] kasan: x86: Apply multishot to the inline
 report handler

On 2025-09-06 at 19:19:06 +0200, Andrey Konovalov wrote:
>On Mon, Aug 25, 2025 at 10:30 PM Maciej Wieczor-Retman
><maciej.wieczor-retman@...el.com> wrote:
>>
>> KASAN by default reports only one tag mismatch and based on other
>> command line parameters either keeps going or panics. The multishot
>> mechanism - enabled either through a command line parameter or by inline
>> enable/disable function calls - lifts that restriction and allows an
>> infinite number of tag mismatch reports to be shown.
>>
>> Inline KASAN uses the INT3 instruction to pass metadata to the report
>> handling function. Currently the "recover" field in that metadata is
>> broken in the compiler layer and causes every inline tag mismatch to
>> panic the kernel.
>>
>> Check the multishot state in the KASAN hook called inside the INT3
>> handling function.
>>
>> Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman@...el.com>
>> ---
>> Changelog v4:
>> - Add this patch to the series.
>>
>>  arch/x86/mm/kasan_inline.c | 3 +++
>>  include/linux/kasan.h      | 3 +++
>>  mm/kasan/report.c          | 8 +++++++-
>>  3 files changed, 13 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/mm/kasan_inline.c b/arch/x86/mm/kasan_inline.c
>> index 9f85dfd1c38b..f837caf32e6c 100644
>> --- a/arch/x86/mm/kasan_inline.c
>> +++ b/arch/x86/mm/kasan_inline.c
>> @@ -17,6 +17,9 @@ bool kasan_inline_handler(struct pt_regs *regs)
>>         if (!kasan_report((void *)addr, size, write, pc))
>>                 return false;
>>
>> +       if (kasan_multi_shot_enabled())
>> +               return true;
>
>It's odd this this is required on x86 but not on arm64, see my comment
>on the patch that adds kasan_inline_handler().
>

I think this is needed if we want to keep the kasan_inline_recover below.
Because without this patch, kasan_report() will report a mismatch, an then die()
will be called. So the multishot gets ignored.

I'll check what happens on arm64 when a mismatch happens with inline mode +
multishot.

>
>> +
>>         kasan_inline_recover(recover, "Oops - KASAN", regs, metadata, die);
>>
>>         return true;
>> diff --git a/include/linux/kasan.h b/include/linux/kasan.h
>> index 8691ad870f3b..7a2527794549 100644
>> --- a/include/linux/kasan.h
>> +++ b/include/linux/kasan.h
>> @@ -663,7 +663,10 @@ void kasan_non_canonical_hook(unsigned long addr);
>>  static inline void kasan_non_canonical_hook(unsigned long addr) { }
>>  #endif /* CONFIG_KASAN_GENERIC || CONFIG_KASAN_SW_TAGS */
>>
>> +bool kasan_multi_shot_enabled(void);
>> +
>>  #ifdef CONFIG_KASAN_SW_TAGS
>> +
>>  /*
>>   * The instrumentation allows to control whether we can proceed after
>>   * a crash was detected. This is done by passing the -recover flag to
>> diff --git a/mm/kasan/report.c b/mm/kasan/report.c
>> index 50d487a0687a..9e830639e1b2 100644
>> --- a/mm/kasan/report.c
>> +++ b/mm/kasan/report.c
>> @@ -121,6 +121,12 @@ static void report_suppress_stop(void)
>>  #endif
>>  }
>>
>> +bool kasan_multi_shot_enabled(void)
>> +{
>> +       return test_bit(KASAN_BIT_MULTI_SHOT, &kasan_flags);
>> +}
>> +EXPORT_SYMBOL(kasan_multi_shot_enabled);
>> +
>>  /*
>>   * Used to avoid reporting more than one KASAN bug unless kasan_multi_shot
>>   * is enabled. Note that KASAN tests effectively enable kasan_multi_shot
>> @@ -128,7 +134,7 @@ static void report_suppress_stop(void)
>>   */
>>  static bool report_enabled(void)
>>  {
>> -       if (test_bit(KASAN_BIT_MULTI_SHOT, &kasan_flags))
>> +       if (kasan_multi_shot_enabled())
>>                 return true;
>>         return !test_and_set_bit(KASAN_BIT_REPORTED, &kasan_flags);
>>  }
>> --
>> 2.50.1
>>

-- 
Kind regards
Maciej Wieczór-Retman

Powered by blists - more mailing lists