Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp2297614ybl; Thu, 19 Dec 2019 11:11:11 -0800 (PST) X-Google-Smtp-Source: APXvYqzgVrT11e6BaieKrvfVFfiS0oPhlTWu934lwdxKb3sRefmjbV/JZl3cu35Ruz01aQa+5cdJ X-Received: by 2002:a05:6830:1199:: with SMTP id u25mr9847679otq.344.1576782671592; Thu, 19 Dec 2019 11:11:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1576782671; cv=none; d=google.com; s=arc-20160816; b=nL/QzwfOsiF3NlNT8ZWsTyYGlpukq/bpGanhK5/+Ecy094ZTXybWzvctcwbo1KAMmi oKRkjNh/y4VVKQGmJKCqwsteMQ04AoR2nse8DXINwQRXBHn4ckuHVh66bMFn8YICv4JX xYBF/hWm0VfTz5DBIx0jHsmkD6iNafV3UKam2OWne5oI3Pgw3d93ihL9AxoOwLQpJKxz uBU3yPKHLvWPGQoqkNhxQumfgLW2vq4RCUCHuAEj1fj09CXANbJRJq1VsT9fiTUkMXY1 ikZNaUUvVKvaO1bO+RJK2xsHqtC90RZZGzYN/cJ1mPPD3G2bCSZ9Ig0uGhJ+eRX05b9N Gw5A== 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=rAOyHaecPEbZ3XPMU+Wltq6muMgSvdGUghE4H/aGhcs=; b=r8kblWGfaCwXx+C1UgTacQH+WIx6NEJQcyBoj1Y/cpEa6/GU2E6ONamHBaNgzAiYBY XH6a+ueG37jDFgbKE1c20/2uyNWl9rOFkyzMaADrq4mySDwAu6Pt0HXzVG4VaJbOq9/c OzPD7zjqW/1l1Vy4AeDthTcIZ/aqK5jUeMN1XKVPi2g5mDMnRsUWp4RZQRSJreofiUb0 6Fg8sMAeWzg2FNQBocHjWBN9dIQBUG9Om327tA27WgRIoPseIbWkPezEJ0uFziM18y1b 9Ihp/CwS4KN/ZAgwIstXRIXwohyGxMNo9CVM3VcfPGM1zVnn0fetO05M5ESYcFOqN3FD W9nA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=jIE9yA97; 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 k77si3531318oih.103.2019.12.19.11.10.59; Thu, 19 Dec 2019 11:11:11 -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; dkim=pass header.i=@kernel.org header.s=default header.b=jIE9yA97; 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 S1728340AbfLSSkO (ORCPT + 99 others); Thu, 19 Dec 2019 13:40:14 -0500 Received: from mail.kernel.org ([198.145.29.99]:58810 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727070AbfLSSkM (ORCPT ); Thu, 19 Dec 2019 13:40:12 -0500 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 54174206D7; Thu, 19 Dec 2019 18:40:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1576780811; bh=dKgJsCTSUmbtavJ0CaPjre5DnKmiGld9hyTZB+L+Pek=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=jIE9yA97ENnXaeDx04wV8k8wjy8ubLdc88NxoU3GRkBOVDzQtdc7sUjcy3ssugdEe lqN11WAWln9yy9EJgyK1MzGtl6043yzI0ls41OPKpXNVvS9B2PNL7JmCrsYKhiDDhB mJ3EePH410gVItDxZPidbYpk5lBXDoQfG2To9GuQ= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Josef Bacik , Filipe Manana , David Sterba , Sasha Levin Subject: [PATCH 4.4 128/162] Btrfs: fix negative subv_writers counter and data space leak after buffered write Date: Thu, 19 Dec 2019 19:33:56 +0100 Message-Id: <20191219183215.570080109@linuxfoundation.org> X-Mailer: git-send-email 2.24.1 In-Reply-To: <20191219183150.477687052@linuxfoundation.org> References: <20191219183150.477687052@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 [ Upstream commit a0e248bb502d5165b3314ac3819e888fdcdf7d9f ] When doing a buffered write it's possible to leave the subv_writers counter of the root, used for synchronization between buffered nocow writers and snapshotting. This happens in an exceptional case like the following: 1) We fail to allocate data space for the write, since there's not enough available data space nor enough unallocated space for allocating a new data block group; 2) Because of that failure, we try to go to NOCOW mode, which succeeds and therefore we set the local variable 'only_release_metadata' to true and set the root's sub_writers counter to 1 through the call to btrfs_start_write_no_snapshotting() made by check_can_nocow(); 3) The call to btrfs_copy_from_user() returns zero, which is very unlikely to happen but not impossible; 4) No pages are copied because btrfs_copy_from_user() returned zero; 5) We call btrfs_end_write_no_snapshotting() which decrements the root's subv_writers counter to 0; 6) We don't set 'only_release_metadata' back to 'false' because we do it only if 'copied', the value returned by btrfs_copy_from_user(), is greater than zero; 7) On the next iteration of the while loop, which processes the same page range, we are now able to allocate data space for the write (we got enough data space released in the meanwhile); 8) After this if we fail at btrfs_delalloc_reserve_metadata(), because now there isn't enough free metadata space, or in some other place further below (prepare_pages(), lock_and_cleanup_extent_if_need(), btrfs_dirty_pages()), we break out of the while loop with 'only_release_metadata' having a value of 'true'; 9) Because 'only_release_metadata' is 'true' we end up decrementing the root's subv_writers counter to -1 (through a call to btrfs_end_write_no_snapshotting()), and we also end up not releasing the data space previously reserved through btrfs_check_data_free_space(). As a consequence the mechanism for synchronizing NOCOW buffered writes with snapshotting gets broken. Fix this by always setting 'only_release_metadata' to false at the start of each iteration. Fixes: 8257b2dc3c1a ("Btrfs: introduce btrfs_{start, end}_nocow_write() for each subvolume") Fixes: 7ee9e4405f26 ("Btrfs: check if we can nocow if we don't have data space") CC: stable@vger.kernel.org # 4.4+ Reviewed-by: Josef Bacik Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin --- fs/btrfs/file.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c index d056060529f81..73b547f88bfca 100644 --- a/fs/btrfs/file.c +++ b/fs/btrfs/file.c @@ -1525,6 +1525,7 @@ static noinline ssize_t __btrfs_buffered_write(struct file *file, } reserve_bytes = num_pages << PAGE_CACHE_SHIFT; + only_release_metadata = false; if ((BTRFS_I(inode)->flags & (BTRFS_INODE_NODATACOW | BTRFS_INODE_PREALLOC)) && @@ -1659,7 +1660,6 @@ again: set_extent_bit(&BTRFS_I(inode)->io_tree, lockstart, lockend, EXTENT_NORESERVE, NULL, NULL, GFP_NOFS); - only_release_metadata = false; } btrfs_drop_pages(pages, num_pages); -- 2.20.1