* Re: [RFC PATCH 0/2] kasan: hw_tags: Add option to tag only at allocation time
From: Harry Yoo @ 2026-06-18 13:35 UTC (permalink / raw)
To: Dev Jain, ryabinin.a.a, akpm, corbet
Cc: glider, andreyknvl, dvyukov, vincenzo.frascino, kasan-dev,
linux-mm, linux-kernel, skhan, workflows, linux-doc,
linux-arm-kernel, ryan.roberts, anshuman.khandual, kaleshsingh,
21cnbao, david, will, catalin.marinas
In-Reply-To: <20260612044425.763060-1-dev.jain@arm.com>
[-- Attachment #1.1: Type: text/plain, Size: 1655 bytes --]
Hi Dev,
On 6/12/26 1:44 PM, Dev Jain wrote:
> Introduce a boot option to tag only at allocation time of the objects. This
> reduces KASAN MTE overhead, the tradeoff being reduced ability of
> catching bugs.
I think most of overhead when enabling MTE comes from loading and
validing tags for every memory access (either in SYNC or ASYNC mode),
rather than from storing tags.
> Now, when a memory object will be freed, it will retain the random tag it
> had at allocation time. This compromises on catching UAF bugs, till the
> time the object is not reallocated, at which point it will have a new
> random tag.
>
> Hence, not catching "use-after-free-before-reallocation" and not catching
> "double-free" will be the compromise for reduced KASAN overhead.
I doubt users who care about security enough to enable HW_TAGS KASAN
are willing to compromise on security just to save a few instructions
to store tags in the free path.
To me, it looks like too much of a compromise on security for little
performance gain.
> This is an RFC because we are not clear about the performance benefit.
>
> Android folks, please help with testing!
>
> ---
> Applies on Linus master (9716c086c8e8).
>
> Dev Jain (2):
> kasan: hw_tags: Use KASAN_PAGE_REDZONE for vmalloc redzoning
> kasan: hw_tags: Add boot option to elide free time poisoning
>
> Documentation/dev-tools/kasan.rst | 4 +++
> mm/kasan/hw_tags.c | 45 +++++++++++++++++++++++++++++--
> mm/kasan/kasan.h | 23 +++++++++++++++-
> 3 files changed, 69 insertions(+), 3 deletions(-)
>
--
Cheers,
Harry / Hyeonggon
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] Documentation: Fix syntax of kmalloc_objs example in coding style doc
From: Manuel Ebner @ 2026-06-18 9:19 UTC (permalink / raw)
To: Uwe Kleine-König, Jonathan Corbet, Vlastimil Babka (SUSE),
SeongJae Park
Cc: Shuah Khan, workflows, linux-doc, linux-kernel
In-Reply-To: <20260529081006.2019687-2-ukleinek@kernel.org>
Thanks, I realized just now that I introduced this.
Manuel
On Fri, 2026-05-29 at 10:10 +0200, Uwe Kleine-König wrote:
> The first parameter should match the variable that the allocated memory
> is assigned to. Fix the example accordingly, the one for kmalloc_obj got
> it right already.
>
> Fixes: 7c6d969d5349 ("Documentation: adopt new coding style of type-aware kmalloc-
> family")
> Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
> ---
> Documentation/process/coding-style.rst | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/process/coding-style.rst b/Documentation/process/coding-
> style.rst
> index a3bf75dc7c88..a8336582f60b 100644
> --- a/Documentation/process/coding-style.rst
> +++ b/Documentation/process/coding-style.rst
> @@ -959,13 +959,13 @@ The preferred form for allocating an array is the following:
>
> .. code-block:: c
>
> - p = kmalloc_objs(*ptr, n, ...);
> + p = kmalloc_objs(*p, n, ...);
>
> The preferred form for allocating a zeroed array is the following:
>
> .. code-block:: c
>
> - p = kzalloc_objs(*ptr, n, ...);
> + p = kzalloc_objs(*p, n, ...);
>
> Both forms check for overflow on the allocation size n * sizeof(...),
> and return NULL if that occurred.
>
> base-commit: f7af91adc230aa99e23330ecf85bc9badd9780ad
^ permalink raw reply
* Re: [PATCH] kselftest docs: remove reference to obsolete/archived wiki
From: Brett Sheffield @ 2026-06-18 8:41 UTC (permalink / raw)
To: Rafael Passos, shuah, corbet
Cc: linux-kselftest, workflows, linux-doc, linux-kernel
In-Reply-To: <865def83-a07e-4eba-b795-7da66e0e2d69@linuxfoundation.org>
>On 6/17/26 19:03, Shuah Khan wrote:
>> On 6/17/26 17:57, Rafael Passos wrote:
>>> This link in the docs point to a wiki that is no longer active.
>>>
>>> The wiki was moved to archive.kernel.org, and there is a warning:
>>> "OBSOLETE CONTENT This wiki has been archived and the content is
>>> no longer updated."
>>>
>>> Signed-off-by: Rafael Passos <rafael@rcpassos.me>
>>> ---
>>>
>>> Documentation/dev-tools/kselftest.rst | 5 -----
>>> 1 file changed, 5 deletions(-)
>>>
>>> diff --git a/Documentation/dev-tools/kselftest.rst b/Documentation/dev-tools/kselftest.rst
>>> index d7bfe320338c..64c0ec7428a2 100644
>>> --- a/Documentation/dev-tools/kselftest.rst
>>> +++ b/Documentation/dev-tools/kselftest.rst
>>> @@ -15,11 +15,6 @@ able to run that test on an older kernel. Hence, it is important to keep
>>> code that can still test an older kernel and make sure it skips the test
>>> gracefully on newer releases.
>>> -You can find additional information on Kselftest framework, how to
>>> -write new tests using the framework on Kselftest wiki:
>>> -
>>> -https://kselftest.wiki.kernel.org/
>>> -
>>> On some systems, hot-plug tests could hang forever waiting for cpu and
>>> memory to be ready to be offlined. A special hot-plug target is created
>>> to run the full range of hot-plug tests. In default mode, hot-plug tests run
>>
>>
>> Looks good to me.
>>
>> Reviewed-by: Shuah Khan <skhan@linuxfoundation.org>
>
>Jon,
>
>I can take this through kselftest tree as I usually do.
>
>thanks,
>-- Shuah
Hi Shuah, Jon et al,
I've been trying to get the same change merged since August 2025:
https://lore.kernel.org/linux-doc/20250824075007.13901-2-bacs@librecast.net/
resent in January:
https://lore.kernel.org/linux-doc/20260115172817.7120-1-bacs@librecast.net/
It's great that this trivial fix is finally getting merged, but can someone
explain why this patch was accepted in preference to the one I sent in August?
Brett Sheffield (he/him)
^ permalink raw reply
* Re: [PATCH net-next] docs: exclude driver and netdevsim bugs
From: Leon Romanovsky @ 2026-06-17 11:40 UTC (permalink / raw)
To: Jakub Kicinski
Cc: davem, netdev, edumazet, pabeni, andrew+netdev, horms, johannes,
corbet, skhan, workflows, linux-doc
In-Reply-To: <20260615091909.78ad2b03@kernel.org>
On Mon, Jun 15, 2026 at 09:19:09AM -0700, Jakub Kicinski wrote:
> On Mon, 15 Jun 2026 12:14:36 +0300 Leon Romanovsky wrote:
> > > +Unless explicitly excluded all bug fixes should be targeting the ``net``
> > > +tree and contain an appropriate Fixes tag.
> > > +
> > > +Obvious exclusions:
> > > +
> > > + - fixes for bugs which only exist in ``net-next`` should target ``net-next``
> > > + (please still include the Fixes tag in the commit message)
> > > + - bugs which cannot be reached, e.g. in code paths not executed given
> > > + current in-tree callers
> > > + - fixes for compiler warnings and typos
> >
> > If you decide to resubmit this patch, could you please remove "fixes for
> > compiler warnings" from the exclusion list?
> >
> > It is quite frustrating to receive a compiler warning originating from a
> > different subsystem after the merge window, knowing it will not be
> > addressed until the next merge window (around eight weeks later).
>
> Agreed, FWIW, but not planning to resubmit.
> I think people misunderstood that I'm __documenting what I already do__
> rather than trying to have a discussion :/
I'm pretty sure that people aren't aware of it.
Thanks
^ permalink raw reply
* Re: [PATCH v13 0/4] kunit: Add support for suppressing warning backtraces
From: David Gow @ 2026-06-16 12:06 UTC (permalink / raw)
To: Albert Esteve, Arnd Bergmann, Brendan Higgins, Rae Moar,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Jonathan Corbet, Shuah Khan, Andrew Morton,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti
Cc: linux-kernel, linux-arch, linux-kselftest, kunit-dev, dri-devel,
workflows, linux-riscv, linux-doc, peterz, Alessandro Carminati,
Guenter Roeck, Kees Cook, Linux Kernel Functional Testing,
Maíra Canal, Dan Carpenter, Simona Vetter
In-Reply-To: <CADSE00+typ3Zi5Vf0Z276+e0G7PuS7mt7oA9h5awBu3YgYKw0g@mail.gmail.com>
Le 16/06/2026 à 7:44 PM, Albert Esteve a écrit :
> On Fri, May 15, 2026 at 2:29 PM Albert Esteve <aesteve@redhat.com> wrote:
>>
>> Some unit tests intentionally trigger warning backtraces by passing bad
>> parameters to kernel API functions. Such unit tests typically check the
>> return value from such calls, not the existence of the warning backtrace.
>>
>> Such intentionally generated warning backtraces are neither desirable
>> nor useful for a number of reasons:
>> - They can result in overlooked real problems.
>> - A warning that suddenly starts to show up in unit tests needs to be
>> investigated and has to be marked to be ignored, for example by
>> adjusting filter scripts. Such filters are ad hoc because there is
>> no real standard format for warnings. On top of that, such filter
>> scripts would require constant maintenance.
>>
>> One option to address the problem would be to add messages such as
>> "expected warning backtraces start/end here" to the kernel log.
>> However, that would again require filter scripts, might result in
>> missing real problematic warning backtraces triggered while the test
>> is running, and the irrelevant backtrace(s) would still clog the
>> kernel log.
>>
>> Solve the problem by providing a means to suppress warning backtraces
>> originating from the current kthread while executing test code.
>> Since each KUnit test runs in its own kthread, this effectively scopes
>> suppression to the test that enabled it, without requiring any
>> architecture-specific code.
>>
>> Overview:
>> Patch#1 Introduces the suppression infrastructure integrated into
>> KUnit's hook mechanism.
>> Patch#2 Adds selftests to validate the functionality.
>> Patch#3 Demonstrates real-world usage in the DRM subsystem.
>> Patch#4 Documents the new API and usage guidelines.
>>
>> Design Notes:
>> Suppression is integrated into the existing KUnit hooks infrastructure,
>> reusing the kunit_running static branch for zero overhead
>> when no tests are running. The implementation lives entirely in the
>> kunit module; only a static-inline wrapper and a function pointer
>> slot are added to built-in code.
>>
>> Suppression is checked at three points in the warning path:
>> - In `warn_slowpath_fmt()` (kernel/panic.c), for architectures without
>> __WARN_FLAGS. The check runs before any output, fully suppressing
>> both message and backtrace.
>> - In `__warn_printk()` (kernel/panic.c), for architectures that define
>> __WARN_FLAGS but not their own __WARN_printf (arm64, loongarch,
>> parisc, powerpc, riscv, sh). The check suppresses the warning message
>> text that is printed before the trap enters __report_bug().
>> - In `__report_bug()` (lib/bug.c), for architectures that define
>> __WARN_FLAGS. The check runs before `__warn()` is called, suppressing
>> the backtrace and stack dump.
>>
>> To avoid double-counting on architectures where both `__warn_printk()`
>> and `__report_bug()` run for the same warning, the hook takes a bool
>> parameter: true to increment the suppression counter, false to suppress
>> without counting.
>>
>> The suppression state is dynamically allocated via kunit_kzalloc() and
>> tied to the KUnit test lifecycle via `kunit_add_action()`, ensuring
>> automatic cleanup at test exit. Writer-side access to the global
>> suppression list is serialized with a spinlock; readers use RCU.
>>
>> Two API forms are provided:
>> - kunit_warning_suppress(test) { ... }: scoped blocks with automatic
>> cleanup. The suppression handle is not accessible outside the block,
>> so warning counts (if needed) must be checked inside. Multiple
>> sequential suppression blocks are allowed.
>> - kunit_start/end_suppress_warning(test): direct functions that return
>> an explicit handle. Use when the handle needs to be retained, or passed
>> across helpers. Multiple sequential suppression blocks are allowed.
>>
>> This series is based on the RFC patch and subsequent discussion at
>> https://patchwork.kernel.org/project/linux-kselftest/patch/02546e59-1afe-4b08-ba81-d94f3b691c9a@moroto.mountain/
>> and offers a more comprehensive solution of the problem discussed there.
>>
>> Changes since RFC:
>> - Introduced CONFIG_KUNIT_SUPPRESS_BACKTRACE
>> - Minor cleanups and bug fixes
>> - Added support for all affected architectures
>> - Added support for counting suppressed warnings
>> - Added unit tests using those counters
>> - Added patch to suppress warning backtraces in dev_addr_lists tests
>>
>> Changes since v1:
>> - Rebased to v6.9-rc1
>> - Added Tested-by:, Acked-by:, and Reviewed-by: tags
>> [I retained those tags since there have been no functional changes]
>> - Introduced KUNIT_SUPPRESS_BACKTRACE configuration option, enabled by
>> default.
>>
>> Changes since v2:
>> - Rebased to v6.9-rc2
>> - Added comments to drm warning suppression explaining why it is needed.
>> - Added patch to move conditional code in arch/sh/include/asm/bug.h
>> to avoid kerneldoc warning
>> - Added architecture maintainers to Cc: for architecture specific patches
>> - No functional changes
>>
>> Changes since v3:
>> - Rebased to v6.14-rc6
>> - Dropped net: "kunit: Suppress lock warning noise at end of dev_addr_lists tests"
>> since 3db3b62955cd6d73afde05a17d7e8e106695c3b9
>> - Added __kunit_ and KUNIT_ prefixes.
>> - Tested on interessed architectures.
>>
>> Changes since v4:
>> - Rebased to v6.15-rc7
>> - Dropped all code in __report_bug()
>> - Moved all checks in WARN*() macros.
>> - Dropped all architecture specific code.
>> - Made __kunit_is_suppressed_warning nice to noinstr functions.
>>
>> Changes since v5:
>> - Rebased to v7.0-rc3
>> - Added RCU protection for the suppressed warnings list.
>> - Added static key and branching optimization.
>> - Removed custom `strcmp` implementation and reworked
>> __kunit_is_suppressed_warning() entrypoint function.
>>
>> Changes since v6:
>> - Moved suppression checks from WARN*() macros to warn_slowpath_fmt()
>> and __report_bug().
>> - Replaced stack-allocated suppression struct with kunit_kzalloc() heap
>> allocation tied to the KUnit test lifecycle.
>> - Changed suppression strategy from function-name matching to task-scoped:
>> all warnings on the current task are suppressed between START and END,
>> rather than only warnings originating from a specific named function.
>> - Simplified macro API: removed KUNIT_DECLARE_SUPPRESSED_WARNING(),
>> the START macro now takes (test) and handles allocation internally.
>> - Removed static key and branching optiomization, as by the time it
>> was executed, callers are already in warn slowpaths.
>> - Link to v6: https://lore.kernel.org/r/20260317-kunit_add_support-v6-0-dd22aeb3fe5d@redhat.com
>>
>> Changes since v7:
>> - Integrated suppression into existing KUnit hooks infrastructure
>> - Removed CONFIG_KUNIT_SUPPRESS_BACKTRACE
>> - Added suppression check in __warn_printk()
>> - Added spinlock for writer-side RCU protection
>> - Replaced explicit rcu_read_lock/unlock with guard(rcu)()
>> - Added scoped API (kunit_warning_suppress) using __cleanup attribute
>> - Updated DRM patch to use scoped API
>> - Expanded self-tests: incremental counting, cross-kthread isolation
>> - Rewrote documentation covering all three API forms with examples
>> - Link to v7: https://lore.kernel.org/r/20260420-kunit_add_support-v7-0-e8bc6e0f70de@redhat.com
>>
>> Changes since v8:
>> - Rebased to v7.1-rc2
>> - Remove KUNIT_START/END_SUPPRESSED_WARNING() macros
>> - Add KUNIT_EXPECT_SUPPRESSED_WARNING_COUNT checks to drm tests
>> - Link to v8: https://lore.kernel.org/r/20260504-kunit_add_support-v8-0-3e5957cdd235@redhat.com
>>
>> Changes since v9:
>> - Fix silent false-pass when kunit_start_suppress_warning() returns NULL
>> - Fix RCU lockdep splat for kunit_is_suppressed_warning() calls
>> - Move disable_trace_on_warning() in __report_bug()
>> - Make suppress counter atomic
>> - Mark helper warn functions in selftest as noinline
>> - Add kunit_skip() for CONFIG_BUG=n in selftests
>> - Fix potentially uninitialized data.was_active in kthread seltest
>> - Add kthread_stop() in kthread selftest early exit
>> - Initialize scaling_factor to INT_MIN in DRM scaling tests
>> - Add include for bool in test-bug.h to fix CONFIG_KUNIT=n case
>> - Link to v9: https://lore.kernel.org/r/20260508-kunit_add_support-v9-0-99df7aa880f6@redhat.com
>>
>> Changes since v10:
>> - Remove synchronize_rcu() to avoid sleeping in atomic context
>> - Pin task_struct refcount to prevent ABA false-positive matches
>> - Loop in suppression selftest to prevent use-after-free on kthread exit
>> - Skip DRM rect tests on CONFIG_BUG=n
>> - Link to v10: https://lore.kernel.org/r/20260513-kunit_add_support-v10-0-e379d206c8cd@redhat.com
>>
>> Changes since v11:
>> - Use call_rcu() to defer free without blocking
>> - Remove #ifdef CONFIG_KUNIT guard in lib/bug.c
>> - Remove stale config checks from selftest
>> - Replace skip on DRM rect tests with conditional expectation
>> - Link to v11: https://lore.kernel.org/r/20260514-kunit_add_support-v11-0-b36a530a6d8f@redhat.com
>>
>> Changes since v12:
>> - Reverted to the v9 synchronize_rcu() approach
>> - Add in_task() check at the top of __kunit_is_suppressed_warning_impl()
>> - Link to v12: https://lore.kernel.org/r/20260515-kunit_add_support-v12-0-a216dc228be8@redhat.com
>
> Hi all,
>
> I am not sure if there is a decision to merge this series or if any
> work remains to be done.
>
> I reckon I sent a few versions back-to-back last time as I was
> struggling with Sashiko. However, there are no significant changes,
> the core strategy remains unchanged, involving only the addition of
> safety checks and the removal of some redundancies to satisfy the AI.
> I am just clarifying in case the last versions/respins were unclear. I
> tried running AI reviews locally but Sashiko always found more issues
> than my local model could.
>
The latest version was fine. It's just landed for 7.2:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=42eb3a5ef6bc56192bf450c79a3f274e081f8131
Thanks for all of your work,
-- David
^ permalink raw reply
* Re: [PATCH v13 0/4] kunit: Add support for suppressing warning backtraces
From: Albert Esteve @ 2026-06-16 11:44 UTC (permalink / raw)
To: Arnd Bergmann, Brendan Higgins, David Gow, Rae Moar,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Jonathan Corbet, Shuah Khan, Andrew Morton,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti
Cc: linux-kernel, linux-arch, linux-kselftest, kunit-dev, dri-devel,
workflows, linux-riscv, linux-doc, peterz, Alessandro Carminati,
Guenter Roeck, Kees Cook, Linux Kernel Functional Testing,
Maíra Canal, Dan Carpenter, Simona Vetter
In-Reply-To: <20260515-kunit_add_support-v13-0-18ee42f96e7b@redhat.com>
On Fri, May 15, 2026 at 2:29 PM Albert Esteve <aesteve@redhat.com> wrote:
>
> Some unit tests intentionally trigger warning backtraces by passing bad
> parameters to kernel API functions. Such unit tests typically check the
> return value from such calls, not the existence of the warning backtrace.
>
> Such intentionally generated warning backtraces are neither desirable
> nor useful for a number of reasons:
> - They can result in overlooked real problems.
> - A warning that suddenly starts to show up in unit tests needs to be
> investigated and has to be marked to be ignored, for example by
> adjusting filter scripts. Such filters are ad hoc because there is
> no real standard format for warnings. On top of that, such filter
> scripts would require constant maintenance.
>
> One option to address the problem would be to add messages such as
> "expected warning backtraces start/end here" to the kernel log.
> However, that would again require filter scripts, might result in
> missing real problematic warning backtraces triggered while the test
> is running, and the irrelevant backtrace(s) would still clog the
> kernel log.
>
> Solve the problem by providing a means to suppress warning backtraces
> originating from the current kthread while executing test code.
> Since each KUnit test runs in its own kthread, this effectively scopes
> suppression to the test that enabled it, without requiring any
> architecture-specific code.
>
> Overview:
> Patch#1 Introduces the suppression infrastructure integrated into
> KUnit's hook mechanism.
> Patch#2 Adds selftests to validate the functionality.
> Patch#3 Demonstrates real-world usage in the DRM subsystem.
> Patch#4 Documents the new API and usage guidelines.
>
> Design Notes:
> Suppression is integrated into the existing KUnit hooks infrastructure,
> reusing the kunit_running static branch for zero overhead
> when no tests are running. The implementation lives entirely in the
> kunit module; only a static-inline wrapper and a function pointer
> slot are added to built-in code.
>
> Suppression is checked at three points in the warning path:
> - In `warn_slowpath_fmt()` (kernel/panic.c), for architectures without
> __WARN_FLAGS. The check runs before any output, fully suppressing
> both message and backtrace.
> - In `__warn_printk()` (kernel/panic.c), for architectures that define
> __WARN_FLAGS but not their own __WARN_printf (arm64, loongarch,
> parisc, powerpc, riscv, sh). The check suppresses the warning message
> text that is printed before the trap enters __report_bug().
> - In `__report_bug()` (lib/bug.c), for architectures that define
> __WARN_FLAGS. The check runs before `__warn()` is called, suppressing
> the backtrace and stack dump.
>
> To avoid double-counting on architectures where both `__warn_printk()`
> and `__report_bug()` run for the same warning, the hook takes a bool
> parameter: true to increment the suppression counter, false to suppress
> without counting.
>
> The suppression state is dynamically allocated via kunit_kzalloc() and
> tied to the KUnit test lifecycle via `kunit_add_action()`, ensuring
> automatic cleanup at test exit. Writer-side access to the global
> suppression list is serialized with a spinlock; readers use RCU.
>
> Two API forms are provided:
> - kunit_warning_suppress(test) { ... }: scoped blocks with automatic
> cleanup. The suppression handle is not accessible outside the block,
> so warning counts (if needed) must be checked inside. Multiple
> sequential suppression blocks are allowed.
> - kunit_start/end_suppress_warning(test): direct functions that return
> an explicit handle. Use when the handle needs to be retained, or passed
> across helpers. Multiple sequential suppression blocks are allowed.
>
> This series is based on the RFC patch and subsequent discussion at
> https://patchwork.kernel.org/project/linux-kselftest/patch/02546e59-1afe-4b08-ba81-d94f3b691c9a@moroto.mountain/
> and offers a more comprehensive solution of the problem discussed there.
>
> Changes since RFC:
> - Introduced CONFIG_KUNIT_SUPPRESS_BACKTRACE
> - Minor cleanups and bug fixes
> - Added support for all affected architectures
> - Added support for counting suppressed warnings
> - Added unit tests using those counters
> - Added patch to suppress warning backtraces in dev_addr_lists tests
>
> Changes since v1:
> - Rebased to v6.9-rc1
> - Added Tested-by:, Acked-by:, and Reviewed-by: tags
> [I retained those tags since there have been no functional changes]
> - Introduced KUNIT_SUPPRESS_BACKTRACE configuration option, enabled by
> default.
>
> Changes since v2:
> - Rebased to v6.9-rc2
> - Added comments to drm warning suppression explaining why it is needed.
> - Added patch to move conditional code in arch/sh/include/asm/bug.h
> to avoid kerneldoc warning
> - Added architecture maintainers to Cc: for architecture specific patches
> - No functional changes
>
> Changes since v3:
> - Rebased to v6.14-rc6
> - Dropped net: "kunit: Suppress lock warning noise at end of dev_addr_lists tests"
> since 3db3b62955cd6d73afde05a17d7e8e106695c3b9
> - Added __kunit_ and KUNIT_ prefixes.
> - Tested on interessed architectures.
>
> Changes since v4:
> - Rebased to v6.15-rc7
> - Dropped all code in __report_bug()
> - Moved all checks in WARN*() macros.
> - Dropped all architecture specific code.
> - Made __kunit_is_suppressed_warning nice to noinstr functions.
>
> Changes since v5:
> - Rebased to v7.0-rc3
> - Added RCU protection for the suppressed warnings list.
> - Added static key and branching optimization.
> - Removed custom `strcmp` implementation and reworked
> __kunit_is_suppressed_warning() entrypoint function.
>
> Changes since v6:
> - Moved suppression checks from WARN*() macros to warn_slowpath_fmt()
> and __report_bug().
> - Replaced stack-allocated suppression struct with kunit_kzalloc() heap
> allocation tied to the KUnit test lifecycle.
> - Changed suppression strategy from function-name matching to task-scoped:
> all warnings on the current task are suppressed between START and END,
> rather than only warnings originating from a specific named function.
> - Simplified macro API: removed KUNIT_DECLARE_SUPPRESSED_WARNING(),
> the START macro now takes (test) and handles allocation internally.
> - Removed static key and branching optiomization, as by the time it
> was executed, callers are already in warn slowpaths.
> - Link to v6: https://lore.kernel.org/r/20260317-kunit_add_support-v6-0-dd22aeb3fe5d@redhat.com
>
> Changes since v7:
> - Integrated suppression into existing KUnit hooks infrastructure
> - Removed CONFIG_KUNIT_SUPPRESS_BACKTRACE
> - Added suppression check in __warn_printk()
> - Added spinlock for writer-side RCU protection
> - Replaced explicit rcu_read_lock/unlock with guard(rcu)()
> - Added scoped API (kunit_warning_suppress) using __cleanup attribute
> - Updated DRM patch to use scoped API
> - Expanded self-tests: incremental counting, cross-kthread isolation
> - Rewrote documentation covering all three API forms with examples
> - Link to v7: https://lore.kernel.org/r/20260420-kunit_add_support-v7-0-e8bc6e0f70de@redhat.com
>
> Changes since v8:
> - Rebased to v7.1-rc2
> - Remove KUNIT_START/END_SUPPRESSED_WARNING() macros
> - Add KUNIT_EXPECT_SUPPRESSED_WARNING_COUNT checks to drm tests
> - Link to v8: https://lore.kernel.org/r/20260504-kunit_add_support-v8-0-3e5957cdd235@redhat.com
>
> Changes since v9:
> - Fix silent false-pass when kunit_start_suppress_warning() returns NULL
> - Fix RCU lockdep splat for kunit_is_suppressed_warning() calls
> - Move disable_trace_on_warning() in __report_bug()
> - Make suppress counter atomic
> - Mark helper warn functions in selftest as noinline
> - Add kunit_skip() for CONFIG_BUG=n in selftests
> - Fix potentially uninitialized data.was_active in kthread seltest
> - Add kthread_stop() in kthread selftest early exit
> - Initialize scaling_factor to INT_MIN in DRM scaling tests
> - Add include for bool in test-bug.h to fix CONFIG_KUNIT=n case
> - Link to v9: https://lore.kernel.org/r/20260508-kunit_add_support-v9-0-99df7aa880f6@redhat.com
>
> Changes since v10:
> - Remove synchronize_rcu() to avoid sleeping in atomic context
> - Pin task_struct refcount to prevent ABA false-positive matches
> - Loop in suppression selftest to prevent use-after-free on kthread exit
> - Skip DRM rect tests on CONFIG_BUG=n
> - Link to v10: https://lore.kernel.org/r/20260513-kunit_add_support-v10-0-e379d206c8cd@redhat.com
>
> Changes since v11:
> - Use call_rcu() to defer free without blocking
> - Remove #ifdef CONFIG_KUNIT guard in lib/bug.c
> - Remove stale config checks from selftest
> - Replace skip on DRM rect tests with conditional expectation
> - Link to v11: https://lore.kernel.org/r/20260514-kunit_add_support-v11-0-b36a530a6d8f@redhat.com
>
> Changes since v12:
> - Reverted to the v9 synchronize_rcu() approach
> - Add in_task() check at the top of __kunit_is_suppressed_warning_impl()
> - Link to v12: https://lore.kernel.org/r/20260515-kunit_add_support-v12-0-a216dc228be8@redhat.com
Hi all,
I am not sure if there is a decision to merge this series or if any
work remains to be done.
I reckon I sent a few versions back-to-back last time as I was
struggling with Sashiko. However, there are no significant changes,
the core strategy remains unchanged, involving only the addition of
safety checks and the removal of some redundancies to satisfy the AI.
I am just clarifying in case the last versions/respins were unclear. I
tried running AI reviews locally but Sashiko always found more issues
than my local model could.
BR,
Albert.
> --
> 2.34.1
>
> ---
> To: Brendan Higgins <brendan.higgins@linux.dev>
> To: David Gow <david@davidgow.net>
> To: Rae Moar <raemoar63@gmail.com>
> To: Andrew Morton <akpm@linux-foundation.org>
> To: Paul Walmsley <pjw@kernel.org>
> To: Palmer Dabbelt <palmer@dabbelt.com>
> To: Albert Ou <aou@eecs.berkeley.edu>
> To: Alexandre Ghiti <alex@ghiti.fr>
> To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> To: Maxime Ripard <mripard@kernel.org>
> To: Thomas Zimmermann <tzimmermann@suse.de>
> To: David Airlie <airlied@gmail.com>
> To: Simona Vetter <simona@ffwll.ch>
> To: Jonathan Corbet <corbet@lwn.net>
> To: Shuah Khan <skhan@linuxfoundation.org>
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-kselftest@vger.kernel.org
> Cc: kunit-dev@googlegroups.com
> Cc: linux-riscv@lists.infradead.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: workflows@vger.kernel.org
> Cc: linux-doc@vger.kernel.org
>
> ---
>
> ---
> Alessandro Carminati (1):
> bug/kunit: Core support for suppressing warning backtraces
>
> Guenter Roeck (3):
> kunit: Add backtrace suppression self-tests
> drm: Suppress intentional warning backtraces in scaling unit tests
> kunit: Add documentation for warning backtrace suppression API
>
> Documentation/dev-tools/kunit/usage.rst | 46 +++++++-
> drivers/gpu/drm/tests/drm_rect_test.c | 36 +++++-
> include/kunit/test-bug.h | 26 +++++
> include/kunit/test.h | 98 ++++++++++++++++
> kernel/panic.c | 11 ++
> lib/bug.c | 12 +-
> lib/kunit/Makefile | 4 +-
> lib/kunit/backtrace-suppression-test.c | 192 ++++++++++++++++++++++++++++++++
> lib/kunit/bug.c | 127 +++++++++++++++++++++
> lib/kunit/hooks-impl.h | 2 +
> 10 files changed, 544 insertions(+), 10 deletions(-)
> ---
> base-commit: 74fe02ce122a6103f207d29fafc8b3a53de6abaf
> change-id: 20260312-kunit_add_support-2f35806b19dd
>
> Best regards,
> --
> Albert Esteve <aesteve@redhat.com>
>
^ permalink raw reply
* Re: [PATCH net-next] docs: exclude driver and netdevsim bugs
From: Jakub Kicinski @ 2026-06-15 16:19 UTC (permalink / raw)
To: Leon Romanovsky
Cc: davem, netdev, edumazet, pabeni, andrew+netdev, horms, johannes,
corbet, skhan, workflows, linux-doc
In-Reply-To: <20260615091436.GP327369@unreal>
On Mon, 15 Jun 2026 12:14:36 +0300 Leon Romanovsky wrote:
> > +Unless explicitly excluded all bug fixes should be targeting the ``net``
> > +tree and contain an appropriate Fixes tag.
> > +
> > +Obvious exclusions:
> > +
> > + - fixes for bugs which only exist in ``net-next`` should target ``net-next``
> > + (please still include the Fixes tag in the commit message)
> > + - bugs which cannot be reached, e.g. in code paths not executed given
> > + current in-tree callers
> > + - fixes for compiler warnings and typos
>
> If you decide to resubmit this patch, could you please remove "fixes for
> compiler warnings" from the exclusion list?
>
> It is quite frustrating to receive a compiler warning originating from a
> different subsystem after the merge window, knowing it will not be
> addressed until the next merge window (around eight weeks later).
Agreed, FWIW, but not planning to resubmit.
I think people misunderstood that I'm __documenting what I already do__
rather than trying to have a discussion :/
^ permalink raw reply
* Re: [PATCH net-next] docs: exclude driver and netdevsim bugs
From: Leon Romanovsky @ 2026-06-15 9:14 UTC (permalink / raw)
To: Jakub Kicinski
Cc: davem, netdev, edumazet, pabeni, andrew+netdev, horms, johannes,
corbet, skhan, workflows, linux-doc
In-Reply-To: <20260603162943.2406080-1-kuba@kernel.org>
On Wed, Jun 03, 2026 at 09:29:43AM -0700, Jakub Kicinski wrote:
> Initial wave of AI-generated fixes was mostly for core and protocols
> we care about. But the number of irrelevant driver fixes is slowly
> increasing. Add a section of explicit exclusions to our maintainer
> profile.
>
> 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 | 28 +++++++++++++++++++++
> 1 file changed, 28 insertions(+)
>
> diff --git a/Documentation/process/maintainer-netdev.rst b/Documentation/process/maintainer-netdev.rst
> index ec7b9aa2877f..cc4b5fa3b5c1 100644
> --- a/Documentation/process/maintainer-netdev.rst
> +++ b/Documentation/process/maintainer-netdev.rst
> @@ -272,6 +272,34 @@ the case today. Please follow the standard stable rules in
> :ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>`,
> and make sure you include appropriate Fixes tags!
>
> +Bug fixes
> +~~~~~~~~~
> +
> +Unless explicitly excluded all bug fixes should be targeting the ``net``
> +tree and contain an appropriate Fixes tag.
> +
> +Obvious exclusions:
> +
> + - fixes for bugs which only exist in ``net-next`` should target ``net-next``
> + (please still include the Fixes tag in the commit message)
> + - bugs which cannot be reached, e.g. in code paths not executed given
> + current in-tree callers
> + - fixes for compiler warnings and typos
If you decide to resubmit this patch, could you please remove "fixes for
compiler warnings" from the exclusion list?
It is quite frustrating to receive a compiler warning originating from a
different subsystem after the merge window, knowing it will not be
addressed until the next merge window (around eight weeks later).
Thanks.
^ permalink raw reply
* Re: [RFC PATCH 0/2] kasan: hw_tags: Add option to tag only at allocation time
From: Lance Yang @ 2026-06-13 6:06 UTC (permalink / raw)
To: dev.jain
Cc: ryabinin.a.a, akpm, corbet, glider, andreyknvl, dvyukov,
vincenzo.frascino, kasan-dev, linux-mm, linux-kernel, skhan,
workflows, linux-doc, linux-arm-kernel, ryan.roberts,
anshuman.khandual, kaleshsingh, 21cnbao, david, will,
catalin.marinas, Lance Yang
In-Reply-To: <20260612044425.763060-1-dev.jain@arm.com>
On Fri, Jun 12, 2026 at 04:44:22AM +0000, Dev Jain wrote:
>Introduce a boot option to tag only at allocation time of the objects. This
>reduces KASAN MTE overhead, the tradeoff being reduced ability of
>catching bugs.
>
>Now, when a memory object will be freed, it will retain the random tag it
>had at allocation time. This compromises on catching UAF bugs, till the
>time the object is not reallocated, at which point it will have a new
>random tag.
>
>Hence, not catching "use-after-free-before-reallocation" and not catching
>"double-free" will be the compromise for reduced KASAN overhead.
Hmm ... do we also need to teach the KASAN KUnit tests about this mode?
With kasan.tag_only_on_alloc=on, free-time poisoning is skipped, so
some UAF and double-free reports are skipped on purpose, but the tests
still expect them :)
Cheers, Lance
^ permalink raw reply
* Re: [RFC PATCH 2/2] kasan: hw_tags: Add boot option to elide free time poisoning
From: Isaac Manjarres @ 2026-06-13 0:23 UTC (permalink / raw)
To: Dev Jain
Cc: ryabinin.a.a, akpm, corbet, glider, andreyknvl, dvyukov,
vincenzo.frascino, kasan-dev, linux-mm, linux-kernel, skhan,
workflows, linux-doc, linux-arm-kernel, ryan.roberts,
anshuman.khandual, kaleshsingh, 21cnbao, david, will,
catalin.marinas
In-Reply-To: <20260612044425.763060-3-dev.jain@arm.com>
On Fri, Jun 12, 2026 at 04:44:24AM +0000, Dev Jain wrote:
> diff --git a/mm/kasan/kasan.h b/mm/kasan/kasan.h
> index fc9169a547662..4fa8abb312faa 100644
> --- a/mm/kasan/kasan.h
> +++ b/mm/kasan/kasan.h
> #ifdef CONFIG_KASAN_GENERIC
> @@ -478,6 +489,16 @@ static inline u8 kasan_random_tag(void) { return 0; }
>
> static inline void kasan_poison(const void *addr, size_t size, u8 value, bool init)
> {
> + if (kasan_tag_only_on_alloc_enabled()) {
> + if ((value != KASAN_SLAB_REDZONE) && (value != KASAN_PAGE_REDZONE)) {
> + if (init)
> + memset((void *)kasan_reset_tag(addr), 0, size);
> + return;
> + }
> + }
> +
> + value |= 0xF0;
> +
I wonder if it would make more sense to have this as:
if (kasan_tag_only_on_alloc_enabled() && (value == KASAN_SLAB_FREE ||
value == KASAN_PAGE_FREE)) {
if (init)
memset((void *)kasan_reset_tag(addr), 0, size);
return;
}
That seems a bit clearer to me as to what it is that you're doing, and
also makes it so that you don't have to do any bit manipulation
on the value when you're filling in the redzones.
Thanks,
Isaac
^ permalink raw reply
* Re: [RFC PATCH 0/2] kasan: hw_tags: Add option to tag only at allocation time
From: Isaac Manjarres @ 2026-06-13 0:16 UTC (permalink / raw)
To: Dev Jain
Cc: ryabinin.a.a, akpm, corbet, glider, andreyknvl, dvyukov,
vincenzo.frascino, kasan-dev, linux-mm, linux-kernel, skhan,
workflows, linux-doc, linux-arm-kernel, ryan.roberts,
anshuman.khandual, kaleshsingh, 21cnbao, david, will,
catalin.marinas
In-Reply-To: <20260612044425.763060-1-dev.jain@arm.com>
On Fri, Jun 12, 2026 at 04:44:22AM +0000, Dev Jain wrote:
> Introduce a boot option to tag only at allocation time of the objects. This
> reduces KASAN MTE overhead, the tradeoff being reduced ability of
> catching bugs.
>
> Now, when a memory object will be freed, it will retain the random tag it
> had at allocation time. This compromises on catching UAF bugs, till the
> time the object is not reallocated, at which point it will have a new
> random tag.
>
> Hence, not catching "use-after-free-before-reallocation" and not catching
> "double-free" will be the compromise for reduced KASAN overhead.
>
> This is an RFC because we are not clear about the performance benefit.
>
> Android folks, please help with testing!
>
> ---
> Applies on Linus master (9716c086c8e8).
>
> Dev Jain (2):
> kasan: hw_tags: Use KASAN_PAGE_REDZONE for vmalloc redzoning
> kasan: hw_tags: Add boot option to elide free time poisoning
>
> Documentation/dev-tools/kasan.rst | 4 +++
> mm/kasan/hw_tags.c | 45 +++++++++++++++++++++++++++++--
> mm/kasan/kasan.h | 23 +++++++++++++++-
> 3 files changed, 69 insertions(+), 3 deletions(-)
>
> --
> 2.43.0
I tested out this series on one of our devices that has MTE support,
and didn't see any functional issues.
One thing I did notice though, and it's independent of this patch, is
that the vmalloc_oob is failing, but that happens even if these patches
aren't present.
Thanks,
Isaac
^ permalink raw reply
* Re: [PATCH] Documentation: process: fix brackets
From: Jonathan Corbet @ 2026-06-12 19:20 UTC (permalink / raw)
To: Manuel Ebner, Shuah Khan, open list:DOCUMENTATION PROCESS,
open list:DOCUMENTATION, open list
Cc: Manuel Ebner
In-Reply-To: <20260611064311.117023-2-manuelebner@mailbox.org>
Manuel Ebner <manuelebner@mailbox.org> writes:
> Fix missing ')' and needless ')'
>
> Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
> ---
> This is the first patch of a 'series', but I won't send them together
> because I'm still producing the patches and it will take me a couple weeks.
> Documentation/process/deprecated.rst | 2 +-
> Documentation/process/maintainer-soc.rst | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
Applied, thanks.
jon
^ permalink raw reply
* Re: [RFC PATCH v2 02/14] kcov: fix INIT_TRACK race in kcov_dataflow
From: Yunseong Kim @ 2026-06-12 13:11 UTC (permalink / raw)
To: Alexander Potapenko
Cc: Ingo Molnar, Peter Zijlstra, Juri Lelli, Vincent Guittot,
Dietmar Eggemann, Steven Rostedt, Ben Segall, Mel Gorman,
Valentin Schneider, K Prateek Nayak, Andrey Konovalov,
Dmitry Vyukov, Andrew Morton, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Nathan Chancellor, Nicolas Schier,
Nick Desaulniers, Bill Wendling, Justin Stitt, Kees Cook,
David Hildenbrand, Lorenzo Stoakes, Liam R. Howlett,
Vlastimil Babka, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Shuah Khan, Jonathan Corbet, Shuah Khan, linux-kernel, kasan-dev,
rust-for-linux, linux-kbuild, llvm, linux-mm, linux-kselftest,
workflows, linux-doc, Yeoreum Yun, sashiko-bot
In-Reply-To: <CAG_fn=XB7_zbjGzpgwEzm5dqcwehqvB+=SpJhHvw9QdETberAg@mail.gmail.com>
Hi Alexander,
> On Fri, Jun 12, 2026 at 9:25 AM Yunseong Kim <yunseong.kim@est.tech> wrote:
>>
>> Hi Alexander,
>>
>>> On Thu, Jun 11, 2026 at 6:21 PM Yunseong Kim <yunseong.kim@est.tech> wrote:
>>>>
>>>> [snip...]
>>
>> Thank you for your guide. I'll remove it in the next patch set.
> Also please make sure to update the patch version. It's really hard to
> distinguish between "[RFC PATCH v2 n/6]" and "[RFC PATCH v2 m/14]"
> when both series pop up in the inbox.
My apologies for the noise in the v1 (Mistakenly sent v2).
I will ensure the v3 patch is thoroughly cleaned up before submitting.
Thank you again, for the review.
Best regards,
Yunseong
^ permalink raw reply
* Re: [RFC PATCH v2 03/14] kcov: add barriers to recursion guard in kcov_df_write
From: Yunseong Kim @ 2026-06-12 12:55 UTC (permalink / raw)
To: Alexander Potapenko
Cc: Ingo Molnar, Peter Zijlstra, Juri Lelli, Vincent Guittot,
Dietmar Eggemann, Steven Rostedt, Ben Segall, Mel Gorman,
Valentin Schneider, K Prateek Nayak, Andrey Konovalov,
Dmitry Vyukov, Andrew Morton, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Nathan Chancellor, Nicolas Schier,
Nick Desaulniers, Bill Wendling, Justin Stitt, Kees Cook,
David Hildenbrand, Lorenzo Stoakes, Liam R. Howlett,
Vlastimil Babka, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Shuah Khan, Jonathan Corbet, Shuah Khan, linux-kernel, kasan-dev,
rust-for-linux, linux-kbuild, llvm, linux-mm, linux-kselftest,
workflows, linux-doc, Yeoreum Yun, Yunseong Kim, Yunseong Kim
In-Reply-To: <CAG_fn=XRzSuFrxtFbz2t9jjY8HPUUhhnU3iWJiSV-X4+hg66cw@mail.gmail.com>
Hi Alexander,
> On Thu, Jun 11, 2026 at 6:21 PM Yunseong Kim <yunseong.kim@est.tech> wrote:
>>
>> The recursion guard (bit-31 of kcov_df_seq) prevents reentry when
>> copy_from_kernel_nofault() or other called functions are instrumented
>> with INSTRUMENT_ALL. Without compiler barriers, the guard set/clear
>> can be reordered relative to the function body, making the protection
>> ineffective under optimization.
>>
>> Add barrier() after setting the guard and before clearing it, ensuring
>> the compiler does not move instrumented operations outside the guarded
>> region.
>>
>> Cc: Peter Zijlstra <peterz@infradead.org>
>> Signed-off-by: Yunseong Kim <yunseong.kim@est.tech>
>> ---
>> kernel/kcov_dataflow.c | 2 ++
>
> Please merge this patch into the one introducing kcov_dataflow.c
>
Understood. I'll merge them in v3.
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/kernel/kcov_dataflow.c b/kernel/kcov_dataflow.c
>> index df7e8bf70bfa..5248293280d5 100644
>> --- a/kernel/kcov_dataflow.c
>> +++ b/kernel/kcov_dataflow.c
>> @@ -86,6 +86,7 @@ kcov_df_write(u64 type_marker, u64 pc, u64 meta, void *ptr,
>> if (t->kcov_df_seq & (1U << 31))
>> return;
>> t->kcov_df_seq |= (1U << 31);
>> + barrier();
>
> Please make sure barriers have comments explaining which barriers they
> pair with (see kernel/kcov.c)
Thanks for the pointer. I see the existing implementation now and will align
my changes with it.
Best regards,
Yunseong
^ permalink raw reply
* Re: [RFC PATCH v2 01/14] kcov: add per-task dataflow tracking for function arguments/return values
From: Yunseong Kim @ 2026-06-12 12:51 UTC (permalink / raw)
To: Alexander Potapenko
Cc: Ingo Molnar, Peter Zijlstra, Juri Lelli, Vincent Guittot,
Dietmar Eggemann, Steven Rostedt, Ben Segall, Mel Gorman,
Valentin Schneider, K Prateek Nayak, Andrey Konovalov,
Dmitry Vyukov, Andrew Morton, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Nathan Chancellor, Nicolas Schier,
Nick Desaulniers, Bill Wendling, Justin Stitt, Kees Cook,
David Hildenbrand, Lorenzo Stoakes, Liam R. Howlett,
Vlastimil Babka, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Shuah Khan, Jonathan Corbet, Shuah Khan, linux-kernel, kasan-dev,
rust-for-linux, linux-kbuild, llvm, linux-mm, linux-kselftest,
workflows, linux-doc, Yeoreum Yun, Yunseong Kim, Yunseong Kim
In-Reply-To: <CAG_fn=WYdnX_09RNs3sTQWn+KZZaw+X9a=s1Uk1bqd3gW04h6Q@mail.gmail.com>
Hi Alexander,
> On Thu, Jun 11, 2026 at 6:21 PM Yunseong Kim <yunseong.kim@est.tech> wrote:
>>
>> [snip...]
>> ---
>> include/linux/sched.h | 10 ++
>> kernel/Makefile | 3 +
>> kernel/kcov.c | 2 +
>> kernel/kcov_dataflow.c | 324 +++++++++++++++++++++++++++++++++++++++++++++++++
>
> I think the total size of kcov_dataflow.c doesn't justify splitting it
> in multiple patches.
Thanks for the feedback. I'll combine the changes into a single patch for the
next version.
Best regards,
Yunseong
^ permalink raw reply
* Re: [RFC PATCH v2 01/14] kcov: add per-task dataflow tracking for function arguments/return values
From: Yunseong Kim @ 2026-06-12 12:48 UTC (permalink / raw)
To: Julian Braha, Ingo Molnar, Peter Zijlstra, Juri Lelli,
Vincent Guittot, Dietmar Eggemann, Steven Rostedt, Ben Segall,
Mel Gorman, Valentin Schneider, K Prateek Nayak, Andrey Konovalov,
Alexander Potapenko, Dmitry Vyukov, Andrew Morton, Miguel Ojeda,
Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin,
Andreas Hindborg, Alice Ryhl, Trevor Gross, Danilo Krummrich,
Nathan Chancellor, Nicolas Schier, Nick Desaulniers,
Bill Wendling, Justin Stitt, Kees Cook, David Hildenbrand,
Lorenzo Stoakes, Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Shuah Khan, Jonathan Corbet,
Shuah Khan
Cc: linux-kernel, kasan-dev, rust-for-linux, linux-kbuild, llvm,
linux-mm, linux-kselftest, workflows, linux-doc, Yeoreum Yun,
Yunseong Kim, Yunseong Kim
In-Reply-To: <2e528372-aba4-4621-a9a3-7ce23571ef37@gmail.com>
Hi Julian,
> On 6/11/26 17:21, Yunseong Kim wrote:
>> +config KCOV_DATAFLOW_RET
>> + bool "Enable KCOV dataflow: return value capture"
>> + depends on KCOV
>> + depends on DEBUG_INFO
>> + depends on $(cc-option,-fsanitize-coverage=trace-ret)
>> + help
>> + Captures function return values via /sys/kernel/debug/kcov_dataflow.
>> + Struct pointer returns are auto-expanded using compiler DebugInfo
>> + metadata, recording individual field values at runtime.
>> + Enable per-module with: KCOV_DATAFLOW_file.o := y in the Makefile.
>> + Requires clang with -fsanitize-coverage=trace-ret support.
>> +
>> +config KCOV_DATAFLOW_NO_INLINE
>> + bool "Disable inlining for dataflow-instrumented files"
>> + default n
> In Kconfig, when you don't specify any default explicitly, it's
> implicitly 'default n'.
>
> I think either style (implicit or explicit) is fine and both are used
> throughout the kernel, but is there any reason to make it explicit only
> for KCOV_DATAFLOW_NO_INLINE, and implicit for the others?
Thank you for pointing out.
You're right, there's no reason to make it explicit only for this one.
I'll drop the "default n" line to be consistent with the other options
in the same block.
> - Julian Braha
Best regards,
Yunseong
^ permalink raw reply
* Re: [RFC PATCH v2 0/6] kcov: per-task dataflow extraction at kernel function boundaries
From: Yunseong Kim @ 2026-06-12 12:45 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Ingo Molnar, Juri Lelli, Vincent Guittot, Dietmar Eggemann,
Steven Rostedt, Ben Segall, Mel Gorman, Valentin Schneider,
K Prateek Nayak, Dmitry Vyukov, Andrey Konovalov, Andrew Morton,
Nathan Chancellor, Nick Desaulniers, Bill Wendling, Justin Stitt,
Nicolas Schier, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Jonathan Corbet, Shuah Khan,
linux-kernel, kasan-dev, llvm, linux-kbuild, rust-for-linux,
workflows, linux-doc, Yunseong Kim, Yeoreum Yun
In-Reply-To: <20260612073858.GS187714@noisy.programming.kicks-ass.net>
Hi Peter,
> On Fri, Jun 12, 2026 at 09:37:40AM +0200, Yunseong Kim wrote:
>> Hi Peter,
>>
>>> On Wed, Jun 03, 2026 at 07:43:27PM +0200, Yunseong Kim wrote:
>>>> CONFIG_KCOV_DATAFLOW_INSTRUMENT_ALL instruments every function in the
>>>> kernel.
>>>
>>> Well, I would hope it would very much not instrument noinstr functions.
>>
>> Thank you for your guidance. I updated the default
>> CONFIG_KCOV_DATAFLOW_NO_INLINE to n.
>
> That's not really the point. The compiler extension *must* respect
> noinstr. If there it no function attribute to suppress this kcov stuff,
> then its an absolute non-starter.
Thank you again, for pointing that out.
I've been using the same mechanism that KCOV (trace-pc) already relies on.
trace-args/ret shares the identical code path and attribute check.
LLVM side:
noinstr functions are never instrumented because the existing
NoSanitizeCoverage attribute check at the top of the function-level pass
covers all SanCov instrumentation types including trace-args/ret.
1. Marked functions as noinstr expands to __no_sanitize_coverage, emits
__attribute__((no_sanitize("coverage")))
2. Clang translates that to Attribute::NoSanitizeCoverage
3. llvm/lib/Transforms/Instrumentation/SanitizerCoverage.cpp
if (F.hasFnAttribute(Attribute::NoSanitizeCoverage))
https://github.com/llvm/llvm-project/commit/280333021e95#diff-1b024748b036cfd10a7c3dfc7e9c53b0f752b27d7ea193939c59b2de60f69a70R445
4. skips ALL instrumentation including trace-args/trace-ret
Dobule check with objtool:
Even KCOV_DATAFLOW_NO_INLINE enabled kernel:
$ for fn in ct_nmi_enter ct_nmi_exit exc_nmi syscall_enter_from_user_mode; do
count=$(objdump -d vmlinux --disassemble=$fn | grep -c sanitizer_cov)
echo "$fn: $count sanitizer calls"
done
ct_nmi_enter: 0 sanitizer calls
ct_nmi_exit: 0 sanitizer calls
exc_nmi: 0 sanitizer calls
syscall_enter_from_user_mode: 0 sanitizer calls
If Rust noinstr functions are added in the future, they would use
#[no_sanitize(coverage)]. This maps to the same Attribute::NoSanitizeCoverage
LLVM attribute, yielding the exact same check and result.
Best regards,
Yunseong
^ permalink raw reply
* Re: [Question] 5.posting.rst use To: or Cc:
From: Jonathan Corbet @ 2026-06-12 12:41 UTC (permalink / raw)
To: Manuel Ebner, Shuah Khan, open list:DOCUMENTATION PROCESS,
open list:DOCUMENTATION, open list
In-Reply-To: <f55eb34b92a01159e0224611296fc51fcfb5ec5d.camel@mailbox.org>
Manuel Ebner <manuelebner@mailbox.org> writes:
> so every time I send a mail to lists or maintainers I have to choose: To:
> or Cc:. I did look for an answer in the Documentation but couldn't find
> one.
> I think if there is an answer then it could be added to 5.posting.rst .
Normally you would To: the maintainers, CC: the rest, but the end result
is the same either way - it really doesn't matter.
jon
^ permalink raw reply
* Re: [RFC PATCH v2 01/14] kcov: add per-task dataflow tracking for function arguments/return values
From: Julian Braha @ 2026-06-12 11:37 UTC (permalink / raw)
To: Yunseong Kim, Ingo Molnar, Peter Zijlstra, Juri Lelli,
Vincent Guittot, Dietmar Eggemann, Steven Rostedt, Ben Segall,
Mel Gorman, Valentin Schneider, K Prateek Nayak, Andrey Konovalov,
Alexander Potapenko, Dmitry Vyukov, Andrew Morton, Miguel Ojeda,
Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin,
Andreas Hindborg, Alice Ryhl, Trevor Gross, Danilo Krummrich,
Nathan Chancellor, Nicolas Schier, Nick Desaulniers,
Bill Wendling, Justin Stitt, Kees Cook, David Hildenbrand,
Lorenzo Stoakes, Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Shuah Khan, Jonathan Corbet,
Shuah Khan
Cc: linux-kernel, kasan-dev, rust-for-linux, linux-kbuild, llvm,
linux-mm, linux-kselftest, workflows, linux-doc, Yeoreum Yun
In-Reply-To: <20260611-b4-kcov-dataflow-v2-v2-1-0a261da3987c@est.tech>
On 6/11/26 17:21, Yunseong Kim wrote:
> +config KCOV_DATAFLOW_RET
> + bool "Enable KCOV dataflow: return value capture"
> + depends on KCOV
> + depends on DEBUG_INFO
> + depends on $(cc-option,-fsanitize-coverage=trace-ret)
> + help
> + Captures function return values via /sys/kernel/debug/kcov_dataflow.
> + Struct pointer returns are auto-expanded using compiler DebugInfo
> + metadata, recording individual field values at runtime.
> + Enable per-module with: KCOV_DATAFLOW_file.o := y in the Makefile.
> + Requires clang with -fsanitize-coverage=trace-ret support.
> +
> +config KCOV_DATAFLOW_NO_INLINE
> + bool "Disable inlining for dataflow-instrumented files"
> + default n
In Kconfig, when you don't specify any default explicitly, it's
implicitly 'default n'.
I think either style (implicit or explicit) is fine and both are used
throughout the kernel, but is there any reason to make it explicit only
for KCOV_DATAFLOW_NO_INLINE, and implicit for the others?
- Julian Braha
^ permalink raw reply
* [Question] 5.posting.rst use To: or Cc:
From: Manuel Ebner @ 2026-06-12 8:01 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, open list:DOCUMENTATION PROCESS,
open list:DOCUMENTATION, open list
Hi,
so every time I send a mail to lists or maintainers I have to choose: To:
or Cc:. I did look for an answer in the Documentation but couldn't find
one.
I think if there is an answer then it could be added to 5.posting.rst .
Thanks
Manuel
^ permalink raw reply
* Re: [RFC PATCH v2 02/14] kcov: fix INIT_TRACK race in kcov_dataflow
From: Alexander Potapenko @ 2026-06-12 8:00 UTC (permalink / raw)
To: Yunseong Kim
Cc: Ingo Molnar, Peter Zijlstra, Juri Lelli, Vincent Guittot,
Dietmar Eggemann, Steven Rostedt, Ben Segall, Mel Gorman,
Valentin Schneider, K Prateek Nayak, Andrey Konovalov,
Dmitry Vyukov, Andrew Morton, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Nathan Chancellor, Nicolas Schier,
Nick Desaulniers, Bill Wendling, Justin Stitt, Kees Cook,
David Hildenbrand, Lorenzo Stoakes, Liam R. Howlett,
Vlastimil Babka, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Shuah Khan, Jonathan Corbet, Shuah Khan, linux-kernel, kasan-dev,
rust-for-linux, linux-kbuild, llvm, linux-mm, linux-kselftest,
workflows, linux-doc, Yeoreum Yun, sashiko-bot
In-Reply-To: <5fa7a528-a4c5-4fdb-9a17-1b0992e955b3@est.tech>
On Fri, Jun 12, 2026 at 9:25 AM Yunseong Kim <yunseong.kim@est.tech> wrote:
>
> Hi Alexander,
>
> > On Thu, Jun 11, 2026 at 6:21 PM Yunseong Kim <yunseong.kim@est.tech> wrote:
> >>
> >> [snip...]
> >> Reported-by: sashiko-bot <sashiko-bot@kernel.org>
> >> Closes: https://sashiko.dev/#/patchset/20260603-kcov-dataflow-next-20260603-v2-0-fee0939de2c4%40est.tech
> >> Signed-off-by: Yunseong Kim <yunseong.kim@est.tech>
> >
> > Can we please avoid this?
> > kcov_dataflow.c is being introduced in the same series, there is no
> > need to send a buggy commit and a follow-up fix - just squash the two
> > together and note the changes after Signed-off-by: separated by a
> > triple dash.
>
> Thank you for your guide. I'll remove it in the next patch set.
Also please make sure to update the patch version. It's really hard to
distinguish between "[RFC PATCH v2 n/6]" and "[RFC PATCH v2 m/14]"
when both series pop up in the inbox.
^ permalink raw reply
* Re: [RFC PATCH v2 1/6] kcov: add per-task dataflow tracking for function arguments/return values
From: Yunseong Kim @ 2026-06-12 7:55 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Ingo Molnar, Juri Lelli, Vincent Guittot, Dietmar Eggemann,
Steven Rostedt, Ben Segall, Mel Gorman, Valentin Schneider,
K Prateek Nayak, Dmitry Vyukov, Andrey Konovalov, Andrew Morton,
Nathan Chancellor, Nick Desaulniers, Bill Wendling, Justin Stitt,
Nicolas Schier, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Jonathan Corbet, Shuah Khan,
linux-kernel, kasan-dev, llvm, linux-kbuild, rust-for-linux,
workflows, linux-doc, Yunseong Kim
In-Reply-To: <20260604084115.GZ3126523@noisy.programming.kicks-ass.net>
Hi Peter,
> On Wed, Jun 03, 2026 at 07:43:28PM +0200, Yunseong Kim wrote:
>> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
>> index e2f976c3301b..abd1a94589aa 100644
>> --- a/lib/Kconfig.debug
>> +++ b/lib/Kconfig.debug
>> @@ -2261,6 +2261,28 @@ config KCOV_SELFTEST
>> On test failure, causes the kernel to panic. Recommended to be
>> enabled, ensuring critical functionality works as intended.
>>
>> +
>
> ^ This line...
>
>> +config KCOV_DATAFLOW_ARGS
>> + bool "Enable KCOV dataflow: function argument capture"
>> + depends on KCOV
>> + depends on $(cc-option,-fsanitize-coverage=dataflow-args)
>> + help
>> + Captures function arguments at entry via /sys/kernel/debug/kcov_dataflow.
>> + Struct pointer arguments are auto-expanded using compiler DebugInfo
>> + metadata, recording individual field values at runtime.
>> + Enable per-module with: KCOV_DATAFLOW_file.o := y in the Makefile.
>> + Requires clang with -fsanitize-coverage=dataflow-args support.
>> +
>> +config KCOV_DATAFLOW_RET
>> + bool "Enable KCOV dataflow: return value capture"
>> + depends on KCOV
>> + depends on $(cc-option,-fsanitize-coverage=dataflow-ret)
>> + help
>> + Captures function return values via /sys/kernel/debug/kcov_dataflow.
>> + Struct pointer returns are auto-expanded using compiler DebugInfo
>> + metadata, recording individual field values at runtime.
>> + Enable per-module with: KCOV_DATAFLOW_file.o := y in the Makefile.
>> + Requires clang with -fsanitize-coverage=dataflow-ret support.
>
> Probably wants to be here...
Thank you for code review. I updated at v2 patch.
>
>> config DEBUG_AID_FOR_SYZBOT
>> bool "Additional debug code for syzbot"
>> default n
>>
>> --
>> 2.43.0
>>
Best regards,
Yunseong
^ permalink raw reply
* Re: [RFC PATCH v2 1/6] kcov: add per-task dataflow tracking for function arguments/return values
From: Yunseong Kim @ 2026-06-12 7:52 UTC (permalink / raw)
To: Alexander Potapenko
Cc: Ingo Molnar, Peter Zijlstra, Juri Lelli, Vincent Guittot,
Dietmar Eggemann, Steven Rostedt, Ben Segall, Mel Gorman,
Valentin Schneider, K Prateek Nayak, Dmitry Vyukov,
Andrey Konovalov, Andrew Morton, Nathan Chancellor,
Nick Desaulniers, Bill Wendling, Justin Stitt, Nicolas Schier,
Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Danilo Krummrich, Jonathan Corbet, Shuah Khan, linux-kernel,
kasan-dev, llvm, linux-kbuild, rust-for-linux, workflows,
linux-doc, Yunseong Kim
In-Reply-To: <CAG_fn=UMJJz+3zipowaC4uTvcbC0gvXbBRaF0UUJ_1AW+oWNGA@mail.gmail.com>
Hi Alexander,
>> - Per-task buffer: task->kcov_df_area with atomic xadd reservation
>
> I don't understand this line...
>
>> - Recursion-safe: notrace __no_sanitize_coverage noinline
>> - ERR_PTR aware: skips struct expansion for error pointers
>
> ... and this.
I updated this text at v2 patch.
>>
>> The callbacks (__sanitizer_cov_trace_args/ret) are inserted by the
>> compiler when -fsanitize-coverage=dataflow-args,dataflow-ret is used.
>> The Kconfig options depend on cc-option to verify compiler support.
>>
>> Buffer format (TLV records, all u64):
>> area[0]: atomic word count
>> [pos+0]: type_and_seq (0xE=entry, 0xF=return in upper 4 bits)
>> [pos+1]: PC
>> [pos+2]: meta (arg_idx | arg_size | ptr)
>> [pos+3..N]: field values read via copy_from_kernel_nofault()
>>
>> This is completely independent from legacy /sys/kernel/debug/kcov.
>> Existing users (syzkaller, oss-fuzz) are unaffected.
>
> Does oss-fuzz even use kcov?
Also, I removed this text at v2 patch. I mistakenly confused it with another
usage of KCOV with a other fuzzer.
https://security.googleblog.com/2024/06/hacking-for-defenders-approaches-to.html
>>
>> Signed-off-by: Yunseong Kim <yunseong.kim@est.tech>
>> ---
>> include/linux/sched.h | 8 ++
>> kernel/kcov.c | 291 ++++++++++++++++++++++++++++++++++++++++++++++++++
>> lib/Kconfig.debug | 22 ++++
>> 3 files changed, 321 insertions(+)
>>
>> diff --git a/include/linux/sched.h b/include/linux/sched.h
>> index c4433c185ad8..03be4b495f70 100644
>> --- a/include/linux/sched.h
>> +++ b/include/linux/sched.h
>> @@ -1533,6 +1533,14 @@ struct task_struct {
>> /* KCOV sequence number: */
>> int kcov_sequence;
>>
>> + /* KCOV dataflow per-task sequence counter for TLV records: */
>> + u32 kcov_dataflow_seq;
>> +
>> + /* KCOV dataflow: separate buffer for trace-args/trace-ret */
>> + unsigned int kcov_df_size;
>> + void *kcov_df_area;
>> + bool kcov_df_enabled;
>> +
>> /* Collect coverage from softirq context: */
>> unsigned int kcov_softirq;
>> #endif
>> diff --git a/kernel/kcov.c b/kernel/kcov.c
>> index 1df373fb562b..d3c9c0efe961 100644
>> --- a/kernel/kcov.c
>> +++ b/kernel/kcov.c
>> @@ -353,6 +353,288 @@ void notrace __sanitizer_cov_trace_switch(kcov_u64 val, void *arg)
>> EXPORT_SYMBOL(__sanitizer_cov_trace_switch);
>> #endif /* ifdef CONFIG_KCOV_ENABLE_COMPARISONS */
>>
>> +#if defined(CONFIG_KCOV_DATAFLOW_ARGS) || defined(CONFIG_KCOV_DATAFLOW_RET)
>> +/*
>> + * KCOV Dataflow: /sys/kernel/debug/kcov_dataflow
>> + *
>> + * Completely separate from legacy /sys/kernel/debug/kcov.
>
> Since this code is completely separate, could it be put into a separate file?
> I think kcov.c is too big already.
Thank you again for your guide, I updated it at v2.
>> + * Own buffer, own ioctl, own mmap. No printk — buffer only.
>
> Can you please not use these long dashes in C code?
I removed all a the v2.
>> +/*
>> + * Core write function — no printk, no locks, just atomic buffer write.
>
> I think it's okay to omit what this function is not doing.
>
>
>> +
>> + /* Atomic reservation */
>> + pos = 1 + xadd((unsigned long *)&area[0], record_len);
>> + if (unlikely(pos + record_len > max_pos)) {
>> + xadd((unsigned long *)&area[0], -(long)record_len);
>> + return;
>> + }
>
> Have you tried compiling this code on ARM64?
> I am pretty sure they don't have xadd(), so it won't work.
> But why do we need an atomic increment here at all? write_comp_data()
> performs the same job, and does not need it.
> Or am I missing something?
Thank you again for pointing out. After updating to the READ_ONCE/WRITE_ONCE
atomic pattern, Testing results based on v2 on arm64 for the Rust for Linux
kernel module(eight_struct_args_rust) are as follows:
do_el0_svc({0xffffffffffffff9c, 0xffffffffffffff9c, 0xffffffff, 0x0, 0x0, 0x0})
invoke_syscall({0xffffffffffffff9c, 0xffffffffffffff9c, 0x38, 0x0, 0x0, 0x0}, 0x38)
__arm64_sys_openat({0xffffffffffffff9c, 0xffffffffffffff9c, 0x38, 0x0, 0x0, 0x0})
ksys_write(0xffff9a031231, 0x1)
fdget_pos(0x4)
0xffff000004421cc0 = fdget_pos()
0x0 = vfs_write()
vfs_write(0xffff9a031231, 0x1, 0x0)
0x0 = _RNvCsdfZGIOKgjaD_22eight_struct_args_rust13write_handler [eight_struct_args_rust]()
_RNvCsdfZGIOKgjaD_22eight_struct_args_rust13write_handler [eight_struct_args_rust](0xffff9a031231, 0x1, 0x0)
rsf_1 [eight_struct_args_rust](0x11)
0x11 = rsf_1 [eight_struct_args_rust]()
rsf_2 [eight_struct_args_rust](0x11, {0x11, 0x22})
0x33 = rsf_2 [eight_struct_args_rust]()
rsf_4 [eight_struct_args_rust](0x11, {0x11, 0x22}, {0x11, 0x22, 0x33}, {0x11, 0x22, 0x33, 0x44})
0xaa = rsf_4 [eight_struct_args_rust]()
...
Latest test results from Github CI:
https://github.com/yskzalloc/kcov-dataflow/actions/runs/27397351811/job/80967927283
Best regards,
Yunseong
^ permalink raw reply
* Re: [RFC PATCH v2 0/6] kcov: per-task dataflow extraction at kernel function boundaries
From: Peter Zijlstra @ 2026-06-12 7:38 UTC (permalink / raw)
To: Yunseong Kim
Cc: Ingo Molnar, Juri Lelli, Vincent Guittot, Dietmar Eggemann,
Steven Rostedt, Ben Segall, Mel Gorman, Valentin Schneider,
K Prateek Nayak, Dmitry Vyukov, Andrey Konovalov, Andrew Morton,
Nathan Chancellor, Nick Desaulniers, Bill Wendling, Justin Stitt,
Nicolas Schier, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Jonathan Corbet, Shuah Khan,
linux-kernel, kasan-dev, llvm, linux-kbuild, rust-for-linux,
workflows, linux-doc, Yunseong Kim
In-Reply-To: <513c68a8-e530-4461-a8e5-36e5d3d5858f@est.tech>
On Fri, Jun 12, 2026 at 09:37:40AM +0200, Yunseong Kim wrote:
> Hi Peter,
>
> > On Wed, Jun 03, 2026 at 07:43:27PM +0200, Yunseong Kim wrote:
> >> CONFIG_KCOV_DATAFLOW_INSTRUMENT_ALL instruments every function in the
> >> kernel.
> >
> > Well, I would hope it would very much not instrument noinstr functions.
>
> Thank you for your guidance. I updated the default
> CONFIG_KCOV_DATAFLOW_NO_INLINE to n.
That's not really the point. The compiler extension *must* respect
noinstr. If there it no function attribute to suppress this kcov stuff,
then its an absolute non-starter.
^ permalink raw reply
* Re: [RFC PATCH v2 0/6] kcov: per-task dataflow extraction at kernel function boundaries
From: Yunseong Kim @ 2026-06-12 7:37 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Ingo Molnar, Juri Lelli, Vincent Guittot, Dietmar Eggemann,
Steven Rostedt, Ben Segall, Mel Gorman, Valentin Schneider,
K Prateek Nayak, Dmitry Vyukov, Andrey Konovalov, Andrew Morton,
Nathan Chancellor, Nick Desaulniers, Bill Wendling, Justin Stitt,
Nicolas Schier, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Jonathan Corbet, Shuah Khan,
linux-kernel, kasan-dev, llvm, linux-kbuild, rust-for-linux,
workflows, linux-doc, Yunseong Kim
In-Reply-To: <20260604084026.GY3126523@noisy.programming.kicks-ass.net>
Hi Peter,
> On Wed, Jun 03, 2026 at 07:43:27PM +0200, Yunseong Kim wrote:
>> CONFIG_KCOV_DATAFLOW_INSTRUMENT_ALL instruments every function in the
>> kernel.
>
> Well, I would hope it would very much not instrument noinstr functions.
Thank you for your guidance. I updated the default
CONFIG_KCOV_DATAFLOW_NO_INLINE to n.
Best regards,
Yunseong
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox