Received: by 10.223.185.116 with SMTP id b49csp2301584wrg; Thu, 15 Feb 2018 09:29:51 -0800 (PST) X-Google-Smtp-Source: AH8x224DoYoaU3Vjb4DmQBk0P3C7yyLXG3l6NddPbk/H4wI+iHnEQx6q/FAy6LduCuFlqeWiGWs4 X-Received: by 10.98.30.67 with SMTP id e64mr3342958pfe.111.1518715791040; Thu, 15 Feb 2018 09:29:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518715791; cv=none; d=google.com; s=arc-20160816; b=L5TdQt4RNTCOg0CM2BCRLe2oUOSqeDrLUJ/ZjQN9mU0pLCww21zYKZv8ljjvP5lobZ yAHU4Ha0Iv2iEYfGlT7q4thlj5xBWhVQjnL8kmBJlQ27cOAKaBQZS+tx2e/NC72BAeJ1 QR6/PXiRQ3k9tU8par0iPkpLGNNLRWrOlw0CTSB3uX51Fc8u/HoSiKL/TmLv3/mDvrTt dbHbJvHOQ9d1c2mD8US87kepYczBO7sRP1dtQORNXULWi8eSVwT+svwNXNtNoowAfC+u qgnYSjwQLYFq7kRMUvO2upkSGRm1haVJheCx3iI+nd7Rznb1u2WcjwWwGwqeDBolwByS yPAQ== 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=lkTK7arZPBERR44bPgEyQR79DShybcOgNs9DAJhvN48=; b=chhD0hVenr66VKbV6cao9/FucOM9vO5fG5uZ2GxZyOM/enEIOuTB4E6uc2N0EfhRp8 k535JEJpCCfUVfNaKUFCGTetEh09BHZrNPkYqSYhpVneQfbjZihJawG62BSRkJmQNeHm AcoSXPUuKvvOaPQiLMrZGJBa/miAyK0mSoDAX9Ynwz06qwhSJyETD6ihinlxmYHeatjh ITuhK1TWxnGYmIxStAHpYe3jEypQzgIxSniOPhQmvwQ4zrUpMLxQjoi7q9W2nXJfvSJl SEDGDILdID9TbsvtBl/1qZY9OgPnQa+aDWkQxUhPkvtFcc09ZZKr7T52Ivz4ZqHJ4jUX +6Ng== 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 t15-v6si313183plo.340.2018.02.15.09.29.36; Thu, 15 Feb 2018 09:29:51 -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 S1165605AbeBOR2V (ORCPT + 99 others); Thu, 15 Feb 2018 12:28:21 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:57086 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1165032AbeBOPeG (ORCPT ); Thu, 15 Feb 2018 10:34:06 -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 321E610D2; Thu, 15 Feb 2018 15:34:06 +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.14 103/195] nfs/pnfs: fix nfs_direct_req ref leak when i/o falls back to the mds Date: Thu, 15 Feb 2018 16:16:34 +0100 Message-Id: <20180215151710.833318054@linuxfoundation.org> X-Mailer: git-send-email 2.16.1 In-Reply-To: <20180215151705.738773577@linuxfoundation.org> References: <20180215151705.738773577@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.14-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 @@ -2237,7 +2237,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 @@ -2360,7 +2360,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); } /*