[PATCH v2] selftests: livepatch: handle PRINTK_CALLER in check_result()
Some arch configs (like ppc64) enable CONFIG_PRINTK_CALLER,
which adds the caller id as part of the dmesg. With recent
util-linux's update 467a5b3192f16 ('dmesg: add caller_id support')
the standard "dmesg" has been enhanced to print PRINTK_CALLER fields.
Due to this, even though the expected vs observed are same,
end testcase results are failed.
-% insmod test_modules/test_klp_livepatch.ko
-livepatch: enabling patch 'test_klp_livepatch'
-livepatch: 'test_klp_livepatch': initializing patching transition
-livepatch: 'test_klp_livepatch': starting patching transition
-livepatch: 'test_klp_livepatch': completing patching transition
-livepatch: 'test_klp_livepatch': patching complete
-% echo 0 > /sys/kernel/livepatch/test_klp_livepatch/enabled
-livepatch: 'test_klp_livepatch': initializing unpatching transition
-livepatch: 'test_klp_livepatch': starting unpatching transition
-livepatch: 'test_klp_livepatch': completing unpatching transition
-livepatch: 'test_klp_livepatch': unpatching complete
-% rmmod test_klp_livepatch
+[ T3659] % insmod test_modules/test_klp_livepatch.ko
+[ T3682] livepatch: enabling patch 'test_klp_livepatch'
+[ T3682] livepatch: 'test_klp_livepatch': initializing patching transition
+[ T3682] livepatch: 'test_klp_livepatch': starting patching transition
+[T826] livepatch: 'test_klp_livepatch': completing patching transition
+[T826] livepatch: 'test_klp_livepatch': patching complete
+[ T3659] % echo 0 > /sys/kernel/livepatch/test_klp_livepatch/enabled
+[ T3659] livepatch: 'test_klp_livepatch': initializing unpatching transition
+[ T3659] livepatch: 'test_klp_livepatch': starting unpatching transition
+[T789] livepatch: 'test_klp_livepatch': completing unpatching transition
+[T789] livepatch: 'test_klp_livepatch': unpatching complete
+[ T3659] % rmmod test_klp_livepatch
ERROR: livepatch kselftest(s) failed
not ok 1 selftests: livepatch: test-livepatch.sh # exit=1
Currently the check_result() handles the "[time]" removal from
the dmesg. Enhance the check to also handle removal of "[Thread Id]"
or "[CPU Id]".
Signed-off-by: Madhavan Srinivasan
---
Changelog v1:
- Modified commit message to include util-linux commit that
updated dmesg to support printing of PRINTK_CALLER fields.
- Updated the check to include "CPU Id" along with "Thread Id"
tools/testing/selftests/livepatch/functions.sh | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/livepatch/functions.sh
b/tools/testing/selftests/livepatch/functions.sh
index e5d06fb40233..15601402dee6 100644
--- a/tools/testing/selftests/livepatch/functions.sh
+++ b/tools/testing/selftests/livepatch/functions.sh
@@ -306,7 +306,8 @@ function check_result {
result=$(dmesg | awk -v last_dmesg="$LAST_DMESG" 'p; $0 == last_dmesg {
p=1 }' | \
grep -e 'livepatch:' -e 'test_klp' | \
grep -v '\(tainting\|taints\) kernel' | \
-sed 's/^\[[ 0-9.]*\] //')
+sed 's/^\[[ 0-9.]*\] //' | \
+sed 's/^\[[ ]*[CT][0-9]*\] //')
if [[ "$expect" == "$result" ]] ; then
echo "ok"
--
2.47.0
Re: BUG: KASAN: vmalloc-out-of-bounds in copy_to_kernel_nofault+0xd8/0x1c8 (v6.13-rc6, PowerMac G4)
On 1/12/25 6:28 PM, Erhard Furtner wrote: > Greetings! > > I am getting this at bootup on my PowerMac G4 with a KASAN-enabled kernel > 6.13-rc6: Sorry for the delayed response, Are you seeing this only in this kernel or this is the recent kernel you tried to boot? Maddy > > [...] > BUG: KASAN: vmalloc-out-of-bounds in copy_to_kernel_nofault+0xd8/0x1c8 > Write of size 8 at addr f100 by task chronyd/1293 > > CPU: 0 UID: 123 PID: 1293 Comm: chronyd Tainted: GW > 6.13.0-rc6-PMacG4 #2 > Tainted: [W]=WARN > Hardware name: PowerMac3,6 7455 0x80010303 PowerMac > Call Trace: > [c2437590] [c1631a84] dump_stack_lvl+0x70/0x8c (unreliable) > [c24375b0] [c0504998] print_report+0xdc/0x504 > [c2437610] [c050475c] kasan_report+0xf8/0x108 > [c2437690] [c0505a3c] kasan_check_range+0x24/0x18c > [c24376a0] [c03fb5e4] copy_to_kernel_nofault+0xd8/0x1c8 > [c24376c0] [c004c014] patch_instructions+0x15c/0x16c > [c2437710] [c00731a8] bpf_arch_text_copy+0x60/0x7c > [c2437730] [c0281168] bpf_jit_binary_pack_finalize+0x50/0xac > [c2437750] [c0073cf4] bpf_int_jit_compile+0xb30/0xdec > [c2437880] [c0280394] bpf_prog_select_runtime+0x15c/0x478 > [c24378d0] [c1263428] bpf_prepare_filter+0xbf8/0xc14 > [c2437990] [c12677ec] bpf_prog_create_from_user+0x258/0x2b4 > [c24379d0] [c027111c] do_seccomp+0x3dc/0x1890 > [c2437ac0] [c001d8e0] system_call_exception+0x2dc/0x420 > [c2437f30] [c00281ac] ret_from_syscall+0x0/0x2c > --- interrupt: c00 at 0x5a1274 > NIP: 005a1274 LR: 006a3b3c CTR: 005296c8 > REGS: c2437f40 TRAP: 0c00 Tainted: GW (6.13.0-rc6-PMacG4) > MSR: 0200f932 CR: 24004422 XER: > > GPR00: 0166 af8f3fa0 a7ee3540 0001 013b6500 005a5858 > 0200f932 > GPR08: 1fe9 013d5fc8 005296c8 2822244c 00b2fcd8 > af8f4b57 > GPR16: 0001 0001 > 0002 > GPR24: 00afdbb0 006e0004 013ce060 006e7c1c > 0001 > NIP [005a1274] 0x5a1274 > LR [006a3b3c] 0x6a3b3c > --- interrupt: c00 > > The buggy address belongs to the virtual mapping at > [f100, f1002000) created by: > text_area_cpu_up+0x20/0x190 > > The buggy address belongs to the physical page: > page: refcount:1 mapcount:0 mapping: index:0x0 pfn:0x76e30 > flags: 0x8000(zone=2) > raw: 8000 0122 0001 > raw: > page dumped because: kasan: bad access detected > > Memory state around the buggy address: > f000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > f080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> f100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 >^ > f180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 > f1000100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 > == > Disabling lock debugging due to kernel taint > > > Kernel .config and full dmesg attached. The other 2 warnings in the dmesg, > "workqueue: work disable count underflowed" are > https://lore.kernel.org/all/ca+g9fysqmft3m1j0ugfwgjjci8mqob7bncmhbr175pabxx9...@mail.gmail.com/ > (offending commit should be reverted in next -rc) and "Missing > '#size-cells'" is fixed by > https://lore.kernel.org/all/87jzbqpnd9@mpe.ellerman.id.au/ (not yet > merged) > > Regards, > Erhard
Re: [PATCH 16/19] powerpc: dts: Add LANCOM NWAPP2 board devicetree
On Fri, Jan 10, 2025 at 04:24:27PM +0100, Krzysztof Kozlowski wrote: > On 02/01/2025 19:31, J. Neuschäfer via B4 Relay wrote: [...] > > + compatible = "lancom,nwapp2", "fsl,mpc8314e"; > > Missing bindings. Please run scripts/checkpatch.pl and fix reported > warnings. After that, run also `scripts/checkpatch.pl --strict` and > (probably) fix more warnings. Some warnings can be ignored, especially > from --strict run, but the code here looks like it needs a fix. Feel > free to get in touch if the warning is not clear. I'm currently aiming for 5-10 converted/new bindings in YAML format. Should I rather put them into a separate series, or include them in this one? Best regards, J. Neuschäfer
Re: [PATCH] tools/perf/tests: Update event_groups test to use instructions as one of the sibling event for hw type
Hi Athira, On 10-Jan-25 3:16 PM, Athira Rajeev wrote: > In some of the powerpc platforms, event group testcase fails as below: > ># perf test -v 'Event groups' >69: Event groups: >--- start --- >test child forked, pid 9765 >Using CPUID 0x00820200 >Using hv_24x7 for uncore pmu event >0x0 0x0, 0x0 0x0, 0x0 0x0: Fail >0x0 0x0, 0x0 0x0, 0x1 0x3: Pass > > The testcase creates various combinations of hw, sw and uncore > PMU events and verify group creation succeeds or fails as expected. > This tests one of the limitation in perf where it doesn't allow > creating a group of events from different hw PMUs. > > The testcase starts a leader event and opens two sibling events. > The combination the fails is three hardware events in a group. > "0x0 0x0, 0x0 0x0, 0x0 0x0: Fail" > > Type zero and config zero which translates to PERF_TYPE_HARDWARE > and PERF_COUNT_HW_CPU_CYCLE. There is event constraint in powerpc > that events using same counter cannot be programmed in a group. > Here there is one alternative event for cycles, hence one leader > and only one sibling event can go in as a group. For power9, cycles seems to map to PM_CYC event: GENERIC_EVENT_ATTR(cpu-cycles, PM_CYC); However, I don't see PM_CYC in power9_event_alternatives[]. Is PM_RUN_CYC and PM_CYC are same? Thanks, Ravi
