This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
RE: Tapset porting to 2.6.38
Very interesting patch for us.
We did not dig that much as we were convinced that we could only dereference pointers. Therefore, we thought we could not do something like @cast(sock, "inet_sock")->sk->__sk_common->skc_daddr because in C, it would be pointer->sk.__sk_common.skc_addr (so no pointer as soon as you want __sk_common).
On top of that, we had bad experience in the past with derefencing V4L2 structures but we finally discovered issue was more related to the use of "enum".
That re-opens some perspective, I will play with that tomorrow and share with teams internally.
Regards
Fred
Frederic Turgis
Texas Instruments - OMAP Platform Business Unit - OMAP System Engineering - Platform Enablement
Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920
-----Original Message-----
From: David Smith [mailto:dsmith@redhat.com]
Sent: Monday, March 14, 2011 10:05 PM
To: Turgis, Frederic
Cc: systemtap@sourceware.org
Subject: Re: Tapset porting to 2.6.38
On 03/14/2011 11:06 AM, Turgis, Frederic wrote:
> Hi,
>
> I recently ran the testsuite on Linaro kernel (2.6.38 on ARM dual core
> cortex A9) and found 1 issue coming from 2.6.38 kernel changes. I
> checked this is
not in latest
> snapshot, I don't seem to find it in bug list so here it is in case
nobody has already
> seen it:
>
> - 2.6.38-rc1 has broken tapset/ip.stp by moving inet_daddr parameter
> in struct sk, commit 68835aba4d9b74e2f94106d13b6a4bddc447c4c8
> impacting
include/net/inet_sock.h.
> This impacts "function __ip_sock_saddr:long (sock:long)"
Actually it breaks __ip_sock_daddr(), not __ip_sock_saddr().
> It is doing this:
> - __be32 inet_daddr;
> - __be32 inet_rcv_saddr;
> +#define inet_daddr sk.__sk_common.skc_daddr #define inet_rcv_saddr
> +sk.__sk_common.skc_rcv_saddr
>
>
> As this is not about only dereferencing pointers, I guess reading
> "inet_daddr" will require some "pure" code so I didn't propose
> solution (and it may require kread/CATCH_DEREF_FAULT stuff which I am
> not familiar with although it
is documented)
I just checked in commit 0321f20 which should fix this problem. I was able to use @defined() to see if 'sk.__sk_common.skc_daddr' exists.
Things at least compile now. Let me know if my fix doesn't work for you. Thanks for the bug report.
--
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)