02:17 <agentzh> fche: but then the begin probe is run without vma initialized.

02:17 <agentzh> and @var() always returns zero for PIE/PIC.

05:22 <agentzh> alas, it seems there's no way to make sure different task finder targets for the same process run in any particular order.

05:23 <agentzh> my previous already-committed patch only handle the callbacks order in the same task finder target (tgt). but among different tgts, it seems quite inconsistent.

05:25 <agentzh> maybe we need a mechanism to establish tgt dependencies.

05:44 <agentzh> ah, i see what's going on here. in __stp_utrace_task_finder_target_quiesce(), if the context can't sleep, it will call stp_task_work_add (and ultimately task_work_add) to postpone the current tgt, which essentially swaps the execution order of the tgts.

06:52 <agentzh> fche: created a PR with more details on this task finder execution order issue: https://sourceware.org/bugzilla/show_bug.cgi?id=26144

06:52 <agentzh> feedback welcome!

06:53 <agentzh> my previous patch indeed makes no sense. please see my proposed changes in the PR itself.

06:53 <agentzh> thanks!

07:53 <agentzh> fche: i've noted that centos 6 also uses relay_v2, at least for recent centos 6 stock kernels. but it does not provide inode_lock(), i'll do the compatibility fixes in my patch before committing.

17:48 <agentzh> fche: relay v7 patch fixes compilation compatibility with centos 6 which lacks inode_lock and etc: https://gist.github.com/agentzh/517eef2a4d54554b2712c18cb79d214d

17:49 <agentzh> now i switched to stap runtime's own wrappers for inode locking/unlocking.

17:50 <agentzh> i haven't committed this patch since i'd like to do more testing on more kernels.

17:52 <agentzh> it'll be great if you can have another look. thanks!

17:57 <fche> agentzh, thanks for your work on this

17:57 <fche> today I probably won't be able to take a close look, too many other chores :(

17:57 <fche> sorry!

17:58 <agentzh> no worries. i just noted my relay locks might lead to deadlocks on centos 6 and 7. i'll dig it up today.

18:00 <agentzh> thanks for your quick responses as always!

18:00 <agentzh> that's been motivating me a lot ;)

18:01 <fche> hey my part is easy - you're doing the hard work on this one :)

18:01 <agentzh> your part is not easy for me :) i really needed those important hints to save a lot of time on my side.

19:23 <agentzh> okay, centos 7's kernel-debug helped me pinpoint the deadlock, which is a copy&paste mistake...already fixed. will include the fix in the upcoming v8 patch.

19:24 <fche> neat

19:24 <agentzh> now lockdep found no issues on centos 7 in my load test for stream mode/bulk mode (with/without percpu headers).

19:25 <agentzh> i'm testing centos 6 now.

20:40 <agentzh> seems like there's no deadlocks on centos 6 either now.

20:40 <agentzh> it's essentially using the same code paths as centos 7.

20:54 <fche> nicew