* [PATCH v6 1/2] crash_core, vmcoreinfo: Append 'MAX_PHYSMEM_BITS' to vmcoreinfo
From: Bhupesh Sharma @ 2020-05-13 18:52 UTC (permalink / raw)
To: linux-arm-kernel, x86
Cc: Mark Rutland, Kazuhito Hagio, bhsharma, kexec, linuxppc-dev,
linux-kernel, James Morse, Boris Petkov, Thomas Gleixner,
bhupesh.linux, Will Deacon, Ingo Molnar, Paul Mackerras,
Dave Anderson
In-Reply-To: <1589395957-24628-1-git-send-email-bhsharma@redhat.com>
Right now user-space tools like 'makedumpfile' and 'crash' need to rely
on a best-guess method of determining value of 'MAX_PHYSMEM_BITS'
supported by underlying kernel.
This value is used in user-space code to calculate the bit-space
required to store a section for SPARESMEM (similar to the existing
calculation method used in the kernel implementation):
#define SECTIONS_SHIFT (MAX_PHYSMEM_BITS - SECTION_SIZE_BITS)
Now, regressions have been reported in user-space utilities
like 'makedumpfile' and 'crash' on arm64, with the recently added
kernel support for 52-bit physical address space, as there is
no clear method of determining this value in user-space
(other than reading kernel CONFIG flags).
As per suggestion from makedumpfile maintainer (Kazu), it makes more
sense to append 'MAX_PHYSMEM_BITS' to vmcoreinfo in the core code itself
rather than in arch-specific code, so that the user-space code for other
archs can also benefit from this addition to the vmcoreinfo and use it
as a standard way of determining 'SECTIONS_SHIFT' value in user-land.
A reference 'makedumpfile' implementation which reads the
'MAX_PHYSMEM_BITS' value from vmcoreinfo in a arch-independent fashion
is available here:
While at it also update vmcoreinfo documentation for 'MAX_PHYSMEM_BITS'
variable being added to vmcoreinfo.
'MAX_PHYSMEM_BITS' defines the maximum supported physical address
space memory.
Cc: Boris Petkov <bp@alien8.de>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: James Morse <james.morse@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Dave Anderson <anderson@redhat.com>
Cc: Kazuhito Hagio <k-hagio@ab.jp.nec.com>
Cc: x86@kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: kexec@lists.infradead.org
Tested-by: John Donnelly <john.p.donnelly@oracle.com>
Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
---
Documentation/admin-guide/kdump/vmcoreinfo.rst | 5 +++++
kernel/crash_core.c | 1 +
2 files changed, 6 insertions(+)
diff --git a/Documentation/admin-guide/kdump/vmcoreinfo.rst b/Documentation/admin-guide/kdump/vmcoreinfo.rst
index e4ee8b2db604..2a632020f809 100644
--- a/Documentation/admin-guide/kdump/vmcoreinfo.rst
+++ b/Documentation/admin-guide/kdump/vmcoreinfo.rst
@@ -93,6 +93,11 @@ It exists in the sparse memory mapping model, and it is also somewhat
similar to the mem_map variable, both of them are used to translate an
address.
+MAX_PHYSMEM_BITS
+----------------
+
+Defines the maximum supported physical address space memory.
+
page
----
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)
VMCOREINFO_LENGTH(mem_section, NR_SECTION_ROOTS);
VMCOREINFO_STRUCT_SIZE(mem_section);
VMCOREINFO_OFFSET(mem_section, section_mem_map);
+ VMCOREINFO_NUMBER(MAX_PHYSMEM_BITS);
#endif
VMCOREINFO_STRUCT_SIZE(page);
VMCOREINFO_STRUCT_SIZE(pglist_data);
--
2.7.4
^ permalink raw reply related
* [powerpc:fixes-test] BUILD SUCCESS 249c9b0cd193d983c3a0b00f3fd3b92333bfeebe
From: kbuild test robot @ 2020-05-13 18:32 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git fixes-test
branch HEAD: 249c9b0cd193d983c3a0b00f3fd3b92333bfeebe powerpc/40x: Make more space for system call exception
elapsed time: 585m
configs tested: 144
configs skipped: 10
The following configs have been built successfully.
More configs may be tested in the coming days.
arm defconfig
arm allyesconfig
arm allmodconfig
arm allnoconfig
arm64 allyesconfig
arm64 defconfig
arm64 allmodconfig
arm64 allnoconfig
sparc allyesconfig
m68k allyesconfig
h8300 edosk2674_defconfig
mips decstation_defconfig
sh rsk7201_defconfig
mips rm200_defconfig
riscv nommu_virt_defconfig
mips pistachio_defconfig
xtensa alldefconfig
sh se7722_defconfig
openrisc alldefconfig
arm cerfcube_defconfig
arm assabet_defconfig
sh sdk7786_defconfig
arm hisi_defconfig
arm exynos_defconfig
arm mps2_defconfig
sh ecovec24-romimage_defconfig
arc hsdk_defconfig
arm iop32x_defconfig
riscv allnoconfig
arm moxart_defconfig
sh allmodconfig
sh espt_defconfig
arm xcep_defconfig
microblaze defconfig
arm orion5x_defconfig
sh sh7724_generic_defconfig
m68k amiga_defconfig
arm shmobile_defconfig
powerpc gamecube_defconfig
sh se7343_defconfig
c6x defconfig
sh titan_defconfig
mips capcella_defconfig
arm spear13xx_defconfig
arc nsimosci_defconfig
arm shannon_defconfig
nios2 alldefconfig
arm corgi_defconfig
arm lpc32xx_defconfig
mips loongson3_defconfig
arc axs101_defconfig
mips loongson1c_defconfig
c6x evmc6472_defconfig
um alldefconfig
arm clps711x_defconfig
powerpc adder875_defconfig
parisc generic-64bit_defconfig
arm vexpress_defconfig
i386 allnoconfig
i386 allyesconfig
i386 defconfig
i386 debian-10.3
ia64 allmodconfig
ia64 defconfig
ia64 allnoconfig
ia64 allyesconfig
m68k allmodconfig
m68k allnoconfig
m68k sun3_defconfig
m68k defconfig
nios2 defconfig
nios2 allyesconfig
openrisc defconfig
c6x allyesconfig
c6x allnoconfig
openrisc allyesconfig
nds32 defconfig
nds32 allnoconfig
csky allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
h8300 allmodconfig
xtensa defconfig
arc defconfig
arc allyesconfig
sh allnoconfig
microblaze allnoconfig
mips allyesconfig
mips allnoconfig
mips allmodconfig
parisc allnoconfig
parisc defconfig
parisc allyesconfig
parisc allmodconfig
powerpc defconfig
powerpc allyesconfig
powerpc rhel-kconfig
powerpc allmodconfig
powerpc allnoconfig
x86_64 randconfig-a005-20200513
x86_64 randconfig-a003-20200513
x86_64 randconfig-a006-20200513
x86_64 randconfig-a004-20200513
x86_64 randconfig-a001-20200513
x86_64 randconfig-a002-20200513
i386 randconfig-a006-20200513
i386 randconfig-a005-20200513
i386 randconfig-a003-20200513
i386 randconfig-a001-20200513
i386 randconfig-a004-20200513
i386 randconfig-a002-20200513
i386 randconfig-a012-20200513
i386 randconfig-a016-20200513
i386 randconfig-a014-20200513
i386 randconfig-a011-20200513
i386 randconfig-a013-20200513
i386 randconfig-a015-20200513
riscv allyesconfig
riscv defconfig
riscv allmodconfig
s390 allyesconfig
s390 allnoconfig
s390 allmodconfig
s390 defconfig
x86_64 defconfig
sparc defconfig
sparc64 defconfig
sparc64 allnoconfig
sparc64 allyesconfig
sparc64 allmodconfig
um allmodconfig
um allnoconfig
um allyesconfig
um defconfig
x86_64 rhel
x86_64 rhel-7.6
x86_64 rhel-7.6-kselftests
x86_64 rhel-7.2-clear
x86_64 lkp
x86_64 fedora-25
x86_64 kexec
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [powerpc:next-test] BUILD SUCCESS 9aaaca63114c41ad857bb9889732c0827a1689af
From: kbuild test robot @ 2020-05-13 18:33 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next-test
branch HEAD: 9aaaca63114c41ad857bb9889732c0827a1689af powerpc/ps3: Fix kexec shutdown hang
elapsed time: 582m
configs tested: 121
configs skipped: 6
The following configs have been built successfully.
More configs may be tested in the coming days.
arm defconfig
arm allyesconfig
arm allmodconfig
arm allnoconfig
arm64 allyesconfig
arm64 defconfig
arm64 allmodconfig
arm64 allnoconfig
m68k allyesconfig
sparc allyesconfig
mips rm200_defconfig
riscv nommu_virt_defconfig
mips pistachio_defconfig
xtensa alldefconfig
sh se7722_defconfig
openrisc alldefconfig
arm cerfcube_defconfig
arm assabet_defconfig
sh ecovec24-romimage_defconfig
arc hsdk_defconfig
arm iop32x_defconfig
riscv allnoconfig
c6x defconfig
sh titan_defconfig
mips capcella_defconfig
arm spear13xx_defconfig
arc nsimosci_defconfig
arm shannon_defconfig
nios2 alldefconfig
arm corgi_defconfig
arm lpc32xx_defconfig
mips loongson3_defconfig
arc axs101_defconfig
mips loongson1c_defconfig
c6x evmc6472_defconfig
um alldefconfig
arm clps711x_defconfig
powerpc adder875_defconfig
parisc generic-64bit_defconfig
arm vexpress_defconfig
i386 allnoconfig
i386 allyesconfig
i386 defconfig
i386 debian-10.3
ia64 allmodconfig
ia64 defconfig
ia64 allnoconfig
ia64 allyesconfig
m68k allmodconfig
m68k allnoconfig
m68k sun3_defconfig
m68k defconfig
nios2 defconfig
nios2 allyesconfig
openrisc defconfig
c6x allyesconfig
c6x allnoconfig
openrisc allyesconfig
nds32 defconfig
nds32 allnoconfig
csky allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
h8300 allmodconfig
xtensa defconfig
arc defconfig
arc allyesconfig
sh allmodconfig
sh allnoconfig
microblaze allnoconfig
mips allyesconfig
mips allnoconfig
mips allmodconfig
parisc allnoconfig
parisc defconfig
parisc allyesconfig
parisc allmodconfig
powerpc defconfig
powerpc allyesconfig
powerpc rhel-kconfig
powerpc allmodconfig
powerpc allnoconfig
x86_64 randconfig-a005-20200513
x86_64 randconfig-a003-20200513
x86_64 randconfig-a006-20200513
x86_64 randconfig-a004-20200513
x86_64 randconfig-a001-20200513
x86_64 randconfig-a002-20200513
i386 randconfig-a004-20200513
i386 randconfig-a006-20200513
i386 randconfig-a005-20200513
i386 randconfig-a003-20200513
i386 randconfig-a001-20200513
i386 randconfig-a002-20200513
riscv allyesconfig
riscv defconfig
riscv allmodconfig
s390 allyesconfig
s390 allnoconfig
s390 allmodconfig
s390 defconfig
x86_64 defconfig
sparc defconfig
sparc64 defconfig
sparc64 allnoconfig
sparc64 allyesconfig
sparc64 allmodconfig
um allmodconfig
um allnoconfig
um allyesconfig
um defconfig
x86_64 rhel
x86_64 rhel-7.6
x86_64 rhel-7.6-kselftests
x86_64 rhel-7.2-clear
x86_64 lkp
x86_64 fedora-25
x86_64 kexec
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [powerpc:merge] BUILD SUCCESS 93369d50dc0f266ee67adcc6053c96700236d8be
From: kbuild test robot @ 2020-05-13 18:32 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git merge
branch HEAD: 93369d50dc0f266ee67adcc6053c96700236d8be Automatic merge of 'master', 'next' and 'fixes' (2020-05-13 18:37)
elapsed time: 584m
configs tested: 127
configs skipped: 6
The following configs have been built successfully.
More configs may be tested in the coming days.
arm defconfig
arm allyesconfig
arm allmodconfig
arm allnoconfig
arm64 allyesconfig
arm64 defconfig
arm64 allmodconfig
arm64 allnoconfig
m68k allyesconfig
sparc allyesconfig
mips rm200_defconfig
riscv nommu_virt_defconfig
mips pistachio_defconfig
xtensa alldefconfig
sh se7722_defconfig
openrisc alldefconfig
arm cerfcube_defconfig
arm assabet_defconfig
sh ecovec24-romimage_defconfig
arc hsdk_defconfig
arm iop32x_defconfig
riscv allnoconfig
c6x defconfig
sh titan_defconfig
mips capcella_defconfig
arm spear13xx_defconfig
arc nsimosci_defconfig
arm shannon_defconfig
nios2 alldefconfig
arm corgi_defconfig
arm lpc32xx_defconfig
mips loongson3_defconfig
arc axs101_defconfig
mips loongson1c_defconfig
c6x evmc6472_defconfig
um alldefconfig
arm clps711x_defconfig
powerpc adder875_defconfig
parisc generic-64bit_defconfig
arm vexpress_defconfig
i386 allnoconfig
i386 allyesconfig
i386 defconfig
i386 debian-10.3
ia64 allmodconfig
ia64 defconfig
ia64 allnoconfig
ia64 allyesconfig
m68k allmodconfig
m68k allnoconfig
m68k sun3_defconfig
m68k defconfig
nios2 defconfig
nios2 allyesconfig
openrisc defconfig
c6x allyesconfig
c6x allnoconfig
openrisc allyesconfig
nds32 defconfig
nds32 allnoconfig
csky allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
h8300 allmodconfig
xtensa defconfig
arc defconfig
arc allyesconfig
sh allmodconfig
sh allnoconfig
microblaze allnoconfig
mips allyesconfig
mips allnoconfig
mips allmodconfig
parisc allnoconfig
parisc defconfig
parisc allyesconfig
parisc allmodconfig
powerpc defconfig
powerpc allyesconfig
powerpc rhel-kconfig
powerpc allmodconfig
powerpc allnoconfig
x86_64 randconfig-a005-20200513
x86_64 randconfig-a003-20200513
x86_64 randconfig-a006-20200513
x86_64 randconfig-a004-20200513
x86_64 randconfig-a001-20200513
x86_64 randconfig-a002-20200513
i386 randconfig-a006-20200513
i386 randconfig-a005-20200513
i386 randconfig-a003-20200513
i386 randconfig-a001-20200513
i386 randconfig-a004-20200513
i386 randconfig-a002-20200513
i386 randconfig-a012-20200513
i386 randconfig-a016-20200513
i386 randconfig-a014-20200513
i386 randconfig-a011-20200513
i386 randconfig-a013-20200513
i386 randconfig-a015-20200513
riscv allyesconfig
riscv defconfig
riscv allmodconfig
s390 allyesconfig
s390 allnoconfig
s390 allmodconfig
s390 defconfig
x86_64 defconfig
sparc defconfig
sparc64 defconfig
sparc64 allnoconfig
sparc64 allyesconfig
sparc64 allmodconfig
um allmodconfig
um allnoconfig
um allyesconfig
um defconfig
x86_64 rhel
x86_64 rhel-7.6
x86_64 rhel-7.6-kselftests
x86_64 rhel-7.2-clear
x86_64 lkp
x86_64 fedora-25
x86_64 kexec
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: [PATCH 12/15] md: stop using ->queuedata
From: Christoph Hellwig @ 2020-05-13 18:33 UTC (permalink / raw)
To: Song Liu
Cc: Jens Axboe, linux-xtensa, linux-raid, Sergey Senozhatsky,
linux-nvdimm, Geoff Levand, open list, Jim Paris, Joshua Morris,
linux-block, Minchan Kim, linux-m68k, Philip Kelleher,
linux-bcache, linuxppc-dev, Christoph Hellwig, Nitin Gupta,
drbd-dev
In-Reply-To: <CAPhsuW6_Y53_XLFeVxhTDpTi_PKNLqqnrXLn+M2fJW268eE6_w@mail.gmail.com>
On Wed, May 13, 2020 at 11:29:17AM -0700, Song Liu wrote:
> On Fri, May 8, 2020 at 9:17 AM Christoph Hellwig <hch@lst.de> wrote:
> >
> > Signed-off-by: Christoph Hellwig <hch@lst.de>
>
> Thanks for the cleanup. IIUC, you want this go through md tree?
Yes, please pick it up though the md tree.
^ permalink raw reply
* Re: [PATCH v2 3/5] libnvdimm/nvdimm/flush: Allow architecture to override the flush barrier
From: Dan Williams @ 2020-05-13 16:14 UTC (permalink / raw)
To: Aneesh Kumar K.V
Cc: Oliver O'Halloran, linuxppc-dev, alistair, linux-nvdimm
In-Reply-To: <20200513034705.172983-3-aneesh.kumar@linux.ibm.com>
On Tue, May 12, 2020 at 8:47 PM Aneesh Kumar K.V
<aneesh.kumar@linux.ibm.com> wrote:
>
> Architectures like ppc64 provide persistent memory specific barriers
> that will ensure that all stores for which the modifications are
> written to persistent storage by preceding dcbfps and dcbstps
> instructions have updated persistent storage before any data
> access or data transfer caused by subsequent instructions is initiated.
> This is in addition to the ordering done by wmb()
>
> Update nvdimm core such that architecture can use barriers other than
> wmb to ensure all previous writes are architecturally visible for
> the platform buffer flush.
This seems like an exceedingly bad idea, maybe I'm missing something.
This implies that the deployed base of DAX applications using the old
instruction sequence are going to regress on new hardware that
requires the new instructions to be deployed. I'm thinking the kernel
should go as far as to disable DAX operation by default on new
hardware until userspace asserts that it is prepared to switch to the
new implementation. Is there any other way to ensure the forward
compatibility of deployed ppc64 DAX applications?
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> ---
> drivers/nvdimm/region_devs.c | 8 ++++----
> include/linux/libnvdimm.h | 4 ++++
> 2 files changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/nvdimm/region_devs.c b/drivers/nvdimm/region_devs.c
> index ccbb5b43b8b2..88ea34a9c7fd 100644
> --- a/drivers/nvdimm/region_devs.c
> +++ b/drivers/nvdimm/region_devs.c
> @@ -1216,13 +1216,13 @@ int generic_nvdimm_flush(struct nd_region *nd_region)
> idx = this_cpu_add_return(flush_idx, hash_32(current->pid + idx, 8));
>
> /*
> - * The first wmb() is needed to 'sfence' all previous writes
> - * such that they are architecturally visible for the platform
> - * buffer flush. Note that we've already arranged for pmem
> + * The first arch_pmem_flush_barrier() is needed to 'sfence' all
> + * previous writes such that they are architecturally visible for
> + * the platform buffer flush. Note that we've already arranged for pmem
> * writes to avoid the cache via memcpy_flushcache(). The final
> * wmb() ensures ordering for the NVDIMM flush write.
> */
> - wmb();
> + arch_pmem_flush_barrier();
> for (i = 0; i < nd_region->ndr_mappings; i++)
> if (ndrd_get_flush_wpq(ndrd, i, 0))
> writeq(1, ndrd_get_flush_wpq(ndrd, i, idx));
> diff --git a/include/linux/libnvdimm.h b/include/linux/libnvdimm.h
> index 18da4059be09..66f6c65bd789 100644
> --- a/include/linux/libnvdimm.h
> +++ b/include/linux/libnvdimm.h
> @@ -286,4 +286,8 @@ static inline void arch_invalidate_pmem(void *addr, size_t size)
> }
> #endif
>
> +#ifndef arch_pmem_flush_barrier
> +#define arch_pmem_flush_barrier() wmb()
> +#endif
> +
> #endif /* __LIBNVDIMM_H__ */
> --
> 2.26.2
>
^ permalink raw reply
* Re: [PATCH v8 16/30] powerpc: Define and use __get_user_instr{, inatomic}()
From: Michael Ellerman @ 2020-05-13 14:18 UTC (permalink / raw)
To: Jordan Niethe, linuxppc-dev
Cc: christophe.leroy, alistair, npiggin, bala24, Jordan Niethe,
naveen.n.rao, dja
In-Reply-To: <20200506034050.24806-17-jniethe5@gmail.com>
Jordan Niethe <jniethe5@gmail.com> writes:
> Define specific __get_user_instr() and __get_user_instr_inatomic()
> macros for reading instructions from user space.
At least for fix_alignment() we could be coming from the kernel, not
sure about the other cases.
I can tweak the change log.
> diff --git a/arch/powerpc/include/asm/uaccess.h b/arch/powerpc/include/asm/uaccess.h
> index 2f500debae21..c0a35e4586a5 100644
> --- a/arch/powerpc/include/asm/uaccess.h
> +++ b/arch/powerpc/include/asm/uaccess.h
> @@ -105,6 +105,11 @@ static inline int __access_ok(unsigned long addr, unsigned long size,
> #define __put_user_inatomic(x, ptr) \
> __put_user_nosleep((__typeof__(*(ptr)))(x), (ptr), sizeof(*(ptr)))
>
> +#define __get_user_instr(x, ptr) \
> + __get_user_nocheck((x).val, (u32 *)(ptr), sizeof(u32), true)
> +
> +#define __get_user_instr_inatomic(x, ptr) \
> + __get_user_nosleep((x).val, (u32 *)(ptr), sizeof(u32))
I'm not super keen on adding new __ versions, which lack the access_ok()
check, but I guess we have to.
> diff --git a/arch/powerpc/kernel/vecemu.c b/arch/powerpc/kernel/vecemu.c
> index 3dd70eeb10c5..60ed5aea8d4e 100644
> --- a/arch/powerpc/kernel/vecemu.c
> +++ b/arch/powerpc/kernel/vecemu.c
> @@ -266,7 +266,7 @@ int emulate_altivec(struct pt_regs *regs)
> unsigned int va, vb, vc, vd;
> vector128 *vrs;
>
> - if (get_user(instr.val, (unsigned int __user *)regs->nip))
> + if (__get_user_instr(instr, (void __user *)regs->nip))
> return -EFAULT;
That drops the access_ok() check, which is not OK, at least without a
reasonable justification.
Given it's regs->nip I guess it should be safe, but it should still be
called out. Or preferably switched to __get_user() in a precursor patch.
cheers
^ permalink raw reply
* [PATCH] powerpc/xive: silence kmemleak false positives
From: Qian Cai @ 2020-05-13 13:40 UTC (permalink / raw)
To: mpe; +Cc: linux-kernel, Qian Cai, catalin.marinas, paulus, linuxppc-dev
opal_xive_donate_page() will reference the newly allocated memory using
__pa(). Since kmemleak is unable to track the physical memory resulting
in false positives, silence those by using kmemleak_ignore().
unreferenced object 0xc000201b53e90000 (size 65536):
comm "qemu-kvm", pid 124557, jiffies 4295650285 (age 364.370s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<00000000acc2fb77>] xive_native_alloc_vp_block+0x168/0x210
xive_native_provision_pages at arch/powerpc/sysdev/xive/native.c:645
(inlined by) xive_native_alloc_vp_block at arch/powerpc/sysdev/xive/native.c:674
[<000000004d5c7964>] kvmppc_xive_compute_vp_id+0x20c/0x3b0 [kvm]
[<0000000055317cd2>] kvmppc_xive_connect_vcpu+0xa4/0x4a0 [kvm]
[<0000000093dfc014>] kvm_arch_vcpu_ioctl+0x388/0x508 [kvm]
[<00000000d25aea0f>] kvm_vcpu_ioctl+0x15c/0x950 [kvm]
[<0000000048155cd6>] ksys_ioctl+0xd8/0x130
[<0000000041ffeaa7>] sys_ioctl+0x28/0x40
[<000000004afc4310>] system_call_exception+0x114/0x1e0
[<00000000fb70a873>] system_call_common+0xf0/0x278
Signed-off-by: Qian Cai <cai@lca.pw>
---
arch/powerpc/sysdev/xive/native.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/powerpc/sysdev/xive/native.c b/arch/powerpc/sysdev/xive/native.c
index 5218fdc4b29a..2d19f28967a6 100644
--- a/arch/powerpc/sysdev/xive/native.c
+++ b/arch/powerpc/sysdev/xive/native.c
@@ -18,6 +18,7 @@
#include <linux/delay.h>
#include <linux/cpumask.h>
#include <linux/mm.h>
+#include <linux/kmemleak.h>
#include <asm/machdep.h>
#include <asm/prom.h>
@@ -647,6 +648,9 @@ static bool xive_native_provision_pages(void)
pr_err("Failed to allocate provisioning page\n");
return false;
}
+ /* Kmemleak is unable to track the physical address. */
+ kmemleak_ignore(p);
+
opal_xive_donate_page(chip, __pa(p));
}
return true;
--
2.21.0 (Apple Git-122.2)
^ permalink raw reply related
* [PATCH] powerpc/kvm/radix: ignore kmemleak false positives
From: Qian Cai @ 2020-05-13 13:39 UTC (permalink / raw)
To: paulus, mpe
Cc: linux-kernel, kvm-ppc, Qian Cai, catalin.marinas, linuxppc-dev
kvmppc_pmd_alloc() and kvmppc_pte_alloc() allocate some memory but then
pud_populate() and pmd_populate() will use __pa() to reference the newly
allocated memory.
Since kmemleak is unable to track the physical memory resulting in false
positives, silence those by using kmemleak_ignore().
unreferenced object 0xc000201c382a1000 (size 4096):
comm "qemu-kvm", pid 124828, jiffies 4295733767 (age 341.250s)
hex dump (first 32 bytes):
c0 00 20 09 f4 60 03 87 c0 00 20 10 72 a0 03 87 .. ..`.... .r...
c0 00 20 0e 13 a0 03 87 c0 00 20 1b dc c0 03 87 .. ....... .....
backtrace:
[<000000004cc2790f>] kvmppc_create_pte+0x838/0xd20 [kvm_hv]
kvmppc_pmd_alloc at arch/powerpc/kvm/book3s_64_mmu_radix.c:366
(inlined by) kvmppc_create_pte at arch/powerpc/kvm/book3s_64_mmu_radix.c:590
[<00000000d123c49a>] kvmppc_book3s_instantiate_page+0x2e0/0x8c0 [kvm_hv]
[<00000000bb549087>] kvmppc_book3s_radix_page_fault+0x1b4/0x2b0 [kvm_hv]
[<0000000086dddc0e>] kvmppc_book3s_hv_page_fault+0x214/0x12a0 [kvm_hv]
[<000000005ae9ccc2>] kvmppc_vcpu_run_hv+0xc5c/0x15f0 [kvm_hv]
[<00000000d22162ff>] kvmppc_vcpu_run+0x34/0x48 [kvm]
[<00000000d6953bc4>] kvm_arch_vcpu_ioctl_run+0x314/0x420 [kvm]
[<000000002543dd54>] kvm_vcpu_ioctl+0x33c/0x950 [kvm]
[<0000000048155cd6>] ksys_ioctl+0xd8/0x130
[<0000000041ffeaa7>] sys_ioctl+0x28/0x40
[<000000004afc4310>] system_call_exception+0x114/0x1e0
[<00000000fb70a873>] system_call_common+0xf0/0x278
unreferenced object 0xc0002001f0c03900 (size 256):
comm "qemu-kvm", pid 124830, jiffies 4295735235 (age 326.570s)
hex dump (first 32 bytes):
c0 00 20 10 fa a0 03 87 c0 00 20 10 fa a1 03 87 .. ....... .....
c0 00 20 10 fa a2 03 87 c0 00 20 10 fa a3 03 87 .. ....... .....
backtrace:
[<0000000023f675b8>] kvmppc_create_pte+0x854/0xd20 [kvm_hv]
kvmppc_pte_alloc at arch/powerpc/kvm/book3s_64_mmu_radix.c:356
(inlined by) kvmppc_create_pte at arch/powerpc/kvm/book3s_64_mmu_radix.c:593
[<00000000d123c49a>] kvmppc_book3s_instantiate_page+0x2e0/0x8c0 [kvm_hv]
[<00000000bb549087>] kvmppc_book3s_radix_page_fault+0x1b4/0x2b0 [kvm_hv]
[<0000000086dddc0e>] kvmppc_book3s_hv_page_fault+0x214/0x12a0 [kvm_hv]
[<000000005ae9ccc2>] kvmppc_vcpu_run_hv+0xc5c/0x15f0 [kvm_hv]
[<00000000d22162ff>] kvmppc_vcpu_run+0x34/0x48 [kvm]
[<00000000d6953bc4>] kvm_arch_vcpu_ioctl_run+0x314/0x420 [kvm]
[<000000002543dd54>] kvm_vcpu_ioctl+0x33c/0x950 [kvm]
[<0000000048155cd6>] ksys_ioctl+0xd8/0x130
[<0000000041ffeaa7>] sys_ioctl+0x28/0x40
[<000000004afc4310>] system_call_exception+0x114/0x1e0
[<00000000fb70a873>] system_call_common+0xf0/0x278
Signed-off-by: Qian Cai <cai@lca.pw>
---
arch/powerpc/kvm/book3s_64_mmu_radix.c | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_64_mmu_radix.c b/arch/powerpc/kvm/book3s_64_mmu_radix.c
index aa12cd4078b3..bc6c1aa3d0e9 100644
--- a/arch/powerpc/kvm/book3s_64_mmu_radix.c
+++ b/arch/powerpc/kvm/book3s_64_mmu_radix.c
@@ -353,7 +353,13 @@ static struct kmem_cache *kvm_pmd_cache;
static pte_t *kvmppc_pte_alloc(void)
{
- return kmem_cache_alloc(kvm_pte_cache, GFP_KERNEL);
+ pte_t *pte;
+
+ pte = kmem_cache_alloc(kvm_pte_cache, GFP_KERNEL);
+ /* pmd_populate() will only reference _pa(pte). */
+ kmemleak_ignore(pte);
+
+ return pte;
}
static void kvmppc_pte_free(pte_t *ptep)
@@ -363,7 +369,13 @@ static void kvmppc_pte_free(pte_t *ptep)
static pmd_t *kvmppc_pmd_alloc(void)
{
- return kmem_cache_alloc(kvm_pmd_cache, GFP_KERNEL);
+ pmd_t *pmd;
+
+ pmd = kmem_cache_alloc(kvm_pmd_cache, GFP_KERNEL);
+ /* pud_populate() will only reference _pa(pmd). */
+ kmemleak_ignore(pmd);
+
+ return pmd;
}
static void kvmppc_pmd_free(pmd_t *pmdp)
--
2.21.0 (Apple Git-122.2)
^ permalink raw reply related
* Re: [PATCH v8 13/30] powerpc: Add a probe_user_read_inst() function
From: Michael Ellerman @ 2020-05-13 12:52 UTC (permalink / raw)
To: Jordan Niethe, linuxppc-dev
Cc: christophe.leroy, alistair, npiggin, bala24, Jordan Niethe,
naveen.n.rao, dja
In-Reply-To: <20200506034050.24806-14-jniethe5@gmail.com>
Jordan Niethe <jniethe5@gmail.com> writes:
> diff --git a/arch/powerpc/lib/inst.c b/arch/powerpc/lib/inst.c
> new file mode 100644
> index 000000000000..eaf786afad2b
> --- /dev/null
> +++ b/arch/powerpc/lib/inst.c
> @@ -0,0 +1,18 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright 2020, IBM Corporation.
> + */
> +
> +#include <linux/uaccess.h>
> +#include <asm/inst.h>
> +
> +int probe_user_read_inst(struct ppc_inst *inst,
> + struct ppc_inst *nip)
> +{
> + unsigned int val;
> + int err;
> +
> + err = probe_user_read(&val, nip, sizeof(val));
> + *inst = ppc_inst(val);
We shouldn't be storing to *inst if the read failed?
I changed it to:
+ if (!err)
+ *inst = ppc_inst(val);
+
Similarly for probe_kernel_read_inst().
cheers
^ permalink raw reply
* Re: [PATCH v3] powerpc/uaccess: evaluate macro arguments once, before user access is allowed
From: Michael Ellerman @ 2020-05-13 12:43 UTC (permalink / raw)
To: linuxppc-dev, Nicholas Piggin
In-Reply-To: <20200407041245.600651-1-npiggin@gmail.com>
On Tue, 7 Apr 2020 14:12:45 +1000, Nicholas Piggin wrote:
> get/put_user can be called with nontrivial arguments. fs/proc/page.c
> has a good example:
>
> if (put_user(stable_page_flags(ppage), out)) {
>
> stable_page_flags is quite a lot of code, including spin locks in the
> page allocator.
>
> [...]
Applied to powerpc/fixes.
[1/1] powerpc/uaccess: Evaluate macro arguments once, before user access is allowed
https://git.kernel.org/powerpc/c/d02f6b7dab8228487268298ea1f21081c0b4b3eb
cheers
^ permalink raw reply
* Re: [PATCH 0/6] assorted kuap fixes
From: Michael Ellerman @ 2020-05-13 12:43 UTC (permalink / raw)
To: linuxppc-dev, Nicholas Piggin
In-Reply-To: <20200429062607.1675792-1-npiggin@gmail.com>
On Wed, 29 Apr 2020 16:26:00 +1000, Nicholas Piggin wrote:
> Here's a bunch of fixes I collected, and some that Aneesh needs for
> his kuap on hash series.
>
> Nicholas Piggin (6):
> powerpc/64/kuap: move kuap checks out of MSR[RI]=0 regions of exit
> code
> missing isync
> powerpc/64/kuap: interrupt exit kuap restore add missing isync,
> conditionally restore AMR
> rpc/64/kuap: restore AMR in system reset exception
> powerpc/64/kuap: restore AMR in fast_interrupt_return
> powerpc/64/kuap: conditionally restore AMR in kuap_restore_amr asm
>
> [...]
Patches 1, 4 and 5 applied to powerpc/fixes.
[1/6] powerpc/64/kuap: Move kuap checks out of MSR[RI]=0 regions of exit code
https://git.kernel.org/powerpc/c/c0d7dcf89e5151b2259d1c2c1b922da3b881d02e
[4/6] powerpc/64s/kuap: Restore AMR in system reset exception
https://git.kernel.org/powerpc/c/53459dc9709db2141d784702abbd43e8fcac8e6d
[5/6] powerpc/64s/kuap: Restore AMR in fast_interrupt_return
https://git.kernel.org/powerpc/c/c44dc6323cd49d8d742c37e234b952e822c35de4
cheers
^ permalink raw reply
* Re: [PATCH v2] powerpc/ima: fix secure boot rules in ima arch policy
From: Michael Ellerman @ 2020-05-13 12:43 UTC (permalink / raw)
To: Nayna Jain, linuxppc-dev, linux-integrity; +Cc: linux-kernel, Mimi Zohar
In-Reply-To: <1588342612-14532-1-git-send-email-nayna@linux.ibm.com>
On Fri, 1 May 2020 10:16:52 -0400, Nayna Jain wrote:
> To prevent verifying the kernel module appended signature twice
> (finit_module), once by the module_sig_check() and again by IMA, powerpc
> secure boot rules define an IMA architecture specific policy rule
> only if CONFIG_MODULE_SIG_FORCE is not enabled. This, unfortunately, does
> not take into account the ability of enabling "sig_enforce" on the boot
> command line (module.sig_enforce=1).
>
> [...]
Applied to powerpc/fixes.
[1/1] powerpc/ima: Fix secure boot rules in ima arch policy
https://git.kernel.org/powerpc/c/fa4f3f56ccd28ac031ab275e673ed4098855fed4
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/64s: Fix unrecoverable SLB crashes due to preemption check
From: Michael Ellerman @ 2020-05-13 12:43 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev; +Cc: hughd, npiggin
In-Reply-To: <20200502143316.929341-1-mpe@ellerman.id.au>
On Sun, 3 May 2020 00:33:16 +1000, Michael Ellerman wrote:
> Hugh reported that his trusty G5 crashed after a few hours under load
> with an "Unrecoverable exception 380".
>
> The crash is in interrupt_return() where we check lazy_irq_pending(),
> which calls get_paca() and with CONFIG_DEBUG_PREEMPT=y that goes to
> check_preemption_disabled() via debug_smp_processor_id().
>
> [...]
Applied to powerpc/fixes.
[1/1] powerpc/64s: Fix unrecoverable SLB crashes due to preemption check
https://git.kernel.org/powerpc/c/0094368e3bb97a710ce163f9c06d290c1c308621
cheers
^ permalink raw reply
* Re: [PATCH fixes] powerpc/vdso32: Fallback on getres syscall when clock is unknown
From: Michael Ellerman @ 2020-05-13 12:43 UTC (permalink / raw)
To: Aurelien Jarno, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras, Christophe Leroy
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <7316a9e2c0c2517923eb4b0411c4a08d15e675a4.1589017281.git.christophe.leroy@csgroup.eu>
On Sat, 9 May 2020 09:42:14 +0000 (UTC), Christophe Leroy wrote:
> There are other clocks than the standard ones, for instance
> per process clocks. Therefore, being above the last standard clock
> doesn't mean it is a bad clock. So, fallback to syscall instead
> of returning -EINVAL inconditionaly.
Applied to powerpc/fixes.
[1/1] powerpc/vdso32: Fallback on getres syscall when clock is unknown
https://git.kernel.org/powerpc/c/e963b7a28b2bf2416304e1a15df967fcf662aff5
cheers
^ permalink raw reply
* Re: [PATCH fixes] powerpc/40x: Make more space for system call exception
From: Michael Ellerman @ 2020-05-13 12:43 UTC (permalink / raw)
To: Michael Ellerman, Christophe Leroy, Paul Mackerras,
Benjamin Herrenschmidt
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <633165d72f75b4ef4c0901aebe99d3915c93e9a2.1589043863.git.christophe.leroy@csgroup.eu>
On Sat, 9 May 2020 17:05:11 +0000 (UTC), Christophe Leroy wrote:
> When CONFIG_VIRT_CPU_ACCOUNTING is selected, system call exception
> handler doesn't fit below 0xd00 and build fails.
>
> As exception 0xd00 doesn't exist and is never generated by 40x,
> comment it out in order to get more space for system call exception.
Applied to powerpc/fixes.
[1/1] powerpc/40x: Make more space for system call exception
https://git.kernel.org/powerpc/c/249c9b0cd193d983c3a0b00f3fd3b92333bfeebe
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/32s: Fix build failure with CONFIG_PPC_KUAP_DEBUG
From: Michael Ellerman @ 2020-05-13 12:43 UTC (permalink / raw)
To: Michael Ellerman, Christophe Leroy, Paul Mackerras,
Benjamin Herrenschmidt
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <ea599546f2a7771bde551393889e44e6b2632332.1587368807.git.christophe.leroy@c-s.fr>
On Mon, 20 Apr 2020 07:47:05 +0000 (UTC), Christophe Leroy wrote:
> gpr2 is not a parametre of kuap_check(), it doesn't exist.
>
> Use gpr instead.
Applied to powerpc/fixes.
[1/1] powerpc/32s: Fix build failure with CONFIG_PPC_KUAP_DEBUG
https://git.kernel.org/powerpc/c/4833ce06e6855d526234618b746ffb71d6612c9a
cheers
^ permalink raw reply
* Re: [PATCH 06/12] m68k/mm: move {cache,nocahe}_page() definitions close to their user
From: Greg Ungerer @ 2020-05-13 11:19 UTC (permalink / raw)
To: Mike Rapoport, linux-kernel
Cc: Rich Felker, linux-ia64, linux-sh, Catalin Marinas,
Heiko Carstens, Max Filippov, Guo Ren, linux-csky, sparclinux,
linux-hexagon, linux-riscv, Vincent Chen, Will Deacon,
Thomas Gleixner, linux-arch, linux-s390, linux-c6x-dev,
Brian Cain, Helge Deller, x86, Russell King, Ley Foon Tan,
Mike Rapoport, Ingo Molnar, Geert Uytterhoeven, linux-parisc,
Mark Salter, Matt Turner, linux-snps-arc, linux-xtensa,
Arnd Bergmann, linux-alpha, linux-um, linux-m68k, Tony Luck,
Borislav Petkov, Greentime Hu, Paul Walmsley, Stafford Horne,
Guan Xuetao, linux-arm-kernel, Chris Zankel, Michal Simek,
Thomas Bogendoerfer, Yoshinori Sato, Nick Hu, linux-mm,
Vineet Gupta, linux-mips, openrisc, Richard Weinberger,
Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <20200512184422.12418-7-rppt@kernel.org>
Hi Mike,
On 13/5/20 4:44 am, Mike Rapoport wrote:
> From: Mike Rapoport <rppt@linux.ibm.com>
>
> The cache_page() and nocache_page() functions are only used by the morotola
^^^^^^^^
motorola
> MMU variant for setting caching attributes for the page table pages.
>
> Move the definitions of these functions from
> arch/m68k/include/asm/motorola_pgtable.h closer to their usage in
> arch/m68k/mm/motorola.c and drop unused definition in
> arch/m68k/include/asm/mcf_pgtable.h.
>
> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
Acked-by: Greg Ungerer <gerg@linux-m68k.org>
Regards
Greg
> ---
> arch/m68k/include/asm/mcf_pgtable.h | 40 ---------------------
> arch/m68k/include/asm/motorola_pgtable.h | 44 ------------------------
> arch/m68k/mm/motorola.c | 43 +++++++++++++++++++++++
> 3 files changed, 43 insertions(+), 84 deletions(-)
>
> diff --git a/arch/m68k/include/asm/mcf_pgtable.h b/arch/m68k/include/asm/mcf_pgtable.h
> index 0031cd387b75..737e826294f3 100644
> --- a/arch/m68k/include/asm/mcf_pgtable.h
> +++ b/arch/m68k/include/asm/mcf_pgtable.h
> @@ -328,46 +328,6 @@ extern pgd_t kernel_pg_dir[PTRS_PER_PGD];
> #define pte_offset_kernel(dir, address) \
> ((pte_t *) __pmd_page(*(dir)) + __pte_offset(address))
>
> -/*
> - * Disable caching for page at given kernel virtual address.
> - */
> -static inline void nocache_page(void *vaddr)
> -{
> - pgd_t *dir;
> - p4d_t *p4dp;
> - pud_t *pudp;
> - pmd_t *pmdp;
> - pte_t *ptep;
> - unsigned long addr = (unsigned long) vaddr;
> -
> - dir = pgd_offset_k(addr);
> - p4dp = p4d_offset(dir, addr);
> - pudp = pud_offset(p4dp, addr);
> - pmdp = pmd_offset(pudp, addr);
> - ptep = pte_offset_kernel(pmdp, addr);
> - *ptep = pte_mknocache(*ptep);
> -}
> -
> -/*
> - * Enable caching for page at given kernel virtual address.
> - */
> -static inline void cache_page(void *vaddr)
> -{
> - pgd_t *dir;
> - p4d_t *p4dp;
> - pud_t *pudp;
> - pmd_t *pmdp;
> - pte_t *ptep;
> - unsigned long addr = (unsigned long) vaddr;
> -
> - dir = pgd_offset_k(addr);
> - p4dp = p4d_offset(dir, addr);
> - pudp = pud_offset(p4dp, addr);
> - pmdp = pmd_offset(pudp, addr);
> - ptep = pte_offset_kernel(pmdp, addr);
> - *ptep = pte_mkcache(*ptep);
> -}
> -
> /*
> * Encode and de-code a swap entry (must be !pte_none(e) && !pte_present(e))
> */
> diff --git a/arch/m68k/include/asm/motorola_pgtable.h b/arch/m68k/include/asm/motorola_pgtable.h
> index 9e5a3de21e15..e1594acf7c7e 100644
> --- a/arch/m68k/include/asm/motorola_pgtable.h
> +++ b/arch/m68k/include/asm/motorola_pgtable.h
> @@ -227,50 +227,6 @@ static inline pte_t *pte_offset_kernel(pmd_t *pmdp, unsigned long address)
> #define pte_offset_map(pmdp,address) ((pte_t *)__pmd_page(*pmdp) + (((address) >> PAGE_SHIFT) & (PTRS_PER_PTE - 1)))
> #define pte_unmap(pte) ((void)0)
>
> -/* Prior to calling these routines, the page should have been flushed
> - * from both the cache and ATC, or the CPU might not notice that the
> - * cache setting for the page has been changed. -jskov
> - */
> -static inline void nocache_page(void *vaddr)
> -{
> - unsigned long addr = (unsigned long)vaddr;
> -
> - if (CPU_IS_040_OR_060) {
> - pgd_t *dir;
> - p4d_t *p4dp;
> - pud_t *pudp;
> - pmd_t *pmdp;
> - pte_t *ptep;
> -
> - dir = pgd_offset_k(addr);
> - p4dp = p4d_offset(dir, addr);
> - pudp = pud_offset(p4dp, addr);
> - pmdp = pmd_offset(pudp, addr);
> - ptep = pte_offset_kernel(pmdp, addr);
> - *ptep = pte_mknocache(*ptep);
> - }
> -}
> -
> -static inline void cache_page(void *vaddr)
> -{
> - unsigned long addr = (unsigned long)vaddr;
> -
> - if (CPU_IS_040_OR_060) {
> - pgd_t *dir;
> - p4d_t *p4dp;
> - pud_t *pudp;
> - pmd_t *pmdp;
> - pte_t *ptep;
> -
> - dir = pgd_offset_k(addr);
> - p4dp = p4d_offset(dir, addr);
> - pudp = pud_offset(p4dp, addr);
> - pmdp = pmd_offset(pudp, addr);
> - ptep = pte_offset_kernel(pmdp, addr);
> - *ptep = pte_mkcache(*ptep);
> - }
> -}
> -
> /* Encode and de-code a swap entry (must be !pte_none(e) && !pte_present(e)) */
> #define __swp_type(x) (((x).val >> 4) & 0xff)
> #define __swp_offset(x) ((x).val >> 12)
> diff --git a/arch/m68k/mm/motorola.c b/arch/m68k/mm/motorola.c
> index 904c2a663977..8e5e74121a78 100644
> --- a/arch/m68k/mm/motorola.c
> +++ b/arch/m68k/mm/motorola.c
> @@ -45,6 +45,49 @@ unsigned long mm_cachebits;
> EXPORT_SYMBOL(mm_cachebits);
> #endif
>
> +/* Prior to calling these routines, the page should have been flushed
> + * from both the cache and ATC, or the CPU might not notice that the
> + * cache setting for the page has been changed. -jskov
> + */
> +static inline void nocache_page(void *vaddr)
> +{
> + unsigned long addr = (unsigned long)vaddr;
> +
> + if (CPU_IS_040_OR_060) {
> + pgd_t *dir;
> + p4d_t *p4dp;
> + pud_t *pudp;
> + pmd_t *pmdp;
> + pte_t *ptep;
> +
> + dir = pgd_offset_k(addr);
> + p4dp = p4d_offset(dir, addr);
> + pudp = pud_offset(p4dp, addr);
> + pmdp = pmd_offset(pudp, addr);
> + ptep = pte_offset_kernel(pmdp, addr);
> + *ptep = pte_mknocache(*ptep);
> + }
> +}
> +
> +static inline void cache_page(void *vaddr)
> +{
> + unsigned long addr = (unsigned long)vaddr;
> +
> + if (CPU_IS_040_OR_060) {
> + pgd_t *dir;
> + p4d_t *p4dp;
> + pud_t *pudp;
> + pmd_t *pmdp;
> + pte_t *ptep;
> +
> + dir = pgd_offset_k(addr);
> + p4dp = p4d_offset(dir, addr);
> + pudp = pud_offset(p4dp, addr);
> + pmdp = pmd_offset(pudp, addr);
> + ptep = pte_offset_kernel(pmdp, addr);
> + *ptep = pte_mkcache(*ptep);
> + }
> +}
>
> /*
> * Motorola 680x0 user's manual recommends using uncached memory for address
>
^ permalink raw reply
* Re: [PATCH v4 01/22] powerpc/pkeys: Avoid using lockless page table walk
From: Michael Ellerman @ 2020-05-13 8:49 UTC (permalink / raw)
To: Aneesh Kumar K.V, linuxppc-dev; +Cc: Aneesh Kumar K.V, Ram Pai, npiggin
In-Reply-To: <20200505071729.54912-2-aneesh.kumar@linux.ibm.com>
On Tue, 2020-05-05 at 07:17:08 UTC, "Aneesh Kumar K.V" wrote:
> Fetch pkey from vma instead of linux page table. Also document the fact that in
> some cases the pkey returned in siginfo won't be the same as the one we took
> keyfault on. Even with linux page table walk, we can end up in a similar scenario.
>
> Cc: Ram Pai <linuxram@linux.ibm.com>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/fe4a6856cb4f4353a6cb8d3629bcfe9204e3d57d
cheers
^ permalink raw reply
* Re: [PATCH v4 3/3] mm/page_alloc: Keep memoryless cpuless node 0 offline
From: Srikar Dronamraju @ 2020-05-13 7:46 UTC (permalink / raw)
To: Christopher Lameter
Cc: Gautham R Shenoy, Michal Hocko, David Hildenbrand, Linus Torvalds,
linux-kernel, linux-mm, Satheesh Rajendran, Mel Gorman,
Kirill A. Shutemov, Andrew Morton, linuxppc-dev, Vlastimil Babka
In-Reply-To: <alpine.DEB.2.22.394.2005121627340.98180@www.lameter.com>
* Christopher Lameter <cl@linux.com> [2020-05-12 16:31:26]:
> On Tue, 12 May 2020, Srikar Dronamraju wrote:
>
> > +#ifdef CONFIG_NUMA
> > + [N_ONLINE] = NODE_MASK_NONE,
>
> Again. Same issue as before. If you do this then you do a global change
> for all architectures. You need to put something in the early boot
> sequence (in a non architecture specific way) that sets the first node
> online by default.
>
I did respond to that earlier.
> You have fixed the issue in your earlier patches for the powerpc
> archicture. What about the other architectures?
>
> Or did I miss something?
>
Here are my assumptions, please do correct me if any of them are wrong.
1. My other patches for Powerpc, don't change when the nodes are being
onlined. They only change how the cpu_to_node numbering of the offline cpus.
In this respect Powerpc due to its PAPR compliance may be slightly unique
from other archs where the cpu binding of the node is not known till CPUs
are onlined.
2. Currently the nodes are onlined (in all arch specific code) as soon as
they are detected. This is unconditional onlining as in there are no checks
to see the node number is 0. i.e I don't see any special checks that
restrict or allow node 0 from being onlined / offlined. Its considered no
special than any other online node.
3. If we were to expect node 0 to be always online, then why do we have
first_online_node. We could always hard code it to 0.
4. I tried enabling CONFIG_MEMORYLESS_NODE on x86, but that's seems to be
not possible. And it looks to me that something like that is only possible
on powerpc and IA64.
5. Without my patch on a regular numa system, node 0 would be onlined by
default during structure initialization. When the nodes get detected, node 0
and other nodes would again be onlined. The only drawback being if node 0
wasn't suppose to be online, it will still end up being marked online.
With the proposed patch, when the nodes get detected, any nodes detected
would be onlined.
I think the node onlining is already pretty early in boot. I don't know of
any other mechanism to move the onlining further up and in a non
architecture specific way. However if you have ideas, please do let me know.
--
Thanks and Regards
Srikar Dronamraju
^ permalink raw reply
* Re: powerpc/pci: [PATCH 1/1]: PCIE PHB reset
From: Sam Bobroff @ 2020-05-13 7:23 UTC (permalink / raw)
To: wenxiong; +Cc: brking, oohall, linuxppc-dev, wenxiong
In-Reply-To: <1588857037-25950-1-git-send-email-wenxiong@linux.vnet.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 6544 bytes --]
On Thu, May 07, 2020 at 08:10:37AM -0500, wenxiong@linux.vnet.ibm.com wrote:
> From: Wen Xiong <wenxiong@linux.vnet.ibm.com>
>
> Several device drivers hit EEH(Extended Error handling) when triggering
> kdump on Pseries PowerVM. This patch implemented a reset of the PHBs
> in pci general code. PHB reset stop all PCI transactions from previous
> kernel. We have tested the patch in several enviroments:
> - direct slot adapters
> - adapters under the switch
> - a VF adapter in PowerVM
> - a VF adapter/adapter in KVM guest.
>
> Signed-off-by: Wen Xiong <wenxiong@linux.vnet.ibm.com>
One other thing:
I tested the patch and this line is logged for each emulated PHB:
[ 3.337057] pseries_get_pdn_addr: Failed to get address for PHB#0-PE# option=1 config_addr=0
And it's not really an error -- QEMU's emulated PHBs don't have EEH
support.
It's not a big deal, because there are other similar messages already
present but it would probably be better if this were suppressed for the
case where there's no support.
Cheers,
Sam.
> ---
> arch/powerpc/platforms/pseries/pci.c | 153 +++++++++++++++++++++++++++
> 1 file changed, 153 insertions(+)
>
> diff --git a/arch/powerpc/platforms/pseries/pci.c b/arch/powerpc/platforms/pseries/pci.c
> index 911534b89c85..aac7f00696d2 100644
> --- a/arch/powerpc/platforms/pseries/pci.c
> +++ b/arch/powerpc/platforms/pseries/pci.c
> @@ -11,6 +11,8 @@
> #include <linux/kernel.h>
> #include <linux/pci.h>
> #include <linux/string.h>
> +#include <linux/crash_dump.h>
> +#include <linux/delay.h>
>
> #include <asm/eeh.h>
> #include <asm/pci-bridge.h>
> @@ -354,3 +356,154 @@ int pseries_root_bridge_prepare(struct pci_host_bridge *bridge)
>
> return 0;
> }
> +
> +/**
> + * pseries_get_pdn_addr - Retrieve PHB address
> + * @pe: EEH PE
> + *
> + * Retrieve the assocated PHB address. Actually, there're 2 RTAS
> + * function calls dedicated for the purpose. We need implement
> + * it through the new function and then the old one. Besides,
> + * you should make sure the config address is figured out from
> + * FDT node before calling the function.
> + *
> + */
> +static int pseries_get_pdn_addr(struct pci_controller *phb)
> +{
> + int ret = -1;
> + int rets[3];
> + int ibm_get_config_addr_info;
> + int ibm_get_config_addr_info2;
> + int config_addr = 0;
> + struct pci_dn *root_pdn, *pdn;
> +
> + ibm_get_config_addr_info2 = rtas_token("ibm,get-config-addr-info2");
> + ibm_get_config_addr_info = rtas_token("ibm,get-config-addr-info");
> +
> + root_pdn = PCI_DN(phb->dn);
> + pdn = list_first_entry(&root_pdn->child_list, struct pci_dn, list);
> + config_addr = (pdn->busno << 16) | (pdn->devfn << 8);
> +
> + if (ibm_get_config_addr_info2 != RTAS_UNKNOWN_SERVICE) {
> + /*
> + * First of all, we need to make sure there has one PE
> + * associated with the device. Otherwise, PE address is
> + * meaningless.
> + */
> + ret = rtas_call(ibm_get_config_addr_info2, 4, 2, rets,
> + config_addr, BUID_HI(pdn->phb->buid),
> + BUID_LO(pdn->phb->buid), 1);
> + if (ret || (rets[0] == 0)) {
> + pr_warn("%s: Failed to get address for PHB#%x-PE# "
> + "option=%d config_addr=%x\n",
> + __func__, pdn->phb->global_number, 1, rets[0]);
> + return -1;
> + }
> +
> + /* Retrieve the associated PE config address */
> + ret = rtas_call(ibm_get_config_addr_info2, 4, 2, rets,
> + config_addr, BUID_HI(pdn->phb->buid),
> + BUID_LO(pdn->phb->buid), 0);
> + if (ret) {
> + pr_warn("%s: Failed to get address for PHB#%x-PE# "
> + "option=%d config_addr=%x\n",
> + __func__, pdn->phb->global_number, 0, rets[0]);
> + return -1;
> + }
> + return rets[0];
> + }
> +
> + if (ibm_get_config_addr_info != RTAS_UNKNOWN_SERVICE) {
> + ret = rtas_call(ibm_get_config_addr_info, 4, 2, rets,
> + config_addr, BUID_HI(pdn->phb->buid),
> + BUID_LO(pdn->phb->buid), 0);
> + if (ret || rets[0]) {
> + pr_warn("%s: Failed to get address for PHB#%x-PE# "
> + "config_addr=%x\n",
> + __func__, pdn->phb->global_number, rets[0]);
> + return -1;
> + }
> + return rets[0];
> + }
> +
> + return ret;
> +}
> +
> +static int __init pseries_phb_reset(void)
> +{
> + struct pci_controller *phb;
> + int config_addr;
> + int ibm_set_slot_reset;
> + int ibm_configure_pe;
> + int ret;
> +
> + if (is_kdump_kernel() || reset_devices) {
> + pr_info("Issue PHB reset ...\n");
> + ibm_set_slot_reset = rtas_token("ibm,set-slot-reset");
> + ibm_configure_pe = rtas_token("ibm,configure-pe");
> +
> + if (ibm_set_slot_reset == RTAS_UNKNOWN_SERVICE ||
> + ibm_configure_pe == RTAS_UNKNOWN_SERVICE) {
> + pr_info("%s: EEH functionality not supported\n",
> + __func__);
> + }
> +
> + list_for_each_entry(phb, &hose_list, list_node) {
> + config_addr = pseries_get_pdn_addr(phb);
> + if (config_addr == -1)
> + continue;
> +
> + ret = rtas_call(ibm_set_slot_reset, 4, 1, NULL,
> + config_addr, BUID_HI(phb->buid),
> + BUID_LO(phb->buid), EEH_RESET_FUNDAMENTAL);
> +
> + /* If fundamental-reset not supported, try hot-reset */
> + if (ret == -8)
> + ret = rtas_call(ibm_set_slot_reset, 4, 1, NULL,
> + config_addr, BUID_HI(phb->buid),
> + BUID_LO(phb->buid), EEH_RESET_HOT);
> +
> + if (ret) {
> + pr_err("%s: fail with rtas_call fundamental reset=%d\n",
> + __func__, ret);
> + continue;
> + }
> + }
> + msleep(EEH_PE_RST_SETTLE_TIME);
> +
> + list_for_each_entry(phb, &hose_list, list_node) {
> + config_addr = pseries_get_pdn_addr(phb);
> + if (config_addr == -1)
> + continue;
> +
> + ret = rtas_call(ibm_set_slot_reset, 4, 1, NULL,
> + config_addr, BUID_HI(phb->buid),
> + BUID_LO(phb->buid), EEH_RESET_DEACTIVATE);
> + if (ret) {
> + pr_err("%s: fail with rtas_call deactive=%d\n",
> + __func__, ret);
> + continue;
> + }
> + }
> + msleep(EEH_PE_RST_SETTLE_TIME);
> +
> + list_for_each_entry(phb, &hose_list, list_node) {
> + config_addr = pseries_get_pdn_addr(phb);
> + if (config_addr == -1)
> + continue;
> +
> + ret = rtas_call(ibm_configure_pe, 3, 1, NULL,
> + config_addr, BUID_HI(phb->buid),
> + BUID_LO(phb->buid));
> + if (ret) {
> + pr_err("%s: fail with rtas_call configure_pe =%d\n",
> + __func__, ret);
> + continue;
> + }
> + }
> + }
> +
> + return 0;
> +}
> +postcore_initcall(pseries_phb_reset);
> +
> --
> 2.18.1
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] tty: hvc: Fix data abort due to race in hvc_open
From: Greg KH @ 2020-05-13 7:04 UTC (permalink / raw)
To: rananta; +Cc: linuxppc-dev, andrew, Jiri Slaby, linux-kernel
In-Reply-To: <417b1d320bda37410788430979dd708d@codeaurora.org>
On Tue, May 12, 2020 at 02:39:50PM -0700, rananta@codeaurora.org wrote:
> On 2020-05-12 01:25, Greg KH wrote:
> > On Tue, May 12, 2020 at 09:22:15AM +0200, Jiri Slaby wrote:
> > > On 11. 05. 20, 9:39, Greg KH wrote:
> > > > On Mon, May 11, 2020 at 12:23:58AM -0700, rananta@codeaurora.org wrote:
> > > >> On 2020-05-09 23:48, Greg KH wrote:
> > > >>> On Sat, May 09, 2020 at 06:30:56PM -0700, rananta@codeaurora.org wrote:
> > > >>>> On 2020-05-06 02:48, Greg KH wrote:
> > > >>>>> On Mon, Apr 27, 2020 at 08:26:01PM -0700, Raghavendra Rao Ananta wrote:
> > > >>>>>> Potentially, hvc_open() can be called in parallel when two tasks calls
> > > >>>>>> open() on /dev/hvcX. In such a scenario, if the
> > > >>>>>> hp->ops->notifier_add()
> > > >>>>>> callback in the function fails, where it sets the tty->driver_data to
> > > >>>>>> NULL, the parallel hvc_open() can see this NULL and cause a memory
> > > >>>>>> abort.
> > > >>>>>> Hence, serialize hvc_open and check if tty->private_data is NULL
> > > >>>>>> before
> > > >>>>>> proceeding ahead.
> > > >>>>>>
> > > >>>>>> The issue can be easily reproduced by launching two tasks
> > > >>>>>> simultaneously
> > > >>>>>> that does nothing but open() and close() on /dev/hvcX.
> > > >>>>>> For example:
> > > >>>>>> $ ./simple_open_close /dev/hvc0 & ./simple_open_close /dev/hvc0 &
> > > >>>>>>
> > > >>>>>> Signed-off-by: Raghavendra Rao Ananta <rananta@codeaurora.org>
> > > >>>>>> ---
> > > >>>>>> drivers/tty/hvc/hvc_console.c | 16 ++++++++++++++--
> > > >>>>>> 1 file changed, 14 insertions(+), 2 deletions(-)
> > > >>>>>>
> > > >>>>>> diff --git a/drivers/tty/hvc/hvc_console.c
> > > >>>>>> b/drivers/tty/hvc/hvc_console.c
> > > >>>>>> index 436cc51c92c3..ebe26fe5ac09 100644
> > > >>>>>> --- a/drivers/tty/hvc/hvc_console.c
> > > >>>>>> +++ b/drivers/tty/hvc/hvc_console.c
> > > >>>>>> @@ -75,6 +75,8 @@ static LIST_HEAD(hvc_structs);
> > > >>>>>> */
> > > >>>>>> static DEFINE_MUTEX(hvc_structs_mutex);
> > > >>>>>>
> > > >>>>>> +/* Mutex to serialize hvc_open */
> > > >>>>>> +static DEFINE_MUTEX(hvc_open_mutex);
> > > >>>>>> /*
> > > >>>>>> * This value is used to assign a tty->index value to a hvc_struct
> > > >>>>>> based
> > > >>>>>> * upon order of exposure via hvc_probe(), when we can not match it
> > > >>>>>> to
> > > >>>>>> @@ -346,16 +348,24 @@ static int hvc_install(struct tty_driver
> > > >>>>>> *driver, struct tty_struct *tty)
> > > >>>>>> */
> > > >>>>>> static int hvc_open(struct tty_struct *tty, struct file * filp)
> > > >>>>>> {
> > > >>>>>> - struct hvc_struct *hp = tty->driver_data;
> > > >>>>>> + struct hvc_struct *hp;
> > > >>>>>> unsigned long flags;
> > > >>>>>> int rc = 0;
> > > >>>>>>
> > > >>>>>> + mutex_lock(&hvc_open_mutex);
> > > >>>>>> +
> > > >>>>>> + hp = tty->driver_data;
> > > >>>>>> + if (!hp) {
> > > >>>>>> + rc = -EIO;
> > > >>>>>> + goto out;
> > > >>>>>> + }
> > > >>>>>> +
> > > >>>>>> spin_lock_irqsave(&hp->port.lock, flags);
> > > >>>>>> /* Check and then increment for fast path open. */
> > > >>>>>> if (hp->port.count++ > 0) {
> > > >>>>>> spin_unlock_irqrestore(&hp->port.lock, flags);
> > > >>>>>> hvc_kick();
> > > >>>>>> - return 0;
> > > >>>>>> + goto out;
> > > >>>>>> } /* else count == 0 */
> > > >>>>>> spin_unlock_irqrestore(&hp->port.lock, flags);
> > > >>>>>
> > > >>>>> Wait, why isn't this driver just calling tty_port_open() instead of
> > > >>>>> trying to open-code all of this?
> > > >>>>>
> > > >>>>> Keeping a single mutext for open will not protect it from close, it will
> > > >>>>> just slow things down a bit. There should already be a tty lock held by
> > > >>>>> the tty core for open() to keep it from racing things, right?
> > > >>>> The tty lock should have been held, but not likely across
> > > >>>> ->install() and
> > > >>>> ->open() callbacks, thus resulting in a race between hvc_install() and
> > > >>>> hvc_open(),
> > > >>>
> > > >>> How? The tty lock is held in install, and should not conflict with
> > > >>> open(), otherwise, we would be seeing this happen in all tty drivers,
> > > >>> right?
> > > >>>
> > > >> Well, I was expecting the same, but IIRC, I see that the open() was being
> > > >> called in parallel for the same device node.
> > > >
> > > > So open and install are happening at the same time? And the tty_lock()
> > > > does not protect the needed fields from being protected properly? If
> > > > not, what fields are being touched without the lock?
> > > >
> > > >> Is it expected that the tty core would allow only one thread to
> > > >> access the dev-node, while blocking the other, or is it the client
> > > >> driver's responsibility to handle the exclusiveness?
> > > >
> > > > The tty core should handle this correctly, for things that can mess
> > > > stuff up (like install and open at the same time). A driver should not
> > > > have to worry about that.
> > > >
> > > >>>> where hvc_install() sets a data and the hvc_open() clears it.
> > > >>>> hvc_open()
> > > >>>> doesn't
> > > >>>> check if the data was set to NULL and proceeds.
> > > >>>
> > > >>> What data is being set that hvc_open is checking?
> > > >> hvc_install sets tty->private_data to hp, while hvc_open sets it to NULL (in
> > > >> one of the paths).
> > > >
> > > > I see no use of private_data in drivers/tty/hvc/ so what exactly are you
> > > > referring to?
> > >
> > > He likely means tty->driver_data. And there exactly lays the issue.
> > >
> > > commit bdb498c20040616e94b05c31a0ceb3e134b7e829
> > > Author: Jiri Slaby <jslaby@suse.cz>
> > > Date: Tue Aug 7 21:48:04 2012 +0200
> > >
> > > TTY: hvc_console, add tty install
> > >
> > > added hvc_install but did not move 'tty->driver_data = NULL;' from
> > > hvc_open's fail path to hvc_cleanup.
> > >
> > > IOW hvc_open now NULLs tty->driver_data even for another task which
> > > opened the tty earlier. The same holds for
> > > "tty_port_tty_set(&hp->port,
> > > NULL);" there. And actually "tty_port_put(&hp->port);" is also
> > > incorrect
> > > for the 2nd task opening the tty.
> > >
> > > So, a mutex with tty->driver_data check in open is not definitely the
> > > way to go. This mess needs to be sorted out properly. Sure, a good
> > > start
> > > would be a conversion to tty_port_open. Right after dropping "tty:
> > > hvc:
> > > Fix data abort due to race in hvc_open" from tty/tty-next :).
> >
> > I've now reverted this commit so we can start from a "clean" place.
> >
> > > What I *don't* understand is why hp->ops->notifier_add fails, given
> > > the
> > > open does not allow multiple opens anyway?
> >
> > I don't understand that either. Raghavendra, can you show a real trace
> > for this issue that shows this?
> >
> Let me know if this helps:
>
> [ 265.332900] Unable to handle kernel NULL pointer dereference at virtual
> address 00000000000000a8
> [ 265.332920] Mem abort info:
> [ 265.332934] ESR = 0x96000006
> [ 265.332950] EC = 0x25: DABT (current EL), IL = 32 bits
> [ 265.332963] SET = 0, FnV = 0
> [ 265.332975] EA = 0, S1PTW = 0
> [ 265.332985] Data abort info:
> [ 265.332997] ISV = 0, ISS = 0x00000006
> [ 265.333008] CM = 0, WnR = 0
> [ 265.333025] user pgtable: 4k pages, 39-bit VAs, pgdp=00000001620f3000
> [ 265.333038] [00000000000000a8] pgd=00000001620f2003,
> pud=00000001620f2003, pmd=0000000000000000
> [ 265.333071] Internal error: Oops: 96000006 [#1] PREEMPT SMP
> [ 265.333424] CPU: 1 PID: 5653 Comm: stress-ng-dev Tainted: G S W O
> 5.4.12-g04866e0 #1
> [ 265.333458] pstate: 80400085 (Nzcv daIf +PAN -UAO)
> [ 265.333499] pc : _raw_spin_lock_irqsave+0x40/0x7c
> [ 265.333517] lr : _raw_spin_lock_irqsave+0x38/0x7c
> [ 265.333530] sp : ffffffc02436ba40
> [ 265.333542] x29: ffffffc02436ba40 x28: 0000000000020800
> [ 265.333562] x27: ffffffdfb4046490 x26: ffffff8101b83400
> [ 265.333580] x25: ffffff80e163ad00 x24: ffffffdfb45c7798
> [ 265.333598] x23: ffffff8101b83668 x22: ffffffdfb4974000
> [ 265.333617] x21: 0000000000000001 x20: 00000000000000a8
> [ 265.333634] x19: 0000000000000000 x18: ffffff80e0b0d460
> [ 265.333652] x17: 0000000000000000 x16: 0000000001000000
> [ 265.333670] x15: 0000000001000000 x14: 00000000f8000000
> [ 265.333688] x13: 0000000000000000 x12: 0000000000000001
> [ 265.333706] x11: 17f5f16765f64600 x10: 17f5f16765f64600
> [ 265.333724] x9 : ffffffdfb3444244 x8 : 0000000000000000
> [ 265.333741] x7 : 0000000000000000 x6 : 0000000000000000
> [ 265.333759] x5 : 0000000000000000 x4 : 0000000000000002
> [ 265.333776] x3 : ffffffc02436b9c0 x2 : ffffffdfb40456e0
> [ 265.333794] x1 : ffffffc02436b9c0 x0 : ffffffdfb3444244
> [ 265.333812] Call trace:
> [ 265.333831] _raw_spin_lock_irqsave+0x40/0x7c
> [ 265.333859] hvc_open$61deaf328f140fd7df47c115ec866fa5+0x28/0x174
> [ 265.333882] tty_open$86bd494905ebe22944bf63b711173de3+0x3d0/0x584
> [ 265.333921] chrdev_open$4083aaa799bca8e0e1e0c8dc1947aa96+0x1c4/0x248
> [ 265.333940] do_dentry_open+0x258/0x3b0
> [ 265.333956] vfs_open+0x2c/0x38
> [ 265.333975] path_openat+0x898/0xedc
> [ 265.333991] do_filp_open+0x78/0x124
> [ 265.334006] do_sys_open+0x13c/0x298
> [ 265.334022] __arm64_sys_openat+0x28/0x34
> [ 265.334044] el0_svc_common+0xb8/0x1b4
> [ 265.334059] el0_svc_handler+0x6c/0x88
> [ 265.334079] el0_svc+0x8/0xc
> [ 265.334110] Code: 52800035 97b9fec7 aa1f03e8 f9800291 (885ffe81)
> [ 265.334130] ---[ end trace ac90e3099a98e99f ]---
> [ 265.334146] Kernel panic - not syncing: Fatal exception
Hm, do you have a strace showing the close happening at the same time?
What about install()?
And what line in hvc_open() does that offset correspond to?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v2 4/5] powerpc/pmem/of_pmem: Update of_pmem to use the new barrier instruction.
From: kbuild test robot @ 2020-05-13 6:44 UTC (permalink / raw)
To: Aneesh Kumar K.V, linuxppc-dev, mpe, linux-nvdimm
Cc: alistair, dan.j.williams, kbuild-all, oohall, Aneesh Kumar K.V
In-Reply-To: <20200513034705.172983-4-aneesh.kumar@linux.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 3435 bytes --]
Hi "Aneesh,
I love your patch! Yet something to improve:
[auto build test ERROR on powerpc/next]
[also build test ERROR on linux-nvdimm/libnvdimm-for-next v5.7-rc5 next-20200512]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url: https://github.com/0day-ci/linux/commits/Aneesh-Kumar-K-V/powerpc-pmem-Add-new-instructions-for-persistent-storage-and-sync/20200513-133938
base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: powerpc-storcenter_defconfig (attached as .config)
compiler: powerpc-linux-gcc (GCC) 9.3.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day GCC_VERSION=9.3.0 make.cross ARCH=powerpc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
WARNING: unmet direct dependencies detected for PPC_INDIRECT_PCI
Depends on PCI
Selected by
- MPC10X_BRIDGE
In file included from include/linux/highmem.h:12,
from include/linux/pagemap.h:11,
from include/linux/blkdev.h:16,
from include/linux/blk-cgroup.h:23,
from include/linux/writeback.h:14,
from include/linux/memcontrol.h:22,
from include/linux/swap.h:9,
from include/linux/suspend.h:5,
from arch/powerpc/kernel/asm-offsets.c:23:
arch/powerpc/include/asm/cacheflush.h: In function 'arch_pmem_flush_barrier':
>> arch/powerpc/include/asm/cacheflush.h:126:22: error: 'CPU_FTR_ARCH_31' undeclared (first use in this function); did you mean
126 | if (cpu_has_feature(CPU_FTR_ARCH_31))
| ^~~~~~~~~~~~~~~
| CPU_FTR_ARCH_300
arch/powerpc/include/asm/cacheflush.h:126:22: note: each undeclared identifier is reported only once for each function it appears in
Makefile arch block certs crypto drivers fs include init ipc kernel lib mm net scripts security sound source usr virt [scripts/Makefile.build:100: arch/powerpc/kernel/asm-offsets.s] Error 1
Target '__build' not remade because of errors.
Makefile arch block certs crypto drivers fs include init ipc kernel lib mm net scripts security sound source usr virt [Makefile:1141: prepare0] Error 2
Target 'prepare' not remade because of errors.
make: Makefile arch block certs crypto drivers fs include init ipc kernel lib mm net scripts security sound source usr virt [Makefile:180: sub-make] Error 2
vim +/CPU_FTR_ARCH_31 +126 arch/powerpc/include/asm/cacheflush.h
113
114 #define copy_to_user_page(vma, page, vaddr, dst, src, len) \
115 do { \
116 memcpy(dst, src, len); \
117 flush_icache_user_range(vma, page, vaddr, len); \
118 } while (0)
119 #define copy_from_user_page(vma, page, vaddr, dst, src, len) \
120 memcpy(dst, src, len)
121
122
123 #define arch_pmem_flush_barrier arch_pmem_flush_barrier
124 static inline void arch_pmem_flush_barrier(void)
125 {
> 126 if (cpu_has_feature(CPU_FTR_ARCH_31))
127 asm volatile(PPC_PHWSYNC ::: "memory");
128 else
129 asm volatile("hwsync" ::: "memory");
130 }
131
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 14417 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc/kvm: silence kmemleak false positives
From: Qian Cai @ 2020-05-13 6:24 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linux-kernel, kvm-ppc, catalin.marinas, linuxppc-dev
In-Reply-To: <87h7wkbhu4.fsf@mpe.ellerman.id.au>
> On May 13, 2020, at 12:04 AM, Michael Ellerman <mpe@ellerman.id.au> wrote:
>
> This should probably also have an include of <linux/kmemleak.h> ?
No, asm/book3s/64/pgalloc.h has already had it and since this is book3s_64_mmu_radix.c, it will include it eventually from,
asm/pgalloc.h
asm/book3s/pgalloc.h
^ permalink raw reply
* Re: [PATCH 19/31] riscv: use asm-generic/cacheflush.h
From: Christoph Hellwig @ 2020-05-13 6:23 UTC (permalink / raw)
To: Palmer Dabbelt
Cc: linux-ia64, linux-sh, zippel, linux-mips, linux-mm, sparclinux,
linux-riscv, Christoph Hellwig, linux-arch, linux-c6x-dev,
linux-hexagon, x86, linux-xtensa, Arnd Bergmann, jeyu, linux-um,
linux-m68k, openrisc, linux-arm-kernel, monstr, linux-kernel,
linux-alpha, linux-fsdevel, akpm, linuxppc-dev
In-Reply-To: <mhng-8adbedbc-0f91-4291-9471-2df5eb7b802b@palmerdabbelt-glaptop1>
On Tue, May 12, 2020 at 04:00:26PM -0700, Palmer Dabbelt wrote:
> Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com>
> Acked-by: Palmer Dabbelt <palmerdabbelt@google.com>
>
> Were you trying to get these all in at once, or do you want me to take it into
> my tree?
Except for the small fixups at the beginning of the series this needs
to go in together. I'll have to do at least another resend, and after
that I hope Andrew is going to pick it up.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox