) with kcsan_mb().
>
> Signed-off-by: Christophe Leroy
Acked-by: Marco Elver
> ---
> arch/powerpc/include/asm/simple_spinlock.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/powerpc/include/asm/simple_spinlock.h
> b/arch/powerpc/include/asm/simple_spi
/{32,book3e}: kcsan: Extend KCSAN Support
Acked-by: Marco Elver
c builtins. Only
> include DEFINE_TSAN_ATOMIC_OPS(64) on 64 bits architectures.
>
> Fixes: 0f8ad5f2e934 ("kcsan: Add support for atomic builtins")
> Suggested-by: Marco Elver
> Signed-off-by: Christophe Leroy
Reviewed-by: Marco Elver
Do you have your own tree to take
;mm: kfence: improve the performance of __kfence_alloc()
> and __kfence_free()")
> Signed-off-by: Michael Ellerman
Reviewed-by: Marco Elver
Andrew, is the Fixes enough to make it to stable as well or do we also
need Cc: stable?
Thanks,
-- Marco
> ---
> mm/kfence/kfence.h | 2
On Mon, 27 Feb 2023 at 23:16, Andrew Morton wrote:
>
> On Mon, 27 Feb 2023 10:47:27 +0100 Marco Elver wrote:
>
> > With appropriate compiler support [1], KASAN builds use __asan prefixed
> > meminstrinsics, and KASAN no longer overrides memcpy/memset/memmove.
> &
/
Reported-by: kernel test robot
Signed-off-by: Marco Elver
---
arch/powerpc/include/asm/kasan.h | 2 +-
arch/powerpc/include/asm/string.h | 15 +++
arch/powerpc/kernel/prom_init_check.sh | 9 +++--
3 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/arch
: Max Filippov
>
> This series should also be addressed to KCSAN Maintainers, shouldn't it ?
>
> KCSAN
> M:Marco Elver
> R:Dmitry Vyukov
> L:kasan-...@googlegroups.com
> S:Maintained
> F:Documentation/dev-tools/kcsan.rst
> F:include/linux/kcsan
On Wed, 8 Feb 2023 at 04:23, Rohan McLure wrote:
>
> Enable HAVE_ARCH_KCSAN on all powerpc platforms, permitting use of the
> kernel concurrency sanitiser through the CONFIG_KCSAN_* kconfig options.
> KCSAN requires compiler builtins __atomic_* 64-bit values, and so only
> report support on
On Tue, 7 Feb 2023 at 18:24, Suren Baghdasaryan wrote:
>
> On Tue, Feb 7, 2023 at 9:16 AM Marco Elver wrote:
> >
> > On Thu, Jan 26, 2023 at 09:27AM -0800, Paul E. McKenney wrote:
> > > On Wed, Jan 25, 2023 at 05:34:49PM -0800, Andrew Morton wrote:
> > >
On Thu, Jan 26, 2023 at 09:27AM -0800, Paul E. McKenney wrote:
> On Wed, Jan 25, 2023 at 05:34:49PM -0800, Andrew Morton wrote:
> > On Wed, 25 Jan 2023 16:50:01 -0800 Suren Baghdasaryan
> > wrote:
> >
> > > On Wed, Jan 25, 2023 at 4:22 PM Andrew Morton
> > > wrote:
> > > >
> > > > On Wed, 25
On Mon, 17 Oct 2022 at 17:08, Sasha Levin wrote:
>
> From: Marco Elver
>
> [ Upstream commit f95e5a3d59011eec1257d0e76de1e1f8969d426f ]
>
> Internal data structures (cpu_bps, task_bps) of powerpc's hw_breakpoint
> implementation have relied on nr_bp_mutex serializing acces
_PTRS_PER_*, which are constant.
>
> Suggested-by: Christophe Leroy
> Suggested-by: Balbir Singh
> Reviewed-by: Christophe Leroy
> Reviewed-by: Balbir Singh
> Signed-off-by: Daniel Axtens
Reviewed-by: Marco Elver
> ---
> include/linux/kasan.h | 6 +++---
> mm/kasan/
d place default definitions
> in include/pgtable.h. These define MAX_PTRS_PER_x to be PTRS_PER_x unless
> an architecture has defined MAX_PTRS_PER_x in its arch headers.
>
> Clean up pgtable-nop4d.h and s390's MAX_PTRS_PER_P4D definitions while
> we're at it: both can just pick up the d
instrumented. Inline instrumentation in DT would
> unconditionally attempt to touch the shadow region, which we won't have
> set up yet, and would crash. We can make outline mode wait for the arch to
> be ready, but we can't change what the compiler inserts for inline mode.
>
> Signed-o
With Christophe's suggestion:
Reviewed-by: Marco Elver
> --
>
> Both previous RFCs for ppc64 - by 2 different people - have
> needed this trick! See:
> - https://lore.kernel.org/patchwork/patch/592820/ # ppc64 hash series
> - https://patchwork.ozlabs.org/patch/795211/
instrumented. Inline instrumentation in DT would
> unconditionally attempt to touch the shadow region, which we won't have
> set up yet, and would crash. We can make outline mode wait for the arch to
> be ready, but we can't change what the compiler inserts for inline mode.
>
> Signed-off-by: Dani
On Wed, 16 Jun 2021 at 10:03, Daniel Axtens wrote:
[...]
> diff --git a/include/linux/kasan.h b/include/linux/kasan.h
> index 768d7d342757..fd65f477ac92 100644
> --- a/include/linux/kasan.h
> +++ b/include/linux/kasan.h
> @@ -40,10 +40,22 @@ struct kunit_kasan_expectation {
> #define
should have a negligible performance penalty.
>
> This will only work in outline mode, so an arch must specify
> ARCH_DISABLE_KASAN_INLINE if it requires this.
>
> Cc: Balbir Singh
> Cc: Aneesh Kumar K.V
> Suggested-by: Christophe Leroy
> Signed-off-by: Daniel Axtens
Revie
[+Cc Andrey]
On Tue, 15 Jun 2021 at 03:47, Daniel Axtens wrote:
>
> Building on the work of Christophe, Aneesh and Balbir, I've ported
> KASAN to 64-bit Book3S kernels running on the Radix MMU.
>
> I've been trying this for a while, but we keep having collisions
> between the kasan code in the
On Tue, 15 Jun 2021 at 03:47, Daniel Axtens wrote:
>
> Allow architectures to define a kasan_arch_is_ready() hook that bails
> out of any function that's about to touch the shadow unless the arch
> says that it is ready for the memory to be accessed. This is fairly
> uninvasive and should have a
On Tue, 15 Jun 2021 at 03:47, Daniel Axtens wrote:
>
> For annoying architectural reasons, it's very difficult to support inline
> instrumentation on powerpc64.
>
> Add a Kconfig flag to allow an arch to disable inline. (It's a bit
> annoying to be 'backwards', but I'm not aware of any way to
On Fri, 19 Mar 2021 at 15:41, Daniel Axtens wrote:
>
> For annoying architectural reasons, it's very difficult to support inline
> instrumentation on powerpc64.
>
> Add a Kconfig flag to allow an arch to disable inline. (It's a bit
> annoying to be 'backwards', but I'm not aware of any way to
On Fri, 19 Mar 2021 at 15:41, Daniel Axtens wrote:
> Allow architectures to define a kasan_arch_is_ready() hook that bails
> out of any function that's about to touch the shadow unless the arch
> says that it is ready for the memory to be accessed. This is fairly
> uninvasive and should have a
On Fri, 5 Mar 2021 at 12:49, Michael Ellerman wrote:
> Marco Elver writes:
> ...
> >
> > The choice is between:
> >
> > 1. ARCH_FUNC_PREFIX (as a matter of fact, the ARCH_FUNC_PREFIX patch
> > is already in -mm). Perhaps we could optimize it further, by
On Thu, 4 Mar 2021 at 19:51, Mark Rutland wrote:
> On Thu, Mar 04, 2021 at 07:22:53PM +0100, Marco Elver wrote:
> > On Thu, 4 Mar 2021 at 19:02, Mark Rutland wrote:
> > > On Thu, Mar 04, 2021 at 06:25:33PM +0100, Marco Elver wrote:
> > > > On Thu, Mar 04, 2021
On Thu, 4 Mar 2021 at 19:02, Mark Rutland wrote:
> On Thu, Mar 04, 2021 at 06:25:33PM +0100, Marco Elver wrote:
> > On Thu, Mar 04, 2021 at 04:59PM +, Mark Rutland wrote:
> > > On Thu, Mar 04, 2021 at 04:30:34PM +0100, Marco Elver wrote:
> > > > On Thu, 4 M
On Thu, Mar 04, 2021 at 04:59PM +, Mark Rutland wrote:
> On Thu, Mar 04, 2021 at 04:30:34PM +0100, Marco Elver wrote:
> > On Thu, 4 Mar 2021 at 15:57, Mark Rutland wrote:
> > > [adding Mark Brown]
> > >
> > > The bigger problem her
On Thu, 4 Mar 2021 at 15:57, Mark Rutland wrote:
> [adding Mark Brown]
>
> On Wed, Mar 03, 2021 at 04:20:43PM +0100, Marco Elver wrote:
> > On Wed, Mar 03, 2021 at 03:52PM +0100, Christophe Leroy wrote:
> > > Le 03/03/2021 � 15:38, Marco Elver a �crit�:
> > &
On Thu, 4 Mar 2021 at 15:08, Christophe Leroy
wrote:
>
>
>
> Le 04/03/2021 à 13:48, Marco Elver a écrit :
> > From d118080eb9552073f5dcf1f86198f3d86d5ea850 Mon Sep 17 00:00:00 2001
> > From: Marco Elver
> > Date: Thu, 4 Mar 2021 13:15:51 +0100
> >
On Thu, Mar 04, 2021 at 12:48PM +0100, Christophe Leroy wrote:
> Le 04/03/2021 à 12:31, Marco Elver a écrit :
> > On Thu, 4 Mar 2021 at 12:23, Christophe Leroy
> > wrote:
> > > Le 03/03/2021 à 11:56, Marco Elver a écrit :
> > > >
> > > > Somewh
On Thu, 4 Mar 2021 at 13:00, Christophe Leroy
wrote:
>
>
>
> Le 04/03/2021 à 12:48, Christophe Leroy a écrit :
> >
> >
> > Le 04/03/2021 à 12:31, Marco Elver a écrit :
> >> On Thu, 4 Mar 2021 at 12:23, Christophe Leroy
> >> wrote:
On Thu, 4 Mar 2021 at 12:23, Christophe Leroy
wrote:
> Le 03/03/2021 à 11:56, Marco Elver a écrit :
> >
> > Somewhat tangentially, I also note that e.g. show_regs(regs) (which
> > was printed along the KFENCE report above) didn't include the top
> > frame in the "
On Wed, Mar 03, 2021 at 03:52PM +0100, Christophe Leroy wrote:
> Le 03/03/2021 à 15:38, Marco Elver a écrit :
> > On Wed, 3 Mar 2021 at 15:09, Christophe Leroy
> > wrote:
> > >
> > > It seems like all other sane architectures, namely x86 and arm64
> > &
0024 907f0028
> 90ff001c
> [ 15.096613] 3949000a 915f0020 3d40c0d1 3d00c085 <8929000a> 3908adb0
> 812a4b98 3d40c02f
> [ 15.104612]
> ==
>
> Signed-off-by: Christophe Leroy
Acked-by: Marco Elver
Thank you, I think this looks like the right solution. Jus
On Wed, 3 Mar 2021 at 11:39, Christophe Leroy
wrote:
>
>
>
> Le 02/03/2021 à 12:39, Marco Elver a écrit :
> > On Tue, 2 Mar 2021 at 12:21, Christophe Leroy
> > wrote:
> > [...]
> >>>> Booting with 'no_hash_pointers" I get the foll
On Wed, 3 Mar 2021 at 11:32, Christophe Leroy
wrote:
>
>
>
> Le 02/03/2021 à 10:53, Marco Elver a écrit :
> > On Tue, 2 Mar 2021 at 10:27, Christophe Leroy
> > wrote:
> >> Le 02/03/2021 à 10:21, Alexander Potapenko a écrit :
> >>&
On Tue, 2 Mar 2021 at 12:21, Christophe Leroy
wrote:
[...]
> >> Booting with 'no_hash_pointers" I get the following. Does it helps ?
> >>
> >> [ 16.837198]
> >> ==
> >> [ 16.848521] BUG: KFENCE: invalid read in
> >>
might be code-gen related, which results in some subtle
issue with stack unwinding. There are a few things to try, if you feel
like it:
-- Change the unwinder, if it's possible for ppc32.
-- Add code to test_invalid_access(), to get the compiler to emit
different code. E.g. add a bunch (unnecessary)
On Tue, 2 Mar 2021 at 09:37, Christophe Leroy
wrote:
> Add architecture specific implementation details for KFENCE and enable
> KFENCE for the ppc32 architecture. In particular, this implements the
> required interface in .
Nice!
> KFENCE requires that attributes for pages from its memory pool
On Mon, 28 Oct 2019 at 14:56, Daniel Axtens wrote:
>
> Hi all,
>
> Would it be possible to get an Ack from a KASAN maintainter? mpe is
> happy to take this through powerpc but would like an ack first.
>
> Regards,
> Daniel
>
> >> Currently bitops-instrumented.h assumes that the architecture
40 matches
Mail list logo
