01:17 <irker418> systemtap: scox systemtap.git:refs/heads/scox/https * release-3.2-103-g11cfa17 / systemtap.spec: Add undefine __brp_mangle_shebangs http://tinyurl.com/ycjyk55p

01:17 <irker418> systemtap: scox systemtap.git:refs/heads/scox/https * release-3.2-106-g913080c / : Merge branch 'master' of ssh://sourceware.org/git/systemtap http://tinyurl.com/y8o53at8

01:17 <irker418> systemtap: scox systemtap.git:refs/heads/scox/https * release-3.2-160-gc9bce69 / : Merge branch 'master' of ssh://sourceware.org/git/systemtap http://tinyurl.com/yaqokeur

01:26 <introom> hi. how to show all the kernel fucnitons invoked by a syscall ?

01:35 <irker418> systemtap: scox systemtap.git:refs/heads/scox/https * release-3.2-161-g3796558 / : Add preliminary https support http://tinyurl.com/y7zm6sfn

16:49 <ciupicri> can systemtap be used to trace what iptables is doing and how long it takes?

16:56 <fche> hi ciupicri

16:57 <fche> a couple of possibilities

16:57 <fche> first, stap can itself hook into the netfilter processing chain, and be as though it were an iptables-like module, and can observe traffic before or after the other modules

16:57 <fche> second, stap could probe iptable module internals, monitor their function calls, that sort of thing

16:58 <fche> https://sourceware.org/systemtap/SystemTap_Beginners_Guide/paracallgraph.html e.g.

17:32 <ciupicri> how would I know what function to trace? I mean what function are in iptables?

17:33 <fche> you'd need to figure that out to some extent, probably by looking at the kernel sources

17:33 <fche> I assume if you want to know module internals, you have looked at them in source form :)

17:33 <fche> so those functions, whatever you saw, can probably be traced reasonably easily

17:35 <ciupicri> that's the thing, I haven't looked at the source code :-) I'm talking a black box route from the outside instead of going from the inside

17:35 <fche> need to peel at least one layer of the onion, at a time, to do that efficiently

17:37 <ciupicri> :-)

17:37 <fche> so something like stap -L 'module("ipt*").function("*").call' or nf_* or nft*

17:38 <ciupicri> it shows me some functions alright

17:38 <fche> right, so those same wildcards can be fed to parametrized scripts like para-callgraph.stp

17:40 <ciupicri> what's strange is that I see iptable_nat, iptable_mangle, iptable_raw etc, but not filter

21:28 <ciupicri> fche: is the sample program from https://sourceware.org/systemtap/SystemTap_Beginners_Guide/paracallgraph.html still valid? I'm getting "WARNING: function files_maxfiles_init is in blacklisted section: keyword at /opt/exp/para-callgraph.stp:22:1 source: probe $1.call { trace(1, $$parms) } "

22:09 <fche> that's okay

22:09 <fche> the kernel prohibits us from probing parts of itself

22:15 <ciupicri> so what should I do?

22:15 <fche> ignore that warning, that's why it's only a warning :)

22:15 <fche> did you get any useful info so far?

22:16 <ciupicri> no

22:17 <ciupicri> it gets stuck at a warning

22:17 <ciupicri> never mind

22:17 <fche> I bet it's not stuck, it's running, just hasn't had to print anything

22:17 <ciupicri> I had to be more patient

22:30 <ciupicri> stap -L 'module("*").function("*").call' should give me a list of all the function right? Because I don't see ip_packet_match ( https://github.com/torvalds/linux/blob/master/net/ipv4/netfilter/ip_tables.c#L47 )

22:31 <ciupicri> my kernel is 4.15.13-300.fc27.x86_64

22:31 <fche> functions -within modules-. Anything compiled into the core kernel would show up as kernel.function("*").call (not-inlined)

22:37 <ciupicri> CONFIG_NETFILTER=y, CONFIG_NETFILTER_ADVANCED=y so it looks like they're in the core indeed

22:59 <ciupicri> I've found this: kernel.function("ip_packet_match@net/ipv4/netfilter/ip_tables.c:47") , but running para-callgraph.stp 'kernel.function("ip_packet_match@net/ipv4/netfilter/ip_tables.c")' fails with "semantic error: while resolving probe point: identifier 'kernel' at"

23:01 <fche> the rest of the message probably helps explain

23:01 <fche> here it says ... "WARNING: cannot probe .return of 1 inlined functions ip_packet_match"

23:02 <ciupicri> I see it too

23:02 <ciupicri> so I have to find another function that isn't inlined

23:02 <fche> yeah. or not use para-callgraph

23:03 <fche> if you just probe kernel.function("ip_packet_match") { println($$parms) } you should get something for inlined fns too

23:03 <ciupicri> you mean it's possible to analyze even inlined functions?

23:03 <fche> yes, and statements within them

23:07 <ciupicri> ip=0xffff951ea88c404e ip=0xffff951ea88c404e ip=0xffff951ea88c404e isfrag=0x0 ... I'm seeing ip multiple times because stap is smart enough to figure out the length of the ip array and print all of it?

23:07 <fche> nope, I suspect it's an inlining artifact :)

23:08 <fche> if you want it pretty-printed, try println($ip$)

23:12 <ciupicri> thanks. It doesn't look bad.