Received: by 10.213.65.68 with SMTP id h4csp264388imn; Fri, 23 Mar 2018 04:15:09 -0700 (PDT) X-Google-Smtp-Source: AG47ELtj0wUnPW071pQODtN1l7KlDGQ3Q+WwpfOJqDCskp3DzGfTr7azgy+g/ZPBPDjAWqiB1vvH X-Received: by 10.99.119.133 with SMTP id s127mr20565126pgc.441.1521803709629; Fri, 23 Mar 2018 04:15:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521803709; cv=none; d=google.com; s=arc-20160816; b=PqANZBK7xVI3f63GX68Tx6mkNFgXAT2+UWKRQcxal/Ng2cElO0P3sV1T9QrsGfuecw Zi7oxmectuIVF5b9XdH98qQXSBtPUU/7hGiL29ulVW54NfPZR/CSZoKqk4gt0C4n7oTx M790ton7fPapyrhEERv55bPQSobgsjuQdt7qCzIjnVeZ8dV2NUrI1+LISrO8+MbTVEUh gnvVsOUELJcoXSj3WVibr9ym2rH0zC8K/VmwkKioA8dRDhwlwaQKHKPKt1t+6ouT6Aal 0CJlSp1eeJbNcREeFEJ9aMgmIR+74DevEx28ahuCOb0BcZubeJoPijkl+cGsGfhMCEMo DZyA== 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=KrXuHRqp9xoKorhiK8qYp2qCMCMIh5RjtVtNIUMp9+0=; b=NOJRHEcczszLrgGxDfBZ0bWSwQK/GnEqayqDGaqqtxppjIPpDDZwhXIpvmKadgu3Tz ojj9Qr5w+al8q+3UXN+09KLTg6qsUphcpRGwPW8pYaLwaTXdLYIrJzPpj4ihiqu6W7Kf 4JMvNi0SnwKhTZA3n6QFx6I2WSM3h5uRAi3Wb0BL+GgxTcJK67BFWBXrpl+3T38Us2Qq 92rvEMk/Sa9FhEMyzZknSR1lLpYmNulIva+kSiH2UbjzOxyvsYlNip9XjBIiDiDMXo8G GDODSjhWAXPx18KbCmhlO3YrjKekWfLaRI4UMb4ShBwHYAsqqT6lhEIrt2eV8PgwbhuU Gmqw== 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 w3si5796616pgq.415.2018.03.23.04.14.54; Fri, 23 Mar 2018 04:15:09 -0700 (PDT) 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 S1755789AbeCWLNq (ORCPT + 99 others); Fri, 23 Mar 2018 07:13:46 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:42548 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932681AbeCWKK2 (ORCPT ); Fri, 23 Mar 2018 06:10:28 -0400 Received: from localhost (LFbn-1-12247-202.w90-92.abo.wanadoo.fr [90.92.61.202]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 5AF241139; Fri, 23 Mar 2018 10:10:27 +0000 (UTC) From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Trond Myklebust , Sasha Levin Subject: [PATCH 4.9 123/177] pNFS: Fix a deadlock when coalescing writes and returning the layout Date: Fri, 23 Mar 2018 10:54:11 +0100 Message-Id: <20180323094210.671622255@linuxfoundation.org> X-Mailer: git-send-email 2.16.2 In-Reply-To: <20180323094205.090519271@linuxfoundation.org> References: <20180323094205.090519271@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review 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: Trond Myklebust [ Upstream commit 61f454e30c18a28924e96be12592c0d5e24bcc81 ] Consider the following deadlock: Process P1 Process P2 Process P3 ========== ========== ========== lock_page(page) lseg = pnfs_update_layout(inode) lo = NFS_I(inode)->layout pnfs_error_mark_layout_for_return(lo) lock_page(page) lseg = pnfs_update_layout(inode) In this scenario, - P1 has declared the layout to be in error, but P2 holds a reference to a layout segment on that inode, so the layoutreturn is deferred. - P2 is waiting for a page lock held by P3. - P3 is asking for a new layout segment, but is blocked waiting for the layoutreturn. The fix is to ensure that pnfs_error_mark_layout_for_return() does not set the NFS_LAYOUT_RETURN flag, which blocks P3. Instead, we allow the latter to call LAYOUTGET so that it can make progress and unblock P2. Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- fs/nfs/pnfs.c | 2 -- 1 file changed, 2 deletions(-) --- a/fs/nfs/pnfs.c +++ b/fs/nfs/pnfs.c @@ -1953,8 +1953,6 @@ void pnfs_error_mark_layout_for_return(s spin_lock(&inode->i_lock); pnfs_set_plh_return_info(lo, range.iomode, 0); - /* Block LAYOUTGET */ - set_bit(NFS_LAYOUT_RETURN, &lo->plh_flags); /* * mark all matching lsegs so that we are sure to have no live * segments at hand when sending layoutreturn. See pnfs_put_lseg()