fche changed the topic of #systemtap to: http://sourceware.org/systemtap; email systemtap@sourceware.org if answers here not timely, conversations may be logged
orivej has quit [Ping timeout: 276 seconds]
<fche>
btw
<fche>
put_utrace_struct is almost always called with a param of 1; get always implies 1
<fche>
there is only one (?) case where it's called with a 2
<fche>
could you just call it twice from that spot?
<fche>
and drop the parameter
<kerneltoast>
i mean you could
<kerneltoast>
i prefer it this way though
derek088_ has quit [Remote host closed the connection]
<kerneltoast>
it's called with a 2 at that location because originally that's where the utrace struct would get freed
<kerneltoast>
ie the original reference gets put
<kerneltoast>
so we must put 1 reference to cover the original utrace reference, and then 1 more to cover the new reference we acquired in that function
<fche>
yes, but that's the super unusual case
<fche>
so calling the fn twice there is kind of a good sticking-out-sore-thumb
<kerneltoast>
bah okay
<fche>
i know it's a bit of a toolshed but it's unusual and not necessarily so
<kerneltoast>
it adds another memory barrier
<kerneltoast>
and makes me cry
<kerneltoast>
but that's okay
<fche>
how frequently?
<kerneltoast>
that is an excellent question, i have never tried putting a printk there
<fche>
ummmmmmmmm
<fche>
don't make me /kick you again, I mean it was fun but
<fche>
:-)
<kerneltoast>
;_;
<fche>
i mean if it's once per stap script detach ... or once per task death ... well one more barrier who cares?
<kerneltoast>
i did printk the utrace lifetime with this patch, just not that specific function
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
hpt has quit [Ping timeout: 240 seconds]
<agentzh>
kerneltoast fche: alas. i can no longer follow your conversation. it's already beyond me. but i won't mind as long as kerneltoast can follow everything here for me :)
<kerneltoast>
lol
<agentzh>
seems like we're finally reaching the end of the tunnel.
<agentzh>
we now have way less kernel freezes in the fuzzer than before.
<kerneltoast>
fche and i communicate in a different language
<agentzh>
good point.
<kerneltoast>
i find that the right balance to get fche motivated is 70% meme and 30% stap
<agentzh>
lol
<agentzh>
yeah i've noted that.
<kerneltoast>
though today he was not very happy about that and kicked me from the channel
<agentzh>
so /me being too serious?! that's my mistake.
<agentzh>
well, just virtual kicking. don't worry.
<agentzh>
fche loves you.
<fche>
hey now
<fche>
this is family channel
<fche>
the memes help the spirit stay aloof and youthful (maybe)
<kerneltoast>
gotta convince the young people that stap is hip and cool
<agentzh>
nice try.
<kerneltoast>
so that my parents will stop thinking that ubuntu is a virus
<fche>
never tell them about the gpl
<fche>
those test result diffs look unremarkable, which is good
<agentzh>
and openresty is a washingtonpost devops.
<fche>
server farms die in darkness
<kerneltoast>
we are jeff bezos' personal news arm
<agentzh>
cool
<kerneltoast>
openresty writes the news
<agentzh>
great news for the test results!
<agentzh>
seems like the stap test suite indeed runs much faster now.
<agentzh>
thanks for parallelism.
<fche>
ok, if the fuzzer is happy, i am happy, ship it
<fche>
and watch Ghostbusters sometime, classic
<kerneltoast>
oh wow late Friday night ship
<agentzh>
yay
<kerneltoast>
i need to touch up the commit msg
<kerneltoast>
agentzh, yeah the parallelism is a godsend but fche has yet to make his buildbots use it
<kerneltoast>
i suspect he is afraid of finding bugs
<fche>
well, serhei is the head honcho of the buildbots, I'm just the occasional troubleshooter
<fche>
maybe we can bribe him next week to turn it on one some of the larger ones
<kerneltoast>
y'all also need to test with non-PREEMPT kernels
<kerneltoast>
those in_atomic() checks were lingering in stap for years
<fche>
seemed like the right thing to do at the time
<kerneltoast>
kernel documentation warns against relying on them