fche changed the topic of #systemtap to: http://sourceware.org/systemtap; email systemtap@sourceware.org if answers here not timely, conversations may be logged
<agentzh>
okay, we can see how it will exactly look like.
<agentzh>
another reason to have a higher level compiler that emits stap scripts :)
khaled has joined #systemtap
khaled has quit [Quit: Konversation terminated!]
hpt has joined #systemtap
<fche>
hey agentzh, I thought y'all were going to add a NEWS blurb for the RCU work.
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
sscox has quit [Ping timeout: 240 seconds]
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
<agentzh>
fche: yeah, i already did, no?
<agentzh>
ah, i forgot to add it. only added to a patch file.
<agentzh>
will commit a change to NEWS.
<agentzh>
sorry about it.
<irker814>
systemtap: yichun systemtap.git:master * release-4.3-97-gc4810171c / NEWS: NEWS: added an entry for the VMA map RCU lock changes
<agentzh>
fche: done
<agentzh>
fche: kerneltoast has run a lot of tests without lockdep errors in a lockdep kernel. he's still hitting the freeze problem when running the test suite long enough on debug or lockdep kernels but it is unrelated to his RCU patches and is a separate issue.
<agentzh>
so is it okay to push his 2nd RCU patch for the task hash table?
orivej has joined #systemtap
lijunlong has quit [Ping timeout: 272 seconds]
lijunlong has joined #systemtap
sscox has joined #systemtap
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
derek0883 has quit [Remote host closed the connection]
irker814 has quit [Quit: transmission timeout]
orivej has quit [Ping timeout: 260 seconds]
lijunlong has quit [Read error: Connection reset by peer]
khaled has joined #systemtap
lijunlong has joined #systemtap
sscox has quit [Ping timeout: 240 seconds]
hpt has quit [Ping timeout: 256 seconds]
orivej has joined #systemtap
<fche>
agentzh, can we have one more look at the patch?
<jlevon>
before I file a bug, thought I'd check here: stap --bpf is still looking at /sys/module/module/parameters/sig_enforce, but that in fact isn't an issue for bpf backend
<fche>
right (well, for now; signed bpf is coming at some point)
<jlevon>
but it's a bug right now, no?
<fche>
guess so!
<fche>
well you can tell us what you're observing and why you think it's wrong
<fche>
(patch of course would be great)
<jlevon>
I'd probably have to dig into the other options and figure those out for a patch
<fche>
kerneltoast, ok re-skimmed that patch. it's intimidatingly low level, and I lack specific expertise, but it looks good & consistent
<fche>
so don't mind giving it a try
<fche>
at worst if something goes wrong in the next few weeks, we pull it back out
<jlevon>
but obviously the whole "modules_must_be_signed" concept needs adapting for stapbpf
<fche>
(for now :)
<jlevon>
in the meantime, "mount --bind ./no /sys/module/module/parameters/sig_enforce" will do :)
<kerneltoast>
if anything goes wrong just revert it so you can feel better (:
<fche>
jlevon, sneaky
<jlevon>
hrm looks like bpf backend can't do stacks :/
<irker354>
systemtap: alizhang systemtap.git:azhang/pr13838 * release-4.3-126-g9fa55a466 / testsuite/buildok/floatingpoint.stp: use try catch to handle NaN error