* Re: [PATCH v8 13/30] powerpc: Add a probe_user_read_inst() function
From: Jordan Niethe @ 2020-05-13 23:51 UTC (permalink / raw)
To: Michael Ellerman
Cc: Christophe Leroy, Alistair Popple, Nicholas Piggin, Balamuruhan S,
naveen.n.rao, linuxppc-dev, Daniel Axtens
In-Reply-To: <87blmsatet.fsf@mpe.ellerman.id.au>
On Wed, May 13, 2020 at 10:52 PM Michael Ellerman <mpe@ellerman.id.au> wrote:
>
> 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?
Good point.
>
> I changed it to:
>
> + if (!err)
> + *inst = ppc_inst(val);
> +
>
> Similarly for probe_kernel_read_inst().
Thanks.
>
> cheers
^ permalink raw reply
* Re: [PATCH v2 2/2] powerpc/rtas: Implement reentrant rtas call
From: kbuild test robot @ 2020-05-13 22:27 UTC (permalink / raw)
To: Leonardo Bras, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras, Allison Randal, Leonardo Bras, Greg Kroah-Hartman,
Thomas Gleixner, Nicholas Piggin, Nathan Lynch, Gautham R. Shenoy,
Nadav Amit
Cc: Leonardo Bras, kbuild-all, linuxppc-dev, linux-kernel
In-Reply-To: <20200513044025.105379-2-leobras.c@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3183 bytes --]
Hi Leonardo,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on powerpc/next]
[also build test ERROR on 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/Leonardo-Bras/powerpc-rtas-Move-type-struct-definitions-from-rtas-h-into-rtas-types-h/20200513-134244
base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: powerpc64-randconfig-r004-20200513 (attached as .config)
compiler: powerpc64-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=powerpc64
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 >>):
In file included from arch/powerpc/include/asm/paca.h:32,
from arch/powerpc/include/asm/current.h:13,
from include/linux/thread_info.h:21,
from include/asm-generic/preempt.h:5,
from ./arch/powerpc/include/generated/asm/preempt.h:1,
from include/linux/preempt.h:78,
from include/linux/spinlock.h:51,
from include/linux/seqlock.h:36,
from include/linux/time.h:6,
from include/linux/compat.h:10,
from arch/powerpc/kernel/asm-offsets.c:14:
>> arch/powerpc/include/asm/rtas-types.h:20:2: error: unknown type name 'arch_spinlock_t'
20 | arch_spinlock_t lock;
| ^~~~~~~~~~~~~~~
make[2]: *** [scripts/Makefile.build:100: arch/powerpc/kernel/asm-offsets.s] Error 1
make[2]: Target '__build' not remade because of errors.
make[1]: *** [Makefile:1141: prepare0] Error 2
make[1]: Target 'prepare' not remade because of errors.
make: *** [Makefile:180: sub-make] Error 2
vim +/arch_spinlock_t +20 arch/powerpc/include/asm/rtas-types.h
199960607a5af4 Leonardo Bras 2020-05-13 15
199960607a5af4 Leonardo Bras 2020-05-13 16 struct rtas_t {
199960607a5af4 Leonardo Bras 2020-05-13 17 unsigned long entry; /* physical address pointer */
199960607a5af4 Leonardo Bras 2020-05-13 18 unsigned long base; /* physical address pointer */
199960607a5af4 Leonardo Bras 2020-05-13 19 unsigned long size;
199960607a5af4 Leonardo Bras 2020-05-13 @20 arch_spinlock_t lock;
199960607a5af4 Leonardo Bras 2020-05-13 21 struct rtas_args args;
199960607a5af4 Leonardo Bras 2020-05-13 22 struct device_node *dev; /* virtual address pointer */
199960607a5af4 Leonardo Bras 2020-05-13 23 };
199960607a5af4 Leonardo Bras 2020-05-13 24
:::::: The code at line 20 was first introduced by commit
:::::: 199960607a5af4bbda685171c4fa70158829a647 powerpc/rtas: Move type/struct definitions from rtas.h into rtas-types.h
:::::: TO: Leonardo Bras <leobras.c@gmail.com>
:::::: CC: 0day robot <lkp@intel.com>
---
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: 32971 bytes --]
^ permalink raw reply
* Re: remove a few uses of ->queuedata
From: Dan Williams @ 2020-05-13 22:26 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Jens Axboe, linux-xtensa, linux-raid, Sergey Senozhatsky,
linux-nvdimm, Geoff Levand, Linux Kernel Mailing List, Jim Paris,
linux-block, Minchan Kim, linux-m68k, Philip Kelleher,
linux-bcache, linuxppc-dev, Joshua Morris, Nitin Gupta, drbd-dev
In-Reply-To: <20200512080820.GA2336@lst.de>
On Tue, May 12, 2020 at 1:08 AM Christoph Hellwig <hch@lst.de> wrote:
>
> On Sat, May 09, 2020 at 08:07:14AM -0700, Dan Williams wrote:
> > > which are all used in the I/O submission path (generic_make_request /
> > > generic_make_request_checks). This is mostly a prep cleanup patch to
> > > also remove the pointless queue argument from ->make_request - then
> > > ->queue is an extra dereference and extra churn.
> >
> > Ah ok. If the changelogs had been filled in with something like "In
> > preparation for removing @q from make_request_fn, stop using
> > ->queuedata", I probably wouldn't have looked twice.
> >
> > For the nvdimm/ driver updates you can add:
> >
> > Reviewed-by: Dan Williams <dan.j.williams@intel.com>
> >
> > ...or just let me know if you want me to pick those up through the nvdimm tree.
>
> I'd love you to pick them up through the nvdimm tree. Do you want
> to fix up the commit message yourself?
Will do, thanks.
^ permalink raw reply
* Re: powerpc/mpc85xx: Add Cyrus P5040 device tree source
From: Darren Stevens @ 2020-05-13 22:02 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, chzigotzky
In-Reply-To: <d64d04f010598ada6e7ddb3af63fee2592b3ebeb.camel@buserror.net>
Hello Scott
On 08/05/2020, Scott Wood wrote:
> On Thu, 2020-05-07 at 22:30 +0100, Darren Stevens wrote:
>>
>> +/include/ "p5040si-pre.dtsi"
>> +
>> +/ {
>> + model = "varisys,CYRUS5040";
>> + compatible = "varisys,CYRUS";
>
> Is this board 100% compatible with the Cyrus P5020 board, down to every last
> quirk, except for the SoC plugged into it? If not, they shouldn't have the
> same compatible. If they are, then couldn't everything in this file but the
> SoC include be moved to a dtsi shared with cyrus_p5020.dts?
It's not 100% compatible, the mdio ports map to different fman ports, but both as are 'corenet generic' boards, I added varisys,CYRUS so it would be detected in corenet_generic.c - support for the 5020 was added by Andy Flemming, I've just tried to copy what he did.
I can add another entry to the table, but do we realy want a separate entry in the table for every supported board rather than using the device tree for similar boards?
It would be nice to get these sorted, the dts files are the last bits to make these fully supported in Linux.
>> + aliases{
>> + ethernet0 = &enet4;
>> + ethernet1 = &enet10;
>> + };
>
> Space after "aliases"
Opps, will be fixed on next version
Thanks
Darren
^ permalink raw reply
* [PATCH 06/11] powerpc/xmon: constify sysrq_key_op
From: Emil Velikov @ 2020-05-13 21:43 UTC (permalink / raw)
To: dri-devel
Cc: Jiri Slaby, emil.l.velikov, linux-kernel, Paul Mackerras,
Greg Kroah-Hartman, linuxppc-dev
In-Reply-To: <20200513214351.2138580-1-emil.l.velikov@gmail.com>
With earlier commits, the API no longer discards the const-ness of the
sysrq_key_op. As such we can add the notation.
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: linux-kernel@vger.kernel.org
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
---
Please keep me in the CC list, as I'm not subscribed to the list.
IMHO it would be better if this gets merged this via the tty tree.
---
arch/powerpc/xmon/xmon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index 7af840c0fc93..0d8ca5c9f131 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -3842,7 +3842,7 @@ static void sysrq_handle_xmon(int key)
xmon_init(0);
}
-static struct sysrq_key_op sysrq_xmon_op = {
+static const struct sysrq_key_op sysrq_xmon_op = {
.handler = sysrq_handle_xmon,
.help_msg = "xmon(x)",
.action_msg = "Entering xmon",
--
2.25.1
^ permalink raw reply related
* Re: [PATCH 12/15] md: stop using ->queuedata
From: Song Liu @ 2020-05-13 18:45 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Jens Axboe, linux-xtensa, linux-raid, Sergey Senozhatsky,
linux-nvdimm, Geoff Levand, open list, Jim Paris, linux-block,
Minchan Kim, linux-m68k, Philip Kelleher, linux-bcache,
linuxppc-dev, Joshua Morris, Nitin Gupta, drbd-dev
In-Reply-To: <20200513183304.GA29895@lst.de>
On Wed, May 13, 2020 at 11:33 AM Christoph Hellwig <hch@lst.de> wrote:
>
> 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.
Thanks for the clarification. Applied to md-next.
^ permalink raw reply
* Re: [PATCH 12/15] md: stop using ->queuedata
From: Song Liu @ 2020-05-13 18:29 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Jens Axboe, linux-xtensa, linux-raid, Sergey Senozhatsky,
linux-nvdimm, Geoff Levand, open list, Jim Paris, linux-block,
Minchan Kim, linux-m68k, Philip Kelleher, linux-bcache,
linuxppc-dev, Joshua Morris, Nitin Gupta, drbd-dev
In-Reply-To: <20200508161517.252308-13-hch@lst.de>
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?
Otherwise,
Acked-by: Song Liu <song@kernel.org>
> ---
> drivers/md/md.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/md/md.c b/drivers/md/md.c
> index 271e8a5873549..c079ecf77c564 100644
> --- a/drivers/md/md.c
> +++ b/drivers/md/md.c
> @@ -466,7 +466,7 @@ static blk_qc_t md_make_request(struct request_queue *q, struct bio *bio)
> {
> const int rw = bio_data_dir(bio);
> const int sgrp = op_stat_group(bio_op(bio));
> - struct mddev *mddev = q->queuedata;
> + struct mddev *mddev = bio->bi_disk->private_data;
> unsigned int sectors;
>
> if (unlikely(test_bit(MD_BROKEN, &mddev->flags)) && (rw == WRITE)) {
> @@ -5626,7 +5626,6 @@ static int md_alloc(dev_t dev, char *name)
> mddev->queue = blk_alloc_queue(md_make_request, NUMA_NO_NODE);
> if (!mddev->queue)
> goto abort;
> - mddev->queue->queuedata = mddev;
>
> blk_set_stacking_limits(&mddev->queue->limits);
>
> --
> 2.26.2
>
^ permalink raw reply
* Re: [RFC PATCH 2/2] powerpc/64s: system call support for scv/rfscv instructions
From: Matheus Castanho @ 2020-05-13 20:55 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev
In-Reply-To: <20200430040202.1735506-3-npiggin@gmail.com>
Hi Nicholas,
Small comment below:
On 4/30/20 1:02 AM, Nicholas Piggin wrote:
> Add support for the scv instruction on POWER9 and later CPUs.
>
> For now this implements the zeroth scv vector 'scv 0', as identical
> to 'sc' system calls, with the exception that lr is not preserved, and
> it is 64-bit only. There may yet be changes made to this ABI, so it's
> for testing only.
>
> rfscv is implemented to return from scv type system calls. It can not
> be used to return from sc system calls because those are defined to
> preserve lr.
>
> In a comparison of getpid syscall, the test program had scv taking
> about 3 more cycles in user mode (92 vs 89 for sc), due to lr handling.
> getpid syscall throughput on POWER9 is improved by 33%, mostly due to
> reducing mtmsr and mtspr.
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> ---
> Documentation/powerpc/syscall64-abi.rst | 42 ++++--
[...]
> +Return value
> +------------
> +- For the sc instruction, both a return value and a return error code are
> + returned. cr0.SO is the return error code, and r3 is the return value or
> + error code. When cr0.SO is clear, the syscall succeeded and r3 is the return
> + value. When cr0.SO is set, the syscall failed and r3 is the error code that
> + generally corresponds to errno.
> +
> +- For the scv 0 instruction, there is a return value indicates failure if it
> + is >= -MAX_ERRNO (-4095) as an unsigned comparison, in which case it is the
> + negated return error code. Otherwise it is the successful return value.
I believe this last paragraph is a bit confusing (didn't quite get the
unsigned comparison with negative values). So instead of cr0.SO to
indicate failure, scv returns the negated error code, and positive in
case of success?
Thanks,
Matheus Castanho
^ permalink raw reply
* [PATCH v6 0/2] Append new variables to vmcoreinfo (TCR_EL1.T1SZ for arm64 and MAX_PHYSMEM_BITS for all archs)
From: Bhupesh Sharma @ 2020-05-13 18:52 UTC (permalink / raw)
To: linux-arm-kernel, x86
Cc: Mark Rutland, linux-doc, bhsharma, Paul Mackerras, Amit Kachhap,
Will Deacon, Ingo Molnar, Jonathan Corbet, Catalin Marinas,
John Donnelly, scott.branden, Boris Petkov, Thomas Gleixner,
bhupesh.linux, Kazuhito Hagio, Ard Biesheuvel, Steve Capper,
kexec, linux-kernel, James Morse, Dave Anderson, linuxppc-dev
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:
http://lists.infradead.org/pipermail/kexec/2019-November/024055.html
- Addressed review comments from James Morse and Boris.
- Added Tested-by received from John on v5 patchset.
- Rebased against arm64 (for-next/ptr-auth) branch which has Amit's
patchset for ARMv8.3-A Pointer Authentication feature vmcoreinfo
applied.
Changes since v4:
----------------
- v4 can be seen here:
http://lists.infradead.org/pipermail/kexec/2019-November/023961.html
- Addressed comments from Dave and added patches for documenting
new variables appended to vmcoreinfo documentation.
- Added testing report shared by Akashi for PATCH 2/5.
Changes since v3:
----------------
- v3 can be seen here:
http://lists.infradead.org/pipermail/kexec/2019-March/022590.html
- Addressed comments from James and exported TCR_EL1.T1SZ in vmcoreinfo
instead of PTRS_PER_PGD.
- Added a new patch (via [PATCH 3/3]), which fixes a simple typo in
'Documentation/arm64/memory.rst'
Changes since v2:
----------------
- v2 can be seen here:
http://lists.infradead.org/pipermail/kexec/2019-March/022531.html
- Protected 'MAX_PHYSMEM_BITS' vmcoreinfo variable under CONFIG_SPARSEMEM
ifdef sections, as suggested by Kazu.
- Updated vmcoreinfo documentation to add description about
'MAX_PHYSMEM_BITS' variable (via [PATCH 3/3]).
Changes since v1:
----------------
- v1 was sent out as a single patch which can be seen here:
http://lists.infradead.org/pipermail/kexec/2019-February/022411.html
- v2 breaks the single patch into two independent patches:
[PATCH 1/2] appends 'PTRS_PER_PGD' to vmcoreinfo for arm64 arch, whereas
[PATCH 2/2] appends 'MAX_PHYSMEM_BITS' to vmcoreinfo in core kernel code (all archs)
This patchset primarily fixes the regression reported in user-space
utilities like 'makedumpfile' and 'crash-utility' on arm64 architecture
with the availability of 52-bit address space feature in underlying
kernel. These regressions have been reported both on CPUs which don't
support ARMv8.2 extensions (i.e. LVA, LPA) and are running newer kernels
and also on prototype platforms (like ARMv8 FVP simulator model) which
support ARMv8.2 extensions and are running newer kernels.
The reason for these regressions is that right now user-space tools
have no direct access to these values (since these are not exported
from the kernel) and hence need to rely on a best-guess method of
determining value of 'vabits_actual' and 'MAX_PHYSMEM_BITS' supported
by underlying kernel.
Exporting these values via vmcoreinfo will help user-land in such cases.
In addition, 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 arm64 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.
Cc: Boris Petkov <bp@alien8.de>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: James Morse <james.morse@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Steve Capper <steve.capper@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.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: John Donnelly <john.p.donnelly@oracle.com>
Cc: scott.branden@broadcom.com
Cc: Amit Kachhap <amit.kachhap@arm.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: linux-doc@vger.kernel.org
Cc: kexec@lists.infradead.org
Bhupesh Sharma (2):
crash_core, vmcoreinfo: Append 'MAX_PHYSMEM_BITS' to vmcoreinfo
arm64/crash_core: Export TCR_EL1.T1SZ in vmcoreinfo
Documentation/admin-guide/kdump/vmcoreinfo.rst | 16 ++++++++++++++++
arch/arm64/include/asm/pgtable-hwdef.h | 1 +
arch/arm64/kernel/crash_core.c | 10 ++++++++++
kernel/crash_core.c | 1 +
4 files changed, 28 insertions(+)
--
2.7.4
^ permalink raw reply
* [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
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