<div dir="ltr"><div>Hi Geneviève,</div><div><br></div><div>Thank you for your response.</div><div><br></div><div>I had tried your solution before. Unfortunately, there is no difference between preloading one or two other shared libraries with my test library. I am not sure about the reason, maybe a conflict between lttng and firefox in access to shared resource.</div><div><br></div><div>Majid </div><div><br></div><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 9, 2018 at 4:26 PM, <span dir="ltr"><<a href="mailto:lttng-dev-request@lists.lttng.org" target="_blank">lttng-dev-request@lists.<wbr>lttng.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Send lttng-dev mailing list submissions to<br>
<a href="mailto:lttng-dev@lists.lttng.org" target="_blank">lttng-dev@lists.lttng.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev" rel="noreferrer" target="_blank">https://lists.lttng.org/cgi-bi<wbr>n/mailman/listinfo/lttng-dev</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:lttng-dev-request@lists.lttng.org" target="_blank">lttng-dev-request@lists.lttng.<wbr>org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:lttng-dev-owner@lists.lttng.org" target="_blank">lttng-dev-owner@lists.lttng.or<wbr>g</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of lttng-dev digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: LD_PRELOAD applications using lttng-ust-pthread<br>
(Jonathan Rajotte-Julien)<br>
2. Re: LD_PRELOAD applications using lttng-ust-pthread<br>
(Jonathan Rajotte-Julien)<br>
3. Re: LD_PRELOAD applications using lttng-ust-pthread<br>
(Genevieve Bastien)<br>
4. [PATCH lttng-modules 3/3] Fix: Update btrfs instrumentation<br>
for v4.15 (Michael Jeanson)<br>
5. [PATCH lttng-modules 2/3] Update kvm instrumentation for<br>
debian kernel 4.9.65-3 (Michael Jeanson)<br>
6. [PATCH lttng-modules 1/3] Fix: debian kernel version parsing<br>
(Michael Jeanson)<br>
7. Re: [PATCH lttng-modules 3/3] Fix: Update btrfs<br>
instrumentation for v4.15 (Mathieu Desnoyers)<br>
<br>
<br>
------------------------------<wbr>------------------------------<wbr>----------<br>
<br>
Message: 1<br>
Date: Tue, 9 Jan 2018 10:43:51 -0500<br>
From: Jonathan Rajotte-Julien <<a href="mailto:jonathan.rajotte-julien@efficios.com" target="_blank">jonathan.rajotte-julien@effic<wbr>ios.com</a>><br>
To: Majid Rezazadeh <<a href="mailto:majid3612@gmail.com" target="_blank">majid3612@gmail.com</a>><br>
Cc: <a href="mailto:lttng-dev@lists.lttng.org" target="_blank">lttng-dev@lists.lttng.org</a><br>
Subject: Re: [lttng-dev] LD_PRELOAD applications using<br>
lttng-ust-pthread<br>
Message-ID: <20180109154351.GA17950@joraj-<wbr>alpa><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
Hi,<br>
<br>
On Mon, Jan 08, 2018 at 10:35:39PM -0500, Majid Rezazadeh wrote:<br>
> Hi all<br>
><br>
> I am using lttng-ust-libc-wrapper for instrumenting some calls to libc for<br>
> some applications like Firefox and Chrome, but I receive "Segmentation<br>
> fault (core dumped)". I compile lttng-ust-pthread.c (gcc -fPIC -shared -o<br>
> test.so lttng-ust-pthread.c -ldl) and then I use "LD_PRELOAD=test.so<br>
> firefox" but I receive segmentation fault (I have exported LD_LIBRARY_PATH<br>
> to the absolute path of test.so file). I found out that when I replace<br>
<br>
Could you give us more information regarding the coredump?<br>
<br>
"thread apply all bt" in gdb with the corefile loaded.<br>
<br>
Make sure to compile with debug symbol and rerun your test.<br>
<br>
> tracepoints with printf in lttng_ust_pthread.c, I receive no error. It<br>
> seems that hooking tracepoints in this wrapper makes some problems. Do you<br>
> have any idea in this regard?<br>
><br>
> Thanks<br>
><br>
> Majid<br>
<br>
> ______________________________<wbr>_________________<br>
> lttng-dev mailing list<br>
> <a href="mailto:lttng-dev@lists.lttng.org" target="_blank">lttng-dev@lists.lttng.org</a><br>
> <a href="https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev" rel="noreferrer" target="_blank">https://lists.lttng.org/cgi-bi<wbr>n/mailman/listinfo/lttng-dev</a><br>
<br>
<br>
--<br>
Jonathan Rajotte-Julien<br>
EfficiOS<br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Tue, 9 Jan 2018 10:47:10 -0500<br>
From: Jonathan Rajotte-Julien <<a href="mailto:jonathan.rajotte-julien@efficios.com" target="_blank">jonathan.rajotte-julien@effic<wbr>ios.com</a>><br>
To: Majid Rezazadeh <<a href="mailto:majid3612@gmail.com" target="_blank">majid3612@gmail.com</a>><br>
Cc: <a href="mailto:lttng-dev@lists.lttng.org" target="_blank">lttng-dev@lists.lttng.org</a><br>
Subject: Re: [lttng-dev] LD_PRELOAD applications using<br>
lttng-ust-pthread<br>
Message-ID: <20180109154710.GB17950@joraj-<wbr>alpa><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
On Tue, Jan 09, 2018 at 10:43:51AM -0500, Jonathan Rajotte-Julien wrote:<br>
> Hi,<br>
><br>
> On Mon, Jan 08, 2018 at 10:35:39PM -0500, Majid Rezazadeh wrote:<br>
> > Hi all<br>
> ><br>
> > I am using lttng-ust-libc-wrapper for instrumenting some calls to libc for<br>
> > some applications like Firefox and Chrome, but I receive "Segmentation<br>
> > fault (core dumped)". I compile lttng-ust-pthread.c (gcc -fPIC -shared -o<br>
> > test.so lttng-ust-pthread.c -ldl) and then I use "LD_PRELOAD=test.so<br>
> > firefox" but I receive segmentation fault (I have exported LD_LIBRARY_PATH<br>
> > to the absolute path of test.so file). I found out that when I replace<br>
><br>
> Could you give us more information regarding the coredump?<br>
><br>
> "thread apply all bt" in gdb with the corefile loaded.<br>
><br>
> Make sure to compile with debug symbol and rerun your test.<br>
<br>
Forgot to mention that you should open a bug here:<br>
<br>
<a href="https://bugs.lttng.org/" rel="noreferrer" target="_blank">https://bugs.lttng.org/</a><br>
<br>
Make sure to read the bug reporting guidelines.<br>
<br>
Cheers!<br>
<br>
--<br>
Jonathan Rajotte-Julien<br>
EfficiOS<br>
<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Tue, 9 Jan 2018 10:34:18 -0500<br>
From: Genevieve Bastien <<a href="mailto:gbastien%2Blttng@versatic.net" target="_blank">gbastien+lttng@versatic.net</a>><br>
To: <a href="mailto:lttng-dev@lists.lttng.org" target="_blank">lttng-dev@lists.lttng.org</a><br>
Subject: Re: [lttng-dev] LD_PRELOAD applications using<br>
lttng-ust-pthread<br>
Message-ID: <<a href="mailto:bfd757ed-4b3e-1294-f476-34a2b373acac@versatic.net" target="_blank">bfd757ed-4b3e-1294-f476-34a2b<wbr>373acac@versatic.net</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi Majid,<br>
<br>
<br>
See the documentation here:<br>
<a href="http://lttng.org/docs/v2.10/#doc-using-lttng-ust-with-daemons" rel="noreferrer" target="_blank">http://lttng.org/docs/v2.10/#d<wbr>oc-using-lttng-ust-with-daemon<wbr>s</a> and<br>
<a href="http://lttng.org/docs/v2.10/#doc-liblttng-ust-fd" rel="noreferrer" target="_blank">http://lttng.org/docs/v2.10/#d<wbr>oc-liblttng-ust-fd</a>. Firefox requires at<br>
least one of those extra libraries to be preloaded, the one for fork I<br>
think.<br>
<br>
<br>
I recall trying to trace firefox with lttng-cyg-profile without much<br>
success. Without the liblttng-ust-fork.so preloaded, my tabs had<br>
segfaults. But when I tried with both libraries, it seemed there was a<br>
conflict between cyg-profile and the other preloaded libraries, I don't<br>
remember exactly what happened. Maybe you won't have this problem with<br>
lttng-ust-libc-wrapper.<br>
<br>
<br>
I hope this helps,<br>
<br>
Geneviève<br>
<br>
<br>
On 2018-01-08 10:35 PM, Majid Rezazadeh wrote:<br>
> Hi all<br>
><br>
> I am using lttng-ust-libc-wrapper for instrumenting some calls to libc<br>
> for some applications like Firefox and Chrome, but I receive<br>
> "Segmentation fault (core dumped)". I compile lttng-ust-pthread.c (gcc<br>
> -fPIC -shared -o test.so lttng-ust-pthread.c -ldl) and then I use<br>
> "LD_PRELOAD=test.so firefox" but I receive segmentation fault (I have<br>
> exported LD_LIBRARY_PATH to the absolute path of test.so file). I<br>
> found out that when I replace tracepoints with printf in<br>
> lttng_ust_pthread.c, I receive no error. It seems that hooking<br>
> tracepoints in this wrapper makes some problems. Do you have any idea<br>
> in this regard?<br>
><br>
> Thanks<br>
><br>
> Majid<br>
><br>
><br>
> ______________________________<wbr>_________________<br>
> lttng-dev mailing list<br>
> <a href="mailto:lttng-dev@lists.lttng.org" target="_blank">lttng-dev@lists.lttng.org</a><br>
> <a href="https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev" rel="noreferrer" target="_blank">https://lists.lttng.org/cgi-bi<wbr>n/mailman/listinfo/lttng-dev</a><br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.lttng.org/pipermail/lttng-dev/attachments/20180109/3b570b98/attachment-0001.html" rel="noreferrer" target="_blank">https://lists.lttng.org/piper<wbr>mail/lttng-dev/attachments/<wbr>20180109/3b570b98/attachment-<wbr>0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Tue, 9 Jan 2018 15:43:21 -0500<br>
From: Michael Jeanson <<a href="mailto:mjeanson@efficios.com" target="_blank">mjeanson@efficios.com</a>><br>
To: <a href="mailto:lttng-dev@lists.lttng.org" target="_blank">lttng-dev@lists.lttng.org</a><br>
Subject: [lttng-dev] [PATCH lttng-modules 3/3] Fix: Update btrfs<br>
instrumentation for v4.15<br>
Message-ID: <<a href="mailto:1515530601-19259-3-git-send-email-mjeanson@efficios.com" target="_blank">1515530601-19259-3-git-send-e<wbr>mail-mjeanson@efficios.com</a>><br>
<br>
See upstream commit:<br>
<br>
commit d278850eff3053ef166cf64c16f798<wbr>dfe36278a2<br>
Author: Josef Bacik <<a href="mailto:josef@toxicpanda.com" target="_blank">josef@toxicpanda.com</a>><br>
Date: Fri Sep 29 15:43:57 2017 -0400<br>
<br>
btrfs: remove delayed_ref_node from ref_head<br>
<br>
This is just excessive information in the ref_head, and makes the code<br>
complicated. It is a relic from when we had the heads and the refs in<br>
the same tree, which is no longer the case. With this removal I've<br>
cleaned up a bunch of the cruft around this old assumption as well.<br>
<br>
Signed-off-by: Michael Jeanson <<a href="mailto:mjeanson@efficios.com" target="_blank">mjeanson@efficios.com</a>><br>
---<br>
instrumentation/events/lttng-<wbr>module/btrfs.h | 18 +++++++++++++++++-<br>
1 file changed, 17 insertions(+), 1 deletion(-)<br>
<br>
diff --git a/instrumentation/events/lttng<wbr>-module/btrfs.h b/instrumentation/events/lttng<wbr>-module/btrfs.h<br>
index b529e8e..7901f05 100644<br>
--- a/instrumentation/events/lttng<wbr>-module/btrfs.h<br>
+++ b/instrumentation/events/lttng<wbr>-module/btrfs.h<br>
@@ -680,7 +680,23 @@ LTTNG_TRACEPOINT_EVENT(btrfs_d<wbr>elayed_data_ref,<br>
)<br>
)<br>
<br>
-#if (LINUX_VERSION_CODE >= KERNEL_VERSION(4,8,0))<br>
+#if (LINUX_VERSION_CODE >= KERNEL_VERSION(4,15,0))<br>
+LTTNG_TRACEPOINT_EVENT(btrfs_<wbr>delayed_ref_head,<br>
+<br>
+ TP_PROTO(struct btrfs_fs_info *fs_info,<br>
+ struct btrfs_delayed_ref_head *head_ref,<br>
+ int action),<br>
+<br>
+ TP_ARGS(fs_info, head_ref, action),<br>
+<br>
+ TP_FIELDS(<br>
+ ctf_integer(u64, bytenr, head_ref->bytenr)<br>
+ ctf_integer(u64, num_bytes, head_ref->num_bytes)<br>
+ ctf_integer(int, action, action)<br>
+ ctf_integer(int, is_data, head_ref->is_data)<br>
+ )<br>
+)<br>
+#elif (LINUX_VERSION_CODE >= KERNEL_VERSION(4,8,0))<br>
LTTNG_TRACEPOINT_EVENT(btrfs_<wbr>delayed_ref_head,<br>
<br>
TP_PROTO(struct btrfs_fs_info *fs_info,<br>
--<br>
2.7.4<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Tue, 9 Jan 2018 15:43:20 -0500<br>
From: Michael Jeanson <<a href="mailto:mjeanson@efficios.com" target="_blank">mjeanson@efficios.com</a>><br>
To: <a href="mailto:lttng-dev@lists.lttng.org" target="_blank">lttng-dev@lists.lttng.org</a><br>
Subject: [lttng-dev] [PATCH lttng-modules 2/3] Update kvm<br>
instrumentation for debian kernel 4.9.65-3<br>
Message-ID: <<a href="mailto:1515530601-19259-2-git-send-email-mjeanson@efficios.com" target="_blank">1515530601-19259-2-git-send-e<wbr>mail-mjeanson@efficios.com</a>><br>
<br>
Signed-off-by: Michael Jeanson <<a href="mailto:mjeanson@efficios.com" target="_blank">mjeanson@efficios.com</a>><br>
---<br>
instrumentation/events/lttng-<wbr>module/kvm.h | 3 ++-<br>
1 file changed, 2 insertions(+), 1 deletion(-)<br>
<br>
diff --git a/instrumentation/events/lttng<wbr>-module/kvm.h b/instrumentation/events/lttng<wbr>-module/kvm.h<br>
index ea63e88..d9d0300 100644<br>
--- a/instrumentation/events/lttng<wbr>-module/kvm.h<br>
+++ b/instrumentation/events/lttng<wbr>-module/kvm.h<br>
@@ -86,7 +86,8 @@ LTTNG_TRACEPOINT_EVENT(kvm_ack<wbr>_irq,<br>
<br>
#if (LINUX_VERSION_CODE >= KERNEL_VERSION(4,15,0) \<br>
|| LTTNG_KERNEL_RANGE(3,16,52, 3,17,0) \<br>
- || LTTNG_KERNEL_RANGE(3,2,97, 3,3,0))<br>
+ || LTTNG_KERNEL_RANGE(3,2,97, 3,3,0) \<br>
+ || LTTNG_DEBIAN_KERNEL_RANGE(4,9,<wbr>65,0,3,0, 4,10,0,0,0,0))<br>
<br>
LTTNG_TRACEPOINT_EVENT(kvm_mm<wbr>io,<br>
TP_PROTO(int type, int len, u64 gpa, void *val),<br>
--<br>
2.7.4<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 6<br>
Date: Tue, 9 Jan 2018 15:43:19 -0500<br>
From: Michael Jeanson <<a href="mailto:mjeanson@efficios.com" target="_blank">mjeanson@efficios.com</a>><br>
To: <a href="mailto:lttng-dev@lists.lttng.org" target="_blank">lttng-dev@lists.lttng.org</a><br>
Subject: [lttng-dev] [PATCH lttng-modules 1/3] Fix: debian kernel<br>
version parsing<br>
Message-ID: <<a href="mailto:1515530601-19259-1-git-send-email-mjeanson@efficios.com" target="_blank">1515530601-19259-1-git-send-e<wbr>mail-mjeanson@efficios.com</a>><br>
<br>
The debian version script only worked for ckt kernels and that was fine<br>
until now because we only had checks for those versions in the code.<br>
<br>
ckt (Canonical Kernel Team) kernels were used for a while during the jessie<br>
cycle, their versionning is a bit different. They track the upstream vanilla<br>
stable updates but they don't update the minor version number and instead add<br>
an additionnal -cktX. They were all 3.16.7-cktX and after a while the version<br>
switched back to upstream style at 3.16.36.<br>
<br>
Knowing that, we can compare regular debian and ckt kernel versions<br>
using this scheme :<br>
<br>
MAJOR.PATCHLEVEL.SUBLEVEL.CKT.<wbr>DEBABI.DEBPATCH<br>
<br>
And setting CKT to zero for non-ckt kernels.<br>
<br>
Signed-off-by: Michael Jeanson <<a href="mailto:mjeanson@efficios.com" target="_blank">mjeanson@efficios.com</a>><br>
---<br>
abi-debian-version.sh | 18 ++++++++++--------<br>
1 file changed, 10 insertions(+), 8 deletions(-)<br>
<br>
diff --git a/abi-debian-version.sh b/abi-debian-version.sh<br>
index 310d6a8..36da212 100755<br>
--- a/abi-debian-version.sh<br>
+++ b/abi-debian-version.sh<br>
@@ -12,24 +12,26 @@ fi<br>
<br>
# Assuming KPATH is the target kernel headers directory<br>
DEB_PACKAGE_VERSION=$(sed -rn 's/^#define LINUX_PACKAGE_ID " Debian (.*)"/\1/p' ${KPATH}/include/generated/pac<wbr>kage.h)<br>
+<br>
# Ignore backports part<br>
DEB_PACKAGE_VERSION=$(echo ${DEB_PACKAGE_VERSION} | sed -r 's/~(bpo|deb).*//')<br>
+<br>
+# ckt (Canonical Kernel Team) kernels were used for a while during the jessie<br>
+# cycle, their versionning is a bit different. They track the upstream vanilla<br>
+# stable updates but they don't update the minor version number and instead add<br>
+# an additionnal -cktX. They were all 3.16.7-cktX and after a while the version<br>
+# switched back to upstream style at 3.16.36.<br>
+<br>
# Get -ckt update number, if present<br>
KERNEL_CKT_UPDATE=$(echo ${DEB_PACKAGE_VERSION} | sed -rn 's/^[0-9]+\.[0-9]+\.[0-9]+-ckt<wbr>([0-9]+).*/\1/p')<br>
-<br>
-# Only care about the rest if it is a -ckt kernel, making sure we do not<br>
-# clash with older Debian kernels (e.g. Debian 3.2.65-1+deb7u2).<br>
-if [ -z "${KERNEL_CKT_UPDATE}" ]; then<br>
- echo 0<br>
- exit 0<br>
-fi<br>
+test -n "${KERNEL_CKT_UPDATE}" || KERNEL_CKT_UPDATE=0<br>
<br>
# Get package revision<br>
DEB_PACKAGE_REVISION=$(echo ${DEB_PACKAGE_VERSION} | sed -r 's/.*-([^-]+)$/\1/')<br>
# Get non-sec update number<br>
DEB_PACKAGE_REVISION_BASE=$(e<wbr>cho ${DEB_PACKAGE_REVISION} | sed -r 's/^([0-9]+).*/\1/')<br>
# Get security update number, if present<br>
-DEB_PACKAGE_REVISION_SECURITY<wbr>=$(echo ${DEB_PACKAGE_REVISION} | sed -rn 's/.*\+(squeeze|deb[0-9])+u([0<wbr>-9]+)$/\1/p')<br>
+DEB_PACKAGE_REVISION_SECURITY<wbr>=$(echo ${DEB_PACKAGE_REVISION} | sed -rn 's/.*\+(squeeze|deb[0-9]+)+u([<wbr>0-9]+)$/\2/p')<br>
test -n "${DEB_PACKAGE_REVISION_SECURI<wbr>TY}" || DEB_PACKAGE_REVISION_SECURITY=<wbr>0<br>
# Combine all update numbers into one<br>
DEB_API_VERSION=$((KERNEL_<wbr>CKT_UPDATE * 10000 + DEB_PACKAGE_REVISION_BASE * 100 + DEB_PACKAGE_REVISION_SECURITY)<wbr>)<br>
--<br>
2.7.4<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 7<br>
Date: Tue, 9 Jan 2018 21:29:55 +0000 (UTC)<br>
From: Mathieu Desnoyers <<a href="mailto:mathieu.desnoyers@efficios.com" target="_blank">mathieu.desnoyers@efficios.co<wbr>m</a>><br>
To: Michael Jeanson <<a href="mailto:mjeanson@efficios.com" target="_blank">mjeanson@efficios.com</a>><br>
Cc: lttng-dev <<a href="mailto:lttng-dev@lists.lttng.org" target="_blank">lttng-dev@lists.lttng.org</a>><br>
Subject: Re: [lttng-dev] [PATCH lttng-modules 3/3] Fix: Update btrfs<br>
instrumentation for v4.15<br>
Message-ID:<br>
<<a href="mailto:2113123048.49851.1515533395136.JavaMail.zimbra@efficios.com" target="_blank">2113123048.49851.151553339513<wbr>6.JavaMail.zimbra@efficios.com</a><wbr>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
----- On Jan 9, 2018, at 3:43 PM, Michael Jeanson <a href="mailto:mjeanson@efficios.com" target="_blank">mjeanson@efficios.com</a> wrote:<br>
<br>
> See upstream commit:<br>
><br>
> commit d278850eff3053ef166cf64c16f798<wbr>dfe36278a2<br>
> Author: Josef Bacik <<a href="mailto:josef@toxicpanda.com" target="_blank">josef@toxicpanda.com</a>><br>
> Date: Fri Sep 29 15:43:57 2017 -0400<br>
><br>
> btrfs: remove delayed_ref_node from ref_head<br>
><br>
> This is just excessive information in the ref_head, and makes the code<br>
> complicated. It is a relic from when we had the heads and the refs in<br>
> the same tree, which is no longer the case. With this removal I've<br>
> cleaned up a bunch of the cruft around this old assumption as well.<br>
<br>
In 3.12, this becomes a DECLARE_EVENT_CLASS with associated DEFINE_EVENT<br>
using the class. Example code snippet from a 4.15-rc kernel:<br>
<br>
DECLARE_EVENT_CLASS(btrfs_dela<wbr>yed_ref_head,<br>
<br>
TP_PROTO(const struct btrfs_fs_info *fs_info,<br>
const struct btrfs_delayed_ref_head *head_ref,<br>
int action),<br>
<br>
TP_ARGS(fs_info, head_ref, action),<br>
<br>
TP_STRUCT__entry_btrfs(<br>
__field( u64, bytenr )<br>
__field( u64, num_bytes )<br>
__field( int, action )<br>
__field( int, is_data )<br>
),<br>
<br>
TP_fast_assign_btrfs(fs_info,<br>
__entry->bytenr = head_ref->bytenr;<br>
__entry->num_bytes = head_ref->num_bytes;<br>
__entry->action = action;<br>
__entry->is_data = head_ref->is_data;<br>
),<br>
<br>
TP_printk_btrfs("bytenr=%llu num_bytes=%llu action=%s is_data=%d",<br>
(unsigned long long)__entry->bytenr,<br>
(unsigned long long)__entry->num_bytes,<br>
show_ref_action(__entry->actio<wbr>n),<br>
__entry->is_data)<br>
);<br>
<br>
DEFINE_EVENT(btrfs_delayed_ref<wbr>_head, add_delayed_ref_head,<br>
<br>
TP_PROTO(const struct btrfs_fs_info *fs_info,<br>
const struct btrfs_delayed_ref_head *head_ref,<br>
int action),<br>
<br>
TP_ARGS(fs_info, head_ref, action)<br>
);<br>
<br>
DEFINE_EVENT(btrfs_delayed_ref<wbr>_head, run_delayed_ref_head,<br>
<br>
TP_PROTO(const struct btrfs_fs_info *fs_info,<br>
const struct btrfs_delayed_ref_head *head_ref,<br>
int action),<br>
<br>
TP_ARGS(fs_info, head_ref, action)<br>
);<br>
<br>
It appears that this instrumentation has not been hooked on any actual<br>
tracepoint for quite some time in lttng-modules.<br>
<br>
We should adapt the lttng-modules instrumentation accordingly. I would<br>
not be surprised that the 4.8.0 kernel version range is also incorrect:<br>
it should apply to the "new" events based on the tracepoint class.<br>
<br>
Thanks,<br>
<br>
Mathieu<br>
<br>
><br>
> Signed-off-by: Michael Jeanson <<a href="mailto:mjeanson@efficios.com" target="_blank">mjeanson@efficios.com</a>><br>
> ---<br>
> instrumentation/events/lttng-m<wbr>odule/btrfs.h | 18 +++++++++++++++++-<br>
> 1 file changed, 17 insertions(+), 1 deletion(-)<br>
><br>
> diff --git a/instrumentation/events/lttng<wbr>-module/btrfs.h<br>
> b/instrumentation/events/lttng<wbr>-module/btrfs.h<br>
> index b529e8e..7901f05 100644<br>
> --- a/instrumentation/events/lttng<wbr>-module/btrfs.h<br>
> +++ b/instrumentation/events/lttng<wbr>-module/btrfs.h<br>
> @@ -680,7 +680,23 @@ LTTNG_TRACEPOINT_EVENT(btrfs_d<wbr>elayed_data_ref,<br>
> )<br>
> )<br>
><br>
> -#if (LINUX_VERSION_CODE >= KERNEL_VERSION(4,8,0))<br>
> +#if (LINUX_VERSION_CODE >= KERNEL_VERSION(4,15,0))<br>
> +LTTNG_TRACEPOINT_EVENT(btrfs_<wbr>delayed_ref_head,<br>
> +<br>
> + TP_PROTO(struct btrfs_fs_info *fs_info,<br>
> + struct btrfs_delayed_ref_head *head_ref,<br>
> + int action),<br>
> +<br>
> + TP_ARGS(fs_info, head_ref, action),<br>
> +<br>
> + TP_FIELDS(<br>
> + ctf_integer(u64, bytenr, head_ref->bytenr)<br>
> + ctf_integer(u64, num_bytes, head_ref->num_bytes)<br>
> + ctf_integer(int, action, action)<br>
> + ctf_integer(int, is_data, head_ref->is_data)<br>
> + )<br>
> +)<br>
> +#elif (LINUX_VERSION_CODE >= KERNEL_VERSION(4,8,0))<br>
> LTTNG_TRACEPOINT_EVENT(btrfs_d<wbr>elayed_ref_head,<br>
><br>
> TP_PROTO(struct btrfs_fs_info *fs_info,<br>
> --<br>
> 2.7.4<br>
<br>
--<br>
Mathieu Desnoyers<br>
EfficiOS Inc.<br>
<a href="http://www.efficios.com" rel="noreferrer" target="_blank">http://www.efficios.com</a><br>
<br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
______________________________<wbr>_________________<br>
lttng-dev mailing list<br>
<a href="mailto:lttng-dev@lists.lttng.org" target="_blank">lttng-dev@lists.lttng.org</a><br>
<a href="https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev" rel="noreferrer" target="_blank">https://lists.lttng.org/cgi-bi<wbr>n/mailman/listinfo/lttng-dev</a><br>
<br>
<br>
------------------------------<br>
<br>
End of lttng-dev Digest, Vol 117, Issue 3<br>
******************************<wbr>***********<br>
</blockquote></div><br></div></div>