public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
* newer kernel+systemtap & nfs.fop.open
@ 2022-03-10 19:58 Daire Byrne
  2022-04-01 12:26 ` Daire Byrne
  0 siblings, 1 reply; 7+ messages in thread
From: Daire Byrne @ 2022-03-10 19:58 UTC (permalink / raw)
  To: systemtap

Hi,

Bit of a newbie question, but I'm trying to port some older code to a
newer version of systemtap (4.7pre) and I'm seeing a change in
behaviour in the output of this:

stap -e 'probe nfs.fop.open { filename = sprintf("%s",
d_path(&$filp->f_path)); printf("filename: %s\n", filename)}'

On previous versions (RHEL7, stap v4.1), the resulting filename had
the full path including the mounted directory path or autompunt path,
But on newer version of the kernel and systemtap, it seems like only
the file path after the NFS mountpoint is being printed.

Is there some other trick now required with the
d_path((&$filp->f_path)) to include the NFS mountpoint location and
provide the full path?

Many thanks,

Daire

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: newer kernel+systemtap & nfs.fop.open
  2022-03-10 19:58 newer kernel+systemtap & nfs.fop.open Daire Byrne
@ 2022-04-01 12:26 ` Daire Byrne
  2022-04-01 14:05   ` David Smith
  2022-04-01 14:55   ` Serhei Makarov
  0 siblings, 2 replies; 7+ messages in thread
From: Daire Byrne @ 2022-04-01 12:26 UTC (permalink / raw)
  To: systemtap

Hi,

Is anyone able to point me in the right direction or is there a better
forum for asking these kinds of questions?

Cheers,

Daire

On Thu, 10 Mar 2022 at 19:58, Daire Byrne <daire@dneg.com> wrote:

> Hi,
>
> Bit of a newbie question, but I'm trying to port some older code to a
> newer version of systemtap (4.7pre) and I'm seeing a change in
> behaviour in the output of this:
>
> stap -e 'probe nfs.fop.open { filename = sprintf("%s",
> d_path(&$filp->f_path)); printf("filename: %s\n", filename)}'
>
> On previous versions (RHEL7, stap v4.1), the resulting filename had
> the full path including the mounted directory path or autompunt path,
> But on newer version of the kernel and systemtap, it seems like only
> the file path after the NFS mountpoint is being printed.
>
> Is there some other trick now required with the
> d_path((&$filp->f_path)) to include the NFS mountpoint location and
> provide the full path?
>
> Many thanks,
>
> Daire
>

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: newer kernel+systemtap & nfs.fop.open
  2022-04-01 12:26 ` Daire Byrne
@ 2022-04-01 14:05   ` David Smith
  2022-04-01 14:55   ` Serhei Makarov
  1 sibling, 0 replies; 7+ messages in thread
From: David Smith @ 2022-04-01 14:05 UTC (permalink / raw)
  To: Daire Byrne; +Cc: systemtap

Daire,

I'll take a stab at answering this. First off, note that systemtap hasn't
changed in this area, the underlying kernel has. That said, I might try
this (completely untested):

    stap -e 'probe nfs.fop.open { filename =
fullpath_struct_file(task_current(), $filp); printf("filename: %s\n",
filename)}'


On Fri, Apr 1, 2022 at 8:27 AM Daire Byrne via Systemtap <
systemtap@sourceware.org> wrote:

> Hi,
>
> Is anyone able to point me in the right direction or is there a better
> forum for asking these kinds of questions?
>
> Cheers,
>
> Daire
>
> On Thu, 10 Mar 2022 at 19:58, Daire Byrne <daire@dneg.com> wrote:
>
> > Hi,
> >
> > Bit of a newbie question, but I'm trying to port some older code to a
> > newer version of systemtap (4.7pre) and I'm seeing a change in
> > behaviour in the output of this:
> >
> > stap -e 'probe nfs.fop.open { filename = sprintf("%s",
> > d_path(&$filp->f_path)); printf("filename: %s\n", filename)}'
> >
> > On previous versions (RHEL7, stap v4.1), the resulting filename had
> > the full path including the mounted directory path or autompunt path,
> > But on newer version of the kernel and systemtap, it seems like only
> > the file path after the NFS mountpoint is being printed.
> >
> > Is there some other trick now required with the
> > d_path((&$filp->f_path)) to include the NFS mountpoint location and
> > provide the full path?
> >
> > Many thanks,
> >
> > Daire
> >
>
>

-- 

David Smith

Manager

Red Hat <https://www.redhat.com/>
<https://www.redhat.com/>

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: newer kernel+systemtap & nfs.fop.open
  2022-04-01 12:26 ` Daire Byrne
  2022-04-01 14:05   ` David Smith
@ 2022-04-01 14:55   ` Serhei Makarov
  2022-04-01 20:13     ` Serhei Makarov
  1 sibling, 1 reply; 7+ messages in thread
From: Serhei Makarov @ 2022-04-01 14:55 UTC (permalink / raw)
  To: Daire Byrne, systemtap



On Fri, Apr 1, 2022, at 8:26 AM, Daire Byrne via Systemtap wrote:
> Hi,
>
> Is anyone able to point me in the right direction or is there a better
> forum for asking these kinds of questions?
Hi, thank you for reporting this.
IRC oftc.net #systemtap may also be a good venue if you're
interested in partial answers quickly over full answers
at an unknown time.

Unfortunately since the kernel may change the same tapsets
can yield different results until they're fixed to match the
newer kernel too. They are generally coded to use
multiple fallbacks, so if only part of the information is in the same
place the d_name() function would yield just the name
instead of "<unknown>".

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.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: newer kernel+systemtap & nfs.fop.open
  2022-04-01 14:55   ` Serhei Makarov
@ 2022-04-01 20:13     ` Serhei Makarov
  2022-04-04 11:21       ` Daire Byrne
  0 siblings, 1 reply; 7+ messages in thread
From: Serhei Makarov @ 2022-04-01 20:13 UTC (permalink / raw)
  To: Daire Byrne, systemtap



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.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: newer kernel+systemtap & nfs.fop.open
  2022-04-01 20:13     ` Serhei Makarov
@ 2022-04-04 11:21       ` Daire Byrne
  2022-04-04 12:28         ` Daire Byrne
  0 siblings, 1 reply; 7+ messages in thread
From: Daire Byrne @ 2022-04-04 11:21 UTC (permalink / raw)
  To: Serhei Makarov; +Cc: systemtap

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 <me@serhei.io> 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.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: newer kernel+systemtap & nfs.fop.open
  2022-04-04 11:21       ` Daire Byrne
@ 2022-04-04 12:28         ` Daire Byrne
  0 siblings, 0 replies; 7+ messages in thread
From: Daire Byrne @ 2022-04-04 12:28 UTC (permalink / raw)
  To: Serhei Makarov; +Cc: systemtap

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 <daire@dneg.com> 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 <me@serhei.io> 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.

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2022-04-04 12:29 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-03-10 19:58 newer kernel+systemtap & nfs.fop.open Daire Byrne
2022-04-01 12:26 ` Daire Byrne
2022-04-01 14:05   ` David Smith
2022-04-01 14:55   ` Serhei Makarov
2022-04-01 20:13     ` Serhei Makarov
2022-04-04 11:21       ` Daire Byrne
2022-04-04 12:28         ` Daire Byrne

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).