> [] start_kernel+0x12e/0x3c0
> [] x86_64_start_reservations+0x18/0x30
> [] x86_64_start_kernel+0x7b/0x80
> [] secondary_startup_64_no_verify+0x15e/0x16b
>
> Link: https://lore.kernel.org/linux-trace-kernel/87r0hfnr9r@kernel.org/
>
> Fixes: 44dc5c41b5b1 ("tracing: Fix wasted memory in saved_cmdlines logic")
> Reported-by: Kalle Valo
> Signed-off-by: Steven Rostedt (Google)
Reviewed-by: Catalin Marinas
ch/arm64/kernel/vdso32/Makefile | 10 --
For arm64:
Acked-by: Catalin Marinas
On Wed, Oct 25, 2023 at 05:52:58PM +0900, Hyesoo Yu wrote:
> If we only avoid using ALLOC_CMA for __GFP_TAGGED, would we still be able to
> use
> the next iteration even if the hardware does not support "tag of tag" ?
It depends on how the next iteration looks like. The plan was not to
support
On Mon, Oct 16, 2023 at 01:41:15PM +0100, Alexandru Elisei wrote:
> On Thu, Oct 12, 2023 at 10:25:11AM +0900, Hyesoo Yu wrote:
> > I don't think it would be effcient when the majority of movable pages
> > do not use GFP_TAGGED.
> >
> > Metadata pages have a low probability of being in the pcp
Hi Kuan-Ying,
On Wed, Sep 13, 2023 at 08:11:40AM +, Kuan-Ying Lee (李冠穎) wrote:
> On Wed, 2023-08-23 at 14:13 +0100, Alexandru Elisei wrote:
> > diff --git a/arch/arm64/boot/dts/arm/fvp-base-revc.dts
> > b/arch/arm64/boot/dts/arm/fvp-base-revc.dts
> > index 60472d65a355..bd050373d6cf 100644
>
On Mon, Sep 11, 2023 at 02:29:03PM +0200, David Hildenbrand wrote:
> On 11.09.23 13:52, Catalin Marinas wrote:
> > On Wed, Sep 06, 2023 at 12:23:21PM +0100, Alexandru Elisei wrote:
> > > On Thu, Aug 24, 2023 at 04:24:30PM +0100, Catalin Marinas wrote:
> > > > On T
On Wed, Sep 06, 2023 at 12:23:21PM +0100, Alexandru Elisei wrote:
> On Thu, Aug 24, 2023 at 04:24:30PM +0100, Catalin Marinas wrote:
> > On Thu, Aug 24, 2023 at 01:25:41PM +0200, David Hildenbrand wrote:
> > > On 24.08.23 13:06, David Hildenbrand wrote:
> > > &
HOLES_IN_ZONE
> select IOMMU_DMA if IOMMU_SUPPORT
> select IRQ_DOMAIN
> select IRQ_FORCED_THREADING
> @@ -1053,9 +1054,6 @@ config NEED_PER_CPU_EMBED_FIRST_CHUNK
> def_bool y
> depends on NUMA
>
> -config HOLES_IN_ZONE
> - def_bool y
> -
> source "kernel/Kconfig.hz"
For arm64:
Acked-by: Catalin Marinas
Hi Linus,
A recent commit (2decad92f473, "arm64: mte: Ensure TIF_MTE_ASYNC_FAULT
is set atomically") broke the kernel build when using the LLVM
integrated assembly (only noticeable with clang-12 as MTE is not
supported by earlier versions and the code in question not compiled).
The Fixes: tag in
On Fri, Apr 16, 2021 at 03:55:31PM +0800, He Zhe wrote:
> The general version of is_syscall_success does not handle 32-bit
> compatible case, which would cause 32-bit negative return code to be
> recoganized as a positive number later and seen as a "success".
>
> Since is_compat_thread is defined
On Tue, 13 Apr 2021 17:08:04 -0700, Nathan Chancellor wrote:
> After commit 2decad92f473 ("arm64: mte: Ensure TIF_MTE_ASYNC_FAULT is
> set atomically"), LLVM's integrated assembler fails to build entry.S:
>
> :5:7: error: expected assembly-time absolute expression
> .org . - (664b-663b) +
On Thu, Apr 15, 2021 at 08:50:25AM -0700, Sami Tolvanen wrote:
> On Thu, Apr 15, 2021 at 7:02 AM Catalin Marinas
> wrote:
> >
> > On Thu, Apr 15, 2021 at 06:25:57AM -0700, Nathan Chancellor wrote:
> > > On Thu, Apr 15, 2021 at 10:17:43AM +0100, Catalin Marinas wrote:
&
On Thu, Apr 15, 2021 at 04:28:21PM +0100, Will Deacon wrote:
> On Thu, Apr 15, 2021 at 05:03:58PM +0200, Peter Zijlstra wrote:
> > On Thu, Apr 15, 2021 at 02:25:52PM +, Ali Saidi wrote:
> > > While this code is executed with the wait_lock held, a reader can
> > > acquire the lock without
On Thu, Apr 15, 2021 at 06:25:57AM -0700, Nathan Chancellor wrote:
> On Thu, Apr 15, 2021 at 10:17:43AM +0100, Catalin Marinas wrote:
> > On Tue, Apr 13, 2021 at 05:08:04PM -0700, Nathan Chancellor wrote:
> > > After commit 2decad92f473 ("arm64: mte: Ensure TIF_MTE_A
Hi Nathan,
On Tue, Apr 13, 2021 at 05:08:04PM -0700, Nathan Chancellor wrote:
> After commit 2decad92f473 ("arm64: mte: Ensure TIF_MTE_ASYNC_FAULT is
> set atomically"), LLVM's integrated assembler fails to build entry.S:
>
> :5:7: error: expected assembly-time absolute expression
> .org . -
(fixed Will's email address)
On Thu, Apr 15, 2021 at 10:09:54AM +0200, Peter Zijlstra wrote:
> On Thu, Apr 15, 2021 at 05:47:34AM +0900, Stafford Horne wrote:
> > > How's this then? Compile tested only on openrisc/simple_smp_defconfig.
> >
> > I did my testing with this FPGA build SoC:
> >
> >
On Wed, Apr 14, 2021 at 05:25:43PM +0800, Kai Shen wrote:
> Performance decreases happen in __arch_clear_user when this
> function is not correctly aligned on HISI-HIP08 arm64 SOC which
> fetches 32 bytes (8 instructions) from icache with a 32-bytes
> aligned end address. As a result, if the hot
On Tue, 30 Mar 2021 04:57:50 -0700, zhouchuangao wrote:
> It can be optimized at compile time.
Applied to arm64 (for-next/misc), it saves one line ;). Thanks!
[1/1] arm64/kernel/probes: Use BUG_ON instead of if condition followed by BUG.
https://git.kernel.org/arm64/c/839157876f97
--
On Wed, Apr 14, 2021 at 08:23:51AM +0800, Guo Ren wrote:
> On Tue, Apr 13, 2021 at 5:31 PM Catalin Marinas
> wrote:
> > On Tue, Apr 13, 2021 at 11:22:40AM +0200, Christoph Müllner wrote:
> > > On Tue, Apr 13, 2021 at 10:03 AM Peter Zijlstra
> > > wrote:
> &g
On Tue, Apr 13, 2021 at 04:52:34PM +, Liam Howlett wrote:
> * Catalin Marinas [210412 13:44]:
> > On Wed, Apr 07, 2021 at 03:11:06PM +, Liam Howlett wrote:
> > > find_vma() will continue to search upwards until the end of the virtual
> > > memory space. T
On Tue, Apr 13, 2021 at 12:25:00PM +0200, Christoph Müllner wrote:
> On Tue, Apr 13, 2021 at 11:37 AM Peter Zijlstra wrote:
> > On Tue, Apr 13, 2021 at 11:22:40AM +0200, Christoph Müllner wrote:
> > > What about trylock()?
> > > I.e. one could implement trylock() without a loop, by letting
> > >
On Mon, 15 Mar 2021 13:20:10 +, Vincenzo Frascino wrote:
> This patchset implements the asynchronous mode support for ARMv8.5-A
> Memory Tagging Extension (MTE), which is a debugging feature that allows
> to detect with the help of the architecture the C and C++ programmatic
> memory errors
On Tue, Apr 13, 2021 at 11:22:40AM +0200, Christoph Müllner wrote:
> On Tue, Apr 13, 2021 at 10:03 AM Peter Zijlstra wrote:
> > On Mon, Apr 12, 2021 at 11:54:55PM +0200, Christoph Müllner wrote:
> > > On Mon, Apr 12, 2021 at 7:33 PM Palmer Dabbelt wrote:
> > > > My plan is to add a generic
On Tue, Apr 13, 2021 at 06:59:36PM +1000, Stephen Rothwell wrote:
> diff --cc lib/test_kasan.c
> index 785e724ce0d8,bf9225002a7e..
> --- a/lib/test_kasan.c
> +++ b/lib/test_kasan.c
> @@@ -78,33 -83,30 +83,35 @@@ static void kasan_test_exit(struct kuni
>* fields, it can reorder or
On Wed, Apr 07, 2021 at 03:11:06PM +, Liam Howlett wrote:
> find_vma() will continue to search upwards until the end of the virtual
> memory space. This means the si_code would almost never be set to
> SEGV_MAPERR even when the address falls outside of any VMA. The result
> is that the
On Sun, Apr 11, 2021 at 03:03:16PM -0700, Andrew Morton wrote:
> On Sun, 11 Apr 2021 11:53:33 +0100 Catalin Marinas
> wrote:
> > On Tue, Mar 30, 2021 at 10:36:37PM -0700, Andrew Morton wrote:
> > > On Mon, 29 Mar 2021 16:54:26 +0200 Andrey Konovalov
> > > wrot
On Thu, Mar 18, 2021 at 06:56:07PM +, Catalin Marinas wrote:
> On Mon, Mar 15, 2021 at 01:20:10PM +, Vincenzo Frascino wrote:
> > This patchset implements the asynchronous mode support for ARMv8.5-A
> > Memory Tagging Extension (MTE), which is a debugging feature that allow
Hi Andrew,
On Tue, Mar 30, 2021 at 10:36:37PM -0700, Andrew Morton wrote:
> On Mon, 29 Mar 2021 16:54:26 +0200 Andrey Konovalov
> wrote:
> > Looks like my patch "kasan: fix KASAN_STACK dependency for HW_TAGS"
> > that was merged into 5.12-rc causes a build time warning:
> >
> >
On Fri, Apr 09, 2021 at 05:18:45PM +0100, Mark Rutland wrote:
> On Fri, Apr 09, 2021 at 03:32:47PM +0100, Mark Rutland wrote:
> > Hi Vincenzo,
> >
> > On Fri, Apr 09, 2021 at 02:24:19PM +0100, Vincenzo Frascino wrote:
> > > The check_mte_async_tcf macro sets the TIF flag non-atomically. This can
On Fri, Apr 09, 2021 at 02:24:19PM +0100, Vincenzo Frascino wrote:
> diff --git a/arch/arm64/kernel/mte.c b/arch/arm64/kernel/mte.c
> index b3c70a612c7a..84a942c25870 100644
> --- a/arch/arm64/kernel/mte.c
> +++ b/arch/arm64/kernel/mte.c
> @@ -166,14 +166,43 @@ static void set_gcr_el1_excl(u64
On Thu, Apr 08, 2021 at 08:16:17PM +0200, David Hildenbrand wrote:
> On 08.04.21 16:18, Catalin Marinas wrote:
> > On Wed, Apr 07, 2021 at 04:52:54PM +0100, Steven Price wrote:
> > > On 07/04/2021 16:14, Catalin Marinas wrote:
> > > > On Wed, Apr 07, 2021 at 11:20:
On Wed, 7 Apr 2021 14:38:17 +0100, Vincenzo Frascino wrote:
> mte_assign_mem_tag_range() was added in commit 85f49cae4dfc
> ("arm64: mte: add in-kernel MTE helpers") in 5.11 but moved out of
> mte.S by commit 2cb34276427a ("arm64: kasan: simplify and inline
> MTE functions") in 5.12 and renamed to
On Tue, 30 Mar 2021 13:54:49 +0800, Jisheng Zhang wrote:
> They are not needed after booting, so mark them as __init to move them
> to the .init section.
Applied to arm64 (for-next/misc), thanks!
[1/1] arm64: Add __init section marker to some functions
On Wed, Apr 07, 2021 at 04:52:54PM +0100, Steven Price wrote:
> On 07/04/2021 16:14, Catalin Marinas wrote:
> > On Wed, Apr 07, 2021 at 11:20:18AM +0100, Steven Price wrote:
> > > On 31/03/2021 19:43, Catalin Marinas wrote:
> > > > When a slot is added by the VMM, i
On Wed, Apr 07, 2021 at 11:20:18AM +0100, Steven Price wrote:
> On 31/03/2021 19:43, Catalin Marinas wrote:
> > When a slot is added by the VMM, if it asked for MTE in guest (I guess
> > that's an opt-in by the VMM, haven't checked the other patches), can we
> > rejec
gt; Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: linux-arm-ker...@lists.infradead.org
> Signed-off-by: Greg Kroah-Hartman
Assuming that it does the same thing (it seems to from a quick look):
Acked-by: Catalin Marinas
y is causing a compilation error.
>
> The drivers/gpu/drm/vmwgfx code uses mapping_dirty_helpers and
> has been ported to ARM64 but it depends on this code getting in
> first in order to compile/work.
>
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Peter Zijlstra
> C
On Tue, 30 Mar 2021 04:58:17 -0400, He Ying wrote:
> depending -> depending on
Applied to arm64 (for-next/misc), thanks!
[1/1] docs: arm64: Fix a grammar error
https://git.kernel.org/arm64/c/68f638a432df
--
Catalin
On Wed, Mar 31, 2021 at 11:41:20AM +0100, Steven Price wrote:
> On 31/03/2021 10:32, David Hildenbrand wrote:
> > On 31.03.21 11:21, Catalin Marinas wrote:
> > > On Wed, Mar 31, 2021 at 09:34:44AM +0200, David Hildenbrand wrote:
> > > > On 30.03.21 12:30, Catalin M
On Wed, Mar 31, 2021 at 09:34:44AM +0200, David Hildenbrand wrote:
> On 30.03.21 12:30, Catalin Marinas wrote:
> > On Mon, Mar 29, 2021 at 05:06:51PM +0100, Steven Price wrote:
> > > On 28/03/2021 13:21, Catalin Marinas wrote:
> > > > On Sat, Mar 27, 2021 at 03:23:24P
On Mon, Mar 29, 2021 at 05:06:51PM +0100, Steven Price wrote:
> On 28/03/2021 13:21, Catalin Marinas wrote:
> > On Sat, Mar 27, 2021 at 03:23:24PM +, Catalin Marinas wrote:
> > > On Fri, Mar 12, 2021 at 03:18:58PM +, Steven Price wrote:
> > > > diff --git
On Mon, Mar 29, 2021 at 04:55:29PM +0100, Steven Price wrote:
> On 26/03/2021 18:56, Catalin Marinas wrote:
> > On Fri, Mar 12, 2021 at 03:18:57PM +, Steven Price wrote:
> > > A KVM guest could store tags in a page even if the VMM hasn't mapped
> > > the page with
On Wed, 24 Mar 2021 12:05:17 +0800, Lecopzer Chen wrote:
> Linux supports KAsan for VMALLOC since commit 3c5c3cfb9ef4da9
> ("kasan: support backing vmalloc space with real shadow memory")
>
> Acroding to how x86 ported it [1], they early allocated p4d and pgd,
> but in arm64 I just simulate how
On Mon, 29 Mar 2021 11:43:43 +0800, Chen Lifu wrote:
> In commit eb631bb5bf5b
> ("arm64: Support arch_irq_work_raise() via self IPIs") a new
> function "arch_irq_work_raise" was added without a prototype.
>
> In commit d914d4d49745
> ("arm64: Implement panic_smp_self_stop()") a new
> function
On Mon, Mar 29, 2021 at 09:29:40AM +1100, Stephen Rothwell wrote:
> diff --cc arch/arm64/include/asm/cpucaps.h
> index c40f2490cd7b,9e3ec4dd56d8..
> --- a/arch/arm64/include/asm/cpucaps.h
> +++ b/arch/arm64/include/asm/cpucaps.h
> @@@ -66,8 -66,8 +66,9 @@@
> #define
On Sat, Mar 27, 2021 at 03:06:51PM +0800, Chen Lifu wrote:
> In commit eb631bb5bf5b
> ("arm64: Support arch_irq_work_raise() via self IPIs") a new
> function "arch_irq_work_raise" was added without a prototype
> in header irq_work.h
>
> In commit d914d4d49745
> ("arm64: Implement
On Sat, Mar 27, 2021 at 03:23:24PM +, Catalin Marinas wrote:
> On Fri, Mar 12, 2021 at 03:18:58PM +, Steven Price wrote:
> > diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> > index 77cb2d28f2a4..b31b7a821f90 100644
> > --- a/arch/arm64/kvm/mmu.c
> >
On Sun, Mar 28, 2021 at 03:59:29PM +0900, Masahiro Yamada wrote:
> On Fri, Mar 26, 2021 at 11:36 PM Catalin Marinas
> wrote:
> > On Wed, Mar 24, 2021 at 04:11:28PM +0900, Masahiro Yamada wrote:
> > > $(call ld-option, --fix-cortex-a53-843419) in arch/arm64/Makefile is
>
On Fri, Mar 12, 2021 at 03:18:58PM +, Steven Price wrote:
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index 77cb2d28f2a4..b31b7a821f90 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -879,6 +879,22 @@ static int user_mem_abort(struct kvm_vcpu *vcpu,
>
On Fri, Mar 26, 2021 at 05:35:19PM -0700, Andrei Vagin wrote:
> On Fri, Mar 26, 2021 at 11:28 AM Catalin Marinas
> wrote:
> >
> > On Mon, Mar 22, 2021 at 03:50:50PM -0700, Andrei Vagin wrote:
> > > diff --git a/arch/arm64/include/uapi/asm/ptrace.h
> > > b/
Hi Steven,
On Fri, Mar 12, 2021 at 03:18:57PM +, Steven Price wrote:
> A KVM guest could store tags in a page even if the VMM hasn't mapped
> the page with PROT_MTE. So when restoring pages from swap we will
> need to check to see if there are any saved tags even if !pte_tagged().
>
>
On Mon, Mar 22, 2021 at 03:50:51PM -0700, Andrei Vagin wrote:
> diff --git a/arch/arm64/include/asm/ptrace.h b/arch/arm64/include/asm/ptrace.h
> index d4cdf98ac003..1008f0fbc5ea 100644
> --- a/arch/arm64/include/asm/ptrace.h
> +++ b/arch/arm64/include/asm/ptrace.h
> @@ -184,6 +184,7 @@ struct
On Mon, Mar 22, 2021 at 03:50:50PM -0700, Andrei Vagin wrote:
> diff --git a/arch/arm64/include/uapi/asm/ptrace.h
> b/arch/arm64/include/uapi/asm/ptrace.h
> index 758ae984ff97..3c118c5b0893 100644
> --- a/arch/arm64/include/uapi/asm/ptrace.h
> +++ b/arch/arm64/include/uapi/asm/ptrace.h
> @@ -90,6
Hi Masahiro,
On Wed, Mar 24, 2021 at 04:11:28PM +0900, Masahiro Yamada wrote:
> $(call ld-option, --fix-cortex-a53-843419) in arch/arm64/Makefile is
> evaluated every time even for Make targets that do not need the linker,
> such as "make ARCH=arm64 install".
>
> Recently, the Kbuild tree queued
On Mon, 15 Mar 2021 11:56:23 +, Mark Rutland wrote:
> Hector's M1 support series [1] shows that some platforms have critical
> interrupts wired to FIQ, and to support these platforms we need to support
> handling FIQ exceptions. Other contemporary platforms don't use FIQ (since
> e.g.
> this
24 Mar 2021 15:51:14 +,
> > > > Suzuki K Poulose wrote:
> > > > >
> > > > > On 24/03/2021 13:49, Marc Zyngier wrote:
> > > > > > On Wed, 24 Mar 2021 09:39:13 +0000,
> > > > > > Suzuki K Poulose wrote:
> > > &
On Wed, Mar 24, 2021 at 08:14:45AM +1100, Stephen Rothwell wrote:
> Commits
>
> b17f265bb4cc ("kselftest/arm64: mte: Fix MTE feature detection")
> 4dfc9d30a8ab ("kselftest/arm64: mte: common: Fix write() warnings")
>
> are missing a Signed-off-by from their author.
Thanks Stephen. Now
Hi Suzuki?
On Tue, Mar 23, 2021 at 12:06:33PM +, Suzuki K Poulose wrote:
> tsb csync synchronizes the trace operation of instructions.
> The instruction is a nop when FEAT_TRF is not implemented.
>
> Cc: Mathieu Poirier
> Cc: Mike Leach
> Cc: Catalin Marinas
> Cc:
On Tue, Mar 23, 2021 at 01:32:18PM +, Will Deacon wrote:
> On Tue, Mar 23, 2021 at 12:08:56PM +, Robin Murphy wrote:
> > On 2021-03-23 07:34, Yang Yingliang wrote:
> > > When copy over 128 bytes, src/dst is added after
> > > each ldp/stp instruction, it will cost more time.
> > > To
On Mon, Mar 22, 2021 at 05:40:23PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the akpm tree got a conflict in:
>
> arch/arm64/mm/mmu.c
>
> between commit:
>
> 87143f404f33 ("arm64: mm: use XN table mapping attributes for the linear
> region")
>
> from the
ith a bunch of
> toolchains, verifying the output of /proc/self/stack and checking that
> the assembly looked sound. For GCC (where we require version 5.1.0 or
> later) I tested with the kernel.org crosstool binares for versions
> 5.5.0, 6.4.0, 6.5.0, 7.3.0, 7.5.0, 8.1.0, 8.3.0, 8.4.0, 9.
RCH_ENABLE_SPLIT_PMD_PTLOCK
> mm: Drop redundant HAVE_ARCH_TRANSPARENT_HUGEPAGE
>
> arch/arc/Kconfig | 9 ++--
> arch/arm/Kconfig | 10 ++---
> arch/arm64/Kconfig | 30 ++
For arm64:
Acked-by: Catalin Marinas
t; And the dependency cannot be guaranteed by Kconfig.
>
> move the definition of CONFIG_DEBUG_KMEMLEAK_TEST from lib/Kconfig.debug
> to samples/Kconfig.
>
> Signed-off-by: Chen Jun
> Acked-by: Catalin Marinas
Cc'ing Andrew, I don't think he's seen the patch.
> lib/Kco
On Fri, Mar 19, 2021 at 08:49:07PM +0530, Naresh Kamboju wrote:
> [This email landed to Spam for some reason, sending it again with modified
> subject]
>
> While building arm64 kernel modules the following kernel warnings /
> errors noticed on linux next 20210318 tag the gcc version is 7.3.0.
>
Hi Lecopzer,
On Sat, Feb 06, 2021 at 04:35:47PM +0800, Lecopzer Chen wrote:
> Linux supports KAsan for VMALLOC since commit 3c5c3cfb9ef4da9
> ("kasan: support backing vmalloc space with real shadow memory")
>
> Acroding to how x86 ported it [1], they early allocated p4d and pgd,
> but in arm64 I
On Sat, Feb 06, 2021 at 04:35:48PM +0800, Lecopzer Chen wrote:
> Linux support KAsan for VMALLOC since commit 3c5c3cfb9ef4da9
> ("kasan: support backing vmalloc space with real shadow memory")
>
> Like how the MODULES_VADDR does now, just not to early populate
> the VMALLOC_START between
IG_MEMTEST.
> Conversely CONFIG_MEMTEST cannot be enabled on platforms where it would
> not be tested anyway.
>
> Cc: Russell King
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Thomas Bogendoerfer
> Cc: Michael Ellerman
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
On Thu, Mar 18, 2021 at 09:41:54AM +0100, Arnd Bergmann wrote:
> On Wed, Mar 17, 2021 at 5:18 PM Catalin Marinas
> wrote:
> >
> > On Wed, Mar 17, 2021 at 02:37:57PM +0000, Catalin Marinas wrote:
> > > On Thu, Feb 25, 2021 at 12:20:56PM +0100, Arnd Bergmann wrote:
>
On Mon, Mar 15, 2021 at 01:20:10PM +, Vincenzo Frascino wrote:
> This patchset implements the asynchronous mode support for ARMv8.5-A
> Memory Tagging Extension (MTE), which is a debugging feature that allows
> to detect with the help of the architecture the C and C++ programmatic
> memory
On Thu, Mar 18, 2021 at 05:12:07PM +, Mark Rutland wrote:
> On Thu, Mar 18, 2021 at 04:17:24PM +0000, Catalin Marinas wrote:
> > On Wed, Mar 17, 2021 at 07:34:16PM +, Mark Rutland wrote:
> > > On Wed, Mar 17, 2021 at 06:36:36PM +0000, Catalin Marinas wrote:
> >
On Wed, Mar 17, 2021 at 07:34:16PM +, Mark Rutland wrote:
> On Wed, Mar 17, 2021 at 06:36:36PM +0000, Catalin Marinas wrote:
> > On Wed, Mar 17, 2021 at 02:20:50PM +, Chen Jun wrote:
> > > On ARM64, cat /sys/kernel/debug/page_owner, all pages return th
On Wed, Mar 17, 2021 at 02:20:50PM +, Chen Jun wrote:
> On ARM64, cat /sys/kernel/debug/page_owner, all pages return the same
> stack:
> stack_trace_save+0x4c/0x78
> register_early_stack+0x34/0x70
> init_page_owner+0x34/0x230
> page_ext_init+0x1bc/0x1dc
>
> The reason is that:
>
On Wed, Mar 17, 2021 at 02:37:57PM +, Catalin Marinas wrote:
> On Thu, Feb 25, 2021 at 12:20:56PM +0100, Arnd Bergmann wrote:
> > diff --git a/arch/arm64/kernel/vmlinux.lds.S
> > b/arch/arm64/kernel/vmlinux.lds.S
> > index bad2b9eaab22..926cdb597a45 100644
> &
On Thu, Feb 25, 2021 at 12:20:56PM +0100, Arnd Bergmann wrote:
> diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
> index bad2b9eaab22..926cdb597a45 100644
> --- a/arch/arm64/kernel/vmlinux.lds.S
> +++ b/arch/arm64/kernel/vmlinux.lds.S
> @@ -217,7 +217,7 @@ SECTIONS
>
e_ksize() in
> slab_post_alloc_hook() (and avoid new IS_ENABLED(CONFIG_DEBUG_KMEMLEAK)
> guard), just call kfence_ksize() in mm/kmemleak.c:create_object().
>
> Reported-by: Luis Henriques
> Cc: Catalin Marinas
> Signed-off-by: Marco Elver
Reviewed-by: Catalin Marinas
On Tue, Mar 16, 2021 at 07:47:00PM +0100, Marco Elver wrote:
> One thing I've just run into: "BUG: KFENCE: out-of-bounds read in
> scan_block+0x6b/0x170 mm/kmemleak.c:1244"
>
> Probably because kmemleak is passed the rounded size for the size-class,
> and not the real allocation size. Can this be
On Tue, Mar 16, 2021 at 05:39:27PM +0100, Arnd Bergmann wrote:
> On Tue, Mar 16, 2021 at 5:27 PM Catalin Marinas
> wrote:
> > On Tue, Mar 16, 2021 at 10:45:32AM +0000, Catalin Marinas wrote:
> > > On Fri, Feb 26, 2021 at 08:32:57PM -0800, Fangrui Song wrote:
> > &
On Tue, Mar 16, 2021 at 06:30:00PM +0100, Marco Elver wrote:
> On Tue, Mar 16, 2021 at 04:42PM +, Luis Henriques wrote:
> > This is probably a known issue, but just in case: looks like it's not
> > possible to use kmemleak when kfence is enabled:
> >
> > [0.272136] kmemleak: Cannot insert
On Tue, Mar 16, 2021 at 10:45:32AM +, Catalin Marinas wrote:
> On Fri, Feb 26, 2021 at 08:32:57PM -0800, Fangrui Song wrote:
> > On 2021-02-26, Kees Cook wrote:
> > > On Fri, Feb 26, 2021 at 03:03:39PM +0100, Arnd Bergmann wrote:
> > > > From: Arnd Bergmann
On Fri, Feb 26, 2021 at 08:32:57PM -0800, Fangrui Song wrote:
> On 2021-02-26, Kees Cook wrote:
> > On Fri, Feb 26, 2021 at 03:03:39PM +0100, Arnd Bergmann wrote:
> > > From: Arnd Bergmann
> > >
> > > When building with CONFIG_LD_DEAD_CODE_DATA_ELIMINATION,
> > > I sometimes see an assertion
> >
On Thu, 25 Feb 2021 05:56:58 -0800, Yury Norov wrote:
> MIPS and ARM64 don't implement find_first_{zero}_bit in arch code and
> don't enable it in config. It leads to using find_next_bit() which is
> less efficient:
>
> It's beneficial to enable GENERIC_FIND_FIRST_BIT as this functionality
> is
On Mon, Mar 15, 2021 at 01:20:16PM +, Vincenzo Frascino wrote:
> mte_enable_kernel_*() are not needed if KASAN_HW is disabled.
>
> Add ash defines around the functions to conditionally compile the
> functions.
>
> Signed-off-by: Vincenzo Frascino
Acked-by: Catalin Mari
On Mon, Mar 15, 2021 at 08:08:06AM +0100, Dmitry Vyukov wrote:
> On Wed, Feb 3, 2021 at 6:59 AM syzbot
> wrote:
> > syzbot found the following issue on:
> >
> > HEAD commit:3aaf0a27 Merge tag 'clang-format-for-linux-v5.11-rc7' of g..
> > git tree: upstream
> > console output:
On Fri, Mar 12, 2021 at 04:55:46AM -0500, Valdis Klētnieks wrote:
> Building arch/arm64/kernel/sys.o with W=1 throws over 300 warnings:
>
> /usr/src/linux-next/arch/arm64/kernel/sys.c:56:40: warning: initialized field
> overwritten [-Woverride-init]
>56 | #define __SYSCALL(nr, sym) [nr]
On Fri, Mar 12, 2021 at 03:23:44PM +, Vincenzo Frascino wrote:
> On 3/12/21 3:13 PM, Catalin Marinas wrote:
> > On Fri, Mar 12, 2021 at 02:22:07PM +, Vincenzo Frascino wrote:
> >> diff --git a/arch/arm64/include/asm/mte.h b/arch/arm64/include/asm/mte.h
> >> index
el free to add my ack on the
rest of the patches:
Acked-by: Catalin Marinas
> static bool report_fault_once = true;
>
> +/* Whether the MTE asynchronous mode is enabled. */
> +DEFINE_STATIC_KEY_FALSE(mte_async_mode);
> +EXPORT_SYMBOL_GPL(mte_async_mode);
Maybe keep these bracketed by #ifdef CONFIG_KASAN_HW_TAGS. I think the
mte_enable_kernel_*() aren't needed either if
On Thu, Mar 11, 2021 at 03:00:26PM +, Vincenzo Frascino wrote:
> On 3/11/21 1:25 PM, Catalin Marinas wrote:
> > On Mon, Mar 08, 2021 at 04:14:34PM +, Vincenzo Frascino wrote:
> >> load_unaligned_zeropad() and __get/put_kernel_nofault() functions can
> >> rea
On Mon, Mar 08, 2021 at 04:14:34PM +, Vincenzo Frascino wrote:
> load_unaligned_zeropad() and __get/put_kernel_nofault() functions can
> read passed some buffer limits which may include some MTE granule with a
> different tag.
>
> When MTE async mode is enable, the load operation crosses the
On Mon, Mar 08, 2021 at 04:14:29PM +, Vincenzo Frascino wrote:
> arch_enable_tagging() was left in memory.h after the introduction of
> async mode to not break the bysectability of the KASAN KUNIT tests.
>
> Remove the function now that KASAN has been fully converted.
>
> C
> \
> + __typeof__(x) __page = x; \
> + void *__addr = __va(page_to_phys(__page)); \
> + (void *)__tag_set((const void *)__addr, page_kasan_tag(__page));\
> +})
> #define virt_to_page(x) pfn_to_page(virt_to_pfn(x))
Reviewed-by: Catalin Marinas
onversion
> with PFN_PHYS() and PHYS_PFN() helpers. While there, also add a comment.
> This does not cause any functional change.
>
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Ard Biesheuvel
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
ons
>
> Skipping memblock_is_map_memory() for all non early memory sections would
> fix pfn_valid() problem for ZONE_DEVICE based memory and also improve its
> performance for normal hotplug memory as well.
>
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Ard Biesheuve
On Mon, Mar 08, 2021 at 04:55:14PM +0100, Andrey Konovalov wrote:
> @@ -68,10 +69,16 @@ static inline void mte_set_mem_tag_range(void *addr,
> size_t size, u8 tag)
>* 'asm volatile' is required to prevent the compiler to move
>* the statement outside of the loop.
>
On Fri, Mar 05, 2021 at 07:24:21PM +0100, David Hildenbrand wrote:
> On 05.03.21 19:13, Catalin Marinas wrote:
> > On Fri, Mar 05, 2021 at 10:54:57AM +0530, Anshuman Khandual wrote:
> > > pfn_valid() validates a pfn but basically it checks for a valid struct
> > > page
On Fri, Mar 05, 2021 at 01:16:28PM -0500, Veronika Kabatova wrote:
> > > On 3/5/21 10:54 AM, Anshuman Khandual wrote:
> > > > This series fixes pfn_valid() for ZONE_DEVICE based memory and
> > > > also improves its performance for normal hotplug memory. While
> > > > here, it also reorganizes
ons
>
> Skipping memblock_is_map_memory() for all non early memory sections would
> fix pfn_valid() problem for ZONE_DEVICE based memory and also improve its
> performance for normal hotplug memory as well.
>
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Ard Biesheuve
On Wed, Mar 03, 2021 at 02:17:41PM -0800, Yury Norov wrote:
> On Thu, Feb 25, 2021 at 02:02:06PM +, Will Deacon wrote:
> > On Thu, Feb 25, 2021 at 05:56:59AM -0800, Yury Norov wrote:
> > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > > index 31bd885b79eb..5596eab04092 100644
> > >
On Thu, Feb 11, 2021 at 01:35:56PM +0100, David Hildenbrand wrote:
> On 11.02.21 13:10, Anshuman Khandual wrote:
> > On 2/11/21 5:23 PM, Will Deacon wrote:
> > > ... and dropped. These patches appear to be responsible for a boot
> > > regression reported by CKI:
> >
> > Ahh, boot regression ?
;) back in 3.11. It looks like hugetlbfs (and the HUGETLB_PAGE_ORDER
definition) was added in the same kernel but we somehow missed the
!TRANSPARENT_HUGEPAGE case and smaller page order. The warning in
__fragmentation_index() was added much later in 4.14.
Anyway, the patch looks fine to me, w
1 - 100 of 5901 matches
Mail list logo
