* Re: [PATCH v1] pseries/hotplug-memory: hot-add: skip redundant LMB lookup
From: Michael Ellerman @ 2020-09-11 13:15 UTC (permalink / raw)
To: Scott Cheloha, linuxppc-dev
Cc: Nathan Lynch, Michal Suchanek, David Hildenbrand, Rick Lindsley,
Laurent Dufour
In-Reply-To: <20200910175637.2865160-1-cheloha@linux.ibm.com>
Hi Scott,
Scott Cheloha <cheloha@linux.ibm.com> writes:
> During memory hot-add, dlpar_add_lmb() calls memory_add_physaddr_to_nid()
> to determine which node id (nid) to use when later calling __add_memory().
>
...
>
> Consider an LPAR with 126976 LMBs. In one test, hot-adding 126000
Nice little machine you got there :P
> LMBs on an upatched kernel took ~3.5 hours while a patched kernel
> completed the same operation in ~2 hours:
...
> diff --git a/arch/powerpc/platforms/pseries/hotplug-memory.c b/arch/powerpc/platforms/pseries/hotplug-memory.c
> index 0ea976d1cac4..9cd572440175 100644
> --- a/arch/powerpc/platforms/pseries/hotplug-memory.c
> +++ b/arch/powerpc/platforms/pseries/hotplug-memory.c
> @@ -595,6 +595,8 @@ static int dlpar_memory_remove_by_ic(u32 lmbs_to_remove, u32 drc_index)
> }
> #endif /* CONFIG_MEMORY_HOTREMOVE */
>
> +extern int of_drconf_to_nid_single(struct drmem_lmb *);
> +
This needs to go in a header.
It should probably go in arch/powerpc/include/asm/topology.h
cheers
> static int dlpar_add_lmb(struct drmem_lmb *lmb)
> {
> unsigned long block_sz;
> @@ -611,8 +613,10 @@ static int dlpar_add_lmb(struct drmem_lmb *lmb)
>
> block_sz = memory_block_size_bytes();
>
> - /* Find the node id for this address. */
> - nid = memory_add_physaddr_to_nid(lmb->base_addr);
> + /* Find the node id for this address. Fake one if necessary. */
> + nid = of_drconf_to_nid_single(lmb);
> + if (nid < 0 || !node_possible(nid))
> + nid = first_online_node;
>
> /* Add the memory */
> rc = __add_memory(nid, lmb->base_addr, block_sz);
> --
> 2.24.1
^ permalink raw reply
* Re: [PATCH] powerpc/powermac: Fix low_sleep_handler with KUAP and KUEP
From: Michael Ellerman @ 2020-09-11 13:06 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <d56e42c0-0117-81bb-b583-4944e7bf0383@csgroup.eu>
Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> Le 11/09/2020 à 01:56, Michael Ellerman a écrit :
>> Christophe Leroy <christophe.leroy@csgroup.eu> writes:
>>> low_sleep_handler() has an hardcoded restore of segment registers
>>> that doesn't take KUAP and KUEP into account.
>>>
>>> Use head_32's load_segment_registers() routine instead.
>>>
>>> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
>>> Fixes: a68c31fc01ef ("powerpc/32s: Implement Kernel Userspace Access Protection")
>>> Fixes: 31ed2b13c48d ("powerpc/32s: Implement Kernel Userspace Execution Prevention.")
>>> Cc: stable@vger.kernel.org
>>> ---
>>> arch/powerpc/platforms/powermac/sleep.S | 9 +--------
>>> 1 file changed, 1 insertion(+), 8 deletions(-)
>>
>> Doesn't build? pmac32_defconfig, gcc 9.3.0:
>>
>> ld: arch/powerpc/platforms/powermac/sleep.o: in function `core99_wake_up':
>> (.text+0x25c): undefined reference to `load_segment_registers'
>>
>> Missing _GLOBAL() presumably?
>
> Oops .. :(
>
> v2 sent out.
Thanks.
cheers
^ permalink raw reply
* Re: [RFC PATCH v2 1/3] mm/gup: fix gup_fast with dynamic page table folding
From: Alexander Gordeev @ 2020-09-11 12:19 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Peter Zijlstra, Dave Hansen, Dave Hansen, Paul Mackerras,
linux-sparc, Claudio Imbrenda, Will Deacon, linux-arch,
linux-s390, Vasily Gorbik, Richard Weinberger, linux-x86,
Russell King, Christian Borntraeger, Ingo Molnar, Catalin Marinas,
Andrey Ryabinin, Gerald Schaefer, Heiko Carstens, Arnd Bergmann,
John Hubbard, Jeff Dike, linux-um, Borislav Petkov,
Andy Lutomirski, Thomas Gleixner, linux-arm, linux-mm,
linux-power, LKML, Andrew Morton, Linus Torvalds, Mike Rapoport
In-Reply-To: <20200910221116.GQ87483@ziepe.ca>
On Thu, Sep 10, 2020 at 07:11:16PM -0300, Jason Gunthorpe wrote:
> On Thu, Sep 10, 2020 at 02:22:37PM -0700, John Hubbard wrote:
>
> > Or am I way off here, and it really is possible (aside from the current
> > s390 situation) to observe something that "is no longer a page table"?
>
> Yes, that is the issue. Remember there is no locking for GUP
> fast. While a page table cannot be freed there is nothing preventing
> the page table entry from being concurrently modified.
>
> Without the stack variable it looks like this:
>
> pud_t pud = READ_ONCE(*pudp);
> if (!pud_present(pud))
> return
> pmd_offset(pudp, address);
>
> And pmd_offset() expands to
>
> return (pmd_t *)pud_page_vaddr(*pud) + pmd_index(address);
>
> Between the READ_ONCE(*pudp) and (*pud) inside pmd_offset() the value
> of *pud can change, eg to !pud_present.
>
> Then pud_page_vaddr(*pud) will crash. It is not use after free, it
> is using data that has not been validated.
One thing I ask myself and it is probably a good moment to wonder.
What if the entry is still pud_present, but got remapped after
READ_ONCE(*pudp)? IOW, it is still valid, but points elsewhere?
> Jason
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Don't return -ENOTSUPP to userspace in ioctls
From: Thadeu Lima de Souza Cascardo @ 2020-09-11 12:08 UTC (permalink / raw)
To: Greg Kurz; +Cc: trivial, linuxppc-dev, kvm-ppc
In-Reply-To: <159982162511.459323.13495475646618845164.stgit@bahia.lan>
On Fri, Sep 11, 2020 at 12:53:45PM +0200, Greg Kurz wrote:
> ENOTSUPP is a linux only thingy, the value of which is unknown to
> userspace, not to be confused with ENOTSUP which linux maps to
> EOPNOTSUPP, as permitted by POSIX [1]:
>
> [EOPNOTSUPP]
> Operation not supported on socket. The type of socket (address family
> or protocol) does not support the requested operation. A conforming
> implementation may assign the same values for [EOPNOTSUPP] and [ENOTSUP].
>
> Return -EOPNOTSUPP instead of -ENOTSUPP for the following ioctls:
> - KVM_GET_FPU for Book3s and BookE
> - KVM_SET_FPU for Book3s and BookE
> - KVM_GET_DIRTY_LOG for BookE
>
> This doesn't affect QEMU which doesn't call the KVM_GET_FPU and
> KVM_SET_FPU ioctls on POWER anyway since they are not supported,
> and _buggily_ ignores anything but -EPERM for KVM_GET_DIRTY_LOG.
>
> [1] https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html
>
> Signed-off-by: Greg Kurz <groug@kaod.org>
Agreed. ENOTSUPP should never be returned to userspace.
Acked-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
> ---
> arch/powerpc/kvm/book3s.c | 4 ++--
> arch/powerpc/kvm/booke.c | 6 +++---
> 2 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
> index 1fce9777af1c..44bf567b6589 100644
> --- a/arch/powerpc/kvm/book3s.c
> +++ b/arch/powerpc/kvm/book3s.c
> @@ -558,12 +558,12 @@ int kvm_arch_vcpu_ioctl_set_regs(struct kvm_vcpu *vcpu, struct kvm_regs *regs)
>
> int kvm_arch_vcpu_ioctl_get_fpu(struct kvm_vcpu *vcpu, struct kvm_fpu *fpu)
> {
> - return -ENOTSUPP;
> + return -EOPNOTSUPP;
> }
>
> int kvm_arch_vcpu_ioctl_set_fpu(struct kvm_vcpu *vcpu, struct kvm_fpu *fpu)
> {
> - return -ENOTSUPP;
> + return -EOPNOTSUPP;
> }
>
> int kvmppc_get_one_reg(struct kvm_vcpu *vcpu, u64 id,
> diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
> index 3e1c9f08e302..b1abcb816439 100644
> --- a/arch/powerpc/kvm/booke.c
> +++ b/arch/powerpc/kvm/booke.c
> @@ -1747,12 +1747,12 @@ int kvmppc_set_one_reg(struct kvm_vcpu *vcpu, u64 id,
>
> int kvm_arch_vcpu_ioctl_get_fpu(struct kvm_vcpu *vcpu, struct kvm_fpu *fpu)
> {
> - return -ENOTSUPP;
> + return -EOPNOTSUPP;
> }
>
> int kvm_arch_vcpu_ioctl_set_fpu(struct kvm_vcpu *vcpu, struct kvm_fpu *fpu)
> {
> - return -ENOTSUPP;
> + return -EOPNOTSUPP;
> }
>
> int kvm_arch_vcpu_ioctl_translate(struct kvm_vcpu *vcpu,
> @@ -1773,7 +1773,7 @@ void kvm_arch_sync_dirty_log(struct kvm *kvm, struct kvm_memory_slot *memslot)
>
> int kvm_vm_ioctl_get_dirty_log(struct kvm *kvm, struct kvm_dirty_log *log)
> {
> - return -ENOTSUPP;
> + return -EOPNOTSUPP;
> }
>
> void kvmppc_core_free_memslot(struct kvm *kvm, struct kvm_memory_slot *slot)
>
>
^ permalink raw reply
* Re: [PATCH v5 05/10] powerpc/smp: Dont assume l2-cache to be superset of sibling
From: Michael Ellerman @ 2020-09-11 11:55 UTC (permalink / raw)
To: Srikar Dronamraju
Cc: Nathan Lynch, Gautham R Shenoy, Michael Neuling,
Srikar Dronamraju, Peter Zijlstra, Jordan Niethe, LKML,
Nicholas Piggin, Valentin Schneider, Oliver O'Halloran,
linuxppc-dev, Ingo Molnar
In-Reply-To: <20200810071834.92514-6-srikar@linux.vnet.ibm.com>
Srikar Dronamraju <srikar@linux.vnet.ibm.com> writes:
> Current code assumes that cpumask of cpus sharing a l2-cache mask will
> always be a superset of cpu_sibling_mask.
>
> Lets stop that assumption. cpu_l2_cache_mask is a superset of
> cpu_sibling_mask if and only if shared_caches is set.
I'm seeing oopses with this:
[ 0.117392][ T1] smp: Bringing up secondary CPUs ...
[ 0.156515][ T1] smp: Brought up 2 nodes, 2 CPUs
[ 0.158265][ T1] numa: Node 0 CPUs: 0
[ 0.158520][ T1] numa: Node 1 CPUs: 1
[ 0.167453][ T1] BUG: Unable to handle kernel data access on read at 0x8000000041228298
[ 0.167992][ T1] Faulting instruction address: 0xc00000000018c128
[ 0.168817][ T1] Oops: Kernel access of bad area, sig: 11 [#1]
[ 0.168964][ T1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
[ 0.169417][ T1] Modules linked in:
[ 0.170047][ T1] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.9.0-rc2-00095-g7430ad5aa700 #209
[ 0.170305][ T1] NIP: c00000000018c128 LR: c00000000018c0cc CTR: c00000000004dce0
[ 0.170498][ T1] REGS: c00000007e343880 TRAP: 0380 Not tainted (5.9.0-rc2-00095-g7430ad5aa700)
[ 0.170602][ T1] MSR: 8000000002009033 <SF,VEC,EE,ME,IR,DR,RI,LE> CR: 44002222 XER: 00000000
[ 0.170985][ T1] CFAR: c00000000018c288 IRQMASK: 0
[ 0.170985][ T1] GPR00: 0000000000000000 c00000007e343b10 c00000000173e400 0000000000004000
[ 0.170985][ T1] GPR04: 0000000000000000 0000000000000800 0000000000000800 0000000000000000
[ 0.170985][ T1] GPR08: 0000000000000000 c00000000122c298 c00000003fffc000 c00000007fd05ce8
[ 0.170985][ T1] GPR12: c00000007e0119f8 c000000001930000 00000000ffff8ade 0000000000000000
[ 0.170985][ T1] GPR16: c00000007e3c0640 0000000000000917 c00000007e3c0658 0000000000000008
[ 0.170985][ T1] GPR20: c0000000015d0bb8 00000000ffff8ade c000000000f57400 c000000001817c28
[ 0.170985][ T1] GPR24: c00000000176dc80 c00000007e3c0890 c00000007e3cfe00 0000000000000000
[ 0.170985][ T1] GPR28: c000000001772310 c00000007e011900 c00000007e3c0800 0000000000000001
[ 0.172750][ T1] NIP [c00000000018c128] build_sched_domains+0x808/0x14b0
[ 0.172900][ T1] LR [c00000000018c0cc] build_sched_domains+0x7ac/0x14b0
[ 0.173186][ T1] Call Trace:
[ 0.173484][ T1] [c00000007e343b10] [c00000000018bfe8] build_sched_domains+0x6c8/0x14b0 (unreliable)
[ 0.173821][ T1] [c00000007e343c50] [c00000000018dcdc] sched_init_domains+0xec/0x130
[ 0.174037][ T1] [c00000007e343ca0] [c0000000010d59d8] sched_init_smp+0x50/0xc4
[ 0.174207][ T1] [c00000007e343cd0] [c0000000010b45c4] kernel_init_freeable+0x1b4/0x378
[ 0.174378][ T1] [c00000007e343db0] [c0000000000129fc] kernel_init+0x24/0x158
[ 0.174740][ T1] [c00000007e343e20] [c00000000000d9d0] ret_from_kernel_thread+0x5c/0x6c
[ 0.175050][ T1] Instruction dump:
[ 0.175626][ T1] 554905ee 71480040 7d2907b4 4182016c 2c290000 3920006e 913e002c 41820034
[ 0.175841][ T1] 7c6307b4 e9300020 78631f24 7d58182a <7d2a482a> f93e0080 7d404828 314a0001
[ 0.178340][ T1] ---[ end trace 6876b88dd1d4b3bb ]---
[ 0.178512][ T1]
[ 1.180458][ T1] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
That's qemu:
qemu-system-ppc64 -nographic -vga none -M pseries -cpu POWER8 \
-kernel build~/vmlinux \
-m 2G,slots=2,maxmem=4G \
-object memory-backend-ram,size=1G,id=m0 \
-object memory-backend-ram,size=1G,id=m1 \
-numa node,nodeid=0,memdev=m0 \
-numa node,nodeid=1,memdev=m1 \
-smp 2,sockets=2,maxcpus=2 \
On mambo I get:
[ 0.005069][ T1] smp: Bringing up secondary CPUs ...
[ 0.011656][ T1] smp: Brought up 2 nodes, 8 CPUs
[ 0.011682][ T1] numa: Node 0 CPUs: 0-3
[ 0.011709][ T1] numa: Node 1 CPUs: 4-7
[ 0.012015][ T1] BUG: arch topology borken
[ 0.012040][ T1] the SMT domain not a subset of the CACHE domain
[ 0.012107][ T1] BUG: Unable to handle kernel data access on read at 0x80000001012e7398
[ 0.012142][ T1] Faulting instruction address: 0xc0000000001aa4f0
[ 0.012174][ T1] Oops: Kernel access of bad area, sig: 11 [#1]
[ 0.012206][ T1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA PowerNV
[ 0.012236][ T1] Modules linked in:
[ 0.012264][ T1] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.9.0-rc2-00095-g7430ad5aa700 #1
[ 0.012304][ T1] NIP: c0000000001aa4f0 LR: c0000000001aa498 CTR: 0000000000000000
[ 0.012341][ T1] REGS: c0000000ef583880 TRAP: 0380 Not tainted (5.9.0-rc2-00095-g7430ad5aa700)
[ 0.012379][ T1] MSR: 9000000002009033 <SF,HV,VEC,EE,ME,IR,DR,RI,LE> CR: 44002222 XER: 00040000
[ 0.012439][ T1] CFAR: c0000000000101b0 IRQMASK: 0
[ 0.012439][ T1] GPR00: 0000000000000000 c0000000ef583b10 c0000000017fd000 0000000000004000
[ 0.012439][ T1] GPR04: 0000000000000000 0000000000000800 0000000000000000 0000000000000000
[ 0.012439][ T1] GPR08: 0000000000000000 c0000000012eb398 c0000000ffffc000 0000000000000000
[ 0.012439][ T1] GPR12: 0000000000000020 c0000000019f0000 00000000ffff8ad1 0000000000000000
[ 0.012439][ T1] GPR16: c0000000ef068658 c0000000018d7ba8 0000000000000008 c000000001690bb8
[ 0.012439][ T1] GPR20: c00000000182dc80 c0000000ef06be90 00000000ffff8ad1 c000000001014aa8
[ 0.012439][ T1] GPR24: 0000000000000917 c0000000ef068e00 0000000000000000 c0000000ef06be00
[ 0.012439][ T1] GPR28: 0000000000000001 c0000000ef068640 c0000000ef4a1800 c000000001832310
[ 0.012774][ T1] NIP [c0000000001aa4f0] build_sched_domains+0x5c0/0x14f0
[ 0.012812][ T1] LR [c0000000001aa498] build_sched_domains+0x568/0x14f0
[ 0.012842][ T1] Call Trace:
[ 0.012872][ T1] [c0000000ef583b10] [c0000000001aa3b4] build_sched_domains+0x484/0x14f0 (unreliable)
[ 0.012922][ T1] [c0000000ef583c50] [c0000000001ac3d8] sched_init_domains+0xd8/0x120
[ 0.012966][ T1] [c0000000ef583ca0] [c0000000011962d0] sched_init_smp+0x50/0xc4
[ 0.013008][ T1] [c0000000ef583cd0] [c00000000117451c] kernel_init_freeable+0x1b4/0x378
[ 0.013051][ T1] [c0000000ef583db0] [c000000000012994] kernel_init+0x2c/0x158
[ 0.013092][ T1] [c0000000ef583e20] [c00000000000d9d0] ret_from_kernel_thread+0x5c/0x6c
[ 0.013128][ T1] Instruction dump:
[ 0.013151][ T1] e93b003a 712a0040 552a05ee 418203c4 2c2a0000 3920006e 913b002c 41820034
[ 0.013206][ T1] 7c6307b4 e93d0020 78631f24 7d54182a <7d2a482a> f93b0080 7d404828 314a0001
[ 0.013267][ T1] ---[ end trace 1bf5f6f38a9fd096 ]---
Did I miss a lead-up patch?
See here for what I have applied:
https://github.com/linuxppc/linux/commits/next-test
cheers
^ permalink raw reply
* Re: [RFC PATCH v2 1/3] mm/gup: fix gup_fast with dynamic page table folding
From: Jason Gunthorpe @ 2020-09-11 11:19 UTC (permalink / raw)
To: peterz
Cc: Dave Hansen, linux-mm, Paul Mackerras, linux-sparc,
Alexander Gordeev, Claudio Imbrenda, Will Deacon, linux-arch,
linux-s390, Vasily Gorbik, Richard Weinberger, linux-x86,
Russell King, Christian Borntraeger, Ingo Molnar, Catalin Marinas,
Andrey Ryabinin, Gerald Schaefer, Heiko Carstens, Arnd Bergmann,
John Hubbard, Jeff Dike, linux-um, Borislav Petkov,
Andy Lutomirski, Thomas Gleixner, linux-arm, Dave Hansen,
linux-power, LKML, Andrew Morton, Linus Torvalds, Mike Rapoport
In-Reply-To: <20200911070939.GB1362448@hirez.programming.kicks-ass.net>
On Fri, Sep 11, 2020 at 09:09:39AM +0200, peterz@infradead.org wrote:
> On Thu, Sep 10, 2020 at 06:59:21PM -0300, Jason Gunthorpe wrote:
> > So, I suggest pXX_offset_unlocked()
>
> Urgh, no. Elsewhere in gup _unlocked() means it will take the lock
> itself (get_user_pages_unlocked()) -- although often it seems to mean
> the lock is already held (git grep _unlocked and marvel).
>
> What we want is _lockless().
This is clear to me!
Thanks,
Jason
^ permalink raw reply
* [PATCH] KVM: PPC: Don't return -ENOTSUPP to userspace in ioctls
From: Greg Kurz @ 2020-09-11 10:53 UTC (permalink / raw)
To: Paul Mackerras, Michael Ellerman; +Cc: trivial, linuxppc-dev, kvm-ppc
ENOTSUPP is a linux only thingy, the value of which is unknown to
userspace, not to be confused with ENOTSUP which linux maps to
EOPNOTSUPP, as permitted by POSIX [1]:
[EOPNOTSUPP]
Operation not supported on socket. The type of socket (address family
or protocol) does not support the requested operation. A conforming
implementation may assign the same values for [EOPNOTSUPP] and [ENOTSUP].
Return -EOPNOTSUPP instead of -ENOTSUPP for the following ioctls:
- KVM_GET_FPU for Book3s and BookE
- KVM_SET_FPU for Book3s and BookE
- KVM_GET_DIRTY_LOG for BookE
This doesn't affect QEMU which doesn't call the KVM_GET_FPU and
KVM_SET_FPU ioctls on POWER anyway since they are not supported,
and _buggily_ ignores anything but -EPERM for KVM_GET_DIRTY_LOG.
[1] https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html
Signed-off-by: Greg Kurz <groug@kaod.org>
---
arch/powerpc/kvm/book3s.c | 4 ++--
arch/powerpc/kvm/booke.c | 6 +++---
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index 1fce9777af1c..44bf567b6589 100644
--- a/arch/powerpc/kvm/book3s.c
+++ b/arch/powerpc/kvm/book3s.c
@@ -558,12 +558,12 @@ int kvm_arch_vcpu_ioctl_set_regs(struct kvm_vcpu *vcpu, struct kvm_regs *regs)
int kvm_arch_vcpu_ioctl_get_fpu(struct kvm_vcpu *vcpu, struct kvm_fpu *fpu)
{
- return -ENOTSUPP;
+ return -EOPNOTSUPP;
}
int kvm_arch_vcpu_ioctl_set_fpu(struct kvm_vcpu *vcpu, struct kvm_fpu *fpu)
{
- return -ENOTSUPP;
+ return -EOPNOTSUPP;
}
int kvmppc_get_one_reg(struct kvm_vcpu *vcpu, u64 id,
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index 3e1c9f08e302..b1abcb816439 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -1747,12 +1747,12 @@ int kvmppc_set_one_reg(struct kvm_vcpu *vcpu, u64 id,
int kvm_arch_vcpu_ioctl_get_fpu(struct kvm_vcpu *vcpu, struct kvm_fpu *fpu)
{
- return -ENOTSUPP;
+ return -EOPNOTSUPP;
}
int kvm_arch_vcpu_ioctl_set_fpu(struct kvm_vcpu *vcpu, struct kvm_fpu *fpu)
{
- return -ENOTSUPP;
+ return -EOPNOTSUPP;
}
int kvm_arch_vcpu_ioctl_translate(struct kvm_vcpu *vcpu,
@@ -1773,7 +1773,7 @@ void kvm_arch_sync_dirty_log(struct kvm *kvm, struct kvm_memory_slot *memslot)
int kvm_vm_ioctl_get_dirty_log(struct kvm *kvm, struct kvm_dirty_log *log)
{
- return -ENOTSUPP;
+ return -EOPNOTSUPP;
}
void kvmppc_core_free_memslot(struct kvm *kvm, struct kvm_memory_slot *slot)
^ permalink raw reply related
* [PATCH v4 4/8] mm/memory_hotplug: prepare passing flags to add_memory() and friends
From: David Hildenbrand @ 2020-09-11 10:34 UTC (permalink / raw)
To: linux-kernel
Cc: linux-hyperv, Michal Hocko, David Hildenbrand, Jason Wang,
Pingfan Liu, virtualization, linux-mm, Paul Mackerras,
K. Y. Srinivasan, Boris Ostrovsky, linux-s390, Wei Liu,
Stefano Stabellini, Dave Jiang, Baoquan He, linux-nvdimm,
Jason Gunthorpe, Michael S. Tsirkin, linux-acpi, xen-devel,
Heiko Carstens, Len Brown, Nathan Lynch, Vasily Gorbik,
Leonardo Bras, Haiyang Zhang, Stephen Hemminger, Dan Williams,
Christian Borntraeger, Juergen Gross, Pankaj Gupta,
Libor Pechacek, Greg Kroah-Hartman, Rafael J. Wysocki, Wei Yang,
Vishal Verma, Oliver O'Halloran, Andrew Morton, linuxppc-dev
In-Reply-To: <20200911103459.10306-1-david@redhat.com>
We soon want to pass flags, e.g., to mark added System RAM resources.
mergeable. Prepare for that.
This patch is based on a similar patch by Oscar Salvador:
https://lkml.kernel.org/r/20190625075227.15193-3-osalvador@suse.de
Acked-by: Wei Liu <wei.liu@kernel.org>
Reviewed-by: Juergen Gross <jgross@suse.com> # Xen related part
Reviewed-by: Pankaj Gupta <pankaj.gupta.linux@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Pankaj Gupta <pankaj.gupta.linux@gmail.com>
Cc: Baoquan He <bhe@redhat.com>
Cc: Wei Yang <richardw.yang@linux.intel.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Len Brown <lenb@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Vishal Verma <vishal.l.verma@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: "K. Y. Srinivasan" <kys@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Cc: Stephen Hemminger <sthemmin@microsoft.com>
Cc: Wei Liu <wei.liu@kernel.org>
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Jason Wang <jasowang@redhat.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>
Cc: "Oliver O'Halloran" <oohall@gmail.com>
Cc: Pingfan Liu <kernelfans@gmail.com>
Cc: Nathan Lynch <nathanl@linux.ibm.com>
Cc: Libor Pechacek <lpechacek@suse.cz>
Cc: Anton Blanchard <anton@ozlabs.org>
Cc: Leonardo Bras <leobras.c@gmail.com>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-acpi@vger.kernel.org
Cc: linux-nvdimm@lists.01.org
Cc: linux-hyperv@vger.kernel.org
Cc: linux-s390@vger.kernel.org
Cc: virtualization@lists.linux-foundation.org
Cc: xen-devel@lists.xenproject.org
Signed-off-by: David Hildenbrand <david@redhat.com>
---
arch/powerpc/platforms/powernv/memtrace.c | 2 +-
arch/powerpc/platforms/pseries/hotplug-memory.c | 2 +-
drivers/acpi/acpi_memhotplug.c | 3 ++-
drivers/base/memory.c | 3 ++-
drivers/dax/kmem.c | 2 +-
drivers/hv/hv_balloon.c | 2 +-
drivers/s390/char/sclp_cmd.c | 2 +-
drivers/virtio/virtio_mem.c | 2 +-
drivers/xen/balloon.c | 2 +-
include/linux/memory_hotplug.h | 16 ++++++++++++----
mm/memory_hotplug.c | 14 +++++++-------
11 files changed, 30 insertions(+), 20 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/memtrace.c b/arch/powerpc/platforms/powernv/memtrace.c
index 13b369d2cc454..6828108486f83 100644
--- a/arch/powerpc/platforms/powernv/memtrace.c
+++ b/arch/powerpc/platforms/powernv/memtrace.c
@@ -224,7 +224,7 @@ static int memtrace_online(void)
ent->mem = 0;
}
- if (add_memory(ent->nid, ent->start, ent->size)) {
+ if (add_memory(ent->nid, ent->start, ent->size, MHP_NONE)) {
pr_err("Failed to add trace memory to node %d\n",
ent->nid);
ret += 1;
diff --git a/arch/powerpc/platforms/pseries/hotplug-memory.c b/arch/powerpc/platforms/pseries/hotplug-memory.c
index 0ea976d1cac47..e1c9fa0d730f5 100644
--- a/arch/powerpc/platforms/pseries/hotplug-memory.c
+++ b/arch/powerpc/platforms/pseries/hotplug-memory.c
@@ -615,7 +615,7 @@ static int dlpar_add_lmb(struct drmem_lmb *lmb)
nid = memory_add_physaddr_to_nid(lmb->base_addr);
/* Add the memory */
- rc = __add_memory(nid, lmb->base_addr, block_sz);
+ rc = __add_memory(nid, lmb->base_addr, block_sz, MHP_NONE);
if (rc) {
invalidate_lmb_associativity_index(lmb);
return rc;
diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c
index e294f44a78504..2067c3bc55763 100644
--- a/drivers/acpi/acpi_memhotplug.c
+++ b/drivers/acpi/acpi_memhotplug.c
@@ -207,7 +207,8 @@ static int acpi_memory_enable_device(struct acpi_memory_device *mem_device)
if (node < 0)
node = memory_add_physaddr_to_nid(info->start_addr);
- result = __add_memory(node, info->start_addr, info->length);
+ result = __add_memory(node, info->start_addr, info->length,
+ MHP_NONE);
/*
* If the memory block has been used by the kernel, add_memory()
diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index 4db3c660de831..b4c297dd04755 100644
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -432,7 +432,8 @@ static ssize_t probe_store(struct device *dev, struct device_attribute *attr,
nid = memory_add_physaddr_to_nid(phys_addr);
ret = __add_memory(nid, phys_addr,
- MIN_MEMORY_BLOCK_SIZE * sections_per_block);
+ MIN_MEMORY_BLOCK_SIZE * sections_per_block,
+ MHP_NONE);
if (ret)
goto out;
diff --git a/drivers/dax/kmem.c b/drivers/dax/kmem.c
index 7dcb2902e9b1b..896cb9444e727 100644
--- a/drivers/dax/kmem.c
+++ b/drivers/dax/kmem.c
@@ -95,7 +95,7 @@ int dev_dax_kmem_probe(struct dev_dax *dev_dax)
* this as RAM automatically.
*/
rc = add_memory_driver_managed(numa_node, range.start,
- range_len(&range), kmem_name);
+ range_len(&range), kmem_name, MHP_NONE);
res->flags |= IORESOURCE_BUSY;
if (rc) {
diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
index 32e3bc0aa665a..3c0d52e244520 100644
--- a/drivers/hv/hv_balloon.c
+++ b/drivers/hv/hv_balloon.c
@@ -726,7 +726,7 @@ static void hv_mem_hot_add(unsigned long start, unsigned long size,
nid = memory_add_physaddr_to_nid(PFN_PHYS(start_pfn));
ret = add_memory(nid, PFN_PHYS((start_pfn)),
- (HA_CHUNK << PAGE_SHIFT));
+ (HA_CHUNK << PAGE_SHIFT), MHP_NONE);
if (ret) {
pr_err("hot_add memory failed error is %d\n", ret);
diff --git a/drivers/s390/char/sclp_cmd.c b/drivers/s390/char/sclp_cmd.c
index a864b21af602a..f6e97f0830f64 100644
--- a/drivers/s390/char/sclp_cmd.c
+++ b/drivers/s390/char/sclp_cmd.c
@@ -406,7 +406,7 @@ static void __init add_memory_merged(u16 rn)
if (!size)
goto skip_add;
for (addr = start; addr < start + size; addr += block_size)
- add_memory(0, addr, block_size);
+ add_memory(0, addr, block_size, MHP_NONE);
skip_add:
first_rn = rn;
num = 1;
diff --git a/drivers/virtio/virtio_mem.c b/drivers/virtio/virtio_mem.c
index 834b7c13ef3dc..ed99e43354010 100644
--- a/drivers/virtio/virtio_mem.c
+++ b/drivers/virtio/virtio_mem.c
@@ -424,7 +424,7 @@ static int virtio_mem_mb_add(struct virtio_mem *vm, unsigned long mb_id)
dev_dbg(&vm->vdev->dev, "adding memory block: %lu\n", mb_id);
return add_memory_driver_managed(nid, addr, memory_block_size_bytes(),
- vm->resource_name);
+ vm->resource_name, MHP_NONE);
}
/*
diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index 51427c752b37b..9f40a294d398d 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -331,7 +331,7 @@ static enum bp_state reserve_additional_memory(void)
mutex_unlock(&balloon_mutex);
/* add_memory_resource() requires the device_hotplug lock */
lock_device_hotplug();
- rc = add_memory_resource(nid, resource);
+ rc = add_memory_resource(nid, resource, MHP_NONE);
unlock_device_hotplug();
mutex_lock(&balloon_mutex);
diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
index 1504b4d5ae6ce..33eb80fdba22f 100644
--- a/include/linux/memory_hotplug.h
+++ b/include/linux/memory_hotplug.h
@@ -57,6 +57,12 @@ enum {
MMOP_ONLINE_MOVABLE,
};
+/* Flags for add_memory() and friends to specify memory hotplug details. */
+typedef int __bitwise mhp_t;
+
+/* No special request */
+#define MHP_NONE ((__force mhp_t)0)
+
/*
* Extended parameters for memory hotplug:
* altmap: alternative allocator for memmap array (optional)
@@ -339,11 +345,13 @@ extern void clear_zone_contiguous(struct zone *zone);
#ifdef CONFIG_MEMORY_HOTPLUG
extern void __ref free_area_init_core_hotplug(int nid);
-extern int __add_memory(int nid, u64 start, u64 size);
-extern int add_memory(int nid, u64 start, u64 size);
-extern int add_memory_resource(int nid, struct resource *resource);
+extern int __add_memory(int nid, u64 start, u64 size, mhp_t mhp_flags);
+extern int add_memory(int nid, u64 start, u64 size, mhp_t mhp_flags);
+extern int add_memory_resource(int nid, struct resource *resource,
+ mhp_t mhp_flags);
extern int add_memory_driver_managed(int nid, u64 start, u64 size,
- const char *resource_name);
+ const char *resource_name,
+ mhp_t mhp_flags);
extern void move_pfn_range_to_zone(struct zone *zone, unsigned long start_pfn,
unsigned long nr_pages,
struct vmem_altmap *altmap, int migratetype);
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 8e1cd18b5cf14..8f0bd7c9a63a5 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -1039,7 +1039,7 @@ static int online_memory_block(struct memory_block *mem, void *arg)
*
* we are OK calling __meminit stuff here - we have CONFIG_MEMORY_HOTPLUG
*/
-int __ref add_memory_resource(int nid, struct resource *res)
+int __ref add_memory_resource(int nid, struct resource *res, mhp_t mhp_flags)
{
struct mhp_params params = { .pgprot = PAGE_KERNEL };
u64 start, size;
@@ -1118,7 +1118,7 @@ int __ref add_memory_resource(int nid, struct resource *res)
}
/* requires device_hotplug_lock, see add_memory_resource() */
-int __ref __add_memory(int nid, u64 start, u64 size)
+int __ref __add_memory(int nid, u64 start, u64 size, mhp_t mhp_flags)
{
struct resource *res;
int ret;
@@ -1127,18 +1127,18 @@ int __ref __add_memory(int nid, u64 start, u64 size)
if (IS_ERR(res))
return PTR_ERR(res);
- ret = add_memory_resource(nid, res);
+ ret = add_memory_resource(nid, res, mhp_flags);
if (ret < 0)
release_memory_resource(res);
return ret;
}
-int add_memory(int nid, u64 start, u64 size)
+int add_memory(int nid, u64 start, u64 size, mhp_t mhp_flags)
{
int rc;
lock_device_hotplug();
- rc = __add_memory(nid, start, size);
+ rc = __add_memory(nid, start, size, mhp_flags);
unlock_device_hotplug();
return rc;
@@ -1167,7 +1167,7 @@ EXPORT_SYMBOL_GPL(add_memory);
* "System RAM ($DRIVER)".
*/
int add_memory_driver_managed(int nid, u64 start, u64 size,
- const char *resource_name)
+ const char *resource_name, mhp_t mhp_flags)
{
struct resource *res;
int rc;
@@ -1185,7 +1185,7 @@ int add_memory_driver_managed(int nid, u64 start, u64 size,
goto out_unlock;
}
- rc = add_memory_resource(nid, res);
+ rc = add_memory_resource(nid, res, mhp_flags);
if (rc < 0)
release_memory_resource(res);
--
2.26.2
^ permalink raw reply related
* Re: [PATCH] powerpc/powermac: Fix low_sleep_handler with KUAP and KUEP
From: Christophe Leroy @ 2020-09-11 10:30 UTC (permalink / raw)
To: Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <871rj9rxt1.fsf@mpe.ellerman.id.au>
Le 11/09/2020 à 01:56, Michael Ellerman a écrit :
> Christophe Leroy <christophe.leroy@csgroup.eu> writes:
>> low_sleep_handler() has an hardcoded restore of segment registers
>> that doesn't take KUAP and KUEP into account.
>>
>> Use head_32's load_segment_registers() routine instead.
>>
>> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
>> Fixes: a68c31fc01ef ("powerpc/32s: Implement Kernel Userspace Access Protection")
>> Fixes: 31ed2b13c48d ("powerpc/32s: Implement Kernel Userspace Execution Prevention.")
>> Cc: stable@vger.kernel.org
>> ---
>> arch/powerpc/platforms/powermac/sleep.S | 9 +--------
>> 1 file changed, 1 insertion(+), 8 deletions(-)
>
> Doesn't build? pmac32_defconfig, gcc 9.3.0:
>
> ld: arch/powerpc/platforms/powermac/sleep.o: in function `core99_wake_up':
> (.text+0x25c): undefined reference to `load_segment_registers'
>
> Missing _GLOBAL() presumably?
Oops .. :(
v2 sent out.
Thanks
Christophe
^ permalink raw reply
* Re: [PATCH v1] pseries/hotplug-memory: hot-add: skip redundant LMB lookup
From: kernel test robot @ 2020-09-11 10:28 UTC (permalink / raw)
To: Scott Cheloha, linuxppc-dev
Cc: Nathan Lynch, Laurent Dufour, kbuild-all, David Hildenbrand,
Michal Suchanek, Rick Lindsley
In-Reply-To: <20200910175637.2865160-1-cheloha@linux.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 2978 bytes --]
Hi Scott,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on powerpc/next]
[also build test WARNING on next-20200910]
[cannot apply to v5.9-rc4]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Scott-Cheloha/pseries-hotplug-memory-hot-add-skip-redundant-LMB-lookup/20200911-015744
base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: powerpc-allyesconfig (attached as .config)
compiler: powerpc64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
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 COMPILER=gcc-9.3.0 make.cross ARCH=powerpc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All warnings (new ones prefixed by >>):
>> arch/powerpc/mm/numa.c:433:5: warning: no previous prototype for 'of_drconf_to_nid_single' [-Wmissing-prototypes]
433 | int of_drconf_to_nid_single(struct drmem_lmb *lmb)
| ^~~~~~~~~~~~~~~~~~~~~~~
# https://github.com/0day-ci/linux/commit/e6847f3f58460841a28885578cc3547735cfa50c
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Scott-Cheloha/pseries-hotplug-memory-hot-add-skip-redundant-LMB-lookup/20200911-015744
git checkout e6847f3f58460841a28885578cc3547735cfa50c
vim +/of_drconf_to_nid_single +433 arch/powerpc/mm/numa.c
428
429 /*
430 * This is like of_node_to_nid_single() for memory represented in the
431 * ibm,dynamic-reconfiguration-memory node.
432 */
> 433 int of_drconf_to_nid_single(struct drmem_lmb *lmb)
434 {
435 struct assoc_arrays aa = { .arrays = NULL };
436 int default_nid = NUMA_NO_NODE;
437 int nid = default_nid;
438 int rc, index;
439
440 if ((min_common_depth < 0) || !numa_enabled)
441 return default_nid;
442
443 rc = of_get_assoc_arrays(&aa);
444 if (rc)
445 return default_nid;
446
447 if (min_common_depth <= aa.array_sz &&
448 !(lmb->flags & DRCONF_MEM_AI_INVALID) && lmb->aa_index < aa.n_arrays) {
449 index = lmb->aa_index * aa.array_sz + min_common_depth - 1;
450 nid = of_read_number(&aa.arrays[index], 1);
451
452 if (nid == 0xffff || nid >= nr_node_ids)
453 nid = default_nid;
454
455 if (nid > 0) {
456 index = lmb->aa_index * aa.array_sz;
457 initialize_distance_lookup_table(nid,
458 &aa.arrays[index]);
459 }
460 }
461
462 return nid;
463 }
464
---
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: 70367 bytes --]
^ permalink raw reply
* [PATCH v2] powerpc/powermac: Fix low_sleep_handler with KUAP and KUEP
From: Christophe Leroy @ 2020-09-11 10:29 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
low_sleep_handler() has an hardcoded restore of segment registers
that doesn't take KUAP and KUEP into account.
Use head_32's load_segment_registers() routine instead.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Fixes: a68c31fc01ef ("powerpc/32s: Implement Kernel Userspace Access Protection")
Fixes: 31ed2b13c48d ("powerpc/32s: Implement Kernel Userspace Execution Prevention.")
Cc: stable@vger.kernel.org
---
v2: Added missing _GLOBAL() to load_segment_registers in head_32.S
---
arch/powerpc/kernel/head_32.S | 2 +-
arch/powerpc/platforms/powermac/sleep.S | 9 +--------
2 files changed, 2 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/kernel/head_32.S b/arch/powerpc/kernel/head_32.S
index 5624db0e09a1..0f60743474a2 100644
--- a/arch/powerpc/kernel/head_32.S
+++ b/arch/powerpc/kernel/head_32.S
@@ -1002,7 +1002,7 @@ BEGIN_MMU_FTR_SECTION
END_MMU_FTR_SECTION_IFSET(MMU_FTR_USE_HIGH_BATS)
blr
-load_segment_registers:
+_GLOBAL(load_segment_registers)
li r0, NUM_USER_SEGMENTS /* load up user segment register values */
mtctr r0 /* for context 0 */
li r3, 0 /* Kp = 0, Ks = 0, VSID = 0 */
diff --git a/arch/powerpc/platforms/powermac/sleep.S b/arch/powerpc/platforms/powermac/sleep.S
index f9a680fdd9c4..51bfdfe85058 100644
--- a/arch/powerpc/platforms/powermac/sleep.S
+++ b/arch/powerpc/platforms/powermac/sleep.S
@@ -294,14 +294,7 @@ grackle_wake_up:
* we do any r1 memory access as we are not sure they
* are in a sane state above the first 256Mb region
*/
- li r0,16 /* load up segment register values */
- mtctr r0 /* for context 0 */
- lis r3,0x2000 /* Ku = 1, VSID = 0 */
- li r4,0
-3: mtsrin r3,r4
- addi r3,r3,0x111 /* increment VSID */
- addis r4,r4,0x1000 /* address of next segment */
- bdnz 3b
+ bl load_segment_registers
sync
isync
--
2.25.0
^ permalink raw reply related
* Re: [PATCH] powerpc/traps: fix recoverability of machine check handling on book3s/32
From: Christophe Leroy @ 2020-09-11 9:54 UTC (permalink / raw)
To: Michal Suchánek
Cc: linux-kernel, Nicholas Piggin, Paul Mackerras, linuxppc-dev
In-Reply-To: <20200911091542.GE29521@kitsune.suse.cz>
Hello,
Le 11/09/2020 à 11:15, Michal Suchánek a écrit :
> Hello,
>
> does this logic apply to "Unrecoverable System Reset" as well?
I don't know, I don't think I have any way the generate a System Reset
on my board to check it.
Christophe
>
> Thanks
>
> Michal
>
> On Tue, Jan 22, 2019 at 02:11:24PM +0000, Christophe Leroy wrote:
>> Looks like book3s/32 doesn't set RI on machine check, so
>> checking RI before calling die() will always be fatal
>> allthought this is not an issue in most cases.
>>
>> Fixes: b96672dd840f ("powerpc: Machine check interrupt is a non-maskable interrupt")
>> Fixes: daf00ae71dad ("powerpc/traps: restore recoverability of machine_check interrupts")
>> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
>> Cc: stable@vger.kernel.org
>> ---
>> arch/powerpc/kernel/traps.c | 8 ++++----
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
>> index 64936b60d521..c740f8bfccc9 100644
>> --- a/arch/powerpc/kernel/traps.c
>> +++ b/arch/powerpc/kernel/traps.c
>> @@ -763,15 +763,15 @@ void machine_check_exception(struct pt_regs *regs)
>> if (check_io_access(regs))
>> goto bail;
>>
>> - /* Must die if the interrupt is not recoverable */
>> - if (!(regs->msr & MSR_RI))
>> - nmi_panic(regs, "Unrecoverable Machine check");
>> -
>> if (!nested)
>> nmi_exit();
>>
>> die("Machine check", regs, SIGBUS);
>>
>> + /* Must die if the interrupt is not recoverable */
>> + if (!(regs->msr & MSR_RI))
>> + nmi_panic(regs, "Unrecoverable Machine check");
>> +
>> return;
>>
>> bail:
>> --
>> 2.13.3
>>
^ permalink raw reply
* Re: [PATCH] powerpc/traps: fix recoverability of machine check handling on book3s/32
From: Michal Suchánek @ 2020-09-11 9:15 UTC (permalink / raw)
To: Christophe Leroy
Cc: linux-kernel, Nicholas Piggin, Paul Mackerras, linuxppc-dev
In-Reply-To: <1c804764d38fb084b420b12ca13e8c1b2dea075e.1548166189.git.christophe.leroy@c-s.fr>
Hello,
does this logic apply to "Unrecoverable System Reset" as well?
Thanks
Michal
On Tue, Jan 22, 2019 at 02:11:24PM +0000, Christophe Leroy wrote:
> Looks like book3s/32 doesn't set RI on machine check, so
> checking RI before calling die() will always be fatal
> allthought this is not an issue in most cases.
>
> Fixes: b96672dd840f ("powerpc: Machine check interrupt is a non-maskable interrupt")
> Fixes: daf00ae71dad ("powerpc/traps: restore recoverability of machine_check interrupts")
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
> Cc: stable@vger.kernel.org
> ---
> arch/powerpc/kernel/traps.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
> index 64936b60d521..c740f8bfccc9 100644
> --- a/arch/powerpc/kernel/traps.c
> +++ b/arch/powerpc/kernel/traps.c
> @@ -763,15 +763,15 @@ void machine_check_exception(struct pt_regs *regs)
> if (check_io_access(regs))
> goto bail;
>
> - /* Must die if the interrupt is not recoverable */
> - if (!(regs->msr & MSR_RI))
> - nmi_panic(regs, "Unrecoverable Machine check");
> -
> if (!nested)
> nmi_exit();
>
> die("Machine check", regs, SIGBUS);
>
> + /* Must die if the interrupt is not recoverable */
> + if (!(regs->msr & MSR_RI))
> + nmi_panic(regs, "Unrecoverable Machine check");
> +
> return;
>
> bail:
> --
> 2.13.3
>
^ permalink raw reply
* Re: [PATCH 1/7] powerpc/sysfs: Fix W=1 compile warning
From: Cédric Le Goater @ 2020-09-11 9:10 UTC (permalink / raw)
To: Christophe Leroy, Michael Ellerman; +Cc: Madhavan Srinivasan, linuxppc-dev
In-Reply-To: <622dc63b-d3ad-3d7e-b796-7b99db9746c4@csgroup.eu>
On 9/11/20 7:26 AM, Christophe Leroy wrote:
>
>
> Le 10/09/2020 à 23:02, Cédric Le Goater a écrit :
>> arch/powerpc/kernel/sysfs.c: In function ‘sysfs_create_dscr_default’:
>> arch/powerpc/kernel/sysfs.c:228:7: error: variable ‘err’ set but not used [-Werror=unused-but-set-variable]
>> int err = 0;
>> ^~~
>> cc1: all warnings being treated as errors
>
> A small sentence explaining how this is fixes would be welcome, so that you don't need to read the code the know what the commit does to fix the warning. Even the subject should be more explicite, rather than saying "Fix W=1 compile warning", I think it should say something like "remove unused err variable"
Yes. I will respin a v2 with better commit logs for all.
Thanks,
C.
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Book3S HV: Do not allocate HPT for a nested guest
From: Greg Kurz @ 2020-09-11 8:17 UTC (permalink / raw)
To: Michal Suchánek; +Cc: david, linuxppc-dev, kvm-ppc, kvm, Fabiano Rosas
In-Reply-To: <20200911080810.GD29521@kitsune.suse.cz>
On Fri, 11 Sep 2020 10:08:10 +0200
Michal Suchánek <msuchanek@suse.de> wrote:
> On Fri, Sep 11, 2020 at 10:01:33AM +0200, Greg Kurz wrote:
> > On Fri, 11 Sep 2020 09:45:36 +0200
> > Greg Kurz <groug@kaod.org> wrote:
> >
> > > On Fri, 11 Sep 2020 01:16:07 -0300
> > > Fabiano Rosas <farosas@linux.ibm.com> wrote:
> > >
> > > > The current nested KVM code does not support HPT guests. This is
> > > > informed/enforced in some ways:
> > > >
> > > > - Hosts < P9 will not be able to enable the nested HV feature;
> > > >
> > > > - The nested hypervisor MMU capabilities will not contain
> > > > KVM_CAP_PPC_MMU_HASH_V3;
> > > >
> > > > - QEMU reflects the MMU capabilities in the
> > > > 'ibm,arch-vec-5-platform-support' device-tree property;
> > > >
> > > > - The nested guest, at 'prom_parse_mmu_model' ignores the
> > > > 'disable_radix' kernel command line option if HPT is not supported;
> > > >
> > > > - The KVM_PPC_CONFIGURE_V3_MMU ioctl will fail if trying to use HPT.
> > > >
> > > > There is, however, still a way to start a HPT guest by using
> > > > max-compat-cpu=power8 at the QEMU machine options. This leads to the
> > > > guest being set to use hash after QEMU calls the KVM_PPC_ALLOCATE_HTAB
> > > > ioctl.
> > > >
> > > > With the guest set to hash, the nested hypervisor goes through the
> > > > entry path that has no knowledge of nesting (kvmppc_run_vcpu) and
> > > > crashes when it tries to execute an hypervisor-privileged (mtspr
> > > > HDEC) instruction at __kvmppc_vcore_entry:
> > > >
> > > > root@L1:~ $ qemu-system-ppc64 -machine pseries,max-cpu-compat=power8 ...
> > > >
> > > > <snip>
> > > > [ 538.543303] CPU: 83 PID: 25185 Comm: CPU 0/KVM Not tainted 5.9.0-rc4 #1
> > > > [ 538.543355] NIP: c00800000753f388 LR: c00800000753f368 CTR: c0000000001e5ec0
> > > > [ 538.543417] REGS: c0000013e91e33b0 TRAP: 0700 Not tainted (5.9.0-rc4)
> > > > [ 538.543470] MSR: 8000000002843033 <SF,VEC,VSX,FP,ME,IR,DR,RI,LE> CR: 22422882 XER: 20040000
> > > > [ 538.543546] CFAR: c00800000753f4b0 IRQMASK: 3
> > > > GPR00: c0080000075397a0 c0000013e91e3640 c00800000755e600 0000000080000000
> > > > GPR04: 0000000000000000 c0000013eab19800 c000001394de0000 00000043a054db72
> > > > GPR08: 00000000003b1652 0000000000000000 0000000000000000 c0080000075502e0
> > > > GPR12: c0000000001e5ec0 c0000007ffa74200 c0000013eab19800 0000000000000008
> > > > GPR16: 0000000000000000 c00000139676c6c0 c000000001d23948 c0000013e91e38b8
> > > > GPR20: 0000000000000053 0000000000000000 0000000000000001 0000000000000000
> > > > GPR24: 0000000000000001 0000000000000001 0000000000000000 0000000000000001
> > > > GPR28: 0000000000000001 0000000000000053 c0000013eab19800 0000000000000001
> > > > [ 538.544067] NIP [c00800000753f388] __kvmppc_vcore_entry+0x90/0x104 [kvm_hv]
> > > > [ 538.544121] LR [c00800000753f368] __kvmppc_vcore_entry+0x70/0x104 [kvm_hv]
> > > > [ 538.544173] Call Trace:
> > > > [ 538.544196] [c0000013e91e3640] [c0000013e91e3680] 0xc0000013e91e3680 (unreliable)
> > > > [ 538.544260] [c0000013e91e3820] [c0080000075397a0] kvmppc_run_core+0xbc8/0x19d0 [kvm_hv]
> > > > [ 538.544325] [c0000013e91e39e0] [c00800000753d99c] kvmppc_vcpu_run_hv+0x404/0xc00 [kvm_hv]
> > > > [ 538.544394] [c0000013e91e3ad0] [c0080000072da4fc] kvmppc_vcpu_run+0x34/0x48 [kvm]
> > > > [ 538.544472] [c0000013e91e3af0] [c0080000072d61b8] kvm_arch_vcpu_ioctl_run+0x310/0x420 [kvm]
> > > > [ 538.544539] [c0000013e91e3b80] [c0080000072c7450] kvm_vcpu_ioctl+0x298/0x778 [kvm]
> > > > [ 538.544605] [c0000013e91e3ce0] [c0000000004b8c2c] sys_ioctl+0x1dc/0xc90
> > > > [ 538.544662] [c0000013e91e3dc0] [c00000000002f9a4] system_call_exception+0xe4/0x1c0
> > > > [ 538.544726] [c0000013e91e3e20] [c00000000000d140] system_call_common+0xf0/0x27c
> > > > [ 538.544787] Instruction dump:
> > > > [ 538.544821] f86d1098 60000000 60000000 48000099 e8ad0fe8 e8c500a0 e9264140 75290002
> > > > [ 538.544886] 7d1602a6 7cec42a6 40820008 7d0807b4 <7d164ba6> 7d083a14 f90d10a0 480104fd
> > > > [ 538.544953] ---[ end trace 74423e2b948c2e0c ]---
> > > >
> > > > This patch makes the KVM_PPC_ALLOCATE_HTAB ioctl fail when running in
> > > > the nested hypervisor, causing QEMU to abort.
> > > >
> > > > Reported-by: Satheesh Rajendran <sathnaga@linux.vnet.ibm.com>
> > > > Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
> > > > ---
> > >
> > > LGTM
> > >
> > > Reviewed-by: Greg Kurz <groug@kaod.org>
> > >
> > > > arch/powerpc/kvm/book3s_hv.c | 6 ++++++
> > > > 1 file changed, 6 insertions(+)
> > > >
> > > > diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
> > > > index 4ba06a2a306c..764b6239ef72 100644
> > > > --- a/arch/powerpc/kvm/book3s_hv.c
> > > > +++ b/arch/powerpc/kvm/book3s_hv.c
> > > > @@ -5250,6 +5250,12 @@ static long kvm_arch_vm_ioctl_hv(struct file *filp,
> > > > case KVM_PPC_ALLOCATE_HTAB: {
> > > > u32 htab_order;
> > > >
> > > > + /* If we're a nested hypervisor, we currently only support radix */
> > > > + if (kvmhv_on_pseries()) {
> > > > + r = -EOPNOTSUPP;
> >
> > According to POSIX [1]:
> >
> > [ENOTSUP]
> > Not supported. The implementation does not support the requested feature or value.
> >
> > [EOPNOTSUPP]
> > Operation not supported on socket. The type of socket (address family or protocol) does not support the requested operation. A conforming implementation may assign the same values for [EOPNOTSUPP] and [ENOTSUP].
> >
> > Even if these two happen to be equal in linux, it seems that ENOTSUP, which
> > doesn't refer to sockets, is more appropriate.
> >
> > [1] https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html
>
> Which in Linux kernel maps to a completely bogus value not recognized by
> userspace.
>
There's no such thing as ENOTSUP in Linux actually :)
Linux has ENOTSUPP which indeed doesn't map to anything usable by
userspace... very unfortunate naming :-(
> So when you mean ENOTSUP use EOPNOTSUPP in Linux.
>
Right. So this patch is good as it is.
Cheers,
--
Greg
> Thanks
>
> Michal
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Book3S HV: Do not allocate HPT for a nested guest
From: Michal Suchánek @ 2020-09-11 8:08 UTC (permalink / raw)
To: Greg Kurz; +Cc: david, linuxppc-dev, kvm-ppc, kvm, Fabiano Rosas
In-Reply-To: <20200911100133.49d22e82@bahia.lan>
On Fri, Sep 11, 2020 at 10:01:33AM +0200, Greg Kurz wrote:
> On Fri, 11 Sep 2020 09:45:36 +0200
> Greg Kurz <groug@kaod.org> wrote:
>
> > On Fri, 11 Sep 2020 01:16:07 -0300
> > Fabiano Rosas <farosas@linux.ibm.com> wrote:
> >
> > > The current nested KVM code does not support HPT guests. This is
> > > informed/enforced in some ways:
> > >
> > > - Hosts < P9 will not be able to enable the nested HV feature;
> > >
> > > - The nested hypervisor MMU capabilities will not contain
> > > KVM_CAP_PPC_MMU_HASH_V3;
> > >
> > > - QEMU reflects the MMU capabilities in the
> > > 'ibm,arch-vec-5-platform-support' device-tree property;
> > >
> > > - The nested guest, at 'prom_parse_mmu_model' ignores the
> > > 'disable_radix' kernel command line option if HPT is not supported;
> > >
> > > - The KVM_PPC_CONFIGURE_V3_MMU ioctl will fail if trying to use HPT.
> > >
> > > There is, however, still a way to start a HPT guest by using
> > > max-compat-cpu=power8 at the QEMU machine options. This leads to the
> > > guest being set to use hash after QEMU calls the KVM_PPC_ALLOCATE_HTAB
> > > ioctl.
> > >
> > > With the guest set to hash, the nested hypervisor goes through the
> > > entry path that has no knowledge of nesting (kvmppc_run_vcpu) and
> > > crashes when it tries to execute an hypervisor-privileged (mtspr
> > > HDEC) instruction at __kvmppc_vcore_entry:
> > >
> > > root@L1:~ $ qemu-system-ppc64 -machine pseries,max-cpu-compat=power8 ...
> > >
> > > <snip>
> > > [ 538.543303] CPU: 83 PID: 25185 Comm: CPU 0/KVM Not tainted 5.9.0-rc4 #1
> > > [ 538.543355] NIP: c00800000753f388 LR: c00800000753f368 CTR: c0000000001e5ec0
> > > [ 538.543417] REGS: c0000013e91e33b0 TRAP: 0700 Not tainted (5.9.0-rc4)
> > > [ 538.543470] MSR: 8000000002843033 <SF,VEC,VSX,FP,ME,IR,DR,RI,LE> CR: 22422882 XER: 20040000
> > > [ 538.543546] CFAR: c00800000753f4b0 IRQMASK: 3
> > > GPR00: c0080000075397a0 c0000013e91e3640 c00800000755e600 0000000080000000
> > > GPR04: 0000000000000000 c0000013eab19800 c000001394de0000 00000043a054db72
> > > GPR08: 00000000003b1652 0000000000000000 0000000000000000 c0080000075502e0
> > > GPR12: c0000000001e5ec0 c0000007ffa74200 c0000013eab19800 0000000000000008
> > > GPR16: 0000000000000000 c00000139676c6c0 c000000001d23948 c0000013e91e38b8
> > > GPR20: 0000000000000053 0000000000000000 0000000000000001 0000000000000000
> > > GPR24: 0000000000000001 0000000000000001 0000000000000000 0000000000000001
> > > GPR28: 0000000000000001 0000000000000053 c0000013eab19800 0000000000000001
> > > [ 538.544067] NIP [c00800000753f388] __kvmppc_vcore_entry+0x90/0x104 [kvm_hv]
> > > [ 538.544121] LR [c00800000753f368] __kvmppc_vcore_entry+0x70/0x104 [kvm_hv]
> > > [ 538.544173] Call Trace:
> > > [ 538.544196] [c0000013e91e3640] [c0000013e91e3680] 0xc0000013e91e3680 (unreliable)
> > > [ 538.544260] [c0000013e91e3820] [c0080000075397a0] kvmppc_run_core+0xbc8/0x19d0 [kvm_hv]
> > > [ 538.544325] [c0000013e91e39e0] [c00800000753d99c] kvmppc_vcpu_run_hv+0x404/0xc00 [kvm_hv]
> > > [ 538.544394] [c0000013e91e3ad0] [c0080000072da4fc] kvmppc_vcpu_run+0x34/0x48 [kvm]
> > > [ 538.544472] [c0000013e91e3af0] [c0080000072d61b8] kvm_arch_vcpu_ioctl_run+0x310/0x420 [kvm]
> > > [ 538.544539] [c0000013e91e3b80] [c0080000072c7450] kvm_vcpu_ioctl+0x298/0x778 [kvm]
> > > [ 538.544605] [c0000013e91e3ce0] [c0000000004b8c2c] sys_ioctl+0x1dc/0xc90
> > > [ 538.544662] [c0000013e91e3dc0] [c00000000002f9a4] system_call_exception+0xe4/0x1c0
> > > [ 538.544726] [c0000013e91e3e20] [c00000000000d140] system_call_common+0xf0/0x27c
> > > [ 538.544787] Instruction dump:
> > > [ 538.544821] f86d1098 60000000 60000000 48000099 e8ad0fe8 e8c500a0 e9264140 75290002
> > > [ 538.544886] 7d1602a6 7cec42a6 40820008 7d0807b4 <7d164ba6> 7d083a14 f90d10a0 480104fd
> > > [ 538.544953] ---[ end trace 74423e2b948c2e0c ]---
> > >
> > > This patch makes the KVM_PPC_ALLOCATE_HTAB ioctl fail when running in
> > > the nested hypervisor, causing QEMU to abort.
> > >
> > > Reported-by: Satheesh Rajendran <sathnaga@linux.vnet.ibm.com>
> > > Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
> > > ---
> >
> > LGTM
> >
> > Reviewed-by: Greg Kurz <groug@kaod.org>
> >
> > > arch/powerpc/kvm/book3s_hv.c | 6 ++++++
> > > 1 file changed, 6 insertions(+)
> > >
> > > diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
> > > index 4ba06a2a306c..764b6239ef72 100644
> > > --- a/arch/powerpc/kvm/book3s_hv.c
> > > +++ b/arch/powerpc/kvm/book3s_hv.c
> > > @@ -5250,6 +5250,12 @@ static long kvm_arch_vm_ioctl_hv(struct file *filp,
> > > case KVM_PPC_ALLOCATE_HTAB: {
> > > u32 htab_order;
> > >
> > > + /* If we're a nested hypervisor, we currently only support radix */
> > > + if (kvmhv_on_pseries()) {
> > > + r = -EOPNOTSUPP;
>
> According to POSIX [1]:
>
> [ENOTSUP]
> Not supported. The implementation does not support the requested feature or value.
>
> [EOPNOTSUPP]
> Operation not supported on socket. The type of socket (address family or protocol) does not support the requested operation. A conforming implementation may assign the same values for [EOPNOTSUPP] and [ENOTSUP].
>
> Even if these two happen to be equal in linux, it seems that ENOTSUP, which
> doesn't refer to sockets, is more appropriate.
>
> [1] https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html
Which in Linux kernel maps to a completely bogus value not recognized by
userspace.
So when you mean ENOTSUP use EOPNOTSUPP in Linux.
Thanks
Michal
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Book3S HV: Do not allocate HPT for a nested guest
From: Greg Kurz @ 2020-09-11 8:01 UTC (permalink / raw)
To: Fabiano Rosas; +Cc: kvm, kvm-ppc, linuxppc-dev, david
In-Reply-To: <20200911094536.72dd700a@bahia.lan>
On Fri, 11 Sep 2020 09:45:36 +0200
Greg Kurz <groug@kaod.org> wrote:
> On Fri, 11 Sep 2020 01:16:07 -0300
> Fabiano Rosas <farosas@linux.ibm.com> wrote:
>
> > The current nested KVM code does not support HPT guests. This is
> > informed/enforced in some ways:
> >
> > - Hosts < P9 will not be able to enable the nested HV feature;
> >
> > - The nested hypervisor MMU capabilities will not contain
> > KVM_CAP_PPC_MMU_HASH_V3;
> >
> > - QEMU reflects the MMU capabilities in the
> > 'ibm,arch-vec-5-platform-support' device-tree property;
> >
> > - The nested guest, at 'prom_parse_mmu_model' ignores the
> > 'disable_radix' kernel command line option if HPT is not supported;
> >
> > - The KVM_PPC_CONFIGURE_V3_MMU ioctl will fail if trying to use HPT.
> >
> > There is, however, still a way to start a HPT guest by using
> > max-compat-cpu=power8 at the QEMU machine options. This leads to the
> > guest being set to use hash after QEMU calls the KVM_PPC_ALLOCATE_HTAB
> > ioctl.
> >
> > With the guest set to hash, the nested hypervisor goes through the
> > entry path that has no knowledge of nesting (kvmppc_run_vcpu) and
> > crashes when it tries to execute an hypervisor-privileged (mtspr
> > HDEC) instruction at __kvmppc_vcore_entry:
> >
> > root@L1:~ $ qemu-system-ppc64 -machine pseries,max-cpu-compat=power8 ...
> >
> > <snip>
> > [ 538.543303] CPU: 83 PID: 25185 Comm: CPU 0/KVM Not tainted 5.9.0-rc4 #1
> > [ 538.543355] NIP: c00800000753f388 LR: c00800000753f368 CTR: c0000000001e5ec0
> > [ 538.543417] REGS: c0000013e91e33b0 TRAP: 0700 Not tainted (5.9.0-rc4)
> > [ 538.543470] MSR: 8000000002843033 <SF,VEC,VSX,FP,ME,IR,DR,RI,LE> CR: 22422882 XER: 20040000
> > [ 538.543546] CFAR: c00800000753f4b0 IRQMASK: 3
> > GPR00: c0080000075397a0 c0000013e91e3640 c00800000755e600 0000000080000000
> > GPR04: 0000000000000000 c0000013eab19800 c000001394de0000 00000043a054db72
> > GPR08: 00000000003b1652 0000000000000000 0000000000000000 c0080000075502e0
> > GPR12: c0000000001e5ec0 c0000007ffa74200 c0000013eab19800 0000000000000008
> > GPR16: 0000000000000000 c00000139676c6c0 c000000001d23948 c0000013e91e38b8
> > GPR20: 0000000000000053 0000000000000000 0000000000000001 0000000000000000
> > GPR24: 0000000000000001 0000000000000001 0000000000000000 0000000000000001
> > GPR28: 0000000000000001 0000000000000053 c0000013eab19800 0000000000000001
> > [ 538.544067] NIP [c00800000753f388] __kvmppc_vcore_entry+0x90/0x104 [kvm_hv]
> > [ 538.544121] LR [c00800000753f368] __kvmppc_vcore_entry+0x70/0x104 [kvm_hv]
> > [ 538.544173] Call Trace:
> > [ 538.544196] [c0000013e91e3640] [c0000013e91e3680] 0xc0000013e91e3680 (unreliable)
> > [ 538.544260] [c0000013e91e3820] [c0080000075397a0] kvmppc_run_core+0xbc8/0x19d0 [kvm_hv]
> > [ 538.544325] [c0000013e91e39e0] [c00800000753d99c] kvmppc_vcpu_run_hv+0x404/0xc00 [kvm_hv]
> > [ 538.544394] [c0000013e91e3ad0] [c0080000072da4fc] kvmppc_vcpu_run+0x34/0x48 [kvm]
> > [ 538.544472] [c0000013e91e3af0] [c0080000072d61b8] kvm_arch_vcpu_ioctl_run+0x310/0x420 [kvm]
> > [ 538.544539] [c0000013e91e3b80] [c0080000072c7450] kvm_vcpu_ioctl+0x298/0x778 [kvm]
> > [ 538.544605] [c0000013e91e3ce0] [c0000000004b8c2c] sys_ioctl+0x1dc/0xc90
> > [ 538.544662] [c0000013e91e3dc0] [c00000000002f9a4] system_call_exception+0xe4/0x1c0
> > [ 538.544726] [c0000013e91e3e20] [c00000000000d140] system_call_common+0xf0/0x27c
> > [ 538.544787] Instruction dump:
> > [ 538.544821] f86d1098 60000000 60000000 48000099 e8ad0fe8 e8c500a0 e9264140 75290002
> > [ 538.544886] 7d1602a6 7cec42a6 40820008 7d0807b4 <7d164ba6> 7d083a14 f90d10a0 480104fd
> > [ 538.544953] ---[ end trace 74423e2b948c2e0c ]---
> >
> > This patch makes the KVM_PPC_ALLOCATE_HTAB ioctl fail when running in
> > the nested hypervisor, causing QEMU to abort.
> >
> > Reported-by: Satheesh Rajendran <sathnaga@linux.vnet.ibm.com>
> > Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
> > ---
>
> LGTM
>
> Reviewed-by: Greg Kurz <groug@kaod.org>
>
> > arch/powerpc/kvm/book3s_hv.c | 6 ++++++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
> > index 4ba06a2a306c..764b6239ef72 100644
> > --- a/arch/powerpc/kvm/book3s_hv.c
> > +++ b/arch/powerpc/kvm/book3s_hv.c
> > @@ -5250,6 +5250,12 @@ static long kvm_arch_vm_ioctl_hv(struct file *filp,
> > case KVM_PPC_ALLOCATE_HTAB: {
> > u32 htab_order;
> >
> > + /* If we're a nested hypervisor, we currently only support radix */
> > + if (kvmhv_on_pseries()) {
> > + r = -EOPNOTSUPP;
According to POSIX [1]:
[ENOTSUP]
Not supported. The implementation does not support the requested feature or value.
[EOPNOTSUPP]
Operation not supported on socket. The type of socket (address family or protocol) does not support the requested operation. A conforming implementation may assign the same values for [EOPNOTSUPP] and [ENOTSUP].
Even if these two happen to be equal in linux, it seems that ENOTSUP, which
doesn't refer to sockets, is more appropriate.
[1] https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html
> > + break;
> > + }
> > +
> > r = -EFAULT;
> > if (get_user(htab_order, (u32 __user *)argp))
> > break;
>
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Book3S HV: Do not allocate HPT for a nested guest
From: Greg Kurz @ 2020-09-11 7:45 UTC (permalink / raw)
To: Fabiano Rosas; +Cc: kvm, kvm-ppc, linuxppc-dev, david
In-Reply-To: <20200911041607.198092-1-farosas@linux.ibm.com>
On Fri, 11 Sep 2020 01:16:07 -0300
Fabiano Rosas <farosas@linux.ibm.com> wrote:
> The current nested KVM code does not support HPT guests. This is
> informed/enforced in some ways:
>
> - Hosts < P9 will not be able to enable the nested HV feature;
>
> - The nested hypervisor MMU capabilities will not contain
> KVM_CAP_PPC_MMU_HASH_V3;
>
> - QEMU reflects the MMU capabilities in the
> 'ibm,arch-vec-5-platform-support' device-tree property;
>
> - The nested guest, at 'prom_parse_mmu_model' ignores the
> 'disable_radix' kernel command line option if HPT is not supported;
>
> - The KVM_PPC_CONFIGURE_V3_MMU ioctl will fail if trying to use HPT.
>
> There is, however, still a way to start a HPT guest by using
> max-compat-cpu=power8 at the QEMU machine options. This leads to the
> guest being set to use hash after QEMU calls the KVM_PPC_ALLOCATE_HTAB
> ioctl.
>
> With the guest set to hash, the nested hypervisor goes through the
> entry path that has no knowledge of nesting (kvmppc_run_vcpu) and
> crashes when it tries to execute an hypervisor-privileged (mtspr
> HDEC) instruction at __kvmppc_vcore_entry:
>
> root@L1:~ $ qemu-system-ppc64 -machine pseries,max-cpu-compat=power8 ...
>
> <snip>
> [ 538.543303] CPU: 83 PID: 25185 Comm: CPU 0/KVM Not tainted 5.9.0-rc4 #1
> [ 538.543355] NIP: c00800000753f388 LR: c00800000753f368 CTR: c0000000001e5ec0
> [ 538.543417] REGS: c0000013e91e33b0 TRAP: 0700 Not tainted (5.9.0-rc4)
> [ 538.543470] MSR: 8000000002843033 <SF,VEC,VSX,FP,ME,IR,DR,RI,LE> CR: 22422882 XER: 20040000
> [ 538.543546] CFAR: c00800000753f4b0 IRQMASK: 3
> GPR00: c0080000075397a0 c0000013e91e3640 c00800000755e600 0000000080000000
> GPR04: 0000000000000000 c0000013eab19800 c000001394de0000 00000043a054db72
> GPR08: 00000000003b1652 0000000000000000 0000000000000000 c0080000075502e0
> GPR12: c0000000001e5ec0 c0000007ffa74200 c0000013eab19800 0000000000000008
> GPR16: 0000000000000000 c00000139676c6c0 c000000001d23948 c0000013e91e38b8
> GPR20: 0000000000000053 0000000000000000 0000000000000001 0000000000000000
> GPR24: 0000000000000001 0000000000000001 0000000000000000 0000000000000001
> GPR28: 0000000000000001 0000000000000053 c0000013eab19800 0000000000000001
> [ 538.544067] NIP [c00800000753f388] __kvmppc_vcore_entry+0x90/0x104 [kvm_hv]
> [ 538.544121] LR [c00800000753f368] __kvmppc_vcore_entry+0x70/0x104 [kvm_hv]
> [ 538.544173] Call Trace:
> [ 538.544196] [c0000013e91e3640] [c0000013e91e3680] 0xc0000013e91e3680 (unreliable)
> [ 538.544260] [c0000013e91e3820] [c0080000075397a0] kvmppc_run_core+0xbc8/0x19d0 [kvm_hv]
> [ 538.544325] [c0000013e91e39e0] [c00800000753d99c] kvmppc_vcpu_run_hv+0x404/0xc00 [kvm_hv]
> [ 538.544394] [c0000013e91e3ad0] [c0080000072da4fc] kvmppc_vcpu_run+0x34/0x48 [kvm]
> [ 538.544472] [c0000013e91e3af0] [c0080000072d61b8] kvm_arch_vcpu_ioctl_run+0x310/0x420 [kvm]
> [ 538.544539] [c0000013e91e3b80] [c0080000072c7450] kvm_vcpu_ioctl+0x298/0x778 [kvm]
> [ 538.544605] [c0000013e91e3ce0] [c0000000004b8c2c] sys_ioctl+0x1dc/0xc90
> [ 538.544662] [c0000013e91e3dc0] [c00000000002f9a4] system_call_exception+0xe4/0x1c0
> [ 538.544726] [c0000013e91e3e20] [c00000000000d140] system_call_common+0xf0/0x27c
> [ 538.544787] Instruction dump:
> [ 538.544821] f86d1098 60000000 60000000 48000099 e8ad0fe8 e8c500a0 e9264140 75290002
> [ 538.544886] 7d1602a6 7cec42a6 40820008 7d0807b4 <7d164ba6> 7d083a14 f90d10a0 480104fd
> [ 538.544953] ---[ end trace 74423e2b948c2e0c ]---
>
> This patch makes the KVM_PPC_ALLOCATE_HTAB ioctl fail when running in
> the nested hypervisor, causing QEMU to abort.
>
> Reported-by: Satheesh Rajendran <sathnaga@linux.vnet.ibm.com>
> Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
> ---
LGTM
Reviewed-by: Greg Kurz <groug@kaod.org>
> arch/powerpc/kvm/book3s_hv.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
> index 4ba06a2a306c..764b6239ef72 100644
> --- a/arch/powerpc/kvm/book3s_hv.c
> +++ b/arch/powerpc/kvm/book3s_hv.c
> @@ -5250,6 +5250,12 @@ static long kvm_arch_vm_ioctl_hv(struct file *filp,
> case KVM_PPC_ALLOCATE_HTAB: {
> u32 htab_order;
>
> + /* If we're a nested hypervisor, we currently only support radix */
> + if (kvmhv_on_pseries()) {
> + r = -EOPNOTSUPP;
> + break;
> + }
> +
> r = -EFAULT;
> if (get_user(htab_order, (u32 __user *)argp))
> break;
^ permalink raw reply
* Re: [RFC PATCH v2 1/3] mm/gup: fix gup_fast with dynamic page table folding
From: peterz @ 2020-09-11 7:09 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Dave Hansen, linux-mm, Paul Mackerras, linux-sparc,
Alexander Gordeev, Claudio Imbrenda, Will Deacon, linux-arch,
linux-s390, Vasily Gorbik, Richard Weinberger, linux-x86,
Russell King, Christian Borntraeger, Ingo Molnar, Catalin Marinas,
Andrey Ryabinin, Gerald Schaefer, Heiko Carstens, Arnd Bergmann,
John Hubbard, Jeff Dike, linux-um, Borislav Petkov,
Andy Lutomirski, Thomas Gleixner, linux-arm, Dave Hansen,
linux-power, LKML, Andrew Morton, Linus Torvalds, Mike Rapoport
In-Reply-To: <20200910215921.GP87483@ziepe.ca>
On Thu, Sep 10, 2020 at 06:59:21PM -0300, Jason Gunthorpe wrote:
> So, I suggest pXX_offset_unlocked()
Urgh, no. Elsewhere in gup _unlocked() means it will take the lock
itself (get_user_pages_unlocked()) -- although often it seems to mean
the lock is already held (git grep _unlocked and marvel).
What we want is _lockless().
^ permalink raw reply
* Re: [PATCH 5/7] powerpc/powernv/pci: Fix W=1 compile warning
From: Oliver O'Halloran @ 2020-09-11 6:32 UTC (permalink / raw)
To: Cédric Le Goater; +Cc: linuxppc-dev
In-Reply-To: <20200910210250.1962595-6-clg@kaod.org>
On Fri, Sep 11, 2020 at 7:02 AM Cédric Le Goater <clg@kaod.org> wrote:
>
> CC arch/powerpc/platforms/powernv/pci-ioda.o
> ../arch/powerpc/platforms/powernv/pci-ioda.c: In function ‘pnv_ioda_configure_pe’:
> ../arch/powerpc/platforms/powernv/pci-ioda.c:897:18: error: variable ‘parent’ set but not used [-Werror=unused-but-set-variable]
> struct pci_dev *parent;
> ^~~~~~
>
> Cc: Oliver O'Halloran <oohall@gmail.com>
> Signed-off-by: Cédric Le Goater <clg@kaod.org>
Come to think of it a fix for this might already be in -next, see
https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=193967&state=*
If not,
Reviewed-by: Oliver O'Halloran <oohall@gmail.com>
^ permalink raw reply
* Re: [PATCH 3/7] powerpc/sstep: Fix W=1 compile warning
From: Christophe Leroy @ 2020-09-11 6:04 UTC (permalink / raw)
To: Cédric Le Goater, Michael Ellerman; +Cc: Jordan Niethe, linuxppc-dev
In-Reply-To: <47310980-9989-c9c0-61a9-ec033ac18197@kaod.org>
Le 11/09/2020 à 07:59, Cédric Le Goater a écrit :
> On 9/11/20 7:38 AM, Christophe Leroy wrote:
>>
>>
>> Le 10/09/2020 à 23:02, Cédric Le Goater a écrit :
>>> ../arch/powerpc/lib/sstep.c: In function ‘mlsd_8lsd_ea’:
>>> ../arch/powerpc/lib/sstep.c:225:3: error: suggest braces around empty body in an ‘if’ statement [-Werror=empty-body]
>>> ; /* Invalid form. Should already be checked for by caller! */
>>> ^
>>
>> A small sentence explaining how this is fixed would be welcome, so that you don't need to read the code the know what the commit does to fix the warning. Also the subject should be more explicit.
>>
>>
>>
>>>
>>> Cc: Jordan Niethe <jniethe5@gmail.com>
>>> Signed-off-by: Cédric Le Goater <clg@kaod.org>
>>> ---
>>> arch/powerpc/lib/sstep.c | 3 ++-
>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/powerpc/lib/sstep.c b/arch/powerpc/lib/sstep.c
>>> index caee8cc77e19..14572af16e55 100644
>>> --- a/arch/powerpc/lib/sstep.c
>>> +++ b/arch/powerpc/lib/sstep.c
>>> @@ -221,8 +221,9 @@ static nokprobe_inline unsigned long mlsd_8lsd_ea(unsigned int instr,
>>> ; /* Leave ea as is */
>>> else if (prefix_r && !ra)
>>> ea += regs->nip;
>>> - else if (prefix_r && ra)
>>> + else if (prefix_r && ra) {
>>> ; /* Invalid form. Should already be checked for by caller! */
>>> + }
>>
>> You can't do that. Now checkpatch will complain that you don't have braces on all legs of the if/else dance.
>
> Should we fix checkpatch ?
Why not, not then fix
https://www.kernel.org/doc/html/latest/process/coding-style.html#placing-braces-and-spaces
first :)
Christophe
^ permalink raw reply
* Re: [PATCH 2/7] powerpc/prom: Fix W=1 compile warning
From: Cédric Le Goater @ 2020-09-11 6:01 UTC (permalink / raw)
To: Christophe Leroy, Michael Ellerman; +Cc: linuxppc-dev
In-Reply-To: <ed65bab2-b42c-38f6-d68e-c9924cfca62d@csgroup.eu>
On 9/11/20 7:33 AM, Christophe Leroy wrote:
>
>
> Le 10/09/2020 à 23:02, Cédric Le Goater a écrit :
>> arch/powerpc/kernel/prom.c: In function ‘early_reserve_mem’:
>> arch/powerpc/kernel/prom.c:625:10: error: variable ‘reserve_map’ set but not used [-Werror=unused-but-set-variable]
>> __be64 *reserve_map;
>> ^~~~~~~~~~~
>> cc1: all warnings being treated as errors
>
> A small sentence explaining how this is fixes would be welcome, so that you don't need to read the code the know what the commit does to fix the warning. Also the subject should be more explicit.
>
>
>>
>> Cc: Christophe Leroy <christophe.leroy@c-s.fr>
>> Signed-off-by: Cédric Le Goater <clg@kaod.org>
>> ---
>> arch/powerpc/kernel/prom.c | 51 +++++++++++++++++++-------------------
>> 1 file changed, 26 insertions(+), 25 deletions(-)
>>
>> diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
>> index d8a2fb87ba0c..4bae9ebc7d0b 100644
>> --- a/arch/powerpc/kernel/prom.c
>> +++ b/arch/powerpc/kernel/prom.c
>> @@ -622,11 +622,6 @@ static void __init early_reserve_mem_dt(void)
>> static void __init early_reserve_mem(void)
>> {
>> - __be64 *reserve_map;
>> -
>> - reserve_map = (__be64 *)(((unsigned long)initial_boot_params) +
>> - fdt_off_mem_rsvmap(initial_boot_params));
>> -
>> /* Look for the new "reserved-regions" property in the DT */
>> early_reserve_mem_dt();
>> @@ -639,28 +634,34 @@ static void __init early_reserve_mem(void)
>> }
>> #endif /* CONFIG_BLK_DEV_INITRD */
>> -#ifdef CONFIG_PPC32
>
> Instead of such a big change, you could simply do the following in addition to the move of reserve_map allocation after it.
>
> if (!IS_ENABLED(CONFIG_PPC32))
> return;
yes. I will include a change for CONFIG_BLK_DEV_INITRD also.
Thanks,
C.
>
>> - /*
>> - * Handle the case where we might be booting from an old kexec
>> - * image that setup the mem_rsvmap as pairs of 32-bit values
>> - */
>> - if (be64_to_cpup(reserve_map) > 0xffffffffull) {
>> - u32 base_32, size_32;
>> - __be32 *reserve_map_32 = (__be32 *)reserve_map;
>> -
>> - DBG("Found old 32-bit reserve map\n");
>> -
>> - while (1) {
>> - base_32 = be32_to_cpup(reserve_map_32++);
>> - size_32 = be32_to_cpup(reserve_map_32++);
>> - if (size_32 == 0)
>> - break;
>> - DBG("reserving: %x -> %x\n", base_32, size_32);
>> - memblock_reserve(base_32, size_32);
>> + if (IS_ENABLED(CONFIG_PPC32)) {
>> + __be64 *reserve_map;
>> +
>> + reserve_map = (__be64 *)(((unsigned long)initial_boot_params) +
>> + fdt_off_mem_rsvmap(initial_boot_params));
>> +
>> + /*
>> + * Handle the case where we might be booting from an
>> + * old kexec image that setup the mem_rsvmap as pairs
>> + * of 32-bit values
>> + */
>> + if (be64_to_cpup(reserve_map) > 0xffffffffull) {
>> + u32 base_32, size_32;
>> + __be32 *reserve_map_32 = (__be32 *)reserve_map;
>> +
>> + DBG("Found old 32-bit reserve map\n");
>> +
>> + while (1) {
>> + base_32 = be32_to_cpup(reserve_map_32++);
>> + size_32 = be32_to_cpup(reserve_map_32++);
>> + if (size_32 == 0)
>> + break;
>> + DBG("reserving: %x -> %x\n", base_32, size_32);
>> + memblock_reserve(base_32, size_32);
>> + }
>> + return;
>> }
>> - return;
>> }
>> -#endif
>> }
>> #ifdef CONFIG_PPC_TRANSACTIONAL_MEM
>>
>
>
> Christophe
^ permalink raw reply
* Re: [PATCH 3/7] powerpc/sstep: Fix W=1 compile warning
From: Cédric Le Goater @ 2020-09-11 5:59 UTC (permalink / raw)
To: Christophe Leroy, Michael Ellerman; +Cc: Jordan Niethe, linuxppc-dev
In-Reply-To: <8a71335b-12b8-4d17-9b98-ff1eb0a39b84@csgroup.eu>
On 9/11/20 7:38 AM, Christophe Leroy wrote:
>
>
> Le 10/09/2020 à 23:02, Cédric Le Goater a écrit :
>> ../arch/powerpc/lib/sstep.c: In function ‘mlsd_8lsd_ea’:
>> ../arch/powerpc/lib/sstep.c:225:3: error: suggest braces around empty body in an ‘if’ statement [-Werror=empty-body]
>> ; /* Invalid form. Should already be checked for by caller! */
>> ^
>
> A small sentence explaining how this is fixed would be welcome, so that you don't need to read the code the know what the commit does to fix the warning. Also the subject should be more explicit.
>
>
>
>>
>> Cc: Jordan Niethe <jniethe5@gmail.com>
>> Signed-off-by: Cédric Le Goater <clg@kaod.org>
>> ---
>> arch/powerpc/lib/sstep.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/powerpc/lib/sstep.c b/arch/powerpc/lib/sstep.c
>> index caee8cc77e19..14572af16e55 100644
>> --- a/arch/powerpc/lib/sstep.c
>> +++ b/arch/powerpc/lib/sstep.c
>> @@ -221,8 +221,9 @@ static nokprobe_inline unsigned long mlsd_8lsd_ea(unsigned int instr,
>> ; /* Leave ea as is */
>> else if (prefix_r && !ra)
>> ea += regs->nip;
>> - else if (prefix_r && ra)
>> + else if (prefix_r && ra) {
>> ; /* Invalid form. Should already be checked for by caller! */
>> + }
>
> You can't do that. Now checkpatch will complain that you don't have braces on all legs of the if/else dance.
Should we fix checkpatch ?
> I think the last 'else if' should simply be removed entirely as it does nothing. Eventually, just leave the comment, something like:
>
> /* (prefix_r && ra) is Invalid form. Should already be checked for by caller! */
>
> And if (prefix_r && ra) is not possible, then the previous if should just be 'if (prefx_r)'
Indeed. I will rework that one.
Thanks,
C.
> Christophe
>
>
>> return ea;
>> }
>>
^ permalink raw reply
* Re: [PATCH 7/7] powerpc/32: Fix W=1 compile warning
From: Christophe Leroy @ 2020-09-11 5:49 UTC (permalink / raw)
To: Cédric Le Goater, Michael Ellerman; +Cc: linuxppc-dev
In-Reply-To: <20200910210250.1962595-8-clg@kaod.org>
Le 10/09/2020 à 23:02, Cédric Le Goater a écrit :
> CC arch/powerpc/kernel/traps.o
> ../arch/powerpc/kernel/traps.c:1663:6: error: no previous prototype for ‘stack_overflow_exception’ [-Werror=missing-prototypes]
> void stack_overflow_exception(struct pt_regs *regs)
> ^~~~~~~~~~~~~~~~~~~~~~~~
>
A small sentence explaining how this is fixed would be welcome, so that
you don't need to read the code the know what the commit does to fix the
warning. Also the subject should be more explicit.
> Cc: Christophe Leroy <christophe.leroy@c-s.fr>
Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> Fixes: 3978eb78517c ("powerpc/32: Add early stack overflow detection with VMAP stack.")
> Signed-off-by: Cédric Le Goater <clg@kaod.org>
> ---
> arch/powerpc/include/asm/asm-prototypes.h | 1 +
Note that asm-prototypes.h is not the right place for such a prototype,
but that's probably for another cleanup patch. See discussion at
https://patchwork.ozlabs.org/project/linuxppc-dev/patch/1463534212-4879-2-git-send-email-dja@axtens.net/
Christophe
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/powerpc/include/asm/asm-prototypes.h b/arch/powerpc/include/asm/asm-prototypes.h
> index de14b1a34d56..4957119604c7 100644
> --- a/arch/powerpc/include/asm/asm-prototypes.h
> +++ b/arch/powerpc/include/asm/asm-prototypes.h
> @@ -67,6 +67,7 @@ void single_step_exception(struct pt_regs *regs);
> void program_check_exception(struct pt_regs *regs);
> void alignment_exception(struct pt_regs *regs);
> void StackOverflow(struct pt_regs *regs);
> +void stack_overflow_exception(struct pt_regs *regs);
> void kernel_fp_unavailable_exception(struct pt_regs *regs);
> void altivec_unavailable_exception(struct pt_regs *regs);
> void vsx_unavailable_exception(struct pt_regs *regs);
>
^ permalink raw reply
* Re: [PATCH 6/7] powerpc/perf: Fix W=1 compile warning
From: Christophe Leroy @ 2020-09-11 5:42 UTC (permalink / raw)
To: Cédric Le Goater, Michael Ellerman; +Cc: Anju T Sudhakar, linuxppc-dev
In-Reply-To: <20200910210250.1962595-7-clg@kaod.org>
Le 10/09/2020 à 23:02, Cédric Le Goater a écrit :
> CC arch/powerpc/perf/imc-pmu.o
> ../arch/powerpc/perf/imc-pmu.c: In function ‘trace_imc_event_init’:
> ../arch/powerpc/perf/imc-pmu.c:1429:22: error: variable ‘target’ set but not used [-Werror=unused-but-set-variable]
> struct task_struct *target;
> ^~~~~~
A small sentence explaining how this is fixed would be welcome, so that
you don't need to read the code the know what the commit does to fix the
warning. Also the subject should be more explicit.
>
> Cc: Anju T Sudhakar <anju@linux.vnet.ibm.com>
> Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> ---
> arch/powerpc/perf/imc-pmu.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/arch/powerpc/perf/imc-pmu.c b/arch/powerpc/perf/imc-pmu.c
> index 62d0b54086f8..9ed4fcccf8a9 100644
> --- a/arch/powerpc/perf/imc-pmu.c
> +++ b/arch/powerpc/perf/imc-pmu.c
> @@ -1426,8 +1426,6 @@ static void trace_imc_event_del(struct perf_event *event, int flags)
>
> static int trace_imc_event_init(struct perf_event *event)
> {
> - struct task_struct *target;
> -
> if (event->attr.type != event->pmu->type)
> return -ENOENT;
>
> @@ -1458,7 +1456,6 @@ static int trace_imc_event_init(struct perf_event *event)
> mutex_unlock(&imc_global_refc.lock);
>
> event->hw.idx = -1;
> - target = event->hw.target;
>
> event->pmu->task_ctx_nr = perf_hw_context;
> event->destroy = reset_global_refc;
>
^ 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