iptfs_pskb_extract_seq(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

✨ NAME ✨

iptfs_pskb_extract_seq β€” bestie, this is the one that makes a brand new sk_buff and then loads it up with data. πŸ’…

(oh also, hi, you're reading the Kernel API Manual page for it, section 9 β€” very demure, very kernel of you πŸŽ€)


🌸 SYNOPSIS 🌸

struct sk_buff * iptfs_pskb_extract_seq (u32 skblen , struct
       skb_seq_state *st , u32 off , int len );

Yes the line wraps weirdly, no I did not do that, that's just how it's printed, leave her alone 😭


πŸ’… ARGUMENTS πŸ’…

  • skblen β€” the total data size for skb. Like, the whole capacity of the thing you're building. πŸ“
  • st β€” the source for the rest of the data to copy into skb. This is where the good stuff lives. 🫢
  • off β€” the offset into st to copy data from. Where you start scooping. πŸ₯„
  • len β€” the length of data to copy from st into skb. ⚠️ And listen: this must be <= skblen. Not a vibe if it isn't, okay?

πŸ¦‹ DESCRIPTION πŸ¦‹

Okay so here's the whole situation, bestie. πŸ’–

First, iptfs_pskb_extract_seq creates a new sk_buff called skb, and it gives it skblen worth of packet data space. Fresh out the box, iconic.

Then β€” and this is the little plot twist β€” if non-zero, it copies rlen bytes of runt into skb. Runt data said "I'm coming too" and honestly? Slay. ✨

After that, it uses the seq functions to copy len bytes out of st and into skb, starting from off. So like: off is your starting point, len is how much you're hauling over, and st is the source it's all coming from. 🌈

⚠️ Heads up: it is an error for len to be greater than the amount of data left in st. Like, you cannot pull more than what's there. The math has to math. πŸ’€

πŸŽ€ RETURN πŸŽ€

You get back the newly allocated sk_buff skb πŸ₯³ β€” or NULL if an error occurs, in which case, no skb for you, sorry babe. πŸ™ˆ


πŸ’– SEE ALSO πŸ’–

Kernel file ./net/xfrm/xfrm_iptfs.c β€” go read the actual source, it's giving main character energy πŸ‘‘

IPTFS_DEFAULT_DROP_TIME_USECS(9), IPTFS_DEFAULT_REORDER_WINDOW(9), IPTFS_DEFAULT_INIT_DELAY_USECS(9), IPTFS_DEFAULT_MAX_QUEUE_SIZE(9), struct xfrm_iptfs_config(9), struct xfrm_iptfs_data(9), iptfs_alloc_skb(9), iptfs_skb_head_to_frag(9), struct iptfs_skb_frag_walk(9), iptfs_skb_prepare_frag_walk(9), iptfs_skb_can_add_frags(9), iptfs_skb_add_frags(9), iptfs_pskb_add_frags(9), iptfs_input_save_runt(9), __iptfs_iphlen(9), __iptfs_iplen(9), iptfs_complete_inner_skb(9), iptfs_reassem_abort(9), iptfs_reassem_done(9), iptfs_reassem_cont(9), iptfs_input_ordered(9), iptfs_drop_timer(9), iptfs_input(9), iptfs_enqueue(9), iptfs_copy_create_frag(9), iptfs_copy_create_frags(9), iptfs_first_skb(9), iptfs_encap_add_ipv4(9), iptfs_encap_add_ipv6(9), iptfs_prepare_output(9), __iptfs_get_inner_mtu(9), iptfs_get_inner_mtu(9), iptfs_user_init(9)

That's the whole friends list, no cap. Go read them all, iykyk πŸ¦‹


✿ and that's the page! ✿ brought to you by ./net/xfrm, dated October 2026, and filed under iptfs_pskb_extract_seq(9) β€” mwah, ily, now go build that skb πŸ’œπŸŒΈπŸŽ€

πŸ“¦ where this page comes from