Re: [RFC 1/3] arm: mm: reordering memory type table

On Thu, Sep 06, 2018 at 07:22:10PM +0900, Minchan Kim wrote: > diff --git a/arch/arm/include/asm/pgtable-2level.h > b/arch/arm/include/asm/pgtable-2level.h > index 92fd2c8a9af0..91b99fadcba1 100644 > --- a/arch/arm/include/asm/pgtable-2level.h > +++ b/arch/arm/include/asm/pgtable-2level.h > @@

Re: [PATCH] arm64: defconfig: enable EFI_ARMSTUB_DTB_LOADER

On Wed, Sep 05, 2018 at 11:04:36AM -0700, Scott Branden wrote: > On 18-09-05 11:00 AM, Grant Likely wrote: > > On Wed, Sep 5, 2018 at 6:27 PM Scott Branden > > wrote: > > > On 18-09-05 02:40 AM, Ard Biesheuvel wrote: > > > > On 4 September 2018 at 19:19, Scott Branden > > > > wrote: > > > > >

Re: [PATCH] arm64: defconfig: enable EFI_ARMSTUB_DTB_LOADER

On Wed, Sep 05, 2018 at 11:04:36AM -0700, Scott Branden wrote: > On 18-09-05 11:00 AM, Grant Likely wrote: > > On Wed, Sep 5, 2018 at 6:27 PM Scott Branden > > wrote: > > > On 18-09-05 02:40 AM, Ard Biesheuvel wrote: > > > > On 4 September 2018 at 19:19, Scott Branden > > > > wrote: > > > > >

Re: [PATCH v3] kmemleak: add module param to print warnings to dmesg

> v3: Expand use case description. Replace config option with module parameter. > > mm/kmemleak.c | 42 +++++++--- > 1 file changed, 35 insertions(+), 7 deletions(-) Acked-by: Catalin Marinas

Re: [PATCH v3] kmemleak: add module param to print warnings to dmesg

> v3: Expand use case description. Replace config option with module parameter. > > mm/kmemleak.c | 42 +++++++--- > 1 file changed, 35 insertions(+), 7 deletions(-) Acked-by: Catalin Marinas

Re: [PATCHv2] kmemleak: Add option to print warnings to dmesg

On Thu, Aug 30, 2018 at 09:43:27AM +0200, Vincent Whitchurch wrote: > On Tue, Aug 28, 2018 at 11:26:22AM +0100, Catalin Marinas wrote: > > On Tue, Aug 28, 2018 at 12:14:12PM +0200, Vincent Whitchurch wrote: > > > On Mon, Aug 27, 2018 at 03:16:41PM -0700, Andrew Morton wrote: >

Re: [PATCHv2] kmemleak: Add option to print warnings to dmesg

On Thu, Aug 30, 2018 at 09:43:27AM +0200, Vincent Whitchurch wrote: > On Tue, Aug 28, 2018 at 11:26:22AM +0100, Catalin Marinas wrote: > > On Tue, Aug 28, 2018 at 12:14:12PM +0200, Vincent Whitchurch wrote: > > > On Mon, Aug 27, 2018 at 03:16:41PM -0700, Andrew Morton wrote: >

Re: Query on dma_set_mask_and_coherent() Usage

On Thu, Aug 23, 2018 at 08:20:36PM +0530, Kedareswararao Appana wrote: > On arm64 platform I have booted Linux only with > 32-bit > Address i.e from 0x8 (reg = <0x8 0x 0x0 0x8000>) So you have 2GB of RAM starting at 0x8__. > In my driver, I am using

Re: Query on dma_set_mask_and_coherent() Usage

On Thu, Aug 23, 2018 at 08:20:36PM +0530, Kedareswararao Appana wrote: > On arm64 platform I have booted Linux only with > 32-bit > Address i.e from 0x8 (reg = <0x8 0x 0x0 0x8000>) So you have 2GB of RAM starting at 0x8__. > In my driver, I am using

Re: [PATCHv2] kmemleak: Add option to print warnings to dmesg

On Tue, Aug 28, 2018 at 12:14:12PM +0200, Vincent Whitchurch wrote: > On Mon, Aug 27, 2018 at 03:16:41PM -0700, Andrew Morton wrote: > > On Mon, 27 Aug 2018 10:38:21 +0200 Vincent Whitchurch > > wrote: > > > --- a/lib/Kconfig.debug > > > +++ b/lib/Kconfig.debug > > > @@ -593,6 +593,15 @@ config

Re: [PATCHv2] kmemleak: Add option to print warnings to dmesg

On Tue, Aug 28, 2018 at 12:14:12PM +0200, Vincent Whitchurch wrote: > On Mon, Aug 27, 2018 at 03:16:41PM -0700, Andrew Morton wrote: > > On Mon, 27 Aug 2018 10:38:21 +0200 Vincent Whitchurch > > wrote: > > > --- a/lib/Kconfig.debug > > > +++ b/lib/Kconfig.debug > > > @@ -593,6 +593,15 @@ config

Re: [PATCH] kmemleak: Always register debugfs file

ailable but is disabled > by default and can be activated via the kernel command line. > > Signed-off-by: Vincent Whitchurch I think that's also consistent with a late disabling of kmemleak when the debugfs entry sticks around. Acked-by: Catalin Marinas

Re: [PATCH] kmemleak: Always register debugfs file

ailable but is disabled > by default and can be activated via the kernel command line. > > Signed-off-by: Vincent Whitchurch I think that's also consistent with a late disabling of kmemleak when the debugfs entry sticks around. Acked-by: Catalin Marinas

Re: [PATCH] kmemleak: Add option to print warnings to dmesg

On Fri, Aug 24, 2018 at 02:40:11PM +0200, Vincent Whitchurch wrote: > diff --git a/mm/kmemleak.c b/mm/kmemleak.c > index 9a085d525bbc..61ba47a357fc 100644 > --- a/mm/kmemleak.c > +++ b/mm/kmemleak.c > @@ -311,6 +311,9 @@ static void hex_dump_object(struct seq_file *seq, > const u8 *ptr =

Re: [PATCH] kmemleak: Add option to print warnings to dmesg

On Fri, Aug 24, 2018 at 02:40:11PM +0200, Vincent Whitchurch wrote: > diff --git a/mm/kmemleak.c b/mm/kmemleak.c > index 9a085d525bbc..61ba47a357fc 100644 > --- a/mm/kmemleak.c > +++ b/mm/kmemleak.c > @@ -311,6 +311,9 @@ static void hex_dump_object(struct seq_file *seq, > const u8 *ptr =

Re: [RFC PATCH 2/2] mm: mmu_notifier fix for tlb_end_vma

On Thu, Aug 23, 2018 at 06:47:09PM +1000, Nicholas Piggin wrote: > The generic tlb_end_vma does not call invalidate_range mmu notifier, > and it resets resets the mmu_gather range, which means the notifier > won't be called on part of the range in case of an unmap that spans > multiple vmas. > >

Re: [RFC PATCH 2/2] mm: mmu_notifier fix for tlb_end_vma

On Thu, Aug 23, 2018 at 06:47:09PM +1000, Nicholas Piggin wrote: > The generic tlb_end_vma does not call invalidate_range mmu notifier, > and it resets resets the mmu_gather range, which means the notifier > won't be called on part of the range in case of an unmap that spans > multiple vmas. > >

Re: [RESEND PATCH v10 1/6] arm: arm64: introduce CONFIG_HAVE_MEMBLOCK_PFN_VALID

On Fri, Jul 06, 2018 at 05:01:10PM +0800, Jia He wrote: > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > index 42c090c..26d75f4 100644 > --- a/arch/arm64/Kconfig > +++ b/arch/arm64/Kconfig > @@ -778,6 +778,10 @@ config ARCH_SELECT_MEMORY_MODEL > config HAVE_ARCH_PFN_VALID > def_bool

Re: [RESEND PATCH v10 1/6] arm: arm64: introduce CONFIG_HAVE_MEMBLOCK_PFN_VALID

On Fri, Jul 06, 2018 at 05:01:10PM +0800, Jia He wrote: > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > index 42c090c..26d75f4 100644 > --- a/arch/arm64/Kconfig > +++ b/arch/arm64/Kconfig > @@ -778,6 +778,10 @@ config ARCH_SELECT_MEMORY_MODEL > config HAVE_ARCH_PFN_VALID > def_bool

Re: framebuffer corruption due to overlapping stp instructions on arm64

On Wed, Aug 08, 2018 at 04:01:12PM +0100, Richard Earnshaw wrote: > On 08/08/18 15:12, Mikulas Patocka wrote: > > On Wed, 8 Aug 2018, Catalin Marinas wrote: > >> On Fri, Aug 03, 2018 at 01:09:02PM -0400, Mikulas Patocka wrote: > >>> while (1) { > >>>

Re: framebuffer corruption due to overlapping stp instructions on arm64

On Wed, Aug 08, 2018 at 04:01:12PM +0100, Richard Earnshaw wrote: > On 08/08/18 15:12, Mikulas Patocka wrote: > > On Wed, 8 Aug 2018, Catalin Marinas wrote: > >> On Fri, Aug 03, 2018 at 01:09:02PM -0400, Mikulas Patocka wrote: > >>> while (1) { > >>>

Re: framebuffer corruption due to overlapping stp instructions on arm64

On Wed, Aug 08, 2018 at 02:26:11PM +, David Laight wrote: > From: Mikulas Patocka > > Sent: 08 August 2018 14:47 > ... > > The problem on ARM is that I see data corruption when the overlapping > > unaligned writes are done just by a single core. > > Is this a sequence of unaligned writes

Re: framebuffer corruption due to overlapping stp instructions on arm64

On Wed, Aug 08, 2018 at 02:26:11PM +, David Laight wrote: > From: Mikulas Patocka > > Sent: 08 August 2018 14:47 > ... > > The problem on ARM is that I see data corruption when the overlapping > > unaligned writes are done just by a single core. > > Is this a sequence of unaligned writes

Re: framebuffer corruption due to overlapping stp instructions on arm64

On Wed, Aug 08, 2018 at 10:12:27AM -0400, Mikulas Patocka wrote: > On Wed, 8 Aug 2018, Catalin Marinas wrote: > > On Fri, Aug 03, 2018 at 01:09:02PM -0400, Mikulas Patocka wrote: > > > while (1) { > > > start = (unsigned)random() % (LEN + 1); > > &

Re: framebuffer corruption due to overlapping stp instructions on arm64

On Wed, Aug 08, 2018 at 10:12:27AM -0400, Mikulas Patocka wrote: > On Wed, 8 Aug 2018, Catalin Marinas wrote: > > On Fri, Aug 03, 2018 at 01:09:02PM -0400, Mikulas Patocka wrote: > > > while (1) { > > > start = (unsigned)random() % (LEN + 1); > > &

Re: [PATCH] arm64: Trap WFI executed in userspace

map this to SIGILL rather than be permissive and regret it later. > > I couldn't find any user, and I'm happy to just send userspace to hell > in that case. But it could also been said that since it was never > prevented, it is a de-facto ABI. I wouldn't really go as far as SIGILL on WFI. I think the patch is fine as it is. In case Will plans to merge it: Acked-by: Catalin Marinas

Re: [PATCH] arm64: Trap WFI executed in userspace

map this to SIGILL rather than be permissive and regret it later. > > I couldn't find any user, and I'm happy to just send userspace to hell > in that case. But it could also been said that since it was never > prevented, it is a de-facto ABI. I wouldn't really go as far as SIGILL on WFI. I think the patch is fine as it is. In case Will plans to merge it: Acked-by: Catalin Marinas

Re: framebuffer corruption due to overlapping stp instructions on arm64

Hi Matt, On Fri, Aug 03, 2018 at 03:44:44PM -0500, Matt Sealey wrote: > On 3 August 2018 at 13:25, Mikulas Patocka wrote: > > On Fri, 3 Aug 2018, Ard Biesheuvel wrote: > >> Are we still talking about overlapping unaligned accesses here? Or do > >> you see other failures as well? > > > > Yes - it

Re: framebuffer corruption due to overlapping stp instructions on arm64

Hi Matt, On Fri, Aug 03, 2018 at 03:44:44PM -0500, Matt Sealey wrote: > On 3 August 2018 at 13:25, Mikulas Patocka wrote: > > On Fri, 3 Aug 2018, Ard Biesheuvel wrote: > >> Are we still talking about overlapping unaligned accesses here? Or do > >> you see other failures as well? > > > > Yes - it

Re: framebuffer corruption due to overlapping stp instructions on arm64

On Fri, Aug 03, 2018 at 01:09:02PM -0400, Mikulas Patocka wrote: > while (1) { > start = (unsigned)random() % (LEN + 1); > end = (unsigned)random() % (LEN + 1); > if (start > end) > continue; > for (i = start; i <

Re: framebuffer corruption due to overlapping stp instructions on arm64

On Fri, Aug 03, 2018 at 01:09:02PM -0400, Mikulas Patocka wrote: > while (1) { > start = (unsigned)random() % (LEN + 1); > end = (unsigned)random() % (LEN + 1); > if (start > end) > continue; > for (i = start; i <

Re: framebuffer corruption due to overlapping stp instructions on arm64

On Mon, Aug 06, 2018 at 05:47:36PM +0200, Ard Biesheuvel wrote: > On 6 August 2018 at 14:42, Robin Murphy wrote: > > On 06/08/18 11:25, Mikulas Patocka wrote: > > [...] > >>> > >>> None of this explains why some transactions fail to make it across > >>> entirely. The overlapping writes in

Re: framebuffer corruption due to overlapping stp instructions on arm64

On Mon, Aug 06, 2018 at 05:47:36PM +0200, Ard Biesheuvel wrote: > On 6 August 2018 at 14:42, Robin Murphy wrote: > > On 06/08/18 11:25, Mikulas Patocka wrote: > > [...] > >>> > >>> None of this explains why some transactions fail to make it across > >>> entirely. The overlapping writes in

Re: [PATCH 1/1] arm64: kexec: machine_kexec should call __flush_icache_range

On Mon, Jul 30, 2018 at 05:22:35PM +0100, Will Deacon wrote: > On Mon, Jul 30, 2018 at 05:16:42PM +0100, Catalin Marinas wrote: > > On Mon, Jul 30, 2018 at 10:29:21AM -0500, Dave Kleikamp wrote: > > > machine_kexec flushes the reboot_code_buffer from the icache > > > af

Re: [PATCH 1/1] arm64: kexec: machine_kexec should call __flush_icache_range

On Mon, Jul 30, 2018 at 05:22:35PM +0100, Will Deacon wrote: > On Mon, Jul 30, 2018 at 05:16:42PM +0100, Catalin Marinas wrote: > > On Mon, Jul 30, 2018 at 10:29:21AM -0500, Dave Kleikamp wrote: > > > machine_kexec flushes the reboot_code_buffer from the icache > > > af

Re: [PATCH 1/1] arm64: kexec: machine_kexec should call __flush_icache_range

t; Signed-off-by: Dave Kleikamp > Cc: AKASHI Takahiro > Cc: Catalin Marinas > Cc: Will Deacon > --- > arch/arm64/kernel/machine_kexec.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm64/kernel/machine_kexec.c > b/arch/arm64/kernel/ma

Re: [PATCH 1/1] arm64: kexec: machine_kexec should call __flush_icache_range

t; Signed-off-by: Dave Kleikamp > Cc: AKASHI Takahiro > Cc: Catalin Marinas > Cc: Will Deacon > --- > arch/arm64/kernel/machine_kexec.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm64/kernel/machine_kexec.c > b/arch/arm64/kernel/ma

[GIT PULL] arm64 fixes for 4.18-rc4

Hi Linus, Please pull the arm64 patches below. Thanks. The following changes since commit 021c91791a5e7e85c567452f1be3e4c2c6cb6063: Linux 4.18-rc3 (2018-07-01 16:04:53 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-fixes

[GIT PULL] arm64 fixes for 4.18-rc4

Hi Linus, Please pull the arm64 patches below. Thanks. The following changes since commit 021c91791a5e7e85c567452f1be3e4c2c6cb6063: Linux 4.18-rc3 (2018-07-01 16:04:53 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-fixes

Re: [PATCH 2/2] arm64: add support for 43bit physical address

On Tue, Jul 03, 2018 at 06:35:32PM +, Nikunj Kela (nkela) wrote: > We are trying to reduce the memory allocation needed for kdump kernel. > We want to reserve less than 32M for kdump kernel if possible. We are > able to get ~14M saving by the proposed change. Have you tried disabling

Re: [PATCH 2/2] arm64: add support for 43bit physical address

On Tue, Jul 03, 2018 at 06:35:32PM +, Nikunj Kela (nkela) wrote: > We are trying to reduce the memory allocation needed for kdump kernel. > We want to reserve less than 32M for kdump kernel if possible. We are > able to get ~14M saving by the proposed change. Have you tried disabling

Re: [PATCH] arm64: Clear the stack

On Tue, Jul 03, 2018 at 01:14:41PM +0100, Mark Rutland wrote: > On Mon, Jul 02, 2018 at 11:48:05AM -0700, Laura Abbott wrote: > > On 07/02/2018 06:02 AM, Alexander Popov wrote: > > > On 29.06.2018 22:05, Laura Abbott wrote: > > > > Implementation of stackleak based heavily on the x86 version > > >

Re: [PATCH] arm64: Clear the stack

On Tue, Jul 03, 2018 at 01:14:41PM +0100, Mark Rutland wrote: > On Mon, Jul 02, 2018 at 11:48:05AM -0700, Laura Abbott wrote: > > On 07/02/2018 06:02 AM, Alexander Popov wrote: > > > On 29.06.2018 22:05, Laura Abbott wrote: > > > > Implementation of stackleak based heavily on the x86 version > > >

Re: [PATCH 2/2] arm64: add support for 43bit physical address

On Mon, Jul 02, 2018 at 02:04:51PM -0700, Nikunj Kela wrote: > This patch adds support for 43bit physical address. Additionally, > this patch adds support for 27bit section size. This is useful in > reducing kernel memory usage. One usecase is in kdump kernel. Some numbers please. -- Catalin

Re: [PATCH 2/2] arm64: add support for 43bit physical address

On Mon, Jul 02, 2018 at 02:04:51PM -0700, Nikunj Kela wrote: > This patch adds support for 43bit physical address. Additionally, > this patch adds support for 27bit section size. This is useful in > reducing kernel memory usage. One usecase is in kdump kernel. Some numbers please. -- Catalin

[GIT PULL] arm64 fixes for 4.18-rc3

() which itself uses alternatives. Change the code to use an unpatched variant of cache maintenance - Remove unnecessary ISBs from set_{pte,pmd,pud} - perf: xgene_pmu: Fix IOB SLOW PMU parser error Catalin Marinas (1): Merge

[GIT PULL] arm64 fixes for 4.18-rc3

() which itself uses alternatives. Change the code to use an unpatched variant of cache maintenance - Remove unnecessary ISBs from set_{pte,pmd,pud} - perf: xgene_pmu: Fix IOB SLOW PMU parser error Catalin Marinas (1): Merge

[GIT PULL] arm64 fixes for 4.18-rc2

Hi Linus, Please pull the arm64 fixes below. Thanks. The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40: Linux 4.18-rc1 (2018-06-17 08:04:49 +0900) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-fixes

[GIT PULL] arm64 fixes for 4.18-rc2

Hi Linus, Please pull the arm64 fixes below. Thanks. The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40: Linux 4.18-rc1 (2018-06-17 08:04:49 +0900) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-fixes

Re: [PATCH] arm64: make secondary_start_kernel() notrace

On Tue, Jun 12, 2018 at 05:07:37PM +0800, Zhizhou Zhang wrote: > We can't call function trace hook before setup percpu offset. > When entering secondary_start_kernel(), percpu offset has not > been initialized. So this lead hotplug malfunction. > Here is the flow to reproduce this bug: > > echo

Re: [PATCH] arm64: make secondary_start_kernel() notrace

On Tue, Jun 12, 2018 at 05:07:37PM +0800, Zhizhou Zhang wrote: > We can't call function trace hook before setup percpu offset. > When entering secondary_start_kernel(), percpu offset has not > been initialized. So this lead hotplug malfunction. > Here is the flow to reproduce this bug: > > echo

[GIT PULL] arm64 patches for 4.18

Arnd Bergmann (3): drivers/bus: arm-cci: fix build warnings ARM: mcpm, perf/arm-cci: export mcpm_is_available arm64: cpu_errata: include required headers Catalin Marinas (4): Revert "arm64: Increase the max granular size"

[GIT PULL] arm64 patches for 4.18

Arnd Bergmann (3): drivers/bus: arm-cci: fix build warnings ARM: mcpm, perf/arm-cci: export mcpm_is_available arm64: cpu_errata: include required headers Catalin Marinas (4): Revert "arm64: Increase the max granular size"

Re: [PATCH v2] arm64: topology: Avoid checking numa mask for scheduler MC selection

On Wed, Jun 06, 2018 at 11:38:46AM -0500, Jeremy Linton wrote: > The numa mask subset check can often lead to system hang or crash during > CPU hotplug and system suspend operation if NUMA is disabled. This is > mostly observed on HMP systems where the CPU compute capacities are > different and

Re: [PATCH v2] arm64: topology: Avoid checking numa mask for scheduler MC selection

On Wed, Jun 06, 2018 at 11:38:46AM -0500, Jeremy Linton wrote: > The numa mask subset check can often lead to system hang or crash during > CPU hotplug and system suspend operation if NUMA is disabled. This is > mostly observed on HMP systems where the CPU compute capacities are > different and

Re: [PATCH v2 2/3] ACPI / PPTT: fix build when CONFIG_ACPI_PPTT is not enabled

On Tue, Jun 05, 2018 at 03:35:03PM +0100, Sudeep Holla wrote: > Though CONFIG_ACPI_PPTT is selected by platforms and nor user visible, > it may be useful to support the build with CONFIG_ACPI_PPTT disabled. > > This patch adds the missing dummy/boiler plate implementation to fix > the build. > >

Re: [PATCH v2 2/3] ACPI / PPTT: fix build when CONFIG_ACPI_PPTT is not enabled

On Tue, Jun 05, 2018 at 03:35:03PM +0100, Sudeep Holla wrote: > Though CONFIG_ACPI_PPTT is selected by platforms and nor user visible, > it may be useful to support the build with CONFIG_ACPI_PPTT disabled. > > This patch adds the missing dummy/boiler plate implementation to fix > the build. > >

Re: [PATCH] arm64: cpu_errata: include required headers

On Tue, Jun 05, 2018 at 01:50:07PM +0200, Arnd Bergmann wrote: > Without including psci.h and arm-smccc.h, we now get a build failure in > some configurations: > > arch/arm64/kernel/cpu_errata.c: In function 'arm64_update_smccc_conduit': > arch/arm64/kernel/cpu_errata.c:278:10: error: 'psci_ops'

Re: [PATCH] arm64: cpu_errata: include required headers

On Tue, Jun 05, 2018 at 01:50:07PM +0200, Arnd Bergmann wrote: > Without including psci.h and arm-smccc.h, we now get a build failure in > some configurations: > > arch/arm64/kernel/cpu_errata.c: In function 'arm64_update_smccc_conduit': > arch/arm64/kernel/cpu_errata.c:278:10: error: 'psci_ops'

Re: [PATCH v9 00/12] Support PPTT for ARM64

On Thu, May 17, 2018 at 06:05:24PM +0100, Catalin Marinas wrote: > On Fri, May 11, 2018 at 06:57:55PM -0500, Jeremy Linton wrote: > > Jeremy Linton (12): > > drivers: base: cacheinfo: move cache_setup_of_node() > > drivers: base: cacheinfo: setup DT cache properties

Re: [PATCH v9 00/12] Support PPTT for ARM64

On Thu, May 17, 2018 at 06:05:24PM +0100, Catalin Marinas wrote: > On Fri, May 11, 2018 at 06:57:55PM -0500, Jeremy Linton wrote: > > Jeremy Linton (12): > > drivers: base: cacheinfo: move cache_setup_of_node() > > drivers: base: cacheinfo: setup DT cache properties

Re: [PATCH v2 00/17] arm64 SSBD (aka Spectre-v4) mitigation

On Tue, May 29, 2018 at 01:11:04PM +0100, Marc Zyngier wrote: > Marc Zyngier (17): > arm/arm64: smccc: Add SMCCC-specific return codes > arm64: Call ARCH_WORKAROUND_2 on transitions between EL0 and EL1 > arm64: Add per-cpu infrastructure to call ARCH_WORKAROUND_2 > arm64: Add

Re: [PATCH v2 00/17] arm64 SSBD (aka Spectre-v4) mitigation

On Tue, May 29, 2018 at 01:11:04PM +0100, Marc Zyngier wrote: > Marc Zyngier (17): > arm/arm64: smccc: Add SMCCC-specific return codes > arm64: Call ARCH_WORKAROUND_2 on transitions between EL0 and EL1 > arm64: Add per-cpu infrastructure to call ARCH_WORKAROUND_2 > arm64: Add

Re: [PATCH v9 00/12] Support PPTT for ARM64

On Fri, May 11, 2018 at 06:57:55PM -0500, Jeremy Linton wrote: > Jeremy Linton (12): > drivers: base: cacheinfo: move cache_setup_of_node() > drivers: base: cacheinfo: setup DT cache properties early > cacheinfo: rename of_node to fw_token > arm64/acpi: Create arch specific cpu to acpi id

Re: [PATCH v9 00/12] Support PPTT for ARM64

On Fri, May 11, 2018 at 06:57:55PM -0500, Jeremy Linton wrote: > Jeremy Linton (12): > drivers: base: cacheinfo: move cache_setup_of_node() > drivers: base: cacheinfo: setup DT cache properties early > cacheinfo: rename of_node to fw_token > arm64/acpi: Create arch specific cpu to acpi id

Re: [PATCH] arm64: remove no-op macro VMLINUX_SYMBOL()

On Wed, May 09, 2018 at 04:46:26PM +0900, Masahiro Yamada wrote: > VMLINUX_SYMBOL() is no-op unless CONFIG_HAVE_UNDERSCORE_SYMBOL_PREFIX > is defined. It has ever been selected only by BLACKFIN and METAG. > VMLINUX_SYMBOL() is unneeded for ARM64-specific code. > > Signed-off-by: Masahiro Yamada

Re: [PATCH] arm64: remove no-op macro VMLINUX_SYMBOL()

On Wed, May 09, 2018 at 04:46:26PM +0900, Masahiro Yamada wrote: > VMLINUX_SYMBOL() is no-op unless CONFIG_HAVE_UNDERSCORE_SYMBOL_PREFIX > is defined. It has ever been selected only by BLACKFIN and METAG. > VMLINUX_SYMBOL() is unneeded for ARM64-specific code. > > Signed-off-by: Masahiro Yamada

Re: [PATCH v3 4/4] KVM: arm64: Add support for PUD hugepages at stage 2

nule) which can be useful on cores that > support mapping larger block sizes in the TLB entries. > > Signed-off-by: Punit Agrawal <punit.agra...@arm.com> > Reviewed-by: Christoffer Dall <christoffer.d...@arm.com> > Cc: Marc Zyngier <marc.zyng...@arm.com> > Cc: Russell

Re: [PATCH v3 4/4] KVM: arm64: Add support for PUD hugepages at stage 2

nule) which can be useful on cores that > support mapping larger block sizes in the TLB entries. > > Signed-off-by: Punit Agrawal > Reviewed-by: Christoffer Dall > Cc: Marc Zyngier > Cc: Russell King > Cc: Catalin Marinas > Cc: Will Deacon > --- > arch/arm/include/as

Re: [PATCH v2 4/4] KVM: arm64: Add support for PUD hugepages at stage 2

nule) which can be useful on cores that > support mapping larger block sizes in the TLB entries. > > Signed-off-by: Punit Agrawal <punit.agra...@arm.com> > Cc: Christoffer Dall <christoffer.d...@arm.com> > Cc: Marc Zyngier <marc.zyng...@arm.com> > Cc: Russell

Re: [PATCH v2 4/4] KVM: arm64: Add support for PUD hugepages at stage 2

nule) which can be useful on cores that > support mapping larger block sizes in the TLB entries. > > Signed-off-by: Punit Agrawal > Cc: Christoffer Dall > Cc: Marc Zyngier > Cc: Russell King > Cc: Catalin Marinas > Cc: Will Deacon > --- > arch/arm/include/asm/kvm_

Re: [GIT PULL] arm64: updates for 4.17

dependencies, > > so the diffstat strays slightly out of arm64 due to his changes. > {snip} > > > > Catalin Marinas (1): > > arm64: Revert L1_CACHE_SHIFT back to 6 (64-byte cache line size) > > I'm wondering if we are changing the L1_CACHE_SHIFT to 6 in 4.17? &g

Re: [GIT PULL] arm64: updates for 4.17

o the diffstat strays slightly out of arm64 due to his changes. > {snip} > > > > Catalin Marinas (1): > > arm64: Revert L1_CACHE_SHIFT back to 6 (64-byte cache line size) > > I'm wondering if we are changing the L1_CACHE_SHIFT to 6 in 4.17? > This is causing big performa

Re: [PATCH 4/6] mm, arm64: untag user addresses in mm/gup.c

On Wed, May 02, 2018 at 07:25:17PM +0200, Andrey Konovalov wrote: > On Wed, May 2, 2018 at 5:36 PM, Kirill A. Shutemov > wrote: > > On Wed, May 02, 2018 at 02:38:42PM +, Andrey Konovalov wrote: > >> > Does having a tagged address here makes any difference? I

Re: [PATCH 4/6] mm, arm64: untag user addresses in mm/gup.c

On Wed, May 02, 2018 at 07:25:17PM +0200, Andrey Konovalov wrote: > On Wed, May 2, 2018 at 5:36 PM, Kirill A. Shutemov > wrote: > > On Wed, May 02, 2018 at 02:38:42PM +, Andrey Konovalov wrote: > >> > Does having a tagged address here makes any difference? I couldn't hit a > >> > failure with

Re: [PATCH v8 2/4] arm64: tlbflush: Introduce __flush_tlb_kernel_pgtable

On Tue, Apr 03, 2018 at 01:30:44PM +0530, Chintan Pandya wrote: > Add an interface to invalidate intermediate page tables > from TLB for kernel. > > Signed-off-by: Chintan Pandya > --- > arch/arm64/include/asm/tlbflush.h | 6 ++ > 1 file changed, 6 insertions(+) > >

Re: [PATCH v8 2/4] arm64: tlbflush: Introduce __flush_tlb_kernel_pgtable

On Tue, Apr 03, 2018 at 01:30:44PM +0530, Chintan Pandya wrote: > Add an interface to invalidate intermediate page tables > from TLB for kernel. > > Signed-off-by: Chintan Pandya > --- > arch/arm64/include/asm/tlbflush.h | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git

Re: [PATCH v8 0/4] Fix issues with huge mapping in ioremap for ARM64

On Tue, Apr 17, 2018 at 03:55:08PM +0530, Chintan Pandya wrote: > Ping... > > On 4/3/2018 1:30 PM, Chintan Pandya wrote: > > This series of patches are follow up work (and depends on) > > Toshi Kani 's patches "fix memory leak/ > > panic in ioremap huge pages". First of all,

Re: [PATCH v8 0/4] Fix issues with huge mapping in ioremap for ARM64

On Tue, Apr 17, 2018 at 03:55:08PM +0530, Chintan Pandya wrote: > Ping... > > On 4/3/2018 1:30 PM, Chintan Pandya wrote: > > This series of patches are follow up work (and depends on) > > Toshi Kani 's patches "fix memory leak/ > > panic in ioremap huge pages". First of all, you'd need to post

Re: [PATCH 0/6] arm64: untag user pointers passed to the kernel

On Wed, Apr 25, 2018 at 04:45:37PM +0200, Andrey Konovalov wrote: > On Thu, Apr 19, 2018 at 11:33 AM, Kirill A. Shutemov > wrote: > > On Wed, Apr 18, 2018 at 08:53:09PM +0200, Andrey Konovalov wrote: > >> arm64 has a feature called Top Byte Ignore, which allows to embed

Re: [PATCH 0/6] arm64: untag user pointers passed to the kernel

On Wed, Apr 25, 2018 at 04:45:37PM +0200, Andrey Konovalov wrote: > On Thu, Apr 19, 2018 at 11:33 AM, Kirill A. Shutemov > wrote: > > On Wed, Apr 18, 2018 at 08:53:09PM +0200, Andrey Konovalov wrote: > >> arm64 has a feature called Top Byte Ignore, which allows to embed pointer > >> tags into the

Re: [PATCH 4/6] mm, arm64: untag user addresses in mm/gup.c

On Wed, Apr 18, 2018 at 08:53:13PM +0200, Andrey Konovalov wrote: > diff --git a/mm/gup.c b/mm/gup.c > index 76af4cfeaf68..fb375de7d40d 100644 > --- a/mm/gup.c > +++ b/mm/gup.c > @@ -386,6 +386,8 @@ struct page *follow_page_mask(struct vm_area_struct *vma, > struct page *page; > struct

Re: [PATCH 4/6] mm, arm64: untag user addresses in mm/gup.c

On Wed, Apr 18, 2018 at 08:53:13PM +0200, Andrey Konovalov wrote: > diff --git a/mm/gup.c b/mm/gup.c > index 76af4cfeaf68..fb375de7d40d 100644 > --- a/mm/gup.c > +++ b/mm/gup.c > @@ -386,6 +386,8 @@ struct page *follow_page_mask(struct vm_area_struct *vma, > struct page *page; > struct

Re: [PATCH 3/6] arm64: untag user addresses in copy_from_user and others

On Wed, Apr 18, 2018 at 08:53:12PM +0200, Andrey Konovalov wrote: > @@ -238,12 +239,15 @@ static inline void uaccess_enable_not_uao(void) > /* > * Sanitise a uaccess pointer such that it becomes NULL if above the > * current addr_limit. > + * Also untag user pointers that have the top byte

Re: [PATCH 3/6] arm64: untag user addresses in copy_from_user and others

On Wed, Apr 18, 2018 at 08:53:12PM +0200, Andrey Konovalov wrote: > @@ -238,12 +239,15 @@ static inline void uaccess_enable_not_uao(void) > /* > * Sanitise a uaccess pointer such that it becomes NULL if above the > * current addr_limit. > + * Also untag user pointers that have the top byte

Re: [RFC] mm: kmemleak: replace __GFP_NOFAIL to GFP_NOWAIT in gfp_kmemleak_mask

On Thu, Apr 26, 2018 at 08:23:19AM -0400, Chunyu Hu wrote: > kmemleak is using kmem_cache to record every pointers returned from kernel > mem > allocation activities such as kmem_cache_alloc(). every time an object from > slab allocator is returned, a following new kmemleak object is allocated.

Re: [RFC] mm: kmemleak: replace __GFP_NOFAIL to GFP_NOWAIT in gfp_kmemleak_mask

On Thu, Apr 26, 2018 at 08:23:19AM -0400, Chunyu Hu wrote: > kmemleak is using kmem_cache to record every pointers returned from kernel > mem > allocation activities such as kmem_cache_alloc(). every time an object from > slab allocator is returned, a following new kmemleak object is allocated.

Re: [PATCH] arm64: skip cpu nodes marked as disabled in DT

On Wed, Apr 25, 2018 at 11:36:06PM +, Rohit Khanna wrote: > Adding few other folks. It looks fine to me but cc'ing Mark and Lorenzo (and it should have been posted on linux-arm-ker...@lists.infradead.org). > From: Rohit Khanna > Sent: Wednesday, April 25, 2018 4:08 PM > To:

Re: [PATCH] arm64: skip cpu nodes marked as disabled in DT

On Wed, Apr 25, 2018 at 11:36:06PM +, Rohit Khanna wrote: > Adding few other folks. It looks fine to me but cc'ing Mark and Lorenzo (and it should have been posted on linux-arm-ker...@lists.infradead.org). > From: Rohit Khanna > Sent: Wednesday, April 25, 2018 4:08 PM > To:

Re: [RFC] mm: kmemleak: replace __GFP_NOFAIL to GFP_NOWAIT in gfp_kmemleak_mask

On Wed, Apr 25, 2018 at 05:50:41AM -0400, Chunyu Hu wrote: > - Original Message - > > From: "Catalin Marinas" <catalin.mari...@arm.com> > > On Tue, Apr 24, 2018 at 07:20:57AM -0600, Michal Hocko wrote: > > > On Mon 23-04-18 12:17:32,

Re: [RFC] mm: kmemleak: replace __GFP_NOFAIL to GFP_NOWAIT in gfp_kmemleak_mask

On Wed, Apr 25, 2018 at 05:50:41AM -0400, Chunyu Hu wrote: > - Original Message - > > From: "Catalin Marinas" > > On Tue, Apr 24, 2018 at 07:20:57AM -0600, Michal Hocko wrote: > > > On Mon 23-04-18 12:17:32, Chunyu Hu wrote: > > > [...]

Re: [PATCHv3 11/11] arm64: docs: document pointer authentication

On Tue, Apr 17, 2018 at 07:37:35PM +0100, Mark Rutland wrote: > +Basic support > +- > + > +When CONFIG_ARM64_PTR_AUTH is selected, and relevant HW support is > +present, the kernel will assign a random APIAKey value to each process > +at exec*() time. This key is shared by all threads

Re: [PATCHv3 11/11] arm64: docs: document pointer authentication

On Tue, Apr 17, 2018 at 07:37:35PM +0100, Mark Rutland wrote: > +Basic support > +- > + > +When CONFIG_ARM64_PTR_AUTH is selected, and relevant HW support is > +present, the kernel will assign a random APIAKey value to each process > +at exec*() time. This key is shared by all threads

Re: [PATCHv3 07/11] arm64: add basic pointer authentication support

Hi Mark, On Tue, Apr 17, 2018 at 07:37:31PM +0100, Mark Rutland wrote: > diff --git a/arch/arm64/include/asm/mmu_context.h > b/arch/arm64/include/asm/mmu_context.h > index 39ec0b8a689e..caf0d3010112 100644 > --- a/arch/arm64/include/asm/mmu_context.h > +++ b/arch/arm64/include/asm/mmu_context.h

Re: [PATCHv3 07/11] arm64: add basic pointer authentication support

Hi Mark, On Tue, Apr 17, 2018 at 07:37:31PM +0100, Mark Rutland wrote: > diff --git a/arch/arm64/include/asm/mmu_context.h > b/arch/arm64/include/asm/mmu_context.h > index 39ec0b8a689e..caf0d3010112 100644 > --- a/arch/arm64/include/asm/mmu_context.h > +++ b/arch/arm64/include/asm/mmu_context.h

Re: [PATCH] kmemleak: Report if we need to tune KMEMLEAK_EARLY_LOG_SIZE

On Tue, Apr 24, 2018 at 05:51:15PM +0200, Jan Kiszka wrote: > ...rather than just mysteriously disabling it. > > Signed-off-by: Jan Kiszka > --- > mm/kmemleak.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/mm/kmemleak.c b/mm/kmemleak.c > index

Re: [PATCH] kmemleak: Report if we need to tune KMEMLEAK_EARLY_LOG_SIZE

On Tue, Apr 24, 2018 at 05:51:15PM +0200, Jan Kiszka wrote: > ...rather than just mysteriously disabling it. > > Signed-off-by: Jan Kiszka > --- > mm/kmemleak.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/mm/kmemleak.c b/mm/kmemleak.c > index 9a085d525bbc..156c0c69cc5c 100644 >

Re: [RFC] mm: kmemleak: replace __GFP_NOFAIL to GFP_NOWAIT in gfp_kmemleak_mask

On Tue, Apr 24, 2018 at 07:20:57AM -0600, Michal Hocko wrote: > On Mon 23-04-18 12:17:32, Chunyu Hu wrote: > [...] > > So if there is a new flag, it would be the 25th bits. > > No new flags please. Can you simply store a simple bool into fail_page_alloc > and have save/restore api for that? For

Re: [RFC] mm: kmemleak: replace __GFP_NOFAIL to GFP_NOWAIT in gfp_kmemleak_mask

On Tue, Apr 24, 2018 at 07:20:57AM -0600, Michal Hocko wrote: > On Mon 23-04-18 12:17:32, Chunyu Hu wrote: > [...] > > So if there is a new flag, it would be the 25th bits. > > No new flags please. Can you simply store a simple bool into fail_page_alloc > and have save/restore api for that? For

[GIT PULL] arm64 fixes for 4.17-rc2

Hi Linus, Please pull the arm64 fixes below. Thanks. The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338: Linux 4.17-rc1 (2018-04-15 18:24:20 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-fixes

<    7   8   9   10   11   12   13   14   15   16   >