Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp1101584pxa; Thu, 20 Aug 2020 02:29:25 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxd6j7I2P2fw/Noa7w6KsRf3xmibTOVxIWiPzktkstaCIZM9E97aTimh10ZbeTGkz6Vc1Dt X-Received: by 2002:aa7:c259:: with SMTP id y25mr1961693edo.130.1597915765176; Thu, 20 Aug 2020 02:29:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1597915765; cv=none; d=google.com; s=arc-20160816; b=qm6UGdUY+xL/OaHc8fKzkgI781TjPdPv1N9PGNiKzQpLpDSbRcuGKmdrIiytoK77di wkSXy8N1YA1wuDvmhlCKdT9TisUXoos+abDRfhXvUVoqUB4KsdQKFD6XkeUDU3RePcyn Y5gzqxZIGnkBMIJMvHqelxPCKaFHbC5MNj+qd70GxKPivZAbIf2x3L2wffSSANXo/tu+ vI/z+epc2mCbGh/RFLWtftuNlRWvOIiHG9J5FZ7X8dlEK+bXv5DpyRrm9gtRFLZG27xr 3or7NjxbnntHjoQE3umQ4vITXsp52qWqUK7Qtz9XSqhitx/+RIRs6QaMqi+p+39m1014 Fpqg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=PtSxp2RIYOTB1f8JgRR3gPLQBOdG0grVMT3KX1mJuH4=; b=Q0VDigGVNPNbaBmQA3CQTK/nMlIUpVQlhcyG8ottULSjNXMZKVuVcaW2oXscVPtepW vWwyZ2WRikfV/UjxnqG9e4ZY3uNV6cg2AjU1UMT45cXba1TXrjZB4ePB4HyfhH7MDCP4 E0KVuSjI8Ni6RZzYR5lZ55GT09XOU9TMWds/tnRzNANBxPkG0zd7SJ9czsW3oofCAYh+ gJnRgeavaJNTn3QjNgYJiiFtd585xsf8WpXus4yCCRB0AB0XVk/tjIaZZABSL7itkR0F +p9rid+/Zi4uGjo9GgzXcWZozV1EdAlk9/K7VcCVub+dgDkb88Tns6COk0mff+Nr/1ux 18qA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=GkJlE32T; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id o18si865881ejx.472.2020.08.20.02.29.01; Thu, 20 Aug 2020 02:29:25 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=GkJlE32T; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727987AbgHTJ1c (ORCPT + 99 others); Thu, 20 Aug 2020 05:27:32 -0400 Received: from mail.kernel.org ([198.145.29.99]:60762 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726803AbgHTJ0O (ORCPT ); Thu, 20 Aug 2020 05:26:14 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id DFC3F22D06; Thu, 20 Aug 2020 09:26:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1597915574; bh=d2MQWqK4nO9dHOGm66JEcLmRTjtTA5AAhr23qVhwR/Q=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=GkJlE32TuAwhYMxyIRPhNLxz3/tbte9TWHiC6UxdPpJLRfavJtvTbNoayAb30MRGq 9OxRDjBzT1j6ApTsazCgMRGadDF1BJTLOmEEaHj3NlW2vUa36/aClg6noEhW6dOYUE 1OMiiDE8XqEfjJtAnOQeNjzg+ZaCU7RFPpIIDMGw= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Filipe Manana , David Sterba Subject: [PATCH 5.8 032/232] btrfs: fix race between page release and a fast fsync Date: Thu, 20 Aug 2020 11:18:03 +0200 Message-Id: <20200820091614.317899495@linuxfoundation.org> X-Mailer: git-send-email 2.28.0 In-Reply-To: <20200820091612.692383444@linuxfoundation.org> References: <20200820091612.692383444@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Filipe Manana commit 3d6448e631591756da36efb3ea6355ff6f383c3a upstream. When releasing an extent map, done through the page release callback, we can race with an ongoing fast fsync and cause the fsync to miss a new extent and not log it. The steps for this to happen are the following: 1) A page is dirtied for some inode I; 2) Writeback for that page is triggered by a path other than fsync, for example by the system due to memory pressure; 3) When the ordered extent for the extent (a single 4K page) finishes, we unpin the corresponding extent map and set its generation to N, the current transaction's generation; 4) The btrfs_releasepage() callback is invoked by the system due to memory pressure for that no longer dirty page of inode I; 5) At the same time, some task calls fsync on inode I, joins transaction N, and at btrfs_log_inode() it sees that the inode does not have the full sync flag set, so we proceed with a fast fsync. But before we get into btrfs_log_changed_extents() and lock the inode's extent map tree: 6) Through btrfs_releasepage() we end up at try_release_extent_mapping() and we remove the extent map for the new 4Kb extent, because it is neither pinned anymore nor locked. By calling remove_extent_mapping(), we remove the extent map from the list of modified extents, since the extent map does not have the logging flag set. We unlock the inode's extent map tree; 7) The task doing the fast fsync now enters btrfs_log_changed_extents(), locks the inode's extent map tree and iterates its list of modified extents, which no longer has the 4Kb extent in it, so it does not log the extent; 8) The fsync finishes; 9) Before transaction N is committed, a power failure happens. After replaying the log, the 4K extent of inode I will be missing, since it was not logged due to the race with try_release_extent_mapping(). So fix this by teaching try_release_extent_mapping() to not remove an extent map if it's still in the list of modified extents. Fixes: ff44c6e36dc9dc ("Btrfs: do not hold the write_lock on the extent tree while logging") CC: stable@vger.kernel.org # 5.4+ Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman --- fs/btrfs/extent_io.c | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) --- a/fs/btrfs/extent_io.c +++ b/fs/btrfs/extent_io.c @@ -4502,15 +4502,25 @@ int try_release_extent_mapping(struct pa free_extent_map(em); break; } - if (!test_range_bit(tree, em->start, - extent_map_end(em) - 1, - EXTENT_LOCKED, 0, NULL)) { + if (test_range_bit(tree, em->start, + extent_map_end(em) - 1, + EXTENT_LOCKED, 0, NULL)) + goto next; + /* + * If it's not in the list of modified extents, used + * by a fast fsync, we can remove it. If it's being + * logged we can safely remove it since fsync took an + * extra reference on the em. + */ + if (list_empty(&em->list) || + test_bit(EXTENT_FLAG_LOGGING, &em->flags)) { set_bit(BTRFS_INODE_NEEDS_FULL_SYNC, &btrfs_inode->runtime_flags); remove_extent_mapping(map, em); /* once for the rb tree */ free_extent_map(em); } +next: start = extent_map_end(em); write_unlock(&map->lock);