* [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
* [PATCH v10 01/13] kasan: sw_tags: Use arithmetic shift for shadow computation
From: Maciej Wieczor-Retman @ 2026-02-04 19:19 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Jonathan Corbet, Andrey Ryabinin,
Alexander Potapenko, Andrey Konovalov, Dmitry Vyukov,
Vincenzo Frascino, Andrew Morton, Jan Kiszka, Kieran Bingham,
Nathan Chancellor, Nick Desaulniers, Bill Wendling, Justin Stitt
Cc: m.wieczorretman, Samuel Holland, Maciej Wieczor-Retman,
linux-arm-kernel, linux-doc, linux-kernel, kasan-dev, workflows,
linux-mm, llvm
In-Reply-To: <cover.1770232424.git.m.wieczorretman@pm.me>
From: Samuel Holland <samuel.holland@sifive.com>
Currently, kasan_mem_to_shadow() uses a logical right shift, which turns
canonical kernel addresses into non-canonical addresses by clearing the
high KASAN_SHADOW_SCALE_SHIFT bits. The value of KASAN_SHADOW_OFFSET is
then chosen so that the addition results in a canonical address for the
shadow memory.
For KASAN_GENERIC, this shift/add combination is ABI with the compiler,
because KASAN_SHADOW_OFFSET is used in compiler-generated inline tag
checks[1], which must only attempt to dereference canonical addresses.
However, for KASAN_SW_TAGS there is some freedom to change the algorithm
without breaking the ABI. Because TBI is enabled for kernel addresses,
the top bits of shadow memory addresses computed during tag checks are
irrelevant, and so likewise are the top bits of KASAN_SHADOW_OFFSET.
This is demonstrated by the fact that LLVM uses a logical right shift in
the tag check fast path[2] but a sbfx (signed bitfield extract)
instruction in the slow path[3] without causing any issues.
Use an arithmetic shift in kasan_mem_to_shadow() as it provides a number
of benefits:
1) The memory layout doesn't change but is easier to understand.
KASAN_SHADOW_OFFSET becomes a canonical memory address, and the shifted
pointer becomes a negative offset, so KASAN_SHADOW_OFFSET ==
KASAN_SHADOW_END regardless of the shift amount or the size of the
virtual address space.
2) KASAN_SHADOW_OFFSET becomes a simpler constant, requiring only one
instruction to load instead of two. Since it must be loaded in each
function with a tag check, this decreases kernel text size by 0.5%.
3) This shift and the sign extension from kasan_reset_tag() can be
combined into a single sbfx instruction. When this same algorithm change
is applied to the compiler, it removes an instruction from each inline
tag check, further reducing kernel text size by an additional 4.6%.
These benefits extend to other architectures as well. On RISC-V, where
the baseline ISA does not shifted addition or have an equivalent to the
sbfx instruction, loading KASAN_SHADOW_OFFSET is reduced from 3 to 2
instructions, and kasan_mem_to_shadow(kasan_reset_tag(addr)) similarly
combines two consecutive right shifts.
Add the arch_kasan_non_canonical_hook() to group the arch specific code
in the relevant arch directories.
Link: https://github.com/llvm/llvm-project/blob/llvmorg-20-init/llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp#L1316 [1]
Link: https://github.com/llvm/llvm-project/blob/llvmorg-20-init/llvm/lib/Transforms/Instrumentation/HWAddressSanitizer.cpp#L895 [2]
Link: https://github.com/llvm/llvm-project/blob/llvmorg-20-init/llvm/lib/Target/AArch64/AArch64AsmPrinter.cpp#L669 [3]
Signed-off-by: Samuel Holland <samuel.holland@sifive.com>
Co-developed-by: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
---
Changelog v10: (Maciej)
- Update the Documentation/dev-tools/kasan.rst file with the changed
kasan_mem_to_shadow().
Changelog v9: (Maciej)
- Take out the arm64 related code from mm/kasan/report.c and put it in
the arch specific directory in a new file so the kasan_mem_to_shadow()
function can be included.
- Reset addr tag bits in arm64's arch_kasan_non_canonical_hook() so the
inline mode can also work with that function (Andrey Ryabinin).
- Fix incorrect number of zeros in a comment in mm/kasan/report.c.
- Remove Catalin's acked-by since changes were made.
Changelog v7: (Maciej)
- Change UL to ULL in report.c to fix some compilation warnings.
Changelog v6: (Maciej)
- Add Catalin's acked-by.
- Move x86 gdb snippet here from the last patch.
Changelog v5: (Maciej)
- (u64) -> (unsigned long) in report.c
Changelog v4: (Maciej)
- Revert x86 to signed mem_to_shadow mapping.
- Remove last two paragraphs since they were just poorer duplication of
the comments in kasan_non_canonical_hook().
Changelog v3: (Maciej)
- Fix scripts/gdb/linux/kasan.py so the new signed mem_to_shadow() is
reflected there.
- Fix Documentation/arch/arm64/kasan-offsets.sh to take new offsets into
account.
- Made changes to the kasan_non_canonical_hook() according to upstream
discussion. Settled on overflow on both ranges and separate checks for
x86 and arm.
Changelog v2: (Maciej)
- Correct address range that's checked in kasan_non_canonical_hook().
Adjust the comment inside.
- Remove part of comment from arch/arm64/include/asm/memory.h.
- Append patch message paragraph about the overflow in
kasan_non_canonical_hook().
Documentation/arch/arm64/kasan-offsets.sh | 8 ++++--
Documentation/dev-tools/kasan.rst | 18 ++++++++----
MAINTAINERS | 2 +-
arch/arm64/Kconfig | 10 +++----
arch/arm64/include/asm/kasan.h | 5 ++++
arch/arm64/include/asm/memory.h | 14 ++++++++-
arch/arm64/mm/Makefile | 2 ++
arch/arm64/mm/kasan_init.c | 7 +++--
arch/arm64/mm/kasan_sw_tags.c | 35 +++++++++++++++++++++++
include/linux/kasan.h | 10 +++++--
mm/kasan/kasan.h | 7 +++++
mm/kasan/report.c | 15 ++++++++--
scripts/gdb/linux/kasan.py | 5 +++-
scripts/gdb/linux/mm.py | 5 ++--
14 files changed, 118 insertions(+), 25 deletions(-)
create mode 100644 arch/arm64/mm/kasan_sw_tags.c
diff --git a/Documentation/arch/arm64/kasan-offsets.sh b/Documentation/arch/arm64/kasan-offsets.sh
index 2dc5f9e18039..ce777c7c7804 100644
--- a/Documentation/arch/arm64/kasan-offsets.sh
+++ b/Documentation/arch/arm64/kasan-offsets.sh
@@ -5,8 +5,12 @@
print_kasan_offset () {
printf "%02d\t" $1
- printf "0x%08x00000000\n" $(( (0xffffffff & (-1 << ($1 - 1 - 32))) \
- - (1 << (64 - 32 - $2)) ))
+ if [[ $2 -ne 4 ]] then
+ printf "0x%08x00000000\n" $(( (0xffffffff & (-1 << ($1 - 1 - 32))) \
+ - (1 << (64 - 32 - $2)) ))
+ else
+ printf "0x%08x00000000\n" $(( (0xffffffff & (-1 << ($1 - 1 - 32))) ))
+ fi
}
echo KASAN_SHADOW_SCALE_SHIFT = 3
diff --git a/Documentation/dev-tools/kasan.rst b/Documentation/dev-tools/kasan.rst
index a034700da7c4..64dbf8b308bd 100644
--- a/Documentation/dev-tools/kasan.rst
+++ b/Documentation/dev-tools/kasan.rst
@@ -318,13 +318,19 @@ translate a memory address to its corresponding shadow address.
Here is the function which translates an address to its corresponding shadow
address::
- static inline void *kasan_mem_to_shadow(const void *addr)
- {
- return (void *)((unsigned long)addr >> KASAN_SHADOW_SCALE_SHIFT)
- + KASAN_SHADOW_OFFSET;
- }
+ static inline void *kasan_mem_to_shadow(const void *addr)
+ {
+ void *scaled;
-where ``KASAN_SHADOW_SCALE_SHIFT = 3``.
+ if (IS_ENABLED(CONFIG_KASAN_GENERIC))
+ scaled = (void *)((unsigned long)addr >> KASAN_SHADOW_SCALE_SHIFT);
+ else
+ scaled = (void *)((long)addr >> KASAN_SHADOW_SCALE_SHIFT);
+
+ return KASAN_SHADOW_OFFSET + scaled;
+ }
+
+where for Generic KASAN ``KASAN_SHADOW_SCALE_SHIFT = 3``.
Compile-time instrumentation is used to insert memory access checks. Compiler
inserts function calls (``__asan_load*(addr)``, ``__asan_store*(addr)``) before
diff --git a/MAINTAINERS b/MAINTAINERS
index 0efa8cc6775b..bbcb5bf5e2c6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13587,7 +13587,7 @@ S: Maintained
B: https://bugzilla.kernel.org/buglist.cgi?component=Sanitizers&product=Memory%20Management
F: Documentation/dev-tools/kasan.rst
F: arch/*/include/asm/*kasan.h
-F: arch/*/mm/kasan_init*
+F: arch/*/mm/kasan*
F: include/linux/kasan*.h
F: lib/Kconfig.kasan
F: mm/kasan/
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 93173f0a09c7..c1b7261cdb96 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -434,11 +434,11 @@ config KASAN_SHADOW_OFFSET
default 0xdffffe0000000000 if ARM64_VA_BITS_42 && !KASAN_SW_TAGS
default 0xdfffffc000000000 if ARM64_VA_BITS_39 && !KASAN_SW_TAGS
default 0xdffffff800000000 if ARM64_VA_BITS_36 && !KASAN_SW_TAGS
- default 0xefff800000000000 if (ARM64_VA_BITS_48 || (ARM64_VA_BITS_52 && !ARM64_16K_PAGES)) && KASAN_SW_TAGS
- default 0xefffc00000000000 if (ARM64_VA_BITS_47 || ARM64_VA_BITS_52) && ARM64_16K_PAGES && KASAN_SW_TAGS
- default 0xeffffe0000000000 if ARM64_VA_BITS_42 && KASAN_SW_TAGS
- default 0xefffffc000000000 if ARM64_VA_BITS_39 && KASAN_SW_TAGS
- default 0xeffffff800000000 if ARM64_VA_BITS_36 && KASAN_SW_TAGS
+ default 0xffff800000000000 if (ARM64_VA_BITS_48 || (ARM64_VA_BITS_52 && !ARM64_16K_PAGES)) && KASAN_SW_TAGS
+ default 0xffffc00000000000 if (ARM64_VA_BITS_47 || ARM64_VA_BITS_52) && ARM64_16K_PAGES && KASAN_SW_TAGS
+ default 0xfffffe0000000000 if ARM64_VA_BITS_42 && KASAN_SW_TAGS
+ default 0xffffffc000000000 if ARM64_VA_BITS_39 && KASAN_SW_TAGS
+ default 0xfffffff800000000 if ARM64_VA_BITS_36 && KASAN_SW_TAGS
default 0xffffffffffffffff
config UNWIND_TABLES
diff --git a/arch/arm64/include/asm/kasan.h b/arch/arm64/include/asm/kasan.h
index b167e9d3da91..42d8e3092835 100644
--- a/arch/arm64/include/asm/kasan.h
+++ b/arch/arm64/include/asm/kasan.h
@@ -22,5 +22,10 @@ void kasan_init(void);
static inline void kasan_init(void) { }
#endif
+#ifdef CONFIG_KASAN_SW_TAGS
+bool __arch_kasan_non_canonical_hook(unsigned long addr);
+#define arch_kasan_non_canonical_hook(addr) __arch_kasan_non_canonical_hook(addr)
+#endif
+
#endif
#endif
diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index 9d54b2ea49d6..f127fbf691ac 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -89,7 +89,15 @@
*
* KASAN_SHADOW_END is defined first as the shadow address that corresponds to
* the upper bound of possible virtual kernel memory addresses UL(1) << 64
- * according to the mapping formula.
+ * according to the mapping formula. For Generic KASAN, the address in the
+ * mapping formula is treated as unsigned (part of the compiler's ABI), so the
+ * end of the shadow memory region is at a large positive offset from
+ * KASAN_SHADOW_OFFSET. For Software Tag-Based KASAN, the address in the
+ * formula is treated as signed. Since all kernel addresses are negative, they
+ * map to shadow memory below KASAN_SHADOW_OFFSET, making KASAN_SHADOW_OFFSET
+ * itself the end of the shadow memory region. (User pointers are positive and
+ * would map to shadow memory above KASAN_SHADOW_OFFSET, but shadow memory is
+ * not allocated for them.)
*
* KASAN_SHADOW_START is defined second based on KASAN_SHADOW_END. The shadow
* memory start must map to the lowest possible kernel virtual memory address
@@ -100,7 +108,11 @@
*/
#if defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)
#define KASAN_SHADOW_OFFSET _AC(CONFIG_KASAN_SHADOW_OFFSET, UL)
+#ifdef CONFIG_KASAN_GENERIC
#define KASAN_SHADOW_END ((UL(1) << (64 - KASAN_SHADOW_SCALE_SHIFT)) + KASAN_SHADOW_OFFSET)
+#else
+#define KASAN_SHADOW_END KASAN_SHADOW_OFFSET
+#endif
#define _KASAN_SHADOW_START(va) (KASAN_SHADOW_END - (UL(1) << ((va) - KASAN_SHADOW_SCALE_SHIFT)))
#define KASAN_SHADOW_START _KASAN_SHADOW_START(vabits_actual)
#define PAGE_END KASAN_SHADOW_START
diff --git a/arch/arm64/mm/Makefile b/arch/arm64/mm/Makefile
index c26489cf96cd..4658d59b7ea6 100644
--- a/arch/arm64/mm/Makefile
+++ b/arch/arm64/mm/Makefile
@@ -15,4 +15,6 @@ obj-$(CONFIG_ARM64_GCS) += gcs.o
KASAN_SANITIZE_physaddr.o += n
obj-$(CONFIG_KASAN) += kasan_init.o
+obj-$(CONFIG_KASAN_SW_TAGS) += kasan_sw_tags.o
KASAN_SANITIZE_kasan_init.o := n
+KASAN_SANITIZE_kasan_sw_tags.o := n
diff --git a/arch/arm64/mm/kasan_init.c b/arch/arm64/mm/kasan_init.c
index abeb81bf6ebd..937f6eb8115b 100644
--- a/arch/arm64/mm/kasan_init.c
+++ b/arch/arm64/mm/kasan_init.c
@@ -198,8 +198,11 @@ static bool __init root_level_aligned(u64 addr)
/* The early shadow maps everything to a single page of zeroes */
asmlinkage void __init kasan_early_init(void)
{
- BUILD_BUG_ON(KASAN_SHADOW_OFFSET !=
- KASAN_SHADOW_END - (1UL << (64 - KASAN_SHADOW_SCALE_SHIFT)));
+ if (IS_ENABLED(CONFIG_KASAN_GENERIC))
+ BUILD_BUG_ON(KASAN_SHADOW_OFFSET !=
+ KASAN_SHADOW_END - (1UL << (64 - KASAN_SHADOW_SCALE_SHIFT)));
+ else
+ BUILD_BUG_ON(KASAN_SHADOW_OFFSET != KASAN_SHADOW_END);
BUILD_BUG_ON(!IS_ALIGNED(_KASAN_SHADOW_START(VA_BITS), SHADOW_ALIGN));
BUILD_BUG_ON(!IS_ALIGNED(_KASAN_SHADOW_START(VA_BITS_MIN), SHADOW_ALIGN));
BUILD_BUG_ON(!IS_ALIGNED(KASAN_SHADOW_END, SHADOW_ALIGN));
diff --git a/arch/arm64/mm/kasan_sw_tags.c b/arch/arm64/mm/kasan_sw_tags.c
new file mode 100644
index 000000000000..d509db7bdc7e
--- /dev/null
+++ b/arch/arm64/mm/kasan_sw_tags.c
@@ -0,0 +1,35 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * This file contains ARM64 specific KASAN sw_tags code.
+ */
+
+#include <linux/kasan.h>
+
+bool __arch_kasan_non_canonical_hook(unsigned long addr)
+{
+ /*
+ * For Software Tag-Based KASAN, kasan_mem_to_shadow() uses the
+ * arithmetic shift. Normally, this would make checking for a possible
+ * shadow address complicated, as the shadow address computation
+ * operation would overflow only for some memory addresses. However, due
+ * to the chosen KASAN_SHADOW_OFFSET values and the fact the
+ * kasan_mem_to_shadow() only operates on pointers with the tag reset,
+ * the overflow always happens.
+ *
+ * For arm64, the top byte of the pointer gets reset to 0xFF. Thus, the
+ * possible shadow addresses belong to a region that is the result of
+ * kasan_mem_to_shadow() applied to the memory range
+ * [0xFF00000000000000, 0xFFFFFFFFFFFFFFFF]. Despite the overflow, the
+ * resulting possible shadow region is contiguous, as the overflow
+ * happens for both 0xFF00000000000000 and 0xFFFFFFFFFFFFFFFF.
+ *
+ * Reset the addr's tag bits so the inline mode which still uses
+ * the logical shift can work correctly. Otherwise it would
+ * always return because of the 'smaller than' comparison below.
+ */
+ addr |= (0xFFULL << 56);
+ if (addr < (unsigned long)kasan_mem_to_shadow((void *)(0xFFULL << 56)) ||
+ addr > (unsigned long)kasan_mem_to_shadow((void *)(~0ULL)))
+ return true;
+ return false;
+}
diff --git a/include/linux/kasan.h b/include/linux/kasan.h
index 338a1921a50a..81c83dcfcebe 100644
--- a/include/linux/kasan.h
+++ b/include/linux/kasan.h
@@ -62,8 +62,14 @@ int kasan_populate_early_shadow(const void *shadow_start,
#ifndef kasan_mem_to_shadow
static inline void *kasan_mem_to_shadow(const void *addr)
{
- return (void *)((unsigned long)addr >> KASAN_SHADOW_SCALE_SHIFT)
- + KASAN_SHADOW_OFFSET;
+ void *scaled;
+
+ if (IS_ENABLED(CONFIG_KASAN_GENERIC))
+ scaled = (void *)((unsigned long)addr >> KASAN_SHADOW_SCALE_SHIFT);
+ else
+ scaled = (void *)((long)addr >> KASAN_SHADOW_SCALE_SHIFT);
+
+ return KASAN_SHADOW_OFFSET + scaled;
}
#endif
diff --git a/mm/kasan/kasan.h b/mm/kasan/kasan.h
index fc9169a54766..02574e53d980 100644
--- a/mm/kasan/kasan.h
+++ b/mm/kasan/kasan.h
@@ -558,6 +558,13 @@ static inline bool kasan_arch_is_ready(void) { return true; }
#error kasan_arch_is_ready only works in KASAN generic outline mode!
#endif
+#ifndef arch_kasan_non_canonical_hook
+static inline bool arch_kasan_non_canonical_hook(unsigned long addr)
+{
+ return false;
+}
+#endif
+
#if IS_ENABLED(CONFIG_KASAN_KUNIT_TEST)
void kasan_kunit_test_suite_start(void);
diff --git a/mm/kasan/report.c b/mm/kasan/report.c
index 62c01b4527eb..53152d148deb 100644
--- a/mm/kasan/report.c
+++ b/mm/kasan/report.c
@@ -642,10 +642,19 @@ void kasan_non_canonical_hook(unsigned long addr)
const char *bug_type;
/*
- * All addresses that came as a result of the memory-to-shadow mapping
- * (even for bogus pointers) must be >= KASAN_SHADOW_OFFSET.
+ * For Generic KASAN, kasan_mem_to_shadow() uses the logical right shift
+ * and never overflows with the chosen KASAN_SHADOW_OFFSET values. Thus,
+ * the possible shadow addresses (even for bogus pointers) belong to a
+ * single contiguous region that is the result of kasan_mem_to_shadow()
+ * applied to the whole address space.
*/
- if (addr < KASAN_SHADOW_OFFSET)
+ if (IS_ENABLED(CONFIG_KASAN_GENERIC)) {
+ if (addr < (unsigned long)kasan_mem_to_shadow((void *)(0ULL)) ||
+ addr > (unsigned long)kasan_mem_to_shadow((void *)(~0ULL)))
+ return;
+ }
+
+ if (arch_kasan_non_canonical_hook(addr))
return;
orig_addr = (unsigned long)kasan_shadow_to_mem((void *)addr);
diff --git a/scripts/gdb/linux/kasan.py b/scripts/gdb/linux/kasan.py
index 56730b3fde0b..4b86202b155f 100644
--- a/scripts/gdb/linux/kasan.py
+++ b/scripts/gdb/linux/kasan.py
@@ -7,7 +7,8 @@
#
import gdb
-from linux import constants, mm
+from linux import constants, utils, mm
+from ctypes import c_int64 as s64
def help():
t = """Usage: lx-kasan_mem_to_shadow [Hex memory addr]
@@ -39,6 +40,8 @@ class KasanMemToShadow(gdb.Command):
else:
help()
def kasan_mem_to_shadow(self, addr):
+ if constants.CONFIG_KASAN_SW_TAGS and not utils.is_target_arch('x86'):
+ addr = s64(addr)
return (addr >> self.p_ops.KASAN_SHADOW_SCALE_SHIFT) + self.p_ops.KASAN_SHADOW_OFFSET
KasanMemToShadow()
diff --git a/scripts/gdb/linux/mm.py b/scripts/gdb/linux/mm.py
index 7571aebbe650..2e63f3dedd53 100644
--- a/scripts/gdb/linux/mm.py
+++ b/scripts/gdb/linux/mm.py
@@ -110,12 +110,13 @@ class aarch64_page_ops():
self.KERNEL_END = gdb.parse_and_eval("_end")
if constants.LX_CONFIG_KASAN_GENERIC or constants.LX_CONFIG_KASAN_SW_TAGS:
+ self.KASAN_SHADOW_OFFSET = constants.LX_CONFIG_KASAN_SHADOW_OFFSET
if constants.LX_CONFIG_KASAN_GENERIC:
self.KASAN_SHADOW_SCALE_SHIFT = 3
+ self.KASAN_SHADOW_END = (1 << (64 - self.KASAN_SHADOW_SCALE_SHIFT)) + self.KASAN_SHADOW_OFFSET
else:
self.KASAN_SHADOW_SCALE_SHIFT = 4
- self.KASAN_SHADOW_OFFSET = constants.LX_CONFIG_KASAN_SHADOW_OFFSET
- self.KASAN_SHADOW_END = (1 << (64 - self.KASAN_SHADOW_SCALE_SHIFT)) + self.KASAN_SHADOW_OFFSET
+ self.KASAN_SHADOW_END = self.KASAN_SHADOW_OFFSET
self.PAGE_END = self.KASAN_SHADOW_END - (1 << (self.vabits_actual - self.KASAN_SHADOW_SCALE_SHIFT))
else:
self.PAGE_END = self._PAGE_END(self.VA_BITS_MIN)
--
2.53.0
^ permalink raw reply related
* [PATCH v10 00/13] kasan: x86: arm64: KASAN tag-based mode for x86
From: Maciej Wieczor-Retman @ 2026-02-04 19:18 UTC (permalink / raw)
To: hpa, andreyknvl, peterz, david, nathan, samitolvanen,
catalin.marinas, lorenzo.stoakes, rppt, ryabinin.a.a, luto,
surenb, nick.desaulniers+lkml, kas, chleroy, will,
maciej.wieczor-retman, vbabka, Liam.Howlett, jeremy.linton,
jpoimboe, thomas.lendacky, thuth, kees, mingo, jan.kiszka,
dave.hansen, vincenzo.frascino, morbo, axelrasmussen, yuanchu,
urezki, trintaeoitogc, brgerst, osandov, akpm, mhocko, nsc,
kbingham, glider, samuel.holland, corbet, dvyukov,
anshuman.khandual, yeoreum.yun, weixugc, leitao, ubizjak,
justinstitt, bp, jackmanb, ardb, tglx
Cc: linux-kernel, x86, llvm, linux-arm-kernel, linux-kbuild,
workflows, kasan-dev, linux-doc, linux-mm, m.wieczorretman
======= Introduction
The patchset aims to add a KASAN tag-based mode for the x86 architecture
with the help of the new CPU feature called Linear Address Masking
(LAM). Main improvement introduced by the series is 2x lower memory
usage compared to KASAN's generic mode, the only currently available
mode on x86. The tag based mode may also find errors that the generic
mode couldn't because of differences in how these modes operate.
======= How does KASAN' tag-based mode work?
When enabled, memory accesses and allocations are augmented by the
compiler during kernel compilation. Instrumentation functions are added
to each memory allocation and each pointer dereference.
The allocation related functions generate a random tag and save it in
two places: in shadow memory that maps to the allocated memory, and in
the top bits of the pointer that points to the allocated memory. Storing
the tag in the top of the pointer is possible because of Top-Byte Ignore
(TBI) on arm64 architecture and LAM on x86.
The access related functions are performing a comparison between the tag
stored in the pointer and the one stored in shadow memory. If the tags
don't match an out of bounds error must have occurred and so an error
report is generated.
The general idea for the tag-based mode is very well explained in the
series with the original implementation [1].
[1] https://lore.kernel.org/all/cover.1544099024.git.andreyknvl@google.com/
======= Differences summary compared to the arm64 tag-based mode
- Tag width:
- Tag width influences the chance of a tag mismatch due to two
tags from different allocations having the same value. The
bigger the possible range of tag values the lower the chance
of that happening.
- Shortening the tag width from 8 bits to 4, while it can help
with memory usage, it also increases the chance of not
reporting an error. 4 bit tags have a ~7% chance of a tag
mismatch.
- Address masking mechanism
- TBI in arm64 allows for storing metadata in the top 8 bits of
the virtual address.
- LAM in x86 allows storing tags in bits [62:57] of the pointer.
To maximize memory savings the tag width is reduced to bits
[60:57].
- Inline mode mismatch reporting
- Arm64 inserts a BRK instruction to pass metadata about a tag
mismatch to the KASAN report.
- Right now on x86 the INT3 instruction is used for the same
purpose. The attempt to move it over to use UD1 is already
implemented and tested but relies on another series that needs
merging first. Therefore this patch will be posted separately
once the dependency is satisfied by being merged upstream.
======= Testing
Checked all the kunits for both software tags and generic KASAN after
making changes.
In generic mode (both with these patches and without) the results were:
kasan: pass:61 fail:1 skip:14 total:76
Totals: pass:61 fail:1 skip:14 total:76
not ok 1 kasan
and for software tags:
kasan: pass:65 fail:1 skip:10 total:76
Totals: pass:65 fail:1 skip:10 total:76
not ok 1 kasan
At the time of testing the one failing case is also present on generic
mode without this patchset applied. This seems to point to something
else being at fault for the one case not passing. The test case in
question concerns strscpy() out of bounds error not getting caught.
======= Benchmarks [1]
All tests were ran on a Sierra Forest server platform. The only
differences between the tests were kernel options:
- CONFIG_KASAN
- CONFIG_KASAN_GENERIC
- CONFIG_KASAN_SW_TAGS
- CONFIG_KASAN_INLINE [1]
- CONFIG_KASAN_OUTLINE
Boot time (until login prompt):
* 02:55 for clean kernel
* 05:42 / 06:32 for generic KASAN (inline/outline)
* 05:58 for tag-based KASAN (outline) [2]
Total memory usage (512GB present on the system - MemAvailable just
after boot):
* 12.56 GB for clean kernel
* 81.74 GB for generic KASAN
* 44.39 GB for tag-based KASAN
Kernel size:
* 14 MB for clean kernel
* 24.7 MB / 19.5 MB for generic KASAN (inline/outline)
* 27.1 MB / 18.1 MB for tag-based KASAN (inline/outline)
Work under load time comparison (compiling the mainline kernel) (200 cores):
* 62s for clean kernel
* 171s / 125s for generic KASAN (outline/inline)
* 145s for tag-based KASAN (outline) [2]
[1] Currently inline mode doesn't work on x86 due to things missing in
the compiler. I have written a patch for clang that seems to fix the
inline mode and I was able to boot and check that all patches regarding
the inline mode work as expected. My hope is to post the patch to LLVM
once this series is completed, and then make inline mode available in
the kernel config.
[2] While I was able to boot the inline tag-based kernel with my
compiler changes in a simulated environment, due to toolchain
difficulties I couldn't get it to boot on the machine I had access to.
Also boot time results from the simulation seem too good to be true, and
they're much too worse for the generic case to be believable. Therefore
I'm posting only results from the physical server platform.
======= Compilation
Clang was used to compile the series (make LLVM=1) since gcc doesn't
seem to have support for KASAN tag-based compiler instrumentation on
x86. Patchset does seem to compile with gcc without an issue but doesn't
boot afterwards.
======= Dependencies
The series is based on 6.19-rc8.
======= Previous versions
v9: https://lore.kernel.org/all/cover.1768845098.git.m.wieczorretman@pm.me/
v8: https://lore.kernel.org/all/cover.1768233085.git.m.wieczorretman@pm.me/
v7: https://lore.kernel.org/all/cover.1765386422.git.m.wieczorretman@pm.me/
v6: https://lore.kernel.org/all/cover.1761763681.git.m.wieczorretman@pm.me/
v5: https://lore.kernel.org/all/cover.1756151769.git.maciej.wieczor-retman@intel.com/
v4: https://lore.kernel.org/all/cover.1755004923.git.maciej.wieczor-retman@intel.com/
v3: https://lore.kernel.org/all/cover.1743772053.git.maciej.wieczor-retman@intel.com/
v2: https://lore.kernel.org/all/cover.1739866028.git.maciej.wieczor-retman@intel.com/
v1: https://lore.kernel.org/all/cover.1738686764.git.maciej.wieczor-retman@intel.com/
=== (two fixes patches were split off after v6) (merged into mm-unstable)
v1: https://lore.kernel.org/all/cover.1762267022.git.m.wieczorretman@pm.me/
v2: https://lore.kernel.org/all/cover.1764685296.git.m.wieczorretman@pm.me/
v3: https://lore.kernel.org/all/cover.1764874575.git.m.wieczorretman@pm.me/
v4: https://lore.kernel.org/all/cover.1764945396.git.m.wieczorretman@pm.me/
Changes v10:
- Rebase the series onto 6.19-rc8.
- Add Mike Rapoport's acked-by to patch 6.
- Modify Documentation/dev-tools/kasan.rst in patches 1 and 13.
Changes v9:
- Lock HAVE_ARCH_KASAN_SW_TAGS behind CC_IS_CLANG due to gcc not working
in practice.
- Remove pr_info() from KASAN initialization.
- Add paragraph to mm.rst explaining the alternative KASAN memory
ranges.
- Move out arch based code from kasan_non_canonical_hook() into arch
subdirectories. arm64 and non-arch changes in patch 1, x86 changes in
patch 12.
- Reset tag bits on arm64's non-canonical hook to allow inline mode to
work.
- Revert modifying __is_canonical_address() since it can break KVM. Just
untag address in copy_from_kernel_no_fault_allowed().
- Add a bunch of reviewed-by tags.
Changes v8:
- Detached the UD1/INT3 inline patch from the series so the whole
patchset can be merged without waiting on other dependency series. For
now with lack of compiler support for the inline mode that patch
didn't work anyway so this delay is not an issue.
- Rebased patches onto 6.19-rc5.
- Added acked-by tag to "kasan: arm64: x86: Make special tags arch
specific".
Changes v7:
- Rebased the series onto Peter Zijlstra's "WARN() hackery" v2 patchset.
- Fix flipped memset arguments in "x86/kasan: KASAN raw shadow memory
PTE init".
- Reorder tag width defines on arm64 to avoid redefinition warnings.
- Split off the pcpu unpoison patches into a separate fix oriented
series.
- Redid the canonicality checks so it works for KVM too (didn't change
the __canonical_address() function previously).
- A lot of fixes pointed out by Alexander in his great review:
- Fixed "x86/mm: Physical address comparisons in fill_p*d/pte"
- Merged "Support tag widths less than 8 bits" and "Make special
tags arch specific".
- Added comments and extended patch messages for patches
"x86/kasan: Make software tag-based kasan available" and
"mm/execmem: Untag addresses in EXECMEM_ROX related pointer arithmetic",
- Fixed KASAN_TAG_MASK definition order so all patches compile
individually.
- Renamed kasan_inline.c to kasan_sw_tags.c.
Changes v6:
- Initialize sw-tags only when LAM is available.
- Move inline mode to use UD1 instead of INT3
- Remove inline multishot patch.
- Fix the canonical check to work for user addresses too.
- Revise patch names and messages to align to tip tree rules.
- Fix vdso compilation issue.
Changes v5:
- Fix a bunch of arm64 compilation errors I didn't catch earlier.
Thank You Ada for testing the series!
- Simplify the usage of the tag handling x86 functions (virt_to_page,
phys_addr etc.).
- Remove within() and within_range() from the EXECMEM_ROX patch.
Changes v4:
- Revert x86 kasan_mem_to_shadow() scheme to the same on used in generic
KASAN. Keep the arithmetic shift idea for the KASAN in general since
it makes more sense for arm64 and in risc-v.
- Fix inline mode but leave it unavailable until a complementary
compiler patch can be merged.
- Apply Dave Hansen's comments on series formatting, patch style and
code simplifications.
Changes v3:
- Remove the runtime_const patch and setup a unified offset for both 5
and 4 paging levels.
- Add a fix for inline mode on x86 tag-based KASAN. Add a handler for
int3 that is generated on inline tag mismatches.
- Fix scripts/gdb/linux/kasan.py so the new signed mem_to_shadow() is
reflected there.
- Fix Documentation/arch/arm64/kasan-offsets.sh to take new offsets into
account.
- Made changes to the kasan_non_canonical_hook() according to upstream
discussion.
- Remove patches 2 and 3 since they related to risc-v and this series
adds only x86 related things.
- Reorder __tag_*() functions so they're before arch_kasan_*(). Remove
CONFIG_KASAN condition from __tag_set().
Changes v2:
- Split the series into one adding KASAN tag-based mode (this one) and
another one that adds the dense mode to KASAN (will post later).
- Removed exporting kasan_poison() and used a wrapper instead in
kasan_init_64.c
- Prepended series with 4 patches from the risc-v series and applied
review comments to the first patch as the rest already are reviewed.
Maciej Wieczor-Retman (11):
kasan: Fix inline mode for x86 tag-based mode
x86/kasan: Add arch specific kasan functions
x86/mm: Reset tag for virtual to physical address conversions
mm/execmem: Untag addresses in EXECMEM_ROX related pointer arithmetic
x86/mm: Use physical address comparisons in fill_p*d/pte
x86/kasan: Initialize KASAN raw shadow memory
x86/mm: Reset tags in a canonical address helper call
x86/mm: Initialize LAM_SUP
x86: Increase minimal SLAB alignment for KASAN
x86/kasan: Use a logical bit shift for kasan_mem_to_shadow
x86/kasan: Make software tag-based kasan available
Samuel Holland (2):
kasan: sw_tags: Use arithmetic shift for shadow computation
kasan: arm64: x86: Make special tags arch specific
Documentation/arch/arm64/kasan-offsets.sh | 8 ++-
Documentation/arch/x86/x86_64/mm.rst | 10 ++-
Documentation/dev-tools/kasan.rst | 46 +++++++------
MAINTAINERS | 4 +-
arch/arm64/Kconfig | 10 +--
arch/arm64/include/asm/kasan-tags.h | 14 ++++
arch/arm64/include/asm/kasan.h | 7 +-
arch/arm64/include/asm/memory.h | 14 +++-
arch/arm64/include/asm/uaccess.h | 1 +
arch/arm64/mm/Makefile | 2 +
arch/arm64/mm/kasan_init.c | 7 +-
arch/arm64/mm/kasan_sw_tags.c | 35 ++++++++++
arch/x86/Kconfig | 4 ++
arch/x86/boot/compressed/misc.h | 1 +
arch/x86/include/asm/cache.h | 4 ++
arch/x86/include/asm/kasan-tags.h | 9 +++
arch/x86/include/asm/kasan.h | 79 ++++++++++++++++++++++-
arch/x86/include/asm/page.h | 8 +++
arch/x86/include/asm/page_64.h | 1 +
arch/x86/kernel/head_64.S | 3 +
arch/x86/mm/init.c | 3 +
arch/x86/mm/init_64.c | 11 ++--
arch/x86/mm/kasan_init_64.c | 24 ++++++-
arch/x86/mm/maccess.c | 2 +-
arch/x86/mm/physaddr.c | 2 +
include/linux/kasan-tags.h | 21 ++++--
include/linux/kasan.h | 13 ++--
include/linux/mm.h | 6 +-
include/linux/mmzone.h | 2 +-
include/linux/page-flags-layout.h | 9 +--
lib/Kconfig.kasan | 3 +-
mm/execmem.c | 9 ++-
mm/kasan/kasan.h | 7 ++
mm/kasan/report.c | 15 ++++-
mm/vmalloc.c | 7 +-
scripts/Makefile.kasan | 3 +
scripts/gdb/linux/kasan.py | 5 +-
scripts/gdb/linux/mm.py | 5 +-
38 files changed, 340 insertions(+), 74 deletions(-)
create mode 100644 arch/arm64/include/asm/kasan-tags.h
create mode 100644 arch/arm64/mm/kasan_sw_tags.c
create mode 100644 arch/x86/include/asm/kasan-tags.h
--
2.53.0
^ permalink raw reply
* Re: [PATCH v2] docs: maintainer-pgp-guide.rst: updated kernel.org link
From: Konstantin Ryabitsev @ 2026-02-03 14:48 UTC (permalink / raw)
To: Amitabh Srivastava; +Cc: corbet, workflows, linux-doc, linux-kernel
In-Reply-To: <20260203050020.27792-1-amitabh@amidevlab.com>
On Tue, Feb 03, 2026 at 10:29:48AM +0530, Amitabh Srivastava wrote:
> docs: process: maintainer-pgp-guide.rst: updated the http link for
I missed this the last time, but you don't need to duplicate the "docs:
process:..." line here.
> 'add the kernel.org UID to your key'. Added SPDX-License-Identifier
> to fix checkpatch.pl warning. Tested kernel using qemu-system-aarch64
You don't need to mention how you tested it (great that you did, but it
doesn't need to be in the commit).
> with busybox inside a multipass ubuntu VM on macos.
I suggest that your submission should look like this:
Subject: docs: process: maintainer-pgp-guide: update kernel.org docs link
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: ...
This has the following improvements:
- removes duplicate info that is already in the subject
- uses imperative mood that is required for commits (update vs updated)
see: https://docs.kernel.org/process/submitting-patches.html#describe-your-changes
> Signed-off-by: Amitabh Srivastava <amitabh@amidevlab.com>
> Reviewed-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
You shouldn't do this -- I didn't actually reply with a "Reviewed-by"
trailer. These trailers are given by the reviewer to indicate "I have reviewed
this and didn't find any problems with the patch. You should only add trailers
that you have actually received from reviewers.
Please send a v3 with these fixes and that should earn you a "Reviewed-by."
Best regards,
--
KR
^ permalink raw reply
* [PATCH v2] docs: maintainer-pgp-guide.rst: updated kernel.org link
From: Amitabh Srivastava @ 2026-02-03 4:59 UTC (permalink / raw)
To: corbet
Cc: workflows, linux-doc, linux-kernel, Amitabh Srivastava,
Konstantin Ryabitsev
docs: process: maintainer-pgp-guide.rst: updated the http link for
'add the kernel.org UID to your key'. Added SPDX-License-Identifier
to fix checkpatch.pl warning. Tested kernel using qemu-system-aarch64
with busybox inside a multipass ubuntu VM on macos.
Signed-off-by: Amitabh Srivastava <amitabh@amidevlab.com>
Reviewed-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
---
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
* Re: [PATCH] docs: maintainer-pgp-guide.rst: updated a kernel.org link
From: Konstantin Ryabitsev @ 2026-02-02 20:40 UTC (permalink / raw)
To: Amitabh Srivastava
Cc: corbet, workflows, linux-doc, linux-kernel, Amitabh Srivastava
In-Reply-To: <20260202193755.41863-1-amitabh@amidevlab.com>
On Tue, 03 Feb 2026 01:07:27 +0530, Amitabh Srivastava <amitabh@amidevlab.com> wrote:
> Signed-off-by: Amitabh Srivastava <amitabh@amidevlab.com>
>
> docs: process: maintainer-pgp-guide.rst: updated the http link for
> 'add the kernel.org UID to your key'. Added SPDX-License-Identifier
> to fix checkpatch.pl warning.
Your Signed-off-by should be at the bottom of the commit message, not at
the top.
Other than that, no objections, but it requires a v2, I think.
--
KR
^ permalink raw reply
* [PATCH] docs: maintainer-pgp-guide.rst: updated a kernel.org link
From: Amitabh Srivastava @ 2026-02-02 19:37 UTC (permalink / raw)
To: corbet; +Cc: workflows, linux-doc, linux-kernel, Amitabh Srivastava
Signed-off-by: Amitabh Srivastava <amitabh@amidevlab.com>
docs: process: maintainer-pgp-guide.rst: updated the http link for
'add the kernel.org UID to your key'. Added SPDX-License-Identifier
to fix checkpatch.pl warning.
---
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
* Re: [PATCH v2] doc: development-process: add notice on testing
From: Jonathan Corbet @ 2026-02-02 17:02 UTC (permalink / raw)
To: Dmitry Antipov, Andy Shevchenko, Randy Dunlap
Cc: workflows, linux-doc, Dmitry Antipov
In-Reply-To: <20260123071523.1392729-1-dmantipov@yandex.ru>
Dmitry Antipov <dmantipov@yandex.ru> writes:
> Add testing notice to "Before creating patches" section.
>
> Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com>
> Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
> ---
> v2: adjust spelling and wording according to Randy
> ---
> Documentation/process/5.Posting.rst | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
Applied, thanks.
jon
^ permalink raw reply
* Re: Hosting first-party kernel.org container images
From: Ben Copeland @ 2026-02-02 12:07 UTC (permalink / raw)
To: Guillaume Tucker
Cc: Arnd Bergmann, Konstantin Ryabitsev, Nathan Chancellor,
Miguel Ojeda, Onur Özkan, linux-kernel@vger.kernel.org,
workflows, automated-testing
In-Reply-To: <cc737636-2a43-4a97-975e-4725733f7ee4@gtucker.io>
Hello Guillaume,
On Fri, 19 Dec 2025 at 13:37, Guillaume Tucker <gtucker@gtucker.io> wrote:
>
> Hi Konstantin, Arnd et al,
>
> This is a follow-up from the series about adding a scripts/container
> tool [1] to run kernel builds in containers. As per the discussion
> at Plumbers last year and the summary I put in a blog post [2], it
> would be great to have container images with kernel.org toolchains
> hosted upstream. This can mean several things, so let's break it
> down into a set of potential options to choose from:
>
>
> * Containerfiles Git repository
>
> There is currently a PoC repository on GitLab with a Makefile and a
> number of Containerfiles to build a set of images:
>
> https://gitlab.com/gtucker/korg-containers
TuxMake already provides container images with kernel.org toolchains
(korg-gcc 8-15, korg-clang 11-22). The Dockerfiles are maintained at
[1]
Since TuxMake is now part of KernelCI and already referenced in the
kernel documentation you pushed [2], it seems like a natural home for
this rather than starting fresh, or having two places for images.
>
> It can be improved in many ways since this is an early PoC. The key
> decision to make here, if we do want to have container images
> supported upstream, is how to manage these files or a derived
> implementation.
>
> One option is to add it to the kernel tree itself under e.g.
> tools/container.
>
> Another option is to add a separate repository on git.kernel.org,
> which I believe would be a better approach as there aren't any direct
> dependencies on the kernel tree itself.
>
> A third option might be to keep it alongside any recipes used to
> produce the existing kernel.org toolchain tarballs although I'm not
> entirely sure how that's managed - something for Arnd to judge I
> guess.
>
> A last option would be to keep it on GitLab or move it to GitHub
> which would provide some CI/CD tools for building the images but I
> doubt this is something viable for the kernel community as it would
> create some vendor lock-in.
>
>
> * Container image registry
>
> This is where things get a bit more complicated. As far as I'm
> aware, there aren't any container registries hosted in the kernel.org
> infrastructure at the moment. A classic option would be to push the
> images to an established one e.g. Docker Hub (docker.io) or the
> Google Artifact Registry. GitLab and GitHub also provide theirs of
> course. I believe there is still a free plan for community projects
> to host images on docker.io and that would be the easiest from a user
> point of view e.g. "docker pull kernel.org/gcc". It comes with some
> maintenance burden of course, and Docker Hub has a history of
> changing its policies quite unexpectedly so it's not entirely
> future-proof.
The images are hosted on Docker Hub (https://hub.docker.com/u/tuxmake)
with ECR Public as fallback:
docker pull tuxmake/arm64_korg-gcc-14
docker pull tuxmake/x86_64_korg-clang-22
Happy to discuss how we can align efforts here. But to me, it makes
sense for KernelCI to be the place for these images (or for us to have
a single place and a single set of images).
[1] https://github.com/kernelci/tuxmake/tree/master/support/docker
[2] https://www.kernel.org/doc/html/next/dev-tools/container.html
Regards,
Ben
>
> A classic alternative would be to host a dedicated service
> e.g. registry.kernel.org and have the images managed there. This
> would obviously involve higher sysadmin efforts and add scalability
> issues but would decouple it from external providers.
>
> Then a third option would be to host the container images as OCI
> tarball dumps alongside the toolchain tarballs. They can then be
> downloaded and imported with "docker image load" or any other
> container runtime. The only infrastructure resources needed would be
> storage space. This is of course suboptimal as all the layers get
> bundled together and users would have to manage these images
> themselves, but it's very effective from a kernel.org sysadmin point
> of view.
>
>
> There are undoubtedly other ways to look at this, I'm curious to know
> what people think. The benefits of having readily-available
> container images upstream appear to be pretty clear, several
> maintainers have expressed their support already. It's all down to
> how much these benefits can outweigh the upstream maintenance costs.
> Maybe this can be done in two steps, first with just the
> Containerfiles and later on a full solution to host the actual
> images.
>
> Best wishes,
> Guillaume
>
> [1] https://lore.kernel.org/all/cover.1766061692.git.gtucker@gtucker.io/
> [2] https://gtucker.io/posts/2024-09-30-korg-containers/
^ permalink raw reply
* Re: [PATCH v3 0/2] scripts: introduce containerized builds
From: Guillaume Tucker @ 2026-01-31 13:36 UTC (permalink / raw)
To: Nicolas Schier
Cc: Nathan Chancellor, Miguel Ojeda, David Gow, Onur Özkan,
Arnd Bergmann, linux-kernel, rust-for-linux, linux-kbuild,
automated-testing, workflows, llvm
In-Reply-To: <aXkceKDeYxUGHLQh@levanger>
Hi Nicolas,
On 27/01/2026 9:13 pm, Nicolas Schier wrote:
> On Thu, Jan 22, 2026 at 03:12:36PM +0100, Guillaume Tucker wrote:
>> Hi Nicolas,
>>
>> On 20/01/2026 14:54, Nicolas Schier wrote:
>>> Out-of-source builds do not work on my system with podman. If this is
>>> expected, I think it would be great to mention that somewhere in the
>>> documentation.
>>
>> The v4 now mentions this and also includes a trick using bind-mount:
>>
>> mkdir -p $HOME/tmp/my-kernel-build
>> mkdir -p build
>> sudo mount --bind $HOME/tmp/my-kernel-build build
>> scripts/container -i kernel.org/gcc -- make mrproper
>> scripts/container -i kernel.org/gcc -- make O=build defconfig
>> scripts/container -i kernel.org/gcc -- make O=build -j$(nproc)
>>
>> Would this work for your use-case? Directory names are entirely
>> arbitrary. It's not ideal but might be good enough as a workaround
>> until this gets properly supported by the tool in a future version.
>
> sorry for the long delay. Yes, thanks for the follow-up!
Great! Thank you for confirming. It's now in linux-next.
Cheers,
Guillaume
^ permalink raw reply
* Re: [PATCH v4 0/2] scripts: introduce containerized builds
From: Nathan Chancellor @ 2026-01-30 0:10 UTC (permalink / raw)
To: Nathan Chancellor, Nicolas Schier, Miguel Ojeda, David Gow,
Onur Özkan, Guillaume Tucker
Cc: Arnd Bergmann, linux-kernel, rust-for-linux, linux-kbuild,
automated-testing, workflows, llvm
In-Reply-To: <cover.1769090419.git.gtucker@gtucker.io>
On Thu, 22 Jan 2026 15:06:58 +0100, Guillaume Tucker wrote:
> This proposal emerged from discussions over email and after a talk at
> Plumbers 2024:
>
> https://lore.kernel.org/all/affb7aff-dc9b-4263-bbd4-a7965c19ac4e@gtucker.io/
>
> The aim is to facilitate reproducing builds for CI bots as well as
> developers using containers. Here's an illustrative example with a
> kernel.org toolchain in a Docker image from tuxmake:
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux.git kbuild-next
Thanks!
[1/2] scripts: add tool to run containerized builds
(no commit info)
[2/2] Documentation: dev-tools: add container.rst page
(no commit info)
Please look out for regression or issue reports or other follow up
comments, as they may result in the patch/series getting dropped or
reverted. Patches applied to an "unstable" branch are accepted pending
wider testing in -next and any post-commit review; they will generally
be moved to the main branch in a week if no issues are found.
Best regards,
--
Nathan Chancellor <nathan@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 0/2] scripts: introduce containerized builds
From: Nicolas Schier @ 2026-01-27 20:13 UTC (permalink / raw)
To: Guillaume Tucker
Cc: Nathan Chancellor, Miguel Ojeda, David Gow, Onur Özkan,
Arnd Bergmann, linux-kernel, rust-for-linux, linux-kbuild,
automated-testing, workflows, llvm
In-Reply-To: <56209dbc-2dbe-4f52-a703-bcbd9ed3e712@gtucker.io>
On Thu, Jan 22, 2026 at 03:12:36PM +0100, Guillaume Tucker wrote:
> Hi Nicolas,
>
> On 20/01/2026 14:54, Nicolas Schier wrote:
> > Out-of-source builds do not work on my system with podman. If this is
> > expected, I think it would be great to mention that somewhere in the
> > documentation.
>
> The v4 now mentions this and also includes a trick using bind-mount:
>
> mkdir -p $HOME/tmp/my-kernel-build
> mkdir -p build
> sudo mount --bind $HOME/tmp/my-kernel-build build
> scripts/container -i kernel.org/gcc -- make mrproper
> scripts/container -i kernel.org/gcc -- make O=build defconfig
> scripts/container -i kernel.org/gcc -- make O=build -j$(nproc)
>
> Would this work for your use-case? Directory names are entirely
> arbitrary. It's not ideal but might be good enough as a workaround
> until this gets properly supported by the tool in a future version.
sorry for the long delay. Yes, thanks for the follow-up!
Kind regards,
Nicolas
^ permalink raw reply
* [PATCH v4] docs: clarify CC list guidance wording
From: John Ashrith @ 2026-01-26 4:22 UTC (permalink / raw)
To: workflows; +Cc: jonathan, gregkh, linux-doc
From 1de01779d580e104bea0148409c3c8c76d204c41 Mon Sep 17 00:00:00 2001
From: John Ashrith <johnashrith6@gmail.com>
Date: Sun, 25 Jan 2026 14:48:28 +0000
Subject: [PATCH] docs: clarify CC list guidance wording
Clarify that recipients should not be removed from the CC list without a
good reason, and that replies should not be sent only to the list address.
This avoids ambiguity in the guidance.
Signed-off-by: John Ashrith <johnashrith6@gmail.com>
---
v4:
- Add changelog text to the commit message
- Ensure patch is sent as text/plain without mail client mangling
- Place version notes below the --- line
Documentation/process/howto.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/process/howto.rst
b/Documentation/process/howto.rst
index 9438e03d6..5a29111d6 100644
--- a/Documentation/process/howto.rst
+++ b/Documentation/process/howto.rst
@@ -403,7 +403,7 @@ interacting with the list (or any list):
If multiple people respond to your mail, the CC: list of recipients may
get pretty large. Don't remove anybody from the CC: list without a good
-reason, or don't reply only to the list address. Get used to receiving the
+reason, and don't reply only to the list address. Get used to receiving the
mail twice, one from the sender and the one from the list, and don't try
to tune that by adding fancy mail-headers, people will not like it.
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v4] docs: clarify CC list guidance wording
From: Jonathan Corbet @ 2026-01-25 18:40 UTC (permalink / raw)
To: John Ashrith, workflows; +Cc: gregkh, linux-doc
In-Reply-To: <0bb5ad12-dd5a-4280-bf6e-7d1ddb59dd9e@gmail.com>
John Ashrith <johnashrith6@gmail.com> writes:
> Changes since v3:
> - Add proper changelog text
> - Move version notes below the --- line
> - Send as plain text to avoid mail client mangling
>
> From 1de01779d580e104bea0148409c3c8c76d204c41 Mon Sep 17 00:00:00 2001
> From: John Ashrith <johnashrith6@gmail.com>
> Date: Sun, 25 Jan 2026 14:48:28 +0000
> Subject: [PATCH] docs: clarify CC list guidance wording
Again ... the above text should not be in the changelog. I can
certainly edit it out on applying the patch, but you really need to find
a way to send patches that don't make maintainers do extra work.
I'll say again: please practice sending to yourself until this comes out
right, then resend your patch to the lists.
Thanks,
jon
^ permalink raw reply
* [PATCH v4] docs: clarify CC list guidance wording
From: John Ashrith @ 2026-01-25 16:21 UTC (permalink / raw)
To: workflows; +Cc: gregkh, corbet, linux-doc
Changes since v3:
- Add proper changelog text
- Move version notes below the --- line
- Send as plain text to avoid mail client mangling
From 1de01779d580e104bea0148409c3c8c76d204c41 Mon Sep 17 00:00:00 2001
From: John Ashrith <johnashrith6@gmail.com>
Date: Sun, 25 Jan 2026 14:48:28 +0000
Subject: [PATCH] docs: clarify CC list guidance wording
Clarify that recipients should not be removed from the CC list without a
good reason, and that replies should not be sent only to the list address.
This avoids ambiguity in the guidance.
Signed-off-by: John Ashrith <johnashrith6@gmail.com>
---
v4:
- Add changelog text to the commit message
- Ensure patch is sent as text/plain without mail client mangling
- Place version notes below the --- line
Documentation/process/howto.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/process/howto.rst
b/Documentation/process/howto.rst
index 9438e03d6..5a29111d6 100644
--- a/Documentation/process/howto.rst
+++ b/Documentation/process/howto.rst
@@ -403,7 +403,7 @@ interacting with the list (or any list):
If multiple people respond to your mail, the CC: list of recipients may
get pretty large. Don't remove anybody from the CC: list without a good
-reason, or don't reply only to the list address. Get used to receiving the
+reason, and don't reply only to the list address. Get used to receiving the
mail twice, one from the sender and the one from the list, and don't try
to tune that by adding fancy mail-headers, people will not like it.
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v3] docs: clarify CC list guidance wording
From: Greg KH @ 2026-01-25 15:25 UTC (permalink / raw)
To: john ashrith6; +Cc: workflows, corbet, linux-doc, linux-kernel
In-Reply-To: <CABoKZAD+694qPMAjgvJKfHdNYbwygsjp5NmowVA5hv63Z8823w@mail.gmail.com>
On Sun, Jan 25, 2026 at 08:31:07PM +0530, john ashrith6 wrote:
> Removed the extra Signed-off-by so that only my real name remains.
>
> Thanks for the review.
>
> >From ed7f4bb8c6e46f76c1a02e91172402b7389ecb5d Mon Sep 17 00:00:00 2001
> From: John Ashrith <johnashrith6@gmail.com>
> Date: Sun, 25 Jan 2026 14:48:28 +0000
> Subject: [PATCH] docs: clarify CC list guidance wording
>
> Signed-off-by: John Ashrith <johnashrith6@gmail.com>
Odd, this is showing up in a strange way. Perhaps just use 'git
send-email' to send the patch out?
Also, you need some changelog text, for obvious reasons you don't want
us to take it without it.
Also, the versioning of the patch goes below the --- line, as the
documentation asks for. Perhaps fix that up for v4?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v3] docs: clarify CC list guidance wording
From: Jonathan Corbet @ 2026-01-25 15:16 UTC (permalink / raw)
To: john ashrith6, workflows; +Cc: gregkh, linux-doc, linux-kernel
In-Reply-To: <CABoKZAAdwO=pm1-GsP=09PkCGs5HT8K=1Y72LJvKCRUFJD38JQ@mail.gmail.com>
john ashrith6 <johnashrith6@gmail.com> writes:
> Removed the extra Signed-off-by so that only my real name remains.
>
> Thanks for the review.
>
> From ed7f4bb8c6e46f76c1a02e91172402b7389ecb5d Mon Sep 17 00:00:00 2001
> From: John Ashrith <johnashrith6@gmail.com>
> Date: Sun, 25 Jan 2026 14:48:28 +0000
> Subject: [PATCH] docs: clarify CC list guidance wording
The above stuff still needs to not be in the changelog body.
Also ... as long as you send HTML mail you will not reach the lists.
Please work on sending to yourself until you get something that comes
through correctly.
> Signed-off-by: John Ashrith <johnashrith6@gmail.com>
> ---
> Documentation/process/howto.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/process/howto.rst b/Documentation/process/howto.rst
> index 9438e03d6..5a29111d6 100644
> --- a/Documentation/process/howto.rst
> +++ b/Documentation/process/howto.rst
> @@ -403,7 +403,7 @@ interacting with the list (or any list):
>
> If multiple people respond to your mail, the CC: list of recipients may
> get pretty large. Don't remove anybody from the CC: list without a good
> -reason, or don't reply only to the list address. Get used to receiving the
> +reason, and don't reply only to the list address. Get used to receiving the
> mail twice, one from the sender and the one from the list, and don't try
The change itself looks fine.
Thanks,
jon
^ permalink raw reply
* [PATCH v2] docs: clarify CC list guidance wording
From: john ashrith6 @ 2026-01-25 14:51 UTC (permalink / raw)
To: workflows; +Cc: gregkh, corbet, linux-doc, linux-kernel
Updated the author and Signed-off-by to use my real name and removed
the patch header duplication from the email body.
Thanks for the feedback.
^ permalink raw reply
* Re: [PATCH] docs: clarify CC list guidance wording
From: Greg KH @ 2026-01-25 14:39 UTC (permalink / raw)
To: john ashrith6; +Cc: workflows, corbet, linux-doc, linux-kernel
In-Reply-To: <CABoKZACHObTMAC5FMvhRG3Guev_s_Pys_t3G7LAqF7BTiLD+KQ@mail.gmail.com>
On Sun, Jan 25, 2026 at 08:08:08PM +0530, john ashrith6 wrote:
> This patch clarifies wording in the CC list guidance to avoid ambiguity.
>
> No functional changes intended.
>
> >From 416237c2cea7ccb4fa863ebc260777ea102b2b62 Mon Sep 17 00:00:00 2001
> From: JAR2004re <johnashrith6@gmail.com>
> Date: Sun, 25 Jan 2026 14:17:13 +0000
> Subject: [PATCH] docs: clarify CC list guidance wording
No need for this to be in the body of the email/changelog.
> Signed-off-by: JAR2004re <johnashrith6@gmail.com>
Please use your name here, not your alias.
thanks,
greg k-h
^ permalink raw reply
* [PATCH] docs: clarify CC list guidance wording
From: john ashrith6 @ 2026-01-25 14:38 UTC (permalink / raw)
To: workflows; +Cc: corbet, linux-doc, linux-kernel
This patch clarifies wording in the CC list guidance to avoid ambiguity.
No functional changes intended.
From 416237c2cea7ccb4fa863ebc260777ea102b2b62 Mon Sep 17 00:00:00 2001
From: JAR2004re <johnashrith6@gmail.com>
Date: Sun, 25 Jan 2026 14:17:13 +0000
Subject: [PATCH] docs: clarify CC list guidance wording
Signed-off-by: JAR2004re <johnashrith6@gmail.com>
---
Documentation/process/howto.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/process/howto.rst b/Documentation/process/howto.rst
index 9438e03d6..5a29111d6 100644
--- a/Documentation/process/howto.rst
+++ b/Documentation/process/howto.rst
@@ -403,7 +403,7 @@ interacting with the list (or any list):
If multiple people respond to your mail, the CC: list of recipients may
get pretty large. Don't remove anybody from the CC: list without a good
-reason, or don't reply only to the list address. Get used to receiving the
+reason, and don't reply only to the list address. Get used to receiving the
mail twice, one from the sender and the one from the list, and don't try
to tune that by adding fancy mail-headers, people will not like it.
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] [v6] Documentation: Provide guidelines for tool-generated content
From: Steven Rostedt @ 2026-01-23 15:30 UTC (permalink / raw)
To: Dave Hansen
Cc: linux-kernel, Shuah Khan, Kees Cook, Greg Kroah-Hartman,
Miguel Ojeda, Luis Chamberlain, SeongJae Park, Dan Williams,
Paul E . McKenney, Simon Glass, Lee Jones, Lorenzo Stoakes,
NeilBrown, Theodore Ts'o, Sasha Levin, Jonathan Corbet,
Vlastimil Babka, workflows, ksummit
In-Reply-To: <20260119200418.89541-1-dave.hansen@linux.intel.com>
On Mon, 19 Jan 2026 12:04:18 -0800
Dave Hansen <dave.hansen@linux.intel.com> wrote:
I decided to go over it one last time.
> +
> +Out of Scope
> +============
> +
> +These guidelines do not apply to tools that make trivial tweaks to
> +preexisting content. Nor do they pertain to tooling that helps with
> +menial tasks. Some examples:
> +
> + - Spelling and grammar fix ups, like rephrasing to imperative voice
> + - Typing aids like identifier completion, common boilerplate or
> + trivial pattern completion
> + - Purely mechanical transformations like variable renaming
> + - Reformatting, like running Lindent, ``clang-format`` or
> + ``rust-fmt``
> +
> +Even whenever your tool use is out of scope, you should still always
Somehow the above reads really weird to me. "Even whenever your tool use is
out of scope". Do you mean "Even when your tool use is out of scope" ?
> +consider if it would help reviewing your contribution if the reviewer
> +knows about the tool that you used.
> +
Other than that, LGTM!
Thanks,
-- Steve
^ permalink raw reply
* Re: [PATCH v2] doc: development-process: add notice on testing
From: Andy Shevchenko @ 2026-01-23 10:50 UTC (permalink / raw)
To: Randy Dunlap; +Cc: Dmitry Antipov, Jonathan Corbet, workflows, linux-doc
In-Reply-To: <d9147abf-0b08-40e2-aa49-821c953f5fc7@infradead.org>
On Thu, Jan 22, 2026 at 11:19:48PM -0800, Randy Dunlap wrote:
> On 1/22/26 11:15 PM, Dmitry Antipov wrote:
> > Add testing notice to "Before creating patches" section.
> >
> > Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com>
> > Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
>
> Acked-by: Randy Dunlap <rdunlap@infradead.org>
>
> Andy also Acked it. I think you could/should include
s/could// --> should
> his Ack here as well.
Yes. Carrying on the given tags is the author's responsibility.
Otherwise, you should explain clearly why the given tag is not
taking into account.
For this time I do it myself again, but next time don't forget doing that,
please.
Acked-by: Andy Shevchenko <andriy.shevchenko@intel.com>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2] doc: development-process: add notice on testing
From: Randy Dunlap @ 2026-01-23 7:19 UTC (permalink / raw)
To: Dmitry Antipov, Andy Shevchenko, Jonathan Corbet; +Cc: workflows, linux-doc
In-Reply-To: <20260123071523.1392729-1-dmantipov@yandex.ru>
On 1/22/26 11:15 PM, Dmitry Antipov wrote:
> Add testing notice to "Before creating patches" section.
>
> Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com>
> Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Andy also Acked it. I think you could/should include
his Ack here as well.
Thanks.
> ---
> v2: adjust spelling and wording according to Randy
> ---
> Documentation/process/5.Posting.rst | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/process/5.Posting.rst b/Documentation/process/5.Posting.rst
> index 9999bcbdccc9..07d7dbed13ec 100644
> --- a/Documentation/process/5.Posting.rst
> +++ b/Documentation/process/5.Posting.rst
> @@ -40,7 +40,12 @@ sending patches to the development community. These include:
> - Test the code to the extent that you can. Make use of the kernel's
> debugging tools, ensure that the kernel will build with all reasonable
> combinations of configuration options, use cross-compilers to build for
> - different architectures, etc.
> + different architectures, etc. Add tests, likely using an existing
> + testing framework like KUnit, and include them as a separate member
> + of your series (see the next section for more about patch series).
> + Note that this may be mandatory when affecting some subsystems. For
> + example, library functions (resides under lib/) are extensively used
> + almost everywhere and expected to be tested appropriately.
>
> - Make sure your code is compliant with the kernel coding style
> guidelines.
--
~Randy
^ permalink raw reply
* [PATCH v2] doc: development-process: add notice on testing
From: Dmitry Antipov @ 2026-01-23 7:15 UTC (permalink / raw)
To: Andy Shevchenko, Jonathan Corbet, Randy Dunlap
Cc: workflows, linux-doc, Dmitry Antipov
In-Reply-To: <658caf3b-aeb6-49c7-9e5a-1eab175dd1b3@infradead.org>
Add testing notice to "Before creating patches" section.
Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
---
v2: adjust spelling and wording according to Randy
---
Documentation/process/5.Posting.rst | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/Documentation/process/5.Posting.rst b/Documentation/process/5.Posting.rst
index 9999bcbdccc9..07d7dbed13ec 100644
--- a/Documentation/process/5.Posting.rst
+++ b/Documentation/process/5.Posting.rst
@@ -40,7 +40,12 @@ sending patches to the development community. These include:
- Test the code to the extent that you can. Make use of the kernel's
debugging tools, ensure that the kernel will build with all reasonable
combinations of configuration options, use cross-compilers to build for
- different architectures, etc.
+ different architectures, etc. Add tests, likely using an existing
+ testing framework like KUnit, and include them as a separate member
+ of your series (see the next section for more about patch series).
+ Note that this may be mandatory when affecting some subsystems. For
+ example, library functions (resides under lib/) are extensively used
+ almost everywhere and expected to be tested appropriately.
- Make sure your code is compliant with the kernel coding style
guidelines.
--
2.52.0
^ permalink raw reply related
* Re: [PATCH v4 1/2] scripts: add tool to run containerized builds
From: Nicolas Schier @ 2026-01-22 19:57 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Guillaume Tucker, Onur Özkan, Miguel Ojeda, David Gow,
Arnd Bergmann, linux-kernel, rust-for-linux, linux-kbuild,
automated-testing, workflows, llvm
In-Reply-To: <20260122184939.GA3461196@ax162>
On Thu, Jan 22, 2026 at 11:49:39AM -0700, Nathan Chancellor wrote:
> On Thu, Jan 22, 2026 at 03:59:54PM +0100, Guillaume Tucker wrote:
> > --- a/scripts/container
> > +++ b/scripts/container
> > @@ -120,7 +120,7 @@ class Runtimes:
> > if not runtime.is_present():
> > raise ValueError(f"runtime not found: {name}")
> > return runtime
> > - raise ValueError(f"unknown runtime: {runtime}")
> > + raise ValueError(f"unknown runtime: {name}")
> >
> > @classmethod
> > def find(cls):
> >
> >
> > Nathan, would you be OK with folding this in or should I send a v5?
>
> I can fold that in, thanks.
>
> I will carry forward Nicolas's ack and testing tags from v3, as this
> revision is not substantially different from what he looked at and
> tested.
thanks!
Kind regards,
Nicolas
^ permalink raw reply
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