fche changed the topic of #systemtap to: http://sourceware.org/systemtap; email systemtap@sourceware.org if answers here not timely, conversations may be logged
gromero has joined #systemtap
_whitelogger has joined #systemtap
orivej has joined #systemtap
gromero has quit [Ping timeout: 272 seconds]
khaled has quit [Quit: Konversation terminated!]
_whitelogger has joined #systemtap
_whitelogger has joined #systemtap
ggherdov has quit [*.net *.split]
tonyj has quit [*.net *.split]
agentzh has quit [*.net *.split]
_whitelogger has joined #systemtap
khaled has joined #systemtap
gromero has joined #systemtap
CamillaShy has joined #systemtap
CamillaShy has quit [Client Quit]
khaled has quit [Ping timeout: 256 seconds]
khaled has joined #systemtap
<agentzh> fche: what do you think of this patch? https://gist.github.com/agentzh/048567e84017955fd5b4fee7eb56a59a
<agentzh> we noted that tapset funcs like uaddr() and register() did not work properly in probe process.begin.
<agentzh> this patch fixes that.
<fche> hmm interesting
<agentzh> another issue that this patch does not address is vma tracker is not initialized yet in this probe context.
<fche> yeah that looks legit
<fche> and is used for the other utrace-themed callbacks
<agentzh> any way to fix the vma tracker thing?
<agentzh> seems like vma tracker is implemented as a task finder callback as well.
<fche> sorry what about it?
<agentzh> the vma tracker is not usable in the process.begin probe.
<agentzh> but it is fine in other probes like timer.profile.
<fche> be more specific - the vma tracker is not something that's used in probes per se
<fche> they just track process memory-mapping changes for purposes of maintaining probes & backtrace address maps
<agentzh> yeah i was aware of that. what i meant is the vma tracker has not yet set up the maps yet in probe process.begin
<agentzh> sorry about any confusions here.
<fche> aha
<fche> not sure we can do that, since I believe the mmap hooks only get attached after the process is recognized as a target
<fche> but maybe it's tweakable
<fche> see timing of call to __stp_call_mmap_callbacks_for_task
<lindi-> btw, what is a good strategy on using systemtap with systems that use secure boot? some sort of remote signing service for the modules?
<fche> lindi-, stap-server is that service
<lindi-> ok, so it works with that case as well
<fche> it is designed to, yes
<lindi-> ah, should have searched that first
<fche> "dear lazyweb, ..." :)
<fche> agentzh, just looking at this code
* fche is not familiar but
<lindi-> currently trying to package tboot for debian and in the process I need to understand EFI better
<fche> taskf_finder2.c lines 1434 vs. 1440 seem relevant
<agentzh> fche: yeah, i noted that the task finder vma callback is called after process.begin handler is run.
<agentzh> looking
<fche> and 1347 & 1353
<agentzh> thanks
<agentzh> fche: i see that __stp_utrace_task_finder_target_syscall_entry is probing on syscall entry, is it similar to ptrace's syscall tracing? sorry for the dumb question.
<agentzh> as per my exeriment the utrace attach can even work on processes in sleeping mode.
<fche> well this is all intra-kernel
<agentzh> it's quite awesome.
<fche> so it can do more
<fche> yeah. utrace was blessed with capability and potential
<fche> and also cursed with same --- for lkml did not seem to like open-ended capability
<agentzh> heh
<agentzh> indeed
<agentzh> fche: i see __stp_utrace_task_finder_target_syscall_entry is only interested in mmap/mmap2 syscalls. what if the target has no such syscalls during the time window?
<agentzh> sorry if i misunderstand things here.
<agentzh> oh, and mprotect/munmap too.
<agentzh> fche: seems like the fix is simple: https://gist.github.com/agentzh/048567e84017955fd5b4fee7eb56a59a
<agentzh> good for committing?
<fche> would you mind coming up with a test for this one? I'm a bit concerned about whether there may be dependency between the sequence of those calls that we're not aware of
<fche> and since we are changing the order, we might as well document why
<agentzh> yeah, will do.
orivej_ has joined #systemtap
orivej has quit [Ping timeout: 264 seconds]
xar- has quit [Ping timeout: 256 seconds]
xar- has joined #systemtap
orivej_ has quit [Ping timeout: 256 seconds]
orivej has joined #systemtap
<agentzh> fche: okay, it seems like process(PATH).begin {} works fine with regard to vma tracker. i don't need to change the order in task_finder2.c.
<agentzh> i was having problems with probe process.begin.
<agentzh> maybe it's just a wrong way to use this.
<agentzh> not entirely sure about the semantics of "probe process.begin".
<agentzh> anyway, i'll leave the task_finder2.c change out of my patch.
<agentzh> i'm happy enough with process(PATH).begin myself.
<agentzh> already.
<agentzh> i added some tests to the tapset-utrace.cxx patch: https://gist.github.com/agentzh/57f48008ded119aef94e02ccb2f1dadf
<agentzh> fche: does it look good now?
<agentzh> just updated the patch above to include more code comments and tests.
<agentzh> the link is the same.
<agentzh> btw, i added a process_template_file proc to test_simple.exp to make such tests easier.
<fche> heh
<fche> you smuggled in your testing infrastructure, you sneaky fellow
<fche> well I don't mind, go for it .. it's just funny when infrastructure weighs many times (in terms of lines) the actual payload
<fche> hm, missing the reordered task-finder hunks no?
<agentzh> as i mentioned it's not needed for process(PATH).begin.
<agentzh> i was fighting the case with process.begin.
<agentzh> so i omitted it in my patch.
orivej has quit [Ping timeout: 264 seconds]
orivej_ has joined #systemtap
<agentzh> fche: test_simple.exp definitely got your greenlight when merging ;) so it's not really smuggling...
<agentzh> these primitives in test_simple.exp definitely saved a lot of code duplication in my tests.
<agentzh> otherwise i wouldn't bother. my .exp test files are automatically generated anyway.
<agentzh> i just want to make them look concose and nice.
<agentzh> *concise
<agentzh> i can prepare another patch for the process.begin case if you think it's worth the while.
irker777 has joined #systemtap
<irker777> systemtap: yichun systemtap.git:master * release-4.2-108-g26b24dc2e / : Bug: tapset functions reading userland registers did not work in probe process.begin
<fche> I'd prefer to have both
<agentzh> okay, working on the 2nd patch now.
<fche> thanks dude
<agentzh> sure
<agentzh> fche: found another thing. seems like register() works in probe process.begin on older kernels like CentOS 6's 2.6.32 but not on newer kernels like 5.0.
<agentzh> sorry, i mean probe process.end
<agentzh> is it a bug that newer kernels still do not allow register() in process.end?
darvon has quit [*.net *.split]
darvon has joined #systemtap
sscox has quit [*.net *.split]
sscox has joined #systemtap
jhg_ has quit [*.net *.split]
jhg_ has joined #systemtap
wcohen has quit [*.net *.split]
CME has quit [*.net *.split]
serhei has quit [*.net *.split]
eichiro_ has quit [*.net *.split]
wcohen has joined #systemtap
eichiro_ has joined #systemtap
CME has joined #systemtap
serhei has joined #systemtap
CME has quit [Max SendQ exceeded]
CME has joined #systemtap
<agentzh> seems like on centos6, probe process.end does have mm->current set while in fedora, mm->current is NULL.
<agentzh> the kernel C backtrace for probe process.end looks very different on centos6, guessing it's the old pid-based utrace at play here?
khaled has quit [Quit: Konversation terminated!]
<agentzh> looking good?
<agentzh> tested on both centos 6 and fedora 28
<fche> agentzh, that looks good to me
<fche> hm that's worth a NEWS blurb too as a small new feature
<agentzh> for reading registers in process.begin?
<fche> sure, that more register / memory-map related tapset functions work in those contexts now