Re: [PATCH] nfs: fix refcount leak in nfs_direct_read_schedule_iovec()
Trond Myklebust <[email protected]>
| Newsgroups | gmane.linux.kernel,gmane.linux.nfs,gmane.linux.kernel.stable |
|---|---|
| Message-ID | <[email protected]> |
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: [email protected] > Fixes: 65caafd0d214 ("SUNRPC reverting d03727b248d0 ("NFSv4 fix CLOSE > not waiting for direct IO compeletion")") > Signed-off-by: WenTao Liang <[email protected]> > --- > 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 [email protected], [email protected]