Re: [PATCH 2/2] powerpc/xmon: use KSYM_NAME_LEN in array size
Maninder Singh writes:
> kallsyms_lookup which in turn calls for kallsyms_lookup_buildid()
> writes on index "KSYM_NAME_LEN - 1".
>
> Thus array size should be KSYM_NAME_LEN.
>
> for powerpc it was defined as "128" directly.
> and commit '61968dbc2d5d' changed define value to 512,
> So both were missed to update with new size.
>
> Fixes: 61968dbc2d5d ("kallsyms: increase maximum kernel symbol length to 512")
AFAICS that's the wrong sha.
That commit appears in linux-next, but the commit that actually went
into mainline is:
b8a94bfb3395 ("kallsyms: increase maximum kernel symbol length to 512")
So I'll update the change log to refer to that.
cheers
> Co-developed-by: Onkarnath
> Signed-off-by: Onkarnath
> Signed-off-by: Maninder Singh
> ---
> arch/powerpc/xmon/xmon.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
> index 728d3c257e4a..70c4c59a1a8f 100644
> --- a/arch/powerpc/xmon/xmon.c
> +++ b/arch/powerpc/xmon/xmon.c
> @@ -88,7 +88,7 @@ static unsigned long ndump = 64;
> static unsigned long nidump = 16;
> static unsigned long ncsum = 4096;
> static int termch;
> -static char tmpstr[128];
> +static char tmpstr[KSYM_NAME_LEN];
> static int tracing_enabled;
>
> static long bus_error_jmp[JMP_BUF_LEN];
> --
> 2.17.1
Re: [PATCH] powerpc: Fail build if using recordmcount with binutils v2.37
Michael Ellerman wrote:
Naveen N Rao writes:
binutils v2.37 drops unused section symbols, which prevents recordmcount
from capturing mcount locations in sections that have no non-weak
symbols. This results in a build failure with a message such as:
Cannot find symbol for section 12: .text.perf_callchain_kernel.
kernel/events/callchain.o: failed
The change to binutils was reverted for v2.38, so this behavior is
specific to binutils v2.37:
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=c09c8b42021180eee9495bd50d8b35e683d3901b
Objtool is able to cope with such sections, so this issue is specific to
recordmcount.
Fail the build and print a warning if binutils v2.37 is detected and if
we are using recordmcount.
Cc: sta...@vger.kernel.org
Suggested-by: Joel Stanley
Signed-off-by: Naveen N Rao
---
arch/powerpc/Makefile | 8
1 file changed, 8 insertions(+)
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index dca73f673d7046..f0540c1f1377c8 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -409,3 +409,11 @@ checkbin:
echo -n '*** Please use a different binutils version.' ; \
false ; \
fi
+ @if test "x${CONFIG_FTRACE_MCOUNT_USE_RECORDMCOUNT}" = "xy" -a \
+ "x${CONFIG_LD_IS_BFD}" = "xy" -a \
+ "x$(call ld-ifversion, -eq, 23700, y)" = "xy" ; then \
+ echo -n '*** binutils 2.37 drops unused section symbols, which
recordmcount ' ; \
+ echo 'is unable to handle.' ; \
+ echo '*** Please use a different binutils version.' ; \
+ false ; \
+ fi
Thanks for doing this.
Masahiro wanted to remove ld-ifversion, he suggested to just check
CONFIG_LD_VERSION directly instead. Mind doing a v2 with that change?
https://lore.kernel.org/all/CAK7LNAQWtDHOs=k+qznt5u1widv86tchkj4zoer4wtvrb97...@mail.gmail.com/
I have posted a v2 with just that change. Let me know if you are
planning to pick up Masahiro's patch above and if you want me to base my
changes atop that (just have to add back archprepare/checkbin).
- Naveen
[PATCH v2] powerpc: Fail build if using recordmcount with binutils v2.37
binutils v2.37 drops unused section symbols, which prevents recordmcount
from capturing mcount locations in sections that have no non-weak
symbols. This results in a build failure with a message such as:
Cannot find symbol for section 12: .text.perf_callchain_kernel.
kernel/events/callchain.o: failed
The change to binutils was reverted for v2.38, so this behavior is
specific to binutils v2.37:
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=c09c8b42021180eee9495bd50d8b35e683d3901b
Objtool is able to cope with such sections, so this issue is specific to
recordmcount.
Fail the build and print a warning if binutils v2.37 is detected and if
we are using recordmcount.
Cc: sta...@vger.kernel.org
Suggested-by: Joel Stanley
Signed-off-by: Naveen N Rao
---
v2: Check directly against $CONFIG_LD_VERSION
arch/powerpc/Makefile | 8
1 file changed, 8 insertions(+)
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index dca73f673d7046..fc76eb9830fdfa 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -409,3 +409,11 @@ checkbin:
echo -n '*** Please use a different binutils version.' ; \
false ; \
fi
+ @if test "x${CONFIG_FTRACE_MCOUNT_USE_RECORDMCOUNT}" = "xy" -a \
+ "x${CONFIG_LD_IS_BFD}" = "xy" -a \
+ "${CONFIG_LD_VERSION}" = "23700" ; then \
+ echo -n '*** binutils 2.37 drops unused section symbols, which
recordmcount ' ; \
+ echo 'is unable to handle.' ; \
+ echo '*** Please use a different binutils version.' ; \
+ false ; \
+ fi
base-commit: 7b2f56d76feff3b494d6e77950ab97987323d3c5
--
2.40.1
Re: WARNING at fs/btrfs/disk-io.c:275 during xfstests run(4k block)
This should be fixed by "btrfs: fix the uptodate assert in btree_csum_one_bio" on the list.
Re: [PATCH] powerpc/crypto: Fix aes-gcm-p10 link errors
On 5/25/23 20:35, Michael Ellerman wrote:
The recently added P10 AES/GCM code added some files containing
CRYPTOGAMS perl-asm code which are near duplicates of the p8 files
found in drivers/crypto/vmx.
In particular the newly added files produce functions with identical
names to the existing code.
When the kernel is built with CONFIG_CRYPTO_AES_GCM_P10=y and
CONFIG_CRYPTO_DEV_VMX_ENCRYPT=y that leads to link errors, eg:
ld: drivers/crypto/vmx/aesp8-ppc.o: in function `aes_p8_set_encrypt_key':
(.text+0xa0): multiple definition of `aes_p8_set_encrypt_key';
arch/powerpc/crypto/aesp8-ppc.o:(.text+0xa0): first defined here
...
ld: drivers/crypto/vmx/ghashp8-ppc.o: in function `gcm_ghash_p8':
(.text+0x140): multiple definition of `gcm_ghash_p8';
arch/powerpc/crypto/ghashp8-ppc.o:(.text+0x2e4): first defined here
Fix it for now by renaming the newly added files and functions to use
"p10" instead of "p8" in the names.
Fixes: 45a4672b9a6e ("crypto: p10-aes-gcm - Update Kconfig and Makefile")
Signed-off-by: Michael Ellerman
---
arch/powerpc/crypto/Makefile | 10 +-
arch/powerpc/crypto/aes-gcm-p10-glue.c | 18 +-
.../crypto/{aesp8-ppc.pl => aesp10-ppc.pl} | 2 +-
.../crypto/{ghashp8-ppc.pl => ghashp10-ppc.pl} | 12 ++--
4 files changed, 21 insertions(+), 21 deletions(-)
rename arch/powerpc/crypto/{aesp8-ppc.pl => aesp10-ppc.pl} (99%)
rename arch/powerpc/crypto/{ghashp8-ppc.pl => ghashp10-ppc.pl} (97%)
I missed adding tested-by in previous reply.
After applying the patch, I was able to successfully build the Linux
kernel v6.4-rc4.
I encountered no errors during the build process. The issue pertaining
to multiple
definitions of certain functions appears to be resolved.
λ grep -i CRYPTO_AES_GCM_P10 .config
CONFIG_CRYPTO_AES_GCM_P10=y
λ grep -i CRYPTO_DEV_VMX_ENCRYPT .config
CONFIG_CRYPTO_DEV_VMX_ENCRYPT=y
+ make O=${BUILD_DIR} CC=clang ARCH=powerpc
CROSS_COMPILE=powerpc64le-linux-gnu- -j16 -s vmlinux modules
Thank you for the well-detailed fix.
Tested-by: Vishal Chourasia
Kernel crash with ftrace tests
While running ftrace specific kernel selftests on IBM Power9 server, following crash is observed. I have observed this crash only on Power9. Similar test run on a Power10 server works. [14350.791484] Kernel attempted to read user page (8) - exploit attempt? (uid: 0) [14350.791507] BUG: Kernel NULL pointer dereference on read at 0x0008 [14350.791514] Faulting instruction address: 0xc04bf0e0 [14350.791521] Oops: Kernel access of bad area, sig: 11 [#1] [14350.791526] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=8192 NUMA pSeries [14350.791532] Modules linked in: nvram rpadlpar_io rpaphp uinput torture dummy veth tun nfsv3 nfs_acl nfs lockd grace fscache netfs brd overlay exfat vfat fat xfs loop sctp ip6_udp_tunnel udp_tunnel dm_mod nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set bonding tls rfkill nf_tables libcrc32c nfnetlink sunrpc pseries_rng vmx_crypto ext4 mbcache jbd2 sd_mod t10_pi crc64_rocksoft crc64 sg ibmvscsi scsi_transport_srp ibmveth fuse [last unloaded: test_cpuidle_latency(O)] [14350.791616] CPU: 8 PID: 1169868 Comm: perl Tainted: G O 6.4.0-rc4-g8b817fded42d #1 [14350.791623] Hardware name: IBM,8375-42A POWER9 (raw) 0x4e0202 0xf05 of:IBM,FW950.50 (VL950_105) hv:phyp pSeries [14350.791629] NIP: c04bf0e0 LR: c0498924 CTR: c02e8f60 [14350.791635] REGS: c002c8313830 TRAP: 0300 Tainted: G O (6.4.0-rc4-g8b817fded42d) [14350.791641] MSR: 80009033 CR: 483139c4 XER: 2004 [14350.791655] CFAR: c000dbbc DAR: 0008 DSISR: 4000 IRQMASK: 0 [14350.791655] GPR00: c0498924 c002c8313ad0 c1411300 [14350.791655] GPR04: c0001d939d68 0001 0008 [14350.791655] GPR08: 8000 0800 0001 [14350.791655] GPR12: 3000 c0001ec56700 [14350.791655] GPR16: [14350.791655] GPR20: c2c67400 c001be8b4000 c2c67378 [14350.791655] GPR24: c0001a41d200 c0001a41d200 7fffb8eb [14350.791655] GPR28: 8603721f02c0 c0001d939d68 c002c8313c18 [14350.791724] NIP [c04bf0e0] page_remove_rmap+0x40/0x320 [14350.791732] LR [c0498924] wp_page_copy+0x384/0xde0 [14350.791738] Call Trace: [14350.791741] [c002c8313ad0] [c0001a41d200] 0xc0001a41d200 (unreliable) [14350.791749] [c002c8313b20] [c0498924] wp_page_copy+0x384/0xde0 [14350.791756] [c002c8313bf0] [c04a1a34] __handle_mm_fault+0x9a4/0xf90 [14350.791764] [c002c8313cf0] [c04a2110] handle_mm_fault+0xf0/0x350 [14350.791771] [c002c8313d40] [c0094b8c] ___do_page_fault+0x47c/0xc20 [14350.791780] [c002c8313df0] [c0095540] hash__do_page_fault+0x30/0x70 [14350.791788] [c002c8313e20] [c009e378] do_hash_fault+0x278/0x470 [14350.791794] [c002c8313e50] [c0008be0] data_access_common_virt+0x210/0x220 [14350.791802] --- interrupt: 300 at 0x7fffb8e91968 [14350.791807] NIP: 7fffb8e91968 LR: 7fffb8e91958 CTR: [14350.791812] REGS: c002c8313e80 TRAP: 0300 Tainted: G O (6.4.0-rc4-g8b817fded42d) [14350.791818] MSR: 8280f033 CR: 24000422 XER: [14350.791835] CFAR: 7fffb8e9185c DAR: 7fffb8eb DSISR: 0a00 IRQMASK: 0 [14350.791835] GPR00: 7fffb9684d14 7fffc55f14f0 7fffb8eb7f00 7fffb8eb [14350.791835] GPR04: 0001 7fffb9122840 0001 [14350.791835] GPR08: 7fffb9122890 0001 7fffc55f1440 [14350.791835] GPR12: 7fffb96dce80 [14350.791835] GPR16: [14350.791835] GPR20: 7fffb8eafb38 7fffc55f15a8 7fffc55f1560 7fffc55f1550 [14350.791835] GPR24: 010022406210 7fffb96d0988 7fffb96d [14350.791835] GPR28: 7fffb96d 7fffb8eafb38 7fffc55f1550 [14350.791902] NIP [7fffb8e91968] 0x7fffb8e91968 [14350.791907] LR [7fffb8e91958] 0x7fffb8e91958 [14350.791911] --- interrupt: 300 [14350.791914] Code: 7c0802a6 7d908026 fb61ffd8 fba1ffe8 fbc1fff0 fbe1fff8 7c7e1b78 7c9d2378 7cbb2b78 91810008 f8010010 f821ffb1 712a0001 3929 7fe3489e [14350.791937] ---[ end trace ]--- [14350.793185] pstore: backend (nvram) writing error (-1) [14350.793190] [14351.793195] Kernel panic - not syncing: Fatal exception - Sachin
Re: [PATCH] powerpc/crypto: Fix aes-gcm-p10 link errors
After applying the patch, I was able to successfully build the Linux
kernel v6.4-rc4.
I encountered no errors during the build process. The issue pertaining
to multiple
definitions of certain functions appears to be resolved.
λ grep -i CRYPTO_AES_GCM_P10 .config
CONFIG_CRYPTO_AES_GCM_P10=y
λ grep -i CRYPTO_DEV_VMX_ENCRYPT .config
CONFIG_CRYPTO_DEV_VMX_ENCRYPT=y
+ make O=${BUILD_DIR} CC=clang ARCH=powerpc
CROSS_COMPILE=powerpc64le-linux-gnu- -j16 -s vmlinux modules
Thank you for the well-detailed fix.
-- vishal.c
On 5/25/23 20:35, Michael Ellerman wrote:
The recently added P10 AES/GCM code added some files containing
CRYPTOGAMS perl-asm code which are near duplicates of the p8 files
found in drivers/crypto/vmx.
In particular the newly added files produce functions with identical
names to the existing code.
When the kernel is built with CONFIG_CRYPTO_AES_GCM_P10=y and
CONFIG_CRYPTO_DEV_VMX_ENCRYPT=y that leads to link errors, eg:
ld: drivers/crypto/vmx/aesp8-ppc.o: in function `aes_p8_set_encrypt_key':
(.text+0xa0): multiple definition of `aes_p8_set_encrypt_key';
arch/powerpc/crypto/aesp8-ppc.o:(.text+0xa0): first defined here
...
ld: drivers/crypto/vmx/ghashp8-ppc.o: in function `gcm_ghash_p8':
(.text+0x140): multiple definition of `gcm_ghash_p8';
arch/powerpc/crypto/ghashp8-ppc.o:(.text+0x2e4): first defined here
Fix it for now by renaming the newly added files and functions to use
"p10" instead of "p8" in the names.
Fixes: 45a4672b9a6e ("crypto: p10-aes-gcm - Update Kconfig and Makefile")
Signed-off-by: Michael Ellerman
---
arch/powerpc/crypto/Makefile | 10 +-
arch/powerpc/crypto/aes-gcm-p10-glue.c | 18 +-
.../crypto/{aesp8-ppc.pl => aesp10-ppc.pl} | 2 +-
.../crypto/{ghashp8-ppc.pl => ghashp10-ppc.pl} | 12 ++--
4 files changed, 21 insertions(+), 21 deletions(-)
rename arch/powerpc/crypto/{aesp8-ppc.pl => aesp10-ppc.pl} (99%)
rename arch/powerpc/crypto/{ghashp8-ppc.pl => ghashp10-ppc.pl} (97%)
diff --git a/arch/powerpc/crypto/Makefile b/arch/powerpc/crypto/Makefile
index 05c7486f42c5..7b4f516abec1 100644
--- a/arch/powerpc/crypto/Makefile
+++ b/arch/powerpc/crypto/Makefile
@@ -22,15 +22,15 @@ sha1-ppc-spe-y := sha1-spe-asm.o sha1-spe-glue.o
sha256-ppc-spe-y := sha256-spe-asm.o sha256-spe-glue.o
crc32c-vpmsum-y := crc32c-vpmsum_asm.o crc32c-vpmsum_glue.o
crct10dif-vpmsum-y := crct10dif-vpmsum_asm.o crct10dif-vpmsum_glue.o
-aes-gcm-p10-crypto-y := aes-gcm-p10-glue.o aes-gcm-p10.o ghashp8-ppc.o
aesp8-ppc.o
+aes-gcm-p10-crypto-y := aes-gcm-p10-glue.o aes-gcm-p10.o ghashp10-ppc.o
aesp10-ppc.o
quiet_cmd_perl = PERL$@
cmd_perl = $(PERL) $< $(if $(CONFIG_CPU_LITTLE_ENDIAN), linux-ppc64le,
linux-ppc64) > $@
-targets += aesp8-ppc.S ghashp8-ppc.S
+targets += aesp10-ppc.S ghashp10-ppc.S
-$(obj)/aesp8-ppc.S $(obj)/ghashp8-ppc.S: $(obj)/%.S: $(src)/%.pl FORCE
+$(obj)/aesp10-ppc.S $(obj)/ghashp10-ppc.S: $(obj)/%.S: $(src)/%.pl FORCE
$(call if_changed,perl)
-OBJECT_FILES_NON_STANDARD_aesp8-ppc.o := y
-OBJECT_FILES_NON_STANDARD_ghashp8-ppc.o := y
+OBJECT_FILES_NON_STANDARD_aesp10-ppc.o := y
+OBJECT_FILES_NON_STANDARD_ghashp10-ppc.o := y
diff --git a/arch/powerpc/crypto/aes-gcm-p10-glue.c
b/arch/powerpc/crypto/aes-gcm-p10-glue.c
index bd3475f5348d..4b6e899895e7 100644
--- a/arch/powerpc/crypto/aes-gcm-p10-glue.c
+++ b/arch/powerpc/crypto/aes-gcm-p10-glue.c
@@ -30,15 +30,15 @@ MODULE_AUTHOR("Danny Tsen
-asmlinkage int aes_p8_set_encrypt_key(const u8 *userKey, const int bits,
+asmlinkage int aes_p10_set_encrypt_key(const u8 *userKey, const int bits,
void *key);
-asmlinkage void aes_p8_encrypt(const u8 *in, u8 *out, const void *key);
+asmlinkage void aes_p10_encrypt(const u8 *in, u8 *out, const void *key);
asmlinkage void aes_p10_gcm_encrypt(u8 *in, u8 *out, size_t len,
void *rkey, u8 *iv, void *Xi);
asmlinkage void aes_p10_gcm_decrypt(u8 *in, u8 *out, size_t len,
void *rkey, u8 *iv, void *Xi);
asmlinkage void gcm_init_htable(unsigned char htable[256], unsigned char
Xi[16]);
-asmlinkage void gcm_ghash_p8(unsigned char *Xi, unsigned char *Htable,
+asmlinkage void gcm_ghash_p10(unsigned char *Xi, unsigned char *Htable,
unsigned char *aad, unsigned int alen);
struct aes_key {
@@ -93,7 +93,7 @@ static void set_aad(struct gcm_ctx *gctx, struct Hash_ctx
*hash,
gctx->aadLen = alen;
i = alen & ~0xf;
if (i) {
- gcm_ghash_p8(nXi, hash->Htable+32, aad, i);
+ gcm_ghash_p10(nXi, hash->Htable+32, aad, i);
aad += i;
alen -= i;
}
@@ -102,7 +102,7 @@ static void set_aad(struct gcm_ctx *gctx, struct Hash_ctx
*hash,
nXi[i] ^= aad[i];
memset(gctx->aad_hash, 0, 16);
- gcm_ghash_p8(gctx->aad_hash, hash->Htable+
WARNING at fs/btrfs/disk-io.c:275 during xfstests run(4k block)
While running xfstests against btrfs (with 4k block size) on IBM Power server booted with 6.4.0-rc3-next-20230525, following warning is seen. This warning Is seen several times during the test run. This problem was first seen with 6.4.0-rc2-next-20230516 [ 365.885258] run fstests btrfs/001 at 2023-05-29 14:40:10 [ 366.070754] BTRFS: device fsid 0732-a1c0-452c-8409-4fa8f9b69e51 devid 1 transid 6 /dev/sdb2 scanned by mkfs.btrfs (27139) [ 366.076267] BTRFS info (device sdb2): using crc32c (crc32c-generic) checksum algorithm [ 366.076286] BTRFS info (device sdb2): using free space tree [ 366.076292] BTRFS warning (device sdb2): read-write for sector size 4096 with page size 65536 is experimental [ 366.078153] BTRFS info (device sdb2): enabling ssd optimizations [ 366.078319] BTRFS info (device sdb2): checking UUID tree [ 366.084911] [ cut here ] [ 366.084923] WARNING: CPU: 16 PID: 27174 at fs/btrfs/disk-io.c:275 btree_csum_one_bio+0xdc/0x310 [btrfs] [ 366.084962] Modules linked in: dm_mod nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 bonding rfkill tls ip_set nf_tables nfnetlink sunrpc btrfs blake2b_generic xor raid6_pq zstd_compress nd_pmem libcrc32c nd_btt dax_pmem pseries_rng papr_scm libnvdimm vmx_crypto aes_gcm_p10_crypto ext4 mbcache jbd2 sd_mod t10_pi crc64_rocksoft crc64 sg ibmvscsi ibmveth scsi_transport_srp fuse [ 366.085003] CPU: 16 PID: 27174 Comm: btrfs Tainted: G W 6.4.0-rc3-next-20230525 #1 [ 366.085009] Hardware name: IBM,9080-HEX POWER10 (raw) 0x800200 0xf06 of:IBM,FW1030.00 (NH1030_026) hv:phyp pSeries [ 366.085014] NIP: c00801a2eed4 LR: c00801b1b5a4 CTR: [ 366.085018] REGS: c0001a3bb030 TRAP: 0700 Tainted: G W (6.4.0-rc3-next-20230525) [ 366.085023] MSR: 8282b033 CR: 24002882 XER: 2004 [ 366.085033] CFAR: c00801a2ee78 IRQMASK: 0 [ 366.085033] GPR00: c00801b1b5a4 c0001a3bb2d0 c0080165a700 c000d18cca80 [ 366.085033] GPR04: c001029da290 4000 01d44000 [ 366.085033] GPR08: c00c0021fd40 ca19d890 [ 366.085033] GPR12: 84002482 c00aa7cf6f00 0001 [ 366.085033] GPR16: c0001a3bb790 c0001a3bb770 [ 366.085033] GPR20: c0001a3bb558 01d4 c0001a3bb558 [ 366.085033] GPR24: c000879ed000 c000d18cca80 c000fd947a80 c000879ed000 [ 366.085033] GPR28: c000d18ccb30 4000 c2c67490 c000d1a0c558 [ 366.085078] NIP [c00801a2eed4] btree_csum_one_bio+0xdc/0x310 [btrfs] [ 366.085110] LR [c00801b1b5a4] btrfs_bio_csum+0x4c/0x70 [btrfs] [ 366.085139] Call Trace: [ 366.085141] [c0001a3bb2d0] [0006] 0x6 (unreliable) [ 366.085146] [c0001a3bb380] [01d44000] 0x1d44000 [ 366.085150] [c0001a3bb3a0] [c00801b1c554] btrfs_submit_chunk+0x51c/0x560 [btrfs] [ 366.085179] [c0001a3bb440] [c00801b1c67c] btrfs_submit_bio+0x44/0x70 [btrfs] [ 366.085207] [c0001a3bb470] [c00801a74ec0] write_one_eb+0x2f8/0x3c0 [btrfs] [ 366.085242] [c0001a3bb4d0] [c00801a75460] btree_write_cache_pages+0x4d8/0x7b0 [btrfs] [ 366.085276] [c0001a3bb660] [c00801a2d04c] btree_writepages+0x94/0xe0 [btrfs] [ 366.085308] [c0001a3bb690] [c044df24] do_writepages+0x114/0x290 [ 366.085316] [c0001a3bb710] [c0436f58] filemap_fdatawrite_wbc+0xb8/0x140 [ 366.085322] [c0001a3bb750] [c043df60] __filemap_fdatawrite_range+0x80/0xc0 [ 366.085327] [c0001a3bb800] [c00801a37dc0] btrfs_write_marked_extents+0x78/0x1b0 [btrfs] [ 366.085360] [c0001a3bb870] [c00801a37f60] btrfs_write_and_wait_transaction.isra.22+0x68/0x140 [btrfs] [ 366.085393] [c0001a3bb8e0] [c00801a3a2d8] btrfs_commit_transaction+0x610/0x11f0 [btrfs] [ 366.085425] [c0001a3bb9d0] [c00801a8ccf0] btrfs_mksubvol.isra.36+0x4e8/0x5b0 [btrfs] [ 366.085460] [c0001a3bbab0] [c00801a8ce8c] btrfs_mksnapshot+0xd4/0x140 [btrfs] [ 366.085493] [c0001a3bbb20] [c00801a8d110] __btrfs_ioctl_snap_create+0x218/0x260 [btrfs] [ 366.085526] [c0001a3bbbd0] [c00801a8d3fc] btrfs_ioctl_snap_create_v2+0x1a4/0x1f0 [btrfs] [ 366.085559] [c0001a3bbc30] [c00801a910a4] btrfs_ioctl+0x1dac/0x3180 [btrfs] [ 366.085592] [c0001a3bbdc0] [c05a7098] sys_ioctl+0xf8/0x190 [ 366.085598] [c0001a3bbe10] [c00374b0] system_call_exception+0x140/0x350 [ 366.085604] [c0001a3bbe50] [c000d6a0] system_call_common+0x160/0x2e4 [ 366.085610] --- interrupt: c00 at 0x7fffa5f29b70 [ 366.085614] NIP: 7fffa5f29b70 LR: 1007a968 CTR: [ 366.085618] REGS: c0001a3bbe80 TRAP: 0c00 Tainted: G W (6.4.0-rc3-next-20230525) [ 366.085625] MSR: 800
Re: [PATCH] powerpc: Fail build if using recordmcount with binutils v2.37
Naveen N Rao writes:
> binutils v2.37 drops unused section symbols, which prevents recordmcount
> from capturing mcount locations in sections that have no non-weak
> symbols. This results in a build failure with a message such as:
> Cannot find symbol for section 12: .text.perf_callchain_kernel.
> kernel/events/callchain.o: failed
>
> The change to binutils was reverted for v2.38, so this behavior is
> specific to binutils v2.37:
> https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=c09c8b42021180eee9495bd50d8b35e683d3901b
>
> Objtool is able to cope with such sections, so this issue is specific to
> recordmcount.
>
> Fail the build and print a warning if binutils v2.37 is detected and if
> we are using recordmcount.
>
> Cc: sta...@vger.kernel.org
> Suggested-by: Joel Stanley
> Signed-off-by: Naveen N Rao
> ---
> arch/powerpc/Makefile | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
> index dca73f673d7046..f0540c1f1377c8 100644
> --- a/arch/powerpc/Makefile
> +++ b/arch/powerpc/Makefile
> @@ -409,3 +409,11 @@ checkbin:
> echo -n '*** Please use a different binutils version.' ; \
> false ; \
> fi
> + @if test "x${CONFIG_FTRACE_MCOUNT_USE_RECORDMCOUNT}" = "xy" -a \
> + "x${CONFIG_LD_IS_BFD}" = "xy" -a \
> + "x$(call ld-ifversion, -eq, 23700, y)" = "xy" ; then \
> + echo -n '*** binutils 2.37 drops unused section symbols, which
> recordmcount ' ; \
> + echo 'is unable to handle.' ; \
> + echo '*** Please use a different binutils version.' ; \
> + false ; \
> + fi
Thanks for doing this.
Masahiro wanted to remove ld-ifversion, he suggested to just check
CONFIG_LD_VERSION directly instead. Mind doing a v2 with that change?
https://lore.kernel.org/all/CAK7LNAQWtDHOs=k+qznt5u1widv86tchkj4zoer4wtvrb97...@mail.gmail.com/
cheers
Re: [PATCH 09/12] mm/khugepaged: retract_page_tables() without mmap or vma lock
On Sun, May 28, 2023 at 11:25:15PM -0700, Hugh Dickins wrote:
> Simplify shmem and file THP collapse's retract_page_tables(), and relax
> its locking: to improve its success rate and to lessen impact on others.
>
> Instead of its MADV_COLLAPSE case doing set_huge_pmd() at target_addr of
> target_mm, leave that part of the work to madvise_collapse() calling
> collapse_pte_mapped_thp() afterwards: just adjust collapse_file()'s
> result code to arrange for that. That spares retract_page_tables() four
> arguments; and since it will be successful in retracting all of the page
> tables expected of it, no need to track and return a result code itself.
>
> It needs i_mmap_lock_read(mapping) for traversing the vma interval tree,
> but it does not need i_mmap_lock_write() for that: page_vma_mapped_walk()
> allows for pte_offset_map_lock() etc to fail, and uses pmd_lock() for
> THPs. retract_page_tables() just needs to use those same spinlocks to
> exclude it briefly, while transitioning pmd from page table to none: so
> restore its use of pmd_lock() inside of which pte lock is nested.
>
> Users of pte_offset_map_lock() etc all now allow for them to fail:
> so retract_page_tables() now has no use for mmap_write_trylock() or
> vma_try_start_write(). In common with rmap and page_vma_mapped_walk(),
> it does not even need the mmap_read_lock().
>
> But those users do expect the page table to remain a good page table,
> until they unlock and rcu_read_unlock(): so the page table cannot be
> freed immediately, but rather by the recently added pte_free_defer().
>
> retract_page_tables() can be enhanced to replace_page_tables(), which
> inserts the final huge pmd without mmap lock: going through an invalid
> state instead of pmd_none() followed by fault. But that does raise some
> questions, and requires a more complicated pte_free_defer() for powerpc
> (when its arch_needs_pgtable_deposit() for shmem and file THPs). Leave
> that enhancement to a later release.
>
> Signed-off-by: Hugh Dickins
> ---
> mm/khugepaged.c | 169 +---
> 1 file changed, 60 insertions(+), 109 deletions(-)
>
> diff --git a/mm/khugepaged.c b/mm/khugepaged.c
> index 1083f0e38a07..4fd408154692 100644
> --- a/mm/khugepaged.c
> +++ b/mm/khugepaged.c
> @@ -1617,9 +1617,8 @@ int collapse_pte_mapped_thp(struct mm_struct *mm,
> unsigned long addr,
> break;
> case SCAN_PMD_NONE:
> /*
> - * In MADV_COLLAPSE path, possible race with khugepaged where
> - * all pte entries have been removed and pmd cleared. If so,
> - * skip all the pte checks and just update the pmd mapping.
> + * All pte entries have been removed and pmd cleared.
> + * Skip all the pte checks and just update the pmd mapping.
>*/
> goto maybe_install_pmd;
> default:
> @@ -1748,123 +1747,73 @@ static void
> khugepaged_collapse_pte_mapped_thps(struct khugepaged_mm_slot *mm_sl
> mmap_write_unlock(mm);
> }
>
> -static int retract_page_tables(struct address_space *mapping, pgoff_t pgoff,
> -struct mm_struct *target_mm,
> -unsigned long target_addr, struct page *hpage,
> -struct collapse_control *cc)
> +static void retract_page_tables(struct address_space *mapping, pgoff_t pgoff)
> {
> struct vm_area_struct *vma;
> - int target_result = SCAN_FAIL;
>
> - i_mmap_lock_write(mapping);
> + i_mmap_lock_read(mapping);
> vma_interval_tree_foreach(vma, &mapping->i_mmap, pgoff, pgoff) {
> - int result = SCAN_FAIL;
> - struct mm_struct *mm = NULL;
> - unsigned long addr = 0;
> - pmd_t *pmd;
> - bool is_target = false;
> + struct mm_struct *mm;
> + unsigned long addr;
> + pmd_t *pmd, pgt_pmd;
> + spinlock_t *pml;
> + spinlock_t *ptl;
>
> /*
>* Check vma->anon_vma to exclude MAP_PRIVATE mappings that
> - * got written to. These VMAs are likely not worth investing
> - * mmap_write_lock(mm) as PMD-mapping is likely to be split
> - * later.
> + * got written to. These VMAs are likely not worth removing
> + * page tables from, as PMD-mapping is likely to be split later.
>*
> - * Note that vma->anon_vma check is racy: it can be set up after
> - * the check but before we took mmap_lock by the fault path.
> - * But page lock would prevent establishing any new ptes of the
> - * page, so we are safe.
> - *
> - * An alternative would be drop the check, but check that page
> - * table is clear before calling pmdp_collapse_flush() under
> - * ptl. It has higher chance to recover THP for t
[PATCH] powerpc/kcsan: Properly instrument arch_spin_unlock()
The following boottime error is encountered with SMP kernel:
kcsan: improperly instrumented type=(0): arch_spin_unlock(&arch_spinlock)
kcsan: improperly instrumented type=(0): spin_unlock(&test_spinlock)
kcsan: improperly instrumented type=(KCSAN_ACCESS_WRITE):
arch_spin_unlock(&arch_spinlock)
kcsan: improperly instrumented type=(KCSAN_ACCESS_WRITE):
spin_unlock(&test_spinlock)
kcsan: improperly instrumented type=(KCSAN_ACCESS_WRITE |
KCSAN_ACCESS_COMPOUND): arch_spin_unlock(&arch_spinlock)
kcsan: improperly instrumented type=(KCSAN_ACCESS_WRITE |
KCSAN_ACCESS_COMPOUND): spin_unlock(&test_spinlock)
kcsan: selftest: test_barrier failed
kcsan: selftest: 2/3 tests passed
Kernel panic - not syncing: selftests failed
Properly instrument arch_spin_unlock() with kcsan_mb().
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/simple_spinlock.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/include/asm/simple_spinlock.h
b/arch/powerpc/include/asm/simple_spinlock.h
index 9dcc7e9993b9..4dd12dcb9ef8 100644
--- a/arch/powerpc/include/asm/simple_spinlock.h
+++ b/arch/powerpc/include/asm/simple_spinlock.h
@@ -15,6 +15,7 @@
* (the type definitions are in asm/simple_spinlock_types.h)
*/
#include
+#include
#include
#include
#include
@@ -126,6 +127,7 @@ static inline void arch_spin_lock(arch_spinlock_t *lock)
static inline void arch_spin_unlock(arch_spinlock_t *lock)
{
+ kcsan_mb();
__asm__ __volatile__("# arch_spin_unlock\n\t"
PPC_RELEASE_BARRIER: : :"memory");
lock->slock = 0;
--
2.40.1
Re: [PATCH 1/1] arch:hexagon/powerpc: use KSYM_NAME_LEN in array size
On Mon, May 29, 2023 at 1:08 PM Maninder Singh wrote: > > I Will add co-developed-by` tag. > because this change was identified while we were working on kallsyms some > time back. > https://lore.kernel.org/lkml/yontol4zc4cyt...@infradead.org/t/ > > this patch set is pending and we will start working on that again, so i > thought better > to send bugfix first. Sounds good to me! (Fixed Wedson's email address) > Yes, I think second buffer was not related to kallsyms, so I have not touched > that. Kees: what is the current stance on `[static N]` parameters? Something like: const char *kallsyms_lookup(unsigned long addr, unsigned long *symbolsize, unsigned long *offset, - char **modname, char *namebuf); + char **modname, char namebuf[static KSYM_NAME_LEN]); makes the compiler complain about cases like these (even if trivial): arch/powerpc/xmon/xmon.c:1711:10: error: array argument is too small; contains 128 elements, callee requires at least 512 [-Werror,-Warray-bounds] name = kallsyms_lookup(pc, &size, &offset, NULL, tmpstr); ^ ~~ ./include/linux/kallsyms.h:86:29: note: callee declares array parameter as static here char **modname, char namebuf[static KSYM_NAME_LEN]); ^ ~~ But I only see 2 files in the kernel using `[static N]` (from 2020 and 2021). Should something else be used instead (e.g. `__counted_by`), even if constexpr-sized?. Also, I went through the other callers to `kallsyms_lookup` to see other issues -- one I am not sure about is `fetch_store_symstring` in `kernel/trace/trace_probe_tmpl.h`. Steven/Masami: is that "with max length" in the function docs enough? Is it 0x? Thanks! Cheers, Miguel
Re: [PATCH 05/12] powerpc: add pte_free_defer() for pgtables sharing page
On Mon, 29 May 2023, Matthew Wilcox wrote:
> On Sun, May 28, 2023 at 11:20:21PM -0700, Hugh Dickins wrote:
> > +void pte_free_defer(struct mm_struct *mm, pgtable_t pgtable)
> > +{
> > + struct page *page;
> > +
> > + page = virt_to_page(pgtable);
> > + call_rcu(&page->rcu_head, pte_free_now);
> > +}
>
> This can't be safe (on ppc). IIRC you might have up to 16x4k page
> tables sharing one 64kB page. So if you have two page tables from the
> same page being defer-freed simultaneously, you'll reuse the rcu_head
> and I cannot imagine things go well from that point.
Oh yes, of course, thanks for catching that so quickly.
So my s390 and sparc implementations will be equally broken.
>
> I have no idea how to solve this problem.
I do: I'll have to go back to the more complicated implementation we
actually ran with on powerpc - I was thinking those complications just
related to deposit/withdraw matters, forgetting the one-rcu_head issue.
It uses large (0x1) increments of the page refcount, avoiding
call_rcu() when already active.
It's not a complication I had wanted to explain or test for now,
but we shall have to. Should apply equally well to sparc, but s390
more of a problem, since s390 already has its own refcount cleverness.
Thanks, I must dash, out much of the day.
Hugh
Re: [PATCH 05/12] powerpc: add pte_free_defer() for pgtables sharing page
On Sun, May 28, 2023 at 11:20:21PM -0700, Hugh Dickins wrote:
> +void pte_free_defer(struct mm_struct *mm, pgtable_t pgtable)
> +{
> + struct page *page;
> +
> + page = virt_to_page(pgtable);
> + call_rcu(&page->rcu_head, pte_free_now);
> +}
This can't be safe (on ppc). IIRC you might have up to 16x4k page
tables sharing one 64kB page. So if you have two page tables from the
same page being defer-freed simultaneously, you'll reuse the rcu_head
and I cannot imagine things go well from that point.
I have no idea how to solve this problem.
Re: [PATCH 02/12] mm/pgtable: add PAE safety to __pte_offset_map()
On Sun, May 28, 2023 at 11:16:16PM -0700, Hugh Dickins wrote: > +#if defined(CONFIG_GUP_GET_PXX_LOW_HIGH) && \ > + (defined(CONFIG_SMP) || defined(CONFIG_PREEMPT_RCU)) > +/* > + * See the comment above ptep_get_lockless() in include/linux/pgtable.h: > + * the barriers in pmdp_get_lockless() cannot guarantee that the value in > + * pmd_high actually belongs with the value in pmd_low; but holding > interrupts > + * off blocks the TLB flush between present updates, which guarantees that a > + * successful __pte_offset_map() points to a page from matched halves. > + */ > +#define config_might_irq_save(flags) local_irq_save(flags) > +#define config_might_irq_restore(flags) local_irq_restore(flags) > +#else > +#define config_might_irq_save(flags) > +#define config_might_irq_restore(flags) I don't like the name. It should indicate that it's PMD-related, so pmd_read_start(flags) / pmd_read_end(flags)?
[PATCH] powerpc: Fail build if using recordmcount with binutils v2.37
binutils v2.37 drops unused section symbols, which prevents recordmcount
from capturing mcount locations in sections that have no non-weak
symbols. This results in a build failure with a message such as:
Cannot find symbol for section 12: .text.perf_callchain_kernel.
kernel/events/callchain.o: failed
The change to binutils was reverted for v2.38, so this behavior is
specific to binutils v2.37:
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=c09c8b42021180eee9495bd50d8b35e683d3901b
Objtool is able to cope with such sections, so this issue is specific to
recordmcount.
Fail the build and print a warning if binutils v2.37 is detected and if
we are using recordmcount.
Cc: sta...@vger.kernel.org
Suggested-by: Joel Stanley
Signed-off-by: Naveen N Rao
---
arch/powerpc/Makefile | 8
1 file changed, 8 insertions(+)
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index dca73f673d7046..f0540c1f1377c8 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -409,3 +409,11 @@ checkbin:
echo -n '*** Please use a different binutils version.' ; \
false ; \
fi
+ @if test "x${CONFIG_FTRACE_MCOUNT_USE_RECORDMCOUNT}" = "xy" -a \
+ "x${CONFIG_LD_IS_BFD}" = "xy" -a \
+ "x$(call ld-ifversion, -eq, 23700, y)" = "xy" ; then \
+ echo -n '*** binutils 2.37 drops unused section symbols, which
recordmcount ' ; \
+ echo 'is unable to handle.' ; \
+ echo '*** Please use a different binutils version.' ; \
+ false ; \
+ fi
base-commit: 7b2f56d76feff3b494d6e77950ab97987323d3c5
--
2.40.1
[PATCH 2/2] powerpc/xmon: use KSYM_NAME_LEN in array size
kallsyms_lookup which in turn calls for kallsyms_lookup_buildid()
writes on index "KSYM_NAME_LEN - 1".
Thus array size should be KSYM_NAME_LEN.
for powerpc it was defined as "128" directly.
and commit '61968dbc2d5d' changed define value to 512,
So both were missed to update with new size.
Fixes: 61968dbc2d5d ("kallsyms: increase maximum kernel symbol length to 512")
Co-developed-by: Onkarnath
Signed-off-by: Onkarnath
Signed-off-by: Maninder Singh
---
arch/powerpc/xmon/xmon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index 728d3c257e4a..70c4c59a1a8f 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -88,7 +88,7 @@ static unsigned long ndump = 64;
static unsigned long nidump = 16;
static unsigned long ncsum = 4096;
static int termch;
-static char tmpstr[128];
+static char tmpstr[KSYM_NAME_LEN];
static int tracing_enabled;
static long bus_error_jmp[JMP_BUF_LEN];
--
2.17.1
[PATCH 1/2] hexagon/traps.c: use KSYM_NAME_LEN in array size
kallsyms_lookup which in turn calls for kallsyms_lookup_buildid()
writes on index "KSYM_NAME_LEN - 1".
Thus array size should be KSYM_NAME_LEN.
for hexagon it was defined as "128" directly.
and commit '61968dbc2d5d' changed define value to 512,
So both were missed to update with new size.
Fixes: 61968dbc2d5d ("kallsyms: increase maximum kernel symbol length to 512")
Co-developed-by: Onkarnath
Signed-off-by: Onkarnath
Signed-off-by: Maninder Singh
---
arch/hexagon/kernel/traps.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/hexagon/kernel/traps.c b/arch/hexagon/kernel/traps.c
index 6447763ce5a9..65b30b6ea226 100644
--- a/arch/hexagon/kernel/traps.c
+++ b/arch/hexagon/kernel/traps.c
@@ -82,7 +82,7 @@ static void do_show_stack(struct task_struct *task, unsigned
long *fp,
const char *name = NULL;
unsigned long *newfp;
unsigned long low, high;
- char tmpstr[128];
+ char tmpstr[KSYM_NAME_LEN];
char *modname;
int i;
--
2.17.1
RE: [PATCH 1/1] arch:hexagon/powerpc: use KSYM_NAME_LEN in array size
Hi,
>>
>> kallsyms_lookup which in turn calls for kallsyms_lookup_buildid()
>> writes on index "KSYM_NAME_LEN - 1".
>>
>> Thus array size should be KSYM_NAME_LEN.
>>
>> for powerpc and hexagon it was defined as "128" directly.
>> and commit '61968dbc2d5d' changed define value to 512,
>> So both were missed to update with new size.
>>
>> Fixes: 61968dbc2d5d ("kallsyms: increase maximum kernel symbol length to
>> 512")
>> Signed-off-by: Onkarnath
>> Signed-off-by: Maninder Singh
> Thanks for this!
>
> There is no `From:` at the top. Since I cannot locate the patch in
> Lore, did you mean to put both of you as authors perhaps? In that
> case, please use a `Co-developed-by` as needed.
>
I Will add co-developed-by` tag.
because this change was identified while we were working on kallsyms some time
back.
https://lore.kernel.org/lkml/yontol4zc4cyt...@infradead.org/t/
this patch set is pending and we will start working on that again, so i thought
better
to send bugfix first.
> Perhaps it is a good idea to submit each arch independently, too.
>
ok, I will share 2 separate patches.
> The changes themselves look fine on a quick inspection, though the
> `xmon.c` one is a global buffer (and there is another equally-sized
> buffer in `xmon.c` with a hard-coded `128` constant that would be nice
> to clarify).
Yes, I think second buffer was not related to kallsyms, so I have not touched
that.
Thanks,
Maninder Singh
Re: [PATCH 1/1] arch:hexagon/powerpc: use KSYM_NAME_LEN in array size
On Mon, May 29, 2023 at 7:44 AM Maninder Singh wrote:
>
> kallsyms_lookup which in turn calls for kallsyms_lookup_buildid()
> writes on index "KSYM_NAME_LEN - 1".
>
> Thus array size should be KSYM_NAME_LEN.
>
> for powerpc and hexagon it was defined as "128" directly.
> and commit '61968dbc2d5d' changed define value to 512,
> So both were missed to update with new size.
>
> Fixes: 61968dbc2d5d ("kallsyms: increase maximum kernel symbol length to 512")
> Signed-off-by: Onkarnath
> Signed-off-by: Maninder Singh
Thanks for this!
There is no `From:` at the top. Since I cannot locate the patch in
Lore, did you mean to put both of you as authors perhaps? In that
case, please use a `Co-developed-by` as needed.
Perhaps it is a good idea to submit each arch independently, too.
The changes themselves look fine on a quick inspection, though the
`xmon.c` one is a global buffer (and there is another equally-sized
buffer in `xmon.c` with a hard-coded `128` constant that would be nice
to clarify).
Cheers,
Miguel
Re: Fwd: ./include/linux/mmzone.h:1735:2: error: #error Allocator MAX_ORDER exceeds SECTION_SIZE (v6.4-rc3 build regression)
On Wed, May 24, 2023 at 06:13:52PM +0300, Doru Iorgulescu wrote: > Awesome, thanks! tl;dr: see [1]. (Hey, looks like complimenting noise here.) [1]: https://lore.kernel.org/regressions/5df92692-296e-3956-24fa-2bd439337...@gmail.com/ -- An old man doll... just what I always wanted! - Clara signature.asc Description: PGP signature
