From: "Cen Zhang (Microsoft)" <blbllhy@gmail.com>
To: horms@kernel.org
Cc: AutonomousCodeSecurity@microsoft.com, blbllhy@gmail.com,
bpf@vger.kernel.org, davem@davemloft.net, edumazet@google.com,
kerneljasonxing@gmail.com, kuba@kernel.org, kys@microsoft.com,
linux-kernel@vger.kernel.org, maciej.fijalkowski@intel.com,
magnus.karlsson@intel.com, netdev@vger.kernel.org,
pabeni@redhat.com, sdf@fomichev.me,
tgopinath@linux.microsoft.com
Subject: Re: [PATCH net v3] xsk: fix NULL pointer dereference in __xsk_rcv()
Date: Thu, 13 Aug 2026 17:42:40 -0400 [thread overview]
Message-ID: <20260813214240.96466-1-blbllhy@gmail.com> (raw)
In-Reply-To: <20260810132505.769431-1-horms@kernel.org>
Hi Simon,
Thanks for the comments.
Given the extra complexity of reusing the pool-global xskb_list here,
including the locking/concurrency issues and the hidden implementation
assumptions needed to reuse the existing frag helpers, I would prefer to
go back to the v2 local-list implementation, which is correct, logically
simpler, and easier to maintain.
@Jason, regarding your v2 memory leak concern:
> It will cause a memory leak because the current xsk_xdp that is not
> added to the local list will miss the chance to get freed? And the
> empty list_node cannot be easily freed by xp_free()...
IIUC, it would not leak. The !list_empty(&xskb->list_node) case can only
happen when fresh aligned-mode allocation returns the same xskb for a
duplicated user Fill Ring address. In that case, the xskb has already
been added to the local staging list by an earlier iteration, so the
error path will walk that list, do list_del_init(), and then
xsk_buff_free() can recycle it. For buffers returned from the free_list,
in either aligned or unaligned mode, xsk_buff_alloc() already did
list_del_init(). For fresh unaligned-mode allocations, xskb metadata
comes from free_heads, so duplicated user addresses should not return the
same in-list xskb.
I'll prepare v4 based on the v2 local-list approach shortly.
Thanks,
Cen
prev parent reply other threads:[~2026-08-13 21:42 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-06 20:47 [PATCH net v3] xsk: fix NULL pointer dereference in __xsk_rcv() Cen Zhang (Microsoft)
2026-08-10 13:25 ` Simon Horman
2026-08-13 21:42 ` Cen Zhang (Microsoft) [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=20260813214240.96466-1-blbllhy@gmail.com \
--to=blbllhy@gmail.com \
--cc=AutonomousCodeSecurity@microsoft.com \
--cc=bpf@vger.kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kerneljasonxing@gmail.com \
--cc=kuba@kernel.org \
--cc=kys@microsoft.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maciej.fijalkowski@intel.com \
--cc=magnus.karlsson@intel.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sdf@fomichev.me \
--cc=tgopinath@linux.microsoft.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox