From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) by sourceware.org (Postfix) with ESMTPS id 0603F3858D1E for ; Mon, 4 Apr 2022 12:29:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0603F3858D1E Received: by mail-ed1-x530.google.com with SMTP id b24so10827444edu.10 for ; Mon, 04 Apr 2022 05:28:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sc6sPGA7jFB0N94MT0nZ4Q43g+VQ8DhFuofeRXjpC+Q=; b=C7XyoRRayfNHoeRRdYhH7tyrVuqmGZLKrkDgjLl4DsIgNSL8BTjdXDYeUsJuM6S9nM N65OFwQUxx0pQaCNslQPCOEj+NN6KeYcBiH8Me9lTXXl8W212XfimrTJZFEON73hJ1gE zLr16zixxPMyvyH3qivPQQOx44+1yFx99JJUVxpDbiu8h9Nttx0LT83u+cU35C3ijnKA 7ax6v1lNjzvk0ETFBJEXYgpPUEt10SKRh5oMwk69vTUOM3kyfOgXLTlMW2ikIN4L+YBV EAx7s4a8gV5oTXqLrW7cMROsd4EntpM9IOhUNgILi2hqIwF81Nd7n6Kiv3GA8Ixr9jhP 6Yeg== X-Gm-Message-State: AOAM531KLOJ2uhc6NtYGCUyLlSXgJ7Y7IBhhrIBDhLDzSKHFli/f717l rJbKSCFS4Jt5LVUeHGk/3cpSftgrYv2elrugmdM6H8B7QdtiqA== X-Google-Smtp-Source: ABdhPJybw+xZmVch15SuCjbbQrTonEARrp80svfmC/vCoCRC6cUiZ9c46fTm37FA1QjnhYgP/y3+ZImG14ldku8hI1Y= X-Received: by 2002:a05:6402:5111:b0:419:74a6:6dc0 with SMTP id m17-20020a056402511100b0041974a66dc0mr32936761edd.293.1649075338755; Mon, 04 Apr 2022 05:28:58 -0700 (PDT) MIME-Version: 1.0 References: <6a4c5961-df38-40d6-9491-1f5a587a3dbf@www.fastmail.com> <9adcadfd-e6ba-4c0b-8e64-892ec7173bac@www.fastmail.com> In-Reply-To: From: Daire Byrne Date: Mon, 4 Apr 2022 13:28:23 +0100 Message-ID: Subject: Re: newer kernel+systemtap & nfs.fop.open To: Serhei Makarov Cc: systemtap Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org 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: Mon, 04 Apr 2022 12:29:02 -0000 Okay, it looks like William Cohen's patches do indeed fix the issue - the fullpath is now being reported. I hadn't noticed those updates since I originally posted. Much obliged, Daire On Mon, 4 Apr 2022 at 12:21, Daire Byrne wrote: > > Serhei/David, > > Thanks for the suggestions and explanation. I get the same result with > "fullpath_struct_file(task_current(), $filp)" using the v5.16 kernel > and systemtap 4.7pre. > > As Serhei said, it seems like the mnt_parent is completely missing. > > But then I realised I had completely forgotten that I manually patched > systemtap according to this just so I could get my script to compile > at all: > > https://sourceware.org/bugzilla/show_bug.cgi?id=26184#c5 > > And now it also looks like a recent commit has been made to fix that > particular issue so I'll try to pull the latest systemtap and try > again. > > https://sourceware.org/git/?p=systemtap.git;a=commit;h=3739d47c4cc427ce4818d884f429a3efa85c38ae > > Daire > > > On Fri, 1 Apr 2022 at 21:13, Serhei Makarov wrote: > > > > > > > > On Fri, Apr 1, 2022, at 10:55 AM, Serhei Makarov wrote: > > > In this case the last commit > > > to tapsets/linux/dentry.stp was in 2020 > > > so it looks like we may have some catching up to the kernel > > > to do. I'll investigate more (i.e. delve into kernel git history) > > > and get back to you. > > I'm got a 'read fault' running your example on Fedora 5.15.4-201.fc35.x86_64, > > which indicates even further divergence later on. > > Which kernel version were you running the example on? > > > > Looks like "struct mount" no longer defines the "mnt_parent" member > > used by task_dentry_path() tapset function in /usr/share/systemtap/tapset/linux/dentry.stp > > which is strange as the upstream Linux kernel code still uses that member > > in the equivalent fs/d_path.c __prepend_path code. > > > > sutap -ve 'probe begin { if (@type_member_defined("mount", mnt_parent)) { print("foo") } else { print("bar") } exit() }' > > > > Very strange, as even checking the debugsource doesn't show any downstream changes > > as found by > > > > $ debuginfod-find source /boot/vmlinuz-5.15.4-201.fc35.x86_64 /usr/src/debug/kernel-5.15.4/linux-5.15.4-201.fc35.x86_64/fs/d_path.c > > > > I'm also confused and will continue investigating until I become unconfused.