Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp276372ybi; Wed, 29 May 2019 21:12:02 -0700 (PDT) X-Google-Smtp-Source: APXvYqzdcps5eBja4Jwfryn9L0xlwJP1S1nZwleQaEtFj2Wgra3lVlRI7mpImTkNNLV1AFkH8jrB X-Received: by 2002:a17:90a:21a8:: with SMTP id q37mr1597080pjc.5.1559189522579; Wed, 29 May 2019 21:12:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559189522; cv=none; d=google.com; s=arc-20160816; b=U6N4sn+kDfZDVZqk5+JeQ9Fs8ffOwpQT5FYqmW8bVP86Qs00po9RjRgAouCdsSlUlC GJYxyFvdKaubMXd8ZwZLbQaFXeU0cNVFs56q5tR/h7nxqUBwWSYmie4JTuWYaYzvgi1O 6mvPrWB3YB0uVZIXTd+GuOJ3/0hWnkHrAfSnt9WVlc/Tk6FILFWpUuR4rRyFzwsbqn26 MwEI+iSYToB5RZAgnDtrC5CeWSM94MbgN4VX0CUoKvp35AomiBODJ+XCTMfKHnyI3B8c drJE4vKDFCdwEjfBYpEEiAMS7U5NeeDSvFKpAADV2TcvRosRrQ8mc+KWpIHGgf8QATL1 MjZQ== 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=8qSE4kBtHF02LKjVlLzQT12WsnGx1ZOpJdLiSzJHspA=; b=oVLve/Aik7P11QITUXTpOTmWSELiM7iHV9jxVqqYuZnagurZGlQ9iqDemE897rlLgx 44PqMsnQoim9SUFu6xSG7ObEEAqS5mUJfrrfOjuMSJjCVpqWaw4ClsTpkJIkEUtlC6Ob Xt5DcqwPZNnGEtOjisig1KaHbepNIiY/WBzF3r/3N2pG6OIIkEiUUxBGYsg/ElUjVy9n HT35fXhvEcC19yg3Y1dOi1yn1wsMzoHXC+wTgwtPn6YWC40s8yAPVUkGPf9PYvLvbdKM qdmqposGTHZKHmuUFNeIsQnjTHFsvxwWjHcHhhQmO0HbAi1Lan+msgXtBHHqadS+0HDW H/5g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=1BsVPh4l; 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 l11si1999913plb.369.2019.05.29.21.11.47; Wed, 29 May 2019 21:12:02 -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; dkim=pass header.i=@kernel.org header.s=default header.b=1BsVPh4l; 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 S1727792AbfE3EKr (ORCPT + 99 others); Thu, 30 May 2019 00:10:47 -0400 Received: from mail.kernel.org ([198.145.29.99]:44448 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729935AbfE3DQ6 (ORCPT ); Wed, 29 May 2019 23:16:58 -0400 Received: from localhost (ip67-88-213-2.z213-88-67.customer.algx.net [67.88.213.2]) (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 DC3032463F; Thu, 30 May 2019 03:16:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1559186218; bh=mB1JwBppuuYo9KbxWZGD36wEw4Y+aFhaE5D0Y/3vHP8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=1BsVPh4lb43Cuz1pkWH0TJS96AsWBF79mhWbcVbr2Kcxk5xwpLtJ2I0e+e5a/UAq0 Q66PuHoYDHapbbhOQ6UdHbwlRMDmIsHpfMJ7rRDxOBHNWGe9t75WSzb8dM99Z+8ncY FGbWfX8OJ/N5eUccyx86EVGErBzVCiQcqSUfDcYA= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Filipe Manana , Robbie Ko , David Sterba , Sasha Levin Subject: [PATCH 4.19 080/276] Btrfs: fix data bytes_may_use underflow with fallocate due to failed quota reserve Date: Wed, 29 May 2019 20:03:58 -0700 Message-Id: <20190530030531.374696788@linuxfoundation.org> X-Mailer: git-send-email 2.21.0 In-Reply-To: <20190530030523.133519668@linuxfoundation.org> References: <20190530030523.133519668@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 [ Upstream commit 39ad317315887c2cb9a4347a93a8859326ddf136 ] When doing fallocate, we first add the range to the reserve_list and then reserve the quota. If quota reservation fails, we'll release all reserved parts of reserve_list. However, cur_offset is not updated to indicate that this range is already been inserted into the list. Therefore, the same range is freed twice. Once at list_for_each_entry loop, and once at the end of the function. This will result in WARN_ON on bytes_may_use when we free the remaining space. At the end, under the 'out' label we have a call to: btrfs_free_reserved_data_space(inode, data_reserved, alloc_start, alloc_end - cur_offset); The start offset, third argument, should be cur_offset. Everything from alloc_start to cur_offset was freed by the list_for_each_entry_safe_loop. Fixes: 18513091af94 ("btrfs: update btrfs_space_info's bytes_may_use timely") Reviewed-by: Filipe Manana Signed-off-by: Robbie Ko Signed-off-by: David Sterba Signed-off-by: Sasha Levin --- fs/btrfs/file.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c index de4d3baec1616..e24c0a69ff5d4 100644 --- a/fs/btrfs/file.c +++ b/fs/btrfs/file.c @@ -3161,6 +3161,7 @@ static long btrfs_fallocate(struct file *file, int mode, ret = btrfs_qgroup_reserve_data(inode, &data_reserved, cur_offset, last_byte - cur_offset); if (ret < 0) { + cur_offset = last_byte; free_extent_map(em); break; } @@ -3210,7 +3211,7 @@ static long btrfs_fallocate(struct file *file, int mode, /* Let go of our reservation. */ if (ret != 0 && !(mode & FALLOC_FL_ZERO_RANGE)) btrfs_free_reserved_data_space(inode, data_reserved, - alloc_start, alloc_end - cur_offset); + cur_offset, alloc_end - cur_offset); extent_changeset_free(data_reserved); return ret; } -- 2.20.1