From: Dragos Tatulea <dtatulea@nvidia.com>
To: Jakub Kicinski <kuba@kernel.org>, tariqt@nvidia.com
Cc: leon@kernel.org, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, moshe@nvidia.com, daniel@iogearbox.net,
edumazet@google.com, andrew+netdev@lunn.ch, hawk@kernel.org,
ast@kernel.org, mbloch@nvidia.com, john.fastabend@gmail.com,
bpf@vger.kernel.org, cjubran@nvidia.com,
linux-rdma@vger.kernel.org, davem@davemloft.net,
pabeni@redhat.com, gal@nvidia.com, saeedm@nvidia.com
Subject: Re: [PATCH net-next 5/5] net/mlx5e: XDP, Use page fragments for linear data in multibuf-mode
Date: Tue, 24 Mar 2026 09:50:04 +0100 [thread overview]
Message-ID: <600504dc-b35d-4e5c-86ec-86590ae314ea@nvidia.com> (raw)
In-Reply-To: <20260324024235.929875-1-kuba@kernel.org>
On 24.03.26 03:42, Jakub Kicinski wrote:
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
>
> For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
> ---
> [...]
>
>> @@ -702,6 +731,16 @@ static void mlx5e_dealloc_rx_mpwqe(struct mlx5e_rq *rq, u16 ix)
>> bitmap_fill(wi->skip_release_bitmap, rq->mpwqe.pages_per_wqe);
>> }
>>
>> +void mlx5e_mpwqe_dealloc_linear_page(struct mlx5e_rq *rq)
>> +{
>> + struct mlx5e_mpw_linear_info *li = rq->mpwqe.linear_info;
>> +
>> + if (!li || !li->frag_page.netmem)
>> + return;
>> +
>> + mlx5e_page_release_fragmented(rq->page_pool, &li->frag_page);
>> +}
>
> Does this function need to reset li->frag_page.netmem to 0 and
> li->frag_page.frags to li->max_frags after releasing the page?
>
> When an RQ is flushed and then reactivated (for example, in error recovery
> via mlx5e_rx_reporter_err_rq_cqe_recover()), the following sequence occurs:
>
> mlx5e_rx_reporter_err_rq_cqe_recover()
> mlx5e_flush_rq()
> mlx5e_free_rx_descs()
> mlx5e_mpwqe_dealloc_linear_page()
> mlx5e_page_release_fragmented() [releases the page]
> [but doesn't reset netmem or frags]
> mlx5e_activate_rq()
> [RQ becomes active again]
>
> When the next XDP multi-buffer packet arrives, mlx5e_mpwqe_get_linear_page_frag()
> is called:
>
> mlx5e_skb_from_cqe_mpwrq_nonlinear()
> mlx5e_mpwqe_get_linear_page_frag()
> mlx5e_mpwqe_linear_page_refill()
> if (likely(li->frag_page.frags < li->max_frags))
> return 0; [skips allocation if frags < max_frags]
> netmem_address(li->frag_page.netmem) + frag_offset [UAF]
>
> If li->frag_page.frags was not reset to li->max_frags in
> mlx5e_mpwqe_dealloc_linear_page(), the refill function will see frags <
> max_frags and skip the allocation, then compute the address using the stale
> netmem pointer that was already returned to the page pool.
>
> Shouldn't this match the initialization in mlx5e_rq_alloc_mpwqe_linear_info()
> which sets li->frag_page.frags = li->max_frags?
Good catch. Will address in v2.
Thanks,
Dragos
prev parent reply other threads:[~2026-03-24 8:50 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-19 7:50 [PATCH net-next 0/5] net/mlx5e: XDP, Add support for multi-packet per page Tariq Toukan
2026-03-19 7:50 ` [PATCH net-next 1/5] net/mlx5e: XSK, Increase size for chunk_size param Tariq Toukan
2026-03-19 7:50 ` [PATCH net-next 2/5] net/mlx5e: XDP, Improve dma address calculation of linear part for XDP_TX Tariq Toukan
2026-03-19 7:50 ` [PATCH net-next 3/5] net/mlx5e: XDP, Remove stride size limitation Tariq Toukan
2026-03-19 7:50 ` [PATCH net-next 4/5] net/mlx5e: XDP, Use a single linear page per rq Tariq Toukan
2026-03-19 7:50 ` [PATCH net-next 5/5] net/mlx5e: XDP, Use page fragments for linear data in multibuf-mode Tariq Toukan
2026-03-24 2:42 ` Jakub Kicinski
2026-03-24 8:50 ` Dragos Tatulea [this message]
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=600504dc-b35d-4e5c-86ec-86590ae314ea@nvidia.com \
--to=dtatulea@nvidia.com \
--cc=andrew+netdev@lunn.ch \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=cjubran@nvidia.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=gal@nvidia.com \
--cc=hawk@kernel.org \
--cc=john.fastabend@gmail.com \
--cc=kuba@kernel.org \
--cc=leon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=mbloch@nvidia.com \
--cc=moshe@nvidia.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=saeedm@nvidia.com \
--cc=tariqt@nvidia.com \
/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.