* Re: [PATCH v10 13/13] x86/kasan: Make software tag-based kasan available
From: Maciej Wieczor-Retman @ 2026-02-24 9:10 UTC (permalink / raw)
To: Dave Hansen
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Jonathan Corbet, Andrey Ryabinin,
Alexander Potapenko, Andrey Konovalov, Dmitry Vyukov,
Vincenzo Frascino, Andy Lutomirski, Peter Zijlstra, Andrew Morton,
Maciej Wieczor-Retman, linux-kernel, linux-doc, kasan-dev,
workflows
In-Reply-To: <f25c328f-4ce7-4494-a200-af4ba928e724@intel.com>
On 2026-02-23 at 12:52:03 -0800, Dave Hansen wrote:
>...
>> diff --git a/Documentation/arch/x86/x86_64/mm.rst b/Documentation/arch/x86/x86_64/mm.rst
>> index a6cf05d51bd8..7e2e4c5fa661 100644
>> --- a/Documentation/arch/x86/x86_64/mm.rst
>> +++ b/Documentation/arch/x86/x86_64/mm.rst
>> @@ -60,7 +60,8 @@ Complete virtual memory map with 4-level page tables
>> ffffe90000000000 | -23 TB | ffffe9ffffffffff | 1 TB | ... unused hole
>> ffffea0000000000 | -22 TB | ffffeaffffffffff | 1 TB | virtual memory map (vmemmap_base)
>> ffffeb0000000000 | -21 TB | ffffebffffffffff | 1 TB | ... unused hole
>> - ffffec0000000000 | -20 TB | fffffbffffffffff | 16 TB | KASAN shadow memory
>> + ffffec0000000000 | -20 TB | fffffbffffffffff | 16 TB | KASAN shadow memory (generic mode)
>> + fffff40000000000 | -8 TB | fffffbffffffffff | 8 TB | KASAN shadow memory (software tag-based mode)
>> __________________|____________|__________________|_________|____________________________________________________________
>> |
>> | Identical layout to the 56-bit one from here on:
>> @@ -130,7 +131,8 @@ Complete virtual memory map with 5-level page tables
>> ffd2000000000000 | -11.5 PB | ffd3ffffffffffff | 0.5 PB | ... unused hole
>> ffd4000000000000 | -11 PB | ffd5ffffffffffff | 0.5 PB | virtual memory map (vmemmap_base)
>> ffd6000000000000 | -10.5 PB | ffdeffffffffffff | 2.25 PB | ... unused hole
>> - ffdf000000000000 | -8.25 PB | fffffbffffffffff | ~8 PB | KASAN shadow memory
>> + ffdf000000000000 | -8.25 PB | fffffbffffffffff | ~8 PB | KASAN shadow memory (generic mode)
>> + ffeffc0000000000 | -6 PB | fffffbffffffffff | 4 PB | KASAN shadow memory (software tag-based mode)
>> __________________|____________|__________________|_________|____________________________________________________________
>
>I think the idea of these is that you can run through, find *one* range
>and know what a given address maps to. This adds overlapping ranges.
>Could you make it clear that part of the area is "generic mode" only and
>the other part is for generic mode and for "software tag-based mode"?
Boris suggested adding a footnote to clarify these are alternative ranges [1].
Perhaps I can add a star '*' next to these two so it can notify someone to look for
the footnote?
[1] https://lore.kernel.org/all/20260113161047.GNaWZuh21aoxqtTNXS@fat_crate.local/
>
>> @@ -176,5 +178,9 @@ Be very careful vs. KASLR when changing anything here. The KASLR address
>> range must not overlap with anything except the KASAN shadow area, which is
>> correct as KASAN disables KASLR.
>>
>> +The 'KASAN shadow memory (generic mode)/(software tag-based mode)' ranges are
>> +mutually exclusive and depend on which KASAN setting is chosen:
>> +CONFIG_KASAN_GENERIC or CONFIG_KASAN_SW_TAGS.
>> +
>> For both 4- and 5-level layouts, the KSTACK_ERASE_POISON value in the last 2MB
>> hole: ffffffffffff4111
>> diff --git a/Documentation/dev-tools/kasan.rst b/Documentation/dev-tools/kasan.rst
>> index 64dbf8b308bd..03b508ebe673 100644
>> --- a/Documentation/dev-tools/kasan.rst
>> +++ b/Documentation/dev-tools/kasan.rst
>> @@ -22,8 +22,8 @@ architectures, but it has significant performance and memory overheads.
>>
>> Software Tag-Based KASAN or SW_TAGS KASAN, enabled with CONFIG_KASAN_SW_TAGS,
>> can be used for both debugging and dogfood testing, similar to userspace HWASan.
>> -This mode is only supported for arm64, but its moderate memory overhead allows
>> -using it for testing on memory-restricted devices with real workloads.
>> +This mode is only supported for arm64 and x86, but its moderate memory overhead
>> +allows using it for testing on memory-restricted devices with real workloads.
>>
>> Hardware Tag-Based KASAN or HW_TAGS KASAN, enabled with CONFIG_KASAN_HW_TAGS,
>> is the mode intended to be used as an in-field memory bug detector or as a
>> @@ -351,10 +351,12 @@ Software Tag-Based KASAN
>> Software Tag-Based KASAN uses a software memory tagging approach to checking
>> access validity. It is currently only implemented for the arm64 architecture.
>>
>> -Software Tag-Based KASAN uses the Top Byte Ignore (TBI) feature of arm64 CPUs
>> -to store a pointer tag in the top byte of kernel pointers. It uses shadow memory
>> -to store memory tags associated with each 16-byte memory cell (therefore, it
>> -dedicates 1/16th of the kernel memory for shadow memory).
>> +Software Tag-Based KASAN uses the Top Byte Ignore (TBI) feature of arm64 CPUs to
>> +store a pointer tag in the top byte of kernel pointers. Analogously to TBI on
>> +x86 CPUs Linear Address Masking (LAM) feature is used and the pointer tag is
>> +stored in four bits of the kernel pointer's top byte. Software Tag-Based mode
>> +uses shadow memory to store memory tags associated with each 16-byte memory cell
>> +(therefore, it dedicates 1/16th of the kernel memory for shadow memory).
>
>This is going to get really cumbersome really fast if all the
>architectures doing this add their marketing terms in here.
>
> Software Tag-Based KASAN uses the hardware CPU features* to
> repurpose space inside kernel pointers to store pointer tags.
> ...
>
>and then _elsewhere_ you can describe the two implementations.
Okay, I'll rewrite that.
>
>> On each memory allocation, Software Tag-Based KASAN generates a random tag, tags
>> the allocated memory with this tag, and embeds the same tag into the returned
>> @@ -370,12 +372,14 @@ Software Tag-Based KASAN also has two instrumentation modes (outline, which
>> emits callbacks to check memory accesses; and inline, which performs the shadow
>> memory checks inline). With outline instrumentation mode, a bug report is
>> printed from the function that performs the access check. With inline
>> -instrumentation, a ``brk`` instruction is emitted by the compiler, and a
>> -dedicated ``brk`` handler is used to print bug reports.
>> -
>> -Software Tag-Based KASAN uses 0xFF as a match-all pointer tag (accesses through
>> -pointers with the 0xFF pointer tag are not checked). The value 0xFE is currently
>> -reserved to tag freed memory regions.
>> +instrumentation, arm64's implementation uses the ``brk`` instruction emitted by
>> +the compiler, and a dedicated ``brk`` handler is used to print bug reports. On
>> +x86 inline mode doesn't work yet due to missing compiler support.
>> +
>> +For arm64 Software Tag-Based KASAN uses 0xFF as a match-all pointer tag
>> +(accesses through pointers with the 0xFF pointer tag are not checked). The value
>> +0xFE is currently reserved to tag freed memory regions. On x86 the same tags
>> +take on 0xF and 0xE respectively.
>
>I think this would be more clear with a table or list of features and
>supported architectures.
That is a good idea, I'll work on that
>
>> Hardware Tag-Based KASAN
>> ~~~~~~~~~~~~~~~~~~~~~~~~
>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>> index 80527299f859..877668cd5deb 100644
>> --- a/arch/x86/Kconfig
>> +++ b/arch/x86/Kconfig
>> @@ -67,6 +67,7 @@ config X86
>> select ARCH_CLOCKSOURCE_INIT
>> select ARCH_CONFIGURES_CPU_MITIGATIONS
>> select ARCH_CORRECT_STACKTRACE_ON_KRETPROBE
>> + select ARCH_DISABLE_KASAN_INLINE if X86_64 && KASAN_SW_TAGS
>> select ARCH_ENABLE_HUGEPAGE_MIGRATION if X86_64 && HUGETLB_PAGE && MIGRATION
>> select ARCH_ENABLE_MEMORY_HOTPLUG if X86_64
>> select ARCH_ENABLE_MEMORY_HOTREMOVE if MEMORY_HOTPLUG
>> @@ -196,6 +197,8 @@ config X86
>> select HAVE_ARCH_JUMP_LABEL_RELATIVE
>> select HAVE_ARCH_KASAN if X86_64
>> select HAVE_ARCH_KASAN_VMALLOC if X86_64
>> + select HAVE_ARCH_KASAN_SW_TAGS if ADDRESS_MASKING && CC_IS_CLANG
>> + select ARCH_NEEDS_DEFER_KASAN if ADDRESS_MASKING
>> select HAVE_ARCH_KFENCE
>> select HAVE_ARCH_KMSAN if X86_64
>> select HAVE_ARCH_KGDB
>> @@ -410,6 +413,7 @@ config AUDIT_ARCH
>> config KASAN_SHADOW_OFFSET
>> hex
>> depends on KASAN
>> + default 0xeffffc0000000000 if KASAN_SW_TAGS
>> default 0xdffffc0000000000
>
>Please separate this from the documentation.
Okay, I'll split the documentation part into a separate patch.
>
>> config HAVE_INTEL_TXT
>> diff --git a/arch/x86/boot/compressed/misc.h b/arch/x86/boot/compressed/misc.h
>> index fd855e32c9b9..ba70036c2abd 100644
>> --- a/arch/x86/boot/compressed/misc.h
>> +++ b/arch/x86/boot/compressed/misc.h
>> @@ -13,6 +13,7 @@
>> #undef CONFIG_PARAVIRT_SPINLOCKS
>> #undef CONFIG_KASAN
>> #undef CONFIG_KASAN_GENERIC
>> +#undef CONFIG_KASAN_SW_TAGS
>>
>> #define __NO_FORTIFY
>>
>> diff --git a/arch/x86/include/asm/kasan.h b/arch/x86/include/asm/kasan.h
>> index 90c18e30848f..53ab7de16517 100644
>> --- a/arch/x86/include/asm/kasan.h
>> +++ b/arch/x86/include/asm/kasan.h
>> @@ -6,7 +6,12 @@
>> #include <linux/kasan-tags.h>
>> #include <linux/types.h>
>> #define KASAN_SHADOW_OFFSET _AC(CONFIG_KASAN_SHADOW_OFFSET, UL)
>> +
>> +#ifdef CONFIG_KASAN_SW_TAGS
>> +#define KASAN_SHADOW_SCALE_SHIFT 4
>> +#else
>> #define KASAN_SHADOW_SCALE_SHIFT 3
>> +#endif
>>
>> /*
>> * Compiler uses shadow offset assuming that addresses start
>> diff --git a/arch/x86/mm/kasan_init_64.c b/arch/x86/mm/kasan_init_64.c
>> index 7f5c11328ec1..8cbb8ec32061 100644
>> --- a/arch/x86/mm/kasan_init_64.c
>> +++ b/arch/x86/mm/kasan_init_64.c
>> @@ -465,4 +465,9 @@ void __init kasan_init(void)
>>
>> init_task.kasan_depth = 0;
>> kasan_init_generic();
>> +
>> + if (cpu_feature_enabled(X86_FEATURE_LAM))
>> + kasan_init_sw_tags();
>> + else
>> + pr_info("KernelAddressSanitizer not initialized (sw-tags): hardware doesn't support LAM\n");
>> }
>> diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan
>> index a4bb610a7a6f..d13ea8da7bfd 100644
>> --- a/lib/Kconfig.kasan
>> +++ b/lib/Kconfig.kasan
>> @@ -112,7 +112,8 @@ config KASAN_SW_TAGS
>>
>> Requires GCC 11+ or Clang.
>>
>> - Supported only on arm64 CPUs and relies on Top Byte Ignore.
>> + Supported on arm64 CPUs that support Top Byte Ignore and on x86 CPUs
>> + that support Linear Address Masking.
>
>Can this read more like:
>
> Supported on:
> arm64: CPUs with Top Byte Ignore
> x86: CPUs with Linear Address Masking.
>
>please?
Sure, I'll change it.
--
Kind regards
Maciej Wieczór-Retman
^ permalink raw reply
* Re: [PATCH] scripts: sort ver_linux and list in changes.rst
From: Hans Anda @ 2026-02-24 7:13 UTC (permalink / raw)
To: Jonathan Corbet, Collin Funk, Shuah Khan
Cc: workflows, linux-doc, linux-kernel
In-Reply-To: <87wm032kex.fsf@trenco.lwn.net>
On Mon, 2026-02-23 at 14:56 -0700, Jonathan Corbet wrote:
> Hans Anda <hansa@airmail.cc> writes:
>
> > It is a pain in the ass to compare the software versions on the running
> > system (scripts/ver_linux) with the minimal required versions (changes.rst).
> >
> > Sort both lists alphabetically
>
> So ... I suspect that the intent, in changes.rst anyway, was to list the
> compilers first and group other stuff roughly by category. But I agree
> it's kind of a mess; if it's really by category, they should be
> explicit.
Well, actually not. i considered categories but decided to sort alphabetically.
Because it is simpler and spared the decisions which tool fits in which category.
> If nobody screams, I am inclined to apply this change. But ...
>
> > Add missing tools in ver_linux
> > (bash, bc, bindgen, bindutils, btrfs, clang, e2fsck, awk, tar, gtags,
> > iptables, kmod, mcelog, mkimage, openssl, pahole, python, Rust, sphinx,
> > squashfs-tools, udev)
> > Fix minor issues (add grub2)
>
> ...these are a separate change and should be in their own patch.
>
i will make a Patch series with the files split.
Thanks for the feedback
Hans
^ permalink raw reply
* Re: [PATCH] scripts: sort ver_linux and list in changes.rst
From: Jonathan Corbet @ 2026-02-23 21:56 UTC (permalink / raw)
To: Hans Anda, Collin Funk, Shuah Khan
Cc: workflows, linux-doc, linux-kernel, Hans Anda
In-Reply-To: <20260221152113.28322-2-hansa@airmail.cc>
Hans Anda <hansa@airmail.cc> writes:
> It is a pain in the ass to compare the software versions on the running
> system (scripts/ver_linux) with the minimal required versions (changes.rst).
>
> Sort both lists alphabetically
So ... I suspect that the intent, in changes.rst anyway, was to list the
compilers first and group other stuff roughly by category. But I agree
it's kind of a mess; if it's really by category, they should be
explicit.
If nobody screams, I am inclined to apply this change. But ...
> Add missing tools in ver_linux
> (bash, bc, bindgen, bindutils, btrfs, clang, e2fsck, awk, tar, gtags,
> iptables, kmod, mcelog, mkimage, openssl, pahole, python, Rust, sphinx,
> squashfs-tools, udev)
> Fix minor issues (add grub2)
...these are a separate change and should be in their own patch.
Thanks,
jon
^ permalink raw reply
* Re: [PATCH] linux-next: update maintainer info.
From: Jonathan Corbet @ 2026-02-23 21:36 UTC (permalink / raw)
To: Randy Dunlap, linux-kernel
Cc: Randy Dunlap, Stephen Rothwell, Mark Brown, Shuah Khan, workflows,
linux-doc
In-Reply-To: <20260216060739.2791462-1-rdunlap@infradead.org>
Randy Dunlap <rdunlap@infradead.org> writes:
> Update the MAINTAINERS file and Documentation/process/2.Process.rst
> with the current linux-next maintainer information.
>
> Translations of 2.Process.rst should also be updated.
>
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> ---
> Cc: Stephen Rothwell <sfr@canb.auug.org.au>
> Cc: Mark Brown <broonie@kernel.org>
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: Shuah Khan <skhan@linuxfoundation.org>
> Cc: workflows@vger.kernel.org
> Cc: linux-doc@vger.kernel.org
>
> Documentation/process/2.Process.rst | 2 +-
> MAINTAINERS | 1 -
> 2 files changed, 1 insertion(+), 2 deletions(-)
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH v10 13/13] x86/kasan: Make software tag-based kasan available
From: Dave Hansen @ 2026-02-23 20:52 UTC (permalink / raw)
To: Maciej Wieczor-Retman, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
Jonathan Corbet, Andrey Ryabinin, Alexander Potapenko,
Andrey Konovalov, Dmitry Vyukov, Vincenzo Frascino,
Andy Lutomirski, Peter Zijlstra, Andrew Morton
Cc: Maciej Wieczor-Retman, linux-kernel, linux-doc, kasan-dev,
workflows
In-Reply-To: <8fd6275f980b90c62ddcb58cfbc78796c9fa7740.1770232424.git.m.wieczorretman@pm.me>
...
> diff --git a/Documentation/arch/x86/x86_64/mm.rst b/Documentation/arch/x86/x86_64/mm.rst
> index a6cf05d51bd8..7e2e4c5fa661 100644
> --- a/Documentation/arch/x86/x86_64/mm.rst
> +++ b/Documentation/arch/x86/x86_64/mm.rst
> @@ -60,7 +60,8 @@ Complete virtual memory map with 4-level page tables
> ffffe90000000000 | -23 TB | ffffe9ffffffffff | 1 TB | ... unused hole
> ffffea0000000000 | -22 TB | ffffeaffffffffff | 1 TB | virtual memory map (vmemmap_base)
> ffffeb0000000000 | -21 TB | ffffebffffffffff | 1 TB | ... unused hole
> - ffffec0000000000 | -20 TB | fffffbffffffffff | 16 TB | KASAN shadow memory
> + ffffec0000000000 | -20 TB | fffffbffffffffff | 16 TB | KASAN shadow memory (generic mode)
> + fffff40000000000 | -8 TB | fffffbffffffffff | 8 TB | KASAN shadow memory (software tag-based mode)
> __________________|____________|__________________|_________|____________________________________________________________
> |
> | Identical layout to the 56-bit one from here on:
> @@ -130,7 +131,8 @@ Complete virtual memory map with 5-level page tables
> ffd2000000000000 | -11.5 PB | ffd3ffffffffffff | 0.5 PB | ... unused hole
> ffd4000000000000 | -11 PB | ffd5ffffffffffff | 0.5 PB | virtual memory map (vmemmap_base)
> ffd6000000000000 | -10.5 PB | ffdeffffffffffff | 2.25 PB | ... unused hole
> - ffdf000000000000 | -8.25 PB | fffffbffffffffff | ~8 PB | KASAN shadow memory
> + ffdf000000000000 | -8.25 PB | fffffbffffffffff | ~8 PB | KASAN shadow memory (generic mode)
> + ffeffc0000000000 | -6 PB | fffffbffffffffff | 4 PB | KASAN shadow memory (software tag-based mode)
> __________________|____________|__________________|_________|____________________________________________________________
I think the idea of these is that you can run through, find *one* range
and know what a given address maps to. This adds overlapping ranges.
Could you make it clear that part of the area is "generic mode" only and
the other part is for generic mode and for "software tag-based mode"?
> @@ -176,5 +178,9 @@ Be very careful vs. KASLR when changing anything here. The KASLR address
> range must not overlap with anything except the KASAN shadow area, which is
> correct as KASAN disables KASLR.
>
> +The 'KASAN shadow memory (generic mode)/(software tag-based mode)' ranges are
> +mutually exclusive and depend on which KASAN setting is chosen:
> +CONFIG_KASAN_GENERIC or CONFIG_KASAN_SW_TAGS.
> +
> For both 4- and 5-level layouts, the KSTACK_ERASE_POISON value in the last 2MB
> hole: ffffffffffff4111
> diff --git a/Documentation/dev-tools/kasan.rst b/Documentation/dev-tools/kasan.rst
> index 64dbf8b308bd..03b508ebe673 100644
> --- a/Documentation/dev-tools/kasan.rst
> +++ b/Documentation/dev-tools/kasan.rst
> @@ -22,8 +22,8 @@ architectures, but it has significant performance and memory overheads.
>
> Software Tag-Based KASAN or SW_TAGS KASAN, enabled with CONFIG_KASAN_SW_TAGS,
> can be used for both debugging and dogfood testing, similar to userspace HWASan.
> -This mode is only supported for arm64, but its moderate memory overhead allows
> -using it for testing on memory-restricted devices with real workloads.
> +This mode is only supported for arm64 and x86, but its moderate memory overhead
> +allows using it for testing on memory-restricted devices with real workloads.
>
> Hardware Tag-Based KASAN or HW_TAGS KASAN, enabled with CONFIG_KASAN_HW_TAGS,
> is the mode intended to be used as an in-field memory bug detector or as a
> @@ -351,10 +351,12 @@ Software Tag-Based KASAN
> Software Tag-Based KASAN uses a software memory tagging approach to checking
> access validity. It is currently only implemented for the arm64 architecture.
>
> -Software Tag-Based KASAN uses the Top Byte Ignore (TBI) feature of arm64 CPUs
> -to store a pointer tag in the top byte of kernel pointers. It uses shadow memory
> -to store memory tags associated with each 16-byte memory cell (therefore, it
> -dedicates 1/16th of the kernel memory for shadow memory).
> +Software Tag-Based KASAN uses the Top Byte Ignore (TBI) feature of arm64 CPUs to
> +store a pointer tag in the top byte of kernel pointers. Analogously to TBI on
> +x86 CPUs Linear Address Masking (LAM) feature is used and the pointer tag is
> +stored in four bits of the kernel pointer's top byte. Software Tag-Based mode
> +uses shadow memory to store memory tags associated with each 16-byte memory cell
> +(therefore, it dedicates 1/16th of the kernel memory for shadow memory).
This is going to get really cumbersome really fast if all the
architectures doing this add their marketing terms in here.
Software Tag-Based KASAN uses the hardware CPU features* to
repurpose space inside kernel pointers to store pointer tags.
...
and then _elsewhere_ you can describe the two implementations.
> On each memory allocation, Software Tag-Based KASAN generates a random tag, tags
> the allocated memory with this tag, and embeds the same tag into the returned
> @@ -370,12 +372,14 @@ Software Tag-Based KASAN also has two instrumentation modes (outline, which
> emits callbacks to check memory accesses; and inline, which performs the shadow
> memory checks inline). With outline instrumentation mode, a bug report is
> printed from the function that performs the access check. With inline
> -instrumentation, a ``brk`` instruction is emitted by the compiler, and a
> -dedicated ``brk`` handler is used to print bug reports.
> -
> -Software Tag-Based KASAN uses 0xFF as a match-all pointer tag (accesses through
> -pointers with the 0xFF pointer tag are not checked). The value 0xFE is currently
> -reserved to tag freed memory regions.
> +instrumentation, arm64's implementation uses the ``brk`` instruction emitted by
> +the compiler, and a dedicated ``brk`` handler is used to print bug reports. On
> +x86 inline mode doesn't work yet due to missing compiler support.
> +
> +For arm64 Software Tag-Based KASAN uses 0xFF as a match-all pointer tag
> +(accesses through pointers with the 0xFF pointer tag are not checked). The value
> +0xFE is currently reserved to tag freed memory regions. On x86 the same tags
> +take on 0xF and 0xE respectively.
I think this would be more clear with a table or list of features and
supported architectures.
> Hardware Tag-Based KASAN
> ~~~~~~~~~~~~~~~~~~~~~~~~
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 80527299f859..877668cd5deb 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -67,6 +67,7 @@ config X86
> select ARCH_CLOCKSOURCE_INIT
> select ARCH_CONFIGURES_CPU_MITIGATIONS
> select ARCH_CORRECT_STACKTRACE_ON_KRETPROBE
> + select ARCH_DISABLE_KASAN_INLINE if X86_64 && KASAN_SW_TAGS
> select ARCH_ENABLE_HUGEPAGE_MIGRATION if X86_64 && HUGETLB_PAGE && MIGRATION
> select ARCH_ENABLE_MEMORY_HOTPLUG if X86_64
> select ARCH_ENABLE_MEMORY_HOTREMOVE if MEMORY_HOTPLUG
> @@ -196,6 +197,8 @@ config X86
> select HAVE_ARCH_JUMP_LABEL_RELATIVE
> select HAVE_ARCH_KASAN if X86_64
> select HAVE_ARCH_KASAN_VMALLOC if X86_64
> + select HAVE_ARCH_KASAN_SW_TAGS if ADDRESS_MASKING && CC_IS_CLANG
> + select ARCH_NEEDS_DEFER_KASAN if ADDRESS_MASKING
> select HAVE_ARCH_KFENCE
> select HAVE_ARCH_KMSAN if X86_64
> select HAVE_ARCH_KGDB
> @@ -410,6 +413,7 @@ config AUDIT_ARCH
> config KASAN_SHADOW_OFFSET
> hex
> depends on KASAN
> + default 0xeffffc0000000000 if KASAN_SW_TAGS
> default 0xdffffc0000000000
Please separate this from the documentation.
> config HAVE_INTEL_TXT
> diff --git a/arch/x86/boot/compressed/misc.h b/arch/x86/boot/compressed/misc.h
> index fd855e32c9b9..ba70036c2abd 100644
> --- a/arch/x86/boot/compressed/misc.h
> +++ b/arch/x86/boot/compressed/misc.h
> @@ -13,6 +13,7 @@
> #undef CONFIG_PARAVIRT_SPINLOCKS
> #undef CONFIG_KASAN
> #undef CONFIG_KASAN_GENERIC
> +#undef CONFIG_KASAN_SW_TAGS
>
> #define __NO_FORTIFY
>
> diff --git a/arch/x86/include/asm/kasan.h b/arch/x86/include/asm/kasan.h
> index 90c18e30848f..53ab7de16517 100644
> --- a/arch/x86/include/asm/kasan.h
> +++ b/arch/x86/include/asm/kasan.h
> @@ -6,7 +6,12 @@
> #include <linux/kasan-tags.h>
> #include <linux/types.h>
> #define KASAN_SHADOW_OFFSET _AC(CONFIG_KASAN_SHADOW_OFFSET, UL)
> +
> +#ifdef CONFIG_KASAN_SW_TAGS
> +#define KASAN_SHADOW_SCALE_SHIFT 4
> +#else
> #define KASAN_SHADOW_SCALE_SHIFT 3
> +#endif
>
> /*
> * Compiler uses shadow offset assuming that addresses start
> diff --git a/arch/x86/mm/kasan_init_64.c b/arch/x86/mm/kasan_init_64.c
> index 7f5c11328ec1..8cbb8ec32061 100644
> --- a/arch/x86/mm/kasan_init_64.c
> +++ b/arch/x86/mm/kasan_init_64.c
> @@ -465,4 +465,9 @@ void __init kasan_init(void)
>
> init_task.kasan_depth = 0;
> kasan_init_generic();
> +
> + if (cpu_feature_enabled(X86_FEATURE_LAM))
> + kasan_init_sw_tags();
> + else
> + pr_info("KernelAddressSanitizer not initialized (sw-tags): hardware doesn't support LAM\n");
> }
> diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan
> index a4bb610a7a6f..d13ea8da7bfd 100644
> --- a/lib/Kconfig.kasan
> +++ b/lib/Kconfig.kasan
> @@ -112,7 +112,8 @@ config KASAN_SW_TAGS
>
> Requires GCC 11+ or Clang.
>
> - Supported only on arm64 CPUs and relies on Top Byte Ignore.
> + Supported on arm64 CPUs that support Top Byte Ignore and on x86 CPUs
> + that support Linear Address Masking.
Can this read more like:
Supported on:
arm64: CPUs with Top Byte Ignore
x86: CPUs with Linear Address Masking.
please?
^ permalink raw reply
* [PATCH V2] Doc: dev-tools: Added Gentoo in the Operating system list under Getting Coccinelle
From: Bhaskar Chowdhury @ 2026-02-22 22:49 UTC (permalink / raw)
To: Julia.Lawall, nicolas.palix, corbet, skhan, cocci, workflows,
linux-doc, linux-kernel
Cc: Bhaskar Chowdhury
Adding Gentoo in the operating system list under "Getting Coccinelle".
This is the correct way:
Example:
bhaskar_04:20:50_Mon Feb 23: :~>sudo emerge -av dev-util/coccinelle
Password:
These are the packages that would be merged, in order:
Calculating dependencies... done!
Dependency resolution took 7.99 s (backtrack: 0/100).
[ebuild N ] dev-lang/ocaml-4.14.2:0/4.14.2::gentoo USE="-emacs -flambda
-latex ocamlopt -xemacs" 5377 KiB
[ebuild N ] dev-ml/dune-3.20.2:0/3.20.2::gentoo USE="-emacs" 2981 KiB
[ebuild N ] dev-ml/findlib-1.9.6-r1::gentoo USE="-doc ocamlopt -tk" 265
KiB
[ebuild N ] dev-ml/result-1.5:0/1.5::gentoo USE="ocamlopt" 3 KiB
[ebuild N ] dev-ml/sexplib0-0.16.0:0/0.16.0::gentoo USE="ocamlopt" 22
KiB
[ebuild N ] dev-ml/ocamlbuild-0.15.0:0/0.15.0::gentoo USE="ocamlopt"
198 KiB
[ebuild N ] dev-ml/menhir-20240715:0/20240715::gentoo USE="ocamlopt"
1217 KiB
[ebuild N ] dev-ml/num-1.5::gentoo USE="ocamlopt" 67 KiB
[ebuild N ] dev-ml/camlp4-4.14_p1-r2:0/4.14_p1::gentoo USE="ocamlopt"
627 KiB
[ebuild N ] dev-ml/csexp-1.5.2-r1:0/1.5.2::gentoo USE="ocamlopt -test"
12 KiB
[ebuild N ] dev-ml/uchar-0.0.2-r1:0/0.0.2::gentoo USE="ocamlopt" 22 KiB
[ebuild N ] dev-ml/dune-configurator-3.20.2:0/3.20.2::gentoo
USE="ocamlopt" 0 KiB
[ebuild N ~] dev-ml/stdcompat-21.1-r1:0/21.1::gentoo 611 KiB
[ebuild N ] dev-ml/base-0.16.3-r1:0/0.16::gentoo USE="ocamlopt" 433 KiB
[ebuild N ] dev-ml/parmap-1.2.5:0/1.2.5::gentoo USE="ocamlopt" 48 KiB
[ebuild N ] dev-ml/stdio-0.16.0:0/0.16::gentoo USE="ocamlopt" 8 KiB
[ebuild N ] dev-ml/parsexp-0.16.0:0/0.16::gentoo USE="ocamlopt" 56 KiB
[ebuild N ] dev-ml/sexplib-0.16.0-r1:0/0.16::gentoo USE="ocamlopt" 54
KiB
[ebuild N ] dev-ml/pcre-ocaml-7.5.0:0/7.5.0::gentoo USE="-examples
ocamlopt" 41 KiB
[ebuild N ~] dev-util/coccinelle-1.3.0::gentoo USE="-doc -emacs ocamlopt
pcre -python -test" PYTHON_SINGLE_TTotal: 20 packages (20 new), Size of
downloads: 14168 KiB
Would you like to merge these packages? [Yes/No]
Signed-off-by: Bhaskar Chowdhury <unixbhaskar@gmail.com>
---
Changes from V1: Package name mismatched, corrected
Documentation/dev-tools/coccinelle.rst | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/dev-tools/coccinelle.rst b/Documentation/dev-tools/coccinelle.rst
index 6e70a1e9a3c0..990a049091e1 100644
--- a/Documentation/dev-tools/coccinelle.rst
+++ b/Documentation/dev-tools/coccinelle.rst
@@ -29,6 +29,7 @@ of many distributions, e.g. :
- Ubuntu
- OpenSUSE
- Arch Linux
+ - Gentoo
- NetBSD
- FreeBSD
--
2.52.0
^ permalink raw reply related
* [PATCH] Doc:dev-tools Added Gentoo in Operating System list under Getting Coccinelle
From: Bhaskar Chowdhury @ 2026-02-22 22:28 UTC (permalink / raw)
To: Julia.Lawall, nicolas.palix, corbet, skhan, cocci, workflows,
linux-doc, linux-kernel
Cc: Bhaskar Chowdhury
Added Gentoo in the operating system list under "Getting Coccinelle".
It should be available the package like this : emerge -av dev-tools/coccinelle
Example:
bhaskar_04:11:00_Mon Feb 23: :~>sudo emerge -av dev-util/coccinelle
These are the packages that would be merged, in order:
Calculating dependencies... done!
Dependency resolution took 6.35 s (backtrack: 0/100).
[ebuild N ] dev-lang/ocaml-4.14.2:0/4.14.2::gentoo USE="-emacs -flambda
-latex ocamlopt -xemacs" 5377 KiB
[ebuild N ] dev-ml/dune-3.20.2:0/3.20.2::gentoo USE="-emacs" 2981 KiB
[ebuild N ] dev-ml/findlib-1.9.6-r1::gentoo USE="-doc ocamlopt -tk" 265
KiB
[ebuild N ] dev-ml/result-1.5:0/1.5::gentoo USE="ocamlopt" 3 KiB
[ebuild N ] dev-ml/sexplib0-0.16.0:0/0.16.0::gentoo USE="ocamlopt" 22
KiB
[ebuild N ] dev-ml/ocamlbuild-0.15.0:0/0.15.0::gentoo USE="ocamlopt" 198
KiB
[ebuild N ] dev-ml/menhir-20240715:0/20240715::gentoo USE="ocamlopt"
1217 KiB
[ebuild N ] dev-ml/num-1.5::gentoo USE="ocamlopt" 67 KiB
[ebuild N ] dev-ml/camlp4-4.14_p1-r2:0/4.14_p1::gentoo USE="ocamlopt"
627 KiB
[ebuild N ] dev-ml/csexp-1.5.2-r1:0/1.5.2::gentoo USE="ocamlopt -test"
12 KiB
[ebuild N ] dev-ml/uchar-0.0.2-r1:0/0.0.2::gentoo USE="ocamlopt" 22 KiB
[ebuild N ] dev-ml/dune-configurator-3.20.2:0/3.20.2::gentoo
USE="ocamlopt" 0 KiB
[ebuild N ~] dev-ml/stdcompat-21.1-r1:0/21.1::gentoo 611 KiB
[ebuild N ] dev-ml/base-0.16.3-r1:0/0.16::gentoo USE="ocamlopt" 433 KiB
[ebuild N ] dev-ml/parmap-1.2.5:0/1.2.5::gentoo USE="ocamlopt" 48 KiB
[ebuild N ] dev-ml/stdio-0.16.0:0/0.16::gentoo USE="ocamlopt" 8 KiB
[ebuild N ] dev-ml/parsexp-0.16.0:0/0.16::gentoo USE="ocamlopt" 56 KiB
[ebuild N ] dev-ml/sexplib-0.16.0-r1:0/0.16::gentoo USE="ocamlopt" 54
KiB
[ebuild N ] dev-ml/pcre-ocaml-7.5.0:0/7.5.0::gentoo USE="-examples
ocamlopt" 41 KiB
[ebuild N ~] dev-util/coccinelle-1.3.0::gentoo USE="-doc -emacs ocamlopt
pcre -python -test" PYTHON_SINGLE_TTotal: 20 packages (20 new), Size of
downloads: 14168 KiB
Would you like to merge these packages? [Yes/No]
Signed-off-by: Bhaskar Chowdhury <unixbhaskar@gmail.com>
---
Documentation/dev-tools/coccinelle.rst | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/dev-tools/coccinelle.rst b/Documentation/dev-tools/coccinelle.rst
index 6e70a1e9a3c0..990a049091e1 100644
--- a/Documentation/dev-tools/coccinelle.rst
+++ b/Documentation/dev-tools/coccinelle.rst
@@ -29,6 +29,7 @@ of many distributions, e.g. :
- Ubuntu
- OpenSUSE
- Arch Linux
+ - Gentoo
- NetBSD
- FreeBSD
--
2.52.0
^ permalink raw reply related
* Re: [cocci] [PATCH RESEND 0/3] scripts: coccicheck: document debug log handling
From: Julia Lawall @ 2026-02-21 16:40 UTC (permalink / raw)
To: Benjamin Philip
Cc: Julia Lawall, Nicolas Palix, Jonathan Corbet, cocci, workflows,
linux-doc, linux-kernel
In-Reply-To: <20260106190836.36630-1-benjamin.philip495@gmail.com>
On Wed, 7 Jan 2026, Benjamin Philip wrote:
> Currently coccicheck prints debug logs to stdout unless a debug file has been
> set. This makes it hard to read coccinelle's suggested changes, especially for
> someone new to coccicheck.
>
> This patchset documents this behaviour in both the coccicheck script as well as
> in the dev-tools documentation. Additionally, it simplifies some of the logic
> for handling debug files.
All applied, thanks.
julia
>
> Benjamin Philip (3):
> scripts: coccicheck: simplify debug file handling
> scripts: coccicheck: warn on unset debug file
> Documentation: Coccinelle: document debug log handling
>
> Documentation/dev-tools/coccinelle.rst | 21 ++++++++++++++++-----
> scripts/coccicheck | 21 +++++++++++++--------
> 2 files changed, 29 insertions(+), 13 deletions(-)
>
> --
> 2.52.0
>
>
^ permalink raw reply
* [PATCH] scripts: sort ver_linux and list in changes.rst
From: Hans Anda @ 2026-02-21 15:21 UTC (permalink / raw)
To: Jonathan Corbet, Collin Funk, Shuah Khan
Cc: workflows, linux-doc, linux-kernel, Hans Anda
It is a pain in the ass to compare the software versions on the running
system (scripts/ver_linux) with the minimal required versions (changes.rst).
Sort both lists alphabetically
Add missing tools in ver_linux
(bash, bc, bindgen, bindutils, btrfs, clang, e2fsck, awk, tar, gtags,
iptables, kmod, mcelog, mkimage, openssl, pahole, python, Rust, sphinx,
squashfs-tools, udev)
Fix minor issues (add grub2)
Signed-off-by: Hans Anda <hansa@airmail.cc>
---
Documentation/process/changes.rst | 50 +++++++++++++--------------
scripts/ver_linux | 56 +++++++++++++++++++++----------
2 files changed, 63 insertions(+), 43 deletions(-)
diff --git a/Documentation/process/changes.rst b/Documentation/process/changes.rst
index 6b373e193548..fb810c3710bb 100644
--- a/Documentation/process/changes.rst
+++ b/Documentation/process/changes.rst
@@ -29,40 +29,40 @@ you probably needn't concern yourself with pcmciautils.
====================== =============== ========================================
Program Minimal version Command to check the version
====================== =============== ========================================
-GNU C 8.1 gcc --version
-Clang/LLVM (optional) 15.0.0 clang --version
-Rust (optional) 1.78.0 rustc --version
-bindgen (optional) 0.65.1 bindgen --version
-GNU make 4.0 make --version
bash 4.2 bash --version
+bc 1.06.95 bc --version
+bindgen (optional) 0.65.1 bindgen --version
binutils 2.30 ld -v
-flex 2.5.35 flex --version
bison 2.0 bison --version
-pahole 1.22 pahole --version
-util-linux 2.10o mount --version
-kmod 13 depmod -V
+btrfs-progs 0.18 btrfs --version
+Clang/LLVM (optional) 15.0.0 clang --version
e2fsprogs 1.41.4 e2fsck -V
+flex 2.5.35 flex --version
+GNU AWK (optional) 5.1.0 gawk --version
+GNU C 8.1 gcc --version
+GNU make 4.0 make --version
+GNU tar 1.28 tar --version
+grub 0.93 grub --version || grub-install --version
+gtags (optional) 6.6.5 gtags --version
+iptables 1.4.2 iptables -V
jfsutils 1.1.3 fsck.jfs -V
-xfsprogs 2.6.0 xfs_db -V
-squashfs-tools 4.0 mksquashfs -version
-btrfs-progs 0.18 btrfs --version
+kmod 13 depmod -V
+mcelog 0.6 mcelog --version
+mkimage (optional) 2017.01 mkimage --version
+nfs-utils 1.0.5 showmount --version
+openssl & libcrypto 1.0.0 openssl version
+pahole 1.22 pahole --version
pcmciautils 004 pccardctl -V
-quota-tools 3.09 quota -V
PPP 2.4.0 pppd --version
-nfs-utils 1.0.5 showmount --version
procps 3.2.0 ps --version
-udev 081 udevd --version
-grub 0.93 grub --version || grub-install --version
-mcelog 0.6 mcelog --version
-iptables 1.4.2 iptables -V
-openssl & libcrypto 1.0.0 openssl version
-bc 1.06.95 bc --version
-Sphinx\ [#f1]_ 3.4.3 sphinx-build --version
-GNU tar 1.28 tar --version
-gtags (optional) 6.6.5 gtags --version
-mkimage (optional) 2017.01 mkimage --version
Python 3.9.x python3 --version
-GNU AWK (optional) 5.1.0 gawk --version
+quota-tools 3.09 quota -V
+Rust (optional) 1.78.0 rustc --version
+Sphinx\ [#f1]_ 3.4.3 sphinx-build --version
+squashfs-tools 4.0 mksquashfs -version
+udev 081 udevadm --version
+util-linux 2.10o mount --version
+xfsprogs 2.6.0 xfs_db -V
====================== =============== ========================================
.. [#f1] Sphinx is needed only to build the Kernel documentation
diff --git a/scripts/ver_linux b/scripts/ver_linux
index d6f2362d3792..6c829448b4d4 100755
--- a/scripts/ver_linux
+++ b/scripts/ver_linux
@@ -17,37 +17,57 @@ BEGIN {
libc = "libc[.]so[.][0-9]+$"
libcpp = "(libg|stdc)[+]+[.]so([.][0-9]+)+$"
- printversion("GNU C", version("gcc -dumpversion"))
- printversion("GNU Make", version("make --version"))
+ printversion("bash", version("bash --version"))
+ printversion("bc", version("bc --version"))
+ printversion("bindgen", version("bindgen --version"))
printversion("Binutils", version("ld -v"))
- printversion("Util-linux", version("mount --version"))
- printversion("Mount", version("mount --version"))
- printversion("Module-init-tools", version("depmod -V"))
- printversion("E2fsprogs", version("tune2fs"))
- printversion("Jfsutils", version("fsck.jfs -V"))
- printversion("Xfsprogs", version("xfs_db -V"))
- printversion("Pcmciautils", version("pccardctl -V"))
- printversion("Pcmcia-cs", version("cardmgr -V"))
- printversion("Quota-tools", version("quota -V"))
- printversion("PPP", version("pppd --version"))
- printversion("Isdn4k-utils", version("isdnctrl"))
- printversion("Nfs-utils", version("showmount --version"))
printversion("Bison", version("bison --version"))
+ printversion("btrfs-progs", version("btrfs --version"))
+ printversion("Clang", version("clang --version"))
+ printversion("Console-tools", version("loadkeys -V"))
+ printversion("Dynamic linker (ldd)", version("ldd --version"))
+ printversion("E2fsprogs", version("e2fsck -V"))
printversion("Flex", version("flex --version"))
+ printversion("GNU AWK", version("gawk -version"))
+ printversion("GNU C", version("gcc -dumpversion"))
+ printversion("GNU make", version("make --version"))
+ printversion("GNU tar", version("tar --version"))
+ printversion("GRUB", version("grub-install --version"))
+ printversion("GRUB2", version("grub2-install --version"))
+ printversion("gtags", version("gtags --version"))
+ printversion("iptables", version("iptables -V"))
+ printversion("Isdn4k-utils", version("isdnctrl"))
+ printversion("Jfsutils", version("fsck.jfs -V"))
+ printversion("Kbd", version("loadkeys -V"))
+ printversion("kmod", version("kmod -V"))
while ("ldconfig -p 2>/dev/null" | getline > 0)
if ($NF ~ libc || $NF ~ libcpp)
if (!seen[ver = version("readlink " $NF)]++)
printversion("Linux C" ($NF ~ libcpp? "++" : "") " Library", ver)
- printversion("Dynamic linker (ldd)", version("ldd --version"))
- printversion("Procps", version("ps --version"))
+ printversion("mcelog", version("mcelog --version"))
+ printversion("mkimage", version("mkimage --version"))
+ printversion("Module-init-tools", version("depmod -V"))
+ printversion("Mount", version("mount --version"))
printversion("Net-tools", version("ifconfig --version"))
- printversion("Kbd", version("loadkeys -V"))
- printversion("Console-tools", version("loadkeys -V"))
+ printversion("Nfs-utils", version("showmount --version"))
+ printversion("openssl", version("openssl version"))
+ printversion("pahole", version("pahole --version"))
+ printversion("Pcmcia-cs", version("cardmgr -V"))
+ printversion("Pcmciautils", version("pccardctl -V"))
+ printversion("PPP", version("pppd --version"))
+ printversion("Procps", version("ps --version"))
+ printversion("Python", version("python3 -V"))
+ printversion("Quota-tools", version("quota -V"))
+ printversion("Rust", version("rustc --version"))
printversion("Sh-utils", version("expr --v"))
+ printversion("Sphinx", version("sphinx-build --version"))
+ printversion("squashfs-tools", version("mksquashfs -version"))
printversion("Udev", version("udevadm --version"))
+ printversion("Util-linux", version("mount --version"))
printversion("Wireless-tools", version("iwconfig --version"))
+ printversion("Xfsprogs", version("xfs_db -V"))
while ("sort /proc/modules" | getline > 0) {
mods = mods sep $1
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] linux-next: update maintainer info.
From: Shuah Khan @ 2026-02-20 17:14 UTC (permalink / raw)
To: Stephen Rothwell, Randy Dunlap
Cc: linux-kernel, Mark Brown, Jonathan Corbet, workflows, linux-doc,
Shuah Khan
In-Reply-To: <20260216091648.7a6a0e3a@canb.auug.org.au>
On 2/16/26 02:16, Stephen Rothwell wrote:
> Hi Randy,
>
> On Sun, 15 Feb 2026 22:07:39 -0800 Randy Dunlap <rdunlap@infradead.org> wrote:
>>
>> Update the MAINTAINERS file and Documentation/process/2.Process.rst
>> with the current linux-next maintainer information.
>>
>> Translations of 2.Process.rst should also be updated.
>>
>> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
>> ---
>> Cc: Stephen Rothwell <sfr@canb.auug.org.au>
>> Cc: Mark Brown <broonie@kernel.org>
>> Cc: Jonathan Corbet <corbet@lwn.net>
>> Cc: Shuah Khan <skhan@linuxfoundation.org>
>> Cc: workflows@vger.kernel.org
>> Cc: linux-doc@vger.kernel.org
>>
>> Documentation/process/2.Process.rst | 2 +-
>> MAINTAINERS | 1 -
>> 2 files changed, 1 insertion(+), 2 deletions(-)
>>
>> --- linux-next-20260213.orig/Documentation/process/2.Process.rst
>> +++ linux-next-20260213/Documentation/process/2.Process.rst
>> @@ -291,7 +291,7 @@ Use of the MMOTM tree is likely to be a
>> there is a definite chance that it will not even compile.
>>
>> The primary tree for next-cycle patch merging is linux-next, maintained by
>> -Stephen Rothwell. The linux-next tree is, by design, a snapshot of what
>> +Mark Brown. The linux-next tree is, by design, a snapshot of what
>> the mainline is expected to look like after the next merge window closes.
>> Linux-next trees are announced on the linux-kernel and linux-next mailing
>> lists when they are assembled; they can be downloaded from:
>> --- linux-next-20260213.orig/MAINTAINERS
>> +++ linux-next-20260213/MAINTAINERS
>> @@ -14749,7 +14749,6 @@ F: Documentation/memory-barriers.txt
>> F: tools/memory-model/
>>
>> LINUX-NEXT TREE
>> -M: Stephen Rothwell <sfr@canb.auug.org.au>
>> M: Mark Brown <broonie@kernel.org>
>> L: linux-next@vger.kernel.org
>> S: Supported
>
> Acked-by: Stephen Rothwell <sfr@canb.auug.org.au>
>
> Maybe update the CREDITS file? ;-)
Thank you Stephen for shepherding linux-next all these years and
keeping us all sane. You will be missed. Good luck with your next
adventure.
thanks,
-- Shuah
^ permalink raw reply
* Re: [PATCH] linux-next: update maintainer info.
From: Mark Brown @ 2026-02-16 15:37 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Randy Dunlap, linux-kernel, Jonathan Corbet, Shuah Khan,
workflows, linux-doc
In-Reply-To: <20260216091648.7a6a0e3a@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 479 bytes --]
On Mon, Feb 16, 2026 at 08:16:48PM +1100, Stephen Rothwell wrote:
> On Sun, 15 Feb 2026 22:07:39 -0800 Randy Dunlap <rdunlap@infradead.org> wrote:
> > LINUX-NEXT TREE
> > -M: Stephen Rothwell <sfr@canb.auug.org.au>
> > M: Mark Brown <broonie@kernel.org>
> > L: linux-next@vger.kernel.org
> > S: Supported
> Acked-by: Stephen Rothwell <sfr@canb.auug.org.au>
You've escaped! :P
Acked-by: Mark Brown <broonie@kernel.org>
> Maybe update the CREDITS file? ;-)
Good idea..
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] linux-next: update maintainer info.
From: Stephen Rothwell @ 2026-02-16 9:16 UTC (permalink / raw)
To: Randy Dunlap
Cc: linux-kernel, Mark Brown, Jonathan Corbet, Shuah Khan, workflows,
linux-doc
In-Reply-To: <20260216060739.2791462-1-rdunlap@infradead.org>
[-- Attachment #1: Type: text/plain, Size: 1914 bytes --]
Hi Randy,
On Sun, 15 Feb 2026 22:07:39 -0800 Randy Dunlap <rdunlap@infradead.org> wrote:
>
> Update the MAINTAINERS file and Documentation/process/2.Process.rst
> with the current linux-next maintainer information.
>
> Translations of 2.Process.rst should also be updated.
>
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> ---
> Cc: Stephen Rothwell <sfr@canb.auug.org.au>
> Cc: Mark Brown <broonie@kernel.org>
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: Shuah Khan <skhan@linuxfoundation.org>
> Cc: workflows@vger.kernel.org
> Cc: linux-doc@vger.kernel.org
>
> Documentation/process/2.Process.rst | 2 +-
> MAINTAINERS | 1 -
> 2 files changed, 1 insertion(+), 2 deletions(-)
>
> --- linux-next-20260213.orig/Documentation/process/2.Process.rst
> +++ linux-next-20260213/Documentation/process/2.Process.rst
> @@ -291,7 +291,7 @@ Use of the MMOTM tree is likely to be a
> there is a definite chance that it will not even compile.
>
> The primary tree for next-cycle patch merging is linux-next, maintained by
> -Stephen Rothwell. The linux-next tree is, by design, a snapshot of what
> +Mark Brown. The linux-next tree is, by design, a snapshot of what
> the mainline is expected to look like after the next merge window closes.
> Linux-next trees are announced on the linux-kernel and linux-next mailing
> lists when they are assembled; they can be downloaded from:
> --- linux-next-20260213.orig/MAINTAINERS
> +++ linux-next-20260213/MAINTAINERS
> @@ -14749,7 +14749,6 @@ F: Documentation/memory-barriers.txt
> F: tools/memory-model/
>
> LINUX-NEXT TREE
> -M: Stephen Rothwell <sfr@canb.auug.org.au>
> M: Mark Brown <broonie@kernel.org>
> L: linux-next@vger.kernel.org
> S: Supported
Acked-by: Stephen Rothwell <sfr@canb.auug.org.au>
Maybe update the CREDITS file? ;-)
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH] linux-next: update maintainer info.
From: Randy Dunlap @ 2026-02-16 6:07 UTC (permalink / raw)
To: linux-kernel
Cc: Randy Dunlap, Stephen Rothwell, Mark Brown, Jonathan Corbet,
Shuah Khan, workflows, linux-doc
Update the MAINTAINERS file and Documentation/process/2.Process.rst
with the current linux-next maintainer information.
Translations of 2.Process.rst should also be updated.
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
---
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Mark Brown <broonie@kernel.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Shuah Khan <skhan@linuxfoundation.org>
Cc: workflows@vger.kernel.org
Cc: linux-doc@vger.kernel.org
Documentation/process/2.Process.rst | 2 +-
MAINTAINERS | 1 -
2 files changed, 1 insertion(+), 2 deletions(-)
--- linux-next-20260213.orig/Documentation/process/2.Process.rst
+++ linux-next-20260213/Documentation/process/2.Process.rst
@@ -291,7 +291,7 @@ Use of the MMOTM tree is likely to be a
there is a definite chance that it will not even compile.
The primary tree for next-cycle patch merging is linux-next, maintained by
-Stephen Rothwell. The linux-next tree is, by design, a snapshot of what
+Mark Brown. The linux-next tree is, by design, a snapshot of what
the mainline is expected to look like after the next merge window closes.
Linux-next trees are announced on the linux-kernel and linux-next mailing
lists when they are assembled; they can be downloaded from:
--- linux-next-20260213.orig/MAINTAINERS
+++ linux-next-20260213/MAINTAINERS
@@ -14749,7 +14749,6 @@ F: Documentation/memory-barriers.txt
F: tools/memory-model/
LINUX-NEXT TREE
-M: Stephen Rothwell <sfr@canb.auug.org.au>
M: Mark Brown <broonie@kernel.org>
L: linux-next@vger.kernel.org
S: Supported
^ permalink raw reply
* Re: [PATCH v3] docs: process: maintainer-pgp-guide: update kernel.org docs link
From: Jonathan Corbet @ 2026-02-09 19:51 UTC (permalink / raw)
To: Amitabh Srivastava; +Cc: workflows, linux-doc, linux-kernel, Amitabh Srivastava
In-Reply-To: <20260205115554.7795-1-amitabh@amidevlab.com>
Amitabh Srivastava <amitabh@amidevlab.com> writes:
> Update http link to the documentation about how to add a kernel.org UID to
> the maintainer's key. Add missing SPDX-License-Identifier to fix a
> checkpatch warning.
>
> Signed-off-by: Amitabh Srivastava <amitabh@amidevlab.com>
> ---
> Documentation/process/maintainer-pgp-guide.rst | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/process/maintainer-pgp-guide.rst b/Documentation/process/maintainer-pgp-guide.rst
> index b6919bf606c3..1e4d885dc784 100644
> --- a/Documentation/process/maintainer-pgp-guide.rst
> +++ b/Documentation/process/maintainer-pgp-guide.rst
> @@ -1,3 +1,5 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> .. _pgpguide:
>
> ===========================
> @@ -864,7 +866,7 @@ don't already have them)::
> If you have a kernel.org account, then you should `add the kernel.org
> UID to your key`_ to make WKD more useful to other kernel developers.
>
> -.. _`add the kernel.org UID to your key`: https://korg.wiki.kernel.org/userdoc/mail#adding_a_kernelorg_uid_to_your_pgp_key
> +.. _`add the kernel.org UID to your key`: https://korg.docs.kernel.org/mail.html#adding-a-kernel-org-uid-to-your-pgp-key
>
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH v3] docs: process: maintainer-pgp-guide: update kernel.org docs link
From: Amitabh @ 2026-02-06 20:43 UTC (permalink / raw)
To: Jonathan Corbet; +Cc: Konstantin Ryabitsev, workflows, linux-doc, linux-kernel
In-Reply-To: <87fr7deu3o.fsf@trenco.lwn.net>
Hi Jon,
Hope my patch gets accepted for commit.
> On 6 Feb 2026, at 9:34 PM, Jonathan Corbet <corbet@lwn.net> wrote:
>
> "Konstantin Ryabitsev" <mricon@kernel.org> writes:
>
>> On Thu, Feb 5, 2026, at 06:55, Amitabh Srivastava wrote:
>>> Update http link to the documentation about how to add a kernel.org UID to
>>> the maintainer's key. Add missing SPDX-License-Identifier to fix a
>>> checkpatch warning.
>>
>> No objections from me, but please check with other reviewers if they want another revision.
>>
>> Reviewed-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
>
> I think we've probably done enough rounds on this one :)
>
> Thanks,
>
> Jon
Regards
Amitabh
^ permalink raw reply
* Re: [PATCH v3] docs: process: maintainer-pgp-guide: update kernel.org docs link
From: Jonathan Corbet @ 2026-02-06 16:04 UTC (permalink / raw)
To: Konstantin Ryabitsev, Amitabh Srivastava
Cc: workflows, linux-doc, linux-kernel
In-Reply-To: <95e18b9f-1426-44cd-a5f1-fca5bd122450@app.fastmail.com>
"Konstantin Ryabitsev" <mricon@kernel.org> writes:
> On Thu, Feb 5, 2026, at 06:55, Amitabh Srivastava wrote:
>> Update http link to the documentation about how to add a kernel.org UID to
>> the maintainer's key. Add missing SPDX-License-Identifier to fix a
>> checkpatch warning.
>
> No objections from me, but please check with other reviewers if they want another revision.
>
> Reviewed-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
I think we've probably done enough rounds on this one :)
Thanks,
jon
^ permalink raw reply
* Re: [PATCH v3] docs: process: maintainer-pgp-guide: update kernel.org docs link
From: Konstantin Ryabitsev @ 2026-02-06 14:38 UTC (permalink / raw)
To: Amitabh Srivastava, corbet; +Cc: workflows, linux-doc, linux-kernel
In-Reply-To: <20260205115554.7795-1-amitabh@amidevlab.com>
On Thu, Feb 5, 2026, at 06:55, Amitabh Srivastava wrote:
> Update http link to the documentation about how to add a kernel.org UID to
> the maintainer's key. Add missing SPDX-License-Identifier to fix a
> checkpatch warning.
No objections from me, but please check with other reviewers if they want another revision.
Reviewed-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
-K
^ permalink raw reply
* Re: [PATCH v3] docs: process: maintainer-pgp-guide: update kernel.org docs link
From: Konstantin Ryabitsev @ 2026-02-06 14:20 UTC (permalink / raw)
To: Amitabh; +Cc: Jonathan Corbet, workflows, linux-doc, linux-kernel
In-Reply-To: <3AB51D59-A054-4847-91CD-DFF3A2EB5F04@amidevlab.com>
On Fri, Feb 06, 2026 at 12:02:00AM +0530, Amitabh wrote:
> > I am aware of kernel documentation practices :) "Typically licensed"
> > does not tell you what any individual contributor intended, though.
> > *Probably* that tag is OK, but you should really consult with the
> > original author of that page to ask what their intent was.
>
> You are absolutely correct. In fact, the original author, Konstantin Ryabitsev,
> (in TO here) responded to my v1 patch in the affirmative regarding the changes.
> (https://lore.kernel.org/all/177006480695.901069.1641199463436529014@lemur/)
Yes, that matches the intended license.
-K
^ permalink raw reply
* Re: [PATCH v3] docs: process: maintainer-pgp-guide: update kernel.org docs link
From: Jonathan Corbet @ 2026-02-05 15:30 UTC (permalink / raw)
To: Amitabh; +Cc: workflows, linux-doc, linux-kernel
In-Reply-To: <E285CDA1-776F-44AF-9C6D-AB43F4EC5054@amidevlab.com>
Amitabh <amitabh@amidevlab.com> writes:
> Hi Jon,
>
>> On 5 Feb 2026, at 8:19 PM, Jonathan Corbet <corbet@lwn.net> wrote:
>>
>> Amitabh Srivastava <amitabh@amidevlab.com> writes:
>>
>>> Update http link to the documentation about how to add a kernel.org UID to
>>> the maintainer's key. Add missing SPDX-License-Identifier to fix a
>>> checkpatch warning.
>>>
>>> Signed-off-by: Amitabh Srivastava <amitabh@amidevlab.com>
>>> ---
>>> Documentation/process/maintainer-pgp-guide.rst | 4 +++-
>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/Documentation/process/maintainer-pgp-guide.rst b/Documentation/process/maintainer-pgp-guide.rst
>>> index b6919bf606c3..1e4d885dc784 100644
>>> --- a/Documentation/process/maintainer-pgp-guide.rst
>>> +++ b/Documentation/process/maintainer-pgp-guide.rst
>>> @@ -1,3 +1,5 @@
>>> +.. SPDX-License-Identifier: GPL-2.0
>>> +
>>
>> Do you know that was the intended license for this file? We need to be
>> careful about putting license declarations on other people's work.
>>
> Yes, The Linux kernel documentation is typically licensed under GPL-2.0.
I am aware of kernel documentation practices :) "Typically licensed"
does not tell you what any individual contributor intended, though.
*Probably* that tag is OK, but you should really consult with the
original author of that page to ask what their intent was.
> Other files in the directory contain the same 'SPDX-License-Identifier' as well.
> However, I have added this just to satisfy checkpatch.pl requirement, which
> checks for missing license information in documentation files. Let me know if
> you think otherwise.
Checkpatch makes suggestions, not requirements. All files in the kernel
should have SPDX lines, but they need to be the correct ones, not just
somebody's guess.
Thanks,
jon
^ permalink raw reply
* Re: [PATCH v3] docs: process: maintainer-pgp-guide: update kernel.org docs link
From: Amitabh @ 2026-02-05 15:15 UTC (permalink / raw)
To: Jonathan Corbet; +Cc: workflows, linux-doc, linux-kernel
In-Reply-To: <875x8bi6su.fsf@trenco.lwn.net>
Hi Jon,
> On 5 Feb 2026, at 8:19 PM, Jonathan Corbet <corbet@lwn.net> wrote:
>
> Amitabh Srivastava <amitabh@amidevlab.com> writes:
>
>> Update http link to the documentation about how to add a kernel.org UID to
>> the maintainer's key. Add missing SPDX-License-Identifier to fix a
>> checkpatch warning.
>>
>> Signed-off-by: Amitabh Srivastava <amitabh@amidevlab.com>
>> ---
>> Documentation/process/maintainer-pgp-guide.rst | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/process/maintainer-pgp-guide.rst b/Documentation/process/maintainer-pgp-guide.rst
>> index b6919bf606c3..1e4d885dc784 100644
>> --- a/Documentation/process/maintainer-pgp-guide.rst
>> +++ b/Documentation/process/maintainer-pgp-guide.rst
>> @@ -1,3 +1,5 @@
>> +.. SPDX-License-Identifier: GPL-2.0
>> +
>
> Do you know that was the intended license for this file? We need to be
> careful about putting license declarations on other people's work.
>
Yes, The Linux kernel documentation is typically licensed under GPL-2.0.
Other files in the directory contain the same 'SPDX-License-Identifier' as well.
However, I have added this just to satisfy checkpatch.pl requirement, which
checks for missing license information in documentation files. Let me know if
you think otherwise.
> Thanks,
>
> jon
^ permalink raw reply
* Re: [PATCH v3] docs: process: maintainer-pgp-guide: update kernel.org docs link
From: Jonathan Corbet @ 2026-02-05 14:49 UTC (permalink / raw)
To: Amitabh Srivastava; +Cc: workflows, linux-doc, linux-kernel, Amitabh Srivastava
In-Reply-To: <20260205115554.7795-1-amitabh@amidevlab.com>
Amitabh Srivastava <amitabh@amidevlab.com> writes:
> Update http link to the documentation about how to add a kernel.org UID to
> the maintainer's key. Add missing SPDX-License-Identifier to fix a
> checkpatch warning.
>
> Signed-off-by: Amitabh Srivastava <amitabh@amidevlab.com>
> ---
> Documentation/process/maintainer-pgp-guide.rst | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/process/maintainer-pgp-guide.rst b/Documentation/process/maintainer-pgp-guide.rst
> index b6919bf606c3..1e4d885dc784 100644
> --- a/Documentation/process/maintainer-pgp-guide.rst
> +++ b/Documentation/process/maintainer-pgp-guide.rst
> @@ -1,3 +1,5 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
Do you know that was the intended license for this file? We need to be
careful about putting license declarations on other people's work.
Thanks,
jon
^ permalink raw reply
* Re: [PATCH v3] docs: process: maintainer-pgp-guide: update kernel.org docs link
From: Amitabh @ 2026-02-05 14:14 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: corbet, workflows, linux-doc, linux-kernel
In-Reply-To: <CAMuHMdVdBoXKg-7wDshMRGi05LiCOi62ETYzyV5HFbQXLinK6A@mail.gmail.com>
Hi Geert,
Hope this clarifies.
> On 5 Feb 2026, at 6:53 PM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Amitabh,
>
> Thanks for your patch!
>
> On Thu, 5 Feb 2026 at 13:09, Amitabh Srivastava <amitabh@amidevlab.com> wrote:
>> Update http link to the documentation about how to add a kernel.org UID to
>> the maintainer's key. Add missing SPDX-License-Identifier to fix a
>> checkpatch warning.
>
> > The first sentence states the obvious, but does not explain the
> > rationale behind this change. Why should it be changed? Both the
> > old and the new URL work.
> The old URL no longer points to the correct page having mentioned information.
> [Old URL]: Simply redirects to 'https://korg.docs.kernel.org/', which doesn't have any information on how to add the kernel.org UID to your PGP key.
> [New URL]: Precisely opens the respective page at the anchor for the respective section 'Adding a kernel.org UID to your PGP key'.
>> Signed-off-by: Amitabh Srivastava <amitabh@amidevlab.com>
>
>> --- a/Documentation/process/maintainer-pgp-guide.rst
>> +++ b/Documentation/process/maintainer-pgp-guide.rst
>> @@ -1,3 +1,5 @@
>> +.. SPDX-License-Identifier: GPL-2.0
>> +
>> .. _pgpguide:
>>
>> ===========================
>> @@ -864,7 +866,7 @@ don't already have them)::
>> If you have a kernel.org account, then you should `add the kernel.org
>> UID to your key`_ to make WKD more useful to other kernel developers.
>>
>> -.. _`add the kernel.org UID to your key`: https://korg.wiki.kernel.org/userdoc/mail#adding_a_kernelorg_uid_to_your_pgp_key
>> +.. _`add the kernel.org UID to your key`: https://korg.docs.kernel.org/mail.html#adding-a-kernel-org-uid-to-your-pgp-key
>>
>> Web of Trust (WOT) vs. Trust on First Use (TOFU)
>> ------------------------------------------------
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus TorvaldsThanks
> Regards
> Amitabh
^ permalink raw reply
* Re: [PATCH v3] docs: process: maintainer-pgp-guide: update kernel.org docs link
From: Geert Uytterhoeven @ 2026-02-05 13:23 UTC (permalink / raw)
To: Amitabh Srivastava; +Cc: corbet, workflows, linux-doc, linux-kernel
In-Reply-To: <20260205115554.7795-1-amitabh@amidevlab.com>
Hi Amitabh,
Thanks for your patch!
On Thu, 5 Feb 2026 at 13:09, Amitabh Srivastava <amitabh@amidevlab.com> wrote:
> Update http link to the documentation about how to add a kernel.org UID to
> the maintainer's key. Add missing SPDX-License-Identifier to fix a
> checkpatch warning.
The first sentence states the obvious, but does not explain the
rationale behind this change. Why should it be changed? Both the
old and the new URL work.
> Signed-off-by: Amitabh Srivastava <amitabh@amidevlab.com>
> --- a/Documentation/process/maintainer-pgp-guide.rst
> +++ b/Documentation/process/maintainer-pgp-guide.rst
> @@ -1,3 +1,5 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> .. _pgpguide:
>
> ===========================
> @@ -864,7 +866,7 @@ don't already have them)::
> If you have a kernel.org account, then you should `add the kernel.org
> UID to your key`_ to make WKD more useful to other kernel developers.
>
> -.. _`add the kernel.org UID to your key`: https://korg.wiki.kernel.org/userdoc/mail#adding_a_kernelorg_uid_to_your_pgp_key
> +.. _`add the kernel.org UID to your key`: https://korg.docs.kernel.org/mail.html#adding-a-kernel-org-uid-to-your-pgp-key
>
> Web of Trust (WOT) vs. Trust on First Use (TOFU)
> ------------------------------------------------
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v3] docs: process: maintainer-pgp-guide: update kernel.org docs link
From: Amitabh Srivastava @ 2026-02-05 11:55 UTC (permalink / raw)
To: corbet; +Cc: workflows, linux-doc, linux-kernel, Amitabh Srivastava
Update http link to the documentation about how to add a kernel.org UID to
the maintainer's key. Add missing SPDX-License-Identifier to fix a
checkpatch warning.
Signed-off-by: Amitabh Srivastava <amitabh@amidevlab.com>
---
Documentation/process/maintainer-pgp-guide.rst | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/process/maintainer-pgp-guide.rst b/Documentation/process/maintainer-pgp-guide.rst
index b6919bf606c3..1e4d885dc784 100644
--- a/Documentation/process/maintainer-pgp-guide.rst
+++ b/Documentation/process/maintainer-pgp-guide.rst
@@ -1,3 +1,5 @@
+.. SPDX-License-Identifier: GPL-2.0
+
.. _pgpguide:
===========================
@@ -864,7 +866,7 @@ don't already have them)::
If you have a kernel.org account, then you should `add the kernel.org
UID to your key`_ to make WKD more useful to other kernel developers.
-.. _`add the kernel.org UID to your key`: https://korg.wiki.kernel.org/userdoc/mail#adding_a_kernelorg_uid_to_your_pgp_key
+.. _`add the kernel.org UID to your key`: https://korg.docs.kernel.org/mail.html#adding-a-kernel-org-uid-to-your-pgp-key
Web of Trust (WOT) vs. Trust on First Use (TOFU)
------------------------------------------------
--
2.51.0
^ permalink raw reply related
* [PATCH v10 13/13] x86/kasan: Make software tag-based kasan available
From: Maciej Wieczor-Retman @ 2026-02-04 19:20 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Jonathan Corbet, Andrey Ryabinin,
Alexander Potapenko, Andrey Konovalov, Dmitry Vyukov,
Vincenzo Frascino, Andy Lutomirski, Peter Zijlstra, Andrew Morton
Cc: m.wieczorretman, Maciej Wieczor-Retman, linux-kernel, linux-doc,
kasan-dev, workflows
In-Reply-To: <cover.1770232424.git.m.wieczorretman@pm.me>
From: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
Make CONFIG_KASAN_SW_TAGS available for x86 machines if they have
ADDRESS_MASKING enabled (LAM) as that works similarly to Top-Byte Ignore
(TBI) that allows the software tag-based mode on arm64 platform.
The value for sw_tags KASAN_SHADOW_OFFSET was calculated by rearranging
the formulas for KASAN_SHADOW_START and KASAN_SHADOW_END from
arch/x86/include/asm/kasan.h - the only prerequisites being
KASAN_SHADOW_SCALE_SHIFT of 4, and KASAN_SHADOW_END equal to the
one from KASAN generic mode.
Set scale macro based on KASAN mode: in software tag-based mode 16 bytes
of memory map to one shadow byte and 8 in generic mode.
Disable CONFIG_KASAN_INLINE and CONFIG_KASAN_STACK when
CONFIG_KASAN_SW_TAGS is enabled on x86 until the appropriate compiler
support is available.
Lock software tag KASAN behind CC_IS_CLANG due to lack of proper support
by gcc resulting in kernel booting issues.
Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
---
Changelog v10:
- Update Documentation/dev-tools/kasan.rst with x86 related
informations.
Changelog v9:
- Lock HAVE_ARCH_KASAN_HAS_SW_TAGS behind CC_IS_CLANG due to lack of
support from gcc.
- Remove pr_info() from KASAN initialization since it's now done by the
generic init helper.
- Add paragraph to the mm.rst to explain the mutual exclusive nature of
the KASAN address ranges.
- Use cpu_feature_enabled() instead of boot_cpu_has() in
kasan_init_64.c.
Changelog v7:
- Add a paragraph to the patch message explaining how the various
addresses and the KASAN_SHADOW_OFFSET were calculated.
Changelog v6:
- Don't enable KASAN if LAM is not supported.
- Move kasan_init_tags() to kasan_init_64.c to not clutter the setup.c
file.
- Move the #ifdef for the KASAN scale shift here.
- Move the gdb code to patch "Use arithmetic shift for shadow
computation".
- Return "depends on KASAN" line to Kconfig.
- Add the defer kasan config option so KASAN can be disabled on hardware
that doesn't have LAM.
Changelog v4:
- Add x86 specific kasan_mem_to_shadow().
- Revert x86 to the older unsigned KASAN_SHADOW_OFFSET. Do the same to
KASAN_SHADOW_START/END.
- Modify scripts/gdb/linux/kasan.py to keep x86 using unsigned offset.
- Disable inline and stack support when software tags are enabled on
x86.
Changelog v3:
- Remove runtime_const from previous patch and merge the rest here.
- Move scale shift definition back to header file.
- Add new kasan offset for software tag based mode.
- Fix patch message typo 32 -> 16, and 16 -> 8.
- Update lib/Kconfig.kasan with x86 now having software tag-based
support.
Changelog v2:
- Remove KASAN dense code.
Documentation/arch/x86/x86_64/mm.rst | 10 ++++++++--
Documentation/dev-tools/kasan.rst | 28 ++++++++++++++++------------
arch/x86/Kconfig | 4 ++++
arch/x86/boot/compressed/misc.h | 1 +
arch/x86/include/asm/kasan.h | 5 +++++
arch/x86/mm/kasan_init_64.c | 5 +++++
lib/Kconfig.kasan | 3 ++-
7 files changed, 41 insertions(+), 15 deletions(-)
diff --git a/Documentation/arch/x86/x86_64/mm.rst b/Documentation/arch/x86/x86_64/mm.rst
index a6cf05d51bd8..7e2e4c5fa661 100644
--- a/Documentation/arch/x86/x86_64/mm.rst
+++ b/Documentation/arch/x86/x86_64/mm.rst
@@ -60,7 +60,8 @@ Complete virtual memory map with 4-level page tables
ffffe90000000000 | -23 TB | ffffe9ffffffffff | 1 TB | ... unused hole
ffffea0000000000 | -22 TB | ffffeaffffffffff | 1 TB | virtual memory map (vmemmap_base)
ffffeb0000000000 | -21 TB | ffffebffffffffff | 1 TB | ... unused hole
- ffffec0000000000 | -20 TB | fffffbffffffffff | 16 TB | KASAN shadow memory
+ ffffec0000000000 | -20 TB | fffffbffffffffff | 16 TB | KASAN shadow memory (generic mode)
+ fffff40000000000 | -8 TB | fffffbffffffffff | 8 TB | KASAN shadow memory (software tag-based mode)
__________________|____________|__________________|_________|____________________________________________________________
|
| Identical layout to the 56-bit one from here on:
@@ -130,7 +131,8 @@ Complete virtual memory map with 5-level page tables
ffd2000000000000 | -11.5 PB | ffd3ffffffffffff | 0.5 PB | ... unused hole
ffd4000000000000 | -11 PB | ffd5ffffffffffff | 0.5 PB | virtual memory map (vmemmap_base)
ffd6000000000000 | -10.5 PB | ffdeffffffffffff | 2.25 PB | ... unused hole
- ffdf000000000000 | -8.25 PB | fffffbffffffffff | ~8 PB | KASAN shadow memory
+ ffdf000000000000 | -8.25 PB | fffffbffffffffff | ~8 PB | KASAN shadow memory (generic mode)
+ ffeffc0000000000 | -6 PB | fffffbffffffffff | 4 PB | KASAN shadow memory (software tag-based mode)
__________________|____________|__________________|_________|____________________________________________________________
|
| Identical layout to the 47-bit one from here on:
@@ -176,5 +178,9 @@ Be very careful vs. KASLR when changing anything here. The KASLR address
range must not overlap with anything except the KASAN shadow area, which is
correct as KASAN disables KASLR.
+The 'KASAN shadow memory (generic mode)/(software tag-based mode)' ranges are
+mutually exclusive and depend on which KASAN setting is chosen:
+CONFIG_KASAN_GENERIC or CONFIG_KASAN_SW_TAGS.
+
For both 4- and 5-level layouts, the KSTACK_ERASE_POISON value in the last 2MB
hole: ffffffffffff4111
diff --git a/Documentation/dev-tools/kasan.rst b/Documentation/dev-tools/kasan.rst
index 64dbf8b308bd..03b508ebe673 100644
--- a/Documentation/dev-tools/kasan.rst
+++ b/Documentation/dev-tools/kasan.rst
@@ -22,8 +22,8 @@ architectures, but it has significant performance and memory overheads.
Software Tag-Based KASAN or SW_TAGS KASAN, enabled with CONFIG_KASAN_SW_TAGS,
can be used for both debugging and dogfood testing, similar to userspace HWASan.
-This mode is only supported for arm64, but its moderate memory overhead allows
-using it for testing on memory-restricted devices with real workloads.
+This mode is only supported for arm64 and x86, but its moderate memory overhead
+allows using it for testing on memory-restricted devices with real workloads.
Hardware Tag-Based KASAN or HW_TAGS KASAN, enabled with CONFIG_KASAN_HW_TAGS,
is the mode intended to be used as an in-field memory bug detector or as a
@@ -351,10 +351,12 @@ Software Tag-Based KASAN
Software Tag-Based KASAN uses a software memory tagging approach to checking
access validity. It is currently only implemented for the arm64 architecture.
-Software Tag-Based KASAN uses the Top Byte Ignore (TBI) feature of arm64 CPUs
-to store a pointer tag in the top byte of kernel pointers. It uses shadow memory
-to store memory tags associated with each 16-byte memory cell (therefore, it
-dedicates 1/16th of the kernel memory for shadow memory).
+Software Tag-Based KASAN uses the Top Byte Ignore (TBI) feature of arm64 CPUs to
+store a pointer tag in the top byte of kernel pointers. Analogously to TBI on
+x86 CPUs Linear Address Masking (LAM) feature is used and the pointer tag is
+stored in four bits of the kernel pointer's top byte. Software Tag-Based mode
+uses shadow memory to store memory tags associated with each 16-byte memory cell
+(therefore, it dedicates 1/16th of the kernel memory for shadow memory).
On each memory allocation, Software Tag-Based KASAN generates a random tag, tags
the allocated memory with this tag, and embeds the same tag into the returned
@@ -370,12 +372,14 @@ Software Tag-Based KASAN also has two instrumentation modes (outline, which
emits callbacks to check memory accesses; and inline, which performs the shadow
memory checks inline). With outline instrumentation mode, a bug report is
printed from the function that performs the access check. With inline
-instrumentation, a ``brk`` instruction is emitted by the compiler, and a
-dedicated ``brk`` handler is used to print bug reports.
-
-Software Tag-Based KASAN uses 0xFF as a match-all pointer tag (accesses through
-pointers with the 0xFF pointer tag are not checked). The value 0xFE is currently
-reserved to tag freed memory regions.
+instrumentation, arm64's implementation uses the ``brk`` instruction emitted by
+the compiler, and a dedicated ``brk`` handler is used to print bug reports. On
+x86 inline mode doesn't work yet due to missing compiler support.
+
+For arm64 Software Tag-Based KASAN uses 0xFF as a match-all pointer tag
+(accesses through pointers with the 0xFF pointer tag are not checked). The value
+0xFE is currently reserved to tag freed memory regions. On x86 the same tags
+take on 0xF and 0xE respectively.
Hardware Tag-Based KASAN
~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 80527299f859..877668cd5deb 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -67,6 +67,7 @@ config X86
select ARCH_CLOCKSOURCE_INIT
select ARCH_CONFIGURES_CPU_MITIGATIONS
select ARCH_CORRECT_STACKTRACE_ON_KRETPROBE
+ select ARCH_DISABLE_KASAN_INLINE if X86_64 && KASAN_SW_TAGS
select ARCH_ENABLE_HUGEPAGE_MIGRATION if X86_64 && HUGETLB_PAGE && MIGRATION
select ARCH_ENABLE_MEMORY_HOTPLUG if X86_64
select ARCH_ENABLE_MEMORY_HOTREMOVE if MEMORY_HOTPLUG
@@ -196,6 +197,8 @@ config X86
select HAVE_ARCH_JUMP_LABEL_RELATIVE
select HAVE_ARCH_KASAN if X86_64
select HAVE_ARCH_KASAN_VMALLOC if X86_64
+ select HAVE_ARCH_KASAN_SW_TAGS if ADDRESS_MASKING && CC_IS_CLANG
+ select ARCH_NEEDS_DEFER_KASAN if ADDRESS_MASKING
select HAVE_ARCH_KFENCE
select HAVE_ARCH_KMSAN if X86_64
select HAVE_ARCH_KGDB
@@ -410,6 +413,7 @@ config AUDIT_ARCH
config KASAN_SHADOW_OFFSET
hex
depends on KASAN
+ default 0xeffffc0000000000 if KASAN_SW_TAGS
default 0xdffffc0000000000
config HAVE_INTEL_TXT
diff --git a/arch/x86/boot/compressed/misc.h b/arch/x86/boot/compressed/misc.h
index fd855e32c9b9..ba70036c2abd 100644
--- a/arch/x86/boot/compressed/misc.h
+++ b/arch/x86/boot/compressed/misc.h
@@ -13,6 +13,7 @@
#undef CONFIG_PARAVIRT_SPINLOCKS
#undef CONFIG_KASAN
#undef CONFIG_KASAN_GENERIC
+#undef CONFIG_KASAN_SW_TAGS
#define __NO_FORTIFY
diff --git a/arch/x86/include/asm/kasan.h b/arch/x86/include/asm/kasan.h
index 90c18e30848f..53ab7de16517 100644
--- a/arch/x86/include/asm/kasan.h
+++ b/arch/x86/include/asm/kasan.h
@@ -6,7 +6,12 @@
#include <linux/kasan-tags.h>
#include <linux/types.h>
#define KASAN_SHADOW_OFFSET _AC(CONFIG_KASAN_SHADOW_OFFSET, UL)
+
+#ifdef CONFIG_KASAN_SW_TAGS
+#define KASAN_SHADOW_SCALE_SHIFT 4
+#else
#define KASAN_SHADOW_SCALE_SHIFT 3
+#endif
/*
* Compiler uses shadow offset assuming that addresses start
diff --git a/arch/x86/mm/kasan_init_64.c b/arch/x86/mm/kasan_init_64.c
index 7f5c11328ec1..8cbb8ec32061 100644
--- a/arch/x86/mm/kasan_init_64.c
+++ b/arch/x86/mm/kasan_init_64.c
@@ -465,4 +465,9 @@ void __init kasan_init(void)
init_task.kasan_depth = 0;
kasan_init_generic();
+
+ if (cpu_feature_enabled(X86_FEATURE_LAM))
+ kasan_init_sw_tags();
+ else
+ pr_info("KernelAddressSanitizer not initialized (sw-tags): hardware doesn't support LAM\n");
}
diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan
index a4bb610a7a6f..d13ea8da7bfd 100644
--- a/lib/Kconfig.kasan
+++ b/lib/Kconfig.kasan
@@ -112,7 +112,8 @@ config KASAN_SW_TAGS
Requires GCC 11+ or Clang.
- Supported only on arm64 CPUs and relies on Top Byte Ignore.
+ Supported on arm64 CPUs that support Top Byte Ignore and on x86 CPUs
+ that support Linear Address Masking.
Consumes about 1/16th of available memory at kernel start and
add an overhead of ~20% for dynamic allocations.
--
2.53.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox