arch/arm/kernel/setup.c | 6 ++++++ arch/arm/mm/kasan_init.c | 2 ++ arch/arm64/mm/kasan_init.c | 6 ++++++ arch/loongarch/mm/kasan_init.c | 2 ++ arch/powerpc/mm/kasan/init_32.c | 5 ++++- arch/powerpc/mm/kasan/init_book3e_64.c | 3 +++ arch/powerpc/mm/kasan/init_book3s_64.c | 3 +++ arch/riscv/mm/kasan_init.c | 3 +++ arch/um/kernel/mem.c | 5 ++++- arch/x86/mm/kasan_init_64.c | 3 +++ arch/xtensa/kernel/setup.c | 1 + arch/xtensa/mm/kasan_init.c | 3 +++ include/linux/kasan-enabled.h | 6 ++++-- mm/kasan/common.c | 20 ++++++++++++++++-- mm/kasan/generic.c | 17 ++++++++++++++-- mm/kasan/hw_tags.c | 28 ++------------------------ mm/kasan/init.c | 6 ++++++ mm/kasan/quarantine.c | 3 +++ mm/kasan/report.c | 4 +++- mm/kasan/shadow.c | 11 +++++++++- mm/kasan/sw_tags.c | 6 ++++++ 21 files changed, 107 insertions(+), 36 deletions(-)
Currently only hw_tags mode of kasan can be enabled or disabled with
kernel parameter kasan=on|off for built kernel. For kasan generic and
sw_tags mode, there's no way to disable them once kernel is built.
This is not convenient sometime, e.g in system kdump is configured.
When the 1st kernel has KASAN enabled and crash triggered to switch to
kdump kernel, the generic or sw_tags mode will cost much extra memory
while in fact it's meaningless to have kasan in kdump kernel
There are two parts of big amount of memory requiring for kasan enabed
kernel. One is the direct memory mapping shadow of kasan, which is 1/8
of system RAM in generic mode and 1/16 of system RAM in sw_tags mode;
the other is the shadow meomry for vmalloc which causes big meomry
usage in kdump kernel because of lazy vmap freeing. By introducing
"kasan=off|on", if we specify 'kasan=off', the former is avoided by skipping
the kasan_init(), and the latter is avoided by not building the vmalloc
shadow for vmalloc.
So this patchset moves the kasan=on|off out of hw_tags scope and into
common code to make it visible in generic and sw_tags mode too. Then we
can add kasan=off in kdump kernel to reduce the unneeded meomry cost for
kasan.
Testing:
========
- Testing on x86_64 and arm64 for generic mode passed when kasan=on or
kasan=off.
- Testing on arm64 with sw_tags mode passed when kasan=off is set. But
when I tried to test sw_tags on arm64, the system bootup failed. It's
not introduced by my patchset, the original code has the bug. I have
reported it to upstream.
- System is broken in KASAN sw_tags mode during bootup
- https://lore.kernel.org/all/aSXKqJTkZPNskFop@MiWiFi-R3L-srv/T/#u
- Haven't found hardware to test hw_tags. If anybody has the system,
please help take a test.
Changelog:
====
v3->v4:
- Rebase code to the latest linux-next/master to make the whole patchset
set on top of
[PATCH 0/2] kasan: cleanups for kasan_enabled() checks
[PATCH v6 0/2] kasan: unify kasan_enabled() and remove arch-specific implementations
v2->v3:
- Fix a building error on UML ARCH when CONFIG_KASAN is not set. The
change of fixing is appended into patch patch 11. This is reported
by LKP, thanks to them.
v1->v2:
- Add __ro_after_init for kasan_arg_disabled, and remove redundant blank
lines in mm/kasan/common.c. Thanks to Marco.
- Fix a code bug in <linux/kasan-enabled.h> when CONFIG_KASAN is unset,
this is found out by SeongJae and Lorenzo, and also reported by LKP
report, thanks to them.
- Add a missing kasan_enabled() checking in kasan_report(). This will
cause below KASAN report info even though kasan=off is set:
==================================================================
BUG: KASAN: stack-out-of-bounds in tick_program_event+0x130/0x150
Read of size 4 at addr ffff00005f747778 by task swapper/0/1
CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.16.0+ #8 PREEMPT(voluntary)
Hardware name: GIGABYTE R272-P30-JG/MP32-AR0-JG, BIOS F31n (SCP: 2.10.20220810) 09/30/2022
Call trace:
show_stack+0x30/0x90 (C)
dump_stack_lvl+0x7c/0xa0
print_address_description.constprop.0+0x90/0x310
print_report+0x104/0x1f0
kasan_report+0xc8/0x110
__asan_report_load4_noabort+0x20/0x30
tick_program_event+0x130/0x150
......snip...
==================================================================
- Add jump_label_init() calling before kasan_init() in setup_arch() in these
architectures: xtensa, arm. Because they currenly rely on
jump_label_init() in main() which is a little late. Then the early static
key kasan_flag_enabled in kasan_init() won't work.
- In UML architecture, change to enable kasan_flag_enabled in arch_mm_preinit()
because kasan_init() is enabled before main(), there's no chance to operate
on static key in kasan_init().
Baoquan He (12):
mm/kasan: add conditional checks in functions to return directly if
kasan is disabled
mm/kasan: move kasan= code to common place
mm/kasan/sw_tags: don't initialize kasan if it's disabled
arch/arm: don't initialize kasan if it's disabled
arch/arm64: don't initialize kasan if it's disabled
arch/loongarch: don't initialize kasan if it's disabled
arch/powerpc: don't initialize kasan if it's disabled
arch/riscv: don't initialize kasan if it's disabled
arch/x86: don't initialize kasan if it's disabled
arch/xtensa: don't initialize kasan if it's disabled
arch/um: don't initialize kasan if it's disabled
mm/kasan: make kasan=on|off take effect for all three modes
arch/arm/kernel/setup.c | 6 ++++++
arch/arm/mm/kasan_init.c | 2 ++
arch/arm64/mm/kasan_init.c | 6 ++++++
arch/loongarch/mm/kasan_init.c | 2 ++
arch/powerpc/mm/kasan/init_32.c | 5 ++++-
arch/powerpc/mm/kasan/init_book3e_64.c | 3 +++
arch/powerpc/mm/kasan/init_book3s_64.c | 3 +++
arch/riscv/mm/kasan_init.c | 3 +++
arch/um/kernel/mem.c | 5 ++++-
arch/x86/mm/kasan_init_64.c | 3 +++
arch/xtensa/kernel/setup.c | 1 +
arch/xtensa/mm/kasan_init.c | 3 +++
include/linux/kasan-enabled.h | 6 ++++--
mm/kasan/common.c | 20 ++++++++++++++++--
mm/kasan/generic.c | 17 ++++++++++++++--
mm/kasan/hw_tags.c | 28 ++------------------------
mm/kasan/init.c | 6 ++++++
mm/kasan/quarantine.c | 3 +++
mm/kasan/report.c | 4 +++-
mm/kasan/shadow.c | 11 +++++++++-
mm/kasan/sw_tags.c | 6 ++++++
21 files changed, 107 insertions(+), 36 deletions(-)
--
2.41.0
On Fri, Nov 28, 2025 at 4:33 AM Baoquan He <bhe@redhat.com> wrote: > > Currently only hw_tags mode of kasan can be enabled or disabled with > kernel parameter kasan=on|off for built kernel. For kasan generic and > sw_tags mode, there's no way to disable them once kernel is built. > > This is not convenient sometime, e.g in system kdump is configured. > When the 1st kernel has KASAN enabled and crash triggered to switch to > kdump kernel, the generic or sw_tags mode will cost much extra memory > while in fact it's meaningless to have kasan in kdump kernel > > There are two parts of big amount of memory requiring for kasan enabed > kernel. One is the direct memory mapping shadow of kasan, which is 1/8 > of system RAM in generic mode and 1/16 of system RAM in sw_tags mode; > the other is the shadow meomry for vmalloc which causes big meomry > usage in kdump kernel because of lazy vmap freeing. By introducing > "kasan=off|on", if we specify 'kasan=off', the former is avoided by skipping > the kasan_init(), and the latter is avoided by not building the vmalloc > shadow for vmalloc. > > So this patchset moves the kasan=on|off out of hw_tags scope and into > common code to make it visible in generic and sw_tags mode too. Then we > can add kasan=off in kdump kernel to reduce the unneeded meomry cost for > kasan. > > Testing: > ======== > - Testing on x86_64 and arm64 for generic mode passed when kasan=on or > kasan=off. > > - Testing on arm64 with sw_tags mode passed when kasan=off is set. But > when I tried to test sw_tags on arm64, the system bootup failed. It's > not introduced by my patchset, the original code has the bug. I have > reported it to upstream. > - System is broken in KASAN sw_tags mode during bootup > - https://lore.kernel.org/all/aSXKqJTkZPNskFop@MiWiFi-R3L-srv/T/#u This will hopefully be fixed soon, so you'll be able to test. > > - Haven't found hardware to test hw_tags. If anybody has the system, > please help take a test. You don't need hardware to run the HW_TAGS mode, just pass -machine virt,mte=on to QEMU. I also wonder if we should keep this kasan=off functionality conservative and limit it to x86 and arm64 (since these are the only two tested architectures). > > Changelog: > ==== > v3->v4: > - Rebase code to the latest linux-next/master to make the whole patchset > set on top of > [PATCH 0/2] kasan: cleanups for kasan_enabled() checks > [PATCH v6 0/2] kasan: unify kasan_enabled() and remove arch-specific implementations Note that are also: [PATCH 1/2] kasan: remove __kasan_save_free_info wrapper [PATCH 2/2] kasan: cleanup of kasan_enabled() checks But I don't know if there will be any conflicts with these. > > v2->v3: > - Fix a building error on UML ARCH when CONFIG_KASAN is not set. The > change of fixing is appended into patch patch 11. This is reported > by LKP, thanks to them. > > v1->v2: > - Add __ro_after_init for kasan_arg_disabled, and remove redundant blank > lines in mm/kasan/common.c. Thanks to Marco. > - Fix a code bug in <linux/kasan-enabled.h> when CONFIG_KASAN is unset, > this is found out by SeongJae and Lorenzo, and also reported by LKP > report, thanks to them. > - Add a missing kasan_enabled() checking in kasan_report(). This will > cause below KASAN report info even though kasan=off is set: > ================================================================== > BUG: KASAN: stack-out-of-bounds in tick_program_event+0x130/0x150 > Read of size 4 at addr ffff00005f747778 by task swapper/0/1 > > CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.16.0+ #8 PREEMPT(voluntary) > Hardware name: GIGABYTE R272-P30-JG/MP32-AR0-JG, BIOS F31n (SCP: 2.10.20220810) 09/30/2022 > Call trace: > show_stack+0x30/0x90 (C) > dump_stack_lvl+0x7c/0xa0 > print_address_description.constprop.0+0x90/0x310 > print_report+0x104/0x1f0 > kasan_report+0xc8/0x110 > __asan_report_load4_noabort+0x20/0x30 > tick_program_event+0x130/0x150 > ......snip... > ================================================================== > > - Add jump_label_init() calling before kasan_init() in setup_arch() in these > architectures: xtensa, arm. Because they currenly rely on > jump_label_init() in main() which is a little late. Then the early static > key kasan_flag_enabled in kasan_init() won't work. > > - In UML architecture, change to enable kasan_flag_enabled in arch_mm_preinit() > because kasan_init() is enabled before main(), there's no chance to operate > on static key in kasan_init(). > > Baoquan He (12): > mm/kasan: add conditional checks in functions to return directly if > kasan is disabled > mm/kasan: move kasan= code to common place > mm/kasan/sw_tags: don't initialize kasan if it's disabled > arch/arm: don't initialize kasan if it's disabled > arch/arm64: don't initialize kasan if it's disabled > arch/loongarch: don't initialize kasan if it's disabled > arch/powerpc: don't initialize kasan if it's disabled > arch/riscv: don't initialize kasan if it's disabled > arch/x86: don't initialize kasan if it's disabled > arch/xtensa: don't initialize kasan if it's disabled > arch/um: don't initialize kasan if it's disabled > mm/kasan: make kasan=on|off take effect for all three modes > > arch/arm/kernel/setup.c | 6 ++++++ > arch/arm/mm/kasan_init.c | 2 ++ > arch/arm64/mm/kasan_init.c | 6 ++++++ > arch/loongarch/mm/kasan_init.c | 2 ++ > arch/powerpc/mm/kasan/init_32.c | 5 ++++- > arch/powerpc/mm/kasan/init_book3e_64.c | 3 +++ > arch/powerpc/mm/kasan/init_book3s_64.c | 3 +++ > arch/riscv/mm/kasan_init.c | 3 +++ > arch/um/kernel/mem.c | 5 ++++- > arch/x86/mm/kasan_init_64.c | 3 +++ > arch/xtensa/kernel/setup.c | 1 + > arch/xtensa/mm/kasan_init.c | 3 +++ > include/linux/kasan-enabled.h | 6 ++++-- > mm/kasan/common.c | 20 ++++++++++++++++-- > mm/kasan/generic.c | 17 ++++++++++++++-- > mm/kasan/hw_tags.c | 28 ++------------------------ > mm/kasan/init.c | 6 ++++++ > mm/kasan/quarantine.c | 3 +++ > mm/kasan/report.c | 4 +++- > mm/kasan/shadow.c | 11 +++++++++- > mm/kasan/sw_tags.c | 6 ++++++ > 21 files changed, 107 insertions(+), 36 deletions(-) One part that's still missing is a Documentation change. > > -- > 2.41.0 >
Hi Andrey, On 12/04/25 at 05:38pm, Andrey Konovalov wrote: > On Fri, Nov 28, 2025 at 4:33 AM Baoquan He <bhe@redhat.com> wrote: > > ...snip... > > Testing: > > ======== > > - Testing on x86_64 and arm64 for generic mode passed when kasan=on or > > kasan=off. > > > > - Testing on arm64 with sw_tags mode passed when kasan=off is set. But > > when I tried to test sw_tags on arm64, the system bootup failed. It's > > not introduced by my patchset, the original code has the bug. I have > > reported it to upstream. > > - System is broken in KASAN sw_tags mode during bootup > > - https://lore.kernel.org/all/aSXKqJTkZPNskFop@MiWiFi-R3L-srv/T/#u > > This will hopefully be fixed soon, so you'll be able to test. Do you have the patch link of the fix on sw_tags breakage? I am organizing patches and testing them for reposting, but still see the sw_tags breakage during boot on arm64 system. If you have the pointer about the fix, I can grab the possible unmature code change to make sw_tags mode work to finish my testing. Thanks Baoquan
On 12/24/25 4:28 AM, Baoquan He wrote: > Hi Andrey, > > On 12/04/25 at 05:38pm, Andrey Konovalov wrote: >> On Fri, Nov 28, 2025 at 4:33 AM Baoquan He <bhe@redhat.com> wrote: >>> > ...snip... >>> Testing: >>> ======== >>> - Testing on x86_64 and arm64 for generic mode passed when kasan=on or >>> kasan=off. >>> >>> - Testing on arm64 with sw_tags mode passed when kasan=off is set. But >>> when I tried to test sw_tags on arm64, the system bootup failed. It's >>> not introduced by my patchset, the original code has the bug. I have >>> reported it to upstream. >>> - System is broken in KASAN sw_tags mode during bootup >>> - https://lore.kernel.org/all/aSXKqJTkZPNskFop@MiWiFi-R3L-srv/T/#u >> >> This will hopefully be fixed soon, so you'll be able to test. > > Do you have the patch link of the fix on sw_tags breakage? I think this one should fix it - https://lkml.kernel.org/r/cover.1765978969.git.m.wieczorretman@pm.me > > I am organizing patches and testing them for reposting, but still see > the sw_tags breakage during boot on arm64 system. If you have the > pointer about the fix, I can grab the possible unmature code change to > make sw_tags mode work to finish my testing. > > Thanks > Baoquan >
On 12/24/25 at 01:25pm, Andrey Ryabinin wrote: > > > On 12/24/25 4:28 AM, Baoquan He wrote: > > Hi Andrey, > > > > On 12/04/25 at 05:38pm, Andrey Konovalov wrote: > >> On Fri, Nov 28, 2025 at 4:33 AM Baoquan He <bhe@redhat.com> wrote: > >>> > > ...snip... > >>> Testing: > >>> ======== > >>> - Testing on x86_64 and arm64 for generic mode passed when kasan=on or > >>> kasan=off. > >>> > >>> - Testing on arm64 with sw_tags mode passed when kasan=off is set. But > >>> when I tried to test sw_tags on arm64, the system bootup failed. It's > >>> not introduced by my patchset, the original code has the bug. I have > >>> reported it to upstream. > >>> - System is broken in KASAN sw_tags mode during bootup > >>> - https://lore.kernel.org/all/aSXKqJTkZPNskFop@MiWiFi-R3L-srv/T/#u > >> > >> This will hopefully be fixed soon, so you'll be able to test. > > > > Do you have the patch link of the fix on sw_tags breakage? > > I think this one should fix it - https://lkml.kernel.org/r/cover.1765978969.git.m.wieczorretman@pm.me Awesome, let me apply them and test. Many thanks.
On 12/04/25 at 05:38pm, Andrey Konovalov wrote: > On Fri, Nov 28, 2025 at 4:33 AM Baoquan He <bhe@redhat.com> wrote: > > > > Currently only hw_tags mode of kasan can be enabled or disabled with > > kernel parameter kasan=on|off for built kernel. For kasan generic and > > sw_tags mode, there's no way to disable them once kernel is built. > > > > This is not convenient sometime, e.g in system kdump is configured. > > When the 1st kernel has KASAN enabled and crash triggered to switch to > > kdump kernel, the generic or sw_tags mode will cost much extra memory > > while in fact it's meaningless to have kasan in kdump kernel > > > > There are two parts of big amount of memory requiring for kasan enabed > > kernel. One is the direct memory mapping shadow of kasan, which is 1/8 > > of system RAM in generic mode and 1/16 of system RAM in sw_tags mode; > > the other is the shadow meomry for vmalloc which causes big meomry > > usage in kdump kernel because of lazy vmap freeing. By introducing > > "kasan=off|on", if we specify 'kasan=off', the former is avoided by skipping > > the kasan_init(), and the latter is avoided by not building the vmalloc > > shadow for vmalloc. > > > > So this patchset moves the kasan=on|off out of hw_tags scope and into > > common code to make it visible in generic and sw_tags mode too. Then we > > can add kasan=off in kdump kernel to reduce the unneeded meomry cost for > > kasan. > > > > Testing: > > ======== > > - Testing on x86_64 and arm64 for generic mode passed when kasan=on or > > kasan=off. > > > > - Testing on arm64 with sw_tags mode passed when kasan=off is set. But > > when I tried to test sw_tags on arm64, the system bootup failed. It's > > not introduced by my patchset, the original code has the bug. I have > > reported it to upstream. > > - System is broken in KASAN sw_tags mode during bootup > > - https://lore.kernel.org/all/aSXKqJTkZPNskFop@MiWiFi-R3L-srv/T/#u > > This will hopefully be fixed soon, so you'll be able to test. Great news, thanks for telling. And thanks a lot for careful reviewing. > > > > > - Haven't found hardware to test hw_tags. If anybody has the system, > > please help take a test. > > You don't need hardware to run the HW_TAGS mode, just pass -machine > virt,mte=on to QEMU. That's great, I will manage to test it in this way. > > I also wonder if we should keep this kasan=off functionality > conservative and limit it to x86 and arm64 (since these are the only > two tested architectures). We may not need to do that. I tested on arm64 because it has sw_tags and hw_tags. And if x86_64 and arm64 works well with kasan=off in generic mode, it should be fine on other architectures. I am a little more familiar with operations on x86/arm64 than others. I can manage to get power system to test kasan=off in generic mode, if that is required. From my side, I would like to see x86_64/arm64/s390/power to have kasan=off because RHEL support these architectures. I need consult people to make clear how to change in s390. Will post patch later or ask other people to help do that. While there seems to be no reason we don't let other arch-es have this benefit if the underlying code has paved the way, the arch side only needs two lines of judgement code. Personal opinion. > > > > Changelog: > > ==== > > v3->v4: > > - Rebase code to the latest linux-next/master to make the whole patchset > > set on top of > > [PATCH 0/2] kasan: cleanups for kasan_enabled() checks > > [PATCH v6 0/2] kasan: unify kasan_enabled() and remove arch-specific implementations > > Note that are also: > > [PATCH 1/2] kasan: remove __kasan_save_free_info wrapper > [PATCH 2/2] kasan: cleanup of kasan_enabled() checks Right, I saw these two patches, and have rebased code to sit on top of them. There are some conflicts, I have handled them manually. I only mentioned the cover-letter one to state the whole patchset. Sabyrzhan Tasbola [PATCH 0/2] kasan: cleanups for kasan_enabled() checks Sabyrzhan Tasbola ├─>[PATCH 2/2] kasan: cleanup of kasan_enabled() checks Sabyrzhan Tasbola └─>[PATCH 1/2] kasan: remove __kasan_save_free_info wrapper Thanks Baoquan > > But I don't know if there will be any conflicts with these. > > > > > v2->v3: > > - Fix a building error on UML ARCH when CONFIG_KASAN is not set. The > > change of fixing is appended into patch patch 11. This is reported > > by LKP, thanks to them. > > > > v1->v2: > > - Add __ro_after_init for kasan_arg_disabled, and remove redundant blank > > lines in mm/kasan/common.c. Thanks to Marco. > > - Fix a code bug in <linux/kasan-enabled.h> when CONFIG_KASAN is unset, > > this is found out by SeongJae and Lorenzo, and also reported by LKP > > report, thanks to them. > > - Add a missing kasan_enabled() checking in kasan_report(). This will > > cause below KASAN report info even though kasan=off is set: > > ================================================================== > > BUG: KASAN: stack-out-of-bounds in tick_program_event+0x130/0x150 > > Read of size 4 at addr ffff00005f747778 by task swapper/0/1 > > > > CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.16.0+ #8 PREEMPT(voluntary) > > Hardware name: GIGABYTE R272-P30-JG/MP32-AR0-JG, BIOS F31n (SCP: 2.10.20220810) 09/30/2022 > > Call trace: > > show_stack+0x30/0x90 (C) > > dump_stack_lvl+0x7c/0xa0 > > print_address_description.constprop.0+0x90/0x310 > > print_report+0x104/0x1f0 > > kasan_report+0xc8/0x110 > > __asan_report_load4_noabort+0x20/0x30 > > tick_program_event+0x130/0x150 > > ......snip... > > ================================================================== > > > > - Add jump_label_init() calling before kasan_init() in setup_arch() in these > > architectures: xtensa, arm. Because they currenly rely on > > jump_label_init() in main() which is a little late. Then the early static > > key kasan_flag_enabled in kasan_init() won't work. > > > > - In UML architecture, change to enable kasan_flag_enabled in arch_mm_preinit() > > because kasan_init() is enabled before main(), there's no chance to operate > > on static key in kasan_init(). > > > > Baoquan He (12): > > mm/kasan: add conditional checks in functions to return directly if > > kasan is disabled > > mm/kasan: move kasan= code to common place > > mm/kasan/sw_tags: don't initialize kasan if it's disabled > > arch/arm: don't initialize kasan if it's disabled > > arch/arm64: don't initialize kasan if it's disabled > > arch/loongarch: don't initialize kasan if it's disabled > > arch/powerpc: don't initialize kasan if it's disabled > > arch/riscv: don't initialize kasan if it's disabled > > arch/x86: don't initialize kasan if it's disabled > > arch/xtensa: don't initialize kasan if it's disabled > > arch/um: don't initialize kasan if it's disabled > > mm/kasan: make kasan=on|off take effect for all three modes > > > > arch/arm/kernel/setup.c | 6 ++++++ > > arch/arm/mm/kasan_init.c | 2 ++ > > arch/arm64/mm/kasan_init.c | 6 ++++++ > > arch/loongarch/mm/kasan_init.c | 2 ++ > > arch/powerpc/mm/kasan/init_32.c | 5 ++++- > > arch/powerpc/mm/kasan/init_book3e_64.c | 3 +++ > > arch/powerpc/mm/kasan/init_book3s_64.c | 3 +++ > > arch/riscv/mm/kasan_init.c | 3 +++ > > arch/um/kernel/mem.c | 5 ++++- > > arch/x86/mm/kasan_init_64.c | 3 +++ > > arch/xtensa/kernel/setup.c | 1 + > > arch/xtensa/mm/kasan_init.c | 3 +++ > > include/linux/kasan-enabled.h | 6 ++++-- > > mm/kasan/common.c | 20 ++++++++++++++++-- > > mm/kasan/generic.c | 17 ++++++++++++++-- > > mm/kasan/hw_tags.c | 28 ++------------------------ > > mm/kasan/init.c | 6 ++++++ > > mm/kasan/quarantine.c | 3 +++ > > mm/kasan/report.c | 4 +++- > > mm/kasan/shadow.c | 11 +++++++++- > > mm/kasan/sw_tags.c | 6 ++++++ > > 21 files changed, 107 insertions(+), 36 deletions(-) > > One part that's still missing is a Documentation change. > > > > > > -- > > 2.41.0 > > >
On Fri, Dec 5, 2025 at 8:14 AM Baoquan He <bhe@redhat.com> wrote: > > > I also wonder if we should keep this kasan=off functionality > > conservative and limit it to x86 and arm64 (since these are the only > > two tested architectures). > > We may not need to do that. I tested on arm64 because it has sw_tags and > hw_tags. And if x86_64 and arm64 works well with kasan=off in generic > mode, it should be fine on other architectures. I am a little more > familiar with operations on x86/arm64 than others. I can manage to get > power system to test kasan=off in generic mode, if that is required. > From my side, I would like to see x86_64/arm64/s390/power to have > kasan=off because RHEL support these architectures. I need consult people > to make clear how to change in s390. Will post patch later or ask other > people to help do that. > > While there seems to be no reason we don't let other arch-es have this > benefit if the underlying code has paved the way, the arch side only needs > two lines of judgement code. Personal opinion. OK, but it would be great if the arch maintainers could review and test the changes.
On Fri, Dec 05, 2025 at 03:14:43PM +0800, Baoquan He wrote: > On 12/04/25 at 05:38pm, Andrey Konovalov wrote: > > On Fri, Nov 28, 2025 at 4:33 AM Baoquan He <bhe@redhat.com> wrote: > > I also wonder if we should keep this kasan=off functionality > > conservative and limit it to x86 and arm64 (since these are the only > > two tested architectures). > > We may not need to do that. I tested on arm64 because it has sw_tags and > hw_tags. And if x86_64 and arm64 works well with kasan=off in generic > mode, it should be fine on other architectures. I am a little more > familiar with operations on x86/arm64 than others. I can manage to get > power system to test kasan=off in generic mode, if that is required. > From my side, I would like to see x86_64/arm64/s390/power to have > kasan=off because RHEL support these architectures. I need consult people > to make clear how to change in s390. Will post patch later or ask other > people to help do that. We are aware that s390 support is missing / does not work, and will provide something. I guess something based on this series would be good, or are you planning to send a new version anytime soon?
On 12/05/25 at 12:03pm, Heiko Carstens wrote: > On Fri, Dec 05, 2025 at 03:14:43PM +0800, Baoquan He wrote: > > On 12/04/25 at 05:38pm, Andrey Konovalov wrote: > > > On Fri, Nov 28, 2025 at 4:33 AM Baoquan He <bhe@redhat.com> wrote: > > > I also wonder if we should keep this kasan=off functionality > > > conservative and limit it to x86 and arm64 (since these are the only > > > two tested architectures). > > > > We may not need to do that. I tested on arm64 because it has sw_tags and > > hw_tags. And if x86_64 and arm64 works well with kasan=off in generic > > mode, it should be fine on other architectures. I am a little more > > familiar with operations on x86/arm64 than others. I can manage to get > > power system to test kasan=off in generic mode, if that is required. > > From my side, I would like to see x86_64/arm64/s390/power to have > > kasan=off because RHEL support these architectures. I need consult people > > to make clear how to change in s390. Will post patch later or ask other > > people to help do that. > > We are aware that s390 support is missing / does not work, and will > provide something. I guess something based on this series would be > good, or are you planning to send a new version anytime soon? I will send v5 soon to address Andrey's concerns. That would be great if you or any s390 expert can send patch based on v5. Thanks a lot.
© 2016 - 2026 Red Hat, Inc.