Re: [PATCH RFC v1] drivers/base/node: consolidate node device subsystem initialization in node_dev_init()
On 31.01.22 07:23, Oscar Salvador wrote: > On Fri, Jan 28, 2022 at 04:15:40PM +0100, David Hildenbrand wrote: >> ... and call node_dev_init() after memory_dev_init() from driver_init(), >> so before any of the existing arch/subsys calls. All online nodes should >> be known at that point. >> >> This is in line with memory_dev_init(), which initializes the memory >> device subsystem and creates all memory block devices. >> >> Similar to memory_dev_init(), panic() if anything goes wrong, we don't >> want to continue with such basic initialization errors. >> >> The important part is that node_dev_init() gets called after >> memory_dev_init() and after cpu_dev_init(), but before any of the >> relevant archs call register_cpu() to register the new cpu device under >> the node device. The latter should be the case for the current users >> of topology_init(). > Hi Oscar, > So, before this change we had something like this: > > do_basic_setup > driver_init > memory_dev_init > do_init_calls > ... >topology_init > register_nodes/register_one_node > > And after the patch all happens in driver_init() > > driver_init > memory_dev_init > node_dev_init > > I guess this is fine as we do not have any ordering problems (aka: none > of the functions we used to call before expect the nodes not to be > there for some weird reason). > > So, no functional change, right? > Right, and the idea is that the online state of nodes (+ node/zone ranges) already has to be known at that point in time, because otherwise, we'd be in bigger trouble. Thanks! -- Thanks, David / dhildenb
[Bug 215389] pagealloc: memory corruption at building glibc-2.33 and running its' testsuite
https://bugzilla.kernel.org/show_bug.cgi?id=215389 --- Comment #10 from Christophe Leroy (christophe.le...@csgroup.eu) --- Thanks for the tests. I'm not surprised that the system doesn't poweroff or reboot without ADB_PMU because the PMU manages power. The "neverending build" is maybe because the PMU also manages RTC clock and without it you get inconsistent time ? Anyway, it looks like there is indeed something linked to VMAP_STACK. I'm wondering whether you could be running out of vmalloc space. I initially thought you were using KASAN, but it seems not according to your .config. Could you try reducing CONFIG_LOWMEM_SIZE to 0x2800 for instance and see if the memory corruption still happens ? To do this you'll need CONFIG_ADVANCED_OPTIONS and CONFIG_LOWMEM_SIZE_BOOL. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[PATCH] powerpc/603: Clear C bit when PTE is read only
On book3s/32 MMU, PP bits don't offer kernel RO protection, kernel pages are always RW. However, on the 603 a page fault is always generated when the C bit (change bit = dirty bit) is not set. Enforce kernel RO protection by clearing C bit in TLB miss handler when the page doesn't have _PAGE_RW flag. Signed-off-by: Christophe Leroy --- arch/powerpc/kernel/head_book3s_32.S | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/powerpc/kernel/head_book3s_32.S b/arch/powerpc/kernel/head_book3s_32.S index 7f4f3a52b730..6c739beb938c 100644 --- a/arch/powerpc/kernel/head_book3s_32.S +++ b/arch/powerpc/kernel/head_book3s_32.S @@ -504,7 +504,9 @@ DataLoadTLBMiss: /* Convert linux-style PTE to low word of PPC-style PTE */ rlwinm r1,r0,32-9,30,30/* _PAGE_RW -> PP msb */ rlwimi r0,r0,32-1,30,30/* _PAGE_USER -> PP msb */ + rlwimi r1,r0,32-3,24,24/* _PAGE_RW -> _PAGE_DIRTY */ rlwimi r0,r0,32-1,31,31/* _PAGE_USER -> PP lsb */ + xorir1,r1,_PAGE_DIRTY /* clear dirty when not rw */ ori r1,r1,0xe04 /* clear out reserved bits */ andcr1,r0,r1/* PP = user? rw? 1: 3: 0 */ BEGIN_FTR_SECTION -- 2.33.1
[PATCH] powerpc/603: Remove outdated comment
Since commit 84de6ab0e904 ("powerpc/603: don't handle PAGE_ACCESSED
in TLB miss handlers.") page table is not updated anymore by
TLB miss handlers.
Remove the comment.
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/head_book3s_32.S | 8
1 file changed, 8 deletions(-)
diff --git a/arch/powerpc/kernel/head_book3s_32.S
b/arch/powerpc/kernel/head_book3s_32.S
index 937c79b8ad0f..6c739beb938c 100644
--- a/arch/powerpc/kernel/head_book3s_32.S
+++ b/arch/powerpc/kernel/head_book3s_32.S
@@ -501,10 +501,6 @@ DataLoadTLBMiss:
lwz r0,0(r2)/* get linux-style pte */
andc. r1,r1,r0/* check access & ~permission */
bne-DataAddressInvalid /* return if access not permitted */
- /*
-* NOTE! We are assuming this is not an SMP system, otherwise
-* we would need to update the pte atomically with lwarx/stwcx.
-*/
/* Convert linux-style PTE to low word of PPC-style PTE */
rlwinm r1,r0,32-9,30,30/* _PAGE_RW -> PP msb */
rlwimi r0,r0,32-1,30,30/* _PAGE_USER -> PP msb */
@@ -585,10 +581,6 @@ DataStoreTLBMiss:
lwz r0,0(r2)/* get linux-style pte */
andc. r1,r1,r0/* check access & ~permission */
bne-DataAddressInvalid /* return if access not permitted */
- /*
-* NOTE! We are assuming this is not an SMP system, otherwise
-* we would need to update the pte atomically with lwarx/stwcx.
-*/
/* Convert linux-style PTE to low word of PPC-style PTE */
rlwimi r0,r0,32-2,31,31/* _PAGE_USER -> PP lsb */
li r1,0xe06/* clear out reserved bits & PP msb */
--
2.33.1
[PATCH 5/5] compat: consolidate the compat_flock{,64} definition
Provide a single common definition for the compat_flock and
compat_flock64 structures using the same tricks as for the native
variants. Another extra define is added for the packing required on
x86.
Signed-off-by: Christoph Hellwig
---
arch/arm64/include/asm/compat.h | 16
arch/mips/include/asm/compat.h| 19 ++-
arch/parisc/include/asm/compat.h | 16
arch/powerpc/include/asm/compat.h | 16
arch/s390/include/asm/compat.h| 16
arch/sparc/include/asm/compat.h | 18 +-
arch/x86/include/asm/compat.h | 20 +++-
include/linux/compat.h| 31 +++
8 files changed, 37 insertions(+), 115 deletions(-)
diff --git a/arch/arm64/include/asm/compat.h b/arch/arm64/include/asm/compat.h
index 2763287654081..e0faec1984a1c 100644
--- a/arch/arm64/include/asm/compat.h
+++ b/arch/arm64/include/asm/compat.h
@@ -65,22 +65,6 @@ struct compat_stat {
compat_ulong_t __unused4[2];
};
-struct compat_flock {
- short l_type;
- short l_whence;
- compat_off_tl_start;
- compat_off_tl_len;
- compat_pid_tl_pid;
-};
-
-struct compat_flock64 {
- short l_type;
- short l_whence;
- compat_loff_t l_start;
- compat_loff_t l_len;
- compat_pid_tl_pid;
-};
-
struct compat_statfs {
int f_type;
int f_bsize;
diff --git a/arch/mips/include/asm/compat.h b/arch/mips/include/asm/compat.h
index 6a350c1f70d7e..6d6e5a451f4d9 100644
--- a/arch/mips/include/asm/compat.h
+++ b/arch/mips/include/asm/compat.h
@@ -55,23 +55,8 @@ struct compat_stat {
s32 st_pad4[14];
};
-struct compat_flock {
- short l_type;
- short l_whence;
- compat_off_tl_start;
- compat_off_tl_len;
- s32 l_sysid;
- compat_pid_tl_pid;
- s32 pad[4];
-};
-
-struct compat_flock64 {
- short l_type;
- short l_whence;
- compat_loff_t l_start;
- compat_loff_t l_len;
- compat_pid_tl_pid;
-};
+#define __ARCH_COMPAT_FLOCK_EXTRA_SYSIDs32 l_sysid;
+#define __ARCH_COMPAT_FLOCK_PADs32 pad[4];
struct compat_statfs {
int f_type;
diff --git a/arch/parisc/include/asm/compat.h b/arch/parisc/include/asm/compat.h
index c04f5a637c390..a1e4534d80509 100644
--- a/arch/parisc/include/asm/compat.h
+++ b/arch/parisc/include/asm/compat.h
@@ -53,22 +53,6 @@ struct compat_stat {
u32 st_spare4[3];
};
-struct compat_flock {
- short l_type;
- short l_whence;
- compat_off_tl_start;
- compat_off_tl_len;
- compat_pid_tl_pid;
-};
-
-struct compat_flock64 {
- short l_type;
- short l_whence;
- compat_loff_t l_start;
- compat_loff_t l_len;
- compat_pid_tl_pid;
-};
-
struct compat_statfs {
s32 f_type;
s32 f_bsize;
diff --git a/arch/powerpc/include/asm/compat.h
b/arch/powerpc/include/asm/compat.h
index 83d8f70779cbc..5ef3c7c83c343 100644
--- a/arch/powerpc/include/asm/compat.h
+++ b/arch/powerpc/include/asm/compat.h
@@ -44,22 +44,6 @@ struct compat_stat {
u32 __unused4[2];
};
-struct compat_flock {
- short l_type;
- short l_whence;
- compat_off_tl_start;
- compat_off_tl_len;
- compat_pid_tl_pid;
-};
-
-struct compat_flock64 {
- short l_type;
- short l_whence;
- compat_loff_t l_start;
- compat_loff_t l_len;
- compat_pid_tl_pid;
-};
-
struct compat_statfs {
int f_type;
int f_bsize;
diff --git a/arch/s390/include/asm/compat.h b/arch/s390/include/asm/compat.h
index 0f14b3188b1bb..07f04d37068b6 100644
--- a/arch/s390/include/asm/compat.h
+++ b/arch/s390/include/asm/compat.h
@@ -102,22 +102,6 @@ struct compat_stat {
u32 __unused5;
};
-struct compat_flock {
- short l_type;
- short l_whence;
- compat_off_tl_start;
- compat_off_tl_len;
- compat_pid_tl_pid;
-};
-
-struct compat_flock64 {
- short l_type;
- short l_whence;
- compat_loff_t l_start;
- compat_loff_t l_len;
- compat_pid_tl_pid;
-};
-
struct compat_statfs {
u32 f_type;
u32 f_bsize;
diff --git a/arch/sparc/include/asm/compat.h b/arch/sparc/include/asm/compat.h
index 108078751bb5a..d78fb44942e0f 100644
--- a/arch/sparc/include/asm/compat.h
+++ b/arch/sparc/include/asm/compat.h
@@
[PATCH 4/5] uapi: always define F_GETLK64/F_SETLK64/F_SETLKW64 in fcntl.h
The F_GETLK64/F_SETLK64/F_SETLKW64 fcntl opcodes are only implemented
for the 32-bit syscall APIs, but are also needed for compat handling
on 64-bit kernels.
Consolidate them in unistd.h instead of definining the internal compat
definitions in compat.h, which is rather errror prone (e.g. parisc
gets the values wrong currently).
Note that before this change they were never visible to userspace due
to the fact that CONFIG_64BIT is only set for kernel builds.
Signed-off-by: Christoph Hellwig
---
arch/arm64/include/asm/compat.h| 4
arch/mips/include/asm/compat.h | 4
arch/mips/include/uapi/asm/fcntl.h | 4 ++--
arch/powerpc/include/asm/compat.h | 4
arch/s390/include/asm/compat.h | 4
arch/sparc/include/asm/compat.h| 4
arch/x86/include/asm/compat.h | 4
include/uapi/asm-generic/fcntl.h | 4 ++--
tools/include/uapi/asm-generic/fcntl.h | 2 --
9 files changed, 4 insertions(+), 30 deletions(-)
diff --git a/arch/arm64/include/asm/compat.h b/arch/arm64/include/asm/compat.h
index eaa6ca062d89b..2763287654081 100644
--- a/arch/arm64/include/asm/compat.h
+++ b/arch/arm64/include/asm/compat.h
@@ -73,10 +73,6 @@ struct compat_flock {
compat_pid_tl_pid;
};
-#define F_GETLK64 12 /* using 'struct flock64' */
-#define F_SETLK64 13
-#define F_SETLKW64 14
-
struct compat_flock64 {
short l_type;
short l_whence;
diff --git a/arch/mips/include/asm/compat.h b/arch/mips/include/asm/compat.h
index bbb3bc5a42fd8..6a350c1f70d7e 100644
--- a/arch/mips/include/asm/compat.h
+++ b/arch/mips/include/asm/compat.h
@@ -65,10 +65,6 @@ struct compat_flock {
s32 pad[4];
};
-#define F_GETLK64 33
-#define F_SETLK64 34
-#define F_SETLKW64 35
-
struct compat_flock64 {
short l_type;
short l_whence;
diff --git a/arch/mips/include/uapi/asm/fcntl.h
b/arch/mips/include/uapi/asm/fcntl.h
index 9e44ac810db94..0369a38e3d4f2 100644
--- a/arch/mips/include/uapi/asm/fcntl.h
+++ b/arch/mips/include/uapi/asm/fcntl.h
@@ -44,11 +44,11 @@
#define F_SETOWN 24 /* for sockets. */
#define F_GETOWN 23 /* for sockets. */
-#ifndef __mips64
+#if __BITS_PER_LONG == 32 || defined(__KERNEL__)
#define F_GETLK64 33 /* using 'struct flock64' */
#define F_SETLK64 34
#define F_SETLKW64 35
-#endif
+#endif /* __BITS_PER_LONG == 32 || defined(__KERNEL__) */
#if _MIPS_SIM != _MIPS_SIM_ABI64
#define __ARCH_FLOCK_EXTRA_SYSID long l_sysid;
diff --git a/arch/powerpc/include/asm/compat.h
b/arch/powerpc/include/asm/compat.h
index 7afc96fb6524b..83d8f70779cbc 100644
--- a/arch/powerpc/include/asm/compat.h
+++ b/arch/powerpc/include/asm/compat.h
@@ -52,10 +52,6 @@ struct compat_flock {
compat_pid_tl_pid;
};
-#define F_GETLK64 12 /* using 'struct flock64' */
-#define F_SETLK64 13
-#define F_SETLKW64 14
-
struct compat_flock64 {
short l_type;
short l_whence;
diff --git a/arch/s390/include/asm/compat.h b/arch/s390/include/asm/compat.h
index cdc7ae72529d8..0f14b3188b1bb 100644
--- a/arch/s390/include/asm/compat.h
+++ b/arch/s390/include/asm/compat.h
@@ -110,10 +110,6 @@ struct compat_flock {
compat_pid_tl_pid;
};
-#define F_GETLK64 12
-#define F_SETLK64 13
-#define F_SETLKW64 14
-
struct compat_flock64 {
short l_type;
short l_whence;
diff --git a/arch/sparc/include/asm/compat.h b/arch/sparc/include/asm/compat.h
index bd949fcf9d63b..108078751bb5a 100644
--- a/arch/sparc/include/asm/compat.h
+++ b/arch/sparc/include/asm/compat.h
@@ -84,10 +84,6 @@ struct compat_flock {
short __unused;
};
-#define F_GETLK64 12
-#define F_SETLK64 13
-#define F_SETLKW64 14
-
struct compat_flock64 {
short l_type;
short l_whence;
diff --git a/arch/x86/include/asm/compat.h b/arch/x86/include/asm/compat.h
index 7516e4199b3c6..8d19a212f4f26 100644
--- a/arch/x86/include/asm/compat.h
+++ b/arch/x86/include/asm/compat.h
@@ -58,10 +58,6 @@ struct compat_flock {
compat_pid_tl_pid;
};
-#define F_GETLK64 12 /* using 'struct flock64' */
-#define F_SETLK64 13
-#define F_SETLKW64 14
-
/*
* IA32 uses 4 byte alignment for 64 bit quantities,
* so we need to pack this structure.
diff --git a/include/uapi/asm-generic/fcntl.h b/include/uapi/asm-generic/fcntl.h
index 98f4ff165b776..8c05d3d89ff18 100644
--- a/include/uapi/asm-generic/fcntl.h
+++ b/include/uapi/asm-generic/fcntl.h
@@ -116,13 +116,13 @@
#define F_GETSIG 11 /* for sockets. */
#endif
-#ifndef CONFIG_64BIT
+#if __BITS_PER_LONG == 32 || defined(__KERNEL__)
#ifndef F_GETLK64
#define F_GETLK64 12 /* using 'struct flock64' */
#define F_SETLK64 13
#define F_SETLKW64 14
#endif
-#endif
+#endif /*
[PATCH 2/5] uapi: simplify __ARCH_FLOCK{,64}_PAD a little
Don't bother to define the symbols empty, just don't use them. That
makes the intent a little more clear.
Signed-off-by: Christoph Hellwig
---
include/uapi/asm-generic/fcntl.h | 12
tools/include/uapi/asm-generic/fcntl.h | 12
2 files changed, 8 insertions(+), 16 deletions(-)
diff --git a/include/uapi/asm-generic/fcntl.h b/include/uapi/asm-generic/fcntl.h
index caa482e3b01af..c53897ca5d402 100644
--- a/include/uapi/asm-generic/fcntl.h
+++ b/include/uapi/asm-generic/fcntl.h
@@ -193,22 +193,16 @@ struct f_owner_ex {
#define F_LINUX_SPECIFIC_BASE 1024
#ifndef HAVE_ARCH_STRUCT_FLOCK
-#ifndef __ARCH_FLOCK_PAD
-#define __ARCH_FLOCK_PAD
-#endif
-
struct flock {
short l_type;
short l_whence;
__kernel_off_t l_start;
__kernel_off_t l_len;
__kernel_pid_t l_pid;
+#ifdef __ARCH_FLOCK_PAD
__ARCH_FLOCK_PAD
-};
#endif
-
-#ifndef __ARCH_FLOCK64_PAD
-#define __ARCH_FLOCK64_PAD
+};
#endif
struct flock64 {
@@ -217,7 +211,9 @@ struct flock64 {
__kernel_loff_t l_start;
__kernel_loff_t l_len;
__kernel_pid_t l_pid;
+#ifdef __ARCH_FLOCK64_PAD
__ARCH_FLOCK64_PAD
+#endif
};
#endif /* _ASM_GENERIC_FCNTL_H */
diff --git a/tools/include/uapi/asm-generic/fcntl.h
b/tools/include/uapi/asm-generic/fcntl.h
index 4a49d33ca4d55..82054502b9748 100644
--- a/tools/include/uapi/asm-generic/fcntl.h
+++ b/tools/include/uapi/asm-generic/fcntl.h
@@ -188,22 +188,16 @@ struct f_owner_ex {
#define F_LINUX_SPECIFIC_BASE 1024
#ifndef HAVE_ARCH_STRUCT_FLOCK
-#ifndef __ARCH_FLOCK_PAD
-#define __ARCH_FLOCK_PAD
-#endif
-
struct flock {
short l_type;
short l_whence;
__kernel_off_t l_start;
__kernel_off_t l_len;
__kernel_pid_t l_pid;
+#ifdef __ARCH_FLOCK_PAD
__ARCH_FLOCK_PAD
-};
#endif
-
-#ifndef __ARCH_FLOCK64_PAD
-#define __ARCH_FLOCK64_PAD
+};
#endif
struct flock64 {
@@ -212,7 +206,9 @@ struct flock64 {
__kernel_loff_t l_start;
__kernel_loff_t l_len;
__kernel_pid_t l_pid;
+#ifdef __ARCH_FLOCK64_PAD
__ARCH_FLOCK64_PAD
+#endif
};
#endif /* _ASM_GENERIC_FCNTL_H */
--
2.30.2
[PATCH 3/5] uapi: merge the 32-bit mips struct flock into the generic one
Add a new __ARCH_FLOCK_EXTRA_SYSID macro following the style of
__ARCH_FLOCK_PAD to avoid having a separate definition just for one
architecture.
Signed-off-by: Christoph Hellwig
---
arch/mips/include/uapi/asm/fcntl.h | 26 +++---
include/uapi/asm-generic/fcntl.h | 5 +++--
tools/include/uapi/asm-generic/fcntl.h | 5 +++--
3 files changed, 9 insertions(+), 27 deletions(-)
diff --git a/arch/mips/include/uapi/asm/fcntl.h
b/arch/mips/include/uapi/asm/fcntl.h
index 42e13dead5431..9e44ac810db94 100644
--- a/arch/mips/include/uapi/asm/fcntl.h
+++ b/arch/mips/include/uapi/asm/fcntl.h
@@ -50,30 +50,10 @@
#define F_SETLKW64 35
#endif
-/*
- * The flavours of struct flock. "struct flock" is the ABI compliant
- * variant. Finally struct flock64 is the LFS variant of struct flock.
As
- * a historic accident and inconsistence with the ABI definition it doesn't
- * contain all the same fields as struct flock.
- */
-
#if _MIPS_SIM != _MIPS_SIM_ABI64
-
-#include
-
-struct flock {
- short l_type;
- short l_whence;
- __kernel_off_t l_start;
- __kernel_off_t l_len;
- longl_sysid;
- __kernel_pid_t l_pid;
- longpad[4];
-};
-
-#define HAVE_ARCH_STRUCT_FLOCK
-
-#endif /* _MIPS_SIM == _MIPS_SIM_ABI32 */
+#define __ARCH_FLOCK_EXTRA_SYSID long l_sysid;
+#define __ARCH_FLOCK_PAD long pad[4];
+#endif
#include
diff --git a/include/uapi/asm-generic/fcntl.h b/include/uapi/asm-generic/fcntl.h
index c53897ca5d402..98f4ff165b776 100644
--- a/include/uapi/asm-generic/fcntl.h
+++ b/include/uapi/asm-generic/fcntl.h
@@ -192,18 +192,19 @@ struct f_owner_ex {
#define F_LINUX_SPECIFIC_BASE 1024
-#ifndef HAVE_ARCH_STRUCT_FLOCK
struct flock {
short l_type;
short l_whence;
__kernel_off_t l_start;
__kernel_off_t l_len;
+#ifdef __ARCH_FLOCK_EXTRA_SYSID
+ __ARCH_FLOCK_EXTRA_SYSID
+#endif
__kernel_pid_t l_pid;
#ifdef __ARCH_FLOCK_PAD
__ARCH_FLOCK_PAD
#endif
};
-#endif
struct flock64 {
short l_type;
diff --git a/tools/include/uapi/asm-generic/fcntl.h
b/tools/include/uapi/asm-generic/fcntl.h
index 82054502b9748..bf961a71802e0 100644
--- a/tools/include/uapi/asm-generic/fcntl.h
+++ b/tools/include/uapi/asm-generic/fcntl.h
@@ -187,18 +187,19 @@ struct f_owner_ex {
#define F_LINUX_SPECIFIC_BASE 1024
-#ifndef HAVE_ARCH_STRUCT_FLOCK
struct flock {
short l_type;
short l_whence;
__kernel_off_t l_start;
__kernel_off_t l_len;
+#ifdef __ARCH_FLOCK_EXTRA_SYSID
+ __ARCH_FLOCK_EXTRA_SYSID
+#endif
__kernel_pid_t l_pid;
#ifdef __ARCH_FLOCK_PAD
__ARCH_FLOCK_PAD
#endif
};
-#endif
struct flock64 {
short l_type;
--
2.30.2
[PATCH 1/5] uapi: remove the unused HAVE_ARCH_STRUCT_FLOCK64 define
Signed-off-by: Christoph Hellwig
---
include/uapi/asm-generic/fcntl.h | 2 --
tools/include/uapi/asm-generic/fcntl.h | 2 --
2 files changed, 4 deletions(-)
diff --git a/include/uapi/asm-generic/fcntl.h b/include/uapi/asm-generic/fcntl.h
index ecd0f5bdfc1d6..caa482e3b01af 100644
--- a/include/uapi/asm-generic/fcntl.h
+++ b/include/uapi/asm-generic/fcntl.h
@@ -207,7 +207,6 @@ struct flock {
};
#endif
-#ifndef HAVE_ARCH_STRUCT_FLOCK64
#ifndef __ARCH_FLOCK64_PAD
#define __ARCH_FLOCK64_PAD
#endif
@@ -220,6 +219,5 @@ struct flock64 {
__kernel_pid_t l_pid;
__ARCH_FLOCK64_PAD
};
-#endif
#endif /* _ASM_GENERIC_FCNTL_H */
diff --git a/tools/include/uapi/asm-generic/fcntl.h
b/tools/include/uapi/asm-generic/fcntl.h
index ac190958c9814..4a49d33ca4d55 100644
--- a/tools/include/uapi/asm-generic/fcntl.h
+++ b/tools/include/uapi/asm-generic/fcntl.h
@@ -202,7 +202,6 @@ struct flock {
};
#endif
-#ifndef HAVE_ARCH_STRUCT_FLOCK64
#ifndef __ARCH_FLOCK64_PAD
#define __ARCH_FLOCK64_PAD
#endif
@@ -215,6 +214,5 @@ struct flock64 {
__kernel_pid_t l_pid;
__ARCH_FLOCK64_PAD
};
-#endif
#endif /* _ASM_GENERIC_FCNTL_H */
--
2.30.2
consolidate the compat fcntl definitions v2
Hi all, currenty the compat fcnt definitions are duplicate for all compat architectures, and the native fcntl64 definitions aren't even usable from userspace due to a bogus CONFIG_64BIT ifdef. This series tries to sort out all that. Changes since v1: - only make the F*64 defines uapi visible for 32-bit architectures Diffstat: arch/arm64/include/asm/compat.h| 20 arch/mips/include/asm/compat.h | 23 ++- arch/mips/include/uapi/asm/fcntl.h | 30 +- arch/parisc/include/asm/compat.h | 16 arch/powerpc/include/asm/compat.h | 20 arch/s390/include/asm/compat.h | 20 arch/sparc/include/asm/compat.h| 22 +- arch/x86/include/asm/compat.h | 24 +++- include/linux/compat.h | 31 +++ include/uapi/asm-generic/fcntl.h | 23 +-- tools/include/uapi/asm-generic/fcntl.h | 21 +++-- 11 files changed, 58 insertions(+), 192 deletions(-)
Re: [PATCH kernel] powerpc/64: Add UADDR64 relocation support
Le 31/01/2022 à 05:14, Alexey Kardashevskiy a écrit :
> When ld detects unaligned relocations, it emits R_PPC64_UADDR64
> relocations instead of R_PPC64_RELATIVE. Currently R_PPC64_UADDR64 are
> detected by arch/powerpc/tools/relocs_check.sh and expected not to work.
> Below is a simple chunk to trigger this behaviour:
According to relocs_check.sh, this is expected to happen only with
binutils < 2.19. Today minimum binutils version is 2.23
Have you observed this problem with newer version of binutils ?
>
> \#pragma GCC push_options
> \#pragma GCC optimize ("O0")
AFAIU Linux Kernel is always built with O2
Have you observed the problem with O2 ?
> struct entry {
> const char *file;
> int line;
> } __attribute__((packed));
> static const struct entry e1 = { .file = __FILE__, .line = __LINE__ };
> static const struct entry e2 = { .file = __FILE__, .line = __LINE__ };
> ...
> prom_printf("e1=%s %lx %lx\n", e1.file, (unsigned long) e1.file, mfmsr());
> prom_printf("e2=%s %lx\n", e2.file, (unsigned long) e2.file);
> \#pragma GCC pop_options
>
>
> This adds support for UADDR64 for 64bit. This reuses __dynamic_symtab
> from the 32bit which supports more relocation types already.
>
> This adds a workaround for the number of relocations as the DT_RELACOUNT
> ELF Dynamic Array Tag does not include relocations other than
> R_PPC64_RELATIVE. This instead iterates over the entire .rela.dyn section.
>
> Signed-off-by: Alexey Kardashevskiy
> ---
>
> Tested via qemu gdb stub (the kernel is loaded at 0x40).
>
> Disasm:
>
> c1a804d0 :
> c1a804d0: b0 04 a8 01 .long 0x1a804b0
> c1a804d0: R_PPC64_RELATIVE
> *ABS*-0x3e57fb50
> c1a804d4: 00 00 00 c0 lfs f0,0(0)
> c1a804d8: fa 08 00 00 .long 0x8fa
>
> c1a804dc :
> ...
> c1a804dc: R_PPC64_UADDR64 .rodata+0x4b0
>
> Before relocation:
>
p *(unsigned long *) 0x1e804d0
> $1 = 0xc1a804b0
p *(unsigned long *) 0x1e804dc
> $2 = 0x0
>
> After:
p *(unsigned long *) 0x1e804d0
> $1 = 0x1e804b0
p *(unsigned long *) 0x1e804dc
> $2 = 0x1e804b0
> ---
> arch/powerpc/kernel/reloc_64.S | 47 +-
> arch/powerpc/kernel/vmlinux.lds.S | 3 +-
> arch/powerpc/tools/relocs_check.sh | 6
> 3 files changed, 41 insertions(+), 15 deletions(-)
>
> diff --git a/arch/powerpc/kernel/reloc_64.S b/arch/powerpc/kernel/reloc_64.S
> index 02d4719bf43a..a91175723d9d 100644
> --- a/arch/powerpc/kernel/reloc_64.S
> +++ b/arch/powerpc/kernel/reloc_64.S
> @@ -10,6 +10,7 @@
> RELA = 7
> RELACOUNT = 0x6ff9
> R_PPC64_RELATIVE = 22
> +R_PPC64_UADDR64 = 43
>
> /*
>* r3 = desired final address of kernel
> @@ -25,6 +26,8 @@ _GLOBAL(relocate)
> add r9,r9,r12 /* r9 has runtime addr of .rela.dyn section */
> ld r10,(p_st - 0b)(r12)
> add r10,r10,r12 /* r10 has runtime addr of _stext */
> + ld r13,(p_sym - 0b)(r12)
> + add r13,r13,r12 /* r13 has runtime addr of .dynsym */
>
> /*
>* Scan the dynamic section for the RELA and RELACOUNT entries.
> @@ -46,8 +49,8 @@ _GLOBAL(relocate)
> b 1b
> 4: cmpdi r7,0/* check we have both RELA and RELACOUNT */
> cmpdi cr1,r8,0
> - beq 6f
> - beq cr1,6f
> + beq 9f
> + beq cr1,9f
>
> /*
>* Work out linktime address of _stext and hence the
> @@ -60,25 +63,55 @@ _GLOBAL(relocate)
> subfr10,r7,r10
> subfr3,r10,r3 /* final_offset */
>
> + /*
> + * FIXME
> + * Here r8 is a number of relocations in .rela.dyn.
> + * When ld issues UADDR64 relocations, they end up at the end
> + * of the .rela.dyn section. However RELACOUNT does not include
> + * them so the loop below is going to finish after the last
> + * R_PPC64_RELATIVE as they normally go first.
> + * Work out the size of .rela.dyn at compile time.
> + */
> + ld r8,(p_rela_end - 0b)(r12)
> + ld r18,(p_rela - 0b)(r12)
> + sub r8,r8,r18
> + li r18,24 /* 24 == sizeof(elf64_rela) */
> + divdr8,r8,r18
> +
> /*
>* Run through the list of relocations and process the
> - * R_PPC64_RELATIVE ones.
> + * R_PPC64_RELATIVE and R_PPC64_UADDR64 ones.
>*/
> mtctr r8
> -5: ld r0,8(9) /* ELF64_R_TYPE(reloc->r_info) */
> +5: lwa r0,8(r9)/* ELF64_R_TYPE(reloc->r_info) */
> cmpdi r0,R_PPC64_RELATIVE
> bne 6f
> ld r6,0(r9)/* reloc->r_offset */
> ld r0,16(r9) /* reloc->r_addend */
> - add r0,r0,r3
> + b 7f
> +
> +6: cmpdi r0,R_PPC64_UADDR64
> + bne 8f
> + ld r6,0(r9)
> + ld r0,16(r9)
> + lwa r14,12(r9) /*
Re: [PATCH RFC v1] drivers/base/node: consolidate node device subsystem initialization in node_dev_init()
On Fri, Jan 28, 2022 at 04:15:40PM +0100, David Hildenbrand wrote: > ... and call node_dev_init() after memory_dev_init() from driver_init(), > so before any of the existing arch/subsys calls. All online nodes should > be known at that point. > > This is in line with memory_dev_init(), which initializes the memory > device subsystem and creates all memory block devices. > > Similar to memory_dev_init(), panic() if anything goes wrong, we don't > want to continue with such basic initialization errors. > > The important part is that node_dev_init() gets called after > memory_dev_init() and after cpu_dev_init(), but before any of the > relevant archs call register_cpu() to register the new cpu device under > the node device. The latter should be the case for the current users > of topology_init(). So, before this change we had something like this: do_basic_setup driver_init memory_dev_init do_init_calls ... topology_init register_nodes/register_one_node And after the patch all happens in driver_init() driver_init memory_dev_init node_dev_init I guess this is fine as we do not have any ordering problems (aka: none of the functions we used to call before expect the nodes not to be there for some weird reason). So, no functional change, right? This certainly looks like an improvment. -- Oscar Salvador SUSE Labs
Re: microwatt booting linux-5.7 under verilator
On January 31, 2022 3:31:41 AM UTC, Nicholas Piggin wrote: >Hi Luke, > >Interesting to read about the project, thanks for the post. no problem. it's been i think 18 years since i last did linux kernel work. >> i also had to fix a couple of things in the linux kernel source >> https://git.kernel.org/pub/scm/linux/kernel/git/joel/microwatt.git > >I think these have mostly (all?) been upstreamed now. i believe so, although last i checked (6 months?) there was some of dts still to do. instructions online all tend to refer to joel or benh's tree(s) >> this led me to add support for CONFIG_KERNEL_UNCOMPRESSED >> and cut that time entirely, hence why you can see this in the console >log: >> >> 0x5b0e10 bytes of uncompressed data copied > >Interesting, it looks like your HAVE_KERNEL_UNCOMPRESSED support >patch is pretty trivial. yeah i was really surprised, it was all there > We should be able to upstream it pretty >easily I think? don't see why not. the next interesting thing which would save another hour when emulating HDL at this astoundingly-slow speed of sub-1000 instructions per second would be in-place execution: no memcpy, just jump. i seem to recall this (inplace execution) being a standard option back in 2003 when i was doing xda-developers wince smartphone reverse-emgineering, although with it being 19 years ago i could be wrong other areas are the memset before VM is set up, followed by memset *again* on.individual pages once created. those are an hour each another hour is spent on early device tree flat walking. one very big one (90+ mins) is the sysfs binary tree walk. i'm sure even just saving the last node in a 1-entry cache would improve time there, or, better, a 4-entry cache (one per level) although it sounds weird talking in a timeframe that is literally 100,000 times slower than what anyone else is used to, if improved it results in dramatic reduction in boot times for embedded IoT e.g BMC systems. >> however in the interim, the attached patch suffices by manually >> altering the clock in microwatt.dts to match that of the SYSCON >> parameter. > >There is a dt_fixup_clock() that's used by a few platforms. Can we >read that parameter say in linux/arch/powerpc/boot/microwatt.c >platform_init() and fix it up there? > >How do you even read the SYSCON parameter for frequency? SYSCON is just a term for a memory-mapped wishbone ROM which contains a crude easily-decoded binary form of devicetree. when you read 0xc0001000 (say) its contents tell you the clock speed. at 0xc0001008 is the number of UARTs. 0xc0001010 contains the UART0 speed or well you can see the real contents syscon.vhdl it is _real_ basic but contains everything that a cold-start BIOS needs to know, such as "do i even have DRAM, do i have an SPI Flash i can read a second stage bootloader from" etc etc https://github.com/antonblanchard/microwatt/blob/master/syscon.vhdl Paul said it was always planned to do reading of these params, the entries in devicetree are a temporary hack. l.
[PATCH kernel] powerpc/64: Add UADDR64 relocation support
When ld detects unaligned relocations, it emits R_PPC64_UADDR64
relocations instead of R_PPC64_RELATIVE. Currently R_PPC64_UADDR64 are
detected by arch/powerpc/tools/relocs_check.sh and expected not to work.
Below is a simple chunk to trigger this behaviour:
\#pragma GCC push_options
\#pragma GCC optimize ("O0")
struct entry {
const char *file;
int line;
} __attribute__((packed));
static const struct entry e1 = { .file = __FILE__, .line = __LINE__ };
static const struct entry e2 = { .file = __FILE__, .line = __LINE__ };
...
prom_printf("e1=%s %lx %lx\n", e1.file, (unsigned long) e1.file, mfmsr());
prom_printf("e2=%s %lx\n", e2.file, (unsigned long) e2.file);
\#pragma GCC pop_options
This adds support for UADDR64 for 64bit. This reuses __dynamic_symtab
from the 32bit which supports more relocation types already.
This adds a workaround for the number of relocations as the DT_RELACOUNT
ELF Dynamic Array Tag does not include relocations other than
R_PPC64_RELATIVE. This instead iterates over the entire .rela.dyn section.
Signed-off-by: Alexey Kardashevskiy
---
Tested via qemu gdb stub (the kernel is loaded at 0x40).
Disasm:
c1a804d0 :
c1a804d0: b0 04 a8 01 .long 0x1a804b0
c1a804d0: R_PPC64_RELATIVE
*ABS*-0x3e57fb50
c1a804d4: 00 00 00 c0 lfs f0,0(0)
c1a804d8: fa 08 00 00 .long 0x8fa
c1a804dc :
...
c1a804dc: R_PPC64_UADDR64 .rodata+0x4b0
Before relocation:
>>> p *(unsigned long *) 0x1e804d0
$1 = 0xc1a804b0
>>> p *(unsigned long *) 0x1e804dc
$2 = 0x0
After:
>>> p *(unsigned long *) 0x1e804d0
$1 = 0x1e804b0
>>> p *(unsigned long *) 0x1e804dc
$2 = 0x1e804b0
---
arch/powerpc/kernel/reloc_64.S | 47 +-
arch/powerpc/kernel/vmlinux.lds.S | 3 +-
arch/powerpc/tools/relocs_check.sh | 6
3 files changed, 41 insertions(+), 15 deletions(-)
diff --git a/arch/powerpc/kernel/reloc_64.S b/arch/powerpc/kernel/reloc_64.S
index 02d4719bf43a..a91175723d9d 100644
--- a/arch/powerpc/kernel/reloc_64.S
+++ b/arch/powerpc/kernel/reloc_64.S
@@ -10,6 +10,7 @@
RELA = 7
RELACOUNT = 0x6ff9
R_PPC64_RELATIVE = 22
+R_PPC64_UADDR64 = 43
/*
* r3 = desired final address of kernel
@@ -25,6 +26,8 @@ _GLOBAL(relocate)
add r9,r9,r12 /* r9 has runtime addr of .rela.dyn section */
ld r10,(p_st - 0b)(r12)
add r10,r10,r12 /* r10 has runtime addr of _stext */
+ ld r13,(p_sym - 0b)(r12)
+ add r13,r13,r12 /* r13 has runtime addr of .dynsym */
/*
* Scan the dynamic section for the RELA and RELACOUNT entries.
@@ -46,8 +49,8 @@ _GLOBAL(relocate)
b 1b
4: cmpdi r7,0/* check we have both RELA and RELACOUNT */
cmpdi cr1,r8,0
- beq 6f
- beq cr1,6f
+ beq 9f
+ beq cr1,9f
/*
* Work out linktime address of _stext and hence the
@@ -60,25 +63,55 @@ _GLOBAL(relocate)
subfr10,r7,r10
subfr3,r10,r3 /* final_offset */
+ /*
+* FIXME
+* Here r8 is a number of relocations in .rela.dyn.
+* When ld issues UADDR64 relocations, they end up at the end
+* of the .rela.dyn section. However RELACOUNT does not include
+* them so the loop below is going to finish after the last
+* R_PPC64_RELATIVE as they normally go first.
+* Work out the size of .rela.dyn at compile time.
+*/
+ ld r8,(p_rela_end - 0b)(r12)
+ ld r18,(p_rela - 0b)(r12)
+ sub r8,r8,r18
+ li r18,24 /* 24 == sizeof(elf64_rela) */
+ divdr8,r8,r18
+
/*
* Run through the list of relocations and process the
-* R_PPC64_RELATIVE ones.
+* R_PPC64_RELATIVE and R_PPC64_UADDR64 ones.
*/
mtctr r8
-5: ld r0,8(9) /* ELF64_R_TYPE(reloc->r_info) */
+5: lwa r0,8(r9)/* ELF64_R_TYPE(reloc->r_info) */
cmpdi r0,R_PPC64_RELATIVE
bne 6f
ld r6,0(r9)/* reloc->r_offset */
ld r0,16(r9) /* reloc->r_addend */
- add r0,r0,r3
+ b 7f
+
+6: cmpdi r0,R_PPC64_UADDR64
+ bne 8f
+ ld r6,0(r9)
+ ld r0,16(r9)
+ lwa r14,12(r9) /* ELF64_R_SYM(reloc->r_info) */
+ mulli r14,r14,24 /* 24 == sizeof(elf64_sym) */
+ add r14,r14,r13 /* elf64_sym[ELF64_R_SYM] */
+ ld r14,8(r14)
+ add r0,r0,r14
+
+7: add r0,r0,r3
stdxr0,r7,r6
- addir9,r9,24
+
+8: addir9,r9,24
bdnz5b
-6: blr
+9: blr
.balign 8
p_dyn: .8byte __dynamic_start - 0b
p_rela:.8byte __rela_dyn_start - 0b
+p_rela_end:.8byte __rela_dyn_end - 0b
+p_sym: .8byte
Re: microwatt booting linux-5.7 under verilator
Hi Luke, Interesting to read about the project, thanks for the post. Excerpts from Luke Kenneth Casson Leighton's message of January 3, 2022 10:45 am: > i am pleased to be able to announce the successful booting of microwatt-5.7 > linux buildroot... under a veriilator simulation of the microwatt VHDL. > from a hardware development and research perspective this is highly > significant because unlike the FPGA boot which was previously reported, > https://shenki.github.io/boot-linux-on-microwatt/ > full memory read/write snooping and full Signal tracing (gtkwave) is possible. > > https://ftp.libre-soc.org/microwatt-linux-5.7-verilator-boot-buildroot.txt > > the branch of microwatt HDL which is being used is here > https://git.libre-soc.org/?p=microwatt.git;a=shortlog;h=refs/heads/verilator_trace > > some minor strategic changes to microwatt HDL were required, including > adding a new SYSCON parameter to specify a BRAM chain-boot address, > and also it was necessary to turn sdram_init into a stand-alone "mini-BIOS" > which performed the role of early-initialising the 16550 uart followed by > chain-loading to the BRAM chain-boot memory location, at which the linux > 5.7 dtbImage.microwatt had been loaded (0x60). > > microwatt-verilator.cpp itself needed some changes to add support for > emulation in c++ of 512 mbyte of "Block" RAM. the interface for BRAM > (aka SRAM) was far simpler than attempting to emulate DRAM, and > also meant that much of the mini-BIOS could be entirely cut. > > i also had to further modify microwatt-verilator.cpp to allow it to load > from files directly into memory, at run-time. this means it is possible > to execute hello_world.bin, zephyr.bin, micropython.bin, dtbImage-microwatt > all without recompiling the verilator binary. > > (not that you want to try compiling a 6 MB binary into VHDL like i did: > it resulted in the creation of a 512 MB verilog file which, at 60 GB resident > RAM by verilator attempting to compile that to c++, i decided that mayyybe > doing that at runtime was a better approach?) > > i also had to fix a couple of things in the linux kernel source > https://git.kernel.org/pub/scm/linux/kernel/git/joel/microwatt.git I think these have mostly (all?) been upstreamed now. > first attempts to boot a compressed image were quite hilarious: a > quick back-of-the-envelope calculation by examining the rate at which > LD/STs were being generated showed that the GZIP decompression > would complete maybe some time in about 1 hour of real-world time. > this led me to add support for CONFIG_KERNEL_UNCOMPRESSED > and cut that time entirely, hence why you can see this in the console log: > > 0x5b0e10 bytes of uncompressed data copied Interesting, it looks like your HAVE_KERNEL_UNCOMPRESSED support patch is pretty trivial. We should be able to upstream it pretty easily I think? > secondly, the microwatt Makefile assumes that verilator clock rate > runs at 50 mhz, where the microwatt.dts file says 100 mhz for both > the UART clock as well as the system clock. it would be really nice > to have microwatt-linux read the SYSCON parameter for the > clock rate, and for that to be dynamically inserted into the dtb. > however in the interim, the attached patch suffices by manually > altering the clock in microwatt.dts to match that of the SYSCON > parameter. There is a dt_fixup_clock() that's used by a few platforms. Can we read that parameter say in linux/arch/powerpc/boot/microwatt.c platform_init() and fix it up there? How do you even read the SYSCON parameter for frequency? Thanks, Nick
[Bug 215389] pagealloc: memory corruption at building glibc-2.33 and running its' testsuite
https://bugzilla.kernel.org/show_bug.cgi?id=215389 --- Comment #9 from Erhard F. (erhar...@mailbox.org) --- Created attachment 300354 --> https://bugzilla.kernel.org/attachment.cgi?id=300354=edit dmesg (5.10-rc2 with ADB_PMU disabled, PowerMac G4 DP) Took a little time but I double checked the results (one time using distcc '-j8 -l2', one time native '-j3') to be sure: ADB_PMU disabled, VMAP_STACK disabled ... "neverending build" ADB_PMU enabled, VMAP_STACK disabled ... works ok ADB_PMU disabled, VMAP_STACK enabled ... "neverending build" ADB_PMU enabled, VMAP_STACK enabled ... memory corruption Version used was git db972a3787d12b1ce9ba7a31ec376d8a79e04c47, which is the one before a last 'git bisect bad' ends the git bisect. The "neverending builds" happen when I run this kernel with ADB_PMU disabled. The G4 runs for several hours building (?) without reaching the glibc test stage. With ADB_PMU enabled I get a pass or memory corruption much earlier. Also without ADB_PMU I get a kernel panic when rebooting or shutting down the G4. Also the G4 does not reboot/poweroff in this case, I need to switch it off manually. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[PATCH] powerpc/ptdump: Fix sparse warning in hashpagetable.c
arch/powerpc/mm/ptdump/hashpagetable.c:264:29: warning: restricted __be64
degrades to integer
arch/powerpc/mm/ptdump/hashpagetable.c:265:49: warning: restricted __be64
degrades to integer
arch/powerpc/mm/ptdump/hashpagetable.c:267:36: warning: incorrect type in
assignment (different base types)
arch/powerpc/mm/ptdump/hashpagetable.c:267:36:expected unsigned long long
[usertype]
arch/powerpc/mm/ptdump/hashpagetable.c:267:36:got restricted __be64
[usertype] v
arch/powerpc/mm/ptdump/hashpagetable.c:268:36: warning: incorrect type in
assignment (different base types)
arch/powerpc/mm/ptdump/hashpagetable.c:268:36:expected unsigned long long
[usertype]
arch/powerpc/mm/ptdump/hashpagetable.c:268:36:got restricted __be64
[usertype] r
struct hash_pte fields have type __be64. Convert them to
regular long before using them.
Reported-by: kernel test robot
Signed-off-by: Christophe Leroy
---
arch/powerpc/mm/ptdump/hashpagetable.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/mm/ptdump/hashpagetable.c
b/arch/powerpc/mm/ptdump/hashpagetable.c
index c7f824d294b2..bf60ab1bedb9 100644
--- a/arch/powerpc/mm/ptdump/hashpagetable.c
+++ b/arch/powerpc/mm/ptdump/hashpagetable.c
@@ -261,11 +261,11 @@ static int pseries_find(unsigned long ea, int psize, bool
primary, u64 *v, u64 *
if (lpar_rc)
continue;
for (j = 0; j < 4; j++) {
- if (HPTE_V_COMPARE(ptes[j].v, want_v) &&
- (ptes[j].v & HPTE_V_VALID)) {
+ if (HPTE_V_COMPARE(be64_to_cpu(ptes[j].v), want_v) &&
+ (be64_to_cpu(ptes[j].v) & HPTE_V_VALID)) {
/* HPTE matches */
- *v = ptes[j].v;
- *r = ptes[j].r;
+ *v = be64_to_cpu(ptes[j].v);
+ *r = be64_to_cpu(ptes[j].r);
return 0;
}
}
--
2.33.1
Re: [patch V3 28/35] PCI/MSI: Simplify pci_irq_get_affinity()
On Fri, Dec 10, 2021 at 11:19:26PM +0100, Thomas Gleixner wrote: > From: Thomas Gleixner > > Replace open coded MSI descriptor chasing and use the proper accessor > functions instead. > > Signed-off-by: Thomas Gleixner > Reviewed-by: Greg Kroah-Hartman > Reviewed-by: Jason Gunthorpe This patch results in the following runtime warning when booting x86 (32 bit) nosmp images from NVME in qemu. [ 14.825482] nvme nvme0: 1/0/0 default/read/poll queues ILLOPC: ca7c6d10: 0f 0b [ 14.826188] [ cut here ] [ 14.826307] WARNING: CPU: 0 PID: 7 at drivers/pci/msi/msi.c:1114 pci_irq_get_affinity+0x80/0x90 [ 14.826455] Modules linked in: [ 14.826640] CPU: 0 PID: 7 Comm: kworker/u2:0 Not tainted 5.17.0-rc1-00419-g1d2d8baaf053 #1 [ 14.826797] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 [ 14.827132] Workqueue: nvme-reset-wq nvme_reset_work [ 14.827336] EIP: pci_irq_get_affinity+0x80/0x90 [ 14.827452] Code: e8 d5 30 af ff 85 c0 75 bd 90 0f 0b 31 c0 5b 5e 5d c3 8d b4 26 00 00 00 00 90 5b b8 24 32 7e cb 5e 5d c3 8d b4 26 00 00 00 00 <0f> 0b eb e0 8d b4 26 00 00 00 00 8d 74 26 00 90 55 89 e5 57 56 53 [ 14.827717] EAX: EBX: c18ba000 ECX: EDX: c297c210 [ 14.827816] ESI: 0001 EDI: c18ba000 EBP: c1247e24 ESP: c1247e1c [ 14.827924] DS: 007b ES: 007b FS: GS: SS: 0068 EFLAGS: 0246 [ 14.828110] CR0: 80050033 CR2: ffda9000 CR3: 0b8ad000 CR4: 06d0 [ 14.828268] Call Trace: [ 14.828554] blk_mq_pci_map_queues+0x26/0x70 [ 14.828710] nvme_pci_map_queues+0x75/0xc0 [ 14.828808] blk_mq_update_queue_map+0x86/0xa0 [ 14.828891] blk_mq_alloc_tag_set+0xf3/0x390 [ 14.828965] ? nvme_wait_freeze+0x3d/0x50 [ 14.829137] nvme_reset_work+0xd02/0x1120 [ 14.829269] ? lock_acquire+0xc3/0x290 [ 14.829435] process_one_work+0x1ed/0x490 [ 14.829569] worker_thread+0x15e/0x3c0 [ 14.829665] kthread+0xd3/0x100 [ 14.829729] ? process_one_work+0x490/0x490 [ 14.829799] ? kthread_complete_and_exit+0x20/0x20 [ 14.829890] ret_from_fork+0x1c/0x28 Bisect results below. #regzbot introduced: f48235900182d6 Guenter --- # bad: [e783362eb54cd99b2cac8b3a9aeac942e6f6ac07] Linux 5.17-rc1 # good: [df0cc57e057f18e44dac8e6c18aba47ab53202f9] Linux 5.16 git bisect start 'v5.17-rc1' 'v5.16' # good: [fef8dfaea9d6c444b6c2174b3a2b0fca4d226c5e] Merge tag 'regulator-v5.17' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator git bisect good fef8dfaea9d6c444b6c2174b3a2b0fca4d226c5e # bad: [3ceff4ea07410763d5d4cccd60349bf7691e7e61] Merge tag 'sound-5.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound git bisect bad 3ceff4ea07410763d5d4cccd60349bf7691e7e61 # good: [57ea81971b7296b42fc77424af44c5915d3d4ae2] Merge tag 'usb-5.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb git bisect good 57ea81971b7296b42fc77424af44c5915d3d4ae2 # bad: [feb7a43de5ef625ad74097d8fd3481d5dbc06a59] Merge tag 'irq-msi-2022-01-13' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip git bisect bad feb7a43de5ef625ad74097d8fd3481d5dbc06a59 # good: [ce990f1de0bc6ff3de43d385e0985efa980fba24] Merge tag 'for-linus-5.17-rc1-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip git bisect good ce990f1de0bc6ff3de43d385e0985efa980fba24 # good: [4afd2a9355a9deb16ea42b896820dacf49843a8f] Merge branches 'clk-ingenic' and 'clk-mediatek' into clk-next git bisect good 4afd2a9355a9deb16ea42b896820dacf49843a8f # good: [455e73a07f6e288b0061dfcf4fcf54fa9fe06458] Merge tag 'clk-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux git bisect good 455e73a07f6e288b0061dfcf4fcf54fa9fe06458 # bad: [f2948df5f87a722591499da60ab91c611422f755] x86/pci/xen: Use msi_for_each_desc() git bisect bad f2948df5f87a722591499da60ab91c611422f755 # good: [93296cd1325d1d9afede60202d8833011c9001f2] PCI/MSI: Allocate MSI device data on first use git bisect good 93296cd1325d1d9afede60202d8833011c9001f2 # good: [82ff8e6b78fc4587a4255301f0a283506daf11b6] PCI/MSI: Use msi_get_virq() in pci_get_vector() git bisect good 82ff8e6b78fc4587a4255301f0a283506daf11b6 # bad: [125282cd4f33ecd53a24ae4807409da0e5e90fd4] genirq/msi: Move descriptor list to struct msi_device_data git bisect bad 125282cd4f33ecd53a24ae4807409da0e5e90fd4 # bad: [065afdc9c521f05c53f226dabe5dda2d30294d65] iommu/arm-smmu-v3: Use msi_get_virq() git bisect bad 065afdc9c521f05c53f226dabe5dda2d30294d65 # bad: [f6632bb2c1454b857adcd131320379ec16fd8666] dmaengine: mv_xor_v2: Get rid of msi_desc abuse git bisect bad f6632bb2c1454b857adcd131320379ec16fd8666 # bad: [f48235900182d64537c6e8f8dc0932b57a1a0638] PCI/MSI: Simplify pci_irq_get_affinity() git bisect bad f48235900182d64537c6e8f8dc0932b57a1a0638 # first bad commit: [f48235900182d64537c6e8f8dc0932b57a1a0638] PCI/MSI: Simplify pci_irq_get_affinity()
Re: [PATCH V4 08/17] riscv: compat: syscall: Add compat_sys_call_table implementation
On Sun, Jan 30, 2022 at 7:32 PM Arnd Bergmann wrote: > > On Sun, Jan 30, 2022 at 6:54 AM Guo Ren wrote: > > On Sun, Jan 30, 2022 at 6:41 AM Arnd Bergmann wrote: > > > > > > I would make these endian-specific, and reverse them on big-endian > > > architectures. That way it > > > should be possible to share them across all compat architectures > > > without needing the override > > > option. > > I hope it could be another patch. Because it's not clear to > > _LITTLE_ENDIAN definition in archs. > > > > eg: Names could be __ORDER_LITTLE_ENDIAN__ CPU_LITTLE_ENDIAN > > SYS_SUPPORTS_LITTLE_ENDIAN __LITTLE_ENDIAN > > > > riscv is little-endian, but no any LITTLE_ENDIAN definition. > > > > So let's keep them in the patch, first, Thx > > The correct way to do it is to check for CONFIG_CPU_BIG_ENDIAN, > which works on all architectures. Since nothing else selects the > __ARCH_WANT_COMPAT_* symbols, there is also no risk for > regressions, so just use this and leave the #ifndef compat_arg_u64 > check in place. Okay, got it. > > Arnd -- Best Regards Guo Ren ML: https://lore.kernel.org/linux-csky/
Re: [PATCH] [Rebased for 4.19 and 4.14] powerpc/32: Fix boot failure with GCC latent entropy plugin
On Sun, Jan 30, 2022 at 09:45:10AM +, Christophe Leroy wrote: > This is backport for 4.19 and 4.14 > > (cherry picked from commit bba496656a73fc1d1330b49c7f82843836e9feb1) > > Boot fails with GCC latent entropy plugin enabled. All now queued up, thanks, greg k-h
Re: [PATCH] [Modified for 5.16 and 5.15] powerpc/32s: Fix kasan_init_region() for KASAN
On Sat, Jan 29, 2022 at 05:26:10PM +, Christophe Leroy wrote:
> This is a backport for 5.16 and 5.15.
>
> To apply, it also requires commit 37eb7ca91b69 ("powerpc/32s: Allocate
> one 256k IBAT instead of two consecutives 128k IBATs")
Thanks for these, now queued up.
greg k-h
Re: [PATCH V4 06/17] riscv: compat: Add basic compat date type implementation
On Sun, Jan 30, 2022 at 6:47 AM Guo Ren wrote: > > On Sun, Jan 30, 2022 at 5:56 AM Arnd Bergmann wrote: > > > > On Sat, Jan 29, 2022 at 1:17 PM wrote: > > > + > > > +#define COMPAT_RLIM_INFINITY 0x7fff > > > > > > +#define F_GETLK64 12 > > > +#define F_SETLK64 13 > > > +#define F_SETLKW64 14 > > > > These now come from the generic definitions I think. The flock definitions > > are just the normal ones, > Yes, it could be removed after Christoph Hellwig's patch merged. Rgiht, I keep forgetting that this is a separate series, so this is fine. > > and AFAICT the RLIM_INIFINITY definition here > > is actually wrong and should be the default 0xu to match the > > native (~0UL) definition. > Yes, native rv32 used ~0UL, although its task_size is only 2.4GB. The rlimit range has very little to do with the virtual memory address limits, it is used for a number of other things that are typically more limited in practice. > I would remove #define COMPAT_RLIM_INFINITY 0x7fff Ok. Arnd
Re: [PATCH V4 08/17] riscv: compat: syscall: Add compat_sys_call_table implementation
On Sun, Jan 30, 2022 at 6:54 AM Guo Ren wrote: > On Sun, Jan 30, 2022 at 6:41 AM Arnd Bergmann wrote: > > > > I would make these endian-specific, and reverse them on big-endian > > architectures. That way it > > should be possible to share them across all compat architectures > > without needing the override > > option. > I hope it could be another patch. Because it's not clear to > _LITTLE_ENDIAN definition in archs. > > eg: Names could be __ORDER_LITTLE_ENDIAN__ CPU_LITTLE_ENDIAN > SYS_SUPPORTS_LITTLE_ENDIAN __LITTLE_ENDIAN > > riscv is little-endian, but no any LITTLE_ENDIAN definition. > > So let's keep them in the patch, first, Thx The correct way to do it is to check for CONFIG_CPU_BIG_ENDIAN, which works on all architectures. Since nothing else selects the __ARCH_WANT_COMPAT_* symbols, there is also no risk for regressions, so just use this and leave the #ifndef compat_arg_u64 check in place. Arnd
[PATCH v4] PCI hotplug: rpaphp: Error out on busy status from get-sensor-state
When certain PHB HW failure causes phyp to recover PHB, it marks the PE
state as temporarily unavailable until recovery is complete. This also
triggers an EEH handler in Linux which needs to notify drivers, and perform
recovery. But before notifying the driver about the pci error it uses
get_adapter_state()->get-sesnor-state() operation of the hotplug_slot to
determine if the slot contains a device or not. if the slot is empty, the
recovery is skipped entirely.
However on certain PHB failures, the rtas call get-sesnor-state() returns
extended busy error (9902) until PHB is recovered by phyp. Once PHB is
recovered, the get-sensor-state() returns success with correct presence
status. The rtas call interface rtas_get_sensor() loops over the rtas call
on extended delay return code (9902) until the return value is either
success (0) or error (-1). This causes the EEH handler to get stuck for ~6
seconds before it could notify that the pci error has been detected and
stop any active operations. Hence with running I/O traffic, during this 6
seconds, the network driver continues its operation and hits a timeout
(netdev watchdog). On timeouts, network driver go into ffdc capture mode
and reset path assuming the PCI device is in fatal condition. This
sometimes causes EEH recovery to fail. This impacts the ssh connection and
leads to the system being inaccessible.
[52732.244731] DEBUG: ibm_read_slot_reset_state2()
[52732.244762] DEBUG: ret = 0, rets[0]=5, rets[1]=1, rets[2]=4000, rets[3]=>
[52732.244798] DEBUG: in eeh_slot_presence_check
[52732.244804] DEBUG: error state check
[52732.244807] DEBUG: Is slot hotpluggable
[52732.244810] DEBUG: hotpluggable ops ?
[52732.244953] DEBUG: Calling ops->get_adapter_status
[52732.244958] DEBUG: calling rpaphp_get_sensor_state
[52736.564262] [ cut here ]
[52736.564299] NETDEV WATCHDOG: enP64p1s0f3 (tg3): transmit queue 0 timed o>
[52736.564324] WARNING: CPU: 1442 PID: 0 at net/sched/sch_generic.c:478 dev>
[...]
[52736.564505] NIP [c0c32368] dev_watchdog+0x438/0x440
[52736.564513] LR [c0c32364] dev_watchdog+0x434/0x440
To avoid this issue, fix the pci hotplug driver (rpaphp) to return an error
if the slot presence state can not be detected immediately while pe is in
EEH recovery state. Current implementation uses rtas_get_sensor() API which
blocks the slot check state until rtas call returns success. Change
rpaphp_get_sensor_state() to invoke rtas_call(get-sensor-state) directly
only if the respective pe is in EEH recovery state, and take actions based
on rtas return status.
In normal cases (non-EEH case) rpaphp_get_sensor_state() will continue to
invoke rtas_get_sensor() as it was earlier with no change in existing
behavior.
Signed-off-by: Mahesh Salgaonkar
---
Change in V4:
- Error out on sensor busy only if pe is going through EEH recovery instead
of always error out.
Change in V3:
- Invoke rtas_call(get-sensor-state) directly from
rpaphp_get_sensor_state() directly and do special handling.
- See v2 at
https://lists.ozlabs.org/pipermail/linuxppc-dev/2021-November/237336.html
Change in V2:
- Alternate approach to fix the EEH issue instead of delaying slot presence
check proposed at
https://lists.ozlabs.org/pipermail/linuxppc-dev/2021-November/236956.html
Also refer:
https://lists.ozlabs.org/pipermail/linuxppc-dev/2021-November/237027.html
---
drivers/pci/hotplug/rpaphp_pci.c | 100 +-
1 file changed, 97 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/hotplug/rpaphp_pci.c b/drivers/pci/hotplug/rpaphp_pci.c
index c380bdacd1466..d93f04b503c04 100644
--- a/drivers/pci/hotplug/rpaphp_pci.c
+++ b/drivers/pci/hotplug/rpaphp_pci.c
@@ -18,12 +18,107 @@
#include "../pci.h"/* for pci_add_new_bus */
#include "rpaphp.h"
+/*
+ * RTAS call get-sensor-state(DR_ENTITY_SENSE) return values as per PAPR:
+ *-1: Hardware Error
+ *-2: RTAS_BUSY
+ *-3: Invalid sensor. RTAS Parameter Error.
+ * -9000: Need DR entity to be powered up and unisolated before RTAS call
+ * -9001: Need DR entity to be powered up, but not unisolated, before RTAS call
+ * -9002: DR entity unusable
+ * 990x: Extended delay - where x is a number in the range of 0-5
+ */
+#define RTAS_HARDWARE_ERROR-1
+#define RTAS_INVALID_SENSOR-3
+#define SLOT_UNISOLATED-9000
+#define SLOT_NOT_UNISOLATED-9001
+#define SLOT_NOT_USABLE-9002
+
+static int rtas_to_errno(int rtas_rc)
+{
+ int rc;
+
+ switch (rtas_rc) {
+ case RTAS_HARDWARE_ERROR:
+ rc = -EIO;
+ break;
+ case RTAS_INVALID_SENSOR:
+ rc = -EINVAL;
+ break;
+ case SLOT_UNISOLATED:
+ case SLOT_NOT_UNISOLATED:
+ rc = -EFAULT;
+ break;
+ case SLOT_NOT_USABLE:
+ rc = -ENODEV;
+ break;
+ case RTAS_BUSY:
+ case
[PATCH] powerpc/32s: Make pte_update() non atomic on 603 core
On 603 core, TLB miss handler don't do any change to the
page tables so pte_update() doesn't need to be atomic.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/book3s/32/pgtable.h | 37
1 file changed, 22 insertions(+), 15 deletions(-)
diff --git a/arch/powerpc/include/asm/book3s/32/pgtable.h
b/arch/powerpc/include/asm/book3s/32/pgtable.h
index f8b94f78403f..772e00dc4ef1 100644
--- a/arch/powerpc/include/asm/book3s/32/pgtable.h
+++ b/arch/powerpc/include/asm/book3s/32/pgtable.h
@@ -298,28 +298,35 @@ static inline pte_basic_t pte_update(struct mm_struct
*mm, unsigned long addr, p
unsigned long clr, unsigned long set, int
huge)
{
pte_basic_t old;
- unsigned long tmp;
- __asm__ __volatile__(
+ if (mmu_has_feature(MMU_FTR_HPTE_TABLE)) {
+ unsigned long tmp;
+
+ asm volatile(
#ifndef CONFIG_PTE_64BIT
-"1:lwarx %0, 0, %3\n"
-" andc%1, %0, %4\n"
+ "1: lwarx %0, 0, %3\n"
+ " andc%1, %0, %4\n"
#else
-"1:lwarx %L0, 0, %3\n"
-" lwz %0, -4(%3)\n"
-" andc%1, %L0, %4\n"
+ "1: lwarx %L0, 0, %3\n"
+ " lwz %0, -4(%3)\n"
+ " andc%1, %L0, %4\n"
#endif
-" or %1, %1, %5\n"
-" stwcx. %1, 0, %3\n"
-" bne-1b"
- : "=" (old), "=" (tmp), "=m" (*p)
+ " or %1, %1, %5\n"
+ " stwcx. %1, 0, %3\n"
+ " bne-1b"
+ : "=" (old), "=" (tmp), "=m" (*p)
#ifndef CONFIG_PTE_64BIT
- : "r" (p),
+ : "r" (p),
#else
- : "b" ((unsigned long)(p) + 4),
+ : "b" ((unsigned long)(p) + 4),
#endif
- "r" (clr), "r" (set), "m" (*p)
- : "cc" );
+ "r" (clr), "r" (set), "m" (*p)
+ : "cc" );
+ } else {
+ old = pte_val(*p);
+
+ *p = __pte((old & ~(pte_basic_t)clr) | set);
+ }
return old;
}
--
2.33.1
[PATCH] [Rebased for 5.4] powerpc/32: Fix boot failure with GCC latent entropy plugin
This is backport for 5.4
(cherry picked from commit bba496656a73fc1d1330b49c7f82843836e9feb1)
Boot fails with GCC latent entropy plugin enabled.
This is due to early boot functions trying to access 'latent_entropy'
global data while the kernel is not relocated at its final
destination yet.
As there is no way to tell GCC to use PTRRELOC() to access it,
disable latent entropy plugin in early_32.o and feature-fixups.o and
code-patching.o
Fixes: 38addce8b600 ("gcc-plugins: Add latent_entropy plugin")
Cc: sta...@vger.kernel.org # v4.9+
Reported-by: Erhard Furtner
Signed-off-by: Christophe Leroy
Signed-off-by: Michael Ellerman
Link: https://bugzilla.kernel.org/show_bug.cgi?id=215217
Link:
https://lore.kernel.org/r/2bac55483b8daf5b1caa163a45fa5f9cdbe18be4.1640178426.git.christophe.le...@csgroup.eu
---
arch/powerpc/kernel/Makefile | 1 +
arch/powerpc/lib/Makefile| 3 +++
2 files changed, 4 insertions(+)
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index afbd47b0a75c..5819a577d267 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -13,6 +13,7 @@ CFLAGS_prom_init.o += -fPIC
CFLAGS_btext.o += -fPIC
endif
+CFLAGS_early_32.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
CFLAGS_cputable.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
CFLAGS_prom_init.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
CFLAGS_btext.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile
index b8de3be10eb4..8656b8d2ce55 100644
--- a/arch/powerpc/lib/Makefile
+++ b/arch/powerpc/lib/Makefile
@@ -16,6 +16,9 @@ CFLAGS_code-patching.o += -DDISABLE_BRANCH_PROFILING
CFLAGS_feature-fixups.o += -DDISABLE_BRANCH_PROFILING
endif
+CFLAGS_code-patching.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
+CFLAGS_feature-fixups.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
+
obj-y += alloc.o code-patching.o feature-fixups.o pmem.o
ifndef CONFIG_KASAN
--
2.33.1
[PATCH] [Rebased for 5.16 and 5.15] powerpc/32: Fix boot failure with GCC latent entropy plugin
This is backport for 5.16 and 5.15
(cherry picked from commit bba496656a73fc1d1330b49c7f82843836e9feb1)
Boot fails with GCC latent entropy plugin enabled.
This is due to early boot functions trying to access 'latent_entropy'
global data while the kernel is not relocated at its final
destination yet.
As there is no way to tell GCC to use PTRRELOC() to access it,
disable latent entropy plugin in early_32.o and feature-fixups.o and
code-patching.o
Fixes: 38addce8b600 ("gcc-plugins: Add latent_entropy plugin")
Cc: sta...@vger.kernel.org # v4.9+
Reported-by: Erhard Furtner
Signed-off-by: Christophe Leroy
Signed-off-by: Michael Ellerman
Link: https://bugzilla.kernel.org/show_bug.cgi?id=215217
Link:
https://lore.kernel.org/r/2bac55483b8daf5b1caa163a45fa5f9cdbe18be4.1640178426.git.christophe.le...@csgroup.eu
---
arch/powerpc/kernel/Makefile | 1 +
arch/powerpc/lib/Makefile| 3 +++
2 files changed, 4 insertions(+)
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index 5fa68c2ef1f8..36f3f5a8868d 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -11,6 +11,7 @@ CFLAGS_prom_init.o += -fPIC
CFLAGS_btext.o += -fPIC
endif
+CFLAGS_early_32.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
CFLAGS_cputable.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
CFLAGS_prom_init.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
CFLAGS_btext.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile
index 9e5d0f413b71..0b08e85d3839 100644
--- a/arch/powerpc/lib/Makefile
+++ b/arch/powerpc/lib/Makefile
@@ -19,6 +19,9 @@ CFLAGS_code-patching.o += -DDISABLE_BRANCH_PROFILING
CFLAGS_feature-fixups.o += -DDISABLE_BRANCH_PROFILING
endif
+CFLAGS_code-patching.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
+CFLAGS_feature-fixups.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
+
obj-y += alloc.o code-patching.o feature-fixups.o pmem.o test_code-patching.o
ifndef CONFIG_KASAN
--
2.33.1
[PATCH] [Rebased for 5.10] powerpc/32: Fix boot failure with GCC latent entropy plugin
This is backport for 5.10
(cherry picked from commit bba496656a73fc1d1330b49c7f82843836e9feb1)
Boot fails with GCC latent entropy plugin enabled.
This is due to early boot functions trying to access 'latent_entropy'
global data while the kernel is not relocated at its final
destination yet.
As there is no way to tell GCC to use PTRRELOC() to access it,
disable latent entropy plugin in early_32.o and feature-fixups.o and
code-patching.o
Fixes: 38addce8b600 ("gcc-plugins: Add latent_entropy plugin")
Cc: sta...@vger.kernel.org # v4.9+
Reported-by: Erhard Furtner
Signed-off-by: Christophe Leroy
Signed-off-by: Michael Ellerman
Link: https://bugzilla.kernel.org/show_bug.cgi?id=215217
Link:
https://lore.kernel.org/r/2bac55483b8daf5b1caa163a45fa5f9cdbe18be4.1640178426.git.christophe.le...@csgroup.eu
---
arch/powerpc/kernel/Makefile | 1 +
arch/powerpc/lib/Makefile| 3 +++
2 files changed, 4 insertions(+)
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index fe2ef598e2ea..376104c166fc 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -11,6 +11,7 @@ CFLAGS_prom_init.o += -fPIC
CFLAGS_btext.o += -fPIC
endif
+CFLAGS_early_32.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
CFLAGS_cputable.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
CFLAGS_prom_init.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
CFLAGS_btext.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile
index 58991233381e..0697a0e014ae 100644
--- a/arch/powerpc/lib/Makefile
+++ b/arch/powerpc/lib/Makefile
@@ -19,6 +19,9 @@ CFLAGS_code-patching.o += -DDISABLE_BRANCH_PROFILING
CFLAGS_feature-fixups.o += -DDISABLE_BRANCH_PROFILING
endif
+CFLAGS_code-patching.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
+CFLAGS_feature-fixups.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
+
obj-y += alloc.o code-patching.o feature-fixups.o pmem.o inst.o
test_code-patching.o
ifndef CONFIG_KASAN
--
2.33.1
[PATCH] [Rebased for 4.9] powerpc/32: Fix boot failure with GCC latent entropy plugin
This is backport for 4.9
(cherry picked from commit bba496656a73fc1d1330b49c7f82843836e9feb1)
Boot fails with GCC latent entropy plugin enabled.
This is due to early boot functions trying to access 'latent_entropy'
global data while the kernel is not relocated at its final
destination yet.
As there is no way to tell GCC to use PTRRELOC() to access it,
disable latent entropy plugin in early_32.o and feature-fixups.o and
code-patching.o
Fixes: 38addce8b600 ("gcc-plugins: Add latent_entropy plugin")
Cc: sta...@vger.kernel.org # v4.9+
Reported-by: Erhard Furtner
Signed-off-by: Christophe Leroy
Signed-off-by: Michael Ellerman
Link: https://bugzilla.kernel.org/show_bug.cgi?id=215217
Link:
https://lore.kernel.org/r/2bac55483b8daf5b1caa163a45fa5f9cdbe18be4.1640178426.git.christophe.le...@csgroup.eu
---
arch/powerpc/kernel/Makefile | 1 +
arch/powerpc/lib/Makefile| 3 +++
2 files changed, 4 insertions(+)
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index d80fbf0884ff..bc6c85788b84 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -14,6 +14,7 @@ CFLAGS_prom_init.o += -fPIC
CFLAGS_btext.o += -fPIC
endif
+CFLAGS_setup_32.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
CFLAGS_cputable.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
CFLAGS_prom_init.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
CFLAGS_btext.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile
index 309361e86523..3e3370d126ae 100644
--- a/arch/powerpc/lib/Makefile
+++ b/arch/powerpc/lib/Makefile
@@ -9,6 +9,9 @@ ccflags-$(CONFIG_PPC64) := $(NO_MINIMAL_TOC)
CFLAGS_REMOVE_code-patching.o = $(CC_FLAGS_FTRACE)
CFLAGS_REMOVE_feature-fixups.o = $(CC_FLAGS_FTRACE)
+CFLAGS_code-patching.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
+CFLAGS_feature-fixups.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
+
obj-y += string.o alloc.o crtsavres.o code-patching.o \
feature-fixups.o
--
2.33.1
[PATCH] [Rebased for 4.19 and 4.14] powerpc/32: Fix boot failure with GCC latent entropy plugin
This is backport for 4.19 and 4.14
(cherry picked from commit bba496656a73fc1d1330b49c7f82843836e9feb1)
Boot fails with GCC latent entropy plugin enabled.
This is due to early boot functions trying to access 'latent_entropy'
global data while the kernel is not relocated at its final
destination yet.
As there is no way to tell GCC to use PTRRELOC() to access it,
disable latent entropy plugin in early_32.o and feature-fixups.o and
code-patching.o
Fixes: 38addce8b600 ("gcc-plugins: Add latent_entropy plugin")
Cc: sta...@vger.kernel.org # v4.9+
Reported-by: Erhard Furtner
Signed-off-by: Christophe Leroy
Signed-off-by: Michael Ellerman
Link: https://bugzilla.kernel.org/show_bug.cgi?id=215217
Link:
https://lore.kernel.org/r/2bac55483b8daf5b1caa163a45fa5f9cdbe18be4.1640178426.git.christophe.le...@csgroup.eu
---
arch/powerpc/kernel/Makefile | 1 +
arch/powerpc/lib/Makefile| 3 +++
2 files changed, 4 insertions(+)
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index 1e64cfe22a83..bf19c5514d6c 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -15,6 +15,7 @@ CFLAGS_prom_init.o += -fPIC
CFLAGS_btext.o += -fPIC
endif
+CFLAGS_setup_32.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
CFLAGS_cputable.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
CFLAGS_prom_init.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
CFLAGS_btext.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile
index 670286808928..36f913084429 100644
--- a/arch/powerpc/lib/Makefile
+++ b/arch/powerpc/lib/Makefile
@@ -10,6 +10,9 @@ ccflags-$(CONFIG_PPC64) := $(NO_MINIMAL_TOC)
CFLAGS_REMOVE_code-patching.o = $(CC_FLAGS_FTRACE)
CFLAGS_REMOVE_feature-fixups.o = $(CC_FLAGS_FTRACE)
+CFLAGS_code-patching.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
+CFLAGS_feature-fixups.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
+
obj-y += string.o alloc.o code-patching.o feature-fixups.o
obj-$(CONFIG_PPC32)+= div64.o copy_32.o crtsavres.o strlen_32.o
--
2.33.1
