fche changed the topic of #systemtap to: http://sourceware.org/systemtap; email systemtap@sourceware.org if answers here not timely, conversations may be logged
derek0883 has quit [Ping timeout: 264 seconds]
orivej has quit [Ping timeout: 265 seconds]
orivej_ has joined #systemtap
amerey has quit [Ping timeout: 260 seconds]
orivej_ has quit [Ping timeout: 258 seconds]
derek0883 has joined #systemtap
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
_whitelogger 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 [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]
lindi- has quit [*.net *.split]
khaled has joined #systemtap
lindi- has joined #systemtap
lindi- has quit [*.net *.split]
mjw has joined #systemtap
lindi- has joined #systemtap
<modem> hi
<modem> I can't run systemtap on debian-testing
<modem> (5.8)
<modem> the mmap_sem apparently changed to mmap_lock
<modem> I am fixing by hand task_finder2.c and access_process_vm.h
<modem> i can provide a diff/patch if you like
<modem> i also hit this:
<modem> Pass 3: translated to C into "/tmp/stapYlVwKK/stap_af57c7df34efd9986deb5a5328293a66_20736_src.c" using 149944virt/138888res/8900shr/129916data kb, in 320usr/10sys/340real ms.
<modem> In file included from /usr/share/systemtap/runtime/linux/runtime.h:31,
<modem> from /usr/share/systemtap/runtime/runtime.h:26,
<modem> from /tmp/stapYlVwKK/stap_af57c7df34efd9986deb5a5328293a66_20736_src.c:21:
<modem> /usr/src/linux-headers-5.8.0-2-common/include/linux/vermagic.h:6:2: error: #error "This header can be included from kernel/module.c or *.mod.c only"
<modem> 6 | #error "This header can be included from kernel/module.c or *.mod.c only"
orivej has joined #systemtap
<fche> modem, commit 37066e2c3a9d9f48fc01b13ec0493b1c67551275
derek0883 has joined #systemtap
orivej has quit [Ping timeout: 240 seconds]
derek0883 has quit [Remote host closed the connection]
<modem> fche: mmm
<modem> fche: i just contributed a patch file
<modem> i also had to remove vermagic.h as an include and replace it with generated/utsrealase.h
<modem> oh and btw it will compile and load and hit a null-deref immediately
<modem> i am on its way of fixing
<modem> any advice on where to check first is welcome '-)
<fche> commit 79000b42e1b490b25d966d08cad30fd01472c59e for that vermagic thing
<fche> are you running git-master stap in your testing?
orivej has joined #systemtap
wcohen has quit [Remote host closed the connection]
khaled has quit [Quit: Konversation terminated!]
khaled has joined #systemtap
khaled has quit [Remote host closed the connection]
khaled has joined #systemtap
wcohen has joined #systemtap
<modem> i am running debian-testing systemtap package
<modem> let me git co and try again
<fche> yeah the general rule is very fresh kernels need git master stap
<fche> 'cause the kernel doesn't have a fixed api so we get to chase it
<modem> fche: i can confirm latest GIT is working flawlessly
<fche> good
<modem> sorry for not checking previously to creating a ticket
<fche> np, happens
<fche> stap -V tries to self-identify the range of kernel versions we've tested
<fche> hm it should include 5.9-rcSOMETHING now
<modem> the po/Makefile had to be stripped from 'en' files (unpresent on git) before compilation
<modem> perfect! you rocks
sscox has quit [Ping timeout: 260 seconds]
amerey has joined #systemtap
orivej has quit [Ping timeout: 240 seconds]
sscox has joined #systemtap
derek0883 has joined #systemtap
derek0883 has quit [Ping timeout: 240 seconds]
derek0883 has joined #systemtap
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
orivej has joined #systemtap
tromey has joined #systemtap
irker950 has joined #systemtap
<irker950> systemtap: fche systemtap.git:master * release-4.3-81-g212352420 / session.cxx: stap -V: note function with kernel 5.9-rc
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
orivej has quit [Ping timeout: 260 seconds]
lindi- has quit [*.net *.split]
lindi- has joined #systemtap
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
derek0883 has quit [Ping timeout: 260 seconds]
derek0883 has joined #systemtap
irker950 has quit [Quit: transmission timeout]
derek088_ has joined #systemtap
derek0883 has quit [Ping timeout: 240 seconds]
derek088_ has quit [Ping timeout: 240 seconds]
derek0883 has joined #systemtap
<irker878> systemtap: alizhang systemtap.git:azhang/pr13838 * release-4.3-86-g94f99aa8a / tapset/floatingpoint.stp: added some of the test case
irker878 has joined #systemtap
orivej has joined #systemtap
tromey has quit [Quit: ERC (IRC client for Emacs 27.1)]
<agentzh> fche: good afternoon! not sure if kerneltoast has already shared with you, but what do you think of his patch here? https://gist.github.com/agentzh/7c98fea4d7461f91e4f1a3b237f6fd77
<agentzh> there's still remaining questions in the patch though.
<fche> well at the least the patch is an obvious defensive improvement, even if don't quite understand why it should ever happen
<agentzh> fche: there's some explanation in the patch regarding why it may return NULL.
<agentzh> does it make sense?
<agentzh> it's very easy to reproduce when running several stap instances at the same time.
<agentzh> but it does require some load on an SMP system.
<agentzh> quite some load
<fche> yeah, nothing jumps out at me as an obvious explanation
<fche> but yeah the patch looks fine
<agentzh> k, thanks
<fche> (git commit --author=XXXX) to get his name into the credits :)
<agentzh> yeah, sure.
<agentzh> fche: and how about this patch? (also from kerneltoast ): https://gist.github.com/agentzh/390c64b938018251d75b442e86e183e9
<agentzh> this one is more hairy.
<fche> the old code wouldn't want to resume something? why?
<kerneltoast> fche, because the action arg there used to just be UTRACE_STOP
<fche> in the case of UTRACE_STOP, the new code = the old code, more or less, right?
<kerneltoast> the UTRACE_RESUME if statement wasn't removed when that change was made
<kerneltoast> let me dig up the commit
<fche> well that sounds entertaining
<fche> commit f346b8b33f045f295bf8044c65d4ccadaffc6266 ?
<kerneltoast> fche, yeah that one
* fche doesn't grok the code well enough to know whether this is intentional
<fche> and unfortunately I must head off to an activity right about now
<fche> so can I leave it to you to figure it out a little more, and then we can talk tomorrow about what you found out?
<kerneltoast> fche, the motivation for this change was that traced processes were getting stuck in utrace_stop()
<kerneltoast> never being woken from their traced state
<kerneltoast> fche, yeah I've been digging through this all week :)
<kerneltoast> have a good evening
<fche> righto
<irker878> systemtap: sultan systemtap.git:master * release-4.3-82-g619f6940d / runtime/stp_utrace.c: PR26697: fix NULL pointer deref in get_utrace_lock()
mjw has quit [Quit: Leaving]
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
lindi- has quit [*.net *.split]