lename=/usr/bin/tty pid=385 old_pid=385
<...>-389 [006] . 192.020147: new_exec: filename=/usr/bin/dmesg
pid=389 comm=bash
bash-389 [006] . 192.021377: sched_process_exec:
filename=/usr/bin/dmesg pid=389 old_pid=389
Signed-off-by: Marco Elver
---
fs/exe
On Tue, 9 Apr 2024 at 16:31, Steven Rostedt wrote:
>
> On Mon, 8 Apr 2024 11:01:54 +0200
> Marco Elver wrote:
>
> > Add "new_exec" tracepoint, which is run right after the point of no
> > return but before the current task assumes its new exec ident
On Tue, Apr 09, 2024 at 08:46AM -0700, Kees Cook wrote:
[...]
> > + trace_new_exec(current, bprm);
> > +
>
> All other steps in this function have explicit comments about
> what/why/etc. Please add some kind of comment describing why the
> tracepoint is where it is, etc.
I beefed up the tracepo
On Wed, 10 Apr 2024 at 01:54, Masami Hiramatsu wrote:
>
> On Tue, 9 Apr 2024 16:45:47 +0200
> Marco Elver wrote:
>
> > On Tue, 9 Apr 2024 at 16:31, Steven Rostedt wrote:
> > >
> > > On Mon, 8 Apr 2024 11:01:54 +0200
> > > Marco Elver wrote:
>
On Wed, 10 Apr 2024 at 15:56, Masami Hiramatsu wrote:
>
> On Mon, 8 Apr 2024 11:01:54 +0200
> Marco Elver wrote:
>
> > Add "new_exec" tracepoint, which is run right after the point of no
> > return but before the current task assumes its new exec ident
sr/bin/tty
filename=/usr/bin/tty pid=385 comm=bash
<...>-389 [006] . 192.020147: sched_prepare_exec:
interp=/usr/bin/dmesg filename=/usr/bin/dmesg pid=389 comm=bash
Signed-off-by: Marco Elver
---
v2:
* Add more documentation.
* Also show bprm->interp in trace.
* Rename to sched_prepare_exe
On Mon, 11 Dec 2023 at 23:48, Paul Heidekrüger wrote:
>
> On 11.12.2023 21:51, Andrey Konovalov wrote:
> > On Mon, Dec 11, 2023 at 7:59 PM Paul Heidekrüger
> > wrote:
> > >
> > > > Hi Paul,
> > > >
> > > > I've been successfully running KASAN tests with CONFIG_TRACEPOINTS
> > > > enabled on arm64
On Tue, 12 Dec 2023 at 10:19, Paul Heidekrüger wrote:
>
> On 12.12.2023 00:37, Andrey Konovalov wrote:
> > On Tue, Dec 12, 2023 at 12:35 AM Paul Heidekrüger
> > wrote:
> > >
> > > Using CONFIG_FTRACE=y instead of CONFIG_TRACEPOINTS=y produces the same
> > > error
> > > for me.
> > >
> > > So
> >
On Mon, 29 Jul 2024 at 14:27, Peter Zijlstra wrote:
>
> On Mon, Jul 29, 2024 at 01:46:09PM +0200, Radoslaw Zielonek wrote:
> > I am currently working on a syzbot-reported bug where bpf
> > is called from trace_sched_switch. In this scenario, we are still within
> > the scheduler context, and calli
On Fri, 2 Aug 2024 at 09:58, syzbot
wrote:
>
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:f524a5e4dfb7 Add linux-next specific files for 20240802
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=174c896d98
> kernel config: https
On Thu, 12 Sept 2024 at 13:03, Michael S. Tsirkin wrote:
>
> On Thu, Sep 12, 2024 at 01:11:21AM -0700, syzbot wrote:
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit:7c6a3a65ace7 minmax: reduce min/max macro expansion in ato..
> > git tree: upstream
> > console
On Thu, 12 Sept 2024 at 16:34, Michael S. Tsirkin wrote:
>
> On Thu, Sep 12, 2024 at 03:48:32PM +0200, Marco Elver wrote:
> > On Thu, 12 Sept 2024 at 13:03, Michael S. Tsirkin wrote:
> > >
> > > On Thu, Sep 12, 2024 at 01:11:21AM -0700, syzbot wrote:
> > >
> Tag the field __data_racy for now.
> We should probably look at ways to make this more straight-forwardly
> correct.
>
> Cc: Marco Elver
> Reported-by: syzbot+8a02104389c2e0ef5...@syzkaller.appspotmail.com
> Signed-off-by: Michael S. Tsirkin
> ---
> drivers/virti
can not figure all this out, and warns about
> the race between the write and the read. Tag the access data_racy for
> now. We should probably look at ways to make this more
> straight-forwardly correct.
>
> Cc: Marco Elver
> Reported-by: syzbot+8a02104389c2e0ef5...@syzkaller.appsp
On Tue, 20 Apr 2021 at 23:26, Marek Szyprowski wrote:
>
> Hi Marco,
>
> On 08.04.2021 12:36, Marco Elver wrote:
> > Introduces the TRAP_PERF si_code, and associated siginfo_t field
> > si_perf. These will be used by the perf event subsystem to send signals
> > (if r
On Fri, 25 Aug 2023 at 23:15, 'Jann Horn' via kasan-dev
wrote:
>
> Currently, KASAN is unable to catch use-after-free in SLAB_TYPESAFE_BY_RCU
> slabs because use-after-free is allowed within the RCU grace period by
> design.
>
> Add a SLUB debugging feature which RCU-delays every individual
> kmem
On Tue, 6 Apr 2021 at 12:57, Vlastimil Babka wrote:
>
>
> On 4/1/21 11:24 PM, Marco Elver wrote:
> > On Thu, 1 Apr 2021 at 21:04, Daniel Latypov wrote:
> >> > }
> >> > #else
> >> > static inline bool slab_add_kunit_e
signal was suggested by Peter Zijlstra in [3].
[2]
https://lore.kernel.org/lkml/CACT4Y+YPrXGw+AtESxAgPyZ84TYkNZdP0xpocX2jwVAbZD=-x...@mail.gmail.com/
[3]
https://lore.kernel.org/lkml/ybv3rat566k+6...@hirez.programming.kicks-ass.net/
Marco Elver (9):
perf: Apply PERF_EVENT_IOC_MODIFY_ATTRIBUTES
d
not find a half baked event.
To address this, teach perf_remove_from_context() to special case
!ctx->is_active and about DETACH_CHILD.
Signed-off-by: Peter Zijlstra (Intel)
[ el...@google.com: fix racing parent/child exit in sync_child_event(). ]
Signed-off-by: Marco Elver
---
v4:
* Fix for pa
As with other ioctls (such as PERF_EVENT_IOC_{ENABLE,DISABLE}), fix up
handling of PERF_EVENT_IOC_MODIFY_ATTRIBUTES to also apply to children.
Suggested-by: Dmitry Vyukov
Reviewed-by: Dmitry Vyukov
Signed-off-by: Marco Elver
---
kernel/events/core.c | 22 +-
1 file changed
hared environment.
Link:
https://lore.kernel.org/lkml/ybvj6ejr%2fdy2t...@hirez.programming.kicks-ass.net/
Suggested-by: Peter Zijlstra
Signed-off-by: Marco Elver
---
v2:
* Add patch to series.
---
include/linux/perf_event.h | 5 +++--
include/uapi/linux/perf_event.h | 3 ++-
kernel/events/c
Signed-off-by: Marco Elver
---
v3:
* Rework based on Peter's "perf: Rework perf_event_exit_event()" added
to the beginning of the series. Intermediate attempts between v2 and
this v3 can be found here:
https://lkml.kernel.org/r/yfm6aaksrlf2n...@elver.google.com
v2:
Introduces the TRAP_PERF si_code, and associated siginfo_t field
si_perf. These will be used by the perf event subsystem to send signals
(if requested) to the task where an event occurred.
Acked-by: Geert Uytterhoeven # m68k
Acked-by: Arnd Bergmann # asm-generic
Signed-off-by: Marco Elver
/ybv3rat566k+6...@hirez.programming.kicks-ass.net/
Suggested-by: Peter Zijlstra
Acked-by: Dmitry Vyukov
Signed-off-by: Marco Elver
---
v4:
* Generalize setting si_perf and si_addr independent of event type;
introduces perf_event_attr::sig_data, which can be set by user space to
be propagated to si_perf
ftest framework provides.
Signed-off-by: Marco Elver
---
v4:
* Update for new perf_event_attr::sig_data / si_perf handling.
v3:
* Fix for latest libc signal.h.
v2:
* Patch added to series.
---
.../testing/selftests/perf_events/.gitignore | 2 +
tools/testing/selftests/perf_events/Makefile | 6 +
Add kselftest to test that remove_on_exec removes inherited events from
child tasks.
Signed-off-by: Marco Elver
---
v3:
* Fix for latest libc signal.h.
v2:
* Add patch to series.
---
.../testing/selftests/perf_events/.gitignore | 1 +
tools/testing/selftests/perf_events/Makefile | 2
Sync tool's uapi to pick up the changes adding inherit_thread,
remove_on_exec, and sigtrap fields to perf_event_attr.
Signed-off-by: Marco Elver
---
v4:
* Update for new perf_event_attr::sig_data.
v3:
* Added to series.
---
tools/include/uapi/linux/perf_event.h | 12 +++-
1
-off-by: Marco Elver
---
v4:
* Update for new perf_event_attr::sig_data / si_perf handling.
v3:
* Added to series (per suggestion from Ian Rogers).
---
tools/perf/tests/Build | 1 +
tools/perf/tests/builtin-test.c | 5 ++
tools/perf/tests/sigtrap.c | 150
decide if our reports can include
other potentially sensitive information such as registers and corrupted
bytes.
Cc: Timur Tabi
Signed-off-by: Marco Elver
---
Depends on "lib/vsprintf: no_hash_pointers prints all addresses as
unhashed", which was merged into mainline yesterday:
https://
Threads receiving signals on performance events to
throttle/unthrottle themselves.
Marco Elver (4):
perf/core: Apply PERF_EVENT_IOC_MODIFY_ATTRIBUTES to children
signal: Introduce TRAP_PERF si_code and si_perf to siginfo
perf/core: Add support for SIGTRAP on perf events
perf/
As with other ioctls (such as PERF_EVENT_IOC_{ENABLE,DISABLE}), fix up
handling of PERF_EVENT_IOC_MODIFY_ATTRIBUTES to also apply to children.
Link: https://lkml.kernel.org/r/ybqvay8atmyto...@hirez.programming.kicks-ass.net
Suggested-by: Dmitry Vyukov
Signed-off-by: Marco Elver
---
kernel
Introduces the TRAP_PERF si_code, and associated siginfo_t field
si_perf. These will be used by the perf event subsystem to send signals
(if requested) to the task where an event occurred.
Signed-off-by: Marco Elver
---
arch/m68k/kernel/signal.c | 3 +++
arch/x86/kernel
synchronous signals on perf events
in the task where an event (such as breakpoints) triggered.
Link:
https://lore.kernel.org/lkml/ybv3rat566k+6...@hirez.programming.kicks-ass.net/
Suggested-by: Peter Zijlstra
Signed-off-by: Marco Elver
---
include/uapi/linux/perf_event.h | 3 ++-
kernel/events
to user space.
Signed-off-by: Marco Elver
---
kernel/events/core.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 8718763045fd..d7908322d796 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -6296,6 +6296,17
On Tue, 23 Feb 2021 at 16:01, Dmitry Vyukov wrote:
>
> On Tue, Feb 23, 2021 at 3:34 PM Marco Elver wrote:
> >
> > Encode information from breakpoint attributes into siginfo_t, which
> > helps disambiguate which breakpoint fired.
> >
> > Note, providing the e
On Tue, 23 Feb 2021 at 16:16, Dmitry Vyukov wrote:
>
> On Tue, Feb 23, 2021 at 4:10 PM 'Marco Elver' via kasan-dev
> wrote:
> > > > Encode information from breakpoint attributes into siginfo_t, which
> > > > helps disambiguate which breakpoint fired.
&
On Tue, 23 Feb 2021 at 15:34, Marco Elver wrote:
>
> The perf subsystem today unifies various tracing and monitoring
> features, from both software and hardware. One benefit of the perf
> subsystem is automatically inheriting events to child tasks, which
> enables process-wide ev
On Tue, 23 Feb 2021 at 21:27, Andy Lutomirski wrote:
> > On Feb 23, 2021, at 6:34 AM, Marco Elver wrote:
> >
> > The perf subsystem today unifies various tracing and monitoring
> > features, from both software and hardware. One benefit of the perf
> > subsyst
On Tue, 9 Feb 2021 at 19:06, Vlastimil Babka wrote:
> On 2/9/21 4:13 PM, Marco Elver wrote:
> > We cannot rely on CONFIG_DEBUG_KERNEL to decide if we're running a
> > "debug kernel" where we can safely show potentially sensitive
> > information in the kernel lo
sting/selftests/kselftest_module.h| 18 ++---
> 4 files changed, 75 insertions(+), 10 deletions(-)
I wanted to test this for deciding if we can show sensitive info in
KFENCE reports, which works just fine now that debug_never_hash_pointers
is non-static. FWIW,
Acked-by: Marco E
alloc caches
> via a new kasan_cache_create_kmalloc() annotation.
>
> Signed-off-by: Andrey Konovalov
Reviewed-by: Marco Elver
> ---
> include/linux/kasan.h | 9 +
> mm/kasan/common.c | 18 ++
> mm/slab_common.c | 1 +
> 3 files changed, 24 insertions(+)
On Mon, Feb 01, 2021 at 08:43PM +0100, Andrey Konovalov wrote:
> For allocations from kmalloc caches, kasan_kmalloc() always follows
> kasan_slab_alloc(). Currenly, both of them unpoison the whole object,
> which is unnecessary.
>
> This patch provides separate implementations for both annotations
) to only poison the redzone.
>
> Signed-off-by: Andrey Konovalov
Reviewed-by: Marco Elver
> ---
> mm/kasan/common.c | 20 +++-
> 1 file changed, 15 insertions(+), 5 deletions(-)
>
> diff --git a/mm/kasan/common.c b/mm/kasan/common.c
> index 128cb3
lection_enabled() is always
> true for generic KASAN. The confusion that this brings outweights saving
> a few instructions.
>
> Signed-off-by: Andrey Konovalov
Reviewed-by: Marco Elver
> ---
> mm/kasan/common.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
On Tue, 2 Feb 2021 at 18:16, Andrey Konovalov wrote:
>
> On Tue, Feb 2, 2021 at 5:25 PM Marco Elver wrote:
> >
> > > +#ifdef CONFIG_KASAN_GENERIC
> > > +
> > > +/**
> > > + * kasan_poison_last_granule - mark the last granule of the memory range
On Tue, 2 Feb 2021 at 18:59, Eric Dumazet wrote:
>
> On Mon, Feb 1, 2021 at 5:04 PM Marco Elver wrote:
> >
> > Avoid the assumption that ksize(kmalloc(S)) == ksize(kmalloc(S)): when
> > cloning an skb, save and restore truesize after pskb_expand_head(). This
> &
On Tue, 2 Feb 2021 at 19:01, 'Andrey Konovalov' via kasan-dev
wrote:
[...]
> > > @@ -83,6 +83,7 @@ static inline void kasan_disable_current(void) {}
> > > struct kasan_cache {
> > > int alloc_meta_offset;
> > > int free_meta_offset;
> > > + bool is_kmalloc;
[...]
> > > if (k
On Mon, 14 Dec 2020 at 11:09, Marco Elver wrote:
> On Thu, 10 Dec 2020 at 20:01, Marco Elver wrote:
> > On Thu, 10 Dec 2020 at 18:14, Eric Dumazet wrote:
> > > On Thu, Dec 10, 2020 at 5:51 PM Marco Elver wrote:
> > [...]
> > > > So I started puttin
t; first byte of the memory that's being freed is accessible.
>
> Signed-off-by: Andrey Konovalov
Reviewed-by: Marco Elver
> ---
> include/linux/kasan.h | 16
> mm/kasan/common.c | 36 ++--
> 2 files changed, 34 inser
On Mon, Feb 01, 2021 at 08:43PM +0100, Andrey Konovalov wrote:
> Currently, krealloc() always calls ksize(), which unpoisons the whole
> object including the redzone. This is inefficient, as kasan_krealloc()
> repoisons the redzone for objects that fit into the same buffer.
>
> This patch changes
KASAN mode, and check accesses to that granule accordingly.
>
> Signed-off-by: Andrey Konovalov
Reviewed-by: Marco Elver
> ---
> lib/test_kasan.c | 91 ++--
> 1 file changed, 81 insertions(+), 10 deletions(-)
>
> diff --git a/lib/tes
ambiguous, because either way behaviour of
krealloc differs from a kernel with KASAN disabled. Something like
"kasan, mm: fail krealloc on already freed object" perhaps?
> This patch also adds a KASAN-KUnit test to check krealloc() behaviour
> when it's called on a freed objec
and
> kasan_unpoison().
>
> Signed-off-by: Andrey Konovalov
Reviewed-by: Marco Elver
> ---
> mm/kasan/common.c | 9 ++---
> mm/kasan/kasan.h | 33 -
> mm/kasan/shadow.c | 37 ++---
> 3 files change
On Mon, Feb 01, 2021 at 08:43PM +0100, Andrey Konovalov wrote:
> Mark all static functions in common.c and kasan.h that are used for
> hardware tag-based KASAN as __always_inline to avoid unnecessary
> function calls.
>
> Signed-off-by: Andrey Konovalov
Does objtool complain about any of these?
On Fri, 29 Jan 2021 at 19:50, Andrey Konovalov wrote:
>
> KFENCE annotations operate on untagged addresses.
>
> Untag addresses in KASAN runtime where they might be tagged.
>
> Signed-off-by: Andrey Konovalov
Reviewed-by: Marco Elver
Thank you!
> ---
>
> This can b
+7b99aafdcc2eedea6...@syzkaller.appspotmail.com
Suggested-by: Eric Dumazet
Signed-off-by: Marco Elver
---
net/core/skbuff.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 2af12f7e170c..3787093239f5 100644
--- a/net/core
On Mon, 1 Feb 2021 at 17:50, Christoph Paasch
wrote:
> On Mon, Feb 1, 2021 at 8:09 AM Marco Elver wrote:
> >
> > Avoid the assumption that ksize(kmalloc(S)) == ksize(kmalloc(S)): when
> > cloning an skb, save and restore truesize after pskb_expand_head(). This
> >
On Fri, 5 Feb 2021 at 18:00, syzbot
wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:2ab38c17 mailmap: remove the "repo-abbrev" comment
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=130e19b4d0
> kernel config: https://syzkal
+2c308b859c8c103aa...@syzkaller.appspotmail.com
Reported-by: syzbot+44f9b37d2de57637d...@syzkaller.appspotmail.com
Reported-by: syzbot+49a9bcf457723ecaf...@syzkaller.appspotmail.com
Reported-by: syzbot+b9914ed52d5b1d63f...@syzkaller.appspotmail.com
Signed-off-by: Marco Elver
---
Note: These 4 data races are
future, this default might makes sense for production
> kernels, assuming we implement a fast stack trace collection approach.
>
> Signed-off-by: Andrey Konovalov
Reviewed-by: Marco Elver
I'm in favor of this simplification.
The fact that CONFIG_DEBUG_KERNEL cannot be relied upon to d
y: syzbot+3536db46dfa58c573...@syzkaller.appspotmail.com
Reported-by: syzbot+516acdb03d3e27d91...@syzkaller.appspotmail.com
Signed-off-by: Marco Elver
---
Detailed reports:
https://groups.google.com/g/syzkaller-upstream-moderation/c/PwsoQ7bfi8k/m/NH9Ni2WxAQAJ
https://groups.google.com/g/
KFENCE reports. The
default behaviour remains unchanged.
Signed-off-by: Marco Elver
---
Documentation/dev-tools/kfence.rst | 6 +++---
lib/Kconfig.kfence | 8
mm/kfence/core.c | 2 +-
mm/kfence/kfence.h | 3 +--
mm/kfence/report.c
On Tue, Feb 02, 2021 at 03:36PM -0600, Timur Tabi wrote:
> If the make-printk-non-secret command-line parameter is set, then
> printk("%p") will print addresses as unhashed. This is useful for
> debugging purposes.
>
> A large warning message is displayed if this option is enabled,
> because unha
On Sun, 31 May 2020 at 11:32, Dmitry Vyukov wrote:
>
> On Fri, May 29, 2020 at 7:11 PM Peter Zijlstra wrote:
> > > Like with KCSAN, we should blanket kill KASAN/UBSAN and friends (at the
> > > very least in arch/x86/) until they get that function attribute stuff
> > > sorted.
> >
> > Something li
On Mon, 18 May 2020 at 20:05, Marco Elver wrote:
>
> On Mon, 18 May 2020, 'Nick Desaulniers' via kasan-dev wrote:
>
> > On Mon, May 18, 2020 at 7:34 AM Marco Elver wrote:
> > >
> > > On Mon, 18 May 2020 at 14:44, Marco Elver wrote:
> > > >
On Tue, 19 May 2020 at 12:16, Marco Elver wrote:
>
> On Mon, 18 May 2020 at 20:05, Marco Elver wrote:
> >
> > On Mon, 18 May 2020, 'Nick Desaulniers' via kasan-dev wrote:
> >
> > > On Mon, May 18, 2020 at 7:34 AM Marco Elver wrote:
> > >
may recurse deep enough to cause kernel
reboots without warning.
To prevent similar issues in future, we should disable branch tracing
for the core runtime.
Link: https://lore.kernel.org/lkml/20200517011732.GE24705@shao2-debian/
Reported-by: kernel test robot
Signed-off-by: Marco Elver
---
mm
On Tue, 19 May 2020 at 15:40, Marco Elver wrote:
>
> On Tue, 19 May 2020 at 12:16, Marco Elver wrote:
> >
> > On Mon, 18 May 2020 at 20:05, Marco Elver wrote:
> > >
> > > On Mon, 18 May 2020, 'Nick Desaulniers' via kasan-dev wrote:
> > &
On Tue, 19 May 2020 at 23:10, Qian Cai wrote:
>
> On Tue, May 12, 2020 at 3:09 PM Peter Zijlstra wrote:
> >
> > On Tue, May 12, 2020 at 08:38:39PM +0200, Marco Elver wrote:
> > > diff --git a/include/linux/compiler.h b/include/linux/compiler.h
> > > ind
On Wed, 20 May 2020 at 05:44, Nathan Chancellor
wrote:
>
> On Tue, May 19, 2020 at 11:16:24PM -0400, Qian Cai wrote:
> > On Tue, May 19, 2020 at 10:47 PM Nathan Chancellor
> > wrote:
> > >
> > > On Tue, May 19, 2020 at 10:28:41PM -0400, Qian Cai wrote:
> > > >
> > > >
> > > > > On May 19, 2020, a
"lockdep: Prepare for NMI IRQ state tracking", KCSAN avoided
touching the IRQ trace events via raw_local_irq_save/restore() and
lockdep_off/on().
Fixes: 248591f5d257 ("kcsan: Make KCSAN compatible with new IRQ state tracking")
Signed-off-by: Marco Elver
---
v2:
* Use simple s
snapshots.
No functional change intended.
Signed-off-by: Marco Elver
---
v2:
* Introduce patch, as pre-requisite to "kcsan: Improve IRQ state trace
reporting".
---
include/linux/irqflags.h | 13 +
include/linux/sched.h| 11 ++--
kernel/fork.c| 16 ---
Cleanups, readability, and cosmetic improvements for KCSAN.
Marco Elver (5):
kcsan: Simplify debugfs counter to name mapping
kcsan: Simplify constant string handling
kcsan: Remove debugfs test command
kcsan: Show message if enabled early
kcsan: Use pr_fmt for consistency
kernel/kcsan
ned-off-by: Marco Elver
---
kernel/kcsan/debugfs.c | 8
kernel/kcsan/report.c | 4 ++--
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/kernel/kcsan/debugfs.c b/kernel/kcsan/debugfs.c
index 3a9566addeff..116bdd8f050c 100644
--- a/kernel/kcsan/debugfs.c
+++ b/kernel/kcsan
Simplify counter ID to name mapping by using an array with designated
inits. This way, we can turn a run-time BUG() into a compile-time static
assertion failure if a counter name is missing.
No functional change intended.
Signed-off-by: Marco Elver
---
kernel/kcsan/debugfs.c | 33
Remove the debugfs test command, as it is no longer needed now that we
have the KUnit+Torture based kcsan-test module. This is to avoid
confusion around how KCSAN should be tested, as only the kcsan-test
module is maintained.
Signed-off-by: Marco Elver
---
kernel/kcsan/debugfs.c | 66
Show a message in the kernel log if KCSAN was enabled early.
Signed-off-by: Marco Elver
---
kernel/kcsan/core.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/kernel/kcsan/core.c b/kernel/kcsan/core.c
index e43a55643e00..23d0c4e4cd3a 100644
--- a/kernel/kcsan/core.c
Use the same pr_fmt throughout for consistency. [ The only exception is
report.c, where the format must be kept precisely as-is. ]
Signed-off-by: Marco Elver
---
kernel/kcsan/debugfs.c | 8 +---
kernel/kcsan/selftest.c | 8 +---
2 files changed, 10 insertions(+), 6 deletions(-)
diff
11:04:17 +02:00
> >
> > READ_ONCE: Use data_race() to avoid KCSAN instrumentation
> >
> > Rather then open-code the disabling/enabling of KCSAN across the guts of
> > {READ,WRITE}_ONCE(), defer to the data_race() macro instead.
> >
> > Signed-off-by: Will Dea
On Thu, 21 May 2020 at 09:26, Borislav Petkov wrote:
>
> On Thu, May 21, 2020 at 12:30:39AM +0200, Marco Elver wrote:
> > This should be fixed when the series that includes this commit is applied:
> > https://lore.kernel.org/lkml/20200515150338.190344-9-el...@google.com/
>
On Fri, 15 May 2020 at 17:04, Marco Elver wrote:
>
> The volatile access no longer needs to be wrapped in data_race(),
> because we require compilers that emit instrumentation distinguishing
> volatile accesses.
>
> Signed-off-by: Marco Elver
> ---
> include/linux/compi
On Thu, 21 May 2020 at 11:47, Marco Elver wrote:
>
> On Fri, 15 May 2020 at 17:04, Marco Elver wrote:
> >
> > The volatile access no longer needs to be wrapped in data_race(),
> > because we require compilers that emit instrumentation distinguishing
> > volatile a
tement expression in
response to apparent issues that compilers are having with nested
statement expressions.
Arnd Bergmann (1):
ubsan, kcsan: don't combine sanitizer with kcov on clang
Marco Elver (10):
kcsan: Avoid inserting __tsan_func_entry/exit if possible
kcsan: Support disting
lore.kernel.org/lkml/20200505142341.1096942-1-a...@arndb.de
Acked-by: Marco Elver
Signed-off-by: Arnd Bergmann
Signed-off-by: Marco Elver
---
This patch is already in -rcu tree, but since since the series is based
on -tip, to avoid conflict it is required for the subsequent patches.
---
lib/Kconfig.kcsan |
.@mail.gmail.com
Signed-off-by: Marco Elver
---
include/linux/compiler.h | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index e24cc3a2bc3e..17c98b215572 100644
--- a/include/linux/compiler.h
+++ b/include/linux/comp
).
[1]
https://github.com/llvm/llvm-project/commit/5a2c31116f412c3b6888be361137efd705e05814
[2] https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544452.html
This patch allows removing any explicit checks in primitives such as
READ_ONCE() and WRITE_ONCE().
Signed-off-by: Marco Elver
---
v2
-off-by: Marco Elver
---
v2:
* Add patch to series in response to above linked discussion.
---
include/linux/compiler.h | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 7444f026eead..1f9bd9f35368 100644
--- a
Signed-off-by: Marco Elver
---
scripts/Makefile.kcsan | 1 +
1 file changed, 1 insertion(+)
diff --git a/scripts/Makefile.kcsan b/scripts/Makefile.kcsan
index 75d2942b9437..bd4da1af5953 100644
--- a/scripts/Makefile.kcsan
+++ b/scripts/Makefile.kcsan
@@ -13,6 +13,7 @@ endif
# of some options does
volatile accesses. Finally, simplify
__READ_ONCE_SCALAR and remove __WRITE_ONCE_SCALAR.
Signed-off-by: Marco Elver
---
v2:
* Remove unnecessary kcsan_check_atomic*() in *_ONCE.
* Simplify __READ_ONCE_SCALAR and remove __WRITE_ONCE_SCALAR. This
effectively restores Will Deacon's pre-KCSAN ve
Signed-off-by: Marco Elver
---
Documentation/dev-tools/kcsan.rst | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/Documentation/dev-tools/kcsan.rst
b/Documentation/dev-tools/kcsan.rst
index f4b5766f12cc..ce4bbd918648 100644
--- a/Documentation/dev-tools/kcsan.rst
entry,exit}() insertion effectively disabled
tail-call optimization, there should be no observable change. [This was
caught and confirmed with kcsan-test & UNWINDER_ORC.]
Signed-off-by: Marco Elver
---
scripts/Makefile.kcsan | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
dif
d #7.
Link:
https://lkml.kernel.org/r/CANpmjNMTsY_8241bS7=xafqvzhflrvekv_um4aduwe_kh3r...@mail.gmail.com
Signed-off-by: Marco Elver
---
lib/Kconfig.kcsan | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/lib/Kconfig.kcsan b/lib/Kconfig.kcsan
index a7276035ca0d..3f3b5bca7a8f 1
Like is done for KCSAN, for KASAN we should also use __always_inline in
compilation units that have instrumentation disabled
(KASAN_SANITIZE_foo.o := n). Adds common documentation for KASAN and
KCSAN explaining the attribute.
Signed-off-by: Marco Elver
---
include/linux/compiler_types.h | 13
Cleanup and move the KASAN and KCSAN related function attributes to
compiler_types.h, where the rest of the same kind live.
No functional change intended.
Signed-off-by: Marco Elver
---
include/linux/compiler.h | 29 -
include/linux/compiler_types.h | 29
On Fri, 15 May 2020 at 17:03, Marco Elver wrote:
>
> This patch series is the conclusion to [1], where we determined that due
> to various interactions with no_sanitize attributes and the new
> {READ,WRITE}_ONCE(), KCSAN will require Clang 11 or later. Other
> sanitizers are la
On Thu, 21 May 2020 at 15:18, Will Deacon wrote:
>
> On Thu, May 21, 2020 at 01:08:46PM +0200, Marco Elver wrote:
> > In the kernel, volatile is used in various concurrent context, whether
> > in low-level synchronization primitives or for legacy reasons. If
> > supported
On Thu, 21 May 2020 at 15:33, Will Deacon wrote:
>
> On Thu, May 21, 2020 at 01:08:50PM +0200, Marco Elver wrote:
> > Signed-off-by: Marco Elver
> > ---
> > Documentation/dev-tools/kcsan.rst | 9 +
> > 1 file changed, 1 insertion(+), 8 deletions(-)
>
On Thu, 21 May 2020 at 15:31, Will Deacon wrote:
>
> On Thu, May 21, 2020 at 01:08:52PM +0200, Marco Elver wrote:
> > It appears that compilers have trouble with nested statements
> > expressions, as such make the data_race() macro be only a single
> > statement expre
On Thu, 21 May 2020 at 15:36, Will Deacon wrote:
>
> On Thu, May 21, 2020 at 01:08:43PM +0200, Marco Elver wrote:
> > This patch series is the conclusion to [1], where we determined that due
> > to various interactions with no_sanitize attributes and the new
> > {READ,W
d #7.
Link:
https://lkml.kernel.org/r/CANpmjNMTsY_8241bS7=xafqvzhflrvekv_um4aduwe_kh3r...@mail.gmail.com
Acked-by: Will Deacon
Signed-off-by: Marco Elver
---
lib/Kconfig.kcsan | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/lib/Kconfig.kcsan b/lib/Kconfig.kcsan
index a727
1 - 100 of 1024 matches
Mail list logo
