Re: [PATCH 21/35] arm64: mte: Add in-kernel tag fault handler

2020-08-27 Thread Catalin Marinas
On Fri, Aug 14, 2020 at 07:27:03PM +0200, Andrey Konovalov wrote: > diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c > index 5e832b3387f1..c62c8ba85c0e 100644 > --- a/arch/arm64/mm/fault.c > +++ b/arch/arm64/mm/fault.c > @@ -33,6 +33,7 @@ > #include > #include > #include >

Re: [PATCH 20/35] arm64: mte: Add in-kernel MTE helpers

2020-08-27 Thread Catalin Marinas
On Fri, Aug 14, 2020 at 07:27:02PM +0200, Andrey Konovalov wrote: > diff --git a/arch/arm64/include/asm/mte.h b/arch/arm64/include/asm/mte.h > index 1c99fcadb58c..733be1cb5c95 100644 > --- a/arch/arm64/include/asm/mte.h > +++ b/arch/arm64/include/asm/mte.h > @@ -5,14 +5,19 @@ > #ifndef

Re: [PATCH 19/35] kasan: don't allow SW_TAGS with ARM64_MTE

2020-08-27 Thread Catalin Marinas
On Fri, Aug 14, 2020 at 07:27:01PM +0200, Andrey Konovalov wrote: > Software tag-based KASAN provides its own tag checking machinery that > can conflict with MTE. Don't allow enabling software tag-based KASAN > when MTE is enabled. > > Signed-off-by: Andrey Konovalov > --- > lib/Kconfig.kasan |

Re: [mm] c566586818: BUG:kernel_hang_in_early-boot_stage,last_printk:Probing_EDD(edd=off_to_disable)...ok

2020-08-26 Thread Catalin Marinas
On Tue, Aug 25, 2020 at 11:02:40PM -0400, Qian Cai wrote: > On Aug 25, 2020, at 8:44 PM, Rong Chen wrote: > > I rebuilt the kernel on commit c566586818 but the error changed to > > "RIP: 0010:clear_page_orig+0x12/0x40", and the error can be > > reproduced on parent commit: > > Catalin, any

Re: [PATCH v2 05/23] arm64: use asm-generic/mmu_context.h for no-op implementations

2020-08-26 Thread Catalin Marinas
On Thu, Aug 27, 2020 at 12:52:31AM +1000, Nicholas Piggin wrote: > Cc: Catalin Marinas > Cc: Will Deacon > Cc: linux-arm-ker...@lists.infradead.org > Signed-off-by: Nicholas Piggin Acked-by: Catalin Marinas

Re: [PATCH v7 07/12] arm64: inline huge vmap supported functions

2020-08-26 Thread Catalin Marinas
On Wed, Aug 26, 2020 at 12:57:48AM +1000, Nicholas Piggin wrote: > This allows unsupported levels to be constant folded away, and so > p4d_free_pud_page can be removed because it's no longer linked to. > > Cc: Catalin Marinas > Cc: Will Deacon > Cc: linux-arm-ker...@lists.infr

[GIT PULL] arm64 fixes for 5.9-rc2

2020-08-22 Thread Catalin Marinas
Hi Linus, Please pull the arm64 updates below. Thanks. The following changes since commit 9123e3a74ec7b934a4a099e98af6a61c2f80bbf5: Linux 5.9-rc1 (2020-08-16 13:04:57 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-fixes

Re: [PATCH] ARM64: vdso32: Install vdso32 from vdso_install

2020-08-21 Thread Catalin Marinas
On Mon, 17 Aug 2020 18:49:50 -0700, Stephen Boyd wrote: > Add the 32-bit vdso Makefile to the vdso_install rule so that 'make > vdso_install' installs the 32-bit compat vdso when it is compiled. Applied to arm64 (for-next/fixes), thanks! [1/1] ARM64: vdso32: Install vdso32 from vdso_install

Re: [PATCH] mm/kmemleak: rely on rcu for task stack scanning

2020-08-21 Thread Catalin Marinas
t; Signed-off-by: Davidlohr Bueso As long as the kernel thread stack is still around (kmemleak does use try_get_task_stack()), I'm fine with the change: Acked-by: Catalin Marinas

[GIT PULL] arm64 fix for 5.9-rc1

2020-08-11 Thread Catalin Marinas
Hi Linus, Please pull the fix below. Thanks. The following changes since commit eaecca9e7710281be7c31d892c9f447eafd7ddd9: arm64: Fix __cpu_logical_map undefined issue (2020-08-08 19:25:04 +0100) are available in the Git repository at:

Re: [PATCH] recordmcount: Fix build failure on non arm64

2020-08-10 Thread Catalin Marinas
On Mon, 10 Aug 2020 08:48:22 + (UTC), Christophe Leroy wrote: > Commit ea0eada45632 leads to the following build failure on powerpc: > > HOSTCC scripts/recordmcount > scripts/recordmcount.c: In function 'arm64_is_fake_mcount': > scripts/recordmcount.c:440: error: 'R_AARCH64_CALL26'

Re: [PATCH] recordmcount: Fix build failure on non arm64

2020-08-10 Thread Catalin Marinas
On Mon, Aug 10, 2020 at 11:17:30AM +0200, Gregory Herrero wrote: > On Mon, Aug 10, 2020 at 08:48:22AM +, Christophe Leroy wrote: > > Commit ea0eada45632 leads to the following build failure on powerpc: > > > > HOSTCC scripts/recordmcount > > scripts/recordmcount.c: In function

Re: [PATCH -next] arm64: Export __cpu_logical_map

2020-08-10 Thread Catalin Marinas
On Mon, Aug 10, 2020 at 08:49:56AM +0100, Sudeep Holla wrote: > On Sat, Aug 01, 2020 at 05:46:43PM +0530, Sumit Gupta wrote: > > > > > > > ERROR: modpost: "__cpu_logical_map" > > > > > > > [drivers/cpufreq/tegra194-cpufreq.ko] undefined! > > > > > > > > > > > > > > ARM64 tegra194-cpufreq driver

Re: [TEGRA194_CPUFREQ PATCH v6 3/3] cpufreq: Add Tegra194 cpufreq driver

2020-08-09 Thread Catalin Marinas
On Sat, Aug 08, 2020 at 05:40:09PM -0700, Guenter Roeck wrote: > On Wed, Jul 15, 2020 at 07:01:25PM +0530, Sumit Gupta wrote: > > Add support for CPU frequency scaling on Tegra194. The frequency > > of each core can be adjusted by writing a clock divisor value to > > a MSR on the core. The range

[GIT PULL] arm64 fix for 5.9-rc1

2020-08-08 Thread Catalin Marinas
Hi Linus, Please pull the arm64 updates below. The fix addresses a symbol export for the tegra194-cpufreq module that made its way into mainline (the issue was found in -next but still debating an alternative fix without exporting __cpu_logical_map). Thanks. The following changes since commit

Re: [PATCH] fix arm64 build with lack of __cpu_logical_map exported

2020-08-08 Thread Catalin Marinas
On Sat, Aug 08, 2020 at 05:29:58PM +0200, Greg Kroah-Hartman wrote: > On Sat, Aug 08, 2020 at 04:05:00PM +0100, Catalin Marinas wrote: > > On Sat, Aug 08, 2020 at 02:42:42PM +0200, Greg Kroah-Hartman wrote: > > > diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/s

Re: [PATCH] fix arm64 build with lack of __cpu_logical_map exported

2020-08-08 Thread Catalin Marinas
Hi Greg, On Sat, Aug 08, 2020 at 02:42:42PM +0200, Greg Kroah-Hartman wrote: > diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c > index 87e81d29e6fb..b421a4756793 100644 > --- a/arch/arm64/kernel/setup.c > +++ b/arch/arm64/kernel/setup.c > @@ -275,6 +275,7 @@ static int __init

Re: [PATCH v2] arm64: kaslr: Use standard early random function

2020-08-07 Thread Catalin Marinas
On Fri, Aug 07, 2020 at 10:48:36AM -0700, Linus Torvalds wrote: > On Fri, Aug 7, 2020 at 10:35 AM Catalin Marinas > wrote: > > Acked-by: Catalin Marinas > > > > Linus, could you please pick this up directly? Otherwise, it will wait > > until we reach -rc1 to avo

Re: [PATCH v2] arm64: kaslr: Use standard early random function

2020-08-07 Thread Catalin Marinas
ecific functions > to solve the problem. > > Reported-by: Qian Cai > Fixes: 585524081ecd ("random: random.h should include archrandom.h, not the > other way around") > Cc: Qian Cai > Cc: Mark Brown > Reviewed-by: Mark Rutland > Reviewed-by: Mark Brown &

Re: [PATCH] arm64: tlb: fix ARM64_TLB_RANGE with LLVM's integrated assembler

2020-08-06 Thread Catalin Marinas
On Thu, Aug 06, 2020 at 03:17:40PM +0800, Zhenyu Ye wrote: > On 2020/8/6 2:19, Sami Tolvanen wrote: > > Commit 7c78f67e9bd9 ("arm64: enable tlbi range instructions") breaks > > LLVM's integrated assembler, because -Wa,-march is only passed to > > external assemblers and therefore, the new

Re: [PATCH] arm64: tlb: fix ARM64_TLB_RANGE with LLVM's integrated assembler

2020-08-06 Thread Catalin Marinas
On Wed, Aug 05, 2020 at 11:19:20AM -0700, Sami Tolvanen wrote: > diff --git a/arch/arm64/include/asm/tlbflush.h > b/arch/arm64/include/asm/tlbflush.h > index d493174415db..66c2aab5e9cb 100644 > --- a/arch/arm64/include/asm/tlbflush.h > +++ b/arch/arm64/include/asm/tlbflush.h > @@ -16,6 +16,16 @@

Re: [PATCH] arm64: tlb: fix ARM64_TLB_RANGE with LLVM's integrated assembler

2020-08-06 Thread Catalin Marinas
On Wed, Aug 05, 2020 at 12:15:54PM -0700, Nick Desaulniers wrote: > On Wed, Aug 5, 2020 at 11:19 AM Sami Tolvanen wrote: > > > > Commit 7c78f67e9bd9 ("arm64: enable tlbi range instructions") breaks > > LLVM's integrated assembler, because -Wa,-march is only passed to > > external assemblers and

Re: [PATCH v2 3/5] kasan, arm64: don't instrument functions that enable kasan

2020-08-04 Thread Catalin Marinas
s proper tags are > missing in normal shadow. > > Disable KASAN instrumentation for start_kernel(). Also disable it for > arm64's setup_arch() as a precaution (it doesn't have any stack variables > right now). > > Signed-off-by: Andrey Konovalov I thought I acked this already. Either way: Acked-by: Catalin Marinas

[GIT PULL] arm64 and cross-arch updates for 5.9

2020-08-03 Thread Catalin Marinas
SW PAN entry/exit routines Bhupesh Sharma (3): crash_core, vmcoreinfo: Append 'MAX_PHYSMEM_BITS' to vmcoreinfo arm64/crash_core: Export TCR_EL1.T1SZ in vmcoreinfo arm64/defconfig: Enable CONFIG_KEXEC_FILE Catalin Marinas (5): arm64: Shift the __tlbi_level() indentation left arm64

Re: [PATCH 1/1] arm64: use IRQ_STACK_SIZE instead of THREAD_SIZE for irq stack

2020-07-31 Thread Catalin Marinas
On Fri, 31 Jul 2020 17:19:50 +0530, Maninder Singh wrote: > IRQ_STACK_SIZE can be made different from THREAD_SIZE, > and as IRQ_STACK_SIZE is used while irq stack allocation, > same define should be used while printing information of irq stack. Applied to arm64 (for-next/misc), thanks! [1/1]

Re: [PATCH v2 3/7] mm: introduce memfd_secret system call to create "secret" memory areas

2020-07-31 Thread Catalin Marinas
On Fri, Jul 31, 2020 at 03:29:05PM +0100, Mark Rutland wrote: > On Thu, Jul 30, 2020 at 05:22:10PM +0100, Catalin Marinas wrote: > > On Mon, Jul 27, 2020 at 07:29:31PM +0300, Mike Rapoport wrote: > > > +static int secretmem_mmap(struct file *file, struct v

Re: [PATCH 2/4] kasan, arm64: don't instrument functions that enable kasan

2020-07-31 Thread Catalin Marinas
s proper tags are > missing in normal shadow. > > Disable KASAN instrumentation for start_kernel(). Also disable it for > arm64's setup_arch() as a precaution (it doesn't have any stack variables > right now). > > Signed-off-by: Andrey Konovalov For arm64: Acked-by: Catalin Marinas

Re: [PATCH v2 3/7] mm: introduce memfd_secret system call to create "secret" memory areas

2020-07-31 Thread Catalin Marinas
On Thu, Jul 30, 2020 at 11:44:09PM +0300, Mike Rapoport wrote: > On Thu, Jul 30, 2020 at 05:22:10PM +0100, Catalin Marinas wrote: > > On Mon, Jul 27, 2020 at 07:29:31PM +0300, Mike Rapoport wrote: > > > For instance, the following example will create an uncached mapping (er

Re: [PATCH] arm64/alternatives: move length validation inside the subsection

2020-07-31 Thread Catalin Marinas
On Fri, Jul 31, 2020 at 08:49:15AM +0200, Greg Kroah-Hartman wrote: > On Thu, Jul 30, 2020 at 04:23:31PM +0100, Catalin Marinas wrote: > > On Thu, Jul 30, 2020 at 08:13:05AM -0700, Sami Tolvanen wrote: > > > On Thu, Jul 30, 2020 at 5:22 AM Catalin Marinas > > > wrote:

Re: [PATCH v2] arm64/alternatives: move length validation inside the subsection

2020-07-30 Thread Catalin Marinas
\ > + ".org . - (662b-661b) + (664b-663b)\n\t" \ > + ".previous\n" \ > ".endif\n" Acked-by: Catalin Marinas There are a few instances of the .org test outside the subsection, though using in .S files. Are those ok? -- Catalin

Re: [PATCH v2 3/7] mm: introduce memfd_secret system call to create "secret" memory areas

2020-07-30 Thread Catalin Marinas
Hi Mike, On Mon, Jul 27, 2020 at 07:29:31PM +0300, Mike Rapoport wrote: > For instance, the following example will create an uncached mapping (error > handling is omitted): > > fd = memfd_secret(SECRETMEM_UNCACHED); > ftruncate(fd, MAP_SIZE); > ptr = mmap(NULL, MAP_SIZE,

Re: [PATCH] arm64/alternatives: move length validation inside the subsection

2020-07-30 Thread Catalin Marinas
On Thu, Jul 30, 2020 at 08:13:05AM -0700, Sami Tolvanen wrote: > On Thu, Jul 30, 2020 at 5:22 AM Catalin Marinas > wrote: > > > > On Wed, Jul 29, 2020 at 02:51:52PM -0700, Sami Tolvanen wrote: > > > Commit f7b93d42945c ("arm64/alternatives: use subsections

Re: [PATCH] arm64: mm: add message to die() in die_kernel_fault()

2020-07-30 Thread Catalin Marinas
On Thu, Jul 30, 2020 at 07:47:57PM +0800, Yue Hu wrote: > From: Yue Hu > > Just to identify the kernel fault more clearly. > > Signed-off-by: Yue Hu > --- > arch/arm64/mm/fault.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm64/mm/fault.c

Re: [PATCH 0/3] arm64: delete duplicated words

2020-07-30 Thread Catalin Marinas
On Sat, 25 Jul 2020 17:32:04 -0700, Randy Dunlap wrote: > Delete duplicated words in arch/arm64/ header files. > > Cc: Catalin Marinas > Cc: Will Deacon > Cc: linux-arm-ker...@lists.infradead.org > > arch/arm64/include/asm/pgtable-hwdef.h |4 ++-- > arch/ar

Re: [PATCH] arm64/alternatives: move length validation inside the subsection

2020-07-30 Thread Catalin Marinas
On Wed, Jul 29, 2020 at 02:51:52PM -0700, Sami Tolvanen wrote: > Commit f7b93d42945c ("arm64/alternatives: use subsections for replacement > sequences") breaks LLVM's integrated assembler, because due to its > one-pass design, it cannot compute instruction sequence lengths before the > layout for

Re: [PATCH 04/15] arm64: numa: simplify dummy_numa_init()

2020-07-30 Thread Catalin Marinas
span itself, so the loop > over memblock.memory regions is redundant. > > Replace the loop with a single call to memblock_set_node() to the entire > memory. > > Signed-off-by: Mike Rapoport Acked-by: Catalin Marinas

Re: [PATCH v2 6/7] arch_topology,arm,arm64: define arch_scale_freq_invariant()

2020-07-30 Thread Catalin Marinas
q use is not important here. The > invariant status is only given to the system if all CPUs have at least > one method of setting the frequency scale factor. > > Signed-off-by: Valentin Schneider > Signed-off-by: Ionela Voinescu > Cc: Catalin Marinas > Cc: Will Deacon > Cc: Sudeep Holla Acked-by: Catalin Marinas

Re: [PATCH v2 5/7] arch_topology,cpufreq,sched/core: constify arch_* cpumasks

2020-07-30 Thread Catalin Marinas
ct this in the prototype. This also > allows to pass system cpumasks like cpu_online_mask without getting > a warning. > > Signed-off-by: Valentin Schneider > Signed-off-by: Ionela Voinescu > Cc: Catalin Marinas > Cc: Will Deacon > Cc: Sudeep Holla > Cc: Rafael J. W

Re: [PATCH] arm, arm64: Fix selection of CONFIG_SCHED_THERMAL_PRESSURE

2020-07-30 Thread Catalin Marinas
| 1 - > init/Kconfig | 2 ++ > 3 files changed, 2 insertions(+), 2 deletions(-) Acked-by: Catalin Marinas

Re: linux-next: build failure after merge of the origin tree

2020-07-30 Thread Catalin Marinas
#include > #include > -#include > > DECLARE_PER_CPU_READ_MOSTLY(int, cpu_number); I think this arm64 patch makes sense irrespective of any other generic fixes. If Will wants to take it as a fix: Acked-by: Catalin Marinas (otherwise I'll queue it for 5.9)

Re: [PATCH v10 4/5] arm64: kdump: fix kdump broken with ZONE_DMA reintroduced

2020-07-29 Thread Catalin Marinas
On Wed, Jul 29, 2020 at 10:14:32PM +0800, chenzhou wrote: > On 2020/7/29 19:58, Catalin Marinas wrote: > > On Wed, Jul 29, 2020 at 11:52:39AM +0800, chenzhou wrote: > >> How about like this: > >> 1. For ZONE_DMA issue, use Bhupesh's solution, keep the crashkernel= &g

Re: [PATCH v10 4/5] arm64: kdump: fix kdump broken with ZONE_DMA reintroduced

2020-07-29 Thread Catalin Marinas
Hi Chen, On Wed, Jul 29, 2020 at 11:52:39AM +0800, chenzhou wrote: > On 2020/7/28 1:30, Catalin Marinas wrote: > > Anyway, there are two series solving slightly different issues with > > kdump reservations: > > > > 1. This series which relaxes the crashkernel

Re: [PATCH v10 4/5] arm64: kdump: fix kdump broken with ZONE_DMA reintroduced

2020-07-27 Thread Catalin Marinas
On Fri, Jul 03, 2020 at 11:58:15AM +0800, Chen Zhou wrote: > commit 1a8e1cef7603 ("arm64: use both ZONE_DMA and ZONE_DMA32") > broken the arm64 kdump. If the memory reserved for crash dump kernel > falled in ZONE_DMA32, the devices in crash dump kernel need to use > ZONE_DMA will alloc fail. > >

Re: [PATCH 1/6] arm64/vdso: use the fault callback to map vvar pages

2020-07-24 Thread Catalin Marinas
On Wed, 24 Jun 2020 01:33:16 -0700, Andrei Vagin wrote: > Currently the vdso has no awareness of time namespaces, which may > apply distinct offsets to processes in different namespaces. To handle > this within the vdso, we'll need to expose a per-namespace data page. > > As a preparatory step,

Re: [PATCH v5 0/6] arm64: add the time namespace support

2020-07-24 Thread Catalin Marinas
On Fri, Jul 24, 2020 at 03:30:39PM +0200, Christian Brauner wrote: > On Thu, Jul 23, 2020 at 10:41:40AM -0700, Andrei Vagin wrote: > > On Wed, Jul 22, 2020 at 07:15:06PM +0100, Catalin Marinas wrote: > > > On Mon, Jul 13, 2020 at 06:57:43PM -0700, Andrei Vagin wrote: > >

Re: [PATCH] recordmcount: only record relocation of type R_AARCH64_CALL26 on arm64.

2020-07-24 Thread Catalin Marinas
On Fri, 17 Jul 2020 16:33:38 +0200, gregory.herr...@oracle.com wrote: > Currently, if a section has a relocation to '_mcount' symbol, a new > __mcount_loc entry will be added whatever the relocation type is. > This is problematic when a relocation to '_mcount' is in the middle of a > section and

Re: [PATCH v5 0/6] arm64: add the time namespace support

2020-07-24 Thread Catalin Marinas
On Thu, Jul 23, 2020 at 10:25:35PM +0200, Thomas Gleixner wrote: > Andrei Vagin writes: > > On Wed, Jul 22, 2020 at 07:15:06PM +0100, Catalin Marinas wrote: > > > > I don't think that we need to handle this case in the kernel. Users > > must understand what they are d

Re: [PATCH -next] arm64: Export __cpu_logical_map

2020-07-24 Thread Catalin Marinas
On Fri, Jul 24, 2020 at 10:13:52AM +0100, Mark Rutland wrote: > On Fri, Jul 24, 2020 at 01:46:18PM +0530, Anshuman Khandual wrote: > > On 07/24/2020 08:38 AM, Kefeng Wang wrote: > > >> Reported-by: Hulk Robot > > >> Signed-off-by: Kefeng Wang > > >> --- > > >>   arch/arm64/kernel/setup.c | 1 + >

Re: [PATCH -next] arm64: Export __cpu_logical_map

2020-07-24 Thread Catalin Marinas
On Fri, Jul 24, 2020 at 01:46:18PM +0530, Anshuman Khandual wrote: > On 07/24/2020 08:38 AM, Kefeng Wang wrote: > > On 2020/7/24 11:04, Kefeng Wang wrote: > >> ERROR: modpost: "__cpu_logical_map" [drivers/cpufreq/tegra194-cpufreq.ko] > >> undefined! > >> > >> ARM64 tegra194-cpufreq driver use

Re: 答复: 答复: [PATCH] arm64: mm: free unused memmap for sparse memory model that define VMEMMAP

2020-07-23 Thread Catalin Marinas
On Wed, Jul 22, 2020 at 01:40:34PM +, liwei (CM) wrote: > Catalin Marinas wrote: > > On Wed, Jul 22, 2020 at 08:41:17AM +, liwei (CM) wrote: > > > Mike Rapoport wrote: > > > > On Tue, Jul 21, 2020 at 03:32:03PM +0800, Wei Li wrote: > > > >

Re: [RFC] raw_copy_from_user() semantics

2020-07-23 Thread Catalin Marinas
On Thu, Jul 23, 2020 at 08:37:27AM +, David Laight wrote: > From: Catalin Marinas > > Sent: 22 July 2020 17:54 > > On Wed, Jul 22, 2020 at 01:14:21PM +, David Laight wrote: > > > From: Catalin Marinas > > > > Sent: 22 July 2020 12:37 > > > >

Re: [PATCH v5 0/6] arm64: add the time namespace support

2020-07-22 Thread Catalin Marinas
On Mon, Jul 13, 2020 at 06:57:43PM -0700, Andrei Vagin wrote: > On Sat, Jul 04, 2020 at 11:40:55PM -0700, Andrei Vagin wrote: > > On Wed, Jun 24, 2020 at 01:33:15AM -0700, Andrei Vagin wrote: > > > Allocate the time namespace page among VVAR pages and add the logic > > > to handle faults on VVAR

Re: [RFC] raw_copy_from_user() semantics

2020-07-22 Thread Catalin Marinas
On Wed, Jul 22, 2020 at 01:14:21PM +, David Laight wrote: > From: Catalin Marinas > > Sent: 22 July 2020 12:37 > > On Sun, Jul 19, 2020 at 12:34:11PM -0700, Linus Torvalds wrote: > > > On Sun, Jul 19, 2020 at 12:28 PM Linus Torvalds > > > wrote: > &g

Re: [PATCH] recordmcount: only record relocation of type R_AARCH64_CALL26 on arm64.

2020-07-22 Thread Catalin Marinas
On Fri, Jul 17, 2020 at 01:30:03PM -0400, Steven Rostedt wrote: > On Fri, 17 Jul 2020 16:33:38 +0200 > gregory.herr...@oracle.com wrote: > > From: Gregory Herrero > > Currently, if a section has a relocation to '_mcount' symbol, a new > > __mcount_loc entry will be added whatever the relocation

Re: 答复: [PATCH] arm64: mm: free unused memmap for sparse memory model that define VMEMMAP

2020-07-22 Thread Catalin Marinas
On Wed, Jul 22, 2020 at 08:41:17AM +, liwei (CM) wrote: > Mike Rapoport wrote: > > On Tue, Jul 21, 2020 at 03:32:03PM +0800, Wei Li wrote: > > > For the memory hole, sparse memory model that define SPARSEMEM_VMEMMAP > > > do not free the reserved memory for the page map, this patch do it. > >

Re: [RFC] raw_copy_from_user() semantics

2020-07-22 Thread Catalin Marinas
On Sun, Jul 19, 2020 at 12:34:11PM -0700, Linus Torvalds wrote: > On Sun, Jul 19, 2020 at 12:28 PM Linus Torvalds > wrote: > > I think we should try to get rid of the exact semantics. > > Side note: I think one of the historical reasons for the exact > semantics was that we used to do things

Re: [PATCH v3 0/3] arm64: tlb: add support for TLBI RANGE instructions

2020-07-15 Thread Catalin Marinas
On Wed, 15 Jul 2020 15:19:42 +0800, Zhenyu Ye wrote: > NOTICE: this series are based on the arm64 for-next/tlbi branch: > git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-next/tlbi > > ARMv8.4-TLBI provides TLBI invalidation instruction that apply to a > range of input addresses.

Re: [PATCH V3] arm64/hugetlb: Reserve CMA areas for gigantic pages on 16K and 64K configs

2020-07-15 Thread Catalin Marinas
On Wed, 1 Jul 2020 10:12:01 +0530, Anshuman Khandual wrote: > Currently 'hugetlb_cma=' command line argument does not create CMA area on > ARM64_16K_PAGES and ARM64_64K_PAGES based platforms. Instead, it just ends > up with the following warning message. Reason being, hugetlb_cma_reserve() > never

Re: [PATCH v3 2/3] arm64: enable tlbi range instructions

2020-07-15 Thread Catalin Marinas
On Wed, Jul 15, 2020 at 03:19:44PM +0800, Zhenyu Ye wrote: > diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile > index a0d94d063fa8..4e823b97c92e 100644 > --- a/arch/arm64/Makefile > +++ b/arch/arm64/Makefile > @@ -82,11 +82,18 @@ endif > # compiler to generate them and consequently to break

Re: [PATCH 3/3] arm64: Use the new generic copy_oldmem_page()

2020-07-14 Thread Catalin Marinas
On Fri, Jul 10, 2020 at 08:55:44PM -0700, Palmer Dabbelt wrote: > From: Palmer Dabbelt > > This is exactly the same as the arm64 code, which I just into lib/ to > avoid copying it into the RISC-V port. This builds with defconfig. > > Signed-off-by: Palmer Dabbelt Acked-by: Catalin Marinas

Re: [PATCH v2 4/5] arm64: Use the generic devmem_is_allowed()

2020-07-14 Thread Catalin Marinas
t work alone. See the cover > letter for more details.] > > Signed-off-by: Palmer Dabbelt Acked-by: Catalin Marinas

Re: [PATCH v2 0/2] arm64: tlb: add support for TLBI RANGE instructions

2020-07-14 Thread Catalin Marinas
On Tue, Jul 14, 2020 at 11:17:01PM +0800, Zhenyu Ye wrote: > On 2020/7/14 0:59, Catalin Marinas wrote: > >> +config ARM64_TLBI_RANGE > >> + bool "Enable support for tlbi range feature" > >> + default y > >> + depends on AS_HAS_TLBI_RANGE

Re: [PATCH v2 2/2] arm64: tlb: Use the TLBI RANGE feature in arm64

2020-07-14 Thread Catalin Marinas
On Fri, Jul 10, 2020 at 05:44:20PM +0800, Zhenyu Ye wrote: > +#define __TLBI_RANGE_PAGES(num, scale) (((num) + 1) << (5 * (scale) + > 1)) > +#define MAX_TLBI_RANGE_PAGES __TLBI_RANGE_PAGES(31, 3) > + > +#define TLBI_RANGE_MASK GENMASK_ULL(4, 0) > +#define

Re: [PATCH v2 2/2] arm64: tlb: Use the TLBI RANGE feature in arm64

2020-07-13 Thread Catalin Marinas
On Mon, Jul 13, 2020 at 03:44:16PM +0100, Jon Hunter wrote: > On 13/07/2020 15:39, Zhenyu Ye wrote: > > On 2020/7/13 22:27, Jon Hunter wrote: > >> After this change I am seeing the following build errors ... > >> > >> /tmp/cckzq3FT.s: Assembler messages: > >> /tmp/cckzq3FT.s:854: Error: unknown or

Re: [PATCH v2 0/2] arm64: tlb: add support for TLBI RANGE instructions

2020-07-13 Thread Catalin Marinas
On Mon, Jul 13, 2020 at 08:41:31PM +0800, Zhenyu Ye wrote: > On 2020/7/13 20:21, Catalin Marinas wrote: > > On Fri, Jul 10, 2020 at 08:11:19PM +0100, Catalin Marinas wrote: > >> On Fri, 10 Jul 2020 17:44:18 +0800, Zhenyu Ye wrote: > >>> NOTICE: this series are ba

Re: [PATCH v2 0/2] arm64: tlb: add support for TLBI RANGE instructions

2020-07-13 Thread Catalin Marinas
On Fri, Jul 10, 2020 at 08:11:19PM +0100, Catalin Marinas wrote: > On Fri, 10 Jul 2020 17:44:18 +0800, Zhenyu Ye wrote: > > NOTICE: this series are based on the arm64 for-next/tlbi branch: > > git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-next/tlbi > > &g

Re: [PATCH v2 3/3] arm, arm64: Select CONFIG_SCHED_THERMAL_PRESSURE

2020-07-13 Thread Catalin Marinas
TER > select GENERIC_ALLOCATOR > select GENERIC_ARCH_TOPOLOGY > + select SCHED_THERMAL_PRESSURE > select GENERIC_CLOCKEVENTS > select GENERIC_CLOCKEVENTS_BROADCAST > select GENERIC_CPU_AUTOPROBE We tend to keep these in alphabetical order. Otherwise, Acked-by: Catalin Marinas

Re: [PATCH v2 2/2] arm64: tlb: Use the TLBI RANGE feature in arm64

2020-07-12 Thread Catalin Marinas
On Sat, Jul 11, 2020 at 02:50:46PM +0800, Zhenyu Ye wrote: > On 2020/7/11 2:31, Catalin Marinas wrote: > > On Fri, Jul 10, 2020 at 05:44:20PM +0800, Zhenyu Ye wrote: > >> - if ((end - start) >= (MAX_TLBI_OPS * stride)) { > >> + if ((!cpus_have_const_cap(ARM64_HAS_T

Re: [PATCH v2 0/2] arm64: tlb: add support for TLBI RANGE instructions

2020-07-10 Thread Catalin Marinas
On Fri, 10 Jul 2020 17:44:18 +0800, Zhenyu Ye wrote: > NOTICE: this series are based on the arm64 for-next/tlbi branch: > git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-next/tlbi > > -- > ARMv8.4-TLBI provides TLBI invalidation instruction that apply to a > range of input

Re: [PATCH v2 2/2] arm64: tlb: Use the TLBI RANGE feature in arm64

2020-07-10 Thread Catalin Marinas
On Fri, Jul 10, 2020 at 05:44:20PM +0800, Zhenyu Ye wrote: > Add __TLBI_VADDR_RANGE macro and rewrite __flush_tlb_range(). > > When cpu supports TLBI feature, the minimum range granularity is > decided by 'scale', so we can not flush all pages by one instruction > in some cases. > > For example,

Re: [PATCH v1] arm64: tlb: don't set the ttl value in flush_tlb_page_nosync

2020-07-10 Thread Catalin Marinas
On Fri, 10 Jul 2020 17:41:58 +0800, Zhenyu Ye wrote: > flush_tlb_page_nosync() may be called from pmd level, so we > can not set the ttl = 3 here. > > The callstack is as follows: > > pmdp_set_access_flags > ptep_set_access_flags >

Re: [RESEND PATCH v5 3/6] arm64: Add tlbi_user_level TLB invalidation helper

2020-07-10 Thread Catalin Marinas
On Fri, Jul 10, 2020 at 09:20:59AM +0800, Zhenyu Ye wrote: > On 2020/7/10 0:48, Catalin Marinas wrote: > > On Thu, Jun 25, 2020 at 04:03:11PM +0800, Zhenyu Ye wrote: > >> @@ -189,8 +195,9 @@ static inline void flush_tlb_page_nosync(struct > >> vm_area_struct *vma,

Re: [PATCH v1 2/2] arm64: tlb: Use the TLBI RANGE feature in arm64

2020-07-09 Thread Catalin Marinas
On Thu, Jul 09, 2020 at 05:10:54PM +0800, Zhenyu Ye wrote: > Add __TLBI_VADDR_RANGE macro and rewrite __flush_tlb_range(). > > Signed-off-by: Zhenyu Ye > --- > arch/arm64/include/asm/tlbflush.h | 156 -- > 1 file changed, 126 insertions(+), 30 deletions(-) > > diff

Re: [RESEND PATCH v5 3/6] arm64: Add tlbi_user_level TLB invalidation helper

2020-07-09 Thread Catalin Marinas
On Thu, Jun 25, 2020 at 04:03:11PM +0800, Zhenyu Ye wrote: > @@ -189,8 +195,9 @@ static inline void flush_tlb_page_nosync(struct > vm_area_struct *vma, > unsigned long addr = __TLBI_VADDR(uaddr, ASID(vma->vm_mm)); > > dsb(ishst); > - __tlbi(vale1is, addr); > -

Re: [RFC PATCH v5 2/2] arm64: tlb: Use the TLBI RANGE feature in arm64

2020-07-08 Thread Catalin Marinas
On Wed, Jul 08, 2020 at 08:40:31PM +0800, Zhenyu Ye wrote: > Add __TLBI_VADDR_RANGE macro and rewrite __flush_tlb_range(). > > In this patch, we only use the TLBI RANGE feature if the stride == PAGE_SIZE, > because when stride > PAGE_SIZE, usually only a small number of pages need > to be flushed

Re: [RFC PATCH] mm: avoid access flag update TLB flush for retried page fault

2020-07-08 Thread Catalin Marinas
On Wed, Jul 08, 2020 at 09:40:11AM -0700, Yang Shi wrote: > On 7/8/20 1:00 AM, Will Deacon wrote: > > On Wed, Jul 08, 2020 at 02:54:32AM +0800, Yang Shi wrote: > > > Recently we found regression when running will_it_scale/page_fault3 test > > > on ARM64. Over 70% down for the multi processes

Re: [PATCH V4 2/3] mm/sparsemem: Enable vmem_altmap support in vmemmap_alloc_block_buf()

2020-07-08 Thread Catalin Marinas
the header and updates Documentation/vm/memory-model.rst. > > Cc: Jonathan Corbet > Cc: Catalin Marinas > Cc: Will Deacon > Cc: Benjamin Herrenschmidt > Cc: Paul Mackerras > Cc: Michael Ellerman > Cc: Dave Hansen > Cc: Andy Lutomirski > Cc: Peter Zijlstra >

Re: memory leak in inotify_update_watch

2020-07-08 Thread Catalin Marinas
On Tue, Jul 07, 2020 at 05:24:11PM +0200, Jan Kara wrote: > On Mon 06-07-20 08:42:24, syzbot wrote: > > syzbot found the following crash on: > > > > HEAD commit:7cc2a8ea Merge tag 'block-5.8-2020-07-01' of git://git.ker.. > > git tree: upstream > > console output:

Re: memory leak in inotify_update_watch

2020-07-08 Thread Catalin Marinas
On Wed, Jul 08, 2020 at 09:17:37AM +0200, Dmitry Vyukov wrote: > On Tue, Jul 7, 2020 at 8:17 PM Catalin Marinas > wrote: > > Kmemleak never performs well under heavy load. Normally you'd need to > > let the system settle for a bit before checking whether the leaks are

Re: memory leak in inotify_update_watch

2020-07-07 Thread Catalin Marinas
On Tue, Jul 07, 2020 at 05:24:11PM +0200, Jan Kara wrote: > On Mon 06-07-20 08:42:24, syzbot wrote: > > syzbot found the following crash on: > > > > HEAD commit:7cc2a8ea Merge tag 'block-5.8-2020-07-01' of git://git.ker.. > > git tree: upstream > > console output:

Re: [RFC PATCH v4 2/2] arm64: tlb: Use the TLBI RANGE feature in arm64

2020-07-07 Thread Catalin Marinas
On Tue, Jul 07, 2020 at 06:43:35PM +0100, Marc Zyngier wrote: > On 2020-07-07 18:36, Catalin Marinas wrote: > > On Mon, Jun 01, 2020 at 10:47:13PM +0800, Zhenyu Ye wrote: > > > @@ -59,6 +69,47 @@ &g

Re: [RFC V2 1/2] arm64/mm: Change THP helpers per generic memory semantics

2020-07-07 Thread Catalin Marinas
On Mon, Jul 06, 2020 at 09:27:04AM +0530, Anshuman Khandual wrote: > On 07/02/2020 05:41 PM, Catalin Marinas wrote: > > On Mon, Jun 15, 2020 at 06:45:17PM +0530, Anshuman Khandual wrote: > >> --- a/arch/arm64/include/asm/pgtable.h > >> +++ b/arch/arm64/include/asm/pgtabl

Re: [RFC PATCH v4 2/2] arm64: tlb: Use the TLBI RANGE feature in arm64

2020-07-07 Thread Catalin Marinas
On Mon, Jun 01, 2020 at 10:47:13PM +0800, Zhenyu Ye wrote: > @@ -59,6 +69,47 @@ > __ta; \ > }) > > +/* > + * __TG defines translation granule of the system, which is decided by > + * PAGE_SHIFT. Used by TTL. > + * - 4KB: 1 > + *

Re: [PATCH V3] arm64/cpufeature: Validate feature bits spacing in arm64_ftr_regs[]

2020-07-07 Thread Catalin Marinas
On Tue, 7 Jul 2020 19:53:13 +0530, Anshuman Khandual wrote: > arm64_feature_bits for a register in arm64_ftr_regs[] are in a descending > order as per their shift values. Validate that these features bits are > defined correctly and do not overlap with each other. This check protects > against any

Re: [RESEND PATCH v5 0/6] arm64: tlb: add support for TTL feature

2020-07-07 Thread Catalin Marinas
On Thu, 25 Jun 2020 16:03:08 +0800, Zhenyu Ye wrote: > In order to reduce the cost of TLB invalidation, ARMv8.4 provides > the TTL field in TLBI instruction. The TTL field indicates the > level of page table walk holding the leaf entry for the address > being invalidated. This series provide

Re: [PATCH V5 (RESEND) 0/4] arm64/cpufeature: Introduce ID_PFR2, ID_DFR1, ID_MMFR5 and other changes

2020-07-03 Thread Catalin Marinas
gt; This series applies on 5.8-rc3. > > Cc: Catalin Marinas > Cc: Will Deacon > Cc: Mark Rutland > Cc: Marc Zyngier > Cc: James Morse > Cc: Suzuki K Poulose > Cc: kvm...@lists.cs.columbia.edu > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-kernel@vger.kern

Re: [PATCH V5 0/4] arm64/cpufeature: Introduce ID_PFR2, ID_DFR1, ID_MMFR5 and other changes

2020-07-02 Thread Catalin Marinas
nd rework. > > This series applies on arm64/for-next/cpufeature. > > Cc: Catalin Marinas > Cc: Will Deacon > Cc: Mark Rutland > Cc: Marc Zyngier > Cc: James Morse > Cc: Suzuki K Poulose > Cc: kvm...@lists.cs.columbia.edu > Cc: linux-arm-ker...@lists.infradead.org

Re: [PATCH v6 0/2] Append new variables to vmcoreinfo (TCR_EL1.T1SZ for arm64 and MAX_PHYSMEM_BITS for all archs)

2020-07-02 Thread Catalin Marinas
On Thu, 14 May 2020 00:22:35 +0530, Bhupesh Sharma wrote: > Apologies for the delayed update. Its been quite some time since I > posted the last version (v5), but I have been really caught up in some > other critical issues. > > Changes since v5: > > - v5 can be viewed here: >

Re: [PATCH v6 1/2] crash_core, vmcoreinfo: Append 'MAX_PHYSMEM_BITS' to vmcoreinfo

2020-07-02 Thread Catalin Marinas
On Thu, Jul 02, 2020 at 08:08:55PM +0800, Dave Young wrote: > Hi Catalin, > On 07/02/20 at 12:00pm, Catalin Marinas wrote: > > On Thu, May 14, 2020 at 12:22:36AM +0530, Bhupesh Sharma wrote: > > > diff --git a/kernel/crash_core.c b/kernel/crash_core.c > > > index 9f1

Re: [PATCH V3] arm64/panic: Unify all three existing notifier blocks

2020-07-02 Thread Catalin Marinas
On Mon, 29 Jun 2020 10:08:31 +0530, Anshuman Khandual wrote: > Currently there are three different registered panic notifier blocks. This > unifies all of them into a single one i.e arm64_panic_block, hence reducing > code duplication and required calling sequence during panic. This preserves >

Re: [PATCH V3 (RESEND) 3/3] arm64/mm: Enable vmem_altmap support for vmemmap mappings

2020-07-02 Thread Catalin Marinas
ulate() and vmemmap_free() > which includes vmemmap_populate_basepages() used for ARM64_16K_PAGES and > ARM64_64K_PAGES configs. > > Cc: Catalin Marinas > Cc: Will Deacon > Cc: Mark Rutland > Cc: Steve Capper > Cc: David Hildenbrand > Cc: Yu Zhao > Cc: Hsin-Yi

Re: [PATCH V3 (RESEND) 2/3] mm/sparsemem: Enable vmem_altmap support in vmemmap_alloc_block_buf()

2020-07-02 Thread Catalin Marinas
On Thu, Jun 18, 2020 at 06:45:29AM +0530, Anshuman Khandual wrote: > There are many instances where vmemap allocation is often switched between > regular memory and device memory just based on whether altmap is available > or not. vmemmap_alloc_block_buf() is used in various platforms to allocate

Re: [PATCH V3 (RESEND) 1/3] mm/sparsemem: Enable vmem_altmap support in vmemmap_populate_basepages()

2020-07-02 Thread Catalin Marinas
ribing device memory > based base page allocation through vmemmap_populate_basepages(). Hence lets > keep it disabled on all archs in order to preserve the existing semantics. > A subsequent patch enables it on arm64. > > Cc: Catalin Marinas > Cc: Will Deacon > Cc: Mark Rutland >

Re: [RFC V2 1/2] arm64/mm: Change THP helpers per generic memory semantics

2020-07-02 Thread Catalin Marinas
Hi Anshuman, On Mon, Jun 15, 2020 at 06:45:17PM +0530, Anshuman Khandual wrote: > --- a/arch/arm64/include/asm/pgtable.h > +++ b/arch/arm64/include/asm/pgtable.h > @@ -353,15 +353,92 @@ static inline int pmd_protnone(pmd_t pmd) > } > #endif > > +#define pmd_table(pmd) ((pmd_val(pmd) &

Re: [PATCH v2] arm64/module: Optimize module load time by optimizing PLT counting

2020-07-02 Thread Catalin Marinas
On Mon, 22 Jun 2020 18:18:02 -0700, Saravana Kannan wrote: > When loading a module, module_frob_arch_sections() tries to figure out > the number of PLTs that'll be needed to handle all the RELAs. While > doing this, it tries to dedupe PLT allocations for multiple > R_AARCH64_CALL26 relocations to

Re: [PATCH v6 1/2] crash_core, vmcoreinfo: Append 'MAX_PHYSMEM_BITS' to vmcoreinfo

2020-07-02 Thread Catalin Marinas
On Thu, May 14, 2020 at 12:22:36AM +0530, Bhupesh Sharma wrote: > diff --git a/kernel/crash_core.c b/kernel/crash_core.c > index 9f1557b98468..18175687133a 100644 > --- a/kernel/crash_core.c > +++ b/kernel/crash_core.c > @@ -413,6 +413,7 @@ static int __init crash_save_vmcoreinfo_init(void) >

Re: [RFC PATCH 0/2] MTE support for KVM guest

2020-06-24 Thread Catalin Marinas
On Wed, Jun 24, 2020 at 03:59:35PM +0100, Steven Price wrote: > On 24/06/2020 15:21, Catalin Marinas wrote: > > On Wed, Jun 24, 2020 at 12:16:28PM +0100, Steven Price wrote: > > > On 23/06/2020 18:48, Catalin Marinas wrote: > > > > On Wed, Jun 17, 2020 at 01:38:

Re: [RFC PATCH 0/2] MTE support for KVM guest

2020-06-24 Thread Catalin Marinas
On Wed, Jun 24, 2020 at 12:16:28PM +0100, Steven Price wrote: > On 23/06/2020 18:48, Catalin Marinas wrote: > > On Wed, Jun 17, 2020 at 01:38:42PM +0100, Steven Price wrote: > > > These patches add support to KVM to enable MTE within a guest. It is > > > based on Catalin

Re: [RFC PATCH 0/2] MTE support for KVM guest

2020-06-24 Thread Catalin Marinas
On Wed, Jun 24, 2020 at 12:18:46PM +0100, Steven Price wrote: > On 24/06/2020 12:09, Catalin Marinas wrote: > > On Wed, Jun 24, 2020 at 12:03:35PM +0100, Steven Price wrote: > > > On 24/06/2020 11:34, Dave Martin wrote: > > > > On Wed, Jun 24, 2020 at 10:38:48A

Re: [RFC PATCH 0/2] MTE support for KVM guest

2020-06-24 Thread Catalin Marinas
On Wed, Jun 24, 2020 at 12:03:35PM +0100, Steven Price wrote: > On 24/06/2020 11:34, Dave Martin wrote: > > On Wed, Jun 24, 2020 at 10:38:48AM +0100, Catalin Marinas wrote: > > > On Tue, Jun 23, 2020 at 07:05:07PM +0100, Peter Maydell wrote: > > > > On Wed, 17 J

<    1   2   3   4   5   6   7   8   9   10   >