* Re: [PATCH] powerpc/powermac: Fix low_sleep_handler with KUAP and KUEP
From: Michael Ellerman @ 2020-09-10 23:56 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <74472ea2a7e8698273643cde7d382bd9f31cd1dd.1598945727.git.christophe.leroy@csgroup.eu>
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?
cheers
> 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
* [PATCH] powerpc/ps3: make two symbols static
From: Jason Yan @ 2020-09-11 2:01 UTC (permalink / raw)
To: geoff, mpe, benh, paulus, linuxppc-dev, linux-kernel
Cc: Hulk Robot, Jason Yan
This addresses the following sparse warning:
arch/powerpc/platforms/ps3/spu.c:451:33: warning: symbol
'spu_management_ps3_ops' was not declared. Should it be static?
arch/powerpc/platforms/ps3/spu.c:592:28: warning: symbol
'spu_priv1_ps3_ops' was not declared. Should it be static?
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Jason Yan <yanaijie@huawei.com>
---
arch/powerpc/platforms/ps3/spu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/ps3/spu.c b/arch/powerpc/platforms/ps3/spu.c
index 1193c294b8d0..0c252478e556 100644
--- a/arch/powerpc/platforms/ps3/spu.c
+++ b/arch/powerpc/platforms/ps3/spu.c
@@ -448,7 +448,7 @@ static void ps3_disable_spu(struct spu_context *ctx)
ctx->ops->runcntl_stop(ctx);
}
-const struct spu_management_ops spu_management_ps3_ops = {
+static const struct spu_management_ops spu_management_ps3_ops = {
.enumerate_spus = ps3_enumerate_spus,
.create_spu = ps3_create_spu,
.destroy_spu = ps3_destroy_spu,
@@ -589,7 +589,7 @@ static u64 resource_allocation_enable_get(struct spu *spu)
return 0; /* No support. */
}
-const struct spu_priv1_ops spu_priv1_ps3_ops = {
+static const struct spu_priv1_ops spu_priv1_ps3_ops = {
.int_mask_and = int_mask_and,
.int_mask_or = int_mask_or,
.int_mask_set = int_mask_set,
--
2.25.4
^ permalink raw reply related
* Re: [PATCH v4 13/13] mm/debug_vm_pgtable: Avoid none pte in pte_clear_test
From: Nathan Chancellor @ 2020-09-11 2:13 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: linux-mm, akpm, Anshuman Khandual, linuxppc-dev
In-Reply-To: <20200902114222.181353-14-aneesh.kumar@linux.ibm.com>
On Wed, Sep 02, 2020 at 05:12:22PM +0530, Aneesh Kumar K.V wrote:
> pte_clear_tests operate on an existing pte entry. Make sure that
> is not a none pte entry.
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> ---
> mm/debug_vm_pgtable.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/mm/debug_vm_pgtable.c b/mm/debug_vm_pgtable.c
> index 9afa1354326b..c36530c69e33 100644
> --- a/mm/debug_vm_pgtable.c
> +++ b/mm/debug_vm_pgtable.c
> @@ -542,9 +542,10 @@ static void __init pgd_populate_tests(struct mm_struct *mm, pgd_t *pgdp,
> #endif /* PAGETABLE_P4D_FOLDED */
>
> static void __init pte_clear_tests(struct mm_struct *mm, pte_t *ptep,
> - unsigned long vaddr)
> + unsigned long pfn, unsigned long vaddr,
> + pgprot_t prot)
> {
> - pte_t pte = ptep_get(ptep);
> + pte_t pte = pfn_pte(pfn, prot);
>
> pr_debug("Validating PTE clear\n");
> pte = __pte(pte_val(pte) | RANDOM_ORVALUE);
> @@ -1049,7 +1050,7 @@ static int __init debug_vm_pgtable(void)
>
> ptl = pte_lockptr(mm, pmdp);
> spin_lock(ptl);
> - pte_clear_tests(mm, ptep, vaddr);
> + pte_clear_tests(mm, ptep, pte_aligned, vaddr, prot);
> pte_advanced_tests(mm, vma, ptep, pte_aligned, vaddr, prot);
> pte_unmap_unlock(ptep, ptl);
>
> --
> 2.26.2
>
>
This patch causes a panic at boot for RISC-V defconfig. The rootfs is here if it is needed:
https://github.com/ClangBuiltLinux/boot-utils/blob/3b21a5b71451742866349ba4f18638c5a754e660/images/riscv/rootfs.cpio.zst
$ make -skj"$(nproc)" ARCH=riscv CROSS_COMPILE=riscv64-linux- O=out/riscv distclean defconfig Image
$ qemu-system-riscv64 -bios default -M virt -display none -initrd rootfs.cpio -kernel Image -m 512m -nodefaults -serial mon:stdio
...
OpenSBI v0.6
____ _____ ____ _____
/ __ \ / ____| _ \_ _|
| | | |_ __ ___ _ __ | (___ | |_) || |
| | | | '_ \ / _ \ '_ \ \___ \| _ < | |
| |__| | |_) | __/ | | |____) | |_) || |_
\____/| .__/ \___|_| |_|_____/|____/_____|
| |
|_|
Platform Name : QEMU Virt Machine
Platform HART Features : RV64ACDFIMSU
Platform Max HARTs : 8
Current Hart : 0
Firmware Base : 0x80000000
Firmware Size : 120 KB
Runtime SBI Version : 0.2
MIDELEG : 0x0000000000000222
MEDELEG : 0x000000000000b109
PMP0 : 0x0000000080000000-0x000000008001ffff (A)
PMP1 : 0x0000000000000000-0xffffffffffffffff (A,R,W,X)
[ 0.000000] Linux version 5.9.0-rc4-next-20200910 (nathan@ubuntu-n2-xlarge-x86) (riscv64-linux-gcc (GCC) 10.2.0, GNU ld (GNU Binutils) 2.35) #1 SMP Thu Sep 10 19:10:43 MST 2020
...
[ 0.294593] NET: Registered protocol family 17
[ 0.295781] 9pnet: Installing 9P2000 support
[ 0.296153] Key type dns_resolver registered
[ 0.296694] debug_vm_pgtable: [debug_vm_pgtable ]: Validating architecture page table helpers
[ 0.297635] Unable to handle kernel paging request at virtual address 0a7fffe01dafefc8
[ 0.298029] Oops [#1]
[ 0.298153] Modules linked in:
[ 0.298433] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.9.0-rc4-next-20200910 #1
[ 0.298792] epc: ffffffe000205afc ra : ffffffe0008be0aa sp : ffffffe01ae73d40
[ 0.299078] gp : ffffffe0010b9b48 tp : ffffffe01ae68000 t0 : ffffffe008152000
[ 0.299362] t1 : 0000000000000000 t2 : 0000000000000000 s0 : ffffffe01ae73d60
[ 0.299648] s1 : bffffffffffffffb a0 : 0a7fffe01dafefc8 a1 : bffffffffffffffb
[ 0.299948] a2 : ffffffe0010a2698 a3 : 0000000000000001 a4 : 0000000000000003
[ 0.300231] a5 : 0000000000000800 a6 : fffffffff0000080 a7 : 000000001b642000
[ 0.300521] s2 : ffffffe0081517b8 s3 : ffffffe008150a80 s4 : ffffffe01af30000
[ 0.300806] s5 : ffffffe01f8ca9b8 s6 : ffffffe008150000 s7 : ffffffe0010bb100
[ 0.301161] s8 : ffffffe0010bb108 s9 : 0000000000080202 s10: ffffffe0010bb928
[ 0.301481] s11: 000000002008085b t3 : 0000000000000000 t4 : 0000000000000000
[ 0.301722] t5 : 0000000000000000 t6 : ffffffe008150000
[ 0.301947] status: 0000000000000120 badaddr: 0a7fffe01dafefc8 cause: 000000000000000f
[ 0.302569] ---[ end trace 7ffb153d816164cf ]---
[ 0.302797] note: swapper/0[1] exited with preempt_count 1
[ 0.303101] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[ 0.303614] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---
$ git bisect log
# bad: [7ce53e3a447bced7b85ed181c4d027e93c062e07] Add linux-next specific files for 20200910
# good: [34d4ddd359dbcdf6c5fb3f85a179243d7a1cb7f8] Merge tag 'linux-kselftest-5.9-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest
git bisect start '7ce53e3a447bced7b85ed181c4d027e93c062e07' '34d4ddd359dbcdf6c5fb3f85a179243d7a1cb7f8'
# good: [bb1f09d126618aa1ec776d87d7f85136edbed485] Merge remote-tracking branch 'crypto/master' into master
git bisect good bb1f09d126618aa1ec776d87d7f85136edbed485
# good: [1fb7e980a0f9a0aa4c7daba1a7e35d12c97820ea] Merge remote-tracking branch 'audit/next' into master
git bisect good 1fb7e980a0f9a0aa4c7daba1a7e35d12c97820ea
# good: [afdf05baff78a658843c1013855985e7a6871406] Merge remote-tracking branch 'thunderbolt/next' into master
git bisect good afdf05baff78a658843c1013855985e7a6871406
# good: [c5f3c031bd4b8ef5fb6b07352abc284603c3edee] Merge remote-tracking branch 'kselftest/next' into master
git bisect good c5f3c031bd4b8ef5fb6b07352abc284603c3edee
# bad: [671aca25e253f2773850aefb0837a225c691e336] lib: bitmap: delete duplicated words
git bisect bad 671aca25e253f2773850aefb0837a225c691e336
# bad: [e42ac710a849403b7fe582cc555dc3b7bf5b6fa9] tools/testing/selftests/vm/hmm-tests.c: use the new SKIP() macro
git bisect bad e42ac710a849403b7fe582cc555dc3b7bf5b6fa9
# good: [1443e3384317a9dfaf1381e8134a69c1e3fc7130] device-dax: kill dax_kmem_res
git bisect good 1443e3384317a9dfaf1381e8134a69c1e3fc7130
# good: [e2aad6f1d232b457ea6a3194992dd4c0a83534a5] mm/debug_vm_pgtable/locks: take correct page table lock
git bisect good e2aad6f1d232b457ea6a3194992dd4c0a83534a5
# bad: [08075d21b791241ba9f1366f814afa4a77372250] mm: workingset: ignore slab memory size when calculating shadows pressure
git bisect bad 08075d21b791241ba9f1366f814afa4a77372250
# bad: [42e9e63856020953cc3645a2032a70179364a1d8] mm-gup-dont-permit-users-to-call-get_user_pages-with-foll_longterm-fix
git bisect bad 42e9e63856020953cc3645a2032a70179364a1d8
# good: [b77bfa2ce4c2e30c1b1d1b3eb18c5b57397277f9] mm/debug_vm_pgtable/hugetlb: disable hugetlb test on ppc64
git bisect good b77bfa2ce4c2e30c1b1d1b3eb18c5b57397277f9
# bad: [90b612d56df39666f0f6fa6a033b4a7ec2e0a16c] mm/gup_benchmark: use pin_user_pages for FOLL_LONGTERM flag
git bisect bad 90b612d56df39666f0f6fa6a033b4a7ec2e0a16c
# bad: [060e70ecf865e55d82282995b4cb478126a1163c] mm/debug_vm_pgtable: avoid none pte in pte_clear_test
git bisect bad 060e70ecf865e55d82282995b4cb478126a1163c
# first bad commit: [060e70ecf865e55d82282995b4cb478126a1163c] mm/debug_vm_pgtable: avoid none pte in pte_clear_test
Cheers,
Nathan
^ permalink raw reply
* [PATCH] KVM: PPC: Book3S HV: Do not allocate HPT for a nested guest
From: Fabiano Rosas @ 2020-09-11 4:16 UTC (permalink / raw)
To: kvm-ppc; +Cc: linuxppc-dev, kvm, david
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>
---
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;
--
2.25.4
^ permalink raw reply related
* Re: [trivial PATCH] treewide: Convert switch/case fallthrough; to break;
From: Joe Perches @ 2020-09-11 4:19 UTC (permalink / raw)
To: Robin Murphy, LKML, Jiri Kosina
Cc: linux-fbdev, oss-drivers, nouveau, alsa-devel, dri-devel,
linux-mips, linux-ide, dm-devel, linux-mtd, linux-i2c, sparclinux,
Will Deacon, linux-afs, linux-rtc, linux-s390, linux-scsi, dccp,
linux-rdma, linux-atm-general, kvmarm, coreteam, intel-wired-lan,
linux-serial, linux-input, linux-mmc, Kees Cook, linux-media,
linux-pm, intel-gfx, linux-mediatek, linux-nvme, storagedev,
ceph-devel, linux-arm-kernel, Nick Desaulniers, linux-nfs,
linux-parisc, netdev, linux-usb, linux-wireless, linux-sctp,
iommu, netfilter-devel, linux-crypto, bpf, linuxppc-dev
In-Reply-To: <9372456a-8dcf-2735-57a4-e126aa5df3a6@arm.com>
On Thu, 2020-09-10 at 15:21 +0100, Robin Murphy wrote:
> On 2020-09-09 21:06, Joe Perches wrote:
> > fallthrough to a separate case/default label break; isn't very readable.
> >
> > Convert pseudo-keyword fallthrough; statements to a simple break; when
> > the next label is case or default and the only statement in the next
> > label block is break;
> >
> > Found using:
> >
> > $ grep-2.5.4 -rP --include=*.[ch] -n "fallthrough;(\s*(case\s+\w+|default)\s*:\s*){1,7}break;" *
> >
> > Miscellanea:
> >
> > o Move or coalesce a couple label blocks above a default: block.
> >
> > Signed-off-by: Joe Perches <joe@perches.com>
> > ---
> >
> > Compiled allyesconfig x86-64 only.
> > A few files for other arches were not compiled.
> >
>
> [...]
> > diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> > index c192544e874b..743db1abec40 100644
> > --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> > +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> > @@ -3777,7 +3777,7 @@ static int arm_smmu_device_hw_probe(struct arm_smmu_device *smmu)
> > switch (FIELD_GET(IDR0_TTF, reg)) {
> > case IDR0_TTF_AARCH32_64:
> > smmu->ias = 40;
> > - fallthrough;
> > + break;
> > case IDR0_TTF_AARCH64:
> > break;
> > default:
>
> I have to say I don't really agree with the readability argument for
> this one - a fallthrough is semantically correct here, since the first
> case is a superset of the second. It just happens that anything we would
> do for the common subset is implicitly assumed (there are other
> potential cases we simply haven't added support for at the moment), thus
> the second case is currently empty.
> This change actively obfuscates that distinction.
Then perhaps comments should be added to usefully
describe the mechanisms.
case IDR0_TTF_AARCH32_64:
smmu->ias = 40;
fallthrough; /* and still do the 64 bit processing */
case IDR0_TTF_AARCH64:
/* Nothing specific yet */
break;
> Robin.
^ permalink raw reply
* [PATCH] powerpc/kasan: Fix CONFIG_KASAN_VMALLOC for 8xx
From: Christophe Leroy @ 2020-09-11 5:05 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
Before the commit identified below, pages tables allocation was
performed after the allocation of final shadow area for linear memory.
But that commit switched the order, leading to page tables being
already allocated at the time 8xx kasan_init_shadow_8M() is called.
Due to this, kasan_init_shadow_8M() doesn't map the needed
shadow entries because there are already page tables.
kasan_init_shadow_8M() installs huge PMD entries instead of page
tables. We could at that time free the page tables, but there is no
point in creating page tables that get freed before being used.
Only book3s/32 hash needs early allocation of page tables. For other
variants, we can keep the initial order and create remaining page
tables after the allocation of final shadow memory for linear mem.
Move back the allocation of shadow page tables for
CONFIG_KASAN_VMALLOC into kasan_init() after the loop which creates
final shadow memory for linear mem.
Fixes: 41ea93cf7ba4 ("powerpc/kasan: Fix shadow pages allocation failure")
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
arch/powerpc/mm/kasan/kasan_init_32.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/mm/kasan/kasan_init_32.c b/arch/powerpc/mm/kasan/kasan_init_32.c
index fb294046e00e..929716ea21e9 100644
--- a/arch/powerpc/mm/kasan/kasan_init_32.c
+++ b/arch/powerpc/mm/kasan/kasan_init_32.c
@@ -127,8 +127,7 @@ void __init kasan_mmu_init(void)
{
int ret;
- if (early_mmu_has_feature(MMU_FTR_HPTE_TABLE) ||
- IS_ENABLED(CONFIG_KASAN_VMALLOC)) {
+ if (early_mmu_has_feature(MMU_FTR_HPTE_TABLE)) {
ret = kasan_init_shadow_page_tables(KASAN_SHADOW_START, KASAN_SHADOW_END);
if (ret)
@@ -139,11 +138,11 @@ void __init kasan_mmu_init(void)
void __init kasan_init(void)
{
struct memblock_region *reg;
+ int ret;
for_each_memblock(memory, reg) {
phys_addr_t base = reg->base;
phys_addr_t top = min(base + reg->size, total_lowmem);
- int ret;
if (base >= top)
continue;
@@ -153,6 +152,13 @@ void __init kasan_init(void)
panic("kasan: kasan_init_region() failed");
}
+ if (IS_ENABLED(CONFIG_KASAN_VMALLOC)) {
+ ret = kasan_init_shadow_page_tables(KASAN_SHADOW_START, KASAN_SHADOW_END);
+
+ if (ret)
+ panic("kasan: kasan_init_shadow_page_tables() failed");
+ }
+
kasan_remap_early_shadow_ro();
clear_page(kasan_early_shadow_page);
--
2.25.0
^ permalink raw reply related
* Re: [PATCH v1] pseries/hotplug-memory: hot-add: skip redundant LMB lookup
From: kernel test robot @ 2020-09-11 5:18 UTC (permalink / raw)
To: Scott Cheloha, linuxppc-dev
Cc: Nathan Lynch, Laurent Dufour, kbuild-all, David Hildenbrand,
clang-built-linux, Michal Suchanek, Rick Lindsley
In-Reply-To: <20200910175637.2865160-1-cheloha@linux.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 3368 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-randconfig-r034-20200911 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 0448d11a06b451a63a8f60408fec613ad24801ba)
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
# install powerpc cross compiling tool for clang build
# apt-get install binutils-powerpc-linux-gnu
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang 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 function 'of_drconf_to_nid_single' [-Wmissing-prototypes]
int of_drconf_to_nid_single(struct drmem_lmb *lmb)
^
arch/powerpc/mm/numa.c:433:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
int of_drconf_to_nid_single(struct drmem_lmb *lmb)
^
static
1 warning generated.
# 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: 34599 bytes --]
^ permalink raw reply
* Re: [PATCH v4 13/13] mm/debug_vm_pgtable: Avoid none pte in pte_clear_test
From: Aneesh Kumar K.V @ 2020-09-11 5:21 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Anshuman Khandual, linux-mm, akpm, linuxppc-dev, linux-riscv
In-Reply-To: <20200911021358.GA3656343@ubuntu-n2-xlarge-x86>
Nathan Chancellor <natechancellor@gmail.com> writes:
> On Wed, Sep 02, 2020 at 05:12:22PM +0530, Aneesh Kumar K.V wrote:
>> pte_clear_tests operate on an existing pte entry. Make sure that
>> is not a none pte entry.
>>
>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
>> ---
>> mm/debug_vm_pgtable.c | 7 ++++---
>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/mm/debug_vm_pgtable.c b/mm/debug_vm_pgtable.c
>> index 9afa1354326b..c36530c69e33 100644
>> --- a/mm/debug_vm_pgtable.c
>> +++ b/mm/debug_vm_pgtable.c
>> @@ -542,9 +542,10 @@ static void __init pgd_populate_tests(struct mm_struct *mm, pgd_t *pgdp,
>> #endif /* PAGETABLE_P4D_FOLDED */
>>
>> static void __init pte_clear_tests(struct mm_struct *mm, pte_t *ptep,
>> - unsigned long vaddr)
>> + unsigned long pfn, unsigned long vaddr,
>> + pgprot_t prot)
>> {
>> - pte_t pte = ptep_get(ptep);
>> + pte_t pte = pfn_pte(pfn, prot);
>>
>> pr_debug("Validating PTE clear\n");
>> pte = __pte(pte_val(pte) | RANDOM_ORVALUE);
>> @@ -1049,7 +1050,7 @@ static int __init debug_vm_pgtable(void)
>>
>> ptl = pte_lockptr(mm, pmdp);
>> spin_lock(ptl);
>> - pte_clear_tests(mm, ptep, vaddr);
>> + pte_clear_tests(mm, ptep, pte_aligned, vaddr, prot);
>> pte_advanced_tests(mm, vma, ptep, pte_aligned, vaddr, prot);
>> pte_unmap_unlock(ptep, ptl);
>>
>> --
> This patch causes a panic at boot for RISC-V defconfig. The rootfs is here if it is needed:
> https://github.com/ClangBuiltLinux/boot-utils/blob/3b21a5b71451742866349ba4f18638c5a754e660/images/riscv/rootfs.cpio.zst
>
> $ make -skj"$(nproc)" ARCH=riscv CROSS_COMPILE=riscv64-linux- O=out/riscv distclean defconfig Image
>
> $ qemu-system-riscv64 -bios default -M virt -display none -initrd rootfs.cpio -kernel Image -m 512m -nodefaults -serial mon:stdio
> ...
>
> OpenSBI v0.6
> ____ _____ ____ _____
> / __ \ / ____| _ \_ _|
> | | | |_ __ ___ _ __ | (___ | |_) || |
> | | | | '_ \ / _ \ '_ \ \___ \| _ < | |
> | |__| | |_) | __/ | | |____) | |_) || |_
> \____/| .__/ \___|_| |_|_____/|____/_____|
> | |
> |_|
>
> Platform Name : QEMU Virt Machine
> Platform HART Features : RV64ACDFIMSU
> Platform Max HARTs : 8
> Current Hart : 0
> Firmware Base : 0x80000000
> Firmware Size : 120 KB
> Runtime SBI Version : 0.2
>
> MIDELEG : 0x0000000000000222
> MEDELEG : 0x000000000000b109
> PMP0 : 0x0000000080000000-0x000000008001ffff (A)
> PMP1 : 0x0000000000000000-0xffffffffffffffff (A,R,W,X)
> [ 0.000000] Linux version 5.9.0-rc4-next-20200910 (nathan@ubuntu-n2-xlarge-x86) (riscv64-linux-gcc (GCC) 10.2.0, GNU ld (GNU Binutils) 2.35) #1 SMP Thu Sep 10 19:10:43 MST 2020
> ...
> [ 0.294593] NET: Registered protocol family 17
> [ 0.295781] 9pnet: Installing 9P2000 support
> [ 0.296153] Key type dns_resolver registered
> [ 0.296694] debug_vm_pgtable: [debug_vm_pgtable ]: Validating architecture page table helpers
> [ 0.297635] Unable to handle kernel paging request at virtual address 0a7fffe01dafefc8
> [ 0.298029] Oops [#1]
> [ 0.298153] Modules linked in:
> [ 0.298433] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.9.0-rc4-next-20200910 #1
> [ 0.298792] epc: ffffffe000205afc ra : ffffffe0008be0aa sp : ffffffe01ae73d40
> [ 0.299078] gp : ffffffe0010b9b48 tp : ffffffe01ae68000 t0 : ffffffe008152000
> [ 0.299362] t1 : 0000000000000000 t2 : 0000000000000000 s0 : ffffffe01ae73d60
> [ 0.299648] s1 : bffffffffffffffb a0 : 0a7fffe01dafefc8 a1 : bffffffffffffffb
> [ 0.299948] a2 : ffffffe0010a2698 a3 : 0000000000000001 a4 : 0000000000000003
> [ 0.300231] a5 : 0000000000000800 a6 : fffffffff0000080 a7 : 000000001b642000
> [ 0.300521] s2 : ffffffe0081517b8 s3 : ffffffe008150a80 s4 : ffffffe01af30000
> [ 0.300806] s5 : ffffffe01f8ca9b8 s6 : ffffffe008150000 s7 : ffffffe0010bb100
> [ 0.301161] s8 : ffffffe0010bb108 s9 : 0000000000080202 s10: ffffffe0010bb928
> [ 0.301481] s11: 000000002008085b t3 : 0000000000000000 t4 : 0000000000000000
> [ 0.301722] t5 : 0000000000000000 t6 : ffffffe008150000
> [ 0.301947] status: 0000000000000120 badaddr: 0a7fffe01dafefc8 cause: 000000000000000f
> [ 0.302569] ---[ end trace 7ffb153d816164cf ]---
> [ 0.302797] note: swapper/0[1] exited with preempt_count 1
> [ 0.303101] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
> [ 0.303614] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---
I guess it is the combination of a valid pte and usage of
RANDOM_ORVALUE. The below change get the kernel to boot. Can somebody
faimilar with riscv pte format take a look at the RANDOM_ORVALUE?
modified mm/debug_vm_pgtable.c
@@ -548,7 +548,7 @@ static void __init pte_clear_tests(struct mm_struct *mm, pte_t *ptep,
pte_t pte = pfn_pte(pfn, prot);
pr_debug("Validating PTE clear\n");
- pte = __pte(pte_val(pte) | RANDOM_ORVALUE);
+// pte = __pte(pte_val(pte) | RANDOM_ORVALUE);
set_pte_at(mm, vaddr, ptep, pte);
barrier();
pte_clear(mm, vaddr, ptep);
^ permalink raw reply
* Re: [PATCH 1/7] powerpc/sysfs: Fix W=1 compile warning
From: Christophe Leroy @ 2020-09-11 5:26 UTC (permalink / raw)
To: Cédric Le Goater, Michael Ellerman; +Cc: Madhavan Srinivasan, linuxppc-dev
In-Reply-To: <20200910210250.1962595-2-clg@kaod.org>
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"
>
> Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
> Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Christophe Leroy <christophe.leroy@c-s.fr>
> ---
> arch/powerpc/kernel/sysfs.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c
> index 46b4ebc33db7..821a3dc4c924 100644
> --- a/arch/powerpc/kernel/sysfs.c
> +++ b/arch/powerpc/kernel/sysfs.c
> @@ -225,14 +225,13 @@ static DEVICE_ATTR(dscr_default, 0600,
> static void sysfs_create_dscr_default(void)
> {
> if (cpu_has_feature(CPU_FTR_DSCR)) {
> - int err = 0;
> int cpu;
>
> dscr_default = spr_default_dscr;
> for_each_possible_cpu(cpu)
> paca_ptrs[cpu]->dscr_default = dscr_default;
>
> - err = device_create_file(cpu_subsys.dev_root, &dev_attr_dscr_default);
> + device_create_file(cpu_subsys.dev_root, &dev_attr_dscr_default);
> }
> }
> #endif /* CONFIG_PPC64 */
>
^ permalink raw reply
* Re: [PATCH 2/7] powerpc/prom: Fix W=1 compile warning
From: Christophe Leroy @ 2020-09-11 5:33 UTC (permalink / raw)
To: Cédric Le Goater, Michael Ellerman; +Cc: linuxppc-dev
In-Reply-To: <20200910210250.1962595-3-clg@kaod.org>
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;
> - /*
> - * 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: Christophe Leroy @ 2020-09-11 5:38 UTC (permalink / raw)
To: Cédric Le Goater, Michael Ellerman; +Cc: Jordan Niethe, linuxppc-dev
In-Reply-To: <20200910210250.1962595-4-clg@kaod.org>
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.
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)'
Christophe
>
> return ea;
> }
>
^ permalink raw reply
* Re: [PATCH 4/7] powerpc/xive: Fix W=1 compile warning
From: Christophe Leroy @ 2020-09-11 5:40 UTC (permalink / raw)
To: Cédric Le Goater, Michael Ellerman; +Cc: linuxppc-dev
In-Reply-To: <20200910210250.1962595-5-clg@kaod.org>
Le 10/09/2020 à 23:02, Cédric Le Goater a écrit :
> CC arch/powerpc/sysdev/xive/common.o
> ../arch/powerpc/sysdev/xive/common.c:1568:6: error: no previous prototype for ‘xive_debug_show_cpu’ [-Werror=missing-prototypes]
> void xive_debug_show_cpu(struct seq_file *m, int cpu)
> ^~~~~~~~~~~~~~~~~~~
> ../arch/powerpc/sysdev/xive/common.c:1602:6: error: no previous prototype for ‘xive_debug_show_irq’ [-Werror=missing-prototypes]
> void xive_debug_show_irq(struct seq_file *m, u32 hw_irq, struct irq_data *d)
> ^~~~~~~~~~~~~~~~~~~
>
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.
There are two ways of fixing it:
- Add the missing prototype
- Make it static
You chose the second alternative, this needs to be told in the commit log.
> Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> ---
> arch/powerpc/sysdev/xive/common.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/sysdev/xive/common.c b/arch/powerpc/sysdev/xive/common.c
> index f591be9f01f4..a80440af491a 100644
> --- a/arch/powerpc/sysdev/xive/common.c
> +++ b/arch/powerpc/sysdev/xive/common.c
> @@ -1565,7 +1565,7 @@ static int __init xive_off(char *arg)
> }
> __setup("xive=off", xive_off);
>
> -void xive_debug_show_cpu(struct seq_file *m, int cpu)
> +static void xive_debug_show_cpu(struct seq_file *m, int cpu)
> {
> struct xive_cpu *xc = per_cpu(xive_cpu, cpu);
>
> @@ -1599,7 +1599,7 @@ void xive_debug_show_cpu(struct seq_file *m, int cpu)
> seq_puts(m, "\n");
> }
>
> -void xive_debug_show_irq(struct seq_file *m, u32 hw_irq, struct irq_data *d)
> +static void xive_debug_show_irq(struct seq_file *m, u32 hw_irq, struct irq_data *d)
> {
> struct irq_chip *chip = irq_data_get_irq_chip(d);
> int rc;
>
^ permalink raw reply
* Re: [PATCH 5/7] powerpc/powernv/pci: Fix W=1 compile warning
From: Christophe Leroy @ 2020-09-11 5:41 UTC (permalink / raw)
To: Cédric Le Goater, Michael Ellerman
Cc: linuxppc-dev, Oliver O'Halloran
In-Reply-To: <20200910210250.1962595-6-clg@kaod.org>
Le 10/09/2020 à 23:02, Cédric Le Goater a écrit :
> 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;
> ^~~~~~
>
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: Oliver O'Halloran <oohall@gmail.com>
> Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> ---
> arch/powerpc/platforms/powernv/pci-ioda.c | 8 --------
> 1 file changed, 8 deletions(-)
>
> diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
> index 023a4f987bb2..2b4ceb5e6ce4 100644
> --- a/arch/powerpc/platforms/powernv/pci-ioda.c
> +++ b/arch/powerpc/platforms/powernv/pci-ioda.c
> @@ -894,7 +894,6 @@ int pnv_ioda_deconfigure_pe(struct pnv_phb *phb, struct pnv_ioda_pe *pe)
>
> int pnv_ioda_configure_pe(struct pnv_phb *phb, struct pnv_ioda_pe *pe)
> {
> - struct pci_dev *parent;
> uint8_t bcomp, dcomp, fcomp;
> long rc, rid_end, rid;
>
> @@ -904,7 +903,6 @@ int pnv_ioda_configure_pe(struct pnv_phb *phb, struct pnv_ioda_pe *pe)
>
> dcomp = OPAL_IGNORE_RID_DEVICE_NUMBER;
> fcomp = OPAL_IGNORE_RID_FUNCTION_NUMBER;
> - parent = pe->pbus->self;
> if (pe->flags & PNV_IODA_PE_BUS_ALL)
> count = resource_size(&pe->pbus->busn_res);
> else
> @@ -925,12 +923,6 @@ int pnv_ioda_configure_pe(struct pnv_phb *phb, struct pnv_ioda_pe *pe)
> }
> rid_end = pe->rid + (count << 8);
> } else {
> -#ifdef CONFIG_PCI_IOV
> - if (pe->flags & PNV_IODA_PE_VF)
> - parent = pe->parent_dev;
> - else
> -#endif /* CONFIG_PCI_IOV */
> - parent = pe->pdev->bus->self;
> bcomp = OpalPciBusAll;
> dcomp = OPAL_COMPARE_RID_DEVICE_NUMBER;
> fcomp = OPAL_COMPARE_RID_FUNCTION_NUMBER;
>
^ 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
* 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 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 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: 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 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: [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] 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: [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: 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: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 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
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