lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAAA3+Bo6RQjhYom0+RPaDvYZJ90NdqgVBFomDMWyc=nsiJm1Tg@mail.gmail.com>
Date:   Fri, 11 Feb 2022 09:53:09 +0800
From:   Yi Li <lovelylich@...il.com>
To:     netdev@...r.kernel.org
Subject: Why skb->data so far from skb->head after skb_reserve?

Hi list,
I am digging on skb layout when tcp send packets throught tcp/ip
stack, but i am stuck on the skb->data now.
I use the net-next branch, and the commit id
6cf7a1ac0fedad8a70c050ade8a27a2071638500, and i think this (problem?)
is not relevant with specific commit id.

Firstly I just used systemtap to digging the routines, but when I
found for every pkt, the data is far way from skb->head, i became
curious.

After add some printk logs and analysis, I found the strange behavior
as follows:

Let's only look at the tcp syn pkt when we do a tcp connection. I have
added many logs , but for simply let's only see root cause, the
following log:

static inline void skb_reserve(struct sk_buff *skb, int len)
{
    printk("%s:%d:  head=%p, data=%p, tail=%d, end=%d, len=%d,
data_len=%d, transport_header=%d, nr_frags=%d\n",
                    __func__, __LINE__, skb->head, skb->data,
skb->tail, skb->end, skb->len, skb->data_len,
                    skb->transport_header, skb_shinfo(skb)->nr_frags);
skb->data += len;
    printk("%s:%d:  head=%p, data=%p, tail=%d, end=%d, len=%d,
data_len=%d, transport_header=%d, nr_frags=%d\n",
                    __func__, __LINE__, skb->head, skb->data,
skb->tail, skb->end, skb->len, skb->data_len,
                    skb->transport_header, skb_shinfo(skb)->nr_frags);
skb->tail += len;
}

And I got the strange result:
[  131.750170] skb_reserve:2453:  head=000000000cfe1b70,
data=000000000cfe1b70, tail=0, end=704, len=0, data_len=0,
transport_header=65535, nr_frags=0
[  131.750173] skb_reserve:2457:  head=000000000cfe1b70,
data=00000000bf8ffb2c, tail=0, end=704, len=0, data_len=0,
transport_header=65535, nr_frags=0

Why the skb->data so far from skb->head, i can't understand. Could you
kindly help me ?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ