All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Mina Almasry" <almasrymina@google.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH net-next v3 1/2] net: netmem: document netmem and memory provider design in comments
Date: Sun, 11 Oct 2026 03:36:40 +0000	[thread overview]
Message-ID: <sashiko-outbox-166995@kernel.org> (raw)
In-Reply-To: <20261010033630.1171692-2-almasrymina@google.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] net: skb_try_coalesce() allows mixing fragments from different memory providers
--

commit e4f91f2e0cb9de813eeecc8b5549e79dc322d463
Author: Mina Almasry <almasrymina@google.com>

net: netmem: document netmem and memory provider design in comments

Clarify the netmem, memory provider, page_pool, and skb fragment design
principles in header and code comments. It documents that all frags in an
skb must either all be struct page-backed or all belong to the same memory
provider instance, and adds a check in skb_try_coalesce() to enforce this.

Link: https://lore.kernel.org/netdev/20261008023030.1089616-1-almasrymina@google.com/
Link: https://lore.kernel.org/netdev/20261005004958.3603059-1-almasrymina@google.com/

> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index d56f4f0102f75..69d3d27e29d97 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c

[ ... ]

> @@ -6210,6 +6210,10 @@ bool skb_try_coalesce(struct sk_buff *to, struct sk_buff *from,
>  	if (to->pp_recycle != from->pp_recycle)
>  		return false;
>  
> +	/* All frags in an skb must either all be struct page-backed or all
> +	 * belong to the same memory provider instance; do not coalesce skbs
> +	 * that would mix them.
> +	 */
> +	if (skb_frags_readable(from) != skb_frags_readable(to))
> +		return false;

[Severity: High]
Does this check reliably prevent mixing fragments from different memory
providers?

If a socket receives packets from multiple RX queues (e.g., via RPS/RFS or
multipath) where one queue is bound to a devmem provider and another to an
io_uring provider, both packets will have skb_frags_readable == false. This
condition then evaluates to false != false and allows skb_try_coalesce() to
successfully merge them into a single SKB.

If this coalesced SKB is processed by the TCP receive path, it can cause a
failure. When tcp_recvmsg_dmabuf() iterates over the fragments and encounters
the io_uring fragment, it will trigger the following check:

net/ipv4/tcp.c:tcp_recvmsg_dmabuf() {
    ...
            niov = skb_frag_net_iov(frag);
            if (!net_is_devmem_iov(niov)) {
                err = -ENODEV;
                goto out;
            }
    ...
}

This breaks the receive path and drops the payload. 

Additionally, if memory providers supply CPU-readable netmems (as
architecturally allowed by this commit), the check evaluates to true != true,
which fails to prevent mixing system pages with memory-provider fragments.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261010033630.1171692-1-almasrymina@google.com?part=1

  reply	other threads:[~2026-10-11  3:36 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-10  3:36 [PATCH net-next v3 0/2] net: netmem: document design principles and intended direction Mina Almasry
2026-10-10  3:36 ` [PATCH net-next v3 1/2] net: netmem: document netmem and memory provider design in comments Mina Almasry
2026-10-11  3:36   ` sashiko-bot [this message]
2026-10-11 15:49     ` Mina Almasry
2026-10-11  3:51   ` netdev-bot+sashiko
2026-10-10  3:36 ` [PATCH net-next v3 2/2] docs: netmem: document netmem and memory provider design principles Mina Almasry
2026-10-11  3:51   ` netdev-bot+sashiko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=sashiko-outbox-166995@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=almasrymina@google.com \
    --cc=bpf@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.