* Re: [PATCH v10 01/13] kasan: sw_tags: Use arithmetic shift for shadow computation
From: Maciej Wieczor-Retman @ 2026-03-05 21:25 UTC (permalink / raw)
To: Andrey Ryabinin
Cc: Catalin Marinas, Will Deacon, Jonathan Corbet,
Alexander Potapenko, Andrey Konovalov, Dmitry Vyukov,
Vincenzo Frascino, Andrew Morton, Jan Kiszka, Kieran Bingham,
Nathan Chancellor, Nick Desaulniers, Bill Wendling, Justin Stitt,
Samuel Holland, Maciej Wieczor-Retman, linux-arm-kernel,
linux-doc, linux-kernel, kasan-dev, workflows, linux-mm, llvm
In-Reply-To: <CAPAsAGyiukChPLYO_tQci-7Bvmnnxh+w=bO6eUYLrO3RVuUThw@mail.gmail.com>
On 2026-03-06 at 06:22:32 +0900, Andrey Ryabinin wrote:
>Maciej Wieczor-Retman <m.wieczorretman@pm.me> writes:
>
>> Thanks, that looks really neat! I should've thought of that instead of making
>> separate arch versions :)
>>
>> Do you want me to attach the code you posted here to this patchset or do you
>> intend to post it yourself?
>
>I think you can just squash my diff into the subject patch.
Cool, thanks, will do!
--
Kind regards
Maciej Wieczór-Retman
^ permalink raw reply
* Re: [PATCH v10 01/13] kasan: sw_tags: Use arithmetic shift for shadow computation
From: Andrey Ryabinin @ 2026-03-05 21:22 UTC (permalink / raw)
To: Maciej Wieczor-Retman
Cc: Catalin Marinas, Will Deacon, Jonathan Corbet,
Alexander Potapenko, Andrey Konovalov, Dmitry Vyukov,
Vincenzo Frascino, Andrew Morton, Jan Kiszka, Kieran Bingham,
Nathan Chancellor, Nick Desaulniers, Bill Wendling, Justin Stitt,
Samuel Holland, Maciej Wieczor-Retman, linux-arm-kernel,
linux-doc, linux-kernel, kasan-dev, workflows, linux-mm, llvm
In-Reply-To: <aanievpHCv0Sz3Bf@wieczorr-mobl1.localdomain>
Maciej Wieczor-Retman <m.wieczorretman@pm.me> writes:
> Thanks, that looks really neat! I should've thought of that instead of making
> separate arch versions :)
>
> Do you want me to attach the code you posted here to this patchset or do you
> intend to post it yourself?
I think you can just squash my diff into the subject patch.
^ permalink raw reply
* Re: [PATCH v10 01/13] kasan: sw_tags: Use arithmetic shift for shadow computation
From: Maciej Wieczor-Retman @ 2026-03-05 20:18 UTC (permalink / raw)
To: Andrey Ryabinin
Cc: Catalin Marinas, Will Deacon, Jonathan Corbet,
Alexander Potapenko, Andrey Konovalov, Dmitry Vyukov,
Vincenzo Frascino, Andrew Morton, Jan Kiszka, Kieran Bingham,
Nathan Chancellor, Nick Desaulniers, Bill Wendling, Justin Stitt,
Samuel Holland, Maciej Wieczor-Retman, linux-arm-kernel,
linux-doc, linux-kernel, kasan-dev, workflows, linux-mm, llvm
In-Reply-To: <CAPAsAGxpHBqzppoKCrqvH0mfhEn6p0aEHR30ZifB3uv81v68EA@mail.gmail.com>
Thanks, that looks really neat! I should've thought of that instead of making
separate arch versions :)
Do you want me to attach the code you posted here to this patchset or do you
intend to post it yourself? I'm working out Dave's comments on the x86 parts and
I wanted to post v11 sometime next week.
Kind regards
Maciej Wieczór-Retman
On 2026-03-05 at 13:05:48 -0600, Andrey Ryabinin wrote:
>Maciej Wieczor-Retman <m.wieczorretman@pm.me> writes:
>
>> --- a/mm/kasan/kasan.h
>> +++ b/mm/kasan/kasan.h
>> @@ -558,6 +558,13 @@ static inline bool kasan_arch_is_ready(void) { return true; }
>> #error kasan_arch_is_ready only works in KASAN generic outline mode!
>> #endif
>>
>> +#ifndef arch_kasan_non_canonical_hook
>> +static inline bool arch_kasan_non_canonical_hook(unsigned long addr)
>> +{
>> + return false;
>> +}
>> +#endif
>> +
>> #if IS_ENABLED(CONFIG_KASAN_KUNIT_TEST)
>>
>> void kasan_kunit_test_suite_start(void);
>> diff --git a/mm/kasan/report.c b/mm/kasan/report.c
>> index 62c01b4527eb..53152d148deb 100644
>> --- a/mm/kasan/report.c
>> +++ b/mm/kasan/report.c
>> @@ -642,10 +642,19 @@ void kasan_non_canonical_hook(unsigned long addr)
>> const char *bug_type;
>>
>> /*
>> - * All addresses that came as a result of the memory-to-shadow mapping
>> - * (even for bogus pointers) must be >= KASAN_SHADOW_OFFSET.
>> + * For Generic KASAN, kasan_mem_to_shadow() uses the logical right shift
>> + * and never overflows with the chosen KASAN_SHADOW_OFFSET values. Thus,
>> + * the possible shadow addresses (even for bogus pointers) belong to a
>> + * single contiguous region that is the result of kasan_mem_to_shadow()
>> + * applied to the whole address space.
>> */
>> - if (addr < KASAN_SHADOW_OFFSET)
>> + if (IS_ENABLED(CONFIG_KASAN_GENERIC)) {
>> + if (addr < (unsigned long)kasan_mem_to_shadow((void *)(0ULL)) ||
>> + addr > (unsigned long)kasan_mem_to_shadow((void *)(~0ULL)))
>> + return;
>> + }
>> +
>> + if (arch_kasan_non_canonical_hook(addr))
>> return;
>>
>
>I've noticed that we currently classify bugs incorrectly in SW_TAGS
>mode. I've sent the fix for it [1] :
> [1] https://lkml.kernel.org/r/20260305185659.20807-1-ryabinin.a.a@gmail.com
>
>While at it, I was thinking whether we can make the logic above more
>arch/mode agnotstic and without per-arch hooks, so I've ended up with
>the following patch (it is on top of [1] fix).
>I think it should work with any arch or mode and both with signed or
>unsigned shifting.
>
>diff --git a/mm/kasan/report.c b/mm/kasan/report.c
>index e804b1e1f886..1e4521b5ef14 100644
>--- a/mm/kasan/report.c
>+++ b/mm/kasan/report.c
>@@ -640,12 +640,20 @@ void kasan_non_canonical_hook(unsigned long addr)
> {
> unsigned long orig_addr, user_orig_addr;
> const char *bug_type;
>+ void *tagged_null = set_tag(NULL, KASAN_TAG_KERNEL);
>+ void *tagged_addr = set_tag((void *)addr, KASAN_TAG_KERNEL);
>
> /*
>- * All addresses that came as a result of the memory-to-shadow mapping
>- * (even for bogus pointers) must be >= KASAN_SHADOW_OFFSET.
>+ * Filter out addresses that cannot be shadow memory accesses generated
>+ * by the compiler.
>+ *
>+ * In SW_TAGS mode, when computing a shadow address, the compiler always
>+ * sets the kernel tag (some top bits) on the pointer *before* computing
>+ * the memory-to-shadow mapping. As a result, valid shadow addresses
>+ * are derived from tagged kernel pointers.
> */
>- if (addr < KASAN_SHADOW_OFFSET)
>+ if (tagged_addr < kasan_mem_to_shadow(tagged_null) ||
>+ tagged_addr > kasan_mem_to_shadow((void *)(~0ULL)))
> return;
>
> orig_addr = (unsigned long)kasan_shadow_to_mem((void *)addr);
>@@ -670,7 +678,7 @@ void kasan_non_canonical_hook(unsigned long addr)
> } else if (user_orig_addr < TASK_SIZE) {
> bug_type = "probably user-memory-access";
> orig_addr = user_orig_addr;
>- } else if (addr_in_shadow((void *)addr))
>+ } else if (addr_in_shadow(tagged_addr))
> bug_type = "probably wild-memory-access";
> else
> bug_type = "maybe wild-memory-access";
>--
>2.52.0
^ permalink raw reply
* Re: [PATCH v10 01/13] kasan: sw_tags: Use arithmetic shift for shadow computation
From: Andrey Ryabinin @ 2026-03-05 19:05 UTC (permalink / raw)
To: Maciej Wieczor-Retman, Catalin Marinas, Will Deacon,
Jonathan Corbet, Alexander Potapenko, Andrey Konovalov,
Dmitry Vyukov, Vincenzo Frascino, Andrew Morton, Jan Kiszka,
Kieran Bingham, Nathan Chancellor, Nick Desaulniers,
Bill Wendling, Justin Stitt
Cc: Samuel Holland, Maciej Wieczor-Retman, linux-arm-kernel,
linux-doc, linux-kernel, kasan-dev, workflows, linux-mm, llvm
In-Reply-To: <bd935d83b2fe3ddfedff052323a2b84e85061042.1770232424.git.m.wieczorretman@pm.me>
Maciej Wieczor-Retman <m.wieczorretman@pm.me> writes:
> --- a/mm/kasan/kasan.h
> +++ b/mm/kasan/kasan.h
> @@ -558,6 +558,13 @@ static inline bool kasan_arch_is_ready(void) { return true; }
> #error kasan_arch_is_ready only works in KASAN generic outline mode!
> #endif
>
> +#ifndef arch_kasan_non_canonical_hook
> +static inline bool arch_kasan_non_canonical_hook(unsigned long addr)
> +{
> + return false;
> +}
> +#endif
> +
> #if IS_ENABLED(CONFIG_KASAN_KUNIT_TEST)
>
> void kasan_kunit_test_suite_start(void);
> diff --git a/mm/kasan/report.c b/mm/kasan/report.c
> index 62c01b4527eb..53152d148deb 100644
> --- a/mm/kasan/report.c
> +++ b/mm/kasan/report.c
> @@ -642,10 +642,19 @@ void kasan_non_canonical_hook(unsigned long addr)
> const char *bug_type;
>
> /*
> - * All addresses that came as a result of the memory-to-shadow mapping
> - * (even for bogus pointers) must be >= KASAN_SHADOW_OFFSET.
> + * For Generic KASAN, kasan_mem_to_shadow() uses the logical right shift
> + * and never overflows with the chosen KASAN_SHADOW_OFFSET values. Thus,
> + * the possible shadow addresses (even for bogus pointers) belong to a
> + * single contiguous region that is the result of kasan_mem_to_shadow()
> + * applied to the whole address space.
> */
> - if (addr < KASAN_SHADOW_OFFSET)
> + if (IS_ENABLED(CONFIG_KASAN_GENERIC)) {
> + if (addr < (unsigned long)kasan_mem_to_shadow((void *)(0ULL)) ||
> + addr > (unsigned long)kasan_mem_to_shadow((void *)(~0ULL)))
> + return;
> + }
> +
> + if (arch_kasan_non_canonical_hook(addr))
> return;
>
I've noticed that we currently classify bugs incorrectly in SW_TAGS
mode. I've sent the fix for it [1] :
[1] https://lkml.kernel.org/r/20260305185659.20807-1-ryabinin.a.a@gmail.com
While at it, I was thinking whether we can make the logic above more
arch/mode agnotstic and without per-arch hooks, so I've ended up with
the following patch (it is on top of [1] fix).
I think it should work with any arch or mode and both with signed or
unsigned shifting.
diff --git a/mm/kasan/report.c b/mm/kasan/report.c
index e804b1e1f886..1e4521b5ef14 100644
--- a/mm/kasan/report.c
+++ b/mm/kasan/report.c
@@ -640,12 +640,20 @@ void kasan_non_canonical_hook(unsigned long addr)
{
unsigned long orig_addr, user_orig_addr;
const char *bug_type;
+ void *tagged_null = set_tag(NULL, KASAN_TAG_KERNEL);
+ void *tagged_addr = set_tag((void *)addr, KASAN_TAG_KERNEL);
/*
- * All addresses that came as a result of the memory-to-shadow mapping
- * (even for bogus pointers) must be >= KASAN_SHADOW_OFFSET.
+ * Filter out addresses that cannot be shadow memory accesses generated
+ * by the compiler.
+ *
+ * In SW_TAGS mode, when computing a shadow address, the compiler always
+ * sets the kernel tag (some top bits) on the pointer *before* computing
+ * the memory-to-shadow mapping. As a result, valid shadow addresses
+ * are derived from tagged kernel pointers.
*/
- if (addr < KASAN_SHADOW_OFFSET)
+ if (tagged_addr < kasan_mem_to_shadow(tagged_null) ||
+ tagged_addr > kasan_mem_to_shadow((void *)(~0ULL)))
return;
orig_addr = (unsigned long)kasan_shadow_to_mem((void *)addr);
@@ -670,7 +678,7 @@ void kasan_non_canonical_hook(unsigned long addr)
} else if (user_orig_addr < TASK_SIZE) {
bug_type = "probably user-memory-access";
orig_addr = user_orig_addr;
- } else if (addr_in_shadow((void *)addr))
+ } else if (addr_in_shadow(tagged_addr))
bug_type = "probably wild-memory-access";
else
bug_type = "maybe wild-memory-access";
--
2.52.0
^ permalink raw reply related
* [PATCH net-next] docs: netdev: refine netdevsim testing guidance
From: Jakub Kicinski @ 2026-03-04 15:16 UTC (permalink / raw)
To: davem
Cc: netdev, edumazet, pabeni, andrew+netdev, horms, Jakub Kicinski,
corbet, skhan, workflows, linux-doc
The library to create tests for both NIC HW and netdevsim has existed
for almost a year. netdevsim-only tests we get increasingly feel like
a waste, we should try to write tests that work both on netdevsim and
real HW. Refine the guidance accordingly.
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
---
CC: corbet@lwn.net
CC: skhan@linuxfoundation.org
CC: workflows@vger.kernel.org
CC: linux-doc@vger.kernel.org
---
Documentation/process/maintainer-netdev.rst | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/Documentation/process/maintainer-netdev.rst b/Documentation/process/maintainer-netdev.rst
index 6bce4507d5d3..3aa13bc2405d 100644
--- a/Documentation/process/maintainer-netdev.rst
+++ b/Documentation/process/maintainer-netdev.rst
@@ -479,8 +479,14 @@ netdevsim
``netdevsim`` is a test driver which can be used to exercise driver
configuration APIs without requiring capable hardware.
-Mock-ups and tests based on ``netdevsim`` are strongly encouraged when
-adding new APIs, but ``netdevsim`` in itself is **not** considered
+Mock-ups and tests based on ``netdevsim`` are encouraged when
+adding new APIs with complex logic in the stack. The tests should
+be written so that they can run both against ``netdevsim`` and a real
+device (see ``tools/testing/selftests/drivers/net/README.rst``).
+``netdevsim``-only tests should focus on testing corner cases
+and failure paths in the core which are hard to exercise with a real driver.
+
+``netdevsim`` in itself is **not** considered
a use case/user. You must also implement the new APIs in a real driver.
We give no guarantees that ``netdevsim`` won't change in the future
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v3 0/2] workflow, scripts: sort changes.rst and ver_linux
From: Jonathan Corbet @ 2026-03-03 19:27 UTC (permalink / raw)
To: Manuel, Collin Funk, Shuah Khan; +Cc: workflows, linux-doc, linux-kernel
In-Reply-To: <8dec205e406364d14f7ddf3ea11695407a7980b4.camel@airmail.cc>
Manuel <manuelebner@airmail.cc> writes:
>> - Why I'm getting the same series from a completely different identity;
>> the first set came from "Hans Anda"
>
> I messed this up, let me explain:
> I used to keep my real name out of the internet. The last couple days i changed
> my mind. I guess it's ok when my real name shows up in git blame.
> I really should have added a note about that. sorry.
So you sent me patches under a false name? That's ... not the best way
to start building trust.
>> - Why my request to separate out the logically different changes were
>> ignored.
>
> I split the patch into a series like i responded on Tue, 24 Feb 2026 08:13:02
>>>i will make a Patch series with the files split.
>
> Do you want me to send two patches, which are not in a patch series?
No, I want you to separate the logical changes.
- Sorting the entries in the list is one logical change.
- Adding new items is a different one. If you mix it in with the sort,
nobody can really see which items are new.
See what I'm getting at?
jon
^ permalink raw reply
* Re: [PATCH] Documentation/maintainer-tip: Fix grammar
From: Jonathan Corbet @ 2026-03-03 16:59 UTC (permalink / raw)
To: Thorsten Blum, Shuah Khan
Cc: Thorsten Blum, workflows, linux-doc, linux-kernel
In-Reply-To: <20260302135141.3213-2-thorsten.blum@linux.dev>
Thorsten Blum <thorsten.blum@linux.dev> writes:
> s/a empty newline/an empty newline/
>
> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
> ---
> Documentation/process/maintainer-tip.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/process/maintainer-tip.rst b/Documentation/process/maintainer-tip.rst
> index 41d5855700cd..b2b14439be22 100644
> --- a/Documentation/process/maintainer-tip.rst
> +++ b/Documentation/process/maintainer-tip.rst
> @@ -352,7 +352,7 @@ following tag ordering scheme:
> Changelog text starts here....
>
> so the authorship is preserved. The 'From:' line has to be followed
> - by a empty newline. If that 'From:' line is missing, then the patch
> + by an empty newline. If that 'From:' line is missing, then the patch
> would be attributed to the person who sent (transported, handled) it.
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH v3 0/2] workflow, scripts: sort changes.rst and ver_linux
From: Jonathan Corbet @ 2026-03-03 16:58 UTC (permalink / raw)
To: Manuel Ebner, Collin Funk, Shuah Khan
Cc: workflows, linux-doc, linux-kernel, Manuel Ebner
In-Reply-To: <20260302182405.86829-2-manuelebner@airmail.cc>
Manuel Ebner <manuelebner@airmail.cc> writes:
> It is a pain in the ass to compare the software versions on the running
> system (scripts/ver_linux) with the minimal required versions (changes.rst).
> Sorting both lists the same way makes side-by-side comparisons a simple task.
>
> [v2] -> [v3]:
> fix changelog
> changes.rst:
> needn't -> do not need to
> add gdb 7.2
> ver_linux:
> /Changes.rst -> /changes.rst
> add gdb
Please explain to me:
- Why I am getting multiple copies of the same patches
- Why I'm getting the same series from a completely different identity;
the first set came from "Hans Anda"
- Why my request to separate out the logically different changes were
ignored.
Thanks,
jon
^ permalink raw reply
* Re: [PATCH] kfence: add kfence.fault parameter
From: Alexander Potapenko @ 2026-03-03 15:50 UTC (permalink / raw)
To: Marco Elver
Cc: Andrew Morton, Dmitry Vyukov, Jonathan Corbet, Shuah Khan,
linux-doc, linux-kernel, kasan-dev, workflows, linux-mm,
Ernesto Martinez Garcia, Kees Cook
In-Reply-To: <CANpmjNNfz9TQcnZWkTXEAzVNdUAAYfBv0-FB-e7oV5PCfsYR5Q@mail.gmail.com>
On Tue, Mar 3, 2026 at 4:23 PM Marco Elver <elver@google.com> wrote:
>
> On Tue, 3 Mar 2026 at 12:20, Alexander Potapenko <glider@google.com> wrote:
> >
> > > @@ -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();
> >
> > By the way, should we also check for kfence_enabled when reporting errors?
>
> Not sure, I think it might be redundant - I don't see a way we should
> get to the reporting path if KFENCE is disabled. And if there
> currently is a way to get there, we should check kfence_enabled before
> (such as in this panic notifier now).
>
> > > @@ -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. */
> >
> > If kfence_handle_fault() oopses, kfence_unprotect() will never be
> > called, is that the desired behavior?
>
> It is - consider multiple kernel threads running into the same OOB or
> UAF. We should oops them all, otherwise this change is almost no
> benefit.
>
> > > /* Require non-NULL meta, except if KFENCE_ERROR_INVALID. */
> > > if (WARN_ON(type != KFENCE_ERROR_INVALID && !meta))
> > > - return;
> > > + return KFENCE_FAULT_NONE;
> >
> > We explicitly don't panic here; guess it should be fine...
>
> Yes - it's a KFENCE bug if we get here, the WARN is fine.
Reviewed-by: Alexander Potapenko <glider@google.com>
^ permalink raw reply
* Re: [PATCH] kfence: add kfence.fault parameter
From: Marco Elver @ 2026-03-03 15:22 UTC (permalink / raw)
To: Alexander Potapenko
Cc: Andrew Morton, Dmitry Vyukov, Jonathan Corbet, Shuah Khan,
linux-doc, linux-kernel, kasan-dev, workflows, linux-mm,
Ernesto Martinez Garcia, Kees Cook
In-Reply-To: <CAG_fn=WAwHUpoay2kY6rkEZQGYxoDGVJYf5B59Y80ht7++Lmqw@mail.gmail.com>
On Tue, 3 Mar 2026 at 12:20, Alexander Potapenko <glider@google.com> wrote:
>
> > @@ -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();
>
> By the way, should we also check for kfence_enabled when reporting errors?
Not sure, I think it might be redundant - I don't see a way we should
get to the reporting path if KFENCE is disabled. And if there
currently is a way to get there, we should check kfence_enabled before
(such as in this panic notifier now).
> > @@ -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. */
>
> If kfence_handle_fault() oopses, kfence_unprotect() will never be
> called, is that the desired behavior?
It is - consider multiple kernel threads running into the same OOB or
UAF. We should oops them all, otherwise this change is almost no
benefit.
> > /* Require non-NULL meta, except if KFENCE_ERROR_INVALID. */
> > if (WARN_ON(type != KFENCE_ERROR_INVALID && !meta))
> > - return;
> > + return KFENCE_FAULT_NONE;
>
> We explicitly don't panic here; guess it should be fine...
Yes - it's a KFENCE bug if we get here, the WARN is fine.
^ permalink raw reply
* Re: [PATCH v1] kasan: docs: SLUB is the only remaining slab implementation
From: Vlastimil Babka (SUSE) @ 2026-03-03 13:33 UTC (permalink / raw)
To: David Hildenbrand (Arm), linux-kernel
Cc: kasan-dev, workflows, linux-doc, Andrew Morton, Andrey Ryabinin,
Alexander Potapenko, Andrey Konovalov, Dmitry Vyukov,
Vincenzo Frascino, Jonathan Corbet, Shuah Khan
In-Reply-To: <20260303120416.62580-1-david@kernel.org>
On 3/3/26 13:04, David Hildenbrand (Arm) wrote:
> We have only the SLUB implementation left in the kernel (referred to
> as "slab"). Therefore, there is nothing special regarding KASAN modes
> when it comes to the slab allocator anymore.
Right, thanks.
> Drop the stale comment regarding differing SLUB vs. SLAB support.
>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
> Cc: Alexander Potapenko <glider@google.com>
> Cc: Andrey Konovalov <andreyknvl@gmail.com>
> Cc: Dmitry Vyukov <dvyukov@google.com>
> Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: Shuah Khan <skhan@linuxfoundation.org>
> Cc: Vlastimil Babka <vbabka@kernel.org>
> Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
> ---
> Documentation/dev-tools/kasan.rst | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/Documentation/dev-tools/kasan.rst b/Documentation/dev-tools/kasan.rst
> index a034700da7c4..4968b2aa60c8 100644
> --- a/Documentation/dev-tools/kasan.rst
> +++ b/Documentation/dev-tools/kasan.rst
> @@ -75,9 +75,6 @@ Software Tag-Based KASAN supports slab, page_alloc, vmalloc, and stack memory.
> Hardware Tag-Based KASAN supports slab, page_alloc, and non-executable vmalloc
> memory.
>
> -For slab, both software KASAN modes support SLUB and SLAB allocators, while
> -Hardware Tag-Based KASAN only supports SLUB.
> -
> Usage
> -----
>
^ permalink raw reply
* [PATCH v1] kasan: docs: SLUB is the only remaining slab implementation
From: David Hildenbrand (Arm) @ 2026-03-03 12:04 UTC (permalink / raw)
To: linux-kernel
Cc: kasan-dev, workflows, linux-doc, David Hildenbrand (Arm),
Andrew Morton, Andrey Ryabinin, Alexander Potapenko,
Andrey Konovalov, Dmitry Vyukov, Vincenzo Frascino,
Jonathan Corbet, Shuah Khan, Vlastimil Babka
We have only the SLUB implementation left in the kernel (referred to
as "slab"). Therefore, there is nothing special regarding KASAN modes
when it comes to the slab allocator anymore.
Drop the stale comment regarding differing SLUB vs. SLAB support.
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Andrey Konovalov <andreyknvl@gmail.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Shuah Khan <skhan@linuxfoundation.org>
Cc: Vlastimil Babka <vbabka@kernel.org>
Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
---
Documentation/dev-tools/kasan.rst | 3 ---
1 file changed, 3 deletions(-)
diff --git a/Documentation/dev-tools/kasan.rst b/Documentation/dev-tools/kasan.rst
index a034700da7c4..4968b2aa60c8 100644
--- a/Documentation/dev-tools/kasan.rst
+++ b/Documentation/dev-tools/kasan.rst
@@ -75,9 +75,6 @@ Software Tag-Based KASAN supports slab, page_alloc, vmalloc, and stack memory.
Hardware Tag-Based KASAN supports slab, page_alloc, and non-executable vmalloc
memory.
-For slab, both software KASAN modes support SLUB and SLAB allocators, while
-Hardware Tag-Based KASAN only supports SLUB.
-
Usage
-----
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] kfence: add kfence.fault parameter
From: Alexander Potapenko @ 2026-03-03 11:19 UTC (permalink / raw)
To: Marco Elver
Cc: Andrew Morton, 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>
> @@ -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();
By the way, should we also check for kfence_enabled when reporting errors?
> @@ -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. */
If kfence_handle_fault() oopses, kfence_unprotect() will never be
called, is that the desired behavior?
> /* Require non-NULL meta, except if KFENCE_ERROR_INVALID. */
> if (WARN_ON(type != KFENCE_ERROR_INVALID && !meta))
> - return;
> + return KFENCE_FAULT_NONE;
We explicitly don't panic here; guess it should be fine...
^ permalink raw reply
* [PATCH v3 0/2] workflow, scripts: sort changes.rst and ver_linux
From: Manuel Ebner @ 2026-03-02 18:24 UTC (permalink / raw)
To: Jonathan Corbet, Collin Funk, Shuah Khan
Cc: workflows, linux-doc, linux-kernel, Manuel Ebner
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).
Sorting both lists the same way makes side-by-side comparisons a simple task.
[v2] -> [v3]:
fix changelog
changes.rst:
needn't -> do not need to
add gdb 7.2
ver_linux:
/Changes.rst -> /changes.rst
add gdb
[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: Manuel Ebner <manuelebner@airmail.cc>
^ permalink raw reply
* [PATCH v3 1/2] workflow: process/changes.rst: sort and cleanup list
From: Manuel Ebner @ 2026-03-02 18:26 UTC (permalink / raw)
To: Jonathan Corbet, Collin Funk, Shuah Khan
Cc: workflows, linux-doc, linux-kernel, Manuel Ebner
In-Reply-To: <20260302182405.86829-2-manuelebner@airmail.cc>
It is a pain in the ass to compare the software versions on the running
system with the minimal required versions (process/changes.rst).
Sorting both lists the same way makes side-by-side comparisons a simple task.
add gdb version 7.2 as mentioned in:
Documentation/process/debugging/gdb-kernel-debugging.rst
scripts/gdb/vmlinux-gdb.py
sort table of required software versions alphabetically
add reference to scripts/ver_linux
needn't -> do not need to
Signed-off-by: Manuel Ebner <manuelebner@airmail.cc>
---
Documentation/process/changes.rst | 54 ++++++++++++++++---------------
1 file changed, 28 insertions(+), 26 deletions(-)
diff --git a/Documentation/process/changes.rst b/Documentation/process/changes.rst
index 6b373e193548..41c97163e67e 100644
--- a/Documentation/process/changes.rst
+++ b/Documentation/process/changes.rst
@@ -24,45 +24,47 @@ 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 do not need to 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
+gdb 7.2 gdb --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
* [PATCH] Documentation/maintainer-tip: Fix grammar
From: Thorsten Blum @ 2026-03-02 13:51 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan
Cc: Thorsten Blum, workflows, linux-doc, linux-kernel
s/a empty newline/an empty newline/
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
Documentation/process/maintainer-tip.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/process/maintainer-tip.rst b/Documentation/process/maintainer-tip.rst
index 41d5855700cd..b2b14439be22 100644
--- a/Documentation/process/maintainer-tip.rst
+++ b/Documentation/process/maintainer-tip.rst
@@ -352,7 +352,7 @@ following tag ordering scheme:
Changelog text starts here....
so the authorship is preserved. The 'From:' line has to be followed
- by a empty newline. If that 'From:' line is missing, then the patch
+ by an empty newline. If that 'From:' line is missing, then the patch
would be attributed to the person who sent (transported, handled) it.
The 'From:' line is automatically removed when the patch is applied
and does not show up in the final git changelog. It merely affects
--
Thorsten Blum <thorsten.blum@linux.dev>
GPG: 1D60 735E 8AEF 3BE4 73B6 9D84 7336 78FD 8DFE EAD4
^ permalink raw reply related
* [PATCH v4] LICENSES: Explicitly allow SPDX-FileCopyrightText
From: Krzysztof Kozlowski @ 2026-03-01 14:33 UTC (permalink / raw)
To: Thomas Gleixner, Greg Kroah-Hartman, Jonathan Corbet, Shuah Khan,
Andy Whitcroft, Joe Perches, Dwaipayan Ray, Lukas Bulwahn,
linux-spdx, workflows, linux-doc, linux-kernel
Cc: Krzysztof Kozlowski, Laurent Pinchart
Sources already have SPDX-FileCopyrightText (~40 instances) and more
appear on the mailing list, so document that it is allowed. On the
other hand SPDX defines several other tags like SPDX-FileType, so add
checkpatch rule to narrow desired tags only to two of them - license and
copyright. That way no new tags would sneak in to the kernel unnoticed.
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Joe Perches <joe@perches.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Other way would be to remove SPDX-FileCopyrightText from existing files
and disallow this, but one way or another we should be explicit about
it. Otherwise people will be sending more of these and each maintainer
would need to make their own call.
Changes in v4:
1. Grammar - "unsupported" -> "disallowed"
2. Add tag
Changes in v3:
1. Typo "or multiple"
Changes in v2:
1. Doc adjustments based on feedback from Greg and Laurent.
2. "unused" -> "unsupported"
3. Drop redundant blank line
---
Documentation/process/license-rules.rst | 7 +++++--
scripts/checkpatch.pl | 8 ++++++++
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/Documentation/process/license-rules.rst b/Documentation/process/license-rules.rst
index 59a7832df7d0..b0176bb8a465 100644
--- a/Documentation/process/license-rules.rst
+++ b/Documentation/process/license-rules.rst
@@ -63,8 +63,11 @@ License identifier syntax
The SPDX license identifier in kernel files shall be added at the first
possible line in a file which can contain a comment. For the majority
of files this is the first line, except for scripts which require the
- '#!PATH_TO_INTERPRETER' in the first line. For those scripts the SPDX
- identifier goes into the second line.
+ '#!PATH_TO_INTERPRETER' in the first line. For those scripts, the SPDX
+ license identifier goes into the second line.
+
+ The license identifier line can then be followed by one or multiple
+ SPDX-FileCopyrightText lines if desired.
|
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index bec7930cdd66..c0025d2f5741 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -3856,6 +3856,14 @@ sub process {
"Misplaced SPDX-License-Identifier tag - use line $checklicenseline instead\n" . $herecurr);
}
+# check for disallowed SPDX file tags
+ if ($rawline =~ /\bSPDX-.*:/ &&
+ $rawline !~ /\bSPDX-License-Identifier:/ &&
+ $rawline !~ /\bSPDX-FileCopyrightText:/) {
+ WARN("SPDX_LICENSE_TAG",
+ "Disallowed SPDX tag\n" . $herecurr);
+ }
+
# line length limit (with some exclusions)
#
# There are a few types of lines that may extend beyond $max_line_length:
--
2.51.0
^ permalink raw reply related
* Re: [PATCH v3] LICENSES: Explicitly allow SPDX-FileCopyrightText
From: Krzysztof Kozlowski @ 2026-03-01 14:27 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Thomas Gleixner, Greg Kroah-Hartman, Jonathan Corbet, Shuah Khan,
Andy Whitcroft, Joe Perches, Dwaipayan Ray, Lukas Bulwahn,
linux-spdx, workflows, linux-doc, linux-kernel
In-Reply-To: <20260301134939.GA2879901@killaraus.ideasonboard.com>
On 01/03/2026 14:49, Laurent Pinchart wrote:
>>
>> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
>> index bec7930cdd66..e317cf2ffc58 100755
>> --- a/scripts/checkpatch.pl
>> +++ b/scripts/checkpatch.pl
>> @@ -3856,6 +3856,14 @@ sub process {
>> "Misplaced SPDX-License-Identifier tag - use line $checklicenseline instead\n" . $herecurr);
>> }
>>
>> +# check for unsupported SPDX file tags
>> + if ($rawline =~ /\bSPDX-.*:/ &&
>> + $rawline !~ /\bSPDX-License-Identifier:/ &&
>> + $rawline !~ /\bSPDX-FileCopyrightText:/) {
>> + WARN("SPDX_LICENSE_TAG",
>> + "Unsupported SPDX tag\n" . $herecurr);
>
> I'd write "nonallowed" instead of "unsupported", possibly because I may
> not be familiar with the usage of "supported" in this acceptation. With
> or without that change,
My two dicts flag "nonallowed" as a mistake while disagreeing with
https://en.wiktionary.org/wiki/nonallowed, thus just in case I will
write "disallowed".
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3] LICENSES: Explicitly allow SPDX-FileCopyrightText
From: Laurent Pinchart @ 2026-03-01 13:49 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Thomas Gleixner, Greg Kroah-Hartman, Jonathan Corbet, Shuah Khan,
Andy Whitcroft, Joe Perches, Dwaipayan Ray, Lukas Bulwahn,
linux-spdx, workflows, linux-doc, linux-kernel
In-Reply-To: <20260301134054.44229-2-krzysztof.kozlowski@oss.qualcomm.com>
On Sun, Mar 01, 2026 at 02:40:55PM +0100, Krzysztof Kozlowski wrote:
> Sources already have SPDX-FileCopyrightText (~40 instances) and more
> appear on the mailing list, so document that it is allowed. On the
> other hand SPDX defines several other tags like SPDX-FileType, so add
> checkpatch rule to narrow desired tags only to two of them - license and
> copyright. That way no new tags would sneak in to the kernel unnoticed.
>
> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Joe Perches <joe@perches.com>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>
> ---
>
> Other way would be to remove SPDX-FileCopyrightText from existing files
> and disallow this, but one way or another we should be explicit about
> it. Otherwise people will be sending more of these and each maintainer
> would need to make their own call.
Ack.
> Changes in v3:
> 1. Typo "or multiple"
>
> Changes in v2:
> 1. Doc adjustments based on feedback from Greg and Laurent.
> 2. "unused" -> "unsupported"
> 3. Drop redundant blank line
> ---
> Documentation/process/license-rules.rst | 7 +++++--
> scripts/checkpatch.pl | 8 ++++++++
> 2 files changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/process/license-rules.rst b/Documentation/process/license-rules.rst
> index 59a7832df7d0..b0176bb8a465 100644
> --- a/Documentation/process/license-rules.rst
> +++ b/Documentation/process/license-rules.rst
> @@ -63,8 +63,11 @@ License identifier syntax
> The SPDX license identifier in kernel files shall be added at the first
> possible line in a file which can contain a comment. For the majority
> of files this is the first line, except for scripts which require the
> - '#!PATH_TO_INTERPRETER' in the first line. For those scripts the SPDX
> - identifier goes into the second line.
> + '#!PATH_TO_INTERPRETER' in the first line. For those scripts, the SPDX
> + license identifier goes into the second line.
> +
> + The license identifier line can then be followed by one or multiple
> + SPDX-FileCopyrightText lines if desired.
>
> |
>
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index bec7930cdd66..e317cf2ffc58 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -3856,6 +3856,14 @@ sub process {
> "Misplaced SPDX-License-Identifier tag - use line $checklicenseline instead\n" . $herecurr);
> }
>
> +# check for unsupported SPDX file tags
> + if ($rawline =~ /\bSPDX-.*:/ &&
> + $rawline !~ /\bSPDX-License-Identifier:/ &&
> + $rawline !~ /\bSPDX-FileCopyrightText:/) {
> + WARN("SPDX_LICENSE_TAG",
> + "Unsupported SPDX tag\n" . $herecurr);
I'd write "nonallowed" instead of "unsupported", possibly because I may
not be familiar with the usage of "supported" in this acceptation. With
or without that change,
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> + }
> +
> # line length limit (with some exclusions)
> #
> # There are a few types of lines that may extend beyond $max_line_length:
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH v3] LICENSES: Explicitly allow SPDX-FileCopyrightText
From: Krzysztof Kozlowski @ 2026-03-01 13:40 UTC (permalink / raw)
To: Thomas Gleixner, Greg Kroah-Hartman, Jonathan Corbet, Shuah Khan,
Andy Whitcroft, Joe Perches, Dwaipayan Ray, Lukas Bulwahn,
linux-spdx, workflows, linux-doc, linux-kernel
Cc: Krzysztof Kozlowski, Laurent Pinchart
Sources already have SPDX-FileCopyrightText (~40 instances) and more
appear on the mailing list, so document that it is allowed. On the
other hand SPDX defines several other tags like SPDX-FileType, so add
checkpatch rule to narrow desired tags only to two of them - license and
copyright. That way no new tags would sneak in to the kernel unnoticed.
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Joe Perches <joe@perches.com>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Other way would be to remove SPDX-FileCopyrightText from existing files
and disallow this, but one way or another we should be explicit about
it. Otherwise people will be sending more of these and each maintainer
would need to make their own call.
Changes in v3:
1. Typo "or multiple"
Changes in v2:
1. Doc adjustments based on feedback from Greg and Laurent.
2. "unused" -> "unsupported"
3. Drop redundant blank line
---
Documentation/process/license-rules.rst | 7 +++++--
scripts/checkpatch.pl | 8 ++++++++
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/Documentation/process/license-rules.rst b/Documentation/process/license-rules.rst
index 59a7832df7d0..b0176bb8a465 100644
--- a/Documentation/process/license-rules.rst
+++ b/Documentation/process/license-rules.rst
@@ -63,8 +63,11 @@ License identifier syntax
The SPDX license identifier in kernel files shall be added at the first
possible line in a file which can contain a comment. For the majority
of files this is the first line, except for scripts which require the
- '#!PATH_TO_INTERPRETER' in the first line. For those scripts the SPDX
- identifier goes into the second line.
+ '#!PATH_TO_INTERPRETER' in the first line. For those scripts, the SPDX
+ license identifier goes into the second line.
+
+ The license identifier line can then be followed by one or multiple
+ SPDX-FileCopyrightText lines if desired.
|
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index bec7930cdd66..e317cf2ffc58 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -3856,6 +3856,14 @@ sub process {
"Misplaced SPDX-License-Identifier tag - use line $checklicenseline instead\n" . $herecurr);
}
+# check for unsupported SPDX file tags
+ if ($rawline =~ /\bSPDX-.*:/ &&
+ $rawline !~ /\bSPDX-License-Identifier:/ &&
+ $rawline !~ /\bSPDX-FileCopyrightText:/) {
+ WARN("SPDX_LICENSE_TAG",
+ "Unsupported SPDX tag\n" . $herecurr);
+ }
+
# line length limit (with some exclusions)
#
# There are a few types of lines that may extend beyond $max_line_length:
--
2.51.0
^ permalink raw reply related
* Re: [PATCH v10 13/13] x86/kasan: Make software tag-based kasan available
From: Maciej Wieczor-Retman @ 2026-02-27 8:27 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: <fb8d8d51-66c8-4cb1-8b14-bc670c629afa@intel.com>
On 2026-02-26 at 15:29:15 -0800, Dave Hansen wrote:
>On 2/24/26 01:10, Maciej Wieczor-Retman wrote:
>>>> - 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/
>
>
>I'd rather this be:
>
> ffdf000000000000 | -8.25 PB | fffffbffffffffff | ~8 PB | KASAN shadow memory[1]
>
>...
>
>1. talk about the ranges here. Maybe: Addresses <ffeffc0000000000 are used by
> KASAN "generic mode" only. Addresses >=ffeffc0000000000 can additionally
> be used by the software tag-based mode.
>
>Or, list both ranges as separate:
>
> ffdf000000000000 | -8.25 PB | ffeffbffffffffff | ~8 PB | KASAN shadow memory (generic mode only)
> ffeffc0000000000 | -6 PB | fffffbffffffffff | 4 PB | KASAN shadow memory (generic or
> software tag-based)
>and describe the same use (generic mode) twice.
Thanks, I like the first option, I'll work on that.
--
Kind regards
Maciej Wieczór-Retman
^ permalink raw reply
* Re: [PATCH v10 13/13] x86/kasan: Make software tag-based kasan available
From: Dave Hansen @ 2026-02-26 23:29 UTC (permalink / raw)
To: Maciej Wieczor-Retman
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: <aZ1qOpMc9PohArcL@wieczorr-mobl1.localdomain>
On 2/24/26 01:10, Maciej Wieczor-Retman wrote:
>>> - 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/
I'd rather this be:
ffdf000000000000 | -8.25 PB | fffffbffffffffff | ~8 PB | KASAN shadow memory[1]
...
1. talk about the ranges here. Maybe: Addresses <ffeffc0000000000 are used by
KASAN "generic mode" only. Addresses >=ffeffc0000000000 can additionally
be used by the software tag-based mode.
Or, list both ranges as separate:
ffdf000000000000 | -8.25 PB | ffeffbffffffffff | ~8 PB | KASAN shadow memory (generic mode only)
ffeffc0000000000 | -6 PB | fffffbffffffffff | 4 PB | KASAN shadow memory (generic or
software tag-based)
and describe the same use (generic mode) twice.
^ permalink raw reply
* Re: [PATCH] Add short author date to Fixes tag
From: Jacob Keller @ 2026-02-26 23:24 UTC (permalink / raw)
To: Steven Rostedt, Alejandro Colomar
Cc: Greg Kroah-Hartman, Mark Brown, Sasha Levin, Geert Uytterhoeven,
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: <20260225190630.1834f850@fedora>
On 2/25/2026 4:08 PM, Steven Rostedt wrote:
> 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.
>
Strictly speaking, I've asked about inserting the data before because
this form:
a2e459555c5f ("shmem: stable directory offsets", 2023-08-09)
is fairly common within the git development community, but I think that
community has significantly less tooling around parsing the contents.
The arguments laid out here are pretty compelling that this has no value
to the Kernel community. If you are worried about disambiguation, adding
more characters to the hash is preferable (at one point 7 or 8
characters was sufficient to provide uniqueness, but now we use 12
characters).
Despite my original comments about liking the format with date, I also
concur with everyone here that it doesn't make sense to change the
format. I just modified my global alias and set one different for the
git projects vs the Linux kernel project. That way my aliases
(git-whatis and git-fixes) will generate the appropriate format for the
given project.
Thanks,
Jake
> Sorry,
>
> -- Steve
>
^ permalink raw reply
* [PATCH v2 2/2] scripts: ver_linux: expand and sort
From: Hans Anda @ 2026-02-26 10:14 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>
Add missing tools in ver_linux
(bash, bc, bindgen, bindutils, btrfs, clang, e2fsck, grub2, awk, tar,
gtags, iptables, kmod, mcelog, mkimage, openssl, pahole, python, Rust,
sphinx, squashfs-tools, udev)
sort output alphabetically
fix path to changes.rst
Signed-off-by: Hans Anda <hansa@airmail.cc>
---
scripts/ver_linux | 58 +++++++++++++++++++++++++++++++----------------
1 file changed, 39 insertions(+), 19 deletions(-)
diff --git a/scripts/ver_linux b/scripts/ver_linux
index d6f2362d3792..51e632adf999 100755
--- a/scripts/ver_linux
+++ b/scripts/ver_linux
@@ -7,7 +7,7 @@
BEGIN {
usage = "If some fields are empty or look unusual you may have an old version.\n"
- usage = usage "Compare to the current minimal requirements in Documentation/Changes.\n"
+ usage = usage "Compare to the current minimal requirements in Documentation/process/Changes.rst\n"
print usage
system("uname -a")
@@ -17,37 +17,57 @@ BEGIN {
libc = "libc[.]so[.][0-9]+$"
libcpp = "(libg|stdc)[+]+[.]so([.][0-9]+)+$"
- printversion("GNU C", version("gcc -dumpversion"))
- printversion("GNU Make", version("make --version"))
+ printversion("bash", version("bash --version"))
+ printversion("bc", version("bc --version"))
+ printversion("bindgen", version("bindgen --version"))
printversion("Binutils", version("ld -v"))
- printversion("Util-linux", version("mount --version"))
- printversion("Mount", version("mount --version"))
- printversion("Module-init-tools", version("depmod -V"))
- printversion("E2fsprogs", version("tune2fs"))
- printversion("Jfsutils", version("fsck.jfs -V"))
- printversion("Xfsprogs", version("xfs_db -V"))
- printversion("Pcmciautils", version("pccardctl -V"))
- printversion("Pcmcia-cs", version("cardmgr -V"))
- printversion("Quota-tools", version("quota -V"))
- printversion("PPP", version("pppd --version"))
- printversion("Isdn4k-utils", version("isdnctrl"))
- printversion("Nfs-utils", version("showmount --version"))
printversion("Bison", version("bison --version"))
+ printversion("btrfs-progs", version("btrfs --version"))
+ printversion("Clang", version("clang --version"))
+ printversion("Console-tools", version("loadkeys -V"))
+ printversion("Dynamic linker (ldd)", version("ldd --version"))
+ printversion("E2fsprogs", version("e2fsck -V"))
printversion("Flex", version("flex --version"))
+ printversion("GNU AWK", version("gawk -version"))
+ printversion("GNU C", version("gcc -dumpversion"))
+ printversion("GNU make", version("make --version"))
+ printversion("GNU tar", version("tar --version"))
+ printversion("GRUB", version("grub-install --version"))
+ printversion("GRUB2", version("grub2-install --version"))
+ printversion("gtags", version("gtags --version"))
+ printversion("iptables", version("iptables -V"))
+ printversion("Isdn4k-utils", version("isdnctrl"))
+ printversion("Jfsutils", version("fsck.jfs -V"))
+ printversion("Kbd", version("loadkeys -V"))
+ printversion("kmod", version("kmod -V"))
while ("ldconfig -p 2>/dev/null" | getline > 0)
if ($NF ~ libc || $NF ~ libcpp)
if (!seen[ver = version("readlink " $NF)]++)
printversion("Linux C" ($NF ~ libcpp? "++" : "") " Library", ver)
- printversion("Dynamic linker (ldd)", version("ldd --version"))
- printversion("Procps", version("ps --version"))
+ printversion("mcelog", version("mcelog --version"))
+ printversion("mkimage", version("mkimage --version"))
+ printversion("Module-init-tools", version("depmod -V"))
+ printversion("Mount", version("mount --version"))
printversion("Net-tools", version("ifconfig --version"))
- printversion("Kbd", version("loadkeys -V"))
- printversion("Console-tools", version("loadkeys -V"))
+ printversion("Nfs-utils", version("showmount --version"))
+ printversion("openssl", version("openssl version"))
+ printversion("pahole", version("pahole --version"))
+ printversion("Pcmcia-cs", version("cardmgr -V"))
+ printversion("Pcmciautils", version("pccardctl -V"))
+ printversion("PPP", version("pppd --version"))
+ printversion("Procps", version("ps --version"))
+ printversion("Python", version("python3 -V"))
+ printversion("Quota-tools", version("quota -V"))
+ printversion("Rust", version("rustc --version"))
printversion("Sh-utils", version("expr --v"))
+ printversion("Sphinx", version("sphinx-build --version"))
+ printversion("squashfs-tools", version("mksquashfs -version"))
printversion("Udev", version("udevadm --version"))
+ printversion("Util-linux", version("mount --version"))
printversion("Wireless-tools", version("iwconfig --version"))
+ printversion("Xfsprogs", version("xfs_db -V"))
while ("sort /proc/modules" | getline > 0) {
mods = mods sep $1
--
2.53.0
^ permalink raw reply related
* [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