* [PATCH 2/5] powerpc: don't use asm-generic/ptrace.h
From: Christoph Hellwig @ 2019-05-20 6:00 UTC (permalink / raw)
To: Oleg Nesterov, Arnd Bergmann
Cc: linux-arch, linux-sh, x86, linux-mips, linux-kernel, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <20190520060018.25569-1-hch@lst.de>
Doing the indirection through macros for the regs accessors just
makes them harder to read, so implement the helpers directly.
Note that only the helpers actually used are implemented now.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
arch/powerpc/include/asm/ptrace.h | 29 ++++++++++++++++++++++-------
1 file changed, 22 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/include/asm/ptrace.h b/arch/powerpc/include/asm/ptrace.h
index 6f047730e642..fc007d186a82 100644
--- a/arch/powerpc/include/asm/ptrace.h
+++ b/arch/powerpc/include/asm/ptrace.h
@@ -115,18 +115,33 @@ struct pt_regs
#ifndef __ASSEMBLY__
-#define GET_IP(regs) ((regs)->nip)
-#define GET_USP(regs) ((regs)->gpr[1])
-#define GET_FP(regs) (0)
-#define SET_FP(regs, val)
+static inline unsigned long instruction_pointer(struct pt_regs *regs)
+{
+ return regs->nip;
+}
+
+static inline void instruction_pointer_set(struct pt_regs *regs,
+ unsigned long val)
+{
+ regs->nip = val;
+}
+
+static inline unsigned long user_stack_pointer(struct pt_regs *regs)
+{
+ return regs->gpr[1];
+}
+
+static inline unsigned long frame_pointer(struct pt_regs *regs)
+{
+ return 0;
+}
#ifdef CONFIG_SMP
extern unsigned long profile_pc(struct pt_regs *regs);
-#define profile_pc profile_pc
+#else
+#define profile_pc(regs) instruction_pointer(regs)
#endif
-#include <asm-generic/ptrace.h>
-
#define kernel_stack_pointer(regs) ((regs)->gpr[1])
static inline int is_syscall_success(struct pt_regs *regs)
{
--
2.20.1
^ permalink raw reply related
* [PATCH] powerpc: dts: Fix the bug that intx interrupt not work in P1010RDB-PB
From: Xiaowei Bao @ 2019-05-20 5:53 UTC (permalink / raw)
To: robh+dt, mark.rutland, benh, paulus, mpe, devicetree,
linuxppc-dev, linux-kernel, minghuan.lian, mingkai.hu,
zhiqiang.hou, leoyang.li
Cc: Xiaowei Bao
Due to the INTA is shared with the active-low PHY2 interrupt on P1010RDB-PA
board, so configure P1010RDB-PA's INTA with polarity as active-low, the
P1010RDB-PB board is used separately, so configure P1010RDB-PB's INTA with
polarity as active-high.
The INTX in P1010RDB-PB do not work because of the pcie@0 node fixup will be
overwrited by p1010si-post.dtsi file, so we move the pcie@0 node fixup to
p1010rdb-pb.dts and p1010rdb-pb_36b.dts.
Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
---
arch/powerpc/boot/dts/fsl/p1010rdb-pb.dts | 16 ++++++++++++++++
arch/powerpc/boot/dts/fsl/p1010rdb-pb_36b.dts | 16 ++++++++++++++++
arch/powerpc/boot/dts/fsl/p1010rdb.dtsi | 16 ----------------
3 files changed, 32 insertions(+), 16 deletions(-)
diff --git a/arch/powerpc/boot/dts/fsl/p1010rdb-pb.dts b/arch/powerpc/boot/dts/fsl/p1010rdb-pb.dts
index 37681fd..6d75e5f 100644
--- a/arch/powerpc/boot/dts/fsl/p1010rdb-pb.dts
+++ b/arch/powerpc/boot/dts/fsl/p1010rdb-pb.dts
@@ -33,3 +33,19 @@
};
/include/ "p1010si-post.dtsi"
+
+&pci0 {
+ pcie@0 {
+ interrupt-map = <
+ /* IDSEL 0x0 */
+ /*
+ *irq[4:5] are active-high
+ *irq[6:7] are active-low
+ */
+ 0000 0x0 0x0 0x1 &mpic 0x4 0x2 0x0 0x0
+ 0000 0x0 0x0 0x2 &mpic 0x5 0x2 0x0 0x0
+ 0000 0x0 0x0 0x3 &mpic 0x6 0x1 0x0 0x0
+ 0000 0x0 0x0 0x4 &mpic 0x7 0x1 0x0 0x0
+ >;
+ };
+};
diff --git a/arch/powerpc/boot/dts/fsl/p1010rdb-pb_36b.dts b/arch/powerpc/boot/dts/fsl/p1010rdb-pb_36b.dts
index 4cf255f..8359035 100644
--- a/arch/powerpc/boot/dts/fsl/p1010rdb-pb_36b.dts
+++ b/arch/powerpc/boot/dts/fsl/p1010rdb-pb_36b.dts
@@ -56,3 +56,19 @@
};
/include/ "p1010si-post.dtsi"
+
+&pci0 {
+ pcie@0 {
+ interrupt-map = <
+ /* IDSEL 0x0 */
+ /*
+ *irq[4:5] are active-high
+ *irq[6:7] are active-low
+ */
+ 0000 0x0 0x0 0x1 &mpic 0x4 0x2 0x0 0x0
+ 0000 0x0 0x0 0x2 &mpic 0x5 0x2 0x0 0x0
+ 0000 0x0 0x0 0x3 &mpic 0x6 0x1 0x0 0x0
+ 0000 0x0 0x0 0x4 &mpic 0x7 0x1 0x0 0x0
+ >;
+ };
+};
diff --git a/arch/powerpc/boot/dts/fsl/p1010rdb.dtsi b/arch/powerpc/boot/dts/fsl/p1010rdb.dtsi
index 2ca9cee..ef49a7d 100644
--- a/arch/powerpc/boot/dts/fsl/p1010rdb.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p1010rdb.dtsi
@@ -215,19 +215,3 @@
phy-connection-type = "sgmii";
};
};
-
-&pci0 {
- pcie@0 {
- interrupt-map = <
- /* IDSEL 0x0 */
- /*
- *irq[4:5] are active-high
- *irq[6:7] are active-low
- */
- 0000 0x0 0x0 0x1 &mpic 0x4 0x2 0x0 0x0
- 0000 0x0 0x0 0x2 &mpic 0x5 0x2 0x0 0x0
- 0000 0x0 0x0 0x3 &mpic 0x6 0x1 0x0 0x0
- 0000 0x0 0x0 0x4 &mpic 0x7 0x1 0x0 0x0
- >;
- };
-};
--
1.7.1
^ permalink raw reply related
* [PATCH 1/5] arm64: don't use asm-generic/ptrace.h
From: Christoph Hellwig @ 2019-05-20 6:00 UTC (permalink / raw)
To: Oleg Nesterov, Arnd Bergmann
Cc: linux-arch, linux-sh, Catalin Marinas, x86, linux-mips,
linux-kernel, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20190520060018.25569-1-hch@lst.de>
Doing the indirection through macros for the regs accessors just
makes them harder to read, so implement the helpers directly.
Note that only the helpers actually used are implemented now.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
---
arch/arm64/include/asm/ptrace.h | 31 +++++++++++++++++++------------
1 file changed, 19 insertions(+), 12 deletions(-)
diff --git a/arch/arm64/include/asm/ptrace.h b/arch/arm64/include/asm/ptrace.h
index b2de32939ada..584261e00619 100644
--- a/arch/arm64/include/asm/ptrace.h
+++ b/arch/arm64/include/asm/ptrace.h
@@ -228,11 +228,12 @@ static inline void forget_syscall(struct pt_regs *regs)
#define fast_interrupts_enabled(regs) \
(!((regs)->pstate & PSR_F_BIT))
-#define GET_USP(regs) \
- (!compat_user_mode(regs) ? (regs)->sp : (regs)->compat_sp)
-
-#define SET_USP(ptregs, value) \
- (!compat_user_mode(regs) ? ((regs)->sp = value) : ((regs)->compat_sp = value))
+static inline unsigned long user_stack_pointer(struct pt_regs *regs)
+{
+ if (compat_user_mode(regs))
+ return regs->compat_sp;
+ return regs->sp;
+}
extern int regs_query_register_offset(const char *name);
extern unsigned long regs_get_kernel_stack_nth(struct pt_regs *regs,
@@ -331,13 +332,20 @@ static inline unsigned long regs_get_kernel_argument(struct pt_regs *regs,
struct task_struct;
int valid_user_regs(struct user_pt_regs *regs, struct task_struct *task);
-#define GET_IP(regs) ((unsigned long)(regs)->pc)
-#define SET_IP(regs, value) ((regs)->pc = ((u64) (value)))
-
-#define GET_FP(ptregs) ((unsigned long)(ptregs)->regs[29])
-#define SET_FP(ptregs, value) ((ptregs)->regs[29] = ((u64) (value)))
+static inline unsigned long instruction_pointer(struct pt_regs *regs)
+{
+ return regs->pc;
+}
+static inline void instruction_pointer_set(struct pt_regs *regs,
+ unsigned long val)
+{
+ regs->pc = val;
+}
-#include <asm-generic/ptrace.h>
+static inline unsigned long frame_pointer(struct pt_regs *regs)
+{
+ return regs->regs[29];
+}
#define procedure_link_pointer(regs) ((regs)->regs[30])
@@ -347,7 +355,6 @@ static inline void procedure_link_pointer_set(struct pt_regs *regs,
procedure_link_pointer(regs) = val;
}
-#undef profile_pc
extern unsigned long profile_pc(struct pt_regs *regs);
#endif /* __ASSEMBLY__ */
--
2.20.1
^ permalink raw reply related
* remove asm-generic/ptrace.h v2
From: Christoph Hellwig @ 2019-05-20 6:00 UTC (permalink / raw)
To: Oleg Nesterov, Arnd Bergmann
Cc: linux-arch, linux-sh, x86, linux-mips, linux-kernel, linuxppc-dev,
linux-arm-kernel
Hi all,
asm-generic/ptrace.h is a little weird in that it doesn't actually
implement any functionality, but it provided multiple layers of macros
that just implement trivial inline functions. We implement those
directly in the few architectures and be off with a much simpler
design.
Changes since v1:
- add a missing empty line between functions
^ permalink raw reply
* Re: PROBLEM: Power9: kernel oops on memory hotunplug from ppc64le guest
From: Bharata B Rao @ 2019-05-20 5:56 UTC (permalink / raw)
To: Nicholas Piggin
Cc: linux-kernel, linux-next, aneesh.kumar, bharata, srikanth,
linuxppc-dev
In-Reply-To: <1558327521.633yjtl8ki.astroid@bobo.none>
On Mon, May 20, 2019 at 02:48:35PM +1000, Nicholas Piggin wrote:
> >> > git bisect points to
> >> >
> >> > commit 4231aba000f5a4583dd9f67057aadb68c3eca99d
> >> > Author: Nicholas Piggin <npiggin@gmail.com>
> >> > Date: Fri Jul 27 21:48:17 2018 +1000
> >> >
> >> > powerpc/64s: Fix page table fragment refcount race vs speculative references
> >> >
> >> > The page table fragment allocator uses the main page refcount racily
> >> > with respect to speculative references. A customer observed a BUG due
> >> > to page table page refcount underflow in the fragment allocator. This
> >> > can be caused by the fragment allocator set_page_count stomping on a
> >> > speculative reference, and then the speculative failure handler
> >> > decrements the new reference, and the underflow eventually pops when
> >> > the page tables are freed.
> >> >
> >> > Fix this by using a dedicated field in the struct page for the page
> >> > table fragment allocator.
> >> >
> >> > Fixes: 5c1f6ee9a31c ("powerpc: Reduce PTE table memory wastage")
> >> > Cc: stable@vger.kernel.org # v3.10+
> >>
> >> That's the commit that added the BUG_ON(), so prior to that you won't
> >> see the crash.
> >
> > Right, but the commit says it fixes page table page refcount underflow by
> > introducing a new field &page->pt_frag_refcount. Now we are hitting the underflow
> > for this pt_frag_refcount.
>
> The fixed underflow is caused by a bug (race on page count) that got
> fixed by that patch. You are hitting a different underflow here. It's
> not certain my patch caused it, I'm just trying to reproduce now.
Ok.
>
> >
> > BTW, if I go below this commit, I don't hit the pagecount
> >
> > VM_BUG_ON_PAGE(page_ref_count(page) == 0, page);
> >
> > which is in pte_fragment_free() path.
>
> Do you have CONFIG_DEBUG_VM=y?
Yes.
Regards,
Bharata.
^ permalink raw reply
* Re: PROBLEM: Power9: kernel oops on memory hotunplug from ppc64le guest
From: Nicholas Piggin @ 2019-05-20 4:48 UTC (permalink / raw)
To: bharata, Michael Ellerman
Cc: aneesh.kumar, linux-kernel, srikanth, linux-next, bharata,
linuxppc-dev
In-Reply-To: <20190520042533.GB22939@in.ibm.com>
Bharata B Rao's on May 20, 2019 2:25 pm:
> On Mon, May 20, 2019 at 12:02:23PM +1000, Michael Ellerman wrote:
>> Bharata B Rao <bharata@linux.ibm.com> writes:
>> > On Thu, May 16, 2019 at 07:44:20PM +0530, srikanth wrote:
>> >> Hello,
>> >>
>> >> On power9 host, performing memory hotunplug from ppc64le guest results in
>> >> kernel oops.
>> >>
>> >> Kernel used : https://github.com/torvalds/linux/tree/v5.1 built using
>> >> ppc64le_defconfig for host and ppc64le_guest_defconfig for guest.
>> >>
>> >> Recreation steps:
>> >>
>> >> 1. Boot a guest with below mem configuration:
>> >> <maxMemory slots='32' unit='KiB'>33554432</maxMemory>
>> >> <memory unit='KiB'>8388608</memory>
>> >> <currentMemory unit='KiB'>4194304</currentMemory>
>> >> <cpu>
>> >> <numa>
>> >> <cell id='0' cpus='0-31' memory='8388608' unit='KiB'/>
>> >> </numa>
>> >> </cpu>
>> >>
>> >> 2. From host hotplug 8G memory -> verify memory hotadded succesfully -> now
>> >> reboot guest -> once guest comes back try to unplug 8G memory
>> >>
>> >> mem.xml used:
>> >> <memory model='dimm'>
>> >> <target>
>> >> <size unit='GiB'>8</size>
>> >> <node>0</node>
>> >> </target>
>> >> </memory>
>> >>
>> >> Memory attach and detach commands used:
>> >> virsh attach-device vm1 ./mem.xml --live
>> >> virsh detach-device vm1 ./mem.xml --live
>> >>
>> >> Trace seen inside guest after unplug, guest just hangs there forever:
>> >>
>> >> [ 21.962986] kernel BUG at arch/powerpc/mm/pgtable-frag.c:113!
>> >> [ 21.963064] Oops: Exception in kernel mode, sig: 5 [#1]
>> >> [ 21.963090] LE PAGE_SIZE=64K MMU=Radix MMU=Hash SMP NR_CPUS=2048 NUMA
>> >> pSeries
>> >> [ 21.963131] Modules linked in: xt_tcpudp iptable_filter squashfs fuse
>> >> vmx_crypto ib_iser rdma_cm iw_cm ib_cm ib_core libiscsi scsi_transport_iscsi
>> >> ip_tables x_tables autofs4 btrfs zstd_decompress zstd_compress lzo_compress
>> >> raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx
>> >> xor raid6_pq multipath crc32c_vpmsum
>> >> [ 21.963281] CPU: 11 PID: 316 Comm: kworker/u64:5 Kdump: loaded Not
>> >> tainted 5.1.0-dirty #2
>> >> [ 21.963323] Workqueue: pseries hotplug workque pseries_hp_work_fn
>> >> [ 21.963355] NIP: c000000000079e18 LR: c000000000c79308 CTR:
>> >> 0000000000008000
>> >> [ 21.963392] REGS: c0000003f88034f0 TRAP: 0700 Not tainted (5.1.0-dirty)
>> >> [ 21.963422] MSR: 800000000282b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR:
>> >> 28002884 XER: 20040000
>> >> [ 21.963470] CFAR: c000000000c79304 IRQMASK: 0
>> >> [ 21.963470] GPR00: c000000000c79308 c0000003f8803780 c000000001521000
>> >> 0000000000fff8c0
>> >> [ 21.963470] GPR04: 0000000000000001 00000000ffe30005 0000000000000005
>> >> 0000000000000020
>> >> [ 21.963470] GPR08: 0000000000000000 0000000000000001 c00a000000fff8e0
>> >> c0000000016d21a0
>> >> [ 21.963470] GPR12: c0000000016e7b90 c000000007ff2700 c00a000000a00000
>> >> c0000003ffe30100
>> >> [ 21.963470] GPR16: c0000003ffe30000 c0000000014aa4de c00a0000009f0000
>> >> c0000000016d21b0
>> >> [ 21.963470] GPR20: c0000000014de588 0000000000000001 c0000000016d21b8
>> >> c00a000000a00000
>> >> [ 21.963470] GPR24: 0000000000000000 ffffffffffffffff c00a000000a00000
>> >> c0000003ffe96000
>> >> [ 21.963470] GPR28: c00a000000a00000 c00a000000a00000 c0000003fffec000
>> >> c00a000000fff8c0
>> >> [ 21.963802] NIP [c000000000079e18] pte_fragment_free+0x48/0xd0
>> >> [ 21.963838] LR [c000000000c79308] remove_pagetable+0x49c/0x5b4
>> >> [ 21.963873] Call Trace:
>> >> [ 21.963890] [c0000003f8803780] [c0000003ffe997f0] 0xc0000003ffe997f0
>> >> (unreliable)
>> >> [ 21.963933] [c0000003f88037b0] [0000000000000000] (null)
>> >> [ 21.963969] [c0000003f88038c0] [c00000000006f038]
>> >> vmemmap_free+0x218/0x2e0
>> >> [ 21.964006] [c0000003f8803940] [c00000000036f100]
>> >> sparse_remove_one_section+0xd0/0x138
>> >> [ 21.964050] [c0000003f8803980] [c000000000383a50]
>> >> __remove_pages+0x410/0x560
>> >> [ 21.964093] [c0000003f8803a90] [c000000000c784d8]
>> >> arch_remove_memory+0x68/0xdc
>> >> [ 21.964136] [c0000003f8803ad0] [c000000000385d74]
>> >> __remove_memory+0xc4/0x110
>> >> [ 21.964180] [c0000003f8803b10] [c0000000000d44e4]
>> >> dlpar_remove_lmb+0x94/0x140
>> >> [ 21.964223] [c0000003f8803b50] [c0000000000d52b4]
>> >> dlpar_memory+0x464/0xd00
>> >> [ 21.964259] [c0000003f8803be0] [c0000000000cd5c0]
>> >> handle_dlpar_errorlog+0xc0/0x190
>> >> [ 21.964303] [c0000003f8803c50] [c0000000000cd6bc]
>> >> pseries_hp_work_fn+0x2c/0x60
>> >> [ 21.964346] [c0000003f8803c80] [c00000000013a4a0]
>> >> process_one_work+0x2b0/0x5a0
>> >> [ 21.964388] [c0000003f8803d10] [c00000000013a818]
>> >> worker_thread+0x88/0x610
>> >> [ 21.964434] [c0000003f8803db0] [c000000000143884] kthread+0x1a4/0x1b0
>> >> [ 21.964468] [c0000003f8803e20] [c00000000000bdc4]
>> >> ret_from_kernel_thread+0x5c/0x78
>> >> [ 21.964506] Instruction dump:
>> >> [ 21.964527] fbe1fff8 f821ffd1 78638502 78633664 ebe90000 7fff1a14
>> >> 395f0020 813f0020
>> >> [ 21.964569] 7d2907b4 7d2900d0 79290fe0 69290001 <0b090000> 7c0004ac
>> >> 7d205028 3129ffff
>> >> [ 21.964613] ---[ end trace aaa571aa1636fee6 ]---
>> >> [ 21.966349]
>> >> [ 21.966383] Sending IPI to other CPUs
>> >> [ 21.978335] IPI complete
>> >> [ 21.981354] kexec: Starting switchover sequence.
>> >> I'm in purgatory
>> >
>> > git bisect points to
>> >
>> > commit 4231aba000f5a4583dd9f67057aadb68c3eca99d
>> > Author: Nicholas Piggin <npiggin@gmail.com>
>> > Date: Fri Jul 27 21:48:17 2018 +1000
>> >
>> > powerpc/64s: Fix page table fragment refcount race vs speculative references
>> >
>> > The page table fragment allocator uses the main page refcount racily
>> > with respect to speculative references. A customer observed a BUG due
>> > to page table page refcount underflow in the fragment allocator. This
>> > can be caused by the fragment allocator set_page_count stomping on a
>> > speculative reference, and then the speculative failure handler
>> > decrements the new reference, and the underflow eventually pops when
>> > the page tables are freed.
>> >
>> > Fix this by using a dedicated field in the struct page for the page
>> > table fragment allocator.
>> >
>> > Fixes: 5c1f6ee9a31c ("powerpc: Reduce PTE table memory wastage")
>> > Cc: stable@vger.kernel.org # v3.10+
>>
>> That's the commit that added the BUG_ON(), so prior to that you won't
>> see the crash.
>
> Right, but the commit says it fixes page table page refcount underflow by
> introducing a new field &page->pt_frag_refcount. Now we are hitting the underflow
> for this pt_frag_refcount.
The fixed underflow is caused by a bug (race on page count) that got
fixed by that patch. You are hitting a different underflow here. It's
not certain my patch caused it, I'm just trying to reproduce now.
>
> BTW, if I go below this commit, I don't hit the pagecount
>
> VM_BUG_ON_PAGE(page_ref_count(page) == 0, page);
>
> which is in pte_fragment_free() path.
Do you have CONFIG_DEBUG_VM=y?
Thanks,
Nick
^ permalink raw reply
* Re: PROBLEM: Power9: kernel oops on memory hotunplug from ppc64le guest
From: Bharata B Rao @ 2019-05-20 4:25 UTC (permalink / raw)
To: Michael Ellerman
Cc: aneesh.kumar, linux-kernel, npiggin, linux-next, bharata,
srikanth, linuxppc-dev
In-Reply-To: <878sv1993k.fsf@concordia.ellerman.id.au>
On Mon, May 20, 2019 at 12:02:23PM +1000, Michael Ellerman wrote:
> Bharata B Rao <bharata@linux.ibm.com> writes:
> > On Thu, May 16, 2019 at 07:44:20PM +0530, srikanth wrote:
> >> Hello,
> >>
> >> On power9 host, performing memory hotunplug from ppc64le guest results in
> >> kernel oops.
> >>
> >> Kernel used : https://github.com/torvalds/linux/tree/v5.1 built using
> >> ppc64le_defconfig for host and ppc64le_guest_defconfig for guest.
> >>
> >> Recreation steps:
> >>
> >> 1. Boot a guest with below mem configuration:
> >> <maxMemory slots='32' unit='KiB'>33554432</maxMemory>
> >> <memory unit='KiB'>8388608</memory>
> >> <currentMemory unit='KiB'>4194304</currentMemory>
> >> <cpu>
> >> <numa>
> >> <cell id='0' cpus='0-31' memory='8388608' unit='KiB'/>
> >> </numa>
> >> </cpu>
> >>
> >> 2. From host hotplug 8G memory -> verify memory hotadded succesfully -> now
> >> reboot guest -> once guest comes back try to unplug 8G memory
> >>
> >> mem.xml used:
> >> <memory model='dimm'>
> >> <target>
> >> <size unit='GiB'>8</size>
> >> <node>0</node>
> >> </target>
> >> </memory>
> >>
> >> Memory attach and detach commands used:
> >> virsh attach-device vm1 ./mem.xml --live
> >> virsh detach-device vm1 ./mem.xml --live
> >>
> >> Trace seen inside guest after unplug, guest just hangs there forever:
> >>
> >> [ 21.962986] kernel BUG at arch/powerpc/mm/pgtable-frag.c:113!
> >> [ 21.963064] Oops: Exception in kernel mode, sig: 5 [#1]
> >> [ 21.963090] LE PAGE_SIZE=64K MMU=Radix MMU=Hash SMP NR_CPUS=2048 NUMA
> >> pSeries
> >> [ 21.963131] Modules linked in: xt_tcpudp iptable_filter squashfs fuse
> >> vmx_crypto ib_iser rdma_cm iw_cm ib_cm ib_core libiscsi scsi_transport_iscsi
> >> ip_tables x_tables autofs4 btrfs zstd_decompress zstd_compress lzo_compress
> >> raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx
> >> xor raid6_pq multipath crc32c_vpmsum
> >> [ 21.963281] CPU: 11 PID: 316 Comm: kworker/u64:5 Kdump: loaded Not
> >> tainted 5.1.0-dirty #2
> >> [ 21.963323] Workqueue: pseries hotplug workque pseries_hp_work_fn
> >> [ 21.963355] NIP: c000000000079e18 LR: c000000000c79308 CTR:
> >> 0000000000008000
> >> [ 21.963392] REGS: c0000003f88034f0 TRAP: 0700 Not tainted (5.1.0-dirty)
> >> [ 21.963422] MSR: 800000000282b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR:
> >> 28002884 XER: 20040000
> >> [ 21.963470] CFAR: c000000000c79304 IRQMASK: 0
> >> [ 21.963470] GPR00: c000000000c79308 c0000003f8803780 c000000001521000
> >> 0000000000fff8c0
> >> [ 21.963470] GPR04: 0000000000000001 00000000ffe30005 0000000000000005
> >> 0000000000000020
> >> [ 21.963470] GPR08: 0000000000000000 0000000000000001 c00a000000fff8e0
> >> c0000000016d21a0
> >> [ 21.963470] GPR12: c0000000016e7b90 c000000007ff2700 c00a000000a00000
> >> c0000003ffe30100
> >> [ 21.963470] GPR16: c0000003ffe30000 c0000000014aa4de c00a0000009f0000
> >> c0000000016d21b0
> >> [ 21.963470] GPR20: c0000000014de588 0000000000000001 c0000000016d21b8
> >> c00a000000a00000
> >> [ 21.963470] GPR24: 0000000000000000 ffffffffffffffff c00a000000a00000
> >> c0000003ffe96000
> >> [ 21.963470] GPR28: c00a000000a00000 c00a000000a00000 c0000003fffec000
> >> c00a000000fff8c0
> >> [ 21.963802] NIP [c000000000079e18] pte_fragment_free+0x48/0xd0
> >> [ 21.963838] LR [c000000000c79308] remove_pagetable+0x49c/0x5b4
> >> [ 21.963873] Call Trace:
> >> [ 21.963890] [c0000003f8803780] [c0000003ffe997f0] 0xc0000003ffe997f0
> >> (unreliable)
> >> [ 21.963933] [c0000003f88037b0] [0000000000000000] (null)
> >> [ 21.963969] [c0000003f88038c0] [c00000000006f038]
> >> vmemmap_free+0x218/0x2e0
> >> [ 21.964006] [c0000003f8803940] [c00000000036f100]
> >> sparse_remove_one_section+0xd0/0x138
> >> [ 21.964050] [c0000003f8803980] [c000000000383a50]
> >> __remove_pages+0x410/0x560
> >> [ 21.964093] [c0000003f8803a90] [c000000000c784d8]
> >> arch_remove_memory+0x68/0xdc
> >> [ 21.964136] [c0000003f8803ad0] [c000000000385d74]
> >> __remove_memory+0xc4/0x110
> >> [ 21.964180] [c0000003f8803b10] [c0000000000d44e4]
> >> dlpar_remove_lmb+0x94/0x140
> >> [ 21.964223] [c0000003f8803b50] [c0000000000d52b4]
> >> dlpar_memory+0x464/0xd00
> >> [ 21.964259] [c0000003f8803be0] [c0000000000cd5c0]
> >> handle_dlpar_errorlog+0xc0/0x190
> >> [ 21.964303] [c0000003f8803c50] [c0000000000cd6bc]
> >> pseries_hp_work_fn+0x2c/0x60
> >> [ 21.964346] [c0000003f8803c80] [c00000000013a4a0]
> >> process_one_work+0x2b0/0x5a0
> >> [ 21.964388] [c0000003f8803d10] [c00000000013a818]
> >> worker_thread+0x88/0x610
> >> [ 21.964434] [c0000003f8803db0] [c000000000143884] kthread+0x1a4/0x1b0
> >> [ 21.964468] [c0000003f8803e20] [c00000000000bdc4]
> >> ret_from_kernel_thread+0x5c/0x78
> >> [ 21.964506] Instruction dump:
> >> [ 21.964527] fbe1fff8 f821ffd1 78638502 78633664 ebe90000 7fff1a14
> >> 395f0020 813f0020
> >> [ 21.964569] 7d2907b4 7d2900d0 79290fe0 69290001 <0b090000> 7c0004ac
> >> 7d205028 3129ffff
> >> [ 21.964613] ---[ end trace aaa571aa1636fee6 ]---
> >> [ 21.966349]
> >> [ 21.966383] Sending IPI to other CPUs
> >> [ 21.978335] IPI complete
> >> [ 21.981354] kexec: Starting switchover sequence.
> >> I'm in purgatory
> >
> > git bisect points to
> >
> > commit 4231aba000f5a4583dd9f67057aadb68c3eca99d
> > Author: Nicholas Piggin <npiggin@gmail.com>
> > Date: Fri Jul 27 21:48:17 2018 +1000
> >
> > powerpc/64s: Fix page table fragment refcount race vs speculative references
> >
> > The page table fragment allocator uses the main page refcount racily
> > with respect to speculative references. A customer observed a BUG due
> > to page table page refcount underflow in the fragment allocator. This
> > can be caused by the fragment allocator set_page_count stomping on a
> > speculative reference, and then the speculative failure handler
> > decrements the new reference, and the underflow eventually pops when
> > the page tables are freed.
> >
> > Fix this by using a dedicated field in the struct page for the page
> > table fragment allocator.
> >
> > Fixes: 5c1f6ee9a31c ("powerpc: Reduce PTE table memory wastage")
> > Cc: stable@vger.kernel.org # v3.10+
>
> That's the commit that added the BUG_ON(), so prior to that you won't
> see the crash.
Right, but the commit says it fixes page table page refcount underflow by
introducing a new field &page->pt_frag_refcount. Now we are hitting the underflow
for this pt_frag_refcount.
BTW, if I go below this commit, I don't hit the pagecount
VM_BUG_ON_PAGE(page_ref_count(page) == 0, page);
which is in pte_fragment_free() path.
Regards,
Bharata.
^ permalink raw reply
* [PATCH] kbuild: do not check name uniqueness of builtin modules
From: Masahiro Yamada @ 2019-05-20 2:54 UTC (permalink / raw)
To: linux-kbuild
Cc: Michael Schmitz, Stephen Rothwell, linuxppc-dev, Kees Cook,
Arnd Bergmann, Masahiro Yamada, Greg KH, Rusty Russell,
Lucas De Marchi, linux-kernel, Lucas De Marchi, Linus Torvalds,
Jessica Yu, Sam Ravnborg
I just thought it was a good idea to scan builtin.modules in the name
uniqueness checking, but Stephen reported a false positive.
ppc64_defconfig produces:
warning: same basename if the following are built as modules:
arch/powerpc/platforms/powermac/nvram.ko
drivers/char/nvram.ko
..., which is a false positive because the former is never built as
a module as you see in arch/powerpc/platforms/powermac/Makefile:
# CONFIG_NVRAM is an arch. independent tristate symbol, for pmac32 we really
# need this to be a bool. Cheat here and pretend CONFIG_NVRAM=m is really
# CONFIG_NVRAM=y
obj-$(CONFIG_NVRAM:m=y) += nvram.o
Since we cannot predict how tricky Makefiles are written in wild,
builtin.modules may potentially contain false positives. I do not
think it is a big deal as far as kmod is concerned, but false positive
warnings in the kernel build makes people upset. It is better to not
do it.
Even without checking builtin.modules, we have enough (and more solid)
test coverage with allmodconfig.
While I touched this part, I replaced the sed code with neater one
provided by Stephen.
Link: https://lkml.org/lkml/2019/5/19/120
Link: https://lkml.org/lkml/2019/5/19/123
Fixes: 3a48a91901c5 ("kbuild: check uniqueness of module names")
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
scripts/modules-check.sh | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/scripts/modules-check.sh b/scripts/modules-check.sh
index 2f659530e1ec..39e8cb36ba19 100755
--- a/scripts/modules-check.sh
+++ b/scripts/modules-check.sh
@@ -6,10 +6,10 @@ set -e
# Check uniqueness of module names
check_same_name_modules()
{
- for m in $(sed 's:.*/::' modules.order modules.builtin | sort | uniq -d)
+ for m in $(sed 's:.*/::' modules.order | sort | uniq -d)
do
- echo "warning: same basename if the following are built as modules:" >&2
- sed "/\/$m/!d;s:^kernel/: :" modules.order modules.builtin >&2
+ echo "warning: same module names found:" >&2
+ sed -n "/\/$m/s:^kernel/: :p" modules.order >&2
done
}
--
2.17.1
^ permalink raw reply related
* RE: [PATCH V2 1/3] PM: wakeup: Add routine to help fetch wakeup source object.
From: Ran Wang @ 2019-05-20 2:15 UTC (permalink / raw)
To: Pavel Machek
Cc: Mark Rutland, Len Brown, devicetree@vger.kernel.org,
Greg Kroah-Hartman, linux-pm@vger.kernel.org, Rafael J . Wysocki,
linux-kernel@vger.kernel.org, Leo Li, Rob Herring,
linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190519213457.GG31403@amd>
Hi Pavel,
On Monday, May 20, 2019 05:35, Pavel Machek wrote:
>
> > --- a/include/linux/pm_wakeup.h
>
> > @@ -70,6 +71,7 @@ struct wakeup_source {
> > unsigned long wakeup_count;
> > bool active:1;
> > bool autosleep_enabled:1;
> > + struct device *attached_dev;
> > };
> >
> > #ifdef CONFIG_PM_SLEEP
>
> You might want to format this similary to the rest...
OK, will update, thanks.
Regards,
Ran
^ permalink raw reply
* Re: PROBLEM: Power9: kernel oops on memory hotunplug from ppc64le guest
From: Michael Ellerman @ 2019-05-20 2:02 UTC (permalink / raw)
To: bharata, srikanth
Cc: aneesh.kumar, linux-kernel, npiggin, linux-next, bharata,
linuxppc-dev
In-Reply-To: <20190518141434.GA22939@in.ibm.com>
Bharata B Rao <bharata@linux.ibm.com> writes:
> On Thu, May 16, 2019 at 07:44:20PM +0530, srikanth wrote:
>> Hello,
>>
>> On power9 host, performing memory hotunplug from ppc64le guest results in
>> kernel oops.
>>
>> Kernel used : https://github.com/torvalds/linux/tree/v5.1 built using
>> ppc64le_defconfig for host and ppc64le_guest_defconfig for guest.
>>
>> Recreation steps:
>>
>> 1. Boot a guest with below mem configuration:
>> <maxMemory slots='32' unit='KiB'>33554432</maxMemory>
>> <memory unit='KiB'>8388608</memory>
>> <currentMemory unit='KiB'>4194304</currentMemory>
>> <cpu>
>> <numa>
>> <cell id='0' cpus='0-31' memory='8388608' unit='KiB'/>
>> </numa>
>> </cpu>
>>
>> 2. From host hotplug 8G memory -> verify memory hotadded succesfully -> now
>> reboot guest -> once guest comes back try to unplug 8G memory
>>
>> mem.xml used:
>> <memory model='dimm'>
>> <target>
>> <size unit='GiB'>8</size>
>> <node>0</node>
>> </target>
>> </memory>
>>
>> Memory attach and detach commands used:
>> virsh attach-device vm1 ./mem.xml --live
>> virsh detach-device vm1 ./mem.xml --live
>>
>> Trace seen inside guest after unplug, guest just hangs there forever:
>>
>> [ 21.962986] kernel BUG at arch/powerpc/mm/pgtable-frag.c:113!
>> [ 21.963064] Oops: Exception in kernel mode, sig: 5 [#1]
>> [ 21.963090] LE PAGE_SIZE=64K MMU=Radix MMU=Hash SMP NR_CPUS=2048 NUMA
>> pSeries
>> [ 21.963131] Modules linked in: xt_tcpudp iptable_filter squashfs fuse
>> vmx_crypto ib_iser rdma_cm iw_cm ib_cm ib_core libiscsi scsi_transport_iscsi
>> ip_tables x_tables autofs4 btrfs zstd_decompress zstd_compress lzo_compress
>> raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx
>> xor raid6_pq multipath crc32c_vpmsum
>> [ 21.963281] CPU: 11 PID: 316 Comm: kworker/u64:5 Kdump: loaded Not
>> tainted 5.1.0-dirty #2
>> [ 21.963323] Workqueue: pseries hotplug workque pseries_hp_work_fn
>> [ 21.963355] NIP: c000000000079e18 LR: c000000000c79308 CTR:
>> 0000000000008000
>> [ 21.963392] REGS: c0000003f88034f0 TRAP: 0700 Not tainted (5.1.0-dirty)
>> [ 21.963422] MSR: 800000000282b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR:
>> 28002884 XER: 20040000
>> [ 21.963470] CFAR: c000000000c79304 IRQMASK: 0
>> [ 21.963470] GPR00: c000000000c79308 c0000003f8803780 c000000001521000
>> 0000000000fff8c0
>> [ 21.963470] GPR04: 0000000000000001 00000000ffe30005 0000000000000005
>> 0000000000000020
>> [ 21.963470] GPR08: 0000000000000000 0000000000000001 c00a000000fff8e0
>> c0000000016d21a0
>> [ 21.963470] GPR12: c0000000016e7b90 c000000007ff2700 c00a000000a00000
>> c0000003ffe30100
>> [ 21.963470] GPR16: c0000003ffe30000 c0000000014aa4de c00a0000009f0000
>> c0000000016d21b0
>> [ 21.963470] GPR20: c0000000014de588 0000000000000001 c0000000016d21b8
>> c00a000000a00000
>> [ 21.963470] GPR24: 0000000000000000 ffffffffffffffff c00a000000a00000
>> c0000003ffe96000
>> [ 21.963470] GPR28: c00a000000a00000 c00a000000a00000 c0000003fffec000
>> c00a000000fff8c0
>> [ 21.963802] NIP [c000000000079e18] pte_fragment_free+0x48/0xd0
>> [ 21.963838] LR [c000000000c79308] remove_pagetable+0x49c/0x5b4
>> [ 21.963873] Call Trace:
>> [ 21.963890] [c0000003f8803780] [c0000003ffe997f0] 0xc0000003ffe997f0
>> (unreliable)
>> [ 21.963933] [c0000003f88037b0] [0000000000000000] (null)
>> [ 21.963969] [c0000003f88038c0] [c00000000006f038]
>> vmemmap_free+0x218/0x2e0
>> [ 21.964006] [c0000003f8803940] [c00000000036f100]
>> sparse_remove_one_section+0xd0/0x138
>> [ 21.964050] [c0000003f8803980] [c000000000383a50]
>> __remove_pages+0x410/0x560
>> [ 21.964093] [c0000003f8803a90] [c000000000c784d8]
>> arch_remove_memory+0x68/0xdc
>> [ 21.964136] [c0000003f8803ad0] [c000000000385d74]
>> __remove_memory+0xc4/0x110
>> [ 21.964180] [c0000003f8803b10] [c0000000000d44e4]
>> dlpar_remove_lmb+0x94/0x140
>> [ 21.964223] [c0000003f8803b50] [c0000000000d52b4]
>> dlpar_memory+0x464/0xd00
>> [ 21.964259] [c0000003f8803be0] [c0000000000cd5c0]
>> handle_dlpar_errorlog+0xc0/0x190
>> [ 21.964303] [c0000003f8803c50] [c0000000000cd6bc]
>> pseries_hp_work_fn+0x2c/0x60
>> [ 21.964346] [c0000003f8803c80] [c00000000013a4a0]
>> process_one_work+0x2b0/0x5a0
>> [ 21.964388] [c0000003f8803d10] [c00000000013a818]
>> worker_thread+0x88/0x610
>> [ 21.964434] [c0000003f8803db0] [c000000000143884] kthread+0x1a4/0x1b0
>> [ 21.964468] [c0000003f8803e20] [c00000000000bdc4]
>> ret_from_kernel_thread+0x5c/0x78
>> [ 21.964506] Instruction dump:
>> [ 21.964527] fbe1fff8 f821ffd1 78638502 78633664 ebe90000 7fff1a14
>> 395f0020 813f0020
>> [ 21.964569] 7d2907b4 7d2900d0 79290fe0 69290001 <0b090000> 7c0004ac
>> 7d205028 3129ffff
>> [ 21.964613] ---[ end trace aaa571aa1636fee6 ]---
>> [ 21.966349]
>> [ 21.966383] Sending IPI to other CPUs
>> [ 21.978335] IPI complete
>> [ 21.981354] kexec: Starting switchover sequence.
>> I'm in purgatory
>
> git bisect points to
>
> commit 4231aba000f5a4583dd9f67057aadb68c3eca99d
> Author: Nicholas Piggin <npiggin@gmail.com>
> Date: Fri Jul 27 21:48:17 2018 +1000
>
> powerpc/64s: Fix page table fragment refcount race vs speculative references
>
> The page table fragment allocator uses the main page refcount racily
> with respect to speculative references. A customer observed a BUG due
> to page table page refcount underflow in the fragment allocator. This
> can be caused by the fragment allocator set_page_count stomping on a
> speculative reference, and then the speculative failure handler
> decrements the new reference, and the underflow eventually pops when
> the page tables are freed.
>
> Fix this by using a dedicated field in the struct page for the page
> table fragment allocator.
>
> Fixes: 5c1f6ee9a31c ("powerpc: Reduce PTE table memory wastage")
> Cc: stable@vger.kernel.org # v3.10+
That's the commit that added the BUG_ON(), so prior to that you won't
see the crash.
cheers
^ permalink raw reply
* Re: [PATCH] crypto: vmx - CTR: always increment IV as quadword
From: Daniel Axtens @ 2019-05-20 1:59 UTC (permalink / raw)
To: mpe, ebiggers, linux-crypto, Herbert Xu
Cc: leo.barbosa, Stephan Mueller, nayna, omosnacek, leitao, pfsmorigo,
marcelo.cerri, gcwilson, linuxppc-dev
In-Reply-To: <20190515102450.30557-1-dja@axtens.net>
Daniel Axtens <dja@axtens.net> writes:
> The kernel self-tests picked up an issue with CTR mode:
> alg: skcipher: p8_aes_ctr encryption test failed (wrong result) on test vector 3, cfg="uneven misaligned splits, may sleep"
>
> Test vector 3 has an IV of FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFD, so
> after 3 increments it should wrap around to 0.
>
> In the aesp8-ppc code from OpenSSL, there are two paths that
> increment IVs: the bulk (8 at a time) path, and the individual
> path which is used when there are fewer than 8 AES blocks to
> process.
>
> In the bulk path, the IV is incremented with vadduqm: "Vector
> Add Unsigned Quadword Modulo", which does 128-bit addition.
>
> In the individual path, however, the IV is incremented with
> vadduwm: "Vector Add Unsigned Word Modulo", which instead
> does 4 32-bit additions. Thus the IV would instead become
> FFFFFFFFFFFFFFFFFFFFFFFF00000000, throwing off the result.
>
> Use vadduqm.
>
> This was probably a typo originally, what with q and w being
> adjacent. It is a pretty narrow edge case: I am really
> impressed by the quality of the kernel self-tests!
>
> Fixes: 5c380d623ed3 ("crypto: vmx - Add support for VMS instructions by ASM")
> Cc: stable@vger.kernel.org
> Signed-off-by: Daniel Axtens <dja@axtens.net>
>
> ---
>
> I'll pass this along internally to get it into OpenSSL as well.
I passed this along to OpenSSL and got pretty comprehensively schooled:
https://github.com/openssl/openssl/pull/8942
It seems we tweak the openssl code to use a 128-bit counter, whereas
the original code was in fact designed for a 32-bit counter. We must
have changed the vaddu instruction in the bulk path but not in the
individual path, as they're both vadduwm (4x32-bit) upstream.
I think this change is still correct with regards to the kernel,
but I guess it's probably something where I should have done a more
thorough read of the documentation before diving in to the code, and
perhaps we should note it in the code somewhere too. Ah well.
Regards,
Daniel
> ---
> drivers/crypto/vmx/aesp8-ppc.pl | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/crypto/vmx/aesp8-ppc.pl b/drivers/crypto/vmx/aesp8-ppc.pl
> index de78282b8f44..9c6b5c1d6a1a 100644
> --- a/drivers/crypto/vmx/aesp8-ppc.pl
> +++ b/drivers/crypto/vmx/aesp8-ppc.pl
> @@ -1357,7 +1357,7 @@ Loop_ctr32_enc:
> addi $idx,$idx,16
> bdnz Loop_ctr32_enc
>
> - vadduwm $ivec,$ivec,$one
> + vadduqm $ivec,$ivec,$one
> vmr $dat,$inptail
> lvx $inptail,0,$inp
> addi $inp,$inp,16
> --
> 2.19.1
^ permalink raw reply
* [Bug 203597] kernel 4.9.175 fails to boot on a PowerMac G4 3,6 at early stage
From: bugzilla-daemon @ 2019-05-20 1:53 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-203597-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=203597
Michael Ellerman (michael@ellerman.id.au) changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |CLOSED
CC| |michael@ellerman.id.au
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* Re: [PATCH] ocxl: Fix potential memory leak on context creation
From: Andrew Donnellan @ 2019-05-20 1:45 UTC (permalink / raw)
To: Frederic Barrat, linuxppc-dev, andrew.donnellan, alastair; +Cc: clombard
In-Reply-To: <20190517142054.13933-1-fbarrat@linux.ibm.com>
On 18/5/19 12:20 am, Frederic Barrat wrote:
> If we couldn't fully init a context, we were leaking memory.
>
> Fixes: b9721d275cc2 ("ocxl: Allow external drivers to use OpenCAPI contexts")
> Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com>
Acked-by: Andrew Donnellan <ajd@linux.ibm.com>
> ---
> drivers/misc/ocxl/context.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/misc/ocxl/context.c b/drivers/misc/ocxl/context.c
> index bab9c9364184..ab93156aa83e 100644
> --- a/drivers/misc/ocxl/context.c
> +++ b/drivers/misc/ocxl/context.c
> @@ -22,6 +22,7 @@ int ocxl_context_alloc(struct ocxl_context **context, struct ocxl_afu *afu,
> afu->pasid_base + afu->pasid_max, GFP_KERNEL);
> if (pasid < 0) {
> mutex_unlock(&afu->contexts_lock);
> + kfree(*context);
(defensive programming: set *context = NULL so that if the caller
ignores the return code we get an obvious crash)
> return pasid;
> }
> afu->pasid_count++;
>
--
Andrew Donnellan OzLabs, ADL Canberra
ajd@linux.ibm.com IBM Australia Limited
^ permalink raw reply
* Re: [PATCH V2 1/3] PM: wakeup: Add routine to help fetch wakeup source object.
From: Pavel Machek @ 2019-05-19 21:34 UTC (permalink / raw)
To: Ran Wang
Cc: Mark Rutland, Len Brown, devicetree, Greg Kroah-Hartman, linux-pm,
Rafael J . Wysocki, linux-kernel, Li Yang, Rob Herring,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <20190517033946.30763-1-ran.wang_1@nxp.com>
[-- Attachment #1: Type: text/plain, Size: 459 bytes --]
> --- a/include/linux/pm_wakeup.h
> @@ -70,6 +71,7 @@ struct wakeup_source {
> unsigned long wakeup_count;
> bool active:1;
> bool autosleep_enabled:1;
> + struct device *attached_dev;
> };
>
> #ifdef CONFIG_PM_SLEEP
You might want to format this similary to the rest...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH V2 3/3] soc: fsl: add RCPM driver
From: Pavel Machek @ 2019-05-19 21:38 UTC (permalink / raw)
To: Ran Wang
Cc: Mark Rutland, Len Brown, devicetree, Greg Kroah-Hartman, linux-pm,
Rafael J . Wysocki, linux-kernel, Li Yang, Rob Herring,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <20190517033946.30763-3-ran.wang_1@nxp.com>
[-- Attachment #1: Type: text/plain, Size: 968 bytes --]
Hi!
> +
> +struct rcpm {
> + unsigned int wakeup_cells;
> + void __iomem *ippdexpcr_base;
> + bool little_endian;
> +};
Inconsistent whitespace
> +static int rcpm_pm_prepare(struct device *dev)
> +{
> + struct device_node *np = dev->of_node;
> + struct wakeup_source *ws;
> + struct rcpm *rcpm;
> + u32 value[RCPM_WAKEUP_CELL_MAX_SIZE + 1], tmp;
> + int i, ret;
> +
> + rcpm = dev_get_drvdata(dev);
> + if (!rcpm)
> + return -EINVAL;
> +
> + /* Begin with first registered wakeup source */
> + ws = wakeup_source_get_next(NULL);
> + while (ws) {
while (ws = wakeup_source_get_next(NULL)) ?
> +static int rcpm_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct resource *r;
> + struct rcpm *rcpm;
> + int ret;
Whitespace.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* [Bug 203597] kernel 4.9.175 fails to boot on a PowerMac G4 3,6 at early stage
From: bugzilla-daemon @ 2019-05-19 20:11 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-203597-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=203597
Erhard F. (erhard_f@mailbox.org) changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |CODE_FIX
--- Comment #3 from Erhard F. (erhard_f@mailbox.org) ---
(In reply to Christophe Leroy from comment #2)
> You are missing following commit:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/
> ?id=b45ba4a51cd
Your fix landed in 4.9.177 and I can confirm my G4 boots fine now. Thanks!
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* [Bug 203647] Locking API testsuite fails "mixed read-lock/lock-write ABBA" rlock on kernels >=4.14.x
From: bugzilla-daemon @ 2019-05-19 19:37 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-203647-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=203647
--- Comment #5 from Erhard F. (erhard_f@mailbox.org) ---
Created attachment 282841
--> https://bugzilla.kernel.org/attachment.cgi?id=282841&action=edit
kernel .config (5.1.3, G5 11,2)
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* [Bug 203647] Locking API testsuite fails "mixed read-lock/lock-write ABBA" rlock on kernels >=4.14.x
From: bugzilla-daemon @ 2019-05-19 19:36 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-203647-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=203647
--- Comment #4 from Erhard F. (erhard_f@mailbox.org) ---
Created attachment 282839
--> https://bugzilla.kernel.org/attachment.cgi?id=282839&action=edit
dmesg (4.9.177, G5 11,2)
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* [Bug 203647] Locking API testsuite fails "mixed read-lock/lock-write ABBA" rlock on kernels >=4.14.x
From: bugzilla-daemon @ 2019-05-19 19:36 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-203647-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=203647
--- Comment #3 from Erhard F. (erhard_f@mailbox.org) ---
Created attachment 282837
--> https://bugzilla.kernel.org/attachment.cgi?id=282837&action=edit
dmesg (4.14.120, G5 11,2)
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* [Bug 203647] Locking API testsuite fails "mixed read-lock/lock-write ABBA" rlock on kernels >=4.14.x
From: bugzilla-daemon @ 2019-05-19 19:35 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-203647-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=203647
--- Comment #2 from Erhard F. (erhard_f@mailbox.org) ---
Created attachment 282835
--> https://bugzilla.kernel.org/attachment.cgi?id=282835&action=edit
dmesg (4.19.44, G5 11,2)
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* [Bug 203647] Locking API testsuite fails "mixed read-lock/lock-write ABBA" rlock on kernels >=4.14.x
From: bugzilla-daemon @ 2019-05-19 19:35 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-203647-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=203647
--- Comment #1 from Erhard F. (erhard_f@mailbox.org) ---
Created attachment 282833
--> https://bugzilla.kernel.org/attachment.cgi?id=282833&action=edit
dmesg (5.0.17, G5 11,2)
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* [Bug 203647] New: Locking API testsuite fails "mixed read-lock/lock-write ABBA" rlock on kernels >=4.14.x
From: bugzilla-daemon @ 2019-05-19 19:34 UTC (permalink / raw)
To: linuxppc-dev
https://bugzilla.kernel.org/show_bug.cgi?id=203647
Bug ID: 203647
Summary: Locking API testsuite fails "mixed
read-lock/lock-write ABBA" rlock on kernels >=4.14.x
Product: Platform Specific/Hardware
Version: 2.5
Kernel Version: 5.1.3
Hardware: All
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: PPC-64
Assignee: platform_ppc-64@kernel-bugs.osdl.org
Reporter: erhard_f@mailbox.org
Regression: No
Created attachment 282831
--> https://bugzilla.kernel.org/attachment.cgi?id=282831&action=edit
dmesg (5.1.3, G5 11,2)
Probably this test fails on ppc64 since it is around. Kernel 4.9.x passes all
tests, since it does not seem to contain "mixed read-lock/lock-write ABBA".
Machine is a PowerMac G5 11,2 running Gentoo Linux ppc64, Big Endian, 4 KiB
pagesize.
[ 0.002051] ------------------------
[ 0.002065] | Locking API testsuite:
[ 0.002079]
----------------------------------------------------------------------------
[ 0.002111] | spin |wlock |rlock |mutex |
wsem | rsem |
[ 0.002142]
--------------------------------------------------------------------------
[ 0.002179] A-A deadlock: ok | ok | ok | ok |
ok | ok | ok |
[ 0.007366] A-B-B-A deadlock: ok | ok | ok | ok |
ok | ok | ok |
[ 0.012471] A-B-B-C-C-A deadlock: ok | ok | ok | ok |
ok | ok | ok |
[ 0.017598] A-B-C-A-B-C deadlock: ok | ok | ok | ok |
ok | ok | ok |
[ 0.022740] A-B-B-C-C-D-D-A deadlock: ok | ok | ok | ok |
ok | ok | ok |
[ 0.027912] A-B-C-D-B-D-D-A deadlock: ok | ok | ok | ok |
ok | ok | ok |
[ 0.033083] A-B-C-D-B-C-D-A deadlock: ok | ok | ok | ok |
ok | ok | ok |
[ 0.038269] double unlock: ok | ok | ok | ok |
ok | ok | ok |
[ 0.043319] initialize held: ok | ok | ok | ok |
ok | ok | ok |
[ 0.048379]
--------------------------------------------------------------------------
[ 0.048411] recursive read-lock: | ok |
| ok |
[ 0.049894] recursive read-lock #2: | ok |
| ok |
[ 0.051375] mixed read-write-lock: | ok |
| ok |
[ 0.052859] mixed write-read-lock: | ok |
| ok |
[ 0.054333] mixed read-lock/lock-write ABBA: |FAILED|
| ok |
[ 0.055802] mixed read-lock/lock-read ABBA: | ok |
| ok |
[ 0.057290] mixed write-lock/lock-write ABBA: | ok |
| ok |
[ 0.058771]
--------------------------------------------------------------------------
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.2-2 tag
From: pr-tracker-bot @ 2019-05-19 17:45 UTC (permalink / raw)
To: Michael Ellerman
Cc: aneesh.kumar, linux-kernel, Linus Torvalds, tobin, linuxppc-dev
In-Reply-To: <87bm00818p.fsf@concordia.ellerman.id.au>
The pull request you sent on Sat, 18 May 2019 21:12:54 +1000:
> https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-5.2-2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/86a78a8b8d0414455c2174852968ce54205add82
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
^ permalink raw reply
* Re: [PATCH] mm/nvdimm: Pick the right alignment default when creating dax devices
From: Dan Williams @ 2019-05-19 16:30 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: Linux MM, Vaibhav Jain, linuxppc-dev, linux-nvdimm
In-Reply-To: <87sgtaddru.fsf@linux.ibm.com>
On Sun, May 19, 2019 at 1:55 AM Aneesh Kumar K.V
<aneesh.kumar@linux.ibm.com> wrote:
>
>
> Hi Dan,
>
> "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> writes:
>
> > On 5/17/19 8:19 PM, Vaibhav Jain wrote:
> >> Hi Aneesh,
> >>
>
> ....
>
> >>
> >>> + /*
> >>> + * Check whether the we support the alignment. For Dax if the
> >>> + * superblock alignment is not matching, we won't initialize
> >>> + * the device.
> >>> + */
> >>> + if (!nd_supported_alignment(align) &&
> >>> + memcmp(pfn_sb->signature, DAX_SIG, PFN_SIG_LEN)) {
> >> Suggestion to change this check to:
> >>
> >> if (memcmp(pfn_sb->signature, DAX_SIG, PFN_SIG_LEN) &&
> >> !nd_supported_alignment(align))
> >>
> >> It would look a bit more natural i.e. "If the device has dax signature and alignment is
> >> not supported".
> >>
> >
> > I guess that should be !memcmp()? . I will send an updated patch with
> > the hash failure details in the commit message.
> >
>
> We need clarification on what the expected failure behaviour should be.
> The nd_pmem_probe doesn't really have a failure behaviour in this
> regard. For example.
>
> I created a dax device with 16M alignment
>
> {
> "dev":"namespace0.0",
> "mode":"devdax",
> "map":"dev",
> "size":"9.98 GiB (10.72 GB)",
> "uuid":"ba62ef22-ebdf-4779-96f5-e6135383ed22",
> "raw_uuid":"7b2492f9-7160-4ee9-9c3d-2f547d9ef3ee",
> "daxregion":{
> "id":0,
> "size":"9.98 GiB (10.72 GB)",
> "align":16777216,
> "devices":[
> {
> "chardev":"dax0.0",
> "size":"9.98 GiB (10.72 GB)"
> }
> ]
> },
> "align":16777216,
> "numa_node":0,
> "supported_alignments":[
> 65536,
> 16777216
> ]
> }
>
> Now what we want is to fail the initialization of the device when we
> boot a kernel that doesn't support 16M page size. But with the
> nd_pmem_probe failure behaviour we now end up with
>
> [
> {
> "dev":"namespace0.0",
> "mode":"fsdax",
> "map":"mem",
> "size":10737418240,
> "uuid":"7b2492f9-7160-4ee9-9c3d-2f547d9ef3ee",
> "blockdev":"pmem0"
> }
> ]
>
> So it did fallthrough the
>
> /* if we find a valid info-block we'll come back as that personality */
> if (nd_btt_probe(dev, ndns) == 0 || nd_pfn_probe(dev, ndns) == 0
> || nd_dax_probe(dev, ndns) == 0)
> return -ENXIO;
>
> /* ...otherwise we're just a raw pmem device */
> return pmem_attach_disk(dev, ndns);
>
>
> Is it ok if i update the code such that we don't do that default
> pmem_atach_disk if we have a label area?
Yes. This seems a new case where the driver finds a valid info-block,
but the capability to load that configuration is missing. So perhaps
special case a EOPNOTSUPP return code from those info-block probe
routines as "fail, and don't fallback to a raw device".
^ permalink raw reply
* Re: [PATCH] mm/nvdimm: Pick the right alignment default when creating dax devices
From: Aneesh Kumar K.V @ 2019-05-19 8:55 UTC (permalink / raw)
To: dan.j.williams; +Cc: linux-mm, Vaibhav Jain, linuxppc-dev, linux-nvdimm
In-Reply-To: <de5cbe7d-bd47-6793-1f1a-2274c5c59eb5@linux.ibm.com>
Hi Dan,
"Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> writes:
> On 5/17/19 8:19 PM, Vaibhav Jain wrote:
>> Hi Aneesh,
>>
....
>>
>>> + /*
>>> + * Check whether the we support the alignment. For Dax if the
>>> + * superblock alignment is not matching, we won't initialize
>>> + * the device.
>>> + */
>>> + if (!nd_supported_alignment(align) &&
>>> + memcmp(pfn_sb->signature, DAX_SIG, PFN_SIG_LEN)) {
>> Suggestion to change this check to:
>>
>> if (memcmp(pfn_sb->signature, DAX_SIG, PFN_SIG_LEN) &&
>> !nd_supported_alignment(align))
>>
>> It would look a bit more natural i.e. "If the device has dax signature and alignment is
>> not supported".
>>
>
> I guess that should be !memcmp()? . I will send an updated patch with
> the hash failure details in the commit message.
>
We need clarification on what the expected failure behaviour should be.
The nd_pmem_probe doesn't really have a failure behaviour in this
regard. For example.
I created a dax device with 16M alignment
{
"dev":"namespace0.0",
"mode":"devdax",
"map":"dev",
"size":"9.98 GiB (10.72 GB)",
"uuid":"ba62ef22-ebdf-4779-96f5-e6135383ed22",
"raw_uuid":"7b2492f9-7160-4ee9-9c3d-2f547d9ef3ee",
"daxregion":{
"id":0,
"size":"9.98 GiB (10.72 GB)",
"align":16777216,
"devices":[
{
"chardev":"dax0.0",
"size":"9.98 GiB (10.72 GB)"
}
]
},
"align":16777216,
"numa_node":0,
"supported_alignments":[
65536,
16777216
]
}
Now what we want is to fail the initialization of the device when we
boot a kernel that doesn't support 16M page size. But with the
nd_pmem_probe failure behaviour we now end up with
[
{
"dev":"namespace0.0",
"mode":"fsdax",
"map":"mem",
"size":10737418240,
"uuid":"7b2492f9-7160-4ee9-9c3d-2f547d9ef3ee",
"blockdev":"pmem0"
}
]
So it did fallthrough the
/* if we find a valid info-block we'll come back as that personality */
if (nd_btt_probe(dev, ndns) == 0 || nd_pfn_probe(dev, ndns) == 0
|| nd_dax_probe(dev, ndns) == 0)
return -ENXIO;
/* ...otherwise we're just a raw pmem device */
return pmem_attach_disk(dev, ndns);
Is it ok if i update the code such that we don't do that default
pmem_atach_disk if we have a label area?
-aneesh
^ 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