Re: Is this a bug from function kernel_int?

[David Smith <dsmith at redhat dot com>]

OK, let's try this again.

You got a huge value from kernel_int(). Why did you get that big
value? Sign extension. 18446744072649393666 is 0xffffffffc0cf4602.
Internally in systemtap, all numeric values are long longs (if I
remember correctly). So, when that signed 32-bit value gets put in a
long long, it gets sign extended.

Now, the next issue with your code is that you aren't handling the
sign correctly. At least in the 4.19 kernel source, in net/tcp.h I see
the following:

    __u32 end_seq; /* SEQ + FIN + SYN + datalen */

So, end_seq is an unsigned 32-bit value, not a signed 32-bit value.
Strangely enough, we don't have a kernel_uint() function. But, you
could do something like:

  __uint32(*kernel_int(&*@cast($skb->cb, "tcp_skb_cb",
"kernel<net/tcp.h>")->end_seq))

But, to tell you the truth, I've forgotten all the details of
@cast()/kernel_int() and I'm not 100% sure you need the kernel_int()
in the first place.

On Sun, Jan 20, 2019 at 3:49 AM Yue Cao <yuecao1990@gmail.com> wrote:
>
> Hi there,
>
> Recently I find systemtap generates a wrong result when I use kernel_int to
> print out the int value from the pointer. In my case, systemtap prints out
> a huge value (18446744072649393666) with kernel_int. As you can see, this
> value is larger than 2^32 (the maximal value for int). However, when I use
> kernel_long, the result is within 2^32. The new value (3234809346) actually
> is equal to what I expected by using kernel_int. I have tried multiple
> times and the results are same. I wonder is it a bug. Could anyone tell me
> how to fix it?
>
> Here is another example that I have used to reproduce the error above. The
> following two values are supposed to be same. But the first value returns
> (18446744072649393666), while the second one returns (3234809346), which is
> the expected value.
>  *kernel_int(&*@cast($skb->cb, "tcp_skb_cb", "kernel<net/tcp.h>")->end_seq)
> @cast($skb->cb, "tcp_skb_cb", "kernel<net/tcp.h>")->end_seq
>
> Looking forward to your reply.
>
> Best,
> Yue
>
>


-- 
David Smith
Associate Manager
Red Hat