On 7/28/25 19:39, Mina Almasry wrote:
On Mon, Jul 28, 2025 at 11:35 AM Pavel Begunkov <asml.silence@xxxxxxxxx> wrote:
On 7/28/25 06:27, Byungchul Park wrote:
Changes from v1:
1. Rebase on linux-next.
net-next is closed, looks like until August 11.
2. Initialize net_iov->pp = NULL when allocating net_iov in
net_devmem_bind_dmabuf() and io_zcrx_create_area().
3. Use ->pp for net_iov to identify if it's pp rather than
always consider net_iov as pp.
4. Add Suggested-by: David Hildenbrand <david@xxxxxxxxxx>.
Oops, looks you killed my suggested-by tag now. Since it's still
pretty much my diff spliced with David's suggestions, maybe
Co-developed-by sounds more appropriate. Even more so goes for
the second patch getting rid of __netmem_clear_lsb().
Looks fine, just one comment below.
...> diff --git a/io_uring/zcrx.c b/io_uring/zcrx.c
index 100b75ab1e64..34634552cf74 100644
--- a/io_uring/zcrx.c
+++ b/io_uring/zcrx.c
@@ -444,6 +444,7 @@ static int io_zcrx_create_area(struct io_zcrx_ifq *ifq,
area->freelist[i] = i;
atomic_set(&area->user_refs[i], 0);
niov->type = NET_IOV_IOURING;
+ niov->pp = NULL;
It's zero initialised, you don't need it.
This may be my bad since I said we should check if it's 0 initialized.
It looks like on the devmem side as well we kvmalloc_array the niovs,
and if I'm checking through the helpers right, kvmalloc_array does
0-initialize indeed.
I wouldn't rely on that, it's just for zcrx I do:
kvmalloc_array(..., GFP_KERNEL | __GFP_ZERO);
--
Pavel Begunkov
