[PATCH] powerpc/32: warn and return error on syscalls from kernel

Since commit b86fb88855ea ("powerpc/32: implement fast entry for syscalls on non BOOKE") and commit 1a4b739bbb4f ("powerpc/32: implement fast entry for syscalls on BOOKE"), syscalls from kernel are unexpected and can have catastrophic consequences as it will destroy the kernel stack. Test MSR_PR

Re: [mm/debug] 87c4696d57: kernel_BUG_at_include/linux/mm.h

On 12/27/2019 07:52 PM, kernel test robot wrote: > [9.781974] kernel BUG at include/linux/mm.h:592! > [9.782810] invalid opcode: [#1] PTI > [9.783443] CPU: 0 PID: 1 Comm: swapper Not tainted > 5.5.0-rc3-1-g87c4696d57b5e #1 > [9.784528] Hardware name: QEMU Standard PC

Re: [PATCH 2/2] powerpc/pseries/svm: Disable BHRB/EBB/PMU access

On 12/27/19 10:59 AM, Sukadev Bhattiprolu wrote: Sukadev Bhattiprolu [suka...@linux.ibm.com] wrote: Ultravisor disables some CPU features like BHRB, EBB and PMU in secure virtual machines (SVMs). Skip accessing those registers in SVMs to avoid getting a Program Interrupt. Here is an updated

Re: [PATCH] powerpc: add support for folded p4d page tables

Mike Rapoport writes: > On Mon, Jan 06, 2020 at 02:31:41PM +1100, Michael Ellerman wrote: >> Mike Rapoport writes: >> > Any updates on this? >> >> It's very ... big, and kind of intrusive. > > I've tried to split it to several smaller ones, but I couldn't find a way > to do it without breaking

Re: [PATCH 05/18] powerpc sstep: Prepare to support prefixed instructions

On Fri, Dec 20, 2019 at 4:17 PM Jordan Niethe wrote: > > On Thu, Dec 19, 2019 at 1:15 AM Daniel Axtens wrote: > > > > Jordan Niethe writes: > > > > > Currently all instructions are a single word long. A future ISA version > > > will include prefixed instructions which have a double word length.

Re: powerpc/xmon: don't access ASDR in VMs

On 7/1/20 1:16 pm, Sukadev Bhattiprolu wrote: From 91a77dbea3c909ff15c66cded37f1334304a293d Mon Sep 17 00:00:00 2001 From: Sukadev Bhattiprolu Date: Mon, 6 Jan 2020 13:50:02 -0600 Subject: [PATCH 1/1] powerpc/xmon: don't access ASDR in VMs ASDR is HV-privileged and must only be accessed in

[Bug 206049] alg: skcipher: p8_aes_xts encryption unexpectedly succeeded on test vector "random: len=0 klen=64"; expected_error=-22, cfg="random: inplace may_sleep use_finup src_divs=[66.99%@+1

https://bugzilla.kernel.org/show_bug.cgi?id=206049 Daniel Axtens (d...@axtens.net) changed: What|Removed |Added CC||d...@axtens.net ---

powerpc/xmon: don't access ASDR in VMs

>From 91a77dbea3c909ff15c66cded37f1334304a293d Mon Sep 17 00:00:00 2001 From: Sukadev Bhattiprolu Date: Mon, 6 Jan 2020 13:50:02 -0600 Subject: [PATCH 1/1] powerpc/xmon: don't access ASDR in VMs ASDR is HV-privileged and must only be accessed in HV-mode. Fixes a Program Check (0x700) when xmon

Re: [PATCH v3 02/22] compat: provide compat_ptr() on all architectures

Arnd Bergmann writes: > In order to avoid needless #ifdef CONFIG_COMPAT checks, > move the compat_ptr() definition to linux/compat.h > where it can be seen by any file regardless of the > architecture. > > Only s390 needs a special definition, this can use the > self-#define trick we have

Re: [PATCH v4 2/2] KVM: PPC: Implement H_SVM_INIT_ABORT hcall

Ram Pai [linux...@us.ibm.com] wrote: > > One small comment.. H_STATE is a better return code than H_UNSUPPORTED. > Here is the updated patch - we now return H_STATE if the abort call is made after the VM has gone secure. --- >From 73fe1fa5aff2829f2fae6a339169e56dc0bbae06 Mon Sep 17 00:00:00 2001

Re: [PATCH v11 00/25] mm/gup: track dma-pinned pages: FOLL_PIN

On 1/6/20 1:01 AM, Jan Kara wrote: ... Also, looking ahead: a) if the problem disappears with the latest above test, then we likely have a huge page refcount overflow, and there are a couple of different ways to fix it. b) if it still reproduces with the above, then it's some other

Re: PPC64: G5 & 4k/64k page size (was: Re: Call for report - G5/PPC970 status)

"Aneesh Kumar K.V" writes: > Romain Dolbeau writes: > >> Le sam. 21 déc. 2019 à 05:31, Aneesh Kumar K.V >> a écrit : >>> I don't have direct access to this system, I have asked if we can get a run >>> with 64K. >> >> OK, thanks! Do you know which model it is? It seems to be working on >> some

Re: [PATCH] powerpc/85xx: Get twr_p102x to compile again

On Thu, 2019-12-19 at 15:16:02 UTC, Sebastian Andrzej Siewior wrote: > With CONFIG_QUICC_ENGINE enabled and CONFIG_UCC_GETH + CONFIG_SERIAL_QE > disabled we have an unused variable (np). The code won't compile with > -Werror. > > Move the np variable to the block where it is actually used. > >

Re: [PATCH] powerpc/pseries: Remove redundant select of PPC_DOORBELL

On Thu, 2019-12-19 at 12:58:40 UTC, Michael Ellerman wrote: > Commit d4e58e5928f8 ("powerpc/powernv: Enable POWER8 doorbell IPIs") > added a select of PPC_DOORBELL to PPC_PSERIES, but it already had a > select of PPC_DOORBELL. One is enough. > > Reported-by: Jason A. Donenfeld > Signed-off-by:

Re: [PATCH] powerpc/512x: Use dma_request_chan() instead dma_request_slave_channel()

On Tue, 2019-12-17 at 07:37:30 UTC, Peter Ujfalusi wrote: > dma_request_slave_channel() is a wrapper on top of dma_request_chan() > eating up the error code. > > By using dma_request_chan() directly the driver can support deferred > probing against DMA. > > Signed-off-by: Peter Ujfalusi

Re: [PATCH kernel v2 1/4] Revert "powerpc/pseries/iommu: Don't use dma_iommu_ops on secure guests"

On Mon, 2019-12-16 at 04:19:21 UTC, Alexey Kardashevskiy wrote: > From: Ram Pai > > This reverts commit edea902c1c1efb855f77e041f9daf1abe7a9768a. > > At the time the change allowed direct DMA ops for secure VMs; however > since then we switched on using SWIOTLB backed with IOMMU (direct

Re: [PATCH] powerpc/64: Use {SAVE,REST}_NVGPRS macros

On Wed, 2019-12-11 at 02:35:52 UTC, Jordan Niethe wrote: > In entry_64.S there are places that open code saving and restoring the > non-volatile registers. There are already macros for doing this so use > them. > > Signed-off-by: Jordan Niethe Applied to powerpc next, thanks.

Re: [PATCH] powerpc/44x: Adjust indentation in ibm4xx_denali_fixup_memsize

On Mon, 2019-12-09 at 20:03:38 UTC, Nathan Chancellor wrote: > Clang warns: > > ../arch/powerpc/boot/4xx.c:231:3: warning: misleading indentation; > statement is not part of the previous 'else' [-Wmisleading-indentation] > val = SDRAM0_READ(DDR0_42); > ^ >

Re: [PATCH] powerpc/papr_scm: Update debug message

On Mon, 2019-12-02 at 06:38:55 UTC, "Aneesh Kumar K.V" wrote: > Resource struct p->res is assigned later. Avoid using %pR before the resource > struct is assigned. > > Signed-off-by: Aneesh Kumar K.V Applied to powerpc next, thanks.

Re: [PATCH v2] powerpc/imc: Add documentation for IMC and trace-mode

On Mon, 2019-10-28 at 10:08:16 UTC, Michael Ellerman wrote: > From: Anju T Sudhakar > > Documentation for IMC (In-Memory Collection Counters) infrastructure > and trace-mode of IMC. > > Signed-off-by: Anju T Sudhakar > [mpe: Convert to rst, minor rewording, make PMI example more concise] >

Re: [PATCH v2 1/3] powernv/iov: Ensure the pdn for VFs always contains a valid PE number

On Mon, 2019-10-28 at 08:54:22 UTC, Oliver O'Halloran wrote: > On pseries there is a bug with adding hotplugged devices to an IOMMU group. > For a number of dumb reasons fixing that bug first requires re-working how > VFs are configured on PowerNV. For background, on PowerNV we use the >

Re: [PATCH v2] selftests/powerpc: Add a test of bad (out-of-range) accesses

On Mon, 2019-05-20 at 10:20:51 UTC, Michael Ellerman wrote: > Userspace isn't allowed to access certain address ranges, make sure we > actually test that to at least some degree. > > This would have caught the recent bug where the SLB fault handler was > incorrectly called on an out-of-range

Re: PPC64: G5 & 4k/64k page size (was: Re: Call for report - G5/PPC970 status)

On Mon, Jan 06, 2020 at 08:11:47PM +0100, Romain Dolbeau wrote: > Interesting idea (and I have a 6600 aka NV43 in there, indeed) but I > don't think so, as > a) 'nouveau' works in 4.19 with 64 KiB pages > b) using "module_blacklist=nouveau" doesn't help, I just tried > c) my original 'bisect' was

Re: PPC64: G5 & 4k/64k page size (was: Re: Call for report - G5/PPC970 status)

Le lun. 6 janv. 2020 à 19:54, Lennart Sorensen a écrit : > Is it possible this has to do with nouveau and not supporting 64K page > size on older nvidia chips? Interesting idea (and I have a 6600 aka NV43 in there, indeed) but I don't think so, as a) 'nouveau' works in 4.19 with 64 KiB pages b)

Re: PPC64: G5 & 4k/64k page size (was: Re: Call for report - G5/PPC970 status)

On Mon, Jan 06, 2020 at 07:18:30PM +0100, Romain Dolbeau wrote: > Applied, recompiled with 64 KiB pages, still crashes. > > The backtrace seems more readable this time (and wasn't overwritten by > something else), bad photo here: > Is it

Re: [PATCH v3 02/22] compat: provide compat_ptr() on all architectures

On 2020-01-02 06:55, Arnd Bergmann wrote: > In order to avoid needless #ifdef CONFIG_COMPAT checks, > move the compat_ptr() definition to linux/compat.h > where it can be seen by any file regardless of the > architecture. > > Only s390 needs a special definition, this can use the > self-#define

Re: PPC64: G5 & 4k/64k page size (was: Re: Call for report - G5/PPC970 status)

Le dim. 5 janv. 2020 à 16:06, Bertrand Dekoninck a écrit : > I can now test on powermac 7,3 (with an ATI card) > How can I build a deb package of this kernel ? Or is there a package to > download somewhere ? I usually cross-compile on x86-64 from upstream sources. On a Debian Buster with the

Re: PPC64: G5 & 4k/64k page size (was: Re: Call for report - G5/PPC970 status)

Le lun. 6 janv. 2020 à 15:06, Aneesh Kumar K.V a écrit : > Can you try this change. Applied, recompiled with 64 KiB pages, still crashes. The backtrace seems more readable this time (and wasn't overwritten by something else), bad photo here:

Re: [PATCH v3 2/2] powerpc/mpc85xx: also write addr_h to spin table for 64bit boot entry

On Mon, 2020-01-06 at 12:29 +0800, yingjie_...@126.com wrote: > From: Bai Yingjie > > CPU like P4080 has 36bit physical address, its DDR physical > start address can be configured above 4G by LAW registers. > > For such systems in which their physical memory start address was > configured

Re: [PATCH 05/10] powerpc/83xx: use resource_size

On Wed, 2020-01-01 at 18:49 +0100, Julia Lawall wrote: > Use resource_size rather than a verbose computation on > the end and start fields. > > The semantic patch that makes this change is as follows: > (http://coccinelle.lip6.fr/) > > > @@ struct resource ptr; @@ > - (ptr.end - ptr.start + 1)

Re: "ftrace: Rework event_create_dir()" triggers boot error messages

On Mon, 6 Jan 2020 12:05:58 -0500 Qian Cai wrote: > > diff --git a/kernel/trace/trace_syscalls.c b/kernel/trace/trace_syscalls.c > > index 53935259f701..abb70c71fe60 100644 > > --- a/kernel/trace/trace_syscalls.c > > +++ b/kernel/trace/trace_syscalls.c > > @@ -269,7 +269,8 @@ static int __init

Re: [PATCH v3 02/22] compat: provide compat_ptr() on all architectures

On Thu, Jan 02, 2020 at 03:55:20PM +0100, Arnd Bergmann wrote: > In order to avoid needless #ifdef CONFIG_COMPAT checks, > move the compat_ptr() definition to linux/compat.h > where it can be seen by any file regardless of the > architecture. > > Only s390 needs a special definition, this can use

Re: "ftrace: Rework event_create_dir()" triggers boot error messages

> On Dec 18, 2019, at 11:31 PM, Steven Rostedt wrote: > > On Wed, 18 Dec 2019 22:58:23 -0500 > Qian Cai wrote: > >> The linux-next commit "ftrace: Rework event_create_dir()” [1] triggers boot >> warnings >> for Clang-build (Clang version 8.0.1) kernels (reproduced on both arm64 and >>

Re: [PATCH 2/2] powerpc: avoid adjusting memory_limit for capture kernel memory reservation

On Wed, Jul 24, 2019 at 11:26:59AM +0530, Mahesh Jagannath Salgaonkar wrote: > On 7/22/19 11:19 PM, Michal Suchánek wrote: > > On Fri, 28 Jun 2019 00:51:19 +0530 > > Hari Bathini wrote: > > > >> Currently, if memory_limit is specified and it overlaps with memory to > >> be reserved for capture

Re: PPC64: G5 & 4k/64k page size (was: Re: Call for report - G5/PPC970 status)

Romain Dolbeau writes: > Le sam. 21 déc. 2019 à 05:31, Aneesh Kumar K.V > a écrit : >> I don't have direct access to this system, I have asked if we can get a run >> with 64K. > > OK, thanks! Do you know which model it is? It seems to be working on > some systems, > but we don't have enough

[PATCH v2 3/3] powerpc/powernv: Parse device tree, population of SPR support

Parse the device tree for nodes self-save, self-restore and populate support for the preferred SPRs based what was advertised by the device tree. Signed-off-by: Pratik Rajesh Sampat --- arch/powerpc/platforms/powernv/idle.c | 104 ++ 1 file changed, 104 insertions(+)

[PATCH v2 2/3] powerpc/powernv: Introduce Self save support

This commit introduces and leverages the Self save API which OPAL now supports. Add the new Self Save OPAL API call in the list of OPAL calls. Implement the self saving of the SPRs based on the support populated while respecting it's preferences. This implementation allows mixing of support for

[PATCH v2 1/3] powerpc/powernv: Interface to define support and preference for a SPR

Define a bitmask interface to determine support for the Self Restore, Self Save or both. Also define an interface to determine the preference of that SPR to be strictly saved or restored or encapsulated with an order of preference. The preference bitmask is shown as below:

[PATCH v2 0/3] Introduce Self-Save API for deep stop states

RFC v1 patches: https://lkml.org/lkml/2019/12/4/193 Changelog RFC v1 --> v2 1. Optimized preference bitmask 2. Addressed comments from Ram Pai Currently the stop-API supports a mechanism called as self-restore which allows us to restore the values of certain SPRs on wakeup from a deep-stop state

Re: [PATCH v2 2/2] powerpc/mm: Warn if W+X pages found on boot

Le 02/05/2019 à 09:39, Russell Currey a écrit : Implement code to walk all pages and warn if any are found to be both writable and executable. Depends on STRICT_KERNEL_RWX enabled, and is behind the DEBUG_WX config option. This only runs on boot and has no runtime performance implications.

Re: [RFC 1/3] powerpc/powernv: Interface to define support and preference for a SPR

Hello Ram, Thank you for your reviewing the patches. +/* Interface for the stop state supported and preference */ +#define SELF_RESTORE_TYPE0 +#define SELF_SAVE_TYPE 1 + +#define NR_PREFERENCES2 +#define PREFERENCE_SHIFT 8 +#define PREFERENCE_MASK 0xff + +#define UNSUPPORTED

Re: [RFC 0/3] Integrate Support for self-save and determine

Thanks for your comments Ram, A list of preferred SPRs are maintained in the kernel which contains two properties: 1. supported_mode: Helps in identifying if it strictly supports self save or restore or both. Will be good to capture the information that, 'supported_mode'

Re: [PATCH v11 00/25] mm/gup: track dma-pinned pages: FOLL_PIN

On Sat 28-12-19 20:33:32, John Hubbard wrote: > On 12/27/19 1:56 PM, John Hubbard wrote: > ... > >> It is ancient verification test (~10y) which is not an easy task to > >> make it understandable and standalone :). > >> > > > > Is this the only test that fails, btw? No other test failures or

[PATCH v3] powerpc/kernel/sysfs: Add new config option PMU_SYSFS to enable PMU SPRs sysfs file creation

Many of the performance moniroting unit (PMU) SPRs are exposed in the sysfs. This may not be a desirable since "perf" API is the primary interface to program PMU and collect counter data in the system. But that said, we cant remove these sysfs files since we dont whether anyone/anything is using