On Fri, Nov 13, 2020 at 12:28:46PM +, Ionela Voinescu wrote:
> On Thursday 12 Nov 2020 at 18:00:46 (+), Catalin Marinas wrote:
> > On Fri, Nov 06, 2020 at 12:53:34PM +, Ionela Voinescu wrote:
> > > +static inline
> > > +int counters_read_on_cpu(int cpu, smp
er to set_direct_map_*_noflush() to expose this ability
> with these APIs.
>
> Signed-off-by: Mike Rapoport
> ---
> arch/arm64/include/asm/cacheflush.h | 4 ++--
> arch/arm64/mm/pageattr.c| 10 ++++++
For arm64:
Acked-by: Catalin Marinas
Hi Mike,
On Tue, Nov 10, 2020 at 05:14:43PM +0200, Mike Rapoport wrote:
> diff --git a/arch/arm64/include/asm/unistd32.h
> b/arch/arm64/include/asm/unistd32.h
> index 6c1dcca067e0..c71c3fe0b6cd 100644
> --- a/arch/arm64/include/asm/unistd32.h
> +++ b/arch/arm64/include/asm/unistd32.h
> @@ -891,6
On Fri, Nov 13, 2020 at 11:17:15AM +, Vincenzo Frascino wrote:
> On 11/12/20 9:43 AM, Catalin Marinas wrote:
> > On Tue, Nov 10, 2020 at 11:10:27PM +0100, Andrey Konovalov wrote:
> >> From: Vincenzo Frascino
> >>
> >> Hardware tag-based KASAN rel
Hi Nicolas,
On Thu, Nov 12, 2020 at 04:56:38PM +0100, Nicolas Saenz Julienne wrote:
> On Tue, 2020-11-10 at 18:17 +0000, Catalin Marinas wrote:
> > On Fri, Nov 06, 2020 at 07:46:29PM +0100, Nicolas Saenz Julienne wrote:
> > > On Thu, 2020-11-05 at 16:11 +, James Morse wrote
On Fri, Nov 06, 2020 at 12:53:34PM +, Ionela Voinescu wrote:
> +static inline
> +int counters_read_on_cpu(int cpu, smp_call_func_t func, u64 *val)
> +{
> + if (!cpu_has_amu_feat(cpu))
> + return -EOPNOTSUPP;
> +
> + smp_call_function_single(cpu, func, val, 1);
> +
> +
On Fri, Nov 06, 2020 at 09:07:38AM +, Will Deacon wrote:
> On Fri, Nov 06, 2020 at 09:06:42AM +0800, tangyouling wrote:
> > In the include/asm-generic/vmlinux.lds.h:978, the description is as follows:
> > DISCARDS must be the last of output section definitions so that such archs
> > put those
On Thu, Nov 12, 2020 at 12:53:58PM +0100, Marco Elver wrote:
> On Thu, 12 Nov 2020 at 12:35, Catalin Marinas wrote:
> >
> > On Tue, Nov 10, 2020 at 11:20:15PM +0100, Andrey Konovalov wrote:
> > > Hardware tag-based KASAN mode is intended to eventually be used in
> &
s are enabled
> - kasan.mode=full - all KASAN features are enabled
Alternative naming if we want to avoid "production" (in case someone
considers MTE to be expensive in a production system):
- kasan.mode=off
- kasan.mode=on
- kasan.mode=debug
Anyway, whatever you prefer is fine by me:
Acked-by: Catalin Marinas
on !KASAN || KASAN_HW_TAGS || KASAN_VMALLOC
>From the arm64 perspective:
Acked-by: Catalin Marinas
n't understand why CONFIG_KASAN_STACK is not a bool (do you plan to
add more values to it?) but for arm64:
Acked-by: Catalin Marinas
over context switching.
>
> Signed-off-by: Vincenzo Frascino
> Signed-off-by: Andrey Konovalov
Acked-by: Catalin Marinas
On Thu, Nov 12, 2020 at 09:45:45AM +, Vincenzo Frascino wrote:
> On 11/12/20 9:39 AM, Catalin Marinas wrote:
> > On Tue, Nov 10, 2020 at 11:10:29PM +0100, Andrey Konovalov wrote:
> >> diff --git a/arch/arm64/kernel/mte.c b/arch/arm64/kernel/mte.c
> >> index 664c96
On Tue, Nov 10, 2020 at 11:10:27PM +0100, Andrey Konovalov wrote:
> From: Vincenzo Frascino
>
> Hardware tag-based KASAN relies on Memory Tagging Extension (MTE)
> feature and requires it to be enabled. MTE supports
>
> This patch adds a new mte_init_tags() helper, that enables MTE in
>
On Tue, Nov 10, 2020 at 11:10:29PM +0100, Andrey Konovalov wrote:
> diff --git a/arch/arm64/kernel/mte.c b/arch/arm64/kernel/mte.c
> index 664c968dc43c..dbda6598c19d 100644
> --- a/arch/arm64/kernel/mte.c
> +++ b/arch/arm64/kernel/mte.c
> @@ -129,6 +131,26 @@ void *mte_set_mem_tag_range(void
On Tue, Nov 10, 2020 at 11:10:25PM +0100, Andrey Konovalov wrote:
> diff --git a/arch/arm64/mm/copypage.c b/arch/arm64/mm/copypage.c
> index 70a71f38b6a9..f0efa4847e2f 100644
> --- a/arch/arm64/mm/copypage.c
> +++ b/arch/arm64/mm/copypage.c
> @@ -23,6 +23,7 @@ void copy_highpage(struct page *to,
Hi Anshuman,
On Wed, Nov 11, 2020 at 09:18:56AM +0530, Anshuman Khandual wrote:
> On 11/11/20 12:44 AM, Catalin Marinas wrote:
> > On Wed, 14 Oct 2020 10:18:57 +0200, Ard Biesheuvel wrote:
> >> As a hardening measure, we currently randomize the placement of
> >> physic
On Tue, 3 Nov 2020 10:22:29 +, Mark Rutland wrote:
> Depending on configuration options and specific code paths, we either
> use the empty_zero_page or the configuration-dependent reserved_ttbr0
> as a reserved value for TTBR{0,1}_EL1.
>
> To simplify this code, let's always allocate and use
On Mon, 9 Nov 2020 17:08:36 +0530, Anshuman Khandual wrote:
> Mapping between IPI type index and its string is direct without requiring
> an additional offset. Hence the existing macro S(x, s) is now redundant
> and can just be dropped. This also makes the code clean and simple.
Applied to arm64
On Wed, 14 Oct 2020 10:18:57 +0200, Ard Biesheuvel wrote:
> As a hardening measure, we currently randomize the placement of
> physical memory inside the linear region when KASLR is in effect.
> Since the random offset at which to place the available physical
> memory inside the linear region is
On Mon, 9 Nov 2020 09:58:54 +0530, Anshuman Khandual wrote:
> This series brings three different changes to the only memory event notifier
> on
> arm64 platform. These changes improve it's robustness while also enhancing
> debug
> capabilities during potential memory offlining error conditions.
On Fri, Nov 06, 2020 at 07:46:29PM +0100, Nicolas Saenz Julienne wrote:
> On Thu, 2020-11-05 at 16:11 +, James Morse wrote:
> > On 03/11/2020 17:31, Nicolas Saenz Julienne wrote:
> > > crashkernel might reserve memory located in ZONE_DMA. We plan to delay
> > > ZONE_DMA's initialization after
On Tue, Oct 27, 2020 at 05:19:59PM -0700, Kees Cook wrote:
> To enable seccomp constant action bitmaps, we need to have a static
> mapping to the audit architecture and system call table size. Add these
> for arm64.
>
> Signed-off-by: Kees Cook
> ---
> arch/arm64/include/asm/seccomp.h | 15
if there is a change in FI support status after
> counter init, use the existing rebuild_sched_domains_energy() function to
> trigger a rebuild of the scheduling and performance domains that in turn
> will determine the enablement of EAS.
>
> Signed-off-by: Ionela Voinescu
> Cc: Catalin Marinas
> Cc: Will Deacon
Acked-by: Catalin Marinas
On Fri, Nov 06, 2020 at 09:33:14AM -0800, Atish Patra wrote:
> On Fri, Nov 6, 2020 at 9:14 AM Catalin Marinas
> wrote:
> > On Mon, Oct 05, 2020 at 05:17:49PM -0700, Atish Patra wrote:
> > > diff --git a/arch/arm64/kernel/acpi_numa.c b/arch/arm64/kernel/acpi_numa.c
>
On Thu, Nov 05, 2020 at 10:07:00AM -0800, Palmer Dabbelt wrote:
> On Mon, 05 Oct 2020 17:17:47 PDT (-0700), Atish Patra wrote:
> > arch/arm64/Kconfig| 1 +
> > arch/arm64/include/asm/numa.h | 45 +
> > arch/arm64/kernel/acpi_numa.c
On Mon, Oct 05, 2020 at 05:17:49PM -0700, Atish Patra wrote:
> diff --git a/arch/arm64/kernel/acpi_numa.c b/arch/arm64/kernel/acpi_numa.c
> index 7ff800045434..96502ff92af5 100644
> --- a/arch/arm64/kernel/acpi_numa.c
> +++ b/arch/arm64/kernel/acpi_numa.c
> @@ -117,16 +117,3 @@ void __init
On Wed, Nov 04, 2020 at 04:03:36PM -0800, Sudarshan Rajagopalan wrote:
> Did you have a chance to review this patch? It is reviewed by others and
> haven't seen any Nacks. This patch will be useful to have so that memory
> hotremove doesn't fail when such PMD_SIZE pages aren't available.. which is
ernel entry and exit.
>
> Signed-off-by: Vincenzo Frascino
> Co-developed-by: Andrey Konovalov
> Signed-off-by: Andrey Konovalov
Reviewed-by: Catalin Marinas
On Thu, Nov 05, 2020 at 06:29:17PM +0100, Andrey Konovalov wrote:
> On Thu, Nov 5, 2020 at 6:26 PM Catalin Marinas
> wrote:
> >
> > On Thu, Nov 05, 2020 at 12:18:45AM +0100, Andrey Konovalov wrote:
> > > diff --git a/arch/arm64/kernel/mte.c b/arch/arm64/kernel/mte
> Signed-off-by: Andrey Konovalov
> Signed-off-by: Vincenzo Frascino
Reviewed-by: Catalin Marinas
On Thu, Nov 05, 2020 at 12:18:47AM +0100, Andrey Konovalov wrote:
> diff --git a/arch/arm64/kernel/mte.c b/arch/arm64/kernel/mte.c
> index 14b0c19a33e3..cc7e0f8707f7 100644
> --- a/arch/arm64/kernel/mte.c
> +++ b/arch/arm64/kernel/mte.c
> @@ -23,6 +23,8 @@
> #include
> #include
>
> +u64
On Thu, Nov 05, 2020 at 12:18:45AM +0100, Andrey Konovalov wrote:
> diff --git a/arch/arm64/kernel/mte.c b/arch/arm64/kernel/mte.c
> index 06ba6c923ab7..fcfbefcc3174 100644
> --- a/arch/arm64/kernel/mte.c
> +++ b/arch/arm64/kernel/mte.c
> @@ -121,6 +121,13 @@ void *mte_set_mem_tag_range(void
rey Konovalov
> Signed-off-by: Andrey Konovalov
Reviewed-by: Catalin Marinas
> Signed-off-by: Andrey Konovalov
Reviewed-by: Catalin Marinas
Also fix pr_fmt() usage for KASAN code: generic.c doesn't need it as it
> doesn't use any printing functions; tag-based mode should use "kasan:"
> instead of KBUILD_MODNAME (which stands for file name).
>
> Signed-off-by: Andrey Konovalov
Reviewed-by: Catalin Marinas
On Thu, Nov 05, 2020 at 12:18:43AM +0100, Andrey Konovalov wrote:
> diff --git a/arch/arm64/kernel/mte.c b/arch/arm64/kernel/mte.c
> index 8f99c65837fd..06ba6c923ab7 100644
> --- a/arch/arm64/kernel/mte.c
> +++ b/arch/arm64/kernel/mte.c
> @@ -34,6 +34,7 @@ static void mte_sync_page_tags(struct
On Wed, Nov 04, 2020 at 08:57:05AM +, Szabolcs Nagy wrote:
> The 11/03/2020 23:41, Jeremy Linton wrote:
> > On 11/3/20 11:34 AM, Mark Brown wrote:
> > > On Tue, Nov 03, 2020 at 10:25:37AM +, Szabolcs Nagy wrote:
> > >
> > > > Re-mmap executable segments instead of mprotecting them in
> >
On Wed, Nov 04, 2020 at 11:55:57AM +0200, Topi Miettinen wrote:
> On 4.11.2020 11.29, Florian Weimer wrote:
> > * Will Deacon:
> >
> > > Is there real value in this seccomp filter if it only looks at mprotect(),
> > > or was it just implemented because it's easy to do and sounds like a good
> > >
On Tue, Nov 03, 2020 at 06:00:33PM +0100, Nicolas Saenz Julienne wrote:
> On Fri, 2020-10-30 at 18:11 +0000, Catalin Marinas wrote:
> > On Thu, Oct 29, 2020 at 06:25:43PM +0100, Nicolas Saenz Julienne wrote:
> > > Ard Biesheuvel (1):
> > > arm64: mm: Set ZONE_DMA si
.
--8<-
>From 3ae252d888be4984a612236124f5b099e804c745 Mon Sep 17 00:00:00 2001
From: Catalin Marinas
Date: Fri, 30 Oct 2020 18:07:34 +
Subject: [PATCH] arm64: Ignore any DMA offsets in the max_zone_phys()
calculation
Currently, the ker
On Thu, Oct 29, 2020 at 06:25:49PM +0100, Nicolas Saenz Julienne wrote:
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index 9929ff50c0c0..05fe4a076bab 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -1718,3 +1718,55 @@ void __init
-982,7 +982,7 @@ config NUMA
> config NODES_SHIFT
> int "Maximum NUMA Nodes (as a power of 2)"
> range 1 10
> - default "2"
> + default "4"
> depends on NEED_MULTIPLE_NODES
> help
> Specify the maximum number of NUMA Nodes available on the target
Acked-by: Catalin Marinas
On Thu, Oct 29, 2020 at 12:48:50PM -0700, Vanshidhar Konda wrote:
> On Thu, Oct 29, 2020 at 01:37:10PM +0000, Catalin Marinas wrote:
> > On Wed, Oct 21, 2020 at 11:29:41PM +0100, Valentin Schneider wrote:
> > > On 21/10/20 12:02, Jonathan Cameron wrote:
> > > > On W
On Wed, Oct 21, 2020 at 11:29:41PM +0100, Valentin Schneider wrote:
> On 21/10/20 12:02, Jonathan Cameron wrote:
> > On Wed, 21 Oct 2020 09:43:21 +0530
> > Anshuman Khandual wrote:
> >> Agreed. Do we really need to match X86 right now ? Do we really have
> >> systems that has 64 nodes ? We should
On Tue, Oct 27, 2020 at 02:15:22PM +, Dave P Martin wrote:
> I also wonder whether we actually care whether the pages are marked
> executable or not here; probably the flags can just be independent. This
> rather depends on whether the how the architecture treats the BTI (a.k.a
> GP)
On Sat, Oct 24, 2020 at 02:01:30PM +0300, Topi Miettinen wrote:
> On 23.10.2020 12.02, Catalin Marinas wrote:
> > On Thu, Oct 22, 2020 at 01:02:18PM -0700, Kees Cook wrote:
> > > Regardless, it makes sense to me to have the kernel load the executable
> > > itself wit
On Fri, Oct 23, 2020 at 05:27:49PM +0200, Nicolas Saenz Julienne wrote:
> On Thu, 2020-10-22 at 19:06 +0100, Catalin Marinas wrote:
> > On Wed, Oct 21, 2020 at 02:34:35PM +0200, Nicolas Saenz Julienne wrote:
> > > @@ -188,9 +186,11 @@ static phys_addr_t __init max_zone
On Fri, Oct 23, 2020 at 07:13:17AM +0100, Szabolcs Nagy wrote:
> The 10/22/2020 10:31, Catalin Marinas wrote:
> > IIUC, the problem is with the main executable which is mapped by the
> > kernel without PROT_BTI. The dynamic loader wants to set PROT_BTI but
> > does not h
On Thu, Oct 22, 2020 at 01:02:18PM -0700, Kees Cook wrote:
> Regardless, it makes sense to me to have the kernel load the executable
> itself with BTI enabled by default. I prefer gaining Catalin's suggested
> patch[2]. :)
[...]
> [2]
On Wed, Oct 21, 2020 at 02:34:35PM +0200, Nicolas Saenz Julienne wrote:
> @@ -188,9 +186,11 @@ static phys_addr_t __init max_zone_phys(unsigned int
> zone_bits)
> static void __init zone_sizes_init(unsigned long min, unsigned long max)
> {
> unsigned long max_zone_pfns[MAX_NR_ZONES] =
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
On Thu, Oct 22, 2020 at 10:38:23AM +0200, Lennart Poettering wrote:
> On Do, 22.10.20 09:29, Szabolcs Nagy (szabolcs.n...@arm.com) wrote:
> > > > The dynamic loader has to process the LOAD segments to get to the ELF
> > > > note that says to enable BTI. Maybe we could do a first pass and load
> >
On Thu, Oct 15, 2020 at 10:26:18PM +0800, Hanjun Guo wrote:
> On 2020/10/15 3:12, Nicolas Saenz Julienne wrote:
> > From: Ard Biesheuvel
> >
> > We recently introduced a 1 GB sized ZONE_DMA to cater for platforms
> > incorporating masters that can address less than 32 bits of DMA, in
> >
On Wed, Oct 14, 2020 at 03:21:16PM -0600, Khalid Aziz wrote:
> On 10/13/20 3:16 AM, Catalin Marinas wrote:
> > On Mon, Oct 12, 2020 at 01:14:50PM -0600, Khalid Aziz wrote:
> >> On 10/12/20 11:22 AM, Catalin Marinas wrote:
> >>> On Mon, Oct 12, 2020 at 11:03
On Mon, Oct 12, 2020 at 01:14:50PM -0600, Khalid Aziz wrote:
> On 10/12/20 11:22 AM, Catalin Marinas wrote:
> > On Mon, Oct 12, 2020 at 11:03:33AM -0600, Khalid Aziz wrote:
> >> On 10/10/20 5:09 AM, Catalin Marinas wrote:
> >>> On Wed, Oct 07, 2020 at 02:14
On Mon, Oct 12, 2020 at 11:03:33AM -0600, Khalid Aziz wrote:
> On 10/10/20 5:09 AM, Catalin Marinas wrote:
> > On Wed, Oct 07, 2020 at 02:14:09PM -0600, Khalid Aziz wrote:
> >> On 10/7/20 1:39 AM, Jann Horn wrote:
> >>> arch_validate_prot() is a hook that ca
On Sat, Oct 10, 2020 at 05:12:31PM +0200, Nicolas Saenz Julienne wrote:
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index f6902a2b4ea6..0eca5865dcb1 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -196,14 +196,16 @@ static void __init zone_sizes_init(unsigned
On Mon, Oct 12, 2020 at 08:47:15AM +0200, Christoph Hellwig wrote:
> On Fri, Oct 09, 2020 at 06:10:52PM +0100, Catalin Marinas wrote:
> > kdump wants DMA-able memory and,
>
> DMAable by whom? The only way to guranteed DMAable memory is to use
> the DMA memory allocator(s) a
Hi Khalid,
On Wed, Oct 07, 2020 at 02:14:09PM -0600, Khalid Aziz wrote:
> On 10/7/20 1:39 AM, Jann Horn wrote:
> > arch_validate_prot() is a hook that can validate whether a given set of
> > protection flags is valid in an mprotect() operation. It is given the set
> > of protection flags and the
On Sat, Oct 10, 2020 at 12:53:19PM +0200, Nicolas Saenz Julienne wrote:
> On Sat, 2020-10-10 at 12:36 +0200, Ard Biesheuvel wrote:
> > On Fri, 9 Oct 2020 at 19:10, Catalin Marinas
> > wrote:
> > > On Fri, Oct 09, 2020 at 06:23:06PM +0200, Ard Biesheuvel wrote:
> > &
On Fri, Oct 09, 2020 at 06:23:06PM +0200, Ard Biesheuvel wrote:
> On Fri, 9 Oct 2020 at 17:24, Lorenzo Pieralisi
> wrote:
> > We can move this check to IORT code and call it from arm64 if it
> > can be made to work.
>
> Finding the smallest value in the IORT, and assigning it to
> zone_dma_bits
On Fri, Oct 09, 2020 at 10:56:02AM +0100, Vincenzo Frascino wrote:
> On 10/9/20 9:11 AM, Catalin Marinas wrote:
> > On Thu, Oct 08, 2020 at 07:24:12PM +0100, Vincenzo Frascino wrote:
> >> On 10/2/20 3:06 PM, Catalin Marinas wrote:
> >>> On Fri, Oct 02, 2020 at 01:1
On Thu, Oct 08, 2020 at 07:24:12PM +0100, Vincenzo Frascino wrote:
> On 10/2/20 3:06 PM, Catalin Marinas wrote:
> > On Fri, Oct 02, 2020 at 01:10:30AM +0200, Andrey Konovalov wrote:
> >> diff --git a/arch/arm64/kernel/mte.c b/arch/arm64/kernel/mte.c
> >> index 7c67ac
On Thu, Oct 08, 2020 at 09:34:26PM +1100, Michael Ellerman wrote:
> Jann Horn writes:
> > So while the mprotect() case
> > checks the flags and refuses unknown values, the mmap() code just lets
> > the architecture figure out which bits are actually valid to set (via
> > arch_calc_vm_prot_bits())
On Thu, Oct 08, 2020 at 12:05:25PM +0200, Nicolas Saenz Julienne wrote:
> On Fri, 2020-10-02 at 12:55 +0100, Catalin Marinas wrote:
> > On Thu, Oct 01, 2020 at 07:31:19PM +0200, Nicolas Saenz Julienne wrote:
> > > On Thu, 2020-10-01 at 18:23 +0100, Catalin Marinas wrote:
>
On Wed, Oct 07, 2020 at 09:39:31AM +0200, Jann Horn wrote:
> arch_validate_prot() is a hook that can validate whether a given set of
> protection flags is valid in an mprotect() operation. It is given the set
> of protection flags and the address being modified.
>
> However, the address being
On Wed, Oct 07, 2020 at 12:37:49PM +0530, Bhupesh Sharma wrote:
> On Tue, Oct 6, 2020 at 11:30 PM Catalin Marinas
> wrote:
> > On Mon, Oct 05, 2020 at 11:12:10PM +0530, Bhupesh Sharma wrote:
> > > I think my earlier email with the test results on this series bounced
>
On Tue, Oct 06, 2020 at 10:10:54AM +0800, chenzhou wrote:
> On 2020/10/6 1:19, Catalin Marinas wrote:
> > On Mon, Sep 07, 2020 at 09:47:45PM +0800, Chen Zhou wrote:
> >> diff --git a/Documentation/admin-guide/kdump/kdump.rst
> >> b/Documentation/admin-guide/kdump/kdump.
urpose.
>
> Signed-off-by: Ionela Voinescu
> Cc: Russell King
> Cc: Catalin Marinas
> Cc: Will Deacon
For the arm64 changes:
Acked-by: Catalin Marinas
Hi Linus,
Please pull the arm64 fix below. Thanks.
The following changes since commit a509a66a9d0d4f4e304d58fad38c078d0336c445:
arm64: permit ACPI core to map kernel memory used for table overrides
(2020-09-30 22:27:51 +0100)
are available in the Git repository at:
On Mon, Oct 05, 2020 at 11:12:10PM +0530, Bhupesh Sharma wrote:
> I think my earlier email with the test results on this series bounced
> off the mailing list server (for some weird reason), but I still see
> several issues with this patchset. I will add specific issues in the
> review comments
On Tue, 6 Oct 2020 11:33:26 -0500, Jeremy Linton wrote:
> The AES code uses a 'br x7' as part of a function called by
> a macro. That branch needs a bti_j as a target. This results
> in a panic as seen below. Using x16 (or x17) with an indirect
> branch keeps the target bti_c.
>
> Bad mode in
On Tue, Oct 06, 2020 at 11:43:14AM +0100, Dave P Martin wrote:
> On Tue, Oct 06, 2020 at 11:25:11AM +0100, Catalin Marinas wrote:
> > On Tue, Oct 06, 2020 at 11:01:21AM +0100, Dave P Martin wrote:
> > > On Tue, Oct 06, 2020 at 09:27:48AM +0100, Will Deacon wrote:
> > > &
On Tue, Oct 06, 2020 at 11:01:21AM +0100, Dave P Martin wrote:
> On Tue, Oct 06, 2020 at 09:27:48AM +0100, Will Deacon wrote:
> > On Mon, Oct 05, 2020 at 10:48:54PM -0500, Jeremy Linton wrote:
> > > The AES code uses a 'br x7' as part of a function called by
> > > a macro. That branch needs a
On Fri, Sep 18, 2020 at 05:06:37PM +0800, chenzhou wrote:
> On 2020/9/18 16:59, chenzhou wrote:
> > On 2020/9/18 15:25, Baoquan He wrote:
> >> On 09/07/20 at 09:47pm, Chen Zhou wrote:
> >>> To make the functions reserve_crashkernel[_low]() as generic,
> >>> replace some hard-coded numbers with
On Mon, Sep 07, 2020 at 09:47:45PM +0800, Chen Zhou wrote:
> diff --git a/Documentation/admin-guide/kdump/kdump.rst
> b/Documentation/admin-guide/kdump/kdump.rst
> index 2da65fef2a1c..549611abc581 100644
> --- a/Documentation/admin-guide/kdump/kdump.rst
> +++
On Mon, Sep 07, 2020 at 09:47:42PM +0800, Chen Zhou wrote:
> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> index 53acbeca4f57..1b24072f2bae 100644
> --- a/arch/arm64/kernel/setup.c
> +++ b/arch/arm64/kernel/setup.c
> @@ -238,7 +238,18 @@ static void __init
On Mon, Sep 07, 2020 at 09:47:43PM +0800, Chen Zhou wrote:
> diff --git a/kernel/crash_core.c b/kernel/crash_core.c
> index 3f735cb37ace..d11d597a470d 100644
> --- a/kernel/crash_core.c
> +++ b/kernel/crash_core.c
> @@ -378,6 +378,15 @@ int __init reserve_crashkernel_low(void)
> }
>
> #if
On Sat, Sep 12, 2020 at 06:44:29AM -0500, John Donnelly wrote:
> On 9/7/20 8:47 AM, Chen Zhou wrote:
> > Chen Zhou (9):
> >x86: kdump: move CRASH_ALIGN to 2M
> >x86: kdump: make the lower bound of crash kernel reservation
> > consistent
> >x86: kdump: use macro CRASH_ADDR_LOW_MAX
ix the spelling of built-in by the way.
>
> Signed-off-by: Hui Su
Moving the test is fine by me.
Acked-by: Catalin Marinas
ccessibility
> kselftest/arm64: Verify all different mmap MTE options
> kselftest/arm64: Verify KSM page merge for MTE pages
> kselftest/arm64: Check mte tagged user address in kernel
Thanks Amit for respinning the series. Tested on FVP (some Qemu bugs get
in the way and they fail).
Acked-by: Ca
On Fri, Oct 02, 2020 at 01:10:31AM +0200, Andrey Konovalov wrote:
> From: Vincenzo Frascino
>
> Hardware tag-based KASAN relies on Memory Tagging Extension (MTE) that is
> built on top of the Top Byte Ignore (TBI) feature.
>
> Enable in-kernel TBI when CONFIG_KASAN_HW_TAGS is turned on by
> tag)
> return ptr;
> }
>
> +void mte_init_tags(u64 max_tag)
> +{
> + u64 incl = GENMASK(max_tag & MTE_TAG_MAX, 0);
Nitpick: it's not obvious that MTE_TAG_MAX is a mask, so better write
this as GENMASK(min(max_tag, MTE_TAG_MAX), 0).
Otherwise it looks fine.
Reviewed-by: Catalin Marinas
On Fri, Oct 02, 2020 at 01:10:28AM +0200, Andrey Konovalov wrote:
> diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
> index 23c326a06b2d..6c1a6621d769 100644
> --- a/arch/arm64/mm/proc.S
> +++ b/arch/arm64/mm/proc.S
> @@ -40,9 +40,15 @@
> #define TCR_CACHE_FLAGS TCR_IRGN_WBWA |
't have any dependencies and is safe to include into any
> low-level header.
>
> Signed-off-by: Vincenzo Frascino
> Co-developed-by: Andrey Konovalov
> Signed-off-by: Andrey Konovalov
Reviewed-by: Catalin Marinas
On Thu, Oct 01, 2020 at 07:31:19PM +0200, Nicolas Saenz Julienne wrote:
> On Thu, 2020-10-01 at 18:23 +0100, Catalin Marinas wrote:
> > On Thu, Oct 01, 2020 at 06:15:01PM +0100, Catalin Marinas wrote:
> > > On Thu, Oct 01, 2020 at 06:17:37PM +0200, Nicolas Saenz Julienne wrote:
Hi Linus,
Please pull the arm64 fix below. Thanks.
The following changes since commit 75df529bec9110dad43ab30e2d9490242529e8b8:
arm64: paravirt: Initialize steal time when cpu is online (2020-09-17
18:12:18 +0100)
are available in the Git repository at:
On Thu, Oct 01, 2020 at 06:15:01PM +0100, Catalin Marinas wrote:
> Hi Nicolas,
>
> Thanks for putting this together.
>
> On Thu, Oct 01, 2020 at 06:17:37PM +0200, Nicolas Saenz Julienne wrote:
> > diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> > index 4602e4
On Thu, Oct 01, 2020 at 06:17:40PM +0200, Nicolas Saenz Julienne wrote:
> The default behavior for arm64 changed, so reflect that.
>
> Signed-off-by: Nicolas Saenz Julienne
Acked-by: Catalin Marinas
On Thu, Oct 01, 2020 at 06:17:39PM +0200, Nicolas Saenz Julienne wrote:
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index e1a69a618832..3c3f462466eb 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -43,8 +43,6 @@
> #include
> #include
>
> -#define
Hi Nicolas,
Thanks for putting this together.
On Thu, Oct 01, 2020 at 06:17:37PM +0200, Nicolas Saenz Julienne wrote:
> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> index 4602e467ca8b..cd0d115ef329 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -25,6 +25,7 @@
> #include
>
skip the registration if CONFIG_MEMORY_HOTREMOVE
> is not enabled and also call out when memory notifier registration fails.
>
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Mark Rutland
> Cc: Marc Zyngier
> Cc: Steve Capper
> Cc: Mark Brown
> Cc: linux-arm-ker...@lists.infradead.o
flush_tlb_page(vma, address);
> return 1;
In my proposal I had a pte_accessible(pte) check instead of dirty here
since we may go for an old pte directly to a writable one and a TLBI
wouldn't be needed. Not that it matters from a performance perspective.
Either way,
Reviewed-by: Catalin Marinas
Hi Gavin,
On Mon, Sep 28, 2020 at 05:22:54PM +1000, Gavin Shan wrote:
> Testing
> ===
> [1] The experiment reveals how heavily the (L1) data cache miss impacts
> the overall application's performance. The machine where the test
> is carried out has the following L1 data cache
On Mon, Sep 28, 2020 at 02:08:29PM +, chenjun (AM) wrote:
> On Mon, Sep 21, 2020 at 02:00:05AM +, Chen Jun wrote:
> > From: Wei Yongjun
> >> @@ -651,6 +672,19 @@ static void create_object(unsigned long ptr, size_t
> >> size, int min_count,
> >>raw_spin_unlock_irqrestore(_lock,
On Fri, Sep 25, 2020 at 12:28:24PM +0100, Vincenzo Frascino wrote:
> On 9/25/20 11:15 AM, Catalin Marinas wrote:
> > On Fri, Sep 25, 2020 at 12:50:31AM +0200, Andrey Konovalov wrote:
> >> +u8 mte_get_mem_tag(void *addr);
> >> +u8 mte_get_random_tag(void);
> >&g
On Fri, Sep 25, 2020 at 12:50:23PM +0100, Vincenzo Frascino wrote:
> On 9/25/20 12:34 PM, Catalin Marinas wrote:
> > On Fri, Sep 25, 2020 at 12:50:36AM +0200, Andrey Konovalov wrote:
> >> + /*
> >> + * Calculate and set the exclude mask preserving
> >&
rey Konovalov
> Signed-off-by: Andrey Konovalov
Reviewed-by: Catalin Marinas
On Fri, Sep 25, 2020 at 01:52:56PM +0200, Andrey Konovalov wrote:
> On Fri, Sep 25, 2020 at 1:47 PM Catalin Marinas
> wrote:
> > On Fri, Sep 25, 2020 at 01:26:02PM +0200, Andrey Konovalov wrote:
> > > On Fri, Sep 25, 2020 at 12:49 PM Catalin Marinas
> > > wrote:
301 - 400 of 5901 matches
Mail list logo
