On 10/02/2023 21:55, Anna Schumaker wrote: > Hi Krzysztof, > > On Fri, Feb 10, 2023 at 3:53 AM Krzysztof Kozlowski > <krzysztof.kozlowski@xxxxxxxxxx> wrote: >> >> On 10/02/2023 09:41, Krzysztof Kozlowski wrote: >>> >>> >>>> >>>> I was also wondering if it would be possible to turn on KASAN in your >>>> kernel, which should give us a little more info? >>> >>> I'll try with KASAN. >> >> Not much from the KASAN, except that kernel >> continues to boot and runs: >> >> [ 44.722846] vdd_vmem: disabling >> [ 44.793465] systemd[1]: Hostname set to <odroidhc1>. >> [ 45.357929] systemd[1]: bpf-lsm: BPF LSM hook not enabled in the kernel, BPF LSM not supported >> [ 45.980476] ================================================================== >> [ 45.986372] BUG: KASAN: null-ptr-deref in xdr_inline_decode+0x140/0x200 >> [ 45.992929] Read of size 4092 at addr 00000004 by task kworker/u16:3/71 >> [ 45.999513] >> [ 46.000940] CPU: 6 PID: 71 Comm: kworker/u16:3 Not tainted 6.2.0-rc7-00018-g0983f6bf2bfc #222 >> [ 46.009504] Hardware name: Samsung Exynos (Flattened Device Tree) >> [ 46.015542] Workqueue: rpciod rpc_async_schedule >> [ 46.020123] unwind_backtrace from show_stack+0x10/0x14 >> [ 46.025323] show_stack from dump_stack_lvl+0x58/0x70 >> [ 46.030301] dump_stack_lvl from kasan_report+0xa8/0xe0 >> [ 46.035501] kasan_report from kasan_check_range+0x94/0x1a0 >> [ 46.041048] kasan_check_range from memcpy+0x28/0x68 >> [ 46.045985] memcpy from xdr_inline_decode+0x140/0x200 >> [ 46.051098] xdr_inline_decode from nfs4_xdr_dec_read_plus+0x298/0x5b8 >> [ 46.057602] nfs4_xdr_dec_read_plus from call_decode+0x39c/0x530 >> [ 46.063581] call_decode from __rpc_execute+0x1f4/0xc5c >> [ 46.068776] __rpc_execute from rpc_async_schedule+0x2c/0x4c >> [ 46.074411] rpc_async_schedule from process_one_work+0x51c/0xc44 >> [ 46.080478] process_one_work from worker_thread+0x9c/0x7c0 >> [ 46.086022] worker_thread from kthread+0x16c/0x1b8 >> [ 46.090872] kthread from ret_from_fork+0x14/0x2c >> [ 46.095550] Exception stack(0xf0ba3fb0 to 0xf0ba3ff8) >> [ 46.100580] 3fa0: 00000000 00000000 00000000 00000000 >> [ 46.108740] 3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 >> [ 46.116885] 3fe0: 00000000 00000000 00000000 00000000 00000013 00000000 >> [ 46.123461] ================================================================== >> [ 46.130774] Disabling lock debugging due to kernel taint >> [ 50.848579] systemd[1]: Queued start job for default target Graphical Interface. >> [ 50.877068] systemd[1]: Created slice Slice /system/getty. >> >> >> Decoded stacktrace is (this is master branch): >> >> [ 46.020123] unwind_backtrace from show_stack (arch/arm/kernel/traps.c:258) >> [ 46.025323] show_stack from dump_stack_lvl (lib/dump_stack.c:107 (discriminator 4)) >> [ 46.030301] dump_stack_lvl from kasan_report (mm/kasan/report.c:184 mm/kasan/report.c:519) >> [ 46.035501] kasan_report from kasan_check_range (mm/kasan/generic.c:173 mm/kasan/generic.c:189) >> [ 46.041048] kasan_check_range from memcpy (mm/kasan/shadow.c:65) >> [ 46.045985] memcpy from xdr_inline_decode (net/sunrpc/xdr.c:1419 net/sunrpc/xdr.c:1454) > > Actually, this part is really useful. net/sunrpc/xdr.c:1419 points to > the memcpy in xdr_copy_to_scratch(), which has me wondering if I'm > incorrectly setting up the xdr scratch buffer that READ_PLUS uses for > decoding. Can you try this patch and let me know if it helps? > > From ac2d6c501dbcdb306480edaee625b5496f1fb4f5 Mon Sep 17 00:00:00 2001 > From: Anna Schumaker <Anna.Schumaker@xxxxxxxxxx> > Date: Fri, 10 Feb 2023 15:50:22 -0500 > Subject: [PATCH] NFSv4.2: Rework scratch handling for READ_PLUS > Patch is corrupted - maybe mail program reformatted it when sending: Applying: NFSv4.2: Rework scratch handling for READ_PLUS error: corrupt patch at line 12 Patch failed at 0001 NFSv4.2: Rework scratch handling for READ_PLUS Best regards, Krzysztof
