From: sashiko-bot@kernel.org
To: "Zhiping Zhang" <zhipingz@meta.com>
Cc: linux-pci@vger.kernel.org, dri-devel@lists.freedesktop.org,
kvm@vger.kernel.org
Subject: Re: [PATCH v10 4/4] RDMA/mlx5: get tph for p2p access when registering dma-buf mr
Date: Tue, 30 Jun 2026 23:11:59 +0000 [thread overview]
Message-ID: <20260630231159.A1F8E1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260630224328.3218796-5-zhipingz@meta.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Memory leak of `struct mlx5_st_idx_data` in `mlx5_st_dealloc_index()` when its refcount reaches 0.
--
Note: Due to system recitation restrictions, this review report cannot quote
the original patch diff inline. The findings are provided as a free-form
summary below.
commit 9ada3f634918f1f6bc02c86bed9350c775185dbc
Author: Zhiping Zhang <zhipingz@meta.com>
Subject: RDMA/mlx5: get tph for p2p access when registering dma-buf mr
This commit wires up mlx5_ib to query dma-buf TPH metadata at MR registration
time to program requester-side TPH on the outbound mkey. It translates
exporter-provided steering tags into local ST entries and ties the extra
ST-table reference to the MR lifetime.
[Severity: High]
This is a pre-existing issue, but I noticed something while reviewing the
surrounding code in drivers/net/ethernet/mellanox/mlx5/core/lib/st.c.
In the mlx5_st_dealloc_index() function, when the usecount refcount drops to
zero, the code calls xa_erase() to remove the element from the xarray.
However, it appears the dynamically allocated memory for the idx_data
structure itself is never freed.
Could this lead to an unbounded memory leak when a user-space application
repeatedly registers and deregisters a dma-buf MR with a TPH tag? During
registration, mlx5_st_alloc_index_by_tag() allocates a new struct
mlx5_st_idx_data via kzalloc_obj(). If deregistration drops the reference
count to zero and removes the pointer from the xarray but fails to free the
structure, could this be triggered in a loop by an unprivileged user-space
process to deplete kernel memory?
Would it make sense to add a kfree() for the idx_data structure immediately
after the xa_erase() call in the refcount_dec_and_test() block?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260630224328.3218796-1-zhipingz@meta.com?part=4
prev parent reply other threads:[~2026-06-30 23:11 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-30 22:42 [PATCH v10 0/4] vfio/dma-buf: add TPH support for peer-to-peer access Zhiping Zhang
2026-06-30 22:42 ` [PATCH v10 1/4] PCI/TPH: Add requester/completer type helpers Zhiping Zhang
2026-06-30 23:07 ` sashiko-bot
2026-06-30 22:42 ` [PATCH v10 2/4] dma-buf: add optional get_pci_tph() callback Zhiping Zhang
2026-06-30 23:01 ` sashiko-bot
2026-07-01 8:25 ` Christian König
2026-07-01 17:53 ` Zhiping Zhang
2026-07-02 7:06 ` Christian König
2026-06-30 22:42 ` [PATCH v10 3/4] vfio/pci: implement get_pci_tph and DMA_BUF_TPH feature Zhiping Zhang
2026-06-30 23:08 ` sashiko-bot
2026-07-01 18:07 ` Alex Williamson
2026-07-01 21:07 ` Zhiping Zhang
2026-06-30 22:42 ` [PATCH v10 4/4] RDMA/mlx5: get tph for p2p access when registering dma-buf mr Zhiping Zhang
2026-06-30 23:11 ` sashiko-bot [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=20260630231159.A1F8E1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=kvm@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=zhipingz@meta.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.