Hello Yauheni. Is there a pull request already upstream?

(In reply to Jose Castillo from comment #1)
> Hello Yauheni. Is there a pull request already upstream?

I, actually, do not know. This requirement came from review of bpf patchset to RHEL8.

I don't think there is. If you don't have a capacity for writing an upstream patch, we can submit one, it's no problem, it should be rather easy. We have enough time for that, the target is RHEL 8.4 (as it's too late for RHEL 8.3 at this point).

(In reply to Jiri Benc from comment #3)
> I don't think there is. If you don't have a capacity for writing an upstream
> patch, we can submit one, it's no problem, it should be rather easy. We have
> enough time for that, the target is RHEL 8.4 (as it's too late for RHEL 8.3
> at this point).

I'll write it then, I just need to finish another one today and will start with it after it.

Done via https://github.com/sosreport/sos/pull/2116 . Check it when you have a minute, in case I missed anything.

That was fast! It looks good to me.

We'll want to test it, I based the command line on bpftool patch review; I've still not finished my review of the bpf kernel and bpftool rebase and haven't had an opportunity to try executing the command, yet. I now checked again the bpftool patch and the bpftool man page and this should be indeed the command to run. A real test is a real test, though.

Agreed, we need to test the patch. I don't know too much about bpftool so I'll need your help to test it. Can I try it in a Fedora VM?

(In reply to Jose Castillo from comment #7)
> Agreed, we need to test the patch. I don't know too much about bpftool so
> I'll need your help to test it. Can I try it in a Fedora VM?

You'll need a kernel v5.7 or newer. To verify that the command indeed dumps the structs, you'll need a tcp_congestion_ops bpf program loaded; there is one in the kernel source tree but I'm not sure Fedora builds it. 'bpftool struct_ops register bpf_cubic.o' is the command to load it in case it does.

I'll verify the command if you're not in hurry - I will get to that only next week, I'm afraid.

Hello,
can you please verify the bug against below build (not sure if our QE will have capacity to verify by themselves)? Thanks in advance.


A yum repository for the build of sos-4.0-2.el8 (task 32548242) is available at:

http://brew-task-repos.usersys.redhat.com/repos/official/sos/4.0/2.el8/

You can install the rpms locally by putting this .repo file in your /etc/yum.repos.d/ directory:

http://brew-task-repos.usersys.redhat.com/repos/official/sos/4.0/2.el8/sos-4.0-2.el8.repo

RPMs and build logs can be found in the following locations:
http://brew-task-repos.usersys.redhat.com/repos/official/sos/4.0/2.el8/noarch/

The full list of available rpms is:
http://brew-task-repos.usersys.redhat.com/repos/official/sos/4.0/2.el8/noarch/sos-4.0-2.el8.src.rpm
http://brew-task-repos.usersys.redhat.com/repos/official/sos/4.0/2.el8/noarch/sos-4.0-2.el8.noarch.rpm
http://brew-task-repos.usersys.redhat.com/repos/official/sos/4.0/2.el8/noarch/sos-audit-4.0-2.el8.noarch.rpm

The repository will be available for the next 60 days. Scratch build output will be deleted
earlier, based on the Brew scratch build retention policy.

Huh, if I knew how :) I'll try, thanks.

(In reply to Yauheni Kaliuta from comment #12)
> Huh, if I knew how :) I'll try, thanks.

Very brief check:

# rpm -q sos
sos-4.0-2.el8.noarch
# sos report -o ebpf --batch --build

sosreport (version 4.0)

WARNING: unable to set option for disabled or non-existing plugin (apache)

This command will collect diagnostic and configuration information from
this Red Hat Enterprise Linux system and installed applications.

An archive containing the collected information will be generated in
/var/tmp/sos.np2zgfza and may be provided to a Red Hat support
representative.

Any information provided to Red Hat will be treated in accordance with
the published support policies at:

  https://access.redhat.com/support/

The generated archive may contain data considered sensitive and its
content should be reviewed by the originating organization before being
passed to any third party.

No changes will be made to system configuration.


 Setting up archive ...
 Setting up plugins ...
 Running plugins. Please wait ...

  Starting 1/1   ebpf            [Running: ebpf]

  Finished running plugins


Your sosreport build tree has been generated in:
	/var/tmp/sosreport-pmoravec-rhel8-2020-10-29-wuhklug


# find /var/tmp/sosreport-pmoravec-rhel8-2020-10-29-wuhklug | grep struct
/var/tmp/sosreport-pmoravec-rhel8-2020-10-29-wuhklug/sos_commands/ebpf/bpftool_struct_ops_dump
# cat /var/tmp/sosreport-pmoravec-rhel8-2020-10-29-wuhklug/sos_commands/ebpf/bpftool_struct_ops_dump
Usage: bpftool [OPTIONS] OBJECT { COMMAND | help }
       bpftool batch file FILE
       bpftool version

       OBJECT := { prog | map | cgroup | perf | net | feature | btf }
       OPTIONS := { {-j|--json} [{-p|--pretty}] | {-f|--bpffs} |
	            {-m|--mapcompat} | {-n|--nomount} }
#


So the command is collected, but bpftool (latest released version 4.18.0-193.28.1.el8_2) does not know that subcommand..?

OK, newer bpftool (bpftool-4.18.0-240.8.el8.x86_64) does know that subcommand:

# cat /var/tmp/sosreport-pmoravec-rhel8-2020-10-29-exhwfgh/sos_commands/ebpf/bpftool_struct_ops_dump
libbpf: failed to find valid kernel BTF
Error: struct_ops requires kernel CONFIG_DEBUG_INFO_BTF=y
#

(then it is rather kernel/config issue that the cmd output is fruitless - output is OK from sos perspective).

# rpm -q sos
sos-4.0-2.el8.noarch
# cat /var/tmp/sosreport-ykaliuta-rhel8-2020-10-29-hqebtir/sos_commands/ebpf/bpftool_struct_ops_dump
[]

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (sos bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2021:1604