Using SKB headroom for SsSkbCb

[milabs]

Hello,

Is it possible to make TFW as a LKM without needing of kernel prepatching? As I see it, the patch (apart from other things) extends skb->cb so SsSkbCb resides on it. But taking into account that the SKBs has some headroom groving with increasing of the OSI's layer seems that it is possible to avoid SKB's cb area to extend.

#define TFW_MAGIC   0x54454d5045535441ULL

typedef struct {
    struct sk_buff  *next;
    struct sk_buff  *prev;
    unsigned long   magic;
} SsSkbCb;

#define TFW_SKB_CB(s)       ((SsSkbCb *)(s)->head)

static inline bool ss_skb_passed(const struct sk_buff *skb)
{
    const SsSkbCb *scb = TFW_SKB_CB(skb);
    return (scb->magic == TFW_MAGIC && (scb->next && scb->prev));
}

Any reasons why is it can't be implemented?

[krizhanovsky]

Ilya,

thank you for the interesting question. We need valid SsSkbCb list members also during skb (re-)transmission, so we can't reuse part of headroom used by MAC or IP layers. However, there is NET_SKB_PAD alignment before mac_header which is typically 64 bytes in size, so it seems we can place SsSkbCb at the room.

This is good thing to keep in mind for next releases.

[krizhanovsky]

In fact, we don't need SsSkbCb since Tempesta doesn't use standard skb next and prev linkage as well as remove ingress skbs from the lists such as sk_receive_queue or frag_list, so we can just use standard skb lists instead.

[keshonok]

Uh, yes, indeed. However, my understanding is that the key word here is skb clone.

The major reason for introduction of a separate list of skbs was that Tempesta kept request's data on a list until a paired response came, and at the same time these same skbs were handed to Linux kernel's TCP/IP stack for sending. Thus, an skb could have been a member of a socket queue, and at the same time a member of a message queue. So, as soon as we started passing skb clones to the TCP/IP stack instead of the original skbs, SsSkbCb became unnecessary. Standard skb list members can be used to link skbs that belong to a message.