From: sashiko-bot@kernel.org
To: "Chuck Lever" <cel@kernel.org>
Cc: "Anna Schumaker" <anna@kernel.org>,
"Chuck Lever" <cel@kernel.org>,
"Jeff Layton" <jlayton@kernel.org>,
linux-rdma@vger.kernel.org
Subject: Re: [PATCH v1 3/5] svcrdma: fix a page leak in backchannel sends
Date: Tue, 22 Sep 2026 01:58:00 +0000 [thread overview]
Message-ID: <20260922015800.CC60B1F00893@smtp.kernel.org> (raw)
In-Reply-To: <20260922015128.240977-3-cel@kernel.org>
> svc_rdma_bc_sendto() takes an extra reference on the page that
> holds the backchannel Call message, so that the page is not
> returned to the allocator while the Send that reads it is still
> posted. Send completion once dropped that reference, back when the
> page sat in the send context's page array. Commit 99722fe4d5a6
> ("svcrdma: Persistently allocate and DMA-map Send buffers")
> switched the backchannel to svc_rdma_map_reply_msg(), which
> DMA-maps the buffer and records no pages. Send completion no
> longer touches the page, but the get_page() stayed.
>
> xprt_rdma_bc_free() drops the allocation reference and nothing
> drops the extra one, so every backchannel Call sent over RPC/RDMA
> leaks its send buffer page.
>
> The extra reference is still needed. A Call at or above
> RPCRDMA_PULLUP_THRESH is DMA-mapped in place. The RPC client frees
> rq_buffer when the callback task times out or is killed, whether
> or not the Send has completed. Record the page in the send
> context's page array so that svc_rdma_send_ctxt_release() drops
> the reference after Send completion.
>
> Fixes: 99722fe4d5a6 ("svcrdma: Persistently allocate and DMA-map Send buffers")
> Signed-off-by: Chuck Lever <cel@kernel.org>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260922015128.240977-1-cel@kernel.org?part=3
next prev parent reply other threads:[~2026-09-22 1:58 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-22 1:51 [PATCH v1 1/5] SUNRPC: fire svc_xprt_free tracepoint before dropping the netns Chuck Lever
2026-09-22 1:51 ` [PATCH v1 2/5] SUNRPC: fire svc_defer_queue tracepoint before publishing the request Chuck Lever
2026-09-22 1:57 ` sashiko-bot
2026-09-22 1:51 ` [PATCH v1 3/5] svcrdma: fix a page leak in backchannel sends Chuck Lever
2026-09-22 1:58 ` sashiko-bot [this message]
2026-09-22 1:51 ` [PATCH v1 4/5] svcrdma: release a send context stranded by a partial post Chuck Lever
2026-09-22 1:59 ` sashiko-bot
2026-09-22 1:51 ` [PATCH v1 5/5] svcrdma: release a receive context stranded by a partial Read post Chuck Lever
2026-09-22 1:57 ` sashiko-bot
2026-09-22 1:57 ` [PATCH v1 1/5] SUNRPC: fire svc_xprt_free tracepoint before dropping the netns sashiko-bot
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=20260922015800.CC60B1F00893@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=anna@kernel.org \
--cc=cel@kernel.org \
--cc=jlayton@kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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.