DATAREF AND HEADERLESS SKBS(9)

📦 version 7.3.1, in nixpkgs unstable

💅 dataref and headerless skbs (9) 💅

okay bestie, welcome to the Kernel API Manual page for dataref and headerless skbs — section 9, and yes it's giving “low-level skb lore,” but we're gonna get through it together 🫶

Transport layers send out clones of payload skbs they hold for retransmissions. To allow lower layers of the stack to prepend their headers, we split skb_shared_info.dataref into two halves. The lower 16 bits count the overall number of references. The higher 16 bits indicate how many of the references are payload-only. skb_header_cloned checks if skb is allowed to add / write the headers ✨

The creator of the skb (e.g. TCP) marks its skb as sk_buff.nohdr (via __skb_header_release). Any clone created from marked skb will get sk_buff.hdr_len populated with the available headroom. If there's the only clone in existence it's able to modify the headroom at will. The sequence of calls inside the transport layer is:

 <alloc skb>
 skb_reserve
 __skb_header_release
 skb_clone
 // send the clone down the stack
⚠️ lowkey important: This is not a very generic construct and it depends on the transport layers doing the right thing. In practice there's usually only one payload-only skb. Having multiple payload-only skbs with different lengths of hdr_len is not possible. The payload-only skbs should never leave their owner — like, never ever. that part is not a vibe, it's a rule 🚨

👀 SEE ALSO 👀

Kernel file ./include/linux/skbuff.h — and yeah, here's the whole skb bestie network linked out for you:

mwah 💖 that's the whole page, bestie — source/version: ./include/linux · date: October 2026 · page: dataref and headerless skbs(9) 🎀

📦 where this page comes from