From: Eric Dumazet <edumazet@xxxxxxxxxx> commit 479f5547239d970d3833f15f54a6481fffdb91ec upstream. We got reports of following warning in inet_sock_destruct() WARN_ON(sk_forward_alloc_get(sk)); Whenever we add a non zero-copy fragment to a pure zerocopy skb, we have to anticipate that whole skb->truesize will be uncharged when skb is finally freed. skb->data_len is the payload length. But the memory truesize estimated by __zerocopy_sg_from_iter() is page aligned. Fixes: 9b65b17db723 ("net: avoid double accounting for pure zerocopy skbs") Signed-off-by: Eric Dumazet <edumazet@xxxxxxxxxx> Cc: Talal Ahmad <talalahmad@xxxxxxxxxx> Cc: Arjun Roy <arjunroy@xxxxxxxxxx> Cc: Willem de Bruijn <willemb@xxxxxxxxxx> Acked-by: Soheil Hassas Yeganeh <soheil@xxxxxxxxxx> Link: https://lore.kernel.org/r/20220201065254.680532-1-eric.dumazet@xxxxxxxxx Signed-off-by: Jakub Kicinski <kuba@xxxxxxxxxx> Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> --- net/ipv4/tcp.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) --- a/net/ipv4/tcp.c +++ b/net/ipv4/tcp.c @@ -1321,10 +1321,13 @@ new_segment: /* skb changing from pure zc to mixed, must charge zc */ if (unlikely(skb_zcopy_pure(skb))) { - if (!sk_wmem_schedule(sk, skb->data_len)) + u32 extra = skb->truesize - + SKB_TRUESIZE(skb_end_offset(skb)); + + if (!sk_wmem_schedule(sk, extra)) goto wait_for_space; - sk_mem_charge(sk, skb->data_len); + sk_mem_charge(sk, extra); skb_shinfo(skb)->flags &= ~SKBFL_PURE_ZEROCOPY; } Patches currently in stable-queue which might be from edumazet@xxxxxxxxxx are queue-5.16/rtnetlink-make-sure-to-refresh-master_dev-m_ops-in-__rtnl_newlink.patch queue-5.16/tcp-fix-mem-under-charging-with-zerocopy-sendmsg.patch queue-5.16/tcp-add-missing-tcp_skb_can_collapse-test-in-tcp_shift_skb_data.patch queue-5.16/af_packet-fix-data-race-in-packet_setsockopt-packet_setsockopt.patch queue-5.16/net-sched-fix-use-after-free-in-tc_new_tfilter.patch