All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chuck Lever <cel@kernel.org>
To: linux-nfs@vger.kernel.org
Cc: Jan Schunk <scpcom@gmx.de>,
	Alexander Duyck <alexander.duyck@gmail.com>,
	Jakub Kacinski <kuba@kernel.org>,
	David Howells <dhowells@redhat.com>,
	Chuck Lever <chuck.lever@oracle.com>
Subject: [PATCH RFC] SUNRPC: Fix a slow server-side memory leak with RPC-over-TCP
Date: Tue, 02 Apr 2024 15:38:42 -0400	[thread overview]
Message-ID: <171208672277.1654.1052289246945629541.stgit@klimt.1015granger.net> (raw)

From: Chuck Lever <chuck.lever@oracle.com>

Jan Schunk reports that his small NFS servers suffer from memory
exhaustion after just a few days. A bisect shows that commit
e18e157bb5c8 ("SUNRPC: Send RPC message on TCP with a single
sock_sendmsg() call") is the first bad commit.

That commit assumed that sock_sendmsg() releases all the pages in
the underlying bio_vec array, but the reality is that it doesn't.
svc_xprt_release() releases the rqst's response pages, but the
record marker page fragment isn't one of those, so it was never
released.

This is a narrow fix that can be applied to stable kernels. A
more extensive fix is in the works.

Reported-by: Jan Schunk <scpcom@gmx.de>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218671
Fixes: e18e157bb5c8 ("SUNRPC: Send RPC message on TCP with a single sock_sendmsg() call")
Cc: Alexander Duyck <alexander.duyck@gmail.com>
Cc: Jakub Kacinski <kuba@kernel.org>
Cc: David Howells <dhowells@redhat.com>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
---
 net/sunrpc/svcsock.c |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/net/sunrpc/svcsock.c b/net/sunrpc/svcsock.c
index 545017a3daa4..be6c6ee85c8f 100644
--- a/net/sunrpc/svcsock.c
+++ b/net/sunrpc/svcsock.c
@@ -130,6 +130,8 @@ static void svc_reclassify_socket(struct socket *sock)
  */
 static void svc_tcp_release_ctxt(struct svc_xprt *xprt, void *ctxt)
 {
+	if (ctxt)
+		page_frag_free(ctxt);
 }
 
 /**
@@ -1237,6 +1239,7 @@ static int svc_tcp_sendmsg(struct svc_sock *svsk, struct svc_rqst *rqstp,
 		return -ENOMEM;
 	memcpy(buf, &marker, sizeof(marker));
 	bvec_set_virt(rqstp->rq_bvec, buf, sizeof(marker));
+	rqstp->rq_xprt_ctxt = buf;
 
 	count = xdr_buf_to_bvec(rqstp->rq_bvec + 1,
 				ARRAY_SIZE(rqstp->rq_bvec) - 1, &rqstp->rq_res);



             reply	other threads:[~2024-04-02 19:38 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-02 19:38 Chuck Lever [this message]
2024-04-03  5:29 ` [PATCH RFC] SUNRPC: Fix a slow server-side memory leak with RPC-over-TCP Cedric Blancher
2024-04-03 13:24   ` Chuck Lever

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=171208672277.1654.1052289246945629541.stgit@klimt.1015granger.net \
    --to=cel@kernel.org \
    --cc=alexander.duyck@gmail.com \
    --cc=chuck.lever@oracle.com \
    --cc=dhowells@redhat.com \
    --cc=kuba@kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=scpcom@gmx.de \
    /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.