[Bug bpf/24639] New: "next" statement not recognized by stap bpf backend

[Bug bpf/24639] New: "next" statement not recognized by stap bpf backend

[wcohen at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=24639

            Bug ID: 24639
           Summary: "next" statement not recognized by stap bpf backend
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: bpf
          Assignee: systemtap at sourceware dot org
          Reporter: wcohen at redhat dot com
  Target Milestone: ---

The bpf backend doesn't understand next statement

[wcohen@fedora30 systemtap]$ sudo ../install/bin/stap --bpf  -e 'probe
kernel.trace("mm_filemap_*") {if (tid()!=pid()) next}' -T 1
[sudo] password for wcohen: 
semantic error: unhandled statement or expression type: keyword at <input>:1:55
        source: probe kernel.trace("mm_filemap_*") {if (tid()!=pid()) next}
                                                                      ^

Pass 4: compilation failed.  [man error::pass4]

However the tradtional backend does work:

[wcohen@fedora30 systemtap]$ sudo ../install/bin/stap -e 'probe
kernel.trace("mm_filemap_*") {if (tid()!=pid()) next}' -T 1
wcohen@fedora30 systemtap]$

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug bpf/24639] "next" statement not recognized by stap bpf backend

[me at serhei dot io]

https://sourceware.org/bugzilla/show_bug.cgi?id=24639

Serhei Makarov <me at serhei dot io> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |me at serhei dot io

--- Comment #1 from Serhei Makarov <me at serhei dot io> ---
Implementing next statement for probes should not be difficult. The other
behaviour is for overloaded functions, which are currently not supported by the
bpf backend.

Pushed a rudimentary implementation in patch
https://sourceware.org/git/gitweb.cgi?p=systemtap.git;a=commitdiff;h=d7679e5526832d70f435a58004a211d35818bf36

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug bpf/24639] "next" statement not recognized by stap bpf backend

[wcohen at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=24639

--- Comment #2 from William Cohen <wcohen at redhat dot com> ---
The bpf back is recognizing the next statement in probes, but the tests fail:

$ ../install/bin/stap --bpf testsuite/systemtap.bpf/bpf_tests/next.stp 
BEGIN
END FAIL

Looks like there is a problem with if statements code generation:

$ ../install/bin/stap --bpf -e 'global a, b; probe init {a=10; b=10} probe
oneshot{if (a!=b) printf("!=\n") else printf("==\n")}'
==

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug bpf/24639] "next" statement not recognized by stap bpf backend

[wcohen at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=24639

--- Comment #3 from William Cohen <wcohen at redhat dot com> ---
Created attachment 11817
  --> https://sourceware.org/bugzilla/attachment.cgi?id=11817&action=edit
next.stp with diagnostic prints.

ignore the previous -e example.  that isn't reproducing the problem.

It looks like changes in the values made by the kernel.function("vfs_read")
probes are not seen in the probe end. Put in the diagnostic printf in the
probes to better see what is going on.

[wcohen@localhost systemtap]$ ../install/bin/stap --bpf next.stp
BEGIN
vfs_read
value 2
status 0
end
value 2
status 2
END FAIL
[wcohen@localhost systemtap]$ ../install/bin/stap --bpf next.stp
BEGIN
vfs_read
value 0
status 0
end
value 2
status 2
END FAIL

--- Comment #4 from William Cohen <wcohen at redhat dot com> ---
Created attachment 11818
  --> https://sourceware.org/bugzilla/attachment.cgi?id=11818&action=edit
next.stp with diagnostic prints.

ignore the previous -e example.  that isn't reproducing the problem.

It looks like changes in the values made by the kernel.function("vfs_read")
probes are not seen in the probe end. Put in the diagnostic printf in the
probes to better see what is going on.

[wcohen@localhost systemtap]$ ../install/bin/stap --bpf next.stp
BEGIN
vfs_read
value 2
status 0
end
value 2
status 2
END FAIL
[wcohen@localhost systemtap]$ ../install/bin/stap --bpf next.stp
BEGIN
vfs_read
value 0
status 0
end
value 2
status 2
END FAIL

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug bpf/24639] "next" statement not recognized by stap bpf backend

[wcohen at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=24639

--- Comment #3 from William Cohen <wcohen at redhat dot com> ---
Created attachment 11817
  --> https://sourceware.org/bugzilla/attachment.cgi?id=11817&action=edit
next.stp with diagnostic prints.

ignore the previous -e example.  that isn't reproducing the problem.

It looks like changes in the values made by the kernel.function("vfs_read")
probes are not seen in the probe end. Put in the diagnostic printf in the
probes to better see what is going on.

[wcohen@localhost systemtap]$ ../install/bin/stap --bpf next.stp
BEGIN
vfs_read
value 2
status 0
end
value 2
status 2
END FAIL
[wcohen@localhost systemtap]$ ../install/bin/stap --bpf next.stp
BEGIN
vfs_read
value 0
status 0
end
value 2
status 2
END FAIL

--- Comment #4 from William Cohen <wcohen at redhat dot com> ---
Created attachment 11818
  --> https://sourceware.org/bugzilla/attachment.cgi?id=11818&action=edit
next.stp with diagnostic prints.

ignore the previous -e example.  that isn't reproducing the problem.

It looks like changes in the values made by the kernel.function("vfs_read")
probes are not seen in the probe end. Put in the diagnostic printf in the
probes to better see what is going on.

[wcohen@localhost systemtap]$ ../install/bin/stap --bpf next.stp
BEGIN
vfs_read
value 2
status 0
end
value 2
status 2
END FAIL
[wcohen@localhost systemtap]$ ../install/bin/stap --bpf next.stp
BEGIN
vfs_read
value 0
status 0
end
value 2
status 2
END FAIL

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug bpf/24639] "next" statement not recognized by stap bpf backend

[me at serhei dot io]

https://sourceware.org/bugzilla/show_bug.cgi?id=24639

--- Comment #5 from Serhei Makarov <me at serhei dot io> ---
Weird, since it passes consistently on earlier 4.18.0 kernel. To me that trace
looks like something went wrong writing to the global variable map.

Which kernel version are you using on Fedora 30?

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug bpf/24639] "next" statement not recognized by stap bpf backend

[wcohen at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=24639

--- Comment #6 from William Cohen <wcohen at redhat dot com> ---
Due to the crashes with bpf on f30 fedora 5.1.x kernels. This was on a rawhide
machine:

$ uname -a
Linux localhost.localdomain 5.2.0-0.rc3.git0.1.fc31.x86_64 #1 SMP Mon Jun 3
13:27:29 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux


However, got same failure on f29:

$ uname -a
Linux fedora29 5.0.19-200.fc29.x86_64 #1 SMP Tue May 28 13:56:29 UTC 2019
x86_64 x86_64 x86_64 GNU/Linux
$ sudo ../install/bin/stap --bpf next.stp
BEGIN
vfs_read
value 2
status 0
end
value 2
status 2
END FAIL

Maybe there is some change in the kernel that is allowing for incoherent values
between kernel and user space.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug bpf/24639] "next" statement not recognized by stap bpf backend

[me at serhei dot io]

https://sourceware.org/bugzilla/show_bug.cgi?id=24639

Serhei Makarov <me at serhei dot io> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #7 from Serhei Makarov <me at serhei dot io> ---
It appears that the recent kernels introduces some timing issue between kernel-
and user-space map operations. Filing as stapbpf pr24659

Changing the second probe vfs_read to probe timer.s(2) would make the testcase
pass on new kernels as well as old ones. But let's keep next.stp as-is and use
it to test for pr24659 as well.

-- 
You are receiving this mail because:
You are the assignee for the bug.