From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 0DFF83858D33; Fri, 17 Nov 2023 17:13:54 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0DFF83858D33 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1700241234; bh=WU7DLAvcDyKT6/rXm0NQ/+dYwbH2TEgNsxAmHcNzEwM=; h=From:To:Subject:Date:From; b=WnGHsAoaPGH58V5sBSJrG8RhizalHFzXL5VShspkayYTlD3Y0PCv4Ld+rGq/E/sTH czthzhrqWWrvfkjtIYZb0N1gNa1Ktlc6a3/+aGpToXU4RBK1169soa5W70wmHUu92Q yhXPvjJtUYMgjpl/R9JCezWrvGq9Le88mfWIrAMg= From: "wcohen at redhat dot com" To: systemtap@sourceware.org Subject: [Bug runtime/31074] New: On aarch64 the systemtap.base/set_kernel.stp triggers "Unable to handle kernel paging request" Date: Fri, 17 Nov 2023 17:13:52 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: systemtap X-Bugzilla-Component: runtime X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: wcohen at redhat dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: systemtap at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D31074 Bug ID: 31074 Summary: On aarch64 the systemtap.base/set_kernel.stp triggers "Unable to handle kernel paging request" Product: systemtap Version: unspecified Status: NEW Severity: normal Priority: P2 Component: runtime Assignee: systemtap at sourceware dot org Reporter: wcohen at redhat dot com Target Milestone: --- When attempting to run the systemtap tests on aarch64 fedora 39 the systemtap.base/set_kernel.stp has an "Unable to handle kernel access" when = the script is shutting down. On the machine have a git checkout of systemtap bu= ilt as an rpm and a recent f39 kernel: $ rpm -q systemtap kernel systemtap-5.0-1.202311152024.fc39.aarch64 kernel-6.5.11-300.fc39.aarch64 This can be demonstrated with on aarch64 machine with the following command= s: $ stap -k -p4 -mset_kernel -v -g set_kernel.stp $ sudo staprun set_kernel.ko -c "sleep 1" It may take a couple tries of staprun to trigger and get: [ 764.982599] Unable to handle kernel access to user memory outside uaccess routines at virtual address 0000000000000030 [ 764.993402] Mem abort info: [ 764.996253] ESR =3D 0x0000000096000004 [ 765.000063] EC =3D 0x25: DABT (current EL), IL =3D 32 bits [ 765.005419] SET =3D 0, FnV =3D 0 [ 765.008489] EA =3D 0, S1PTW =3D 0 [ 765.011636] FSC =3D 0x04: level 0 translation fault [ 765.016527] Data abort info: [ 765.019412] ISV =3D 0, ISS =3D 0x00000004, ISS2 =3D 0x00000000 [ 765.024895] CM =3D 0, WnR =3D 0, TnD =3D 0, TagAccess =3D 0 [ 765.029959] GCS =3D 0, Overlay =3D 0, DirtyBit =3D 0, Xs =3D 0 [ 765.035284] user pgtable: 4k pages, 48-bit VAs, pgdp=3D0000000171423000 [ 765.041737] [0000000000000030] pgd=3D0000000000000000, p4d=3D00000000000= 00000 [ 765.048549] Internal error: Oops: 0000000096000004 [#1] SMP [ 765.054121] Modules linked in: set_kernel(OE) snd_seq_dummy snd_hrtimer nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inett [ 765.054381] usb_conn_gpio udc_core tegra_soctherm snd_timer videodev at= 24 snd vfat soundcore mc fat loop zram mmc_block onboard_use [ 765.144548] Unloaded tainted modules: set_kernel(OE):1 [last unloaded: set_kernel(OE)] [ 765.190112] CPU: 2 PID: 5917 Comm: stapio Tainted: G WC OE=20=20= =20=20=20 6.5.11-300.fc39.aarch64 #1 [ 765.198979] Hardware name: nvidia p3450-0000/p3450-0000, BIOS 2020.10 10/06/2020 [ 765.206365] pstate: 00400005 (nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE= =3D--) [ 765.213320] pc : __pi_strcmp+0xbc/0x140 [ 765.217173] lr : get_tracepoint+0x5c/0x80 [set_kernel] [ 765.222348] sp : ffff8000871c3a30 [ 765.225656] x29: ffff8000871c3a30 x28: ffff800082bcf850 x27: ffff80007c3ddc80 [ 765.232791] x26: ffff00008423d560 x25: dead000000000122 x24: dead000000000100 [ 765.239923] x23: 000000000000000b x22: ffff80007c3dd298 x21: ffff000089e41c20 [ 765.247055] x20: ffff80007be10610 x19: 0000000000000001 x18: 0000000000000000 [ 765.254189] x17: 000000040044ffff x16: 00500074b5503510 x15: 0000000000000000 [ 765.261321] x14: ffff00008035a200 x13: ffff80007c2db000 x12: ffff800082bcf6d8 [ 765.268452] x11: 0000000000000001 x10: 00007fff841efa21 x9 : fffffffffffffe78 [ 765.275583] x8 : 0101010101010101 x7 : 000000002ad85bff x6 : 0000000000000000 [ 765.282716] x5 : 676461675f627375 x4 : 0000000000000000 x3 : 0000000000000000 [ 765.289848] x2 : 00000000000000ea x1 : 0000000000000030 x0 : ffff80007be10610 [ 765.296984] Call trace: [ 765.299432] __pi_strcmp+0xbc/0x140 [ 765.302926] stp_tracepoint_notify+0x7c/0x248 [set_kernel] [ 765.308431] unregister_tracepoint_module_notifier+0x6c/0xa8 [ 765.314097] stp_tracepoint_exit+0x40/0xc8 [set_kernel] [ 765.319337] systemtap_module_exit+0x1bc/0x2f0 [set_kernel] [ 765.324922] _stp_cleanup_and_exit.part.0+0xe8/0x128 [set_kernel] [ 765.331025] _stp_ctl_write_cmd+0x184/0x4e8 [set_kernel] [ 765.336344] proc_reg_write+0xa4/0x100 [ 765.340104] vfs_write+0xd0/0x318 [ 765.343421] ksys_write+0x7c/0x120 [ 765.346823] __arm64_sys_write+0x24/0x38 [ 765.350743] invoke_syscall+0x78/0x100 [ 765.354493] el0_svc_common.constprop.0+0x4c/0xf8 [ 765.359191] do_el0_svc+0x34/0x50 [ 765.362502] el0_svc+0x34/0x108 [ 765.365650] el0t_64_sync_handler+0x120/0x130 [ 765.370003] el0t_64_sync+0x194/0x198 [ 765.373673] Code: f240081f 54ffff41 cb010fe9 927df021 (f8408427) [ 765.379763] ---[ end trace 0000000000000000 ]--- I suspect that some how the buffer in get_buffer is overlapping other memory somehow. Doubling the buffersize, but limiting the memset to MAXTRINGLEN s= eems to eliminate problem. --=20 You are receiving this mail because: You are the assignee for the bug.=