fche changed the topic of #systemtap to: http://sourceware.org/systemtap; email systemtap@sourceware.org if answers here not timely, conversations may be logged
khaled has quit [Quit: Konversation terminated!]
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
derek0883 has quit [Ping timeout: 264 seconds]
hpt has joined #systemtap
derek0883 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
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #systemtap
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #systemtap
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
ema has quit [Ping timeout: 240 seconds]
ema has joined #systemtap
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
orivej has quit [Ping timeout: 260 seconds]
khaled has joined #systemtap
ema has quit [Ping timeout: 256 seconds]
ema has joined #systemtap
derek0883 has quit [Remote host closed the connection]
orivej has joined #systemtap
irker219 has quit [Quit: transmission timeout]
_whitelogger has joined #systemtap
hpt has quit [Ping timeout: 256 seconds]
agentzh has quit [*.net *.split]
agentzh has joined #systemtap
derek0883 has joined #systemtap
derek0883 has quit [Read error: Connection reset by peer]
amerey has joined #systemtap
amerey_ has joined #systemtap
amerey has quit [Ping timeout: 256 seconds]
derek0883 has joined #systemtap
derek0883 has quit [Read error: Connection reset by peer]
derek0883 has joined #systemtap
mjw has quit [Quit: Leaving]
tromey has joined #systemtap
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
derek0883 has quit [Ping timeout: 264 seconds]
derek0883 has joined #systemtap
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
derek0883 has quit [Ping timeout: 264 seconds]
derek0883 has joined #systemtap
derek0883 has quit [Read error: Connection reset by peer]
derek0883 has joined #systemtap
tromey has quit [Ping timeout: 246 seconds]
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
derek088_ has joined #systemtap
derek0883 has quit [Ping timeout: 256 seconds]
derek088_ has quit [Ping timeout: 264 seconds]
derek0883 has joined #systemtap
derek0883 has quit [Read error: Connection reset by peer]
derek0883 has joined #systemtap
<kerneltoast> fche, bonjour
<kerneltoast> how uneasy does this patch make you feel? https://gist.github.com/kerneltoast/54c49d6cdf121d50d99ec7fab396ed27
derek088_ has joined #systemtap
derek0883 has quit [Remote host closed the connection]
amerey_ has quit [Quit: Leaving]
derek088_ has quit [Remote host closed the connection]
derek0883 has joined #systemtap
<fche> could the comment better spell out the lifespan of the relevant objects in the union?
derek0883 has quit [Read error: Connection reset by peer]
derek0883 has joined #systemtap
<fche> like ... "rcu is only used in functions x y z AFTER an event takes place"
<fche> "attached/attaching are only used in function a b c BEFORE this event"
<fche> and some way to feel sure that the transition of that event is atomic, i.e., there is no moment when both conditions are true in some sort of inatomic way
<kerneltoast> hmm i could also make those objects' lifetimes more strict wrt RCU and easier to audit
<kerneltoast> fche, oh no
<kerneltoast> i found a bug in my first stap commit
<fche> probably there was one in my first one too
irker249 has joined #systemtap
<irker249> systemtap: sultan systemtap.git:master * release-4.4-62-g23ef716aa / runtime/stp_utrace.c: stp_utrace: remove kmem cache usage
<irker249> systemtap: sultan systemtap.git:master * release-4.4-63-gd5c4be8aa / runtime/stp_utrace.c: stp_utrace: add missing rcu_read_unlock() in get_utrace_lock() error path
<kerneltoast> CRAP
<kerneltoast> CRAP
<kerneltoast> NOOOOOOOOOOOO
<kerneltoast> AAAAAAAAAAAAAAH
<kerneltoast> FCHE HELP ME
<fche> with
<kerneltoast> I MESSED UP
<kerneltoast> I DIDN'T MEAN TO PUSH THE KMEM CACHE COMMIT
<kerneltoast> AAAAAAAAAAAAAA
<fche> ok so you revert it and push
<fche> bad toast
<fche> no butter
<irker249> systemtap: sultan systemtap.git:master * release-4.4-64-g3b858b727 / runtime/stp_utrace.c: Revert "stp_utrace: remove kmem cache usage"
<kerneltoast> the message in "stp_utrace: add missing rcu_read_unlock() in get_utrace_lock() error path" didn't lie
<kerneltoast> bad day to be a toast
<kerneltoast> fche, so RCU isn't even used to strictly guarantee a utrace struct's lifetime, as seen in task_utrace_struct()
<kerneltoast> task_utrace_struct() returns a utrace struct which is then used outside the RCU lock
<kerneltoast> this was a mistake on my part when i added the RCU stuff; i just made use of the existing assumptions about utrace object lifetime when i did that
<kerneltoast> *wasn't a mistake
<kerneltoast> man i am failing hard today
<kerneltoast> so, since we aren't even relying on RCU to keep utrace structs safe, we can assume that the struct members i'm reusing for the RCU callback are not used in a way that leans on RCU's lifetime guarantees after the utrace struct is marked dead
<kerneltoast> i hope that makes sense
<fche> or how about this
<fche> if we're not SURE,
<fche> leave the code the way it is, waste the hundred or whatever bytes, who cares
derek0883 has quit [Ping timeout: 264 seconds]