Linux NFS development
 help / color / mirror / Atom feed
From: Trond Myklebust <trondmy@kernel.org>
To: WenTao Liang <vulab@iscas.ac.cn>, anna@kernel.org
Cc: linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org,
	 stable@vger.kernel.org
Subject: Re: [PATCH] nfs: fix refcount leak in nfs_direct_read_schedule_iovec()
Date: Thu, 11 Jun 2026 13:24:04 -0400	[thread overview]
Message-ID: <7ae31abd06022e7e348e2d7e194cf292b6471309.camel@kernel.org> (raw)
In-Reply-To: <20260611145956.90270-1-vulab@iscas.ac.cn>

On Thu, 2026-06-11 at 22:59 +0800, WenTao Liang wrote:
> When nfs_direct_read_schedule_iovec() encounters an error after
> get_dreq(dreq) increments the io_count but fails to start any I/O
> (requested_bytes == 0), it falls through to the error path. That
> path calls nfs_direct_req_release() to drop the I/O path’s kref,
> but it never calls put_dreq() to balance the io_count. This leaves
> the request’s io_count permanently elevated, a reference counting
> violation that corrupts the teardown logic once the object is
> freed via the remaining kref.

Exactly how is this corruption supposed to happen? I'm not seeing
anything that cares about the value of io_count either in
nfs_file_direct_read or in nfs_direct_req_free.

> 
> Fix the leak by calling put_dreq(dreq) before
> nfs_direct_req_release() in the zero-bytes error path, so the
> io_count is properly balanced.
> 
> Cc: stable@vger.kernel.org
> Fixes: 65caafd0d214 ("SUNRPC reverting d03727b248d0 ("NFSv4 fix CLOSE
> not waiting for direct IO compeletion")")
> Signed-off-by: WenTao Liang <vulab@iscas.ac.cn>
> ---
>  fs/nfs/direct.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/fs/nfs/direct.c b/fs/nfs/direct.c
> index 48d89716193a..41a6cabb0592 100644
> --- a/fs/nfs/direct.c
> +++ b/fs/nfs/direct.c
> @@ -400,6 +400,7 @@ static ssize_t
> nfs_direct_read_schedule_iovec(struct nfs_direct_req *dreq,
>  	 */
>  	if (requested_bytes == 0) {
>  		inode_dio_end(inode);
> +		put_dreq(dreq);
>  		nfs_direct_req_release(dreq);
>  		return result < 0 ? result : -EIO;
>  	}

-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trondmy@kernel.org, trond.myklebust@hammerspace.com

      reply	other threads:[~2026-06-11 17:24 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-11 14:59 [PATCH] nfs: fix refcount leak in nfs_direct_read_schedule_iovec() WenTao Liang
2026-06-11 17:24 ` Trond Myklebust [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=7ae31abd06022e7e348e2d7e194cf292b6471309.camel@kernel.org \
    --to=trondmy@kernel.org \
    --cc=anna@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=vulab@iscas.ac.cn \
    /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