* Tapset porting to 2.6.38
@ 2011-03-14 16:06 Turgis, Frederic
2011-03-14 21:05 ` David Smith
2011-03-14 21:25 ` Frank Ch. Eigler
0 siblings, 2 replies; 6+ messages in thread
From: Turgis, Frederic @ 2011-03-14 16:06 UTC (permalink / raw)
To: Turgis, Frederic, systemtap
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)"
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)
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Tapset porting to 2.6.38
2011-03-14 16:06 Tapset porting to 2.6.38 Turgis, Frederic
@ 2011-03-14 21:05 ` David Smith
2011-03-14 22:41 ` Turgis, Frederic
2011-03-14 21:25 ` Frank Ch. Eigler
1 sibling, 1 reply; 6+ messages in thread
From: David Smith @ 2011-03-14 21:05 UTC (permalink / raw)
To: Turgis, Frederic; +Cc: systemtap
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)
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Tapset porting to 2.6.38
2011-03-14 16:06 Tapset porting to 2.6.38 Turgis, Frederic
2011-03-14 21:05 ` David Smith
@ 2011-03-14 21:25 ` Frank Ch. Eigler
1 sibling, 0 replies; 6+ messages in thread
From: Frank Ch. Eigler @ 2011-03-14 21:25 UTC (permalink / raw)
To: Turgis, Frederic; +Cc: systemtap
Hi -
f-turgis wrote:
> 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. [...]
> [...] commit 68835aba4d9b74e2f94106d13b6a4bddc447c4c8 [...]
> impacts "function __ip_sock_saddr:long (sock:long)"
> - __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
> [...]
This should be handleable by something like extending the current
@defined conditional there with another alternative, as in:
@defined(@cast(sock,"inet_sock","kernel<net/ip.h>")->__sk_common->skc_daddr) ?
@cast(sock,"inet_sock","kernel<net/ip.h>")->__sk_common->skc_daddr) :
[...whatever else...]
- FChE
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: Tapset porting to 2.6.38
2011-03-14 21:05 ` David Smith
@ 2011-03-14 22:41 ` Turgis, Frederic
2011-03-15 16:15 ` David Smith
0 siblings, 1 reply; 6+ messages in thread
From: Turgis, Frederic @ 2011-03-14 22:41 UTC (permalink / raw)
To: David Smith; +Cc: systemtap
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)
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Tapset porting to 2.6.38
2011-03-14 22:41 ` Turgis, Frederic
@ 2011-03-15 16:15 ` David Smith
2011-03-15 16:44 ` Turgis, Frederic
0 siblings, 1 reply; 6+ messages in thread
From: David Smith @ 2011-03-15 16:15 UTC (permalink / raw)
To: Turgis, Frederic; +Cc: systemtap
On 03/14/2011 05:40 PM, Turgis, Frederic wrote:
> 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).
That has confused people before. In systemtap script language, you
always just use '->'.
If you want to see the C source code that systemtap produces for
__ip_sock_daddr(), you can do the following:
# stap -vp3 -e 'probe begin { print(__ip_sock_daddr(0)) }'
> 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".
Hmm, I'm not aware of any issues we have with enums. Have you got an
example?
--
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: Tapset porting to 2.6.38
2011-03-15 16:15 ` David Smith
@ 2011-03-15 16:44 ` Turgis, Frederic
0 siblings, 0 replies; 6+ messages in thread
From: Turgis, Frederic @ 2011-03-15 16:44 UTC (permalink / raw)
To: David Smith; +Cc: systemtap
Hi,
We spent time looking at generated code to debug some "pure" code but dereferencing was such a myth internally (bad habit from C) that we never had a deeper look :-(
I meant union and not enum. Of course, now that I know better, I can't figure out the example again. Not even sure it was related to V4L2 even if this is where we have mostly used it like: "@cast($q, "videobuf_queue")->bufs[@cast($b, "v4l2_buffer")->index]->baddr"
I will keep looking in our drivers related to V4L2
Regards
Fred
Frederic Turgis
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: Tuesday, March 15, 2011 5:15 PM
To: Turgis, Frederic
Cc: systemtap@sourceware.org
Subject: Re: Tapset porting to 2.6.38
On 03/14/2011 05:40 PM, Turgis, Frederic wrote:
> 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).
That has confused people before. In systemtap script language, you always just use '->'.
If you want to see the C source code that systemtap produces for __ip_sock_daddr(), you can do the following:
# stap -vp3 -e 'probe begin { print(__ip_sock_daddr(0)) }'
> 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".
Hmm, I'm not aware of any issues we have with enums. Have you got an example?
--
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-03-15 16:44 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-03-14 16:06 Tapset porting to 2.6.38 Turgis, Frederic
2011-03-14 21:05 ` David Smith
2011-03-14 22:41 ` Turgis, Frederic
2011-03-15 16:15 ` David Smith
2011-03-15 16:44 ` Turgis, Frederic
2011-03-14 21:25 ` Frank Ch. Eigler
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).