From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 4E8303844072; Fri, 22 Jan 2021 04:26:06 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4E8303844072 From: "craig.ringer at 2ndquadrant dot com" To: systemtap@sourceware.org Subject: [Bug runtime/27224] New: stap 4.4 'cannot attach to module' in debugfs mode as non-root Date: Fri, 22 Jan 2021 04:26:06 +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: craig.ringer at 2ndquadrant dot com X-Bugzilla-Status: UNCONFIRMED 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 X-BeenThere: systemtap@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Systemtap mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2021 04:26:06 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D27224 Bug ID: 27224 Summary: stap 4.4 'cannot attach to module' in debugfs mode as non-root Product: systemtap Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: runtime Assignee: systemtap at sourceware dot org Reporter: craig.ringer at 2ndquadrant dot com Target Milestone: --- On Fedora 33 with kernel 5.9.16-200.fc33.x86_64 and stap 4.4/0.182, rpm 4.4-2.fc33 I noticed that staprun can't seem to attach to module I/O anymor= e. It fails with ERROR: Cannot attach to module stap_nnn control channel; not running? ERROR: 'stap_nnn' is not a zombie systemtap module. The issue arises with no explicit transport selection or with -DSTAP_TRANS_DEBUGFS explicitly requested. This has also been reported by a colleague on Debian who is using "Systemtap translator/driver (version 4.4/0.176, Debian version 4.4-1~bpo10+1 (buster-backports))" Running stap with sudo has no effect. WORKAROUND =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 I have been able to work around the error with: sudo mount /sys/kernel/debug -o remount,mode=3D755 DETAIL =3D=3D=3D=3D=3D=3D I found the above info the ancient Debian bug report https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D706817 from 2013, and it references a 2012 Linux kernel patch http://lkml.iu.edu/hypermail/linux/kernel/1201.3/00626.html . Also https://github.com/torvalds/linux/commit/82aceae4f0d42f03d9ad7d1e90389e7311= 53898f . But remounting debugfs solves this issue despite the last relevant changes I can find related to debugfs being 7 or 8 years old. It might be related to the changes in systemtap intended to work around the kernel lockdown issues and add procfs transport support, per https://bugzilla.redhat.com/show_bug.cgi?id=3D1873492 in commit 7615cae79 ? Running with -DSTAP_TRANS_PROCFS output instead works, but only when stap itself is run as root, even though staprun is setuid root. Unclear why, per= haps a separate issue. I don't see the same problem when running on a self-compiled version of git master @ HEAD =3D d7ea535c6 but I don't yet know if that's due to differenc= es in configuration and installation for packages vs source builds, or whether it= 's down to a code change since the 4.4 release. I'll compile 4.4 to see. Sample output for various runs is attached. --=20 You are receiving this mail because: You are the assignee for the bug.=