* 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 v6 4/5] slab: Introduce kmalloc_flex() and family
From: Lorenzo Stoakes @ 2026-02-24 10:26 UTC (permalink / raw)
To: Kees Cook
Cc: Vlastimil Babka, Jonathan Corbet, Andrew Morton,
Christoph Lameter, David Rientjes, Roman Gushchin, Harry Yoo,
Gustavo A. R. Silva, workflows, linux-doc, linux-mm,
linux-hardening, Linus Torvalds, Randy Dunlap, Miguel Ojeda,
Przemek Kitszel, Matthew Wilcox, John Hubbard, Joe Perches,
Christoph Lameter, Marco Elver, Vegard Nossum, Pekka Enberg,
Joonsoo Kim, Bill Wendling, Justin Stitt, Jann Horn,
Greg Kroah-Hartman, Sasha Levin, Nathan Chancellor,
Peter Zijlstra, Nick Desaulniers, Jakub Kicinski, Yafang Shao,
Tony Ambardar, Alexander Lobakin, Jan Hendrik Farr,
Alexander Potapenko, linux-kernel, llvm
In-Reply-To: <20251203233036.3212363-4-kees@kernel.org>
On Wed, Dec 03, 2025 at 03:30:34PM -0800, Kees Cook wrote:
> As done for kmalloc_obj*(), introduce a type-aware allocator for flexible
> arrays, which may also have "counted_by" annotations:
>
> ptr = kmalloc(struct_size(ptr, flex_member, count), gfp);
>
> becomes:
>
> ptr = kmalloc_flex(*ptr, flex_member, count, gfp);
>
> The internal use of __flex_counter() allows for automatically setting
> the counter member of a struct's flexible array member when it has
> been annotated with __counted_by(), avoiding any missed early size
> initializations while __counted_by() annotations are added to the
> kernel. Additionally, this also checks for "too large" allocations based
> on the type size of the counter variable. For example:
>
> if (count > type_max(ptr->flex_counter))
> fail...;
> size = struct_size(ptr, flex_member, count);
> ptr = kmalloc(size, gfp);
> ptr->flex_counter = count;
>
> becomes (n.b. unchanged from earlier example):
>
> ptr = kmalloc_flex(*ptr, flex_member, count, gfp);
> ptr->flex_count = count;
>
> Note that manual initialization of the flexible array counter is still
> required (at some point) after allocation as not all compiler versions
> support the __counted_by annotation yet. But doing it internally makes
> sure they cannot be missed when __counted_by _is_ available, meaning
> that the bounds checker will not trip due to the lack of "early enough"
> initializations that used to work before enabling the stricter bounds
> checking. For example:
>
> ptr = kmalloc_flex(*ptr, flex_member, count, gfp);
> fill(ptr->flex, count);
> ptr->flex_count = count;
>
> This works correctly before adding a __counted_by annotation (since
> nothing is checking ptr->flex accesses against ptr->flex_count). After
> adding the annotation, the bounds sanitizer would trip during fill()
> because ptr->flex_count wasn't set yet. But with kmalloc_flex() setting
> ptr->flex_count internally at allocation time, the existing code works
> without needing to move the ptr->flex_count assignment before the call
> to fill(). (This has been a stumbling block for __counted_by adoption.)
>
> Signed-off-by: Kees Cook <kees@kernel.org>
> ---
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: Vlastimil Babka <vbabka@suse.cz>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Christoph Lameter <cl@gentwo.org>
> Cc: David Rientjes <rientjes@google.com>
> Cc: Roman Gushchin <roman.gushchin@linux.dev>
> Cc: Harry Yoo <harry.yoo@oracle.com>
> Cc: "Gustavo A. R. Silva" <gustavoars@kernel.org>
> Cc: <workflows@vger.kernel.org>
> Cc: <linux-doc@vger.kernel.org>
> Cc: <linux-mm@kvack.org>
> Cc: <linux-hardening@vger.kernel.org>
> ---
> Documentation/process/deprecated.rst | 7 ++++
> include/linux/slab.h | 48 ++++++++++++++++++++++++++++
> 2 files changed, 55 insertions(+)
>
> diff --git a/Documentation/process/deprecated.rst b/Documentation/process/deprecated.rst
> index 91c628fa2d59..fed56864d036 100644
> --- a/Documentation/process/deprecated.rst
> +++ b/Documentation/process/deprecated.rst
> @@ -387,6 +387,7 @@ allocations. For example, these open coded assignments::
> ptr = kzalloc(sizeof(*ptr), gfp);
> ptr = kmalloc_array(count, sizeof(*ptr), gfp);
> ptr = kcalloc(count, sizeof(*ptr), gfp);
> + ptr = kmalloc(struct_size(ptr, flex_member, count), gfp);
> ptr = kmalloc(sizeof(struct foo, gfp);
>
> become, respectively::
> @@ -395,4 +396,10 @@ become, respectively::
> ptr = kzalloc_obj(*ptr, gfp);
> ptr = kmalloc_objs(*ptr, count, gfp);
> ptr = kzalloc_objs(*ptr, count, gfp);
> + ptr = kmalloc_flex(*ptr, flex_member, count, gfp);
> __auto_type ptr = kmalloc_obj(struct foo, gfp);
> +
> +If `ptr->flex_member` is annotated with __counted_by(), the allocation
> +will automatically fail if `count` is larger than the maximum
> +representable value that can be stored in the counter member associated
> +with `flex_member`.
> diff --git a/include/linux/slab.h b/include/linux/slab.h
> index 726457daedbd..2656ea610b68 100644
> --- a/include/linux/slab.h
> +++ b/include/linux/slab.h
> @@ -982,6 +982,33 @@ void *kmalloc_nolock_noprof(size_t size, gfp_t gfp_flags, int node);
> (TYPE *)KMALLOC(__obj_size, GFP); \
> })
>
> +/**
> + * __alloc_flex - Allocate an object that has a trailing flexible array
> + * @KMALLOC: kmalloc wrapper function to use for allocation.
> + * @GFP: GFP flags for the allocation.
> + * @TYPE: type of structure to allocate space for.
> + * @FAM: The name of the flexible array member of @TYPE structure.
> + * @COUNT: how many @FAM elements to allocate space for.
> + *
> + * Returns: Newly allocated pointer to @TYPE with @COUNT-many trailing
> + * @FAM elements, or NULL on failure or if @COUNT cannot be represented
> + * by the member of @TYPE that counts the @FAM elements (annotated via
> + * __counted_by()).
> + */
> +#define __alloc_flex(KMALLOC, GFP, TYPE, FAM, COUNT) \
> +({ \
> + const size_t __count = (COUNT); \
> + const size_t __obj_size = struct_size_t(TYPE, FAM, __count); \
> + TYPE *__obj_ptr; \
> + if (WARN_ON_ONCE(overflows_flex_counter_type(TYPE, FAM, __count))) \
> + __obj_ptr = NULL; \
I wonder if this is correct? Because overflows_flex_counter_type() is:
#define overflows_flex_counter_type(TYPE, FAM, COUNT) \
(!overflows_type(COUNT, typeof_flex_counter(((TYPE *)NULL)->FAM)))
I.e. returns true if overflows_type() returns false, and whose comment states:
* Returns: true if @COUNT can be represented in the @FAM's counter. When
* @FAM is not annotated with __counted_by(), always returns true.
So we warn on when the @COUNT _can_ be represented in @FAM's counter?
I'm seeing the warning for the following:
struct multi_remaps {
unsigned int nr, cap;
long offsets[] __counted_by(cap);
};
...
unsigned int cap;
...
multi = kmalloc_flex(*multi, offsets, cap, gfp);
Surely that ! should not be there?
Annnd now I typed that I realise that Linus fixed this up in mainline and I was
working with a stale version of this file :))
Anyway, I see that the comment isn't fixed up, so I think that's something we
should patch, like:
* Returns: true if @COUNT can be represented in the @FAM's counter. When
* @FAM is not annotated with __counted_by(), always returns true.
->
* Returns: true if @COUNT cannot be represented in the @FAM's counter. When
* @FAM is not annotated with __counted_by(), always returns false.
Cheers, Lorenzo
^ permalink raw reply
* Re: [PATCH v6 4/5] slab: Introduce kmalloc_flex() and family
From: David Laight @ 2026-02-24 11:11 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Kees Cook, Vlastimil Babka, Jonathan Corbet, Andrew Morton,
Christoph Lameter, David Rientjes, Roman Gushchin, Harry Yoo,
Gustavo A. R. Silva, workflows, linux-doc, linux-mm,
linux-hardening, Linus Torvalds, Randy Dunlap, Miguel Ojeda,
Przemek Kitszel, Matthew Wilcox, John Hubbard, Joe Perches,
Christoph Lameter, Marco Elver, Vegard Nossum, Pekka Enberg,
Joonsoo Kim, Bill Wendling, Justin Stitt, Jann Horn,
Greg Kroah-Hartman, Sasha Levin, Nathan Chancellor,
Peter Zijlstra, Nick Desaulniers, Jakub Kicinski, Yafang Shao,
Tony Ambardar, Alexander Lobakin, Jan Hendrik Farr,
Alexander Potapenko, linux-kernel, llvm
In-Reply-To: <675ec547-dac8-465f-b3c9-a0f97c5bdef7@lucifer.local>
On Tue, 24 Feb 2026 10:26:36 +0000
Lorenzo Stoakes <lorenzo.stoakes@oracle.com> wrote:
> On Wed, Dec 03, 2025 at 03:30:34PM -0800, Kees Cook wrote:
...
> > +/**
> > + * __alloc_flex - Allocate an object that has a trailing flexible array
> > + * @KMALLOC: kmalloc wrapper function to use for allocation.
> > + * @GFP: GFP flags for the allocation.
> > + * @TYPE: type of structure to allocate space for.
> > + * @FAM: The name of the flexible array member of @TYPE structure.
> > + * @COUNT: how many @FAM elements to allocate space for.
> > + *
> > + * Returns: Newly allocated pointer to @TYPE with @COUNT-many trailing
> > + * @FAM elements, or NULL on failure or if @COUNT cannot be represented
> > + * by the member of @TYPE that counts the @FAM elements (annotated via
> > + * __counted_by()).
> > + */
> > +#define __alloc_flex(KMALLOC, GFP, TYPE, FAM, COUNT) \
> > +({ \
> > + const size_t __count = (COUNT); \
> > + const size_t __obj_size = struct_size_t(TYPE, FAM, __count); \
> > + TYPE *__obj_ptr; \
> > + if (WARN_ON_ONCE(overflows_flex_counter_type(TYPE, FAM, __count))) \
> > + __obj_ptr = NULL; \
...
> Annnd now I typed that I realise that Linus fixed this up in mainline and I was
> working with a stale version of this file :))
I think someone else mentioned it, but having a WARN_ON_ONCE() is there
is really a bad idea.
The code bloat must be stunning.
I won't ask why the #define parameters are all UPPER CASE.
David
^ permalink raw reply
* Re: [PATCH v6 4/5] slab: Introduce kmalloc_flex() and family
From: Kees Cook @ 2026-02-24 23:45 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Vlastimil Babka, Jonathan Corbet, Andrew Morton,
Christoph Lameter, David Rientjes, Roman Gushchin, Harry Yoo,
Gustavo A. R. Silva, workflows, linux-doc, linux-mm,
linux-hardening, Linus Torvalds, Randy Dunlap, Miguel Ojeda,
Przemek Kitszel, Matthew Wilcox, John Hubbard, Joe Perches,
Christoph Lameter, Marco Elver, Vegard Nossum, Pekka Enberg,
Joonsoo Kim, Bill Wendling, Justin Stitt, Jann Horn,
Greg Kroah-Hartman, Sasha Levin, Nathan Chancellor,
Peter Zijlstra, Nick Desaulniers, Jakub Kicinski, Yafang Shao,
Tony Ambardar, Alexander Lobakin, Jan Hendrik Farr,
Alexander Potapenko, linux-kernel, llvm
In-Reply-To: <675ec547-dac8-465f-b3c9-a0f97c5bdef7@lucifer.local>
On Tue, Feb 24, 2026 at 10:26:36AM +0000, Lorenzo Stoakes wrote:
> Annnd now I typed that I realise that Linus fixed this up in mainline and I was
> working with a stale version of this file :))
>
> Anyway, I see that the comment isn't fixed up, so I think that's something we
> should patch, like:
>
> * Returns: true if @COUNT can be represented in the @FAM's counter. When
> * @FAM is not annotated with __counted_by(), always returns true.
>
> ->
>
> * Returns: true if @COUNT cannot be represented in the @FAM's counter. When
> * @FAM is not annotated with __counted_by(), always returns false.
Yeah, I'm working on fixing this up correctly. I think Linux is right
that we need to put the overflow checking entirely within the counter
setting. That way the checks will only happen for the cases where
counted_by is actually in use.
I am, however, still pondering that the size check (as I _intended_
it, not as it actually manifested), would catch negative sizes (i.e.
negative can't be represented in a size_t -- the default type when the
counter type is unknown) and refuse to allocate, though honestly the
allocator would probably also refuse to allocate them since they would
be very very large when cast back to size_t for the allocation itself.
--
Kees Cook
^ permalink raw reply
* Re: [PATCH] Add short author date to Fixes tag
From: Alejandro Colomar @ 2026-02-25 0:56 UTC (permalink / raw)
To: Steven Rostedt, Greg Kroah-Hartman
Cc: Mark Brown, Sasha Levin, Geert Uytterhoeven, Jacob Keller, Yeking,
kuba, Jonathan Corbet, Theodore Ts'o, Andy Whitcroft,
Joe Perches, Dwaipayan Ray, Lukas Bulwahn, Andrew Morton,
workflows, linux-doc, linux-kernel, tech-board-discuss,
Andrew Lunn
[-- Attachment #1: Type: text/plain, Size: 7322 bytes --]
Hi Steven, Greg,
[I'll reply to several sub-threads at once.]
[Message-ID: <20250113095101.4e0fff91@gandalf.local.home>]
On Mon, Jan 13, 2025 at 09:51:01AM -0500, Steven Rostedt wrote:
> Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > $ git help fixes
> > 'fixes' is aliased to 'show --format='Fixes: %h ("%s")' -s'
>
> Hmm, I've just been manually adding the Fixes tags ;-) That's because when
> I add a fixes tag, I also do a more in depth analysis to make sure the
> commit being tagged is really the cause of the problem. A lot of my fixes
> tags are due to very subtle bugs, and a lot of times its a combination of
> event that happened.
I also precede the generation of the fixes tag with an in-depth
analysis. However, that doesn't conflict with using a git alias to
generate it, once I've reached a conclusion. I use this alias to
generate them, and it's quite handy:
<https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/CONTRIBUTING.d/git#n46>
>
> That said, maybe one day I'll use a script or alias in the future.
[Message-ID: <20250111120935.769ab9a3@gandalf.local.home>]
On Sat, Jan 11, 2025 at 6:08 PM Steven Rostedt <rostedt@goodmis.org> wrote:
> On Fri, 10 Jan 2025 16:21:35 -0800
> Jacob Keller <jacob.e.keller@intel.com> wrote:
>
> > I personally find the date helpful as it can help place a commit without
> > needing to take the extra time to do a lookup.
>
> I've never found dates to be meaningful. I'm always more concerned about
> when a commit was added to mainline. Thus the version where the commit was
> added is very important for me.
Indeed. I agree with this, and it's a quite important difference.
The commit dates are strictly increasing, which means you can use the
date to perform a search of a commit, if there's a collision in the
hash (and possibly in the subject).
I documented this in the man-pages project, where I require the commit
date to appear in Fixes tags.
<https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/CONTRIBUTING.d/patches/trailer#n16>
> This is why I keep a bare clone of Linus's
> tree and commonly do:
>
> $ git describe --contains fd3040b9394c
> v5.19-rc1~159^2~154^2
> $ git describe --contains a76053707dbf
> v5.15-rc1~157^2~376^2~4
>
> I can easily see that a76053707dbf was added in 5.15 and fd3040b9394c was
> added in 5.19. The amount of work needed to add dates to Fixes tags would
> greatly exceed the amount of added work someone would need to do to do the
> above operations if they wanted to know the order of commits.
[Message-ID: <2025011032-gargle-showing-7500@gregkh>]
Greg wrote (Fri, 10 Jan 2025 13:32:22 +0100):
> Please no, you will break all of our tooling and scripts that parse
> these types of fields. The git commit id and commit header is all we
> need to properly determine this type of information, no need to add a
> date in here at all.
>
[...]
>
> So I don't think you need to add a date here. Dates also really do not
> mean much with commits, what matters is what release a commit is in, not
> when it was originally made. We have commits that take years to show up
> in a release, so if you only look at a date, you will be mistaken many
> times as it's not showing what came before what many times (i.e. we
> apply commits out-of-date-order all the time.)
As I said above, I agree that the commit date is the right choice.
Author dates can be out-of-date-order by years. Commit dates are
necessarily in order, though.
[Message-ID: <20250110080331.04645768@gandalf.local.home>]
Steven wrote (Fri, 10 Jan 2025 08:03:31 -0500):
> How can it lead to misjudgment? If you have two or more hashes matching, do
> you really think they'll have the same subjects?
The possibility isn't zero. Statistically, it's quite low. However,
it's non-zero.
$ git log --format=tformat:'%s' | sort | uniq -c | sort | tail
248 Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
263 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6
275 Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
293 Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
314 Merge branch 'akpm' (patches from Andrew)
315 Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net
318 Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
324 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
369 Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
670 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
$ git log --format=tformat:'%s' | grep -v ^Merge | sort | uniq -c | sort | tail
grep: (standard input): binary file matches
22 drm/amd/display: Clean up some inconsistent indenting
25 Auto-update from upstream
26 [ARM] Update mach-types
26 pmdomain: Merge branch fixes into next
30 s390: update defconfigs
32 tools arch x86: Sync the msr-index.h copy with the kernel sources
38 [SPARC64]: Update defconfig.
52 mmc: Merge branch fixes into next
59 drm/i915: Convert wait_for(I915_READ(reg)) to intel_wait_for_register()
62 batman-adv: Start new development cycle
Subjects repeat every now and then, and the entropy in some subjects is
actually quite low.
If you include the commit date in a Fixes tag, then you preclude the
entire possibility of a commit reference clash, because you won't have
two patches committed in the same date with the same subject and same
hash (unless you *really* try)
[Message-ID: <2025011115-energize-edge-c9c7@gregkh>]
Greg wrote (Sat, 11 Jan 2025 06:48:53 +0100):
> And if it isn't long enough, tools like:
> https://lore.kernel.org/r/20241226220555.3540872-1-sashal@kernel.org
> can help figure it out as well.
That uses hash+subject. This may be not enough in some cases (see how
much subjects repeat, in the logs above). And importantly, a fixes tag
may become ambiguous *after* it has been written, so you can't predict
much.
By having a commit date in the Fixes tag, you could even simplify the
script to just do a binary search in case of ambiguity. Let's say I
want to find the following commit (arbitrarily taken from the first
Fixes tag I've found in my copy of linux.git):
a2e459555c5f (2023-08-09; "shmem: stable directory offsets")
We could find it, with a trivial command line. We only even need two
characters of the hash:
$ git log --oneline --after='2023-08-08' --before='2023-08-10' \
| grep ^a2;
a2e459555c5f shmem: stable directory offsets
No need for a huge script to disambiguate. This is even typo-resistant,
as one could eventually find something that is similar enough, if one
had such a field with a typo (in any of the three fields). You'd be
able to search by the other two fields, and two fields should be
_usually_ enough for disambiguating, and the third one could corroborate
the typo.
So, what would you think of having the commit date in commit references
such as Fixes tags?
Have a lovely night!
Alex
--
<https://www.alejandro-colomar.es>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] Add short author date to Fixes tag
From: Alejandro Colomar @ 2026-02-25 0:57 UTC (permalink / raw)
To: Steven Rostedt, Greg Kroah-Hartman
Cc: Mark Brown, Sasha Levin, Geert Uytterhoeven, Jacob Keller, Yeking,
kuba, Jonathan Corbet, Theodore Ts'o, Andy Whitcroft,
Joe Perches, Dwaipayan Ray, Lukas Bulwahn, Andrew Morton,
workflows, linux-doc, linux-kernel, tech-board-discuss,
Andrew Lunn
In-Reply-To: <aZ4_sBIy8rOUL59Q@devuan>
[-- Attachment #1: Type: text/plain, Size: 7951 bytes --]
D'oh! I forgot to add the In-Reply-To tag.
I meant to reply to
<https://lore.kernel.org/all/52541f79-ba1c-49c9-a576-45c3472d1c79@intel.com/T/#mf183db5f382b4a39cf52a4a1d2ca8f96697c312e>
On 2026-02-25T01:56:08+0100, Alejandro Colomar wrote:
> Hi Steven, Greg,
>
> [I'll reply to several sub-threads at once.]
>
>
> [Message-ID: <20250113095101.4e0fff91@gandalf.local.home>]
> On Mon, Jan 13, 2025 at 09:51:01AM -0500, Steven Rostedt wrote:
> > Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> > > $ git help fixes
> > > 'fixes' is aliased to 'show --format='Fixes: %h ("%s")' -s'
> >
> > Hmm, I've just been manually adding the Fixes tags ;-) That's because when
> > I add a fixes tag, I also do a more in depth analysis to make sure the
> > commit being tagged is really the cause of the problem. A lot of my fixes
> > tags are due to very subtle bugs, and a lot of times its a combination of
> > event that happened.
>
> I also precede the generation of the fixes tag with an in-depth
> analysis. However, that doesn't conflict with using a git alias to
> generate it, once I've reached a conclusion. I use this alias to
> generate them, and it's quite handy:
> <https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/CONTRIBUTING.d/git#n46>
>
> >
> > That said, maybe one day I'll use a script or alias in the future.
>
>
> [Message-ID: <20250111120935.769ab9a3@gandalf.local.home>]
> On Sat, Jan 11, 2025 at 6:08 PM Steven Rostedt <rostedt@goodmis.org> wrote:
> > On Fri, 10 Jan 2025 16:21:35 -0800
> > Jacob Keller <jacob.e.keller@intel.com> wrote:
> >
> > > I personally find the date helpful as it can help place a commit without
> > > needing to take the extra time to do a lookup.
> >
> > I've never found dates to be meaningful. I'm always more concerned about
> > when a commit was added to mainline. Thus the version where the commit was
> > added is very important for me.
>
> Indeed. I agree with this, and it's a quite important difference.
> The commit dates are strictly increasing, which means you can use the
> date to perform a search of a commit, if there's a collision in the
> hash (and possibly in the subject).
>
> I documented this in the man-pages project, where I require the commit
> date to appear in Fixes tags.
> <https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/CONTRIBUTING.d/patches/trailer#n16>
>
> > This is why I keep a bare clone of Linus's
> > tree and commonly do:
> >
> > $ git describe --contains fd3040b9394c
> > v5.19-rc1~159^2~154^2
> > $ git describe --contains a76053707dbf
> > v5.15-rc1~157^2~376^2~4
> >
> > I can easily see that a76053707dbf was added in 5.15 and fd3040b9394c was
> > added in 5.19. The amount of work needed to add dates to Fixes tags would
> > greatly exceed the amount of added work someone would need to do to do the
> > above operations if they wanted to know the order of commits.
>
>
> [Message-ID: <2025011032-gargle-showing-7500@gregkh>]
> Greg wrote (Fri, 10 Jan 2025 13:32:22 +0100):
> > Please no, you will break all of our tooling and scripts that parse
> > these types of fields. The git commit id and commit header is all we
> > need to properly determine this type of information, no need to add a
> > date in here at all.
> >
> [...]
> >
> > So I don't think you need to add a date here. Dates also really do not
> > mean much with commits, what matters is what release a commit is in, not
> > when it was originally made. We have commits that take years to show up
> > in a release, so if you only look at a date, you will be mistaken many
> > times as it's not showing what came before what many times (i.e. we
> > apply commits out-of-date-order all the time.)
>
> As I said above, I agree that the commit date is the right choice.
> Author dates can be out-of-date-order by years. Commit dates are
> necessarily in order, though.
>
>
> [Message-ID: <20250110080331.04645768@gandalf.local.home>]
> Steven wrote (Fri, 10 Jan 2025 08:03:31 -0500):
> > How can it lead to misjudgment? If you have two or more hashes matching, do
> > you really think they'll have the same subjects?
>
> The possibility isn't zero. Statistically, it's quite low. However,
> it's non-zero.
>
> $ git log --format=tformat:'%s' | sort | uniq -c | sort | tail
> 248 Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
> 263 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6
> 275 Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
> 293 Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
> 314 Merge branch 'akpm' (patches from Andrew)
> 315 Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net
> 318 Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
> 324 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
> 369 Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
> 670 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
> $ git log --format=tformat:'%s' | grep -v ^Merge | sort | uniq -c | sort | tail
> grep: (standard input): binary file matches
> 22 drm/amd/display: Clean up some inconsistent indenting
> 25 Auto-update from upstream
> 26 [ARM] Update mach-types
> 26 pmdomain: Merge branch fixes into next
> 30 s390: update defconfigs
> 32 tools arch x86: Sync the msr-index.h copy with the kernel sources
> 38 [SPARC64]: Update defconfig.
> 52 mmc: Merge branch fixes into next
> 59 drm/i915: Convert wait_for(I915_READ(reg)) to intel_wait_for_register()
> 62 batman-adv: Start new development cycle
>
> Subjects repeat every now and then, and the entropy in some subjects is
> actually quite low.
>
> If you include the commit date in a Fixes tag, then you preclude the
> entire possibility of a commit reference clash, because you won't have
> two patches committed in the same date with the same subject and same
> hash (unless you *really* try)
>
>
> [Message-ID: <2025011115-energize-edge-c9c7@gregkh>]
> Greg wrote (Sat, 11 Jan 2025 06:48:53 +0100):
> > And if it isn't long enough, tools like:
> > https://lore.kernel.org/r/20241226220555.3540872-1-sashal@kernel.org
> > can help figure it out as well.
>
> That uses hash+subject. This may be not enough in some cases (see how
> much subjects repeat, in the logs above). And importantly, a fixes tag
> may become ambiguous *after* it has been written, so you can't predict
> much.
>
> By having a commit date in the Fixes tag, you could even simplify the
> script to just do a binary search in case of ambiguity. Let's say I
> want to find the following commit (arbitrarily taken from the first
> Fixes tag I've found in my copy of linux.git):
>
> a2e459555c5f (2023-08-09; "shmem: stable directory offsets")
>
> We could find it, with a trivial command line. We only even need two
> characters of the hash:
>
> $ git log --oneline --after='2023-08-08' --before='2023-08-10' \
> | grep ^a2;
> a2e459555c5f shmem: stable directory offsets
>
> No need for a huge script to disambiguate. This is even typo-resistant,
> as one could eventually find something that is similar enough, if one
> had such a field with a typo (in any of the three fields). You'd be
> able to search by the other two fields, and two fields should be
> _usually_ enough for disambiguating, and the third one could corroborate
> the typo.
>
> So, what would you think of having the commit date in commit references
> such as Fixes tags?
>
>
> Have a lovely night!
> Alex
>
> --
> <https://www.alejandro-colomar.es>
--
<https://www.alejandro-colomar.es>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: Hosting first-party kernel.org container images
From: Guillaume Tucker @ 2026-02-25 14:44 UTC (permalink / raw)
To: Ben Copeland, Konstantin Ryabitsev, Miguel Ojeda,
Nathan Chancellor, Nicolas Schier, Arnd Bergmann, Onur Özkan
Cc: linux-kernel@vger.kernel.org, workflows, automated-testing,
kernelci@lists.linux.dev
In-Reply-To: <CAL0q8a7mepGUdgrLsQhCUdLVP8VcxB9x_oBRCWAYNeoVAUb=7A@mail.gmail.com>
+kernelci
On 02/02/2026 13:07, Ben Copeland wrote:
> 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
The scripts/container tool has now been merged so it's on its way to
be part of v7.0:
https://docs.kernel.org/next/dev-tools/container.html
As such, the topic of maintaining first-party container images is
becoming even more relevant.
>> 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.
Thanks Ben for the input here, these sound like very good points and
the situation has improved since the idea of having upstream
containers was first initiated. The TuxMake images are mentioned in
the documentation as they're already available so it made sense in
practice.
>> 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).
Yes, I see the value in consolidating things rather than duplicating
efforts. However, I believe there are still a few good reasons worth
considering for keeping a separate set of images:
* images related to a tool e.g. TuxMake or KernelCI are less likely
to be adopted by developers
CI bots and other services are a subset of the use cases for these
container images, so if they're branded as being tool-specific then
developers will see them as specialised images.
An ideal approach, if there were no images already published
anywhere, would be to have Containerfiles and images coming directly
from kernel.org and then specialised use cases would base their own
tooling on top. I know the current TuxMake images with kernel.org
toolchains don't have TuxMake-specific packages installed in
principle, but they're still branded as TuxMake and it's hard to tell
how they might evolve.
* external projects can have their own agendas
Projects such as TuxMake and KernelCI may decide to host images on
docker.io and code on GitHub for now, which may not be the preferred
choices for the kernel developers' community. Then if the projects
are forced to move hosting because of pricing or limitations, it's
also likely to be for reasons beyond or against the community's best
interests.
Creating those container images isn't particularly challenging in
itself, the main point is to align use cases with a standard set of
images to facilitate reproducible builds across the board. And the
main part of the maintenance work is to keep them up to date,
functional and available. As such, any pre-existing implementation
or hosting solution doesn't seem like a big factor for deciding what
to host and where. Rather, the interests and resources associated
with them are critical. In other words, it's much easier to create a
new repository from scratch on git.kernel.org and implement a new way
of building these images there than having to deal with the ongoing
risks associated with third parties.
This boils things down to a few practical options:
1. treating TuxMake images with kernel.org toolchains as the de facto
stardard,
2. creating a repository from scratch on git.kernel.org with
independent hosting for base images,
3. some middle ground to be defined which would remove the risks
associated with third parties without duplicating efforts.
I feel it would be good to have more maintainers' feedback though.
Nathan, Nicolas, Miguel - what are your thoughts on this?
Thanks,
Guillaume
> [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 V2] Doc: dev-tools: Added Gentoo in the Operating system list under Getting Coccinelle
From: Jonathan Corbet @ 2026-02-25 17:55 UTC (permalink / raw)
To: Bhaskar Chowdhury, Julia.Lawall, nicolas.palix, skhan, cocci,
workflows, linux-doc, linux-kernel
Cc: Bhaskar Chowdhury
In-Reply-To: <20260222225536.19196-1-unixbhaskar@gmail.com>
Bhaskar Chowdhury <unixbhaskar@gmail.com> writes:
> Adding Gentoo in the operating system list under "Getting Coccinelle".
Applied, thanks. I also truncated the changelog here, we really don't
need to immortalize your ebuild session.
jon
^ permalink raw reply
* Re: [PATCH] Add short author date to Fixes tag
From: Greg Kroah-Hartman @ 2026-02-25 18:00 UTC (permalink / raw)
To: Alejandro Colomar
Cc: Steven Rostedt, Mark Brown, Sasha Levin, Geert Uytterhoeven,
Jacob Keller, Yeking, kuba, Jonathan Corbet, Theodore Ts'o,
Andy Whitcroft, Joe Perches, Dwaipayan Ray, Lukas Bulwahn,
Andrew Morton, workflows, linux-doc, linux-kernel,
tech-board-discuss, Andrew Lunn
In-Reply-To: <aZ4_sBIy8rOUL59Q@devuan>
On Wed, Feb 25, 2026 at 01:56:02AM +0100, Alejandro Colomar wrote:
> [Message-ID: <2025011032-gargle-showing-7500@gregkh>]
> Greg wrote (Fri, 10 Jan 2025 13:32:22 +0100):
> > Please no, you will break all of our tooling and scripts that parse
> > these types of fields. The git commit id and commit header is all we
> > need to properly determine this type of information, no need to add a
> > date in here at all.
> >
> [...]
> >
> > So I don't think you need to add a date here. Dates also really do not
> > mean much with commits, what matters is what release a commit is in, not
> > when it was originally made. We have commits that take years to show up
> > in a release, so if you only look at a date, you will be mistaken many
> > times as it's not showing what came before what many times (i.e. we
> > apply commits out-of-date-order all the time.)
>
> As I said above, I agree that the commit date is the right choice.
> Author dates can be out-of-date-order by years. Commit dates are
> necessarily in order, though.
Commit date also doesn't matter. If I commit a fix to one of my
branches today, but Linus pulls it in in 2 years from now, what would
that date really show to anyone?
Again, all that matters is when a commit is in a release, and for that
you walk the tree/graph to determine it. Please don't consider changing
the format of our commit identification logic as we have tools that
parse and handle what we have today, and all would be changed if we were
to change it.
Especially when it doesn't even provide any specific value that I can
see, if you want that info, just get it directly from git after looking
it up.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] Add short author date to Fixes tag
From: Alejandro Colomar @ 2026-02-25 18:20 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Steven Rostedt, Mark Brown, Sasha Levin, Geert Uytterhoeven,
Jacob Keller, Yeking, kuba, Jonathan Corbet, Theodore Ts'o,
Andy Whitcroft, Joe Perches, Dwaipayan Ray, Lukas Bulwahn,
Andrew Morton, workflows, linux-doc, linux-kernel,
tech-board-discuss, Andrew Lunn
In-Reply-To: <2026022531-tightness-rare-6a14@gregkh>
[-- Attachment #1: Type: text/plain, Size: 2344 bytes --]
Hi Greg,
On 2026-02-25T10:00:06-0800, Greg Kroah-Hartman wrote:
> On Wed, Feb 25, 2026 at 01:56:02AM +0100, Alejandro Colomar wrote:
> > [Message-ID: <2025011032-gargle-showing-7500@gregkh>]
> > Greg wrote (Fri, 10 Jan 2025 13:32:22 +0100):
> > > Please no, you will break all of our tooling and scripts that parse
> > > these types of fields. The git commit id and commit header is all we
> > > need to properly determine this type of information, no need to add a
> > > date in here at all.
> > >
> > [...]
> > >
> > > So I don't think you need to add a date here. Dates also really do not
> > > mean much with commits, what matters is what release a commit is in, not
> > > when it was originally made. We have commits that take years to show up
> > > in a release, so if you only look at a date, you will be mistaken many
> > > times as it's not showing what came before what many times (i.e. we
> > > apply commits out-of-date-order all the time.)
> >
> > As I said above, I agree that the commit date is the right choice.
> > Author dates can be out-of-date-order by years. Commit dates are
> > necessarily in order, though.
>
> Commit date also doesn't matter. If I commit a fix to one of my
> branches today, but Linus pulls it in in 2 years from now, what would
> that date really show to anyone?
I think this is a bit confused.
If you commit a fix for a commit that is in Linus's tree, your Fixes tag
will refer to the mainline commit, and the Fixes tag will remain valid
if the fix is pulled by Linus in the future, because it will continue to
refer to the same commit with the same hash and date.
The case where it would matter is if you commit a fix for a commit that
is only in your stable branch. However, since the stable branches are
not real branches, but actually a set of patches, I expect you would
just drop the faulty patch, right?
I expect any Fixes tag refers to commits in Linus's tree, right?
Otherwise, they are dangling references, except to those who know where
to find the commit. If all Fixes tags refer to commits in Linus's tree,
then all Fixes tags are stable.
The commit date is tied to a commit and its hash, and the date will
remain valid as much as the hash itself.
Have a lovely night!
Alex
--
<https://www.alejandro-colomar.es>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] Add short author date to Fixes tag
From: James Bottomley @ 2026-02-25 19:47 UTC (permalink / raw)
To: Alejandro Colomar, Greg Kroah-Hartman
Cc: Steven Rostedt, Mark Brown, Sasha Levin, Geert Uytterhoeven,
Jacob Keller, Yeking, kuba, Jonathan Corbet, Theodore Ts'o,
Andy Whitcroft, Joe Perches, Dwaipayan Ray, Lukas Bulwahn,
Andrew Morton, workflows, linux-doc, linux-kernel,
tech-board-discuss, Andrew Lunn
In-Reply-To: <aZ87Z24f9HZsofGl@devuan>
[-- Attachment #1: Type: text/plain, Size: 1948 bytes --]
On Wed, 2026-02-25 at 19:20 +0100, Alejandro Colomar wrote:
> > Commit date also doesn't matter. If I commit a fix to one of my
> > branches today, but Linus pulls it in in 2 years from now, what
> > would that date really show to anyone?
>
> I think this is a bit confused.
Let me try another explanation: we only change tag formats for what
most people agree is a compelling reason (because of the script
breakage it causes among other things). Your reasons so far aren't
compelling.
> If you commit a fix for a commit that is in Linus's tree, your Fixes
> tag will refer to the mainline commit, and the Fixes tag will remain
> valid if the fix is pulled by Linus in the future, because it will
> continue to refer to the same commit with the same hash and date.
>
> The case where it would matter is if you commit a fix for a commit
> that is only in your stable branch. However, since the stable
> branches are not real branches, but actually a set of patches, I
> expect you would just drop the faulty patch, right?
I think this is a bit confused. The decision to rebase or revert is a
balancing act which depends how many people have seen (and possibly
rely on) the branch with the original commit in it.
> I expect any Fixes tag refers to commits in Linus's tree, right?
> Otherwise, they are dangling references, except to those who know
> where to find the commit. If all Fixes tags refer to commits in
> Linus's tree, then all Fixes tags are stable.
I believe one of the prerequisites for changing current process should
be actually understanding how it works today.
> The commit date is tied to a commit and its hash, and the date will
> remain valid as much as the hash itself.
The argument isn't about validity, it's about utility. Most of the
tasks we do don't care about the date and for the odd occasion we do
care we can follow the hash to get it.
Regards,
James
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 265 bytes --]
^ permalink raw reply
* Re: [PATCH] Add short author date to Fixes tag
From: Sasha Levin @ 2026-02-25 20:08 UTC (permalink / raw)
To: Alejandro Colomar
Cc: Steven Rostedt, Greg Kroah-Hartman, Mark Brown,
Geert Uytterhoeven, Jacob Keller, Yeking, kuba, Jonathan Corbet,
Theodore Ts'o, Andy Whitcroft, Joe Perches, Dwaipayan Ray,
Lukas Bulwahn, Andrew Morton, workflows, linux-doc, linux-kernel,
tech-board-discuss, Andrew Lunn
In-Reply-To: <aZ4_sBIy8rOUL59Q@devuan>
On Wed, Feb 25, 2026 at 01:56:02AM +0100, Alejandro Colomar wrote:
>Steven wrote (Fri, 10 Jan 2025 08:03:31 -0500):
>> How can it lead to misjudgment? If you have two or more hashes matching, do
>> you really think they'll have the same subjects?
>
>The possibility isn't zero. Statistically, it's quite low. However,
>it's non-zero.
>
>$ git log --format=tformat:'%s' | sort | uniq -c | sort | tail
> 248 Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
> 263 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6
> 275 Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
> 293 Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
> 314 Merge branch 'akpm' (patches from Andrew)
> 315 Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net
> 318 Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
> 324 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
> 369 Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
> 670 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
>$ git log --format=tformat:'%s' | grep -v ^Merge | sort | uniq -c | sort | tail
>grep: (standard input): binary file matches
> 22 drm/amd/display: Clean up some inconsistent indenting
> 25 Auto-update from upstream
> 26 [ARM] Update mach-types
> 26 pmdomain: Merge branch fixes into next
> 30 s390: update defconfigs
> 32 tools arch x86: Sync the msr-index.h copy with the kernel sources
> 38 [SPARC64]: Update defconfig.
> 52 mmc: Merge branch fixes into next
> 59 drm/i915: Convert wait_for(I915_READ(reg)) to intel_wait_for_register()
> 62 batman-adv: Start new development cycle
>
>Subjects repeat every now and then, and the entropy in some subjects is
>actually quite low.
>
>If you include the commit date in a Fixes tag, then you preclude the
>entire possibility of a commit reference clash, because you won't have
>two patches committed in the same date with the same subject and same
>hash (unless you *really* try)
The probability of a collision where two commits share both the same
abbreviated SHA1 and the same subject line is so astronomically low that it's
not a realistic concern.
For context, Linus himself pushed back on merely extending the 12-character
SHA1 abbreviation to 13. A change that wouldn't even break existing scripts.
Yet the proposal here is to introduce an entirely new date parameter that's
incompatible with the current format, all to address a scenario that is
unlikely in practice.
--
Thanks,
Sasha
^ permalink raw reply
* [PATCH] kfence: add kfence.fault parameter
From: Marco Elver @ 2026-02-25 20:36 UTC (permalink / raw)
To: elver, Andrew Morton
Cc: Alexander Potapenko, Dmitry Vyukov, Jonathan Corbet, Shuah Khan,
linux-doc, linux-kernel, kasan-dev, workflows, linux-mm,
Ernesto Martinez Garcia, Kees Cook
Add kfence.fault parameter to control the behavior when a KFENCE error
is detected (similar in spirit to kasan.fault=<mode>).
The supported modes for kfence.fault=<mode> are:
- report: print the error report and continue (default).
- oops: print the error report and oops.
- panic: print the error report and panic.
In particular, the 'oops' mode offers a trade-off between no mitigation
on report and panicking outright (if panic_on_oops is not set).
Signed-off-by: Marco Elver <elver@google.com>
---
.../admin-guide/kernel-parameters.txt | 6 +++
Documentation/dev-tools/kfence.rst | 7 +++
mm/kfence/core.c | 23 ++++++---
mm/kfence/kfence.h | 16 +++++-
mm/kfence/report.c | 49 +++++++++++++++++--
5 files changed, 89 insertions(+), 12 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index cb850e5290c2..05acdea306b2 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2958,6 +2958,12 @@ Kernel parameters
Format: <bool>
Default: CONFIG_KFENCE_DEFERRABLE
+ kfence.fault= [MM,KFENCE] Controls the behavior when a KFENCE
+ error is detected.
+ report - print the error report and continue (default).
+ oops - print the error report and oops.
+ panic - print the error report and panic.
+
kfence.sample_interval=
[MM,KFENCE] KFENCE's sample interval in milliseconds.
Format: <unsigned integer>
diff --git a/Documentation/dev-tools/kfence.rst b/Documentation/dev-tools/kfence.rst
index 541899353865..b03d1201ddae 100644
--- a/Documentation/dev-tools/kfence.rst
+++ b/Documentation/dev-tools/kfence.rst
@@ -81,6 +81,13 @@ tables being allocated.
Error reports
~~~~~~~~~~~~~
+The boot parameter ``kfence.fault`` can be used to control the behavior when a
+KFENCE error is detected:
+
+- ``kfence.fault=report``: Print the error report and continue (default).
+- ``kfence.fault=oops``: Print the error report and oops.
+- ``kfence.fault=panic``: Print the error report and panic.
+
A typical out-of-bounds access looks like this::
==================================================================
diff --git a/mm/kfence/core.c b/mm/kfence/core.c
index b4ea3262c925..a5f7dffa9f6f 100644
--- a/mm/kfence/core.c
+++ b/mm/kfence/core.c
@@ -50,7 +50,7 @@
/* === Data ================================================================= */
-static bool kfence_enabled __read_mostly;
+bool kfence_enabled __read_mostly;
static bool disabled_by_warn __read_mostly;
unsigned long kfence_sample_interval __read_mostly = CONFIG_KFENCE_SAMPLE_INTERVAL;
@@ -335,6 +335,7 @@ metadata_update_state(struct kfence_metadata *meta, enum kfence_object_state nex
static check_canary_attributes bool check_canary_byte(u8 *addr)
{
struct kfence_metadata *meta;
+ enum kfence_fault fault;
unsigned long flags;
if (likely(*addr == KFENCE_CANARY_PATTERN_U8(addr)))
@@ -344,8 +345,9 @@ static check_canary_attributes bool check_canary_byte(u8 *addr)
meta = addr_to_metadata((unsigned long)addr);
raw_spin_lock_irqsave(&meta->lock, flags);
- kfence_report_error((unsigned long)addr, false, NULL, meta, KFENCE_ERROR_CORRUPTION);
+ fault = kfence_report_error((unsigned long)addr, false, NULL, meta, KFENCE_ERROR_CORRUPTION);
raw_spin_unlock_irqrestore(&meta->lock, flags);
+ kfence_handle_fault(fault);
return false;
}
@@ -524,11 +526,14 @@ static void kfence_guarded_free(void *addr, struct kfence_metadata *meta, bool z
raw_spin_lock_irqsave(&meta->lock, flags);
if (!kfence_obj_allocated(meta) || meta->addr != (unsigned long)addr) {
+ enum kfence_fault fault;
+
/* Invalid or double-free, bail out. */
atomic_long_inc(&counters[KFENCE_COUNTER_BUGS]);
- kfence_report_error((unsigned long)addr, false, NULL, meta,
- KFENCE_ERROR_INVALID_FREE);
+ fault = kfence_report_error((unsigned long)addr, false, NULL, meta,
+ KFENCE_ERROR_INVALID_FREE);
raw_spin_unlock_irqrestore(&meta->lock, flags);
+ kfence_handle_fault(fault);
return;
}
@@ -830,7 +835,8 @@ static void kfence_check_all_canary(void)
static int kfence_check_canary_callback(struct notifier_block *nb,
unsigned long reason, void *arg)
{
- kfence_check_all_canary();
+ if (READ_ONCE(kfence_enabled))
+ kfence_check_all_canary();
return NOTIFY_OK;
}
@@ -1249,6 +1255,7 @@ bool kfence_handle_page_fault(unsigned long addr, bool is_write, struct pt_regs
struct kfence_metadata *to_report = NULL;
unsigned long unprotected_page = 0;
enum kfence_error_type error_type;
+ enum kfence_fault fault;
unsigned long flags;
if (!is_kfence_address((void *)addr))
@@ -1307,12 +1314,14 @@ bool kfence_handle_page_fault(unsigned long addr, bool is_write, struct pt_regs
if (to_report) {
raw_spin_lock_irqsave(&to_report->lock, flags);
to_report->unprotected_page = unprotected_page;
- kfence_report_error(addr, is_write, regs, to_report, error_type);
+ fault = kfence_report_error(addr, is_write, regs, to_report, error_type);
raw_spin_unlock_irqrestore(&to_report->lock, flags);
} else {
/* This may be a UAF or OOB access, but we can't be sure. */
- kfence_report_error(addr, is_write, regs, NULL, KFENCE_ERROR_INVALID);
+ fault = kfence_report_error(addr, is_write, regs, NULL, KFENCE_ERROR_INVALID);
}
+ kfence_handle_fault(fault);
+
return kfence_unprotect(addr); /* Unprotect and let access proceed. */
}
diff --git a/mm/kfence/kfence.h b/mm/kfence/kfence.h
index f9caea007246..1f618f9b0d12 100644
--- a/mm/kfence/kfence.h
+++ b/mm/kfence/kfence.h
@@ -16,6 +16,8 @@
#include "../slab.h" /* for struct kmem_cache */
+extern bool kfence_enabled;
+
/*
* Get the canary byte pattern for @addr. Use a pattern that varies based on the
* lower 3 bits of the address, to detect memory corruptions with higher
@@ -140,8 +142,18 @@ enum kfence_error_type {
KFENCE_ERROR_INVALID_FREE, /* Invalid free. */
};
-void kfence_report_error(unsigned long address, bool is_write, struct pt_regs *regs,
- const struct kfence_metadata *meta, enum kfence_error_type type);
+enum kfence_fault {
+ KFENCE_FAULT_NONE,
+ KFENCE_FAULT_REPORT,
+ KFENCE_FAULT_OOPS,
+ KFENCE_FAULT_PANIC,
+};
+
+enum kfence_fault
+kfence_report_error(unsigned long address, bool is_write, struct pt_regs *regs,
+ const struct kfence_metadata *meta, enum kfence_error_type type);
+
+void kfence_handle_fault(enum kfence_fault fault);
void kfence_print_object(struct seq_file *seq, const struct kfence_metadata *meta) __must_hold(&meta->lock);
diff --git a/mm/kfence/report.c b/mm/kfence/report.c
index 787e87c26926..d548536864b1 100644
--- a/mm/kfence/report.c
+++ b/mm/kfence/report.c
@@ -7,9 +7,12 @@
#include <linux/stdarg.h>
+#include <linux/bug.h>
+#include <linux/init.h>
#include <linux/kernel.h>
#include <linux/lockdep.h>
#include <linux/math.h>
+#include <linux/panic.h>
#include <linux/printk.h>
#include <linux/sched/debug.h>
#include <linux/seq_file.h>
@@ -29,6 +32,26 @@
#define ARCH_FUNC_PREFIX ""
#endif
+static enum kfence_fault kfence_fault __ro_after_init = KFENCE_FAULT_REPORT;
+
+static int __init early_kfence_fault(char *arg)
+{
+ if (!arg)
+ return -EINVAL;
+
+ if (!strcmp(arg, "report"))
+ kfence_fault = KFENCE_FAULT_REPORT;
+ else if (!strcmp(arg, "oops"))
+ kfence_fault = KFENCE_FAULT_OOPS;
+ else if (!strcmp(arg, "panic"))
+ kfence_fault = KFENCE_FAULT_PANIC;
+ else
+ return -EINVAL;
+
+ return 0;
+}
+early_param("kfence.fault", early_kfence_fault);
+
/* Helper function to either print to a seq_file or to console. */
__printf(2, 3)
static void seq_con_printf(struct seq_file *seq, const char *fmt, ...)
@@ -189,8 +212,9 @@ static const char *get_access_type(bool is_write)
return str_write_read(is_write);
}
-void kfence_report_error(unsigned long address, bool is_write, struct pt_regs *regs,
- const struct kfence_metadata *meta, enum kfence_error_type type)
+enum kfence_fault
+kfence_report_error(unsigned long address, bool is_write, struct pt_regs *regs,
+ const struct kfence_metadata *meta, enum kfence_error_type type)
{
unsigned long stack_entries[KFENCE_STACK_DEPTH] = { 0 };
const ptrdiff_t object_index = meta ? meta - kfence_metadata : -1;
@@ -206,7 +230,7 @@ void kfence_report_error(unsigned long address, bool is_write, struct pt_regs *r
/* Require non-NULL meta, except if KFENCE_ERROR_INVALID. */
if (WARN_ON(type != KFENCE_ERROR_INVALID && !meta))
- return;
+ return KFENCE_FAULT_NONE;
/*
* Because we may generate reports in printk-unfriendly parts of the
@@ -282,6 +306,25 @@ void kfence_report_error(unsigned long address, bool is_write, struct pt_regs *r
/* We encountered a memory safety error, taint the kernel! */
add_taint(TAINT_BAD_PAGE, LOCKDEP_STILL_OK);
+
+ return kfence_fault;
+}
+
+void kfence_handle_fault(enum kfence_fault fault)
+{
+ switch (fault) {
+ case KFENCE_FAULT_NONE:
+ case KFENCE_FAULT_REPORT:
+ break;
+ case KFENCE_FAULT_OOPS:
+ BUG();
+ break;
+ case KFENCE_FAULT_PANIC:
+ /* Disable KFENCE to avoid recursion if check_on_panic is set. */
+ WRITE_ONCE(kfence_enabled, false);
+ panic("kfence.fault=panic set ...\n");
+ break;
+ }
}
#ifdef CONFIG_PRINTK
--
2.53.0.414.gf7e9f6c205-goog
^ permalink raw reply related
* Re: [PATCH] Add short author date to Fixes tag
From: Greg Kroah-Hartman @ 2026-02-25 21:23 UTC (permalink / raw)
To: Alejandro Colomar
Cc: Steven Rostedt, Mark Brown, Sasha Levin, Geert Uytterhoeven,
Jacob Keller, Yeking, kuba, Jonathan Corbet, Theodore Ts'o,
Andy Whitcroft, Joe Perches, Dwaipayan Ray, Lukas Bulwahn,
Andrew Morton, workflows, linux-doc, linux-kernel,
tech-board-discuss, Andrew Lunn
In-Reply-To: <aZ87Z24f9HZsofGl@devuan>
On Wed, Feb 25, 2026 at 07:20:25PM +0100, Alejandro Colomar wrote:
> Hi Greg,
>
> On 2026-02-25T10:00:06-0800, Greg Kroah-Hartman wrote:
> > On Wed, Feb 25, 2026 at 01:56:02AM +0100, Alejandro Colomar wrote:
> > > [Message-ID: <2025011032-gargle-showing-7500@gregkh>]
> > > Greg wrote (Fri, 10 Jan 2025 13:32:22 +0100):
> > > > Please no, you will break all of our tooling and scripts that parse
> > > > these types of fields. The git commit id and commit header is all we
> > > > need to properly determine this type of information, no need to add a
> > > > date in here at all.
> > > >
> > > [...]
> > > >
> > > > So I don't think you need to add a date here. Dates also really do not
> > > > mean much with commits, what matters is what release a commit is in, not
> > > > when it was originally made. We have commits that take years to show up
> > > > in a release, so if you only look at a date, you will be mistaken many
> > > > times as it's not showing what came before what many times (i.e. we
> > > > apply commits out-of-date-order all the time.)
> > >
> > > As I said above, I agree that the commit date is the right choice.
> > > Author dates can be out-of-date-order by years. Commit dates are
> > > necessarily in order, though.
> >
> > Commit date also doesn't matter. If I commit a fix to one of my
> > branches today, but Linus pulls it in in 2 years from now, what would
> > that date really show to anyone?
>
> I think this is a bit confused.
>
> If you commit a fix for a commit that is in Linus's tree, your Fixes tag
> will refer to the mainline commit, and the Fixes tag will remain valid
> if the fix is pulled by Linus in the future, because it will continue to
> refer to the same commit with the same hash and date.
But we do not need the date! It provides no additional information that
we can't just look up if we really need it.
The HASH ("text") format does 2 things, it provides an id we can use to
look up more, and the text is there to give humans a hint if they don't
want or need to look it up. There is no need to include anything else,
let's keep it simple please.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] Add short author date to Fixes tag
From: Alejandro Colomar @ 2026-02-25 21:45 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Steven Rostedt, Mark Brown, Sasha Levin, Geert Uytterhoeven,
Jacob Keller, Yeking, kuba, Jonathan Corbet, Theodore Ts'o,
Andy Whitcroft, Joe Perches, Dwaipayan Ray, Lukas Bulwahn,
Andrew Morton, workflows, linux-doc, linux-kernel,
tech-board-discuss, Andrew Lunn
In-Reply-To: <2026022539-commotion-huskiness-8736@gregkh>
[-- Attachment #1: Type: text/plain, Size: 2048 bytes --]
Hi Greg,
On 2026-02-25T13:23:24-0800, Greg Kroah-Hartman wrote:
> > > Commit date also doesn't matter. If I commit a fix to one of my
> > > branches today, but Linus pulls it in in 2 years from now, what would
> > > that date really show to anyone?
> >
> > I think this is a bit confused.
> >
> > If you commit a fix for a commit that is in Linus's tree, your Fixes tag
> > will refer to the mainline commit, and the Fixes tag will remain valid
> > if the fix is pulled by Linus in the future, because it will continue to
> > refer to the same commit with the same hash and date.
>
> But we do not need the date! It provides no additional information that
> we can't just look up if we really need it.
>
> The HASH ("text") format does 2 things, it provides an id we can use to
> look up more, and the text is there to give humans a hint if they don't
> want or need to look it up.
The date gives more information to humans to decide if the commit is
important to look up. Sometimes, a subject can be ambiguous to the
human, even if it's not ambiguous to a machine. The date can help give
some context to a human. For example, one could relate a commit to a
series that was merged around that date.
The date uses few characters, so it's not too expensive in terms of
space. You may even take some space back by dropping a few characters
from the hash. Also, by having a fixed-width, it doesn't distract much,
as all subjects will still be aligned, so the eyes can jump it easily if
not interesting (just like the hash).
I appreciate seeing the date in my Fixes tags elsewhere, as it avoids
looking up some commits, which I would look up if I hadn't seen the
date.
Secondarily, it helps with the ID, in case it becomes ambiguous. But
I started using it for the human part of it.
> There is no need to include anything else,
> let's keep it simple please.
Okay; I won't insist.
Have a lovely night!
Alex
>
> thanks,
>
> greg k-h
--
<https://www.alejandro-colomar.es>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] kfence: add kfence.fault parameter
From: Rik van Riel @ 2026-02-25 22:26 UTC (permalink / raw)
To: Marco Elver, Andrew Morton
Cc: Alexander Potapenko, Dmitry Vyukov, Jonathan Corbet, Shuah Khan,
linux-doc, linux-kernel, kasan-dev, workflows, linux-mm,
Ernesto Martinez Garcia, Kees Cook
In-Reply-To: <20260225203639.3159463-1-elver@google.com>
On Wed, 2026-02-25 at 21:36 +0100, Marco Elver wrote:
>
> +static int __init early_kfence_fault(char *arg)
> +{
> + if (!arg)
> + return -EINVAL;
> +
> + if (!strcmp(arg, "report"))
> + kfence_fault = KFENCE_FAULT_REPORT;
> + else if (!strcmp(arg, "oops"))
> + kfence_fault = KFENCE_FAULT_OOPS;
> + else if (!strcmp(arg, "panic"))
> + kfence_fault = KFENCE_FAULT_PANIC;
> + else
> + return -EINVAL;
> +
> + return 0;
> +}
> +early_param("kfence.fault", early_kfence_fault);
The other parameters in mm/kfence/ seem to be module_param,
which make them tunable at run time through
/sys/module/kfence/parameters/*
Why is this one different?
And, does this one show up as /sys/module/kfence/parameters/fault?
Having the ability to tweak this behavior at run time, without
requiring a system reboot, could be really useful for people
unexpectedly triggering kernel panics across a fleet of servers,
and deciding they would rather not.
--
All Rights Reversed.
^ permalink raw reply
* Re: [PATCH] Add short author date to Fixes tag
From: Theodore Tso @ 2026-02-25 22:35 UTC (permalink / raw)
To: Alejandro Colomar
Cc: Greg Kroah-Hartman, Steven Rostedt, Mark Brown, Sasha Levin,
Geert Uytterhoeven, Jacob Keller, Yeking, kuba, Jonathan Corbet,
Andy Whitcroft, Joe Perches, Dwaipayan Ray, Lukas Bulwahn,
Andrew Morton, workflows, linux-doc, linux-kernel,
tech-board-discuss, Andrew Lunn
In-Reply-To: <aZ9p2RMrJL1mQ10w@devuan>
On Wed, Feb 25, 2026 at 10:45:48PM +0100, Alejandro Colomar wrote:
> The date gives more information to humans to decide if the commit is
> important to look up. Sometimes, a subject can be ambiguous to the
> human, even if it's not ambiguous to a machine. The date can help give
> some context to a human. For example, one could relate a commit to a
> series that was merged around that date.
I'm really confused under what circumstances the date would ever be
*useful* to me. In general, what I want to know is "is this fix
applicable to a branch I care about", which basically means I want to
know if a particular branch (a) has the commit id, or (b) has a commit
whose description contains a "commit upstream" line referencing the
commit.
The date is almost never interesting to me. For upstream commits in
Linus's tree, the hint:
Cc: stable@kernel.org # 6.8+
Is a bit more interesting to me, but so long as there's a fixes tag
with a commit ID, I can just do a "git tag --contains <commit-id>" to
get the same information.
- Ted
^ permalink raw reply
* Re: [PATCH] Add short author date to Fixes tag
From: Sasha Levin @ 2026-02-25 23:27 UTC (permalink / raw)
To: Alejandro Colomar
Cc: Greg Kroah-Hartman, Steven Rostedt, Mark Brown,
Geert Uytterhoeven, Jacob Keller, Yeking, kuba, Jonathan Corbet,
Theodore Ts'o, Andy Whitcroft, Joe Perches, Dwaipayan Ray,
Lukas Bulwahn, Andrew Morton, workflows, linux-doc, linux-kernel,
tech-board-discuss, Andrew Lunn
In-Reply-To: <aZ9p2RMrJL1mQ10w@devuan>
On Wed, Feb 25, 2026 at 10:45:48PM +0100, Alejandro Colomar wrote:
>I appreciate seeing the date in my Fixes tags elsewhere, as it avoids
>looking up some commits, which I would look up if I hadn't seen the
>date.
If it's something that is helpful for you, just add a git alias?
$ cat ~/git-fixes-date-filter
#!/usr/bin/perl
# Save as e.g. ~/bin/git-fixes-date-filter
while (<STDIN>) {
if (/^(\s*Fixes:\s+)([0-9a-f]+)\s+\("(.*)"\)/) {
my ($prefix, $sha, $desc) = ($1, $2, $3);
chomp(my $date = `git log -1 --format=%as $sha 2>/dev/null`);
if ($date) {
print "$prefix$sha ($date,\"$desc\")\n";
next;
}
}
print;
}
Add to .gitconfig:
[alias]
lg = "!git log \"$@\" | ~/git-fixes-date-filter | less -R #"
And then "git lg" will do exactly what you're asking for:
$ git lg -1 origin/master | grep Fixes
Fixes: cc1e127bfa95 (2022-05-09,"random: remove ratelimiting for in-kernel unseeded randomness")
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH] Add short author date to Fixes tag
From: Greg Kroah-Hartman @ 2026-02-25 23:46 UTC (permalink / raw)
To: Alejandro Colomar
Cc: Steven Rostedt, Mark Brown, Sasha Levin, Geert Uytterhoeven,
Jacob Keller, Yeking, kuba, Jonathan Corbet, Theodore Ts'o,
Andy Whitcroft, Joe Perches, Dwaipayan Ray, Lukas Bulwahn,
Andrew Morton, workflows, linux-doc, linux-kernel,
tech-board-discuss, Andrew Lunn
In-Reply-To: <aZ9p2RMrJL1mQ10w@devuan>
On Wed, Feb 25, 2026 at 10:45:48PM +0100, Alejandro Colomar wrote:
> Hi Greg,
>
> On 2026-02-25T13:23:24-0800, Greg Kroah-Hartman wrote:
> > > > Commit date also doesn't matter. If I commit a fix to one of my
> > > > branches today, but Linus pulls it in in 2 years from now, what would
> > > > that date really show to anyone?
> > >
> > > I think this is a bit confused.
> > >
> > > If you commit a fix for a commit that is in Linus's tree, your Fixes tag
> > > will refer to the mainline commit, and the Fixes tag will remain valid
> > > if the fix is pulled by Linus in the future, because it will continue to
> > > refer to the same commit with the same hash and date.
> >
> > But we do not need the date! It provides no additional information that
> > we can't just look up if we really need it.
> >
> > The HASH ("text") format does 2 things, it provides an id we can use to
> > look up more, and the text is there to give humans a hint if they don't
> > want or need to look it up.
>
> The date gives more information to humans to decide if the commit is
> important to look up.
No it does not, that is what the subject determines.
> Sometimes, a subject can be ambiguous to the human, even if it's not
> ambiguous to a machine.
Then work with the developers to not provide such subject lines. Don't
rely on a date for anything, that doesn't help.
> The date can help give
> some context to a human. For example, one could relate a commit to a
> series that was merged around that date.
Again, dates of commit time do not reflect the date of the release it
shows up in.
> I appreciate seeing the date in my Fixes tags elsewhere, as it avoids
> looking up some commits, which I would look up if I hadn't seen the
> date.
That's great, but again, for the kernel we don't need or want this. If
you do want this, great, you can add it yourself as Sasha just showed.
> Secondarily, it helps with the ID, in case it becomes ambiguous. But
> I started using it for the human part of it.
Our ids are not ambiguous. Our "problem" is people putting git ids in
the logs that are not valid git ids. Just happened again today as we
are "human". Putting the date in there would not help with that very
real problem we have today at all.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] Add short author date to Fixes tag
From: Steven Rostedt @ 2026-02-26 0:08 UTC (permalink / raw)
To: Alejandro Colomar
Cc: Greg Kroah-Hartman, Mark Brown, Sasha Levin, Geert Uytterhoeven,
Jacob Keller, Yeking, kuba, Jonathan Corbet, Theodore Ts'o,
Andy Whitcroft, Joe Perches, Dwaipayan Ray, Lukas Bulwahn,
Andrew Morton, workflows, linux-doc, linux-kernel,
tech-board-discuss, Andrew Lunn
In-Reply-To: <aZ4_sBIy8rOUL59Q@devuan>
On Wed, 25 Feb 2026 01:56:02 +0100
Alejandro Colomar <alx@kernel.org> wrote:
> That uses hash+subject. This may be not enough in some cases (see how
> much subjects repeat, in the logs above). And importantly, a fixes tag
Most of those repeats are merges. And people tend to use the same
subject when they merge commits. The only time a Fixes is for a merge
is if there was a merge conflict and it was done poorly.
> may become ambiguous *after* it has been written, so you can't predict
> much.
>
> By having a commit date in the Fixes tag, you could even simplify the
> script to just do a binary search in case of ambiguity. Let's say I
> want to find the following commit (arbitrarily taken from the first
> Fixes tag I've found in my copy of linux.git):
>
> a2e459555c5f (2023-08-09; "shmem: stable directory offsets")
>
> We could find it, with a trivial command line. We only even need two
> characters of the hash:
>
> $ git log --oneline --after='2023-08-08' --before='2023-08-10' \
> | grep ^a2;
> a2e459555c5f shmem: stable directory offsets
Why not just git show a2e459555c5f? You're just worried because of
conflicts? That happens so seldom doing a bit more work to find the
task is less work than every developer adding a useless date in the tag.
Even if there are conflicts, git show shows you all the commits that conflict:
(random example)
$ git show cbced
error: short object ID cbced is ambiguous
hint: The candidates are:
hint: cbced93894d1 commit 2026-02-02 - drm/amd/display: Set CRTC source for DAC using registers
hint: cbced0de1ae7 tree
hint: cbced35df940 tree
hint: cbced38b00f6 tree
hint: cbced53122ce tree
hint: cbced7856638 tree
hint: cbced88f5140 tree
hint: cbceda69074d tree
hint: cbcedadcc0f9 tree
hint: cbced8ff29d4 blob
hint: cbcedd7a684b blob
The above only has one with a subject.
>
> No need for a huge script to disambiguate. This is even typo-resistant,
> as one could eventually find something that is similar enough, if one
> had such a field with a typo (in any of the three fields). You'd be
> able to search by the other two fields, and two fields should be
> _usually_ enough for disambiguating, and the third one could corroborate
> the typo.
>
> So, what would you think of having the commit date in commit references
> such as Fixes tags?
NAK. I really see no purpose for it, and just adds added noise to the
Fixes tag. Seriously, your example above:
a2e459555c5f (2023-08-09; "shmem: stable directory offsets")
Looks horrible compared to:
a2e459555c5f ("shmem: stable directory offsets")
You are the first one to complain about needing a date here. Who else
finds this useful in the kernel community? It really feels like it's a
solution looking for a problem.
Sorry,
-- Steve
^ permalink raw reply
* Re: [PATCH] Add short author date to Fixes tag
From: Alejandro Colomar @ 2026-02-26 0:20 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Steven Rostedt, Mark Brown, Sasha Levin, Geert Uytterhoeven,
Jacob Keller, Yeking, kuba, Jonathan Corbet, Theodore Ts'o,
Andy Whitcroft, Joe Perches, Dwaipayan Ray, Lukas Bulwahn,
Andrew Morton, workflows, linux-doc, linux-kernel,
tech-board-discuss, Andrew Lunn
In-Reply-To: <2026022547-confirm-upturned-a736@gregkh>
[-- Attachment #1: Type: text/plain, Size: 2469 bytes --]
Hi Greg,
On 2026-02-25T15:46:28-0800, Greg Kroah-Hartman wrote:
[...]
> > Secondarily, it helps with the ID, in case it becomes ambiguous. But
> > I started using it for the human part of it.
>
> Our ids are not ambiguous. Our "problem" is people putting git ids in
> the logs that are not valid git ids. Just happened again today as we
> are "human". Putting the date in there would not help with that very
> real problem we have today at all.
It would help locate the commit it refers to. If you have a commit
date, you know that if it was rebased, the date can only increase. So,
instead of having to search exclusively by subject, you can limit your
search to dates no older than the date from the Fixes tag.
Let's say we want to locate
bogus-hash (2025-11-21; "bug: Add BUG_FORMAT_ARGS infrastructure")
We can first of all check if maybe there's a typo in the hash (maybe
the first character is missing, due to a cut/paste accident).
$ git log --oneline --before 2025-11-22 --after 2025-11-20 \
| grep BUG_FORMAT_ARGS;
5c47b7f3d1a9 bug: Add BUG_FORMAT_ARGS infrastructure
But even if the date was wrong. Let's say someone used a reference to
a commit that got rebased a year later, as the case you stated.
old-hash (2025-01-21; "bug: Add BUG_FORMAT_ARGS infrastructure")
We can search by date something that looks similar. We know the date
can't be older than that, if it wasrebased.
$ git log --oneline --after 2025-11-20 | grep infrastructure
cb2dc6d2869a can: Kconfig: select CAN driver infrastructure by default
93d7a7ed0734 netfilter: flowtable: move path discovery infrastructure to its own file
23343b6b09ac sched/mmcid: Introduce per task/CPU ownership infrastructure
775465fd26a3 lib/test_hmm: add zone device private THP test infrastructure
99e4e1028337 RDMA/bng_re: Add basic debugfs infrastructure
4f830cd8d7fe RDMA/bng_re: Add infrastructure for enabling Firmware channel
5c47b7f3d1a9 bug: Add BUG_FORMAT_ARGS infrastructure
d292dbb5640c bug: Add BUG_FORMAT infrastructure
So, we'd start looking at the tail of that list (assuming the rebase was
close to the commit date), and depart from that as necessary. In this
case, we find it as the second commit.
On the other hand, if you have no date, you must look at the entire
git-log(1), which is a lot more work.
> thanks,
>
> greg k-h
Have a lovely night!
Alex
--
<https://www.alejandro-colomar.es>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] kfence: add kfence.fault parameter
From: Marco Elver @ 2026-02-26 1:16 UTC (permalink / raw)
To: Rik van Riel
Cc: Andrew Morton, Alexander Potapenko, Dmitry Vyukov,
Jonathan Corbet, Shuah Khan, linux-doc, linux-kernel, kasan-dev,
workflows, linux-mm, Ernesto Martinez Garcia, Kees Cook
In-Reply-To: <9476ab2ff783c77ff4f1d323fad3e356bb172fcd.camel@surriel.com>
On Wed, 25 Feb 2026 at 23:26, Rik van Riel <riel@surriel.com> wrote:
>
> On Wed, 2026-02-25 at 21:36 +0100, Marco Elver wrote:
> >
> > +static int __init early_kfence_fault(char *arg)
> > +{
> > + if (!arg)
> > + return -EINVAL;
> > +
> > + if (!strcmp(arg, "report"))
> > + kfence_fault = KFENCE_FAULT_REPORT;
> > + else if (!strcmp(arg, "oops"))
> > + kfence_fault = KFENCE_FAULT_OOPS;
> > + else if (!strcmp(arg, "panic"))
> > + kfence_fault = KFENCE_FAULT_PANIC;
> > + else
> > + return -EINVAL;
> > +
> > + return 0;
> > +}
> > +early_param("kfence.fault", early_kfence_fault);
>
> The other parameters in mm/kfence/ seem to be module_param,
> which make them tunable at run time through
> /sys/module/kfence/parameters/*
>
> Why is this one different?
That was my first thought too, but after much thought we should not
make this changeable after init, see below ...
> And, does this one show up as /sys/module/kfence/parameters/fault?
>
> Having the ability to tweak this behavior at run time, without
> requiring a system reboot, could be really useful for people
> unexpectedly triggering kernel panics across a fleet of servers,
> and deciding they would rather not.
It's intentional - having the ability to switch it after init means
we'd have to remove __ro_after_init from the kfence_fault setting. We
risk having the system administrator's choice being overridden by
accident in the exact situation where we do not want it to happen:
either through memory corruption overwriting that global flag, or it
might give an attacker the ability to circumvent the oops/panic
setting, if they manage to reset it. KFENCE is not a mitigation, but
this setting is meant to give a knob to reduce the risk that someone
takes advantage of KFENCE's heap layout - until now, KFENCE only
reports and continues - the actual buggy access happily proceeds.
^ permalink raw reply
* Re: [PATCH] Add short author date to Fixes tag
From: Geert Uytterhoeven @ 2026-02-26 7:50 UTC (permalink / raw)
To: Alejandro Colomar
Cc: Greg Kroah-Hartman, Steven Rostedt, Mark Brown, Sasha Levin,
Jacob Keller, Yeking, kuba, Jonathan Corbet, Theodore Ts'o,
Andy Whitcroft, Joe Perches, Dwaipayan Ray, Lukas Bulwahn,
Andrew Morton, workflows, linux-doc, linux-kernel,
tech-board-discuss, Andrew Lunn
In-Reply-To: <aZ87Z24f9HZsofGl@devuan>
Hi Alejandro,
On Wed, 25 Feb 2026 at 19:20, Alejandro Colomar <alx@kernel.org> wrote:
> The case where it would matter is if you commit a fix for a commit that
> is only in your stable branch. However, since the stable branches are
> not real branches, but actually a set of patches, I expect you would
> just drop the faulty patch, right?
Stable branches are real branches, cfr.
https://web.git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/refs/heads.
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 v2 0/2] scripts: workflow: sort ver_linux
From: Hans Anda @ 2026-02-26 10:02 UTC (permalink / raw)
To: Jonathan Corbet, Collin Funk, Shuah Khan
Cc: workflows, linux-doc, linux-kernel, Hans Anda
In-Reply-To: <20260221152113.28322-2-hansa@airmail.cc>
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).
[v1] -> [v2]
split v1 into a patch series
changes.rst:
add reference to ver_linux
ver_linux:
fix path to changes.rst
Signed-off-by: Hans Anda <hansa@airmail.cc>
^ permalink raw reply
* [PATCH v2 1/2] workflow: process/changes.rst: sort list
From: Hans Anda @ 2026-02-26 10:11 UTC (permalink / raw)
To: Jonathan Corbet, Collin Funk, Shuah Khan
Cc: workflows, linux-doc, linux-kernel, Hans Anda
In-Reply-To: <20260226100256.40215-2-hansa@airmail.cc>
sort table of required software versions alphabetically
add reference to scripts/ver_linux
Signed-off-by: Hans Anda <hansa@airmail.cc>
---
Documentation/process/changes.rst | 53 ++++++++++++++++---------------
1 file changed, 27 insertions(+), 26 deletions(-)
diff --git a/Documentation/process/changes.rst b/Documentation/process/changes.rst
index 6b373e193548..f27572d415a5 100644
--- a/Documentation/process/changes.rst
+++ b/Documentation/process/changes.rst
@@ -24,45 +24,46 @@ running, the suggested command should tell you.
Again, keep in mind that this list assumes you are already functionally
running a Linux kernel. Also, not all tools are necessary on all
systems; obviously, if you don't have any PC Card hardware, for example,
-you probably needn't concern yourself with pcmciautils.
+you probably needn't concern yourself with pcmciautils. For a list of the
+programs on your system including their version execute ./scripts/ver_linux
====================== =============== ========================================
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
--
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