fche changed the topic of #systemtap to: http://sourceware.org/systemtap; email systemtap@sourceware.org if answers here not timely, conversations may be logged
lkthomas has left #systemtap ["Leaving"]
khaled has quit [Quit: Konversation terminated!]
orivej has quit [Ping timeout: 258 seconds]
derek0883 has joined #systemtap
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
hpt 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]
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 [Remote host closed the connection]
derek0883 has joined #systemtap
derek0883 has quit [Remote host closed the connection]
orivej has joined #systemtap
orivej has quit [Ping timeout: 260 seconds]
hpt has quit [Ping timeout: 260 seconds]
lijunlong has quit [Ping timeout: 268 seconds]
lijunlong has joined #systemtap
khaled 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]
sscox has quit [Ping timeout: 264 seconds]
orivej has joined #systemtap
sscox has joined #systemtap
mjw has joined #systemtap
wcohen has quit [Remote host closed the connection]
wcohen has joined #systemtap
amerey has joined #systemtap
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #systemtap
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #systemtap
tromey has joined #systemtap
sscox has quit [Ping timeout: 258 seconds]
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
sscox has joined #systemtap
sscox has quit [Ping timeout: 260 seconds]
orivej has quit [Ping timeout: 258 seconds]
orivej has joined #systemtap
tromey has quit [Quit: ERC (IRC client for Emacs 27.1.50)]
derek0883 has quit [Remote host closed the connection]
<fche>
sure, ... as long there's no reason to think it could be an infinite loop
<fche>
leaving a module behind is not that bad
<fche>
by the way
<fche>
we're planning to cut a stap release in the next 7 days
<kerneltoast>
but the president said no child process should be left behind
<fche>
or was that the little green marine toy
<kerneltoast>
next 7 days... so no extreme things between now and then?
<kerneltoast>
fche, have there been no problems with my patches on your end?
<fche>
buildbots have been happy
<kerneltoast>
god bless paul mckenny
<kerneltoast>
ok ignore my rmmod gist
<fche>
done
<fche>
I forgot it ever happened
<kerneltoast>
okay now `sudo yum update`
<kerneltoast>
fche, it would be quite opportune if i could fix the remaining kernel panic from our fuzzer before the stap release... is there any kind of freeze before the release in 7 days?
<fche>
not anything hard
<fche>
but yeah we won't be very receptive to invasive things in a matter of $fuzzy# of days
<kerneltoast>
sounds like a good time for 25,000 line patches
<fche>
cat > /dev/null :-)
<kerneltoast>
last release was in june?
sscox has joined #systemtap
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #systemtap
<kerneltoast>
fche, question about the buildbots
<kerneltoast>
do the tested kernels use CONFIG_PREEMPT=y?
<kerneltoast>
our kernel panics are caused by the *absence* of CONFIG_PREEMPT=y, because when there's no PREEMPT, in_atomic() becomes unreliable
<kerneltoast>
and the task finder depends on in_atomic() :}
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
amerey has quit [Quit: Leaving]
<fche>
not sure
<fche>
we intermittently test on kernel-rt builds for RHEL and methinks fedora, but those results are worse.
<kerneltoast>
fche, so fixing this panic in stap can be hairy
<kerneltoast>
there are two options:
<kerneltoast>
the quick and easy fix to just always use a task worker in place of those in_atomic() checks
<kerneltoast>
or
<kerneltoast>
make the mmap callback functions fully atomic
orivej has quit [Ping timeout: 272 seconds]
<kerneltoast>
which would be maybe a hundred lines changed?
<kerneltoast>
the code i'm talking about is in __stp_utrace_task_finder_target_quiesce()
<kerneltoast>
right here:
<kerneltoast>
if (in_atomic() || irqs_disabled()) {
<fche>
so i.e., do that if (...) stuff unconditionally?
<kerneltoast>
correct
<fche>
I think I'd like that
<kerneltoast>
there's another in_atomic() in the task finder that should probably be nuked too
<kerneltoast>
in __stp_utrace_task_finder_target_syscall_exit()
<kerneltoast>
i believe this gave us panics too
<kerneltoast>
i'll prep a patch
<fche>
hm in that code, currently is there a memory leak on the stap_task_work_add error case?
derek0883 has quit [Remote host closed the connection]
<kerneltoast>
hah
<kerneltoast>
it looks like it
<kerneltoast>
let me double check
<kerneltoast>
yeah
<kerneltoast>
lol
<kerneltoast>
i think there are lot of broken stap_task_work_add error paths
<kerneltoast>
like the one i found last week with the atomic refcount