Received: by 10.223.185.116 with SMTP id b49csp2231922wrg; Thu, 15 Feb 2018 08:28:23 -0800 (PST) X-Google-Smtp-Source: AH8x225JU7T0KBKCCnMqxe/75Pm++4OoNhM0IZpw+KxU8whJp1HZEjkLmRD4q4iJ9n3/hEUg5VPl X-Received: by 2002:a17:902:a983:: with SMTP id bh3-v6mr3030326plb.237.1518712103183; Thu, 15 Feb 2018 08:28:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518712103; cv=none; d=google.com; s=arc-20160816; b=qNZxd+WHlIpXiHCU/mFRMrRmhXEOJU4hEIOGCIfmLo92+G50uxRqFhsJuTP8rY+uSX hghl9/C4mM2+H8tDmvSKTkheBOCgbZRHjF8MB6dyS+uHmKcNSMLtCi2/WOQze/xBV4iQ 5IdJJaeq9krEwpGWq3J6aYN5YXDgGDDf5kMgC1qDmwFwnDTzhLh01KQjSO6F+h4uP6li PkyBx7WOElQ2a2c+CfbXxghBPvpCQk95s3+W8ijvHFdyHgi2JQREDp0eEtIm4da3vp90 J8hCEKFvnVuR96KMGbsnvvKfydH5sgshJiraPLsZ5qyYiqJlU6TiD3JfOucp6eAnKWNc vuGA== 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=M1Y/c1mR2lF9ZfTl8iMfOGJi74m5vFTr9g8rskBCLJM=; b=0Q3V+0pmbibuiixYqJ54OsdtKIpVuTYpMvGCFLXveg5ZcQgVuReChT3fGVnabpmnkl bZlbbo5lF16EFvC3dIvg5ukjXE5hQKt/z1EZlZI0kUWYHlZmo8ux4hLugJkmWzQhrAvo crgvZ63oLTVUMQ0HCjMAbZD1sNZWhxP6fbYAJlfcTQyZkekLpAeivS+OX1wimK4VVcHs 2NyP1nD2ykxmjk1gPmnaJoq+llEa70YBvorkv1X5jOM9XiszKtHOO9cDnZ2VeRxzkjCL JfmYhWBNf1LxdGxIFtwQQofH7JMRzdAN1gCbMvoY8CdEL22QXri1q2pU7iokgTh/Ywwy 8xcg== 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 h63si2547846pgc.497.2018.02.15.08.28.07; Thu, 15 Feb 2018 08:28:23 -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 S1424292AbeBOPm6 (ORCPT + 99 others); Thu, 15 Feb 2018 10:42:58 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:33554 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1424277AbeBOPmy (ORCPT ); Thu, 15 Feb 2018 10:42:54 -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 BF0B8F97; Thu, 15 Feb 2018 15:42:53 +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.15 096/202] nfs/pnfs: fix nfs_direct_req ref leak when i/o falls back to the mds Date: Thu, 15 Feb 2018 16:16:36 +0100 Message-Id: <20180215151718.388606263@linuxfoundation.org> X-Mailer: git-send-email 2.16.1 In-Reply-To: <20180215151712.768794354@linuxfoundation.org> References: <20180215151712.768794354@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.15-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 @@ -2255,7 +2255,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 @@ -2378,7 +2378,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); } /*