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!]
lijunlong has quit [Read error: Connection reset by peer]
lijunlong has joined #systemtap
derek088_ has joined #systemtap
derek0883 has quit [Ping timeout: 272 seconds]
hpt has joined #systemtap
derek088_ has quit [Remote host closed the connection]
irker318 has quit [Quit: transmission timeout]
derek0883 has joined #systemtap
derek088_ has joined #systemtap
derek0883 has quit [Ping timeout: 260 seconds]
derek088_ has quit [Ping timeout: 256 seconds]
derek0883 has joined #systemtap
orivej has quit [Ping timeout: 260 seconds]
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
orivej has joined #systemtap
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
derek0883 has quit [Remote host closed the connection]
khaled has joined #systemtap
mjw has joined #systemtap
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #systemtap
hpt has quit [Ping timeout: 265 seconds]
derek0883 has joined #systemtap
derek0883 has quit [Read error: Connection reset by peer]
orivej has quit [Ping timeout: 246 seconds]
amerey has joined #systemtap
orivej has joined #systemtap
DTEIT_ has joined #systemtap
DTEIT has quit [Quit: ZNC 1.8.2 - https://znc.in]
DTEIT_ has quit [Quit: ZNC 1.8.2 - https://znc.in]
DTEIT has joined #systemtap
derek0883 has joined #systemtap
derek0883 has quit [Remote host closed the connection]
khaled has quit [Quit: Konversation terminated!]
khaled has joined #systemtap
derek0883 has joined #systemtap
tromey has joined #systemtap
irker157 has joined #systemtap
<irker157> systemtap: jamie.bainbridge systemtap.git:master * release-4.4-8-gc77a9824d / doc/SystemTap_Beginners_Guide/en-US/Useful_Scripts-dropwatch.xml testsuite/systemtap.examples/network/dropwatch.stp: examples: add timestamp to dropwatch.stp
khaled has quit [Quit: Konversation terminated!]
khaled has joined #systemtap
khaled has quit [Client Quit]
khaled has joined #systemtap
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
khaled has quit [Quit: Konversation terminated!]
khaled has joined #systemtap
khaled has quit [Remote host closed the connection]
khaled has joined #systemtap
khaled has quit [Client Quit]
khaled has joined #systemtap
khaled has quit [Client Quit]
khaled has joined #systemtap
<kerneltoast> fche, hiya
khaled has quit [Quit: Konversation terminated!]
khaled has joined #systemtap
<fche> nobody but us chickens
khaled has quit [Client Quit]
<kerneltoast> yeah it has been quiet here except for us
khaled has joined #systemtap
orivej has quit [Ping timeout: 256 seconds]
<fche> lgtm
<fche> I don't want to know what sort of crazy conditions allow the task-finder to not start
<kerneltoast> missing the target process
<kerneltoast> when -x PID is used
<kerneltoast> i haven't actually tested this, because i kind of can't
<kerneltoast> do you want to wait until someone tests it?
<kerneltoast> we have someone who can reproduce the error, albeit rarely
<fche> nah, the fix looks good, assuming one can get into that code path at all
<fche> go for it
<kerneltoast> coolbeans
<irker157> systemtap: sultan systemtap.git:master * release-4.4-9-g6a092f5ae / task_finder.cxx: task_finder: call _stp_vma_done() upon error to fix memory leak
amerey has quit [Remote host closed the connection]
amerey has joined #systemtap
<kerneltoast> fche, i think i solved the print_flush dilemma
derek0883 has quit [Remote host closed the connection]
<fche> puts the die into dielemma
<kerneltoast> it's the same as the old spaghetti but with more marinara
<fche> hm so how safe is tasket_schedule() to call from practically anywhere ?
<kerneltoast> supermegasafe
<kerneltoast> static void __tasklet_schedule_common(struct tasklet_struct *t,
<kerneltoast> struct tasklet_head __percpu *headp,
<kerneltoast> {
<kerneltoast> unsigned int softirq_nr)
<kerneltoast> struct tasklet_head *head;
<kerneltoast> unsigned long flags;
<kerneltoast> local_irq_save(flags);
<kerneltoast> head = this_cpu_ptr(headp);
<kerneltoast> t->next = NULL;
<kerneltoast> *head->tail = t;
<kerneltoast> head->tail = &(t->next);
<kerneltoast> raise_softirq_irqoff(softirq_nr);
<kerneltoast> local_irq_restore(flags);
<kerneltoast> }
<kerneltoast> no locks, no tracepoints
<fche> I would bet that is exactly the intent of them
<fche> if we have tasklets do we still need work gadgets too?
<kerneltoast> yeah
<kerneltoast> well
<kerneltoast> i thought about that
<kerneltoast> i dunno if we can do super heavy work inside a tasklet without causing stalls elsewhere
tromey has quit [Quit: ERC (IRC client for Emacs 27.1.50)]
<kerneltoast> the print buffers are bigly so i need to check
<fche> aha, so the tasklet just schedules the work
<fche> what a funny indirect way of doing it
<fche> (are there precedents for doing this elsewhere in the kernel)?
<kerneltoast> lemme check, i've never used a tasklet before
<kerneltoast> softirq stuff is mainly for networking braindamage
<kerneltoast> of which i have no experience :)
<fche> next q: did you have a chance to test this on rhel6 2.6.32 era kernels?
<kerneltoast> not yet but i checked the api on 2.6.32
<kerneltoast> the api hasn't changed
<kerneltoast> so it has a chance of working
<fche> ok, yeah plausible overall
<fche> Ship It To The Testsuites
derek0883 has joined #systemtap
<kerneltoast> fche, it seems fine to punt this on the tasklet
<kerneltoast> fche, okay i have another problem
<kerneltoast> _stp_stack_kernel_sprint and _stp_stack_user_sprint depend on instantly flushing the print buffer
<kerneltoast> which would be a valid assumption if they were never called with IRQs disabled, but i see no such guarantee
<kerneltoast> i guess i can just convert them to use a normal print?
<fche> sprint is there to return the string , not to print it
<fche> but that doesn't mean they have to go through the whole buffering game junk
<fche> there is a string allocated in the stap context object where they could print their thing directly via vscnprintf or whatever
<fche> they just don't
<kerneltoast> why do they clear the print buffer though
<kerneltoast> log->len = 0;
<fche> not sure
<fche> maybe to pretend it was empty to start with, so when they print incremental line content etc., it doesn't have some other prior data there to start with
<fche> it all seems like an unfortunate shortcut
<kerneltoast> can we nuke the shortcut?
<fche> the longer way would require passing that output-buffer gadget along throughout the process
<fche> so that's painful tooo
<fche> a little bit
<kerneltoast> oh wait i see what it's doing
<kerneltoast> ok i can fixor it
<irker157> systemtap: fche systemtap.git:master * release-4.4-10-g532eb9a15 / buildrun.cxx runtime/linux/autoconf-lockdown-kernel.c runtime/transport/transport.c session.cxx: PR26665 detect rhel8 (4.18) era kernel_is_locked_down() as procfs trigger
orivej 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
amerey has quit [Quit: Leaving]
<fche> checking dis
<kerneltoast> ✓ fixed the stack.c changes
<kerneltoast> ✓ 37 miles to the gallon
<kerneltoast> ✓ fancy commit message
<kerneltoast> ✓ fixes more than one bugsy
<fche> strong unicode game
<kerneltoast> if everything looks good i'll proceed to running the painsuite
<kerneltoast> our lean testsuite is happy with this btw
<kerneltoast> i'll ask agentzh to test rhel6
<fche> looks plausible
<fche> one bit as an extra comment please - why the print lock is a rwlock, and what r vs. w locking implies/protects
<fche> it's straightforward but might as well spell it out
<kerneltoast> ok
<kerneltoast> i'll just tack it at the lock definition