From: netdev-bot+sashiko@kernel.org
To: sdf.kernel@gmail.com
Cc: netdev@vger.kernel.org, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com, horms@kernel.org,
hawk@kernel.org, ilias.apalodimas@linaro.org,
asml.silence@gmail.com, axboe@kernel.dk, sdf@fomichev.me,
bobbyeshleman@meta.com, almasrymina@google.com,
kaiyuanz@google.com, linux-kernel@vger.kernel.org,
io-uring@vger.kernel.org
Subject: Re: [PATCH net-next 2/3] net: devmem: use memory provider helpers for net_iovs
Date: Wed, 23 Sep 2026 23:46:29 +0000 [thread overview]
Message-ID: <179020718952.2160803.820732555059297637@kernel.org> (raw)
In-Reply-To: <20260922204348.717198-3-sdf@fomichev.me>
Thank you for your contribution! Sashiko AI review found more severe
issue(s) in other patches of this series. This mail is only an FYI, in case
you want to address the nit picks below when you respin.
Low priority / nit picks for your consideration:
- [Low] net: devmem: use memory provider helpers for net_iovs bundles a
real bug fix into a patch whose commit message presents it as a…
--
net: devmem: use memory provider helpers for net_iovs
This converts net/core/devmem.c to the public memory-provider helpers
net_mp_niov_set_dma_addr(), net_mp_niov_set_page_pool() and
net_mp_niov_clear_page_pool() instead of open-coding page_pool state,
switches the net_iov array to kvzalloc_objs(), and now rejects DMA
addresses that cannot be represented in net_iov metadata.
> Zero the net_iov array because net_mp_niov_set_page_pool() ORs
> PP_SIGNATURE into pp_magic. Reject DMA addresses that cannot be
> represented in net_iov metadata.
[Severity: Low]
This isn't a bug in the new code, but should the "Reject DMA addresses
that cannot be represented in net_iov metadata" sentence spell out that
the old behaviour was a silent truncation, and should the patch carry a
Fixes: tag?
Before this patch net_devmem_bind_dmabuf() dropped the return value of
page_pool_set_dma_addr_netmem(), which is the "this address does not
round-trip through the compressed net_iov metadata" indicator:
net/core/page_pool_priv.h:page_pool_set_dma_addr_netmem() {
if (PAGE_POOL_32BIT_ARCH_WITH_64BIT_DMA) {
netmem_set_dma_addr(netmem, addr >> PAGE_SHIFT);
/* We assume page alignment to shave off bottom bits,
* if this "compression" doesn't work we need to drop.
*/
return addr != (dma_addr_t)netmem_get_dma_addr(netmem)
<< PAGE_SHIFT;
}
...
}
Every other caller treats a true return as fatal, e.g.
page_pool_dma_map():
if (page_pool_set_dma_addr_netmem(netmem, dma)) {
WARN_ONCE(1, "unexpected DMA address, please report to netdev@");
goto unmap_failed;
}
and io_uring/zcrx.c returns -EFAULT. Devmem was the only site that kept
the truncated address and handed it to the NIC for DMA.
The path looks reachable from user space on 32-bit arches with 64-bit
dma_addr_t: netdev_nl_bind_rx_doit() only checks is_power_of_2() on
NETDEV_A_DMABUF_RX_PAGE_SIZE before niov_shift = ilog2(rx_page_size), so
a sub-PAGE_SIZE niov size is accepted, and the bind loop then advances
dma_addr += niov_size producing non-page-aligned addresses whose
compression fails.
Given that the next patch in the series ("net: devmem: decode DMA
addresses for TX") does carry a Fixes: tag for the other half of the same
32-bit/64-bit-DMA problem, would it make sense to split this hunk out
with its own Fixes: tag so it can be picked up for stable?
> diff --git a/net/core/devmem.c b/net/core/devmem.c
> index c1c1872b88de2..0fc77c1a29569 100644
> --- a/net/core/devmem.c
> +++ b/net/core/devmem.c
[ ... ]
> @@ -274,8 +272,12 @@ net_devmem_bind_dmabuf(struct net_device *dev, void *vdev,
> for (i = 0; i < nr_niovs; i++, niov_idx++) {
> niov = &binding->area.niovs[niov_idx];
> net_iov_init(niov, &binding->area, NET_IOV_DMABUF);
> - page_pool_set_dma_addr_netmem(net_iov_to_netmem(niov),
> - dma_addr);
> + if (net_mp_niov_set_dma_addr(niov, dma_addr)) {
> + err = -EFAULT;
> + NL_SET_ERR_MSG(extack,
> + "dmabuf DMA address cannot be represented");
> + goto err_free_niovs;
> + }
> if (direction == DMA_TO_DEVICE)
> binding->tx_vec[niov_idx] = niov;
> else
[ ... ]
--
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260922204348.717198-1-sdf%40fomichev.me
next prev parent reply other threads:[~2026-09-23 23:46 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-22 20:43 [PATCH net-next 0/3] net: consolidate net_iov freelist and DMA handling Stanislav Fomichev
2026-09-22 20:43 ` [PATCH net-next 1/3] net: netmem: add net_iov_area freelist helpers Stanislav Fomichev
2026-09-23 23:46 ` netdev-bot+sashiko
2026-09-24 16:28 ` Stanislav Fomichev
2026-09-24 15:02 ` Mina Almasry
2026-09-24 15:41 ` Pavel Begunkov
2026-09-24 16:46 ` Mina Almasry
2026-09-24 16:48 ` Stanislav Fomichev
2026-09-24 16:45 ` Stanislav Fomichev
2026-09-22 20:43 ` [PATCH net-next 2/3] net: devmem: use memory provider helpers for net_iovs Stanislav Fomichev
2026-09-23 23:46 ` netdev-bot+sashiko [this message]
2026-09-24 16:25 ` Stanislav Fomichev
2026-09-24 15:15 ` Mina Almasry
2026-09-22 20:43 ` [PATCH net-next 3/3] net: devmem: decode DMA addresses for TX Stanislav Fomichev
2026-09-24 19:26 ` Mina Almasry
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=179020718952.2160803.820732555059297637@kernel.org \
--to=netdev-bot+sashiko@kernel.org \
--cc=almasrymina@google.com \
--cc=asml.silence@gmail.com \
--cc=axboe@kernel.dk \
--cc=bobbyeshleman@meta.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hawk@kernel.org \
--cc=horms@kernel.org \
--cc=ilias.apalodimas@linaro.org \
--cc=io-uring@vger.kernel.org \
--cc=kaiyuanz@google.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sdf.kernel@gmail.com \
--cc=sdf@fomichev.me \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®