sed in kcov_move_area()
>
> Signed-off-by: Soham Bagchi
Reviewed-by: Marco Elver
> ---
>
> Changes in v2:
Btw, it is customary to send out the whole patch series on a version
bump, even if only one of the patches changed.
https://www.kernel.org/doc/html/latest/process/submitting-patch
On Mon, 28 Jul 2025 at 20:43, Soham Bagchi wrote:
>
> Updating the KCOV documentation to use a load-acquire
> operation for the first element of the shared memory
> buffer between kernel-space and user-space.
>
> The load-acquire pairs with the write memory barrier
> used in kcov_move_area()
>
> S
nel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/Documentation/dev-tools/kcov.rst#n364
>
> Signed-off-by: Soham Bagchi
Reviewed-by: Marco Elver
> ---
> kernel/kcov.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/kernel/kcov.c b/kernel/kcov.c
> ind
appears safe to disable
> for them as well.
@ Dmitry, Aleksandr - Will this produce some unwanted side-effects for
syzbot? I also think it's safe, but just double checking.
> Link:
> https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/kcov.c?h=v6.14#n179
&
On Fri, 24 Jan 2025 at 09:42, Vlastimil Babka wrote:
>
> On 1/24/25 09:37, Marco Elver wrote:
> > On Fri, 24 Jan 2025 at 09:13, Vlastimil Babka wrote:
> >>
> >> On 1/23/25 23:44, Christoph Lameter via B4 Relay wrote:
> >> > From: Christoph Lameter
>
On Fri, 24 Jan 2025 at 03:06, Christoph Lameter via B4 Relay
wrote:
>
> From: Christoph Lameter
>
> KFENCE manages its own pools and redirects regular memory allocations
> to those pools in a sporadic way. The usual memory allocator features
> like NUMA, memory policies and pfmemalloc are not sup
On Fri, 24 Jan 2025 at 09:13, Vlastimil Babka wrote:
>
> On 1/23/25 23:44, Christoph Lameter via B4 Relay wrote:
> > From: Christoph Lameter
> >
> > KFENCE manages its own pools and redirects regular memory allocations
> > to those pools in a sporadic way. The usual memory allocator features
> >
On Thu, 23 Jan 2025 at 23:44, Christoph Lameter via B4 Relay
wrote:
>
> From: Christoph Lameter
>
> KFENCE manages its own pools and redirects regular memory allocations
> to those pools in a sporadic way. The usual memory allocator features
> like NUMA, memory policies and pfmemalloc are not sup
On Tue, 14 Jan 2025 at 06:35, Jiao, Joey wrote:
>
> Hi,
>
> This patch series introduces new kcov unique modes:
> `KCOV_TRACE_UNIQ_[PC|EDGE|CMP]`, which are used to collect unique PC, EDGE,
> CMP information.
>
> Background
> --
>
> In the current kcov implementation, when `__sanitizer_cov
On Fri, 10 Jan 2025 at 08:33, Joey Jiao wrote:
>
> From: "Jiao, Joey"
>
> The current design of KCOV risks frequent buffer overflows. To mitigate
> this, new modes are introduced: KCOV_TRACE_UNIQ_PC, KCOV_TRACE_UNIQ_EDGE,
> and KCOV_TRACE_UNIQ_CMP. These modes allow for the recording of unique
>
On Tue, 15 Oct 2024 at 16:11, Dongliang Mu wrote:
>
> On Tue, Oct 15, 2024 at 10:09 PM Haoyang Liu
> wrote:
> >
> > fix a typo in dev-tools/kmsan.rst
> >
> > Signed-off-by: Haoyang Liu
> > ---
> > Documentation/dev-tools/kmsan.rst | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
>
On Mon, 8 Apr 2024 at 20:24, Alexei Starovoitov
wrote:
>
> On Mon, Apr 8, 2024 at 2:30 AM Marco Elver wrote:
> >
> > On Fri, 5 Apr 2024 at 22:28, Andrii Nakryiko
> > wrote:
> > >
> > > On Fri, Apr 5, 2024 at 1:28 AM Marco Elver wrote:
> >
On Fri, 5 Apr 2024 at 22:28, Andrii Nakryiko wrote:
>
> On Fri, Apr 5, 2024 at 1:28 AM Marco Elver wrote:
> >
> > On Fri, 5 Apr 2024 at 01:23, Alexei Starovoitov
> > wrote:
[...]
> > > and the tasks can use mmaped array shared across all or unique to each
>
On Fri, 5 Apr 2024 at 01:23, Alexei Starovoitov
wrote:
>
> On Thu, Apr 4, 2024 at 12:02 PM Marco Elver wrote:
> >
> > With all the known caveats, tracing BPF programs may directly write to
> > user-space memory with the bpf_probe_write_user() helper. Memory safety
> &
Introduce a BPF test program and user space code to test
bpf_probe_write_user_registered().
The test program also demonstrates 2 ways a BPF program may obtain the
addresses it can write to: either by tracing prctl() or simply accessing
current->bpf_user_writable directly.
Signed-off-by: Ma
cal system administrator, tag allocation may be done by the system
administrator. For example, by providing headers with tag definitions,
or a central service to distribute tags to the BPF program loader and to
user applications.
Signed-off-by: Marco Elver
---
Documentation/bpf/bpf_design_QA.rst |
On Tue, 22 Oct 2019 at 14:33, Mark Rutland wrote:
>
> On Thu, Oct 17, 2019 at 04:13:04PM +0200, Marco Elver wrote:
> > This adds KCSAN instrumentation to atomic-instrumented.h.
> >
> > Signed-off-by: Marco Elver
> > ---
> > v2:
> > * Use kcs
On Tue, 22 Oct 2019 at 17:49, Oleg Nesterov wrote:
>
> On 10/17, Marco Elver wrote:
> >
> > + /*
> > + * Delay this thread, to increase probability of observing a racy
> > + * conflicting access.
> > + */
> > + udelay(get_delay()
Hi Mark,
Thanks for you comments; see inline comments below.
On Tue, 22 Oct 2019 at 16:11, Mark Rutland wrote:
>
> Hi Marco,
>
> On Thu, Oct 17, 2019 at 04:12:58PM +0200, Marco Elver wrote:
> > Kernel Concurrency Sanitizer (KCSAN) is a dynamic data-race detector for
> >
On Tue, 22 Oct 2019 at 14:59, Mark Rutland wrote:
>
> On Thu, Oct 17, 2019 at 04:13:05PM +0200, Marco Elver wrote:
> > This patch enables KCSAN for x86, with updates to build rules to not use
> > KCSAN for several incompatible compilation units.
> >
> > Signed-off-b
On Mon, 21 Oct 2019 at 15:37, Alexander Potapenko wrote:
>
> On Thu, Oct 17, 2019 at 4:13 PM Marco Elver wrote:
> >
> > Kernel Concurrency Sanitizer (KCSAN) is a dynamic data-race detector for
> > kernel space. KCSAN is a sampling watchpoint-based data-race detect
On Mon, 21 Oct 2019 at 17:15, Dmitry Vyukov wrote:
>
> On Thu, Oct 17, 2019 at 4:13 PM Marco Elver wrote:
> >
> > This patch adds KCSAN runtime functions to the objtool whitelist.
> >
> > Signed-off-by: Marco Elver
> > ---
> > tools/objtool/check.c
On Wed, 16 Oct 2019 at 10:41, Marco Elver wrote:
>
> This is the patch-series for the Kernel Concurrency Sanitizer (KCSAN).
> KCSAN is a sampling watchpoint-based data-race detector. More details
> are included in Documentation/dev-tools/kcsan.rst. This patch-series
> only enable
This patch enables KCSAN for x86, with updates to build rules to not use
KCSAN for several incompatible compilation units.
Signed-off-by: Marco Elver
---
v2:
* Document build exceptions where no previous above comment explained
why we cannot instrument.
---
arch/x86/Kconfig
Add explicit KCSAN checks for bitops.
Signed-off-by: Marco Elver
---
v2:
* Use kcsan_check{,_atomic}_{read,write} instead of
kcsan_check_{access,atomic}.
---
include/asm-generic/bitops-instrumented.h | 18 ++
1 file changed, 18 insertions(+)
diff --git a/include/asm-generic
This adds KCSAN instrumentation to atomic-instrumented.h.
Signed-off-by: Marco Elver
---
v2:
* Use kcsan_check{,_atomic}_{read,write} instead of
kcsan_check_{access,atomic}.
* Introduce __atomic_check_{read,write} [Suggested by Mark Rutland].
---
include/asm-generic/atomic-instrumented.h
when designing and implementing KCSAN, because KCSAN would
flag these accesses as data-races. After careful analysis, our reasoning
as above led us to conclude that the best thing to do is to propose an
amendment to the raw_seqcount_barrier usage.
Signed-off-by: Marco Elver
---
include/linux
This blacklists several compilation units from KCSAN. See the respective
inline comments for the reasoning.
Signed-off-by: Marco Elver
---
kernel/Makefile | 5 +
kernel/sched/Makefile | 6 ++
mm/Makefile | 8
3 files changed, 19 insertions(+)
diff --git a
READ_ONCE).
Further, to avoid false positives in the absence of clear ending of a
seqlock reader critical section (only when using the raw interface),
KCSAN assumes a fixed number of accesses after start of a seqlock
critical section are atomic.
Signed-off-by: Marco Elver
---
include/linux
This patch adds KCSAN runtime functions to the objtool whitelist.
Signed-off-by: Marco Elver
---
tools/objtool/check.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index 044c9a3cb247..d1acc867b43c 100644
--- a/tools/objtool
architecture.
Signed-off-by: Marco Elver
---
v2:
* Elaborate comment about instrumentation calls emitted by compilers.
* Replace kcsan_check_access(.., {true, false}) with
kcsan_check_{read,write} for improved readability.
* Change bug title of race of unknown origin to just say "data-race in"
* Document x86 build exceptions where no previous above comment
explained why we cannot instrument.
v1: http://lkml.kernel.org/r/20191016083959.186860-1-el...@google.com
Marco Elver (8):
kcsan: Add Kernel Concurrency Sanitizer infrastructure
objtool, kcsan: Add KCSAN runtime functions to whit
On Thu, 17 Oct 2019 at 09:47, Peter Zijlstra wrote:
>
> On Wed, Oct 16, 2019 at 09:34:05PM +0200, Marco Elver wrote:
> > On Wed, 16 Oct 2019 at 20:44, Peter Zijlstra wrote:
> > > > + /*
> > > > + * Disable interrupts & preemptions, to
On Wed, 16 Oct 2019 at 20:44, Peter Zijlstra wrote:
>
> On Wed, Oct 16, 2019 at 10:39:52AM +0200, Marco Elver wrote:
>
> > +bool __kcsan_check_watchpoint(const volatile void *ptr, size_t size,
> > + bool is_write)
> > +{
> >
On Wed, 16 Oct 2019 at 18:14, Dave Hansen wrote:
>
> On 10/16/19 1:39 AM, Marco Elver wrote:
> > This patch enables KCSAN for x86, with updates to build rules to not use
> > KCSAN for several incompatible compilation units.
>
> First of all KCSAN looks really interesti
On Wed, 16 Oct 2019 at 17:16, Mark Rutland wrote:
>
> On Wed, Oct 16, 2019 at 10:39:52AM +0200, Marco Elver wrote:
> > diff --git a/include/linux/sched.h b/include/linux/sched.h
> > index 2c2e56bd8913..34a1d9310304 100644
> > --- a/include/linux/sched.h
> &g
> > diff --git a/Documentation/dev-tools/kcsan.rst
> > b/Documentation/dev-tools/kcsan.rst
> > new file mode 100644
> > index ..5b46cc5593c3
> > --- /dev/null
> > +++ b/Documentation/dev-tools/kcsan.rst
> > @@ -0,0 +1,202 @@
> > +The Kernel Concurrency Sanitizer (KCSAN)
> > +==
On Wed, 16 Oct 2019 at 13:18, Mark Rutland wrote:
>
> Hi Marco,
>
> On Wed, Oct 16, 2019 at 10:39:58AM +0200, Marco Elver wrote:
> > This adds KCSAN instrumentation to atomic-instrumented.h.
> >
> > Signed-off-by: Marco Elver
> > ---
> > inclu
On Wed, 16 Oct 2019 at 11:42, Boqun Feng wrote:
>
> Hi Marco,
>
> On Wed, Oct 16, 2019 at 10:39:52AM +0200, Marco Elver wrote:
> [...]
> > --- /dev/null
> > +++ b/kernel/kcsan/kcsan.c
> > @@ -0,0 +1,81 @@
> > +// SPDX-License-Identifier: GPL-2.0
>
Add explicit KCSAN checks for bitops.
Signed-off-by: Marco Elver
---
include/asm-generic/bitops-instrumented.h | 18 ++
1 file changed, 18 insertions(+)
diff --git a/include/asm-generic/bitops-instrumented.h
b/include/asm-generic/bitops-instrumented.h
index ddd1c6d9d8db
This adds KCSAN instrumentation to atomic-instrumented.h.
Signed-off-by: Marco Elver
---
include/asm-generic/atomic-instrumented.h | 192 +-
scripts/atomic/gen-atomic-instrumented.sh | 9 +-
2 files changed, 199 insertions(+), 2 deletions(-)
diff --git a/include/asm
This patch enables KCSAN for x86, with updates to build rules to not use
KCSAN for several incompatible compilation units.
Signed-off-by: Marco Elver
---
arch/x86/Kconfig | 1 +
arch/x86/boot/Makefile| 1 +
arch/x86/boot/compressed/Makefile | 1 +
arch
This blacklists several compilation units from KCSAN. See the respective
inline comments for the reasoning.
Signed-off-by: Marco Elver
---
kernel/Makefile | 5 +
kernel/sched/Makefile | 6 ++
mm/Makefile | 8
3 files changed, 19 insertions(+)
diff --git a
READ_ONCE).
Further, to avoid false positives in the absence of clear ending of a
seqlock reader critical section (only when using the raw interface),
KCSAN assumes a fixed number of accesses after start of a seqlock
critical section are atomic.
Signed-off-by: Marco Elver
---
include/linux
when designing and implementing KCSAN, because KCSAN would
flag these accesses as data-races. After careful analysis, our reasoning
as above led us to conclude that the best thing to do is to propose an
amendment to the raw_seqcount_barrier usage.
Signed-off-by: Marco Elver
---
include/linux
architecture.
Signed-off-by: Marco Elver
---
Documentation/dev-tools/kcsan.rst | 202 +
MAINTAINERS | 11 +
Makefile | 3 +-
include/linux/compiler-clang.h| 9 +
include/linux/compiler-gcc.h | 7 +
include/linux/compiler.h
This patch adds KCSAN runtime functions to the objtool whitelist.
Signed-off-by: Marco Elver
---
tools/objtool/check.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index 044c9a3cb247..d1acc867b43c 100644
--- a/tools/objtool
data-races found by KCSAN
can be found here:
https://github.com/google/ktsan/wiki/KCSAN#upstream-fixes-of-data-races-found-by-kcsan
Marco Elver (8):
kcsan: Add Kernel Concurrency Sanitizer infrastructure
objtool, kcsan: Add KCSAN runtime functions to whitelist
build, kcsan: Add KCSAN build
All 3 patches have now been Acked and Reviewed. Which tree should this land in?
Since this is related to KASAN, would this belong into the MM tree?
Many thanks,
-- Marco
On Thu, 13 Jun 2019 at 15:00, Marco Elver wrote:
>
> Previous version:
> http://lkml.kernel.org/r/20190613123028
Previous version:
http://lkml.kernel.org/r/20190531150828.157832-1-el...@google.com
* This version only changes lib/test_kasan.c.
* Remaining files are identical to v3.
Marco Elver (3):
lib/test_kasan: Add bitops tests
x86: Use static_cpu_has in uaccess region to avoid instrumentation
asm
changed to mirror this change,
however, is never instrumented with KASAN (currently unsupported under
x86 32bit).
Signed-off-by: Marco Elver
Suggested-by: H. Peter Anvin
Acked-by: Peter Zijlstra (Intel)
Reviewed-by: Andrey Ryabinin
---
Changes in v3:
* Use static_cpu_has instead of moving
This adds bitops tests to the test_kasan module. In a follow-up patch,
support for bitops instrumentation will be added.
Signed-off-by: Marco Elver
Acked-by: Mark Rutland
---
Changes in v4:
* Remove "within-bounds" tests.
* Allocate sizeof(*bite) + 1, to not actually corrupt other
s
asm-generic versions: 1) references to x86 have been removed; 2) as a
result, some of the text had to be reworded for clarity and consistency.
Tested: using lib/test_kasan with bitops tests (pre-requisite patch).
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=198439
Signed-off-by: Marco Elver
Thanks, I've sent v4.
On Thu, 13 Jun 2019 at 12:49, Andrey Ryabinin wrote:
>
>
>
> On 5/31/19 6:08 PM, Marco Elver wrote:
> > This adds bitops tests to the test_kasan module. In a follow-up patch,
> > support for bitops instrumentation will be added.
>
This adds bitops tests to the test_kasan module. In a follow-up patch,
support for bitops instrumentation will be added.
Signed-off-by: Marco Elver
Acked-by: Mark Rutland
Reviewed-by: Andrey Ryabinin
---
Changes in v5:
* Remove incorrect comment.
Changes in v4:
* Remove "within-bounds&q
Previous version:
http://lkml.kernel.org/r/20190613123028.179447-1-el...@google.com
* Only changed lib/test_kasan in this version.
Marco Elver (3):
lib/test_kasan: Add bitops tests
x86: Use static_cpu_has in uaccess region to avoid instrumentation
asm-generic, x86: Add bitops
changed to mirror this change,
however, is never instrumented with KASAN (currently unsupported under
x86 32bit).
Signed-off-by: Marco Elver
Suggested-by: H. Peter Anvin
Acked-by: Peter Zijlstra (Intel)
Reviewed-by: Andrey Ryabinin
---
Changes in v3:
* Use static_cpu_has instead of moving
s
asm-generic versions: 1) references to x86 have been removed; 2) as a
result, some of the text had to be reworded for clarity and consistency.
Tested: using lib/test_kasan with bitops tests (pre-requisite patch).
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=198439
Signed-off-by: Marco Elver
On Thu, 13 Jun 2019 at 14:49, Andrey Ryabinin wrote:
>
>
>
> On 6/13/19 3:30 PM, Marco Elver wrote:
> > This adds bitops tests to the test_kasan module. In a follow-up patch,
> > support for bitops instrumentation will be added.
> >
> > Signed-off-by: Mar
at 17:11, Marco Elver wrote:
>
> This patch is a pre-requisite for enabling KASAN bitops instrumentation;
> using static_cpu_has instead of boot_cpu_has avoids instrumentation of
> test_bit inside the uaccess region. With instrumentation, the KASAN
> check would otherwise be fla
/20190531150828.157832-3-el...@google.com
Many thanks!
-- Marco
On Sat, 1 Jun 2019 at 03:13, wrote:
>
> On May 31, 2019 2:57:36 AM PDT, Marco Elver wrote:
> >On Wed, 29 May 2019 at 16:29, wrote:
> >>
> >> On May 29, 2019 7:15:00 AM PDT, Marco Elver wrote:
> >> >This p
Addressed comments, and sent v3:
http://lkml.kernel.org/r/20190531150828.157832-1-el...@google.com
Many thanks!
-- Marco
On Wed, 29 May 2019 at 16:23, Marco Elver wrote:
>
> The previous version of this patch series and discussion can be found
> here: https://lkml.org/lkml/2019
s
asm-generic versions: 1) references to x86 have been removed; 2) as a
result, some of the text had to be reworded for clarity and consistency.
Tested: using lib/test_kasan with bitops tests (pre-requisite patch).
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=198439
Signed-off-by: Marco
This adds bitops tests to the test_kasan module. In a follow-up patch,
support for bitops instrumentation will be added.
Signed-off-by: Marco Elver
---
Changes in v3:
* Use kzalloc instead of kmalloc.
* Use sizeof(*bits).
Changes in v2:
* Use BITS_PER_LONG.
* Use heap allocated memory for test
changed to mirror this change,
however, is never instrumented with KASAN (currently unsupported under
x86 32bit).
Signed-off-by: Marco Elver
Suggested-by: H. Peter Anvin
---
Changes in v3:
* Use static_cpu_has instead of moving boot_cpu_has outside uaccess
region.
Changes in v2:
* Replaces patch
Previous version of this patch series and discussion can be found here:
http://lkml.kernel.org/r/20190529141500.193390-1-el...@google.com
Marco Elver (3):
lib/test_kasan: Add bitops tests
x86: Use static_cpu_has in uaccess region to avoid instrumentation
asm-generic, x86: Add bitops
On Wed, 29 May 2019 at 16:29, wrote:
>
> On May 29, 2019 7:15:00 AM PDT, Marco Elver wrote:
> >This patch is a pre-requisite for enabling KASAN bitops
> >instrumentation:
> >moves boot_cpu_has feature test out of the uaccess region, as
> >boot_cpu_has uses test_
On Wed, 29 May 2019 at 17:33, Mark Rutland wrote:
>
> On Wed, May 29, 2019 at 04:15:01PM +0200, Marco Elver wrote:
> > This adds a new header to asm-generic to allow optionally instrumenting
> > architecture-specific asm implementations of bitops.
> >
> > This chang
have been made in this patch.
Tested: using lib/test_kasan with bitops tests (pre-requisite patch).
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=198439
Signed-off-by: Marco Elver
---
Changes in v2:
* Instrument word-sized accesses, as specified by the interface.
---
Documentation/cor
This adds bitops tests to the test_kasan module. In a follow-up patch,
support for bitops instrumentation will be added.
Signed-off-by: Marco Elver
---
Changes in v2:
* Use BITS_PER_LONG.
* Use heap allocated memory for test, as newer compilers (correctly)
warn on OOB stack access.
---
lib
kasan_check_*
functions to the uaccess whitelist of objtool, as the case here appears
to be the only one.
Signed-off-by: Marco Elver
---
v1:
* This patch replaces patch: 'tools/objtool: add kasan_check_* to
uaccess whitelist'
---
arch/x86/ia32/ia32_signal.c | 9 -
1 file
The previous version of this patch series and discussion can be found
here: https://lkml.org/lkml/2019/5/28/769
The most significant change is the change of the instrumented access
size to cover the entire word of a bit.
Marco Elver (3):
lib/test_kasan: Add bitops tests
x86: Move CPU
On Wed, 29 May 2019 at 12:01, Peter Zijlstra wrote:
>
> On Wed, May 29, 2019 at 11:20:17AM +0200, Marco Elver wrote:
> > For the default, we decided to err on the conservative side for now,
> > since it seems that e.g. x86 operates only on the byte the bit is on.
>
> This
On Wed, 29 May 2019 at 10:55, Dmitry Vyukov wrote:
>
> On Tue, May 28, 2019 at 7:19 PM Peter Zijlstra wrote:
> >
> > On Tue, May 28, 2019 at 06:32:57PM +0200, Marco Elver wrote:
> > > This is a pre-requisite for enabling bitops instrumentation. Some bitops
&g
On Wed, 29 May 2019 at 10:53, Dmitry Vyukov wrote:
>
> On Tue, May 28, 2019 at 6:50 PM Mark Rutland wrote:
> >
> > On Tue, May 28, 2019 at 06:32:58PM +0200, Marco Elver wrote:
> > > This adds a new header to asm-generic to allow optionally instrumenting
>
have been made in this patch.
Tested: using lib/test_kasan with bitops tests (pre-requisite patch).
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=198439
Signed-off-by: Marco Elver
---
Documentation/core-api/kernel-api.rst | 2 +-
arch/x86/include/asm/bitops.h
This is a pre-requisite for enabling bitops instrumentation. Some bitops
may safely be used with instrumentation in uaccess regions.
For example, on x86, `test_bit` is used to test a CPU-feature in a
uaccess region: arch/x86/ia32/ia32_signal.c:361
Signed-off-by: Marco Elver
---
tools/objtool
This adds bitops tests to the test_kasan module. In a follow-up patch,
support for bitops instrumentation will be added.
Signed-off-by: Marco Elver
---
lib/test_kasan.c | 73 ++--
1 file changed, 70 insertions(+), 3 deletions(-)
diff --git a/lib
78 matches
Mail list logo
