Received: by 10.223.185.116 with SMTP id b49csp2352275wrg; Thu, 15 Feb 2018 10:14:58 -0800 (PST) X-Google-Smtp-Source: AH8x225ssNMeCeYLLTWMmnfmIajCs+v/Ud3b7ODZihdwFUfdFBT8sD0BpsucXLUuvjVb+3ep/awO X-Received: by 10.99.154.73 with SMTP id e9mr2825433pgo.26.1518718498772; Thu, 15 Feb 2018 10:14:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518718498; cv=none; d=google.com; s=arc-20160816; b=gPiQ0B5S3LYef1zGyYNVB2AcW6aBIDV/TqVoCOYIHLLP3obBhV9RPTu8xRyMxXJkEP GNbFxU28u0+3WSWxD1lEpVHa9A9NcJt9ssl/c6m5ev6WAVowT5JfCmlB1/w4FT3yvB2/ i9/vaGRjwcSFqAGMdTekwDbC6BYLj4WyU2+cbUXujdyWBnWOg2Q7OXvUBDlFjOkb2cJn HD+louNeScO9Yr4U5C9klEw4jRFwtDcMP3MpUY74qZWBcF9dWHePMFb+4ime2mbBy/7u Kh6a7SegrcIP/OLAdl2R0r9Szu2ABtIRRRTLHhiJ/VtdsAZqRY2mNQMinmUEq3oJaloJ MmLA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:message-id:date:subject:cc:to:from :arc-authentication-results; bh=u55rjbYibP1PSrfQEGnRBcWQScOJBqPJy5NtzhhDE4M=; b=dKg0q7kYRcn3eN1Ee+yw3r/Qu2NzAm41TEOsrIRQBzTfph3VAUABdmHQK4h1iAG++O f9HCuEh/FUOvlZpanzUdQXE4ZejoLnvF97LcpNpHk21u7LhOZimx5yPcZC7Q7PmPipyr CDajeOdjZZOLe+4qa9JBUqKoFcNHXpOVgBDXS/nSVFSD3EgSXjB/glyz6q8sNiyq2oys CJj3eYnhh98+52uJvE89uWBU300T8DTzYa6xw87Bl36QfJBq9Ox0vK+XhoT1jAB1VxSp NpNWsf6NqHsEv3aEQ1T3twa68X5Gd0cYHSjITfstx+Q6GqwTIL0DeNeFwBM3XZ6miXtU ZzgA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l72si456167pfk.307.2018.02.15.10.14.44; Thu, 15 Feb 2018 10:14:58 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1163736AbeBOP2H (ORCPT + 99 others); Thu, 15 Feb 2018 10:28:07 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:53722 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1163693AbeBOP2E (ORCPT ); Thu, 15 Feb 2018 10:28:04 -0500 Received: from localhost (LFbn-1-12258-90.w90-92.abo.wanadoo.fr [90.92.71.90]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 75E0A105C; Thu, 15 Feb 2018 15:28:03 +0000 (UTC) From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Trond Myklebust , Scott Mayhew Subject: [PATCH 4.9 22/88] nfs/pnfs: fix nfs_direct_req ref leak when i/o falls back to the mds Date: Thu, 15 Feb 2018 16:16:49 +0100 Message-Id: <20180215151225.750670993@linuxfoundation.org> X-Mailer: git-send-email 2.16.1 In-Reply-To: <20180215151222.437136975@linuxfoundation.org> References: <20180215151222.437136975@linuxfoundation.org> User-Agent: quilt/0.65 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.9-stable review patch. If anyone has any objections, please let me know. ------------------ From: Scott Mayhew commit ba4a76f703ab7eb72941fdaac848502073d6e9ee upstream. Currently when falling back to doing I/O through the MDS (via pnfs_{read|write}_through_mds), the client frees the nfs_pgio_header without releasing the reference taken on the dreq via pnfs_generic_pg_{read|write}pages -> nfs_pgheader_init -> nfs_direct_pgio_init. It then takes another reference on the dreq via nfs_generic_pg_pgios -> nfs_pgheader_init -> nfs_direct_pgio_init and as a result the requester will become stuck in inode_dio_wait. Once that happens, other processes accessing the inode will become stuck as well. Ensure that pnfs_read_through_mds() and pnfs_write_through_mds() clean up correctly by calling hdr->completion_ops->completion() instead of calling hdr->release() directly. This can be reproduced (sometimes) by performing "storage failover takeover" commands on NetApp filer while doing direct I/O from a client. This can also be reproduced using SystemTap to simulate a failure while doing direct I/O from a client (from Dave Wysochanski ): stap -v -g -e 'probe module("nfs_layout_nfsv41_files").function("nfs4_fl_prepare_ds").return { $return=NULL; exit(); }' Suggested-by: Trond Myklebust Signed-off-by: Scott Mayhew Fixes: 1ca018d28d ("pNFS: Fix a memory leak when attempted pnfs fails") Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman --- fs/nfs/pnfs.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/fs/nfs/pnfs.c +++ b/fs/nfs/pnfs.c @@ -2145,7 +2145,7 @@ pnfs_write_through_mds(struct nfs_pageio nfs_pageio_reset_write_mds(desc); mirror->pg_recoalesce = 1; } - hdr->release(hdr); + hdr->completion_ops->completion(hdr); } static enum pnfs_try_status @@ -2256,7 +2256,7 @@ pnfs_read_through_mds(struct nfs_pageio_ nfs_pageio_reset_read_mds(desc); mirror->pg_recoalesce = 1; } - hdr->release(hdr); + hdr->completion_ops->completion(hdr); } /*