Bug 1721779

Hello,
just collecting "bpftool net list" is required? No need to iterate over devices from the list output and collect "bpftool net show <device>" ?

In case the net show is also required, can I assume each line from "bpftool net list" that is not blank and not "xdp:" and not "tc:" contains device name before the very first "(" (or provide a different precise specification how to generate list of such devices)?

Thanks for clarification.

(In reply to Pavel Moravec from comment #1)
> Hello,
> just collecting "bpftool net list" is required? No need to iterate over
> devices from the list output and collect "bpftool net show <device>" ?

No, I think just "bpftool net list" is enough. there is no more detail for "bpftool net show <device>".

Hi Jiri, what do you think?

Yes, "bpftool net list" is enough.

Thx for clarification.

devel_ack+ to 8.2, upstream PR raised.

Hi,
can I expect with OtherQE verification here as well, please?

(In reply to Pavel Moravec from comment #6)
> Hi,
> can I expect with OtherQE verification here as well, please?

Do we have a test package now?

Thanks
Hangbin

(In reply to Hangbin Liu from comment #7)
> (In reply to Pavel Moravec from comment #6)
> > Hi,
> > can I expect with OtherQE verification here as well, please?
> 
> Do we have a test package now?
> 
> Thanks
> Hangbin

Not yet. The bureaucratic logic is qa_ack+ (where OtherQA helps) => pm_ack+/release+ => I can put to dist-git => I can build a package.

So far, a 8.2 sos candidate build 3.8-1 is without this fix. I plan a re-spin probably in mid Jan.

Hmm, isn't this a duplicate of bug 1768956 (or vice versa)? Sorry for that, I completely forgot we have this bug open.

The description of this bug made me realize that we're not capturing 'bpftool cgroup tree' output. I guess I should file a separate bug report/RFE for that, right?

(In reply to Jiri Benc from comment #9)
> Hmm, isn't this a duplicate of bug 1768956 (or vice versa)? Sorry for that,
> I completely forgot we have this bug open.

This BZ is for collecting "bpftool net list" itself, while bug 1768956 requests to collect the same per each namespace.


> 
> The description of this bug made me realize that we're not capturing
> 'bpftool cgroup tree' output. I guess I should file a separate bug
> report/RFE for that, right?

A new BZ is preferred. On RHEL7 or 8 or both? Just this command "system wide" or also per namespace?

(In reply to Pavel Moravec from comment #12)
> A new BZ is preferred.

Filed bug 1787586.

> On RHEL7 or 8 or both?

RHEL 8 only, this is not available on RHEL 7.

> Just this command "system wide" or also per namespace?

System wide. Added this info to the newly filed bug, too.

Thanks!

(In reply to Hangbin Liu from comment #7)
> (In reply to Pavel Moravec from comment #6)
> > Hi,
> > can I expect with OtherQE verification here as well, please?
> 
> Do we have a test package now?
> 
> Thanks
> Hangbin

Now we have :) Could you please verify the bugfix against below package? Thanks in advance.


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

http://brew-task-repos.usersys.redhat.com/repos/official/sos/3.8/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/3.8/2.el8/sos-3.8-2.el8.repo

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

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

Build output will be available for the next 21 days.

Hi Pavel,

Thanks for the package, here is the test result:

# rpm -q sos
sos-3.8-2.el8.noarch

# cat sos_commands/networking/bpftool_net_list
xdp:
test(6) driver id 68

tc:
test(6) clsact/ingress xdp_pass_kern.o:[xdp] id 65
test(6) clsact/ingress xdp_pass_kern.o:[xdp] id 64

flow_dissector:

# cat sos_commands/networking/ip_netns_exec_test_bpftool_net_list
xdp:
veth0(5) driver id 69

tc:

flow_dissector:

I ran a few kselftests, seems to work okay for xdp, tc and flow_dissector:

$ for f in sosreport-*/sos_commands/networking/*bpftool_net*; do echo $f; cat $f; done
sosreport-localhost-2-2020-01-16-inqeubt/sos_commands/networking/bpftool_net_list
xdp:

tc:

flow_dissector:

sosreport-localhost-2-2020-01-16-inqeubt/sos_commands/networking/ip_netns_exec_ns-vePDNH_bpftool_net_list
xdp:

tc:

flow_dissector:
id 4
sosreport-localhost-5-2020-01-16-hgmfhcn/sos_commands/networking/bpftool_net_list
xdp:
veth1(7) generic id 74

tc:

flow_dissector:

sosreport-localhost-5-2020-01-16-hgmfhcn/sos_commands/networking/ip_netns_exec_xdp_ns0_bpftool_net_list
xdp:
veth0(8) generic id 70

tc:

flow_dissector:

sosreport-localhost-6-2020-01-16-ivlznto/sos_commands/networking/bpftool_net_list
xdp:

tc:

flow_dissector:

sosreport-localhost-6-2020-01-16-ivlznto/sos_commands/networking/ip_netns_exec_ns-970-1_bpftool_net_list
xdp:

tc:
veth1(3) clsact/egress test_tc_tunnel.o:[encap_ip6tnl_none] id 3

flow_dissector:

sosreport-localhost-6-2020-01-16-ivlznto/sos_commands/networking/ip_netns_exec_ns-970-2_bpftool_net_list
xdp:

tc:

flow_dissector:

One thing I noticed: there's no sos_commands/kernel/bpftool_prog_list and sos_commands/kernel/bpftool_map_list, only the json (-j) versions are there. While the json files should be used by sos itself to parse the program and map ids, it's not the ideal output for an engineer looking at the report, as it's not easily human consumable. Shouldn't both version (-j and non-j) be captured? It's not urgent, both contain the same data and with the help of json_reformat it is kind of workable but it doesn't seem ideal. What do you think?

To illustrate that on a simple example (only one program loaded):

[root@localhost ~]# bpftool prog list
3: sched_cls  tag dd562a23ff170aab  gpl
        loaded_at 2020-01-16T20:36:45+0100  uid 0
        xlated 520B  jited 328B  memlock 4096B
[root@localhost ~]# bpftool prog -j list
[{"id":3,"type":"sched_cls","tag":"dd562a23ff170aab","gpl_compatible":true,"loaded_at":1579203405,"uid":0,"bytes_xlated":520,"jited":true,"bytes_jited":328,"bytes_memlock":4096}]

Good point (that revealed a regression just in upstream :) ), I raised https://github.com/sosreport/sos/pull/1923

Until somebody disagrees, we will:
- collect just JSON format in 8.2
- fix the upstream regression (map/prog missing in either format in stored data, info available indirectly only via individual maps/progs)
- collect both JSON and human readable data since 8.3

(In reply to Pavel Moravec from comment #19)
> Until somebody disagrees, we will:
> - collect just JSON format in 8.2
> - fix the upstream regression (map/prog missing in either format in stored
> data, info available indirectly only via individual maps/progs)
> - collect both JSON and human readable data since 8.3

Sounds good to me, thanks a lot for taking care of this!

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, 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-2020:1900