search for: kcsan

...I can think of that we're bound to hit. Aaargh! > diff --git a/init/main.c b/init/main.c > index 15bd0efff3df..0873319dcff4 100644 > --- a/init/main.c > +++ b/init/main.c > @@ -1041,6 +1041,22 @@ asmlinkage __visible void __init start_kernel(void) > sfi_init_late(); > kcsan_init(); > > + /* DEBUG CODE */ > + lockdep_assert_irqs_enabled(); /* Pass. */ > + { > + unsigned long flags1; > + raw_local_irq_save(flags1); This disables IRQs but doesn't trace.. > + { > + unsigned long flags2; > + lockdep_assert_irqs_enabled(); /* Pass -...

On Wed, Aug 05, 2020 at 03:59:40PM +0200, Marco Elver wrote: > On Wed, Aug 05, 2020 at 03:42PM +0200, peterz at infradead.org wrote: > > Shouldn't we __always_inline those? They're going to be really small. > > I can send a v2, and you can choose. For reference, though: > > ffffffff86271ee0 <arch_local_save_flags>: > ffffffff86271ee0: 0f 1f 44 00 00

On Wed, Aug 05, 2020 at 03:59:40PM +0200, Marco Elver wrote: > On Wed, Aug 05, 2020 at 03:42PM +0200, peterz at infradead.org wrote: > > Shouldn't we __always_inline those? They're going to be really small. > > I can send a v2, and you can choose. For reference, though: > > ffffffff86271ee0 <arch_local_save_flags>: > ffffffff86271ee0: 0f 1f 44 00 00

...think of that we're bound to hit. >>> ... >>>> >>>> /me goes ponder things... >>>> >>>> How's something like this then? >>>> >>>> --- >>>> include/linux/sched.h | 3 --- >>>> kernel/kcsan/core.c | 62 ++++++++++++++++++++++++++++++++++++--------------- >>>> 2 files changed, 44 insertions(+), 21 deletions(-) >>> >>> Thank you! That approach seems to pass syzbot (also with >>> CONFIG_PARAVIRT) and kcsan-test tests. >>> >>> I...

...t;>>> >>>>>> /me goes ponder things... >>>>>> >>>>>> How's something like this then? >>>>>> >>>>>> --- >>>>>> include/linux/sched.h | 3 --- >>>>>> kernel/kcsan/core.c | 62 ++++++++++++++++++++++++++++++++++++--------------- >>>>>> 2 files changed, 44 insertions(+), 21 deletions(-) >>>>> >>>>> Thank you! That approach seems to pass syzbot (also with >>>>> CONFIG_PARAVIRT) and kcsan-test te...

...onder things... >>>>>>>> >>>>>>>> How's something like this then? >>>>>>>> >>>>>>>> --- >>>>>>>> include/linux/sched.h | 3 --- >>>>>>>> kernel/kcsan/core.c | 62 ++++++++++++++++++++++++++++++++++++--------------- >>>>>>>> 2 files changed, 44 insertions(+), 21 deletions(-) >>>>>>> >>>>>>> Thank you! That approach seems to pass syzbot (also with >>>>>>> C...

...eract + * with an explicit memory barrier or atomic instruction that provides the + * required ordering. + */ +#ifndef __ASM_GENERIC_RWONCE_H +#define __ASM_GENERIC_RWONCE_H + +#ifndef __ASSEMBLY__ + +#include <linux/compiler_types.h> +#include <linux/kasan-checks.h> +#include <linux/kcsan-checks.h> + +#include <asm/barrier.h> + +/* + * Use __READ_ONCE() instead of READ_ONCE() if you do not require any + * atomicity or dependency ordering guarantees. Note that this may result + * in tears! + */ +#define __READ_ONCE(x) (*(const volatile __unqual_scalar_typeof(x) *)&(x)) +...

...eract + * with an explicit memory barrier or atomic instruction that provides the + * required ordering. + */ +#ifndef __ASM_GENERIC_RWONCE_H +#define __ASM_GENERIC_RWONCE_H + +#ifndef __ASSEMBLY__ + +#include <linux/compiler_types.h> +#include <linux/kasan-checks.h> +#include <linux/kcsan-checks.h> + +#include <asm/barrier.h> + +/* + * Use __READ_ONCE() instead of READ_ONCE() if you do not require any + * atomicity or dependency ordering guarantees. Note that this may result + * in tears! + */ +#define __READ_ONCE(x) (*(const volatile __unqual_scalar_typeof(x) *)&(x)) +...

...c instruction that provides the > + * required ordering. > + */ > +#ifndef __ASM_GENERIC_RWONCE_H > +#define __ASM_GENERIC_RWONCE_H > + > +#ifndef __ASSEMBLY__ > + > +#include <linux/compiler_types.h> > +#include <linux/kasan-checks.h> > +#include <linux/kcsan-checks.h> > + > +#include <asm/barrier.h> > + > +/* > + * Use __READ_ONCE() instead of READ_ONCE() if you do not require any > + * atomicity or dependency ordering guarantees. Note that this may result > + * in tears! > + */ > +#define __READ_ONCE(x) (*(const vol...

On Wed, Aug 05, 2020 at 03:26:29PM +0200, Marco Elver wrote: > Add missing noinstr to arch_local*() helpers, as they may be called from > noinstr code. > > On a KCSAN config with CONFIG_PARAVIRT=y, syzbot stumbled across corrupt Cute, so I've been working on adding objtool support for this a little: https://lkml.kernel.org/r/20200803143231.GE2674 at hirez.programming.kicks-ass.net > diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/...

...gt; #include <uapi/linux/time.h> diff --git a/include/asm-generic/rwonce.h b/include/asm-generic/rwonce.h index cc810f1f18ca..cd0302746fb4 100644 --- a/include/asm-generic/rwonce.h +++ b/include/asm-generic/rwonce.h @@ -26,8 +26,6 @@ #include <linux/kasan-checks.h> #include <linux/kcsan-checks.h> -#include <asm/barrier.h> - /* * Use __READ_ONCE() instead of READ_ONCE() if you do not require any * atomicity. Note that this may result in tears! diff --git a/include/linux/nospec.h b/include/linux/nospec.h index 0c5ef54fd416..c1e79f72cd89 100644 --- a/include/linux/nos...

...> > diff --git a/include/asm-generic/rwonce.h b/include/asm-generic/rwonce.h > index cc810f1f18ca..cd0302746fb4 100644 > --- a/include/asm-generic/rwonce.h > +++ b/include/asm-generic/rwonce.h > @@ -26,8 +26,6 @@ > #include <linux/kasan-checks.h> > #include <linux/kcsan-checks.h> > > -#include <asm/barrier.h> > - > /* > * Use __READ_ONCE() instead of READ_ONCE() if you do not require any > * atomicity. Note that this may result in tears! > diff --git a/include/linux/nospec.h b/include/linux/nospec.h > index 0c5ef54fd416..c1e79...

Hi all, This is version three of the patches I previously posted here: v1: https://lore.kernel.org/lkml/20191108170120.22331-1-will at kernel.org/ v2: https://lore.kernel.org/r/20200630173734.14057-1-will at kernel.org Changes since v2 include: * Actually add the barrier in READ_ONCE() for Alpha! * Implement Alpha's smp_load_acquire() using __READ_ONCE(), rather than the other

...ic inline void kmap_local_fork(struct task_struct *tsk) { } +static inline void kmap_assert_nomap(void) { } #endif #ifdef CONFIG_HIGHMEM --- a/include/linux/sched.h +++ b/include/linux/sched.h @@ -34,6 +34,7 @@ #include <linux/rseq.h> #include <linux/seqlock.h> #include <linux/kcsan.h> +#include <asm/kmap_size.h> /* task_struct member predeclarations (sorted alphabetically): */ struct audit_context; @@ -629,6 +630,13 @@ struct wake_q_node { struct wake_q_node *next; }; +struct kmap_ctrl { +#ifdef CONFIG_KMAP_LOCAL + int idx; + pte_t pteval[KM_TYPE_NR];...

Hi everyone, This is the long-awaited version two of the patches I previously posted in November last year: https://lore.kernel.org/lkml/20191108170120.22331-1-will at kernel.org/ I ended up parking the series while the READ_ONCE() implementation was being overhauled, but with that merged during the recent merge window and LTO patches being posted again [1], it was time for a refresh. The

Hi everyone, This is the long-awaited version two of the patches I previously posted in November last year: https://lore.kernel.org/lkml/20191108170120.22331-1-will at kernel.org/ I ended up parking the series while the READ_ONCE() implementation was being overhauled, but with that merged during the recent merge window and LTO patches being posted again [1], it was time for a refresh. The

A malicious actor behind one bridge port may spam the kernel with packets with a random source MAC address, each of which will create an FDB entry, each of which is a dynamic allocation in the kernel. There are roughly 2^48 different MAC addresses, further limited by the rhashtable they are stored in to 2^31. Each entry is of the type struct net_bridge_fdb_entry, which is currently 128 bytes big.

Following up to the discussion in: https://lore.kernel.org/r/20200914204209.256266093 at linutronix.de and the second version of this: https://lore.kernel.org/r/20201029221806.189523375 at linutronix.de this series provides a preemptible variant of kmap_atomic & related interfaces. This is achieved by: - Removing the RT dependency from migrate_disable/enable() - Consolidating all

Following up to the discussion in: https://lore.kernel.org/r/20200914204209.256266093 at linutronix.de and the second version of this: https://lore.kernel.org/r/20201029221806.189523375 at linutronix.de this series provides a preemptible variant of kmap_atomic & related interfaces. This is achieved by: - Removing the RT dependency from migrate_disable/enable() - Consolidating all

Following up to the discussion in: https://lore.kernel.org/r/20200914204209.256266093 at linutronix.de and the second version of this: https://lore.kernel.org/r/20201029221806.189523375 at linutronix.de this series provides a preemptible variant of kmap_atomic & related interfaces. This is achieved by: - Removing the RT dependency from migrate_disable/enable() - Consolidating all