Received: by 10.223.185.116 with SMTP id b49csp2381594wrg; Thu, 15 Feb 2018 10:44:29 -0800 (PST) X-Google-Smtp-Source: AH8x224VbmvEwXUy9HLMEoBmRTlOySzCnZ7ITvQVbIdpjxV4VqiuOjPXX9U6I4TllMdpZY56YUrp X-Received: by 10.99.117.28 with SMTP id q28mr2953978pgc.187.1518720269718; Thu, 15 Feb 2018 10:44:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518720269; cv=none; d=google.com; s=arc-20160816; b=cW+AELRvIHL+9FV8vjra5SbXhwZoVs4daGsIhONmKa5NTf7fjbf3lgz8D4108ugZ0c l14GUtOfmZn7WOT4TCCPp/ME+nt3TCBjFOHD8oDzEO2QbwtY4l3SjIWZfjWm5w5cTqsC kVFK60K+3J2Mo2x2n9ghkzFWF+ZLMiu4uGX6n5c3+bz08SXy/EByBGgYEzYTMrjpGcRP TzHYPvfVJBtJP6N0s2Hbzeob+D3/YGMPirSiet9BRjVZ+OrUl0/hyEQ4HVCq8zpk/STm TEIZ/DVmcrBk1ujjRHXhqZ41ZyY9TZoXg3bK6Z/JGsdo2sDgBu1eyY3bLt8jR8cy4nQy ZqTg== 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=IyJLi3SMvLt75YnkD/yt/jyERWGCFDoR4cvpSuMk6kw=; b=BwC2eqajFqBrS2/Xpy3D3vdKOAqXtgDVRY7LlZswH8aUnrT57dpePumawdjrwo7/bz aPQOgq3E3vZKW5MvNvWdyUAL+eTF+lgxG0+hM06v4k5XHr7eGV7qt16mCsYOt6iG9JEP NacJX2ZslpNvl/gfAFzRyGh9lGz5TtidEDzP5b1YFkv29U8ewWxx13HJf8fmUESEj5PK KiUwnTMUiuwDQfSlBZpkvtHI2Uc9r41GKZ3AjM2aO1qilk5diXWG/1HTrRNHlaFay3/m 1FjOLo7XJw37n2X2a7Wq9QDAAUCeAkX0Q4XMB8fenLYuBIjDflIguvgur59KFAZ41atV tyBQ== 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 s86si3352633pfd.327.2018.02.15.10.44.14; Thu, 15 Feb 2018 10:44:29 -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 S1162645AbeBOPXW (ORCPT + 99 others); Thu, 15 Feb 2018 10:23:22 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:50864 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1161910AbeBOPXQ (ORCPT ); Thu, 15 Feb 2018 10:23:16 -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 C9276E34; Thu, 15 Feb 2018 15:23:00 +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.4 059/108] nfs/pnfs: fix nfs_direct_req ref leak when i/o falls back to the mds Date: Thu, 15 Feb 2018 16:16:56 +0100 Message-Id: <20180215151230.667868832@linuxfoundation.org> X-Mailer: git-send-email 2.16.1 In-Reply-To: <20180215151222.267507937@linuxfoundation.org> References: <20180215151222.267507937@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.4-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 @@ -1943,7 +1943,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 @@ -2058,7 +2058,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); } /*