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!]
modem has quit [Ping timeout: 252 seconds]
modem has joined #systemtap
hpt has joined #systemtap
orivej has quit [Ping timeout: 240 seconds]
khaled has joined #systemtap
fdalleau_away is now known as fdalleau
khaled has quit [Quit: Konversation terminated!]
khaled has joined #systemtap
hpt has quit [Ping timeout: 240 seconds]
LW has quit [Quit: Leaving]
orivej has joined #systemtap
khaled_ has joined #systemtap
khaled has quit [Remote host closed the connection]
tromey has joined #systemtap
<modem>
mmm
<modem>
I have a probe that does a down_write(mm->mmap_sem)
<modem>
it's creating a recursive deadlock issue
<modem>
despite the lock is not held when the probe is hit
<modem>
Can someone confirm me that recursive probe trigger deadlock ?
<fche>
that's a lockdep warning about a lock-ordering problem
<fche>
you have a -probe- that does a down_write() in the probe handler via embedded-C?
<fche>
yeah don't do that
orivej has quit [Ping timeout: 252 seconds]
<modem>
fche: yes I have a probe that does down_write() via embedded-C and it also call the function that is probed
<modem>
it seems I have a deadlock problem because my probe does hit itself
<modem>
(it's not from the down_write)
<fche>
that's not a recursion warning, but a lock ordering one
<fche>
lockdep is telling you that with the way your code is run (CPU0), another piece of code run on another CPU could trigger a deadlock
<fche>
and anyway, yeah, you really shouldn't do down_write etc. in embedded C unless you know Very well what context you do it in, ensure the locking context is Just Right etc.
<modem>
I understand
<modem>
what is this kretprobe_table_locks things
<modem>
you cannot run the same probe handler concurrently ?
<fche>
some internal kernel part
<fche>
we run concurrently all the time
<fche>
but WHAT we run is the issue. Yours introducing locking that's inconsistent with the way the rest of the kernel is doing it
<modem>
I can not acquire exclusive lock from an embedded-c probe ? correct me
<irker075>
systemtap: fche systemtap.git:master * release-4.4-152-g15e40b631 / testsuite/systemtap.base/sdt_buildid.exp util.cxx: use long-lived debuginfod_client handle for buildid based probes
<fche>
modem, correct, you generally cannot just take locks you might want to
<fche>
stap probes do not run in 'process context' or something like that, where blocking etc. are okay
<modem>
yes
<modem>
gotcha
<modem>
first time I am stuck from doing something from systemtap