Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp9408840pxu; Mon, 28 Dec 2020 15:32:07 -0800 (PST) X-Google-Smtp-Source: ABdhPJwVIL4eEL5YhE6ucuequcT7lFWi4a/+DCQaU0rXmdENbXiUrb7JKh0TOUpWaJ/93v6WEuxI X-Received: by 2002:aa7:c94a:: with SMTP id h10mr44110799edt.247.1609198327413; Mon, 28 Dec 2020 15:32:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1609198327; cv=none; d=google.com; s=arc-20160816; b=BUE9xGWzqspoz4jvh2vEbPZcMeSB+0Cib1jLeAuxdhz8QFrMY/Z/CHa2qnEhwkdEbA jfmgRrY9qD1n0crTkj+yrwFXw183TkaDH0/84Bu1pBetGX2bRqfD9L9fqKnD4VheDdaa 73w2qzbn3kd7KS6H0K2eH1xCzAJ8cIGgf7uYxwQVV9RXKwZ66fe8z0h110hjNP9Gz2jB 3le2VSGFzqsJmjHe4A2gO+rEbGKfGBrh8ENdZPNWNoJ08+WTSTHgra8QbB/SzXopfKKH CLUmOfnp/CJMv5xmeRKtojp4dO9Fdy6NFl4Jrs+Lu9FFrVtN8hbdIwQZKHCmzIrq6Sn6 T/IQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=h5NV5BdoZlGbiDWN+/qqb9w6Ee4+UHWdnixnnOZ2axY=; b=NfqAMqp9LMHE6/MwBZ4sqxXQ/XkAfStOPi2wFawYpY2fsxsdzIRzMowGce+K4MGq85 FAb8iyQslWpGQmRyVf/z88QI6l2vJH/injq3tGDEVJFYe3eKYhBhv+d37krx3mIRk28y ZZRBx6z/pWdYbBwmmTAGB8jf1884RPe3S3yEIjqrDwsWBVRweu0T7b7aFSDdYD83C3oe XgBSDIYXP2AjCWkQqOuzwfrfFXig/3d2BqWJO5jlEHjx6VVvaaoy6vog86ShZR6bqVOx bLrktVeq8ZfGSitYeY75vUvoIfr6yARBTOv17yqttWLlA/pO2zddxby3QrrqkATR9V09 95sg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=yF576i30; 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=pass (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 ar24si10776639ejc.359.2020.12.28.15.31.45; Mon, 28 Dec 2020 15:32:07 -0800 (PST) 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=@linuxfoundation.org header.s=korg header.b=yF576i30; 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=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2502405AbgL1O1n (ORCPT + 99 others); Mon, 28 Dec 2020 09:27:43 -0500 Received: from mail.kernel.org ([198.145.29.99]:35088 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2502213AbgL1O1O (ORCPT ); Mon, 28 Dec 2020 09:27:14 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id AA53C221F0; Mon, 28 Dec 2020 14:26:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1609165594; bh=IYo9dDO2K3mUSRTp/Lolj/l9f38TYl0dyTsQTsF9z04=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=yF576i30Edtmw6+ucAOA9c2NfcjvD58zJpcCeQPlWGhtav7ym0YGhLVJTQAnrcUU6 fy66q7DBRbLY8x+apTO2Qm46oPSd1ZqjX/hHj1G0en1xFBcZUGRZ3AThgR2Krr2DCb 9ygW/trp5mhSchQlrN8KNwJZrzqzAVj044a8Dyi8= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Filipe Manana , Josef Bacik , David Sterba Subject: [PATCH 5.10 587/717] btrfs: do not shorten unpin len for caching block groups Date: Mon, 28 Dec 2020 13:49:45 +0100 Message-Id: <20201228125049.038838478@linuxfoundation.org> X-Mailer: git-send-email 2.29.2 In-Reply-To: <20201228125020.963311703@linuxfoundation.org> References: <20201228125020.963311703@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Josef Bacik commit 9076dbd5ee837c3882fc42891c14cecd0354a849 upstream. While fixing up our ->last_byte_to_unpin locking I noticed that we will shorten len based on ->last_byte_to_unpin if we're caching when we're adding back the free space. This is correct for the free space, as we cannot unpin more than ->last_byte_to_unpin, however we use len to adjust the ->bytes_pinned counters and such, which need to track the actual pinned usage. This could result in WARN_ON(space_info->bytes_pinned) triggering at unmount time. Fix this by using a local variable for the amount to add to free space cache, and leave len untouched in this case. CC: stable@vger.kernel.org # 5.4+ Reviewed-by: Filipe Manana Signed-off-by: Josef Bacik Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman --- fs/btrfs/extent-tree.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) --- a/fs/btrfs/extent-tree.c +++ b/fs/btrfs/extent-tree.c @@ -2816,10 +2816,10 @@ static int unpin_extent_range(struct btr len = cache->start + cache->length - start; len = min(len, end + 1 - start); - if (start < cache->last_byte_to_unpin) { - len = min(len, cache->last_byte_to_unpin - start); - if (return_free_space) - btrfs_add_free_space(cache, start, len); + if (start < cache->last_byte_to_unpin && return_free_space) { + u64 add_len = min(len, cache->last_byte_to_unpin - start); + + btrfs_add_free_space(cache, start, add_len); } start += len;