From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1DA7C27D786; Mon, 5 May 2025 22:42:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1746484923; cv=none; b=MvXKPTlXt5uubiaW9X+wFc/L3o/u37tcqmf9RZlbitJ2if8uucDH1T5akHxXekFwP7i3Xg4ybM3WZsbjhRuOtfytM+J+9POIH/09NEDNiSJRtZxSqlaHAYK8OLW+NBLD+FoF0YHS2PwPCDcyxyKCwctIpRpCKJdhfeM9U63xGBo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1746484923; c=relaxed/simple; bh=ikB6SErqWkThOyImGk4WEEG5UGvxZgZ7KBXa1b1k3CQ=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=Es7fEjdNIC6ffjI1KgW6Ot7zRAPzIQM2B2bOub764vBDB1yKgLE18+BIStCu38/GJaZA0AkGMFaQGmcDBN2npNvlhu2e8uGPFvxbTivy8cIL9Xa/zYZRykzrKxnympK40W7Y1AtZy6Zb2ah0pMBBb2BRbKr+vWkClzUcmTi0J2o= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=l3vLWOBV; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="l3vLWOBV" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A23CEC4CEEE; Mon, 5 May 2025 22:42:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1746484922; bh=ikB6SErqWkThOyImGk4WEEG5UGvxZgZ7KBXa1b1k3CQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=l3vLWOBV+H7T4RmjrE6aQ/NsgNe/RF01rcJ6X3OO8Ln42INXR7RduN5nQ1Z0HKxBj YUNrxf8BqOIQiXAbVKdkCnikHnzC6yU+Hq+bl882olrK55/7tD/9KYWOgC+L/m6X/4 dqrax+HcPBoXzm1Wli6XRUExZpMPwVxxqh185JVSibFgbEnOhwyD6Yuv0MJHyA1HhY qbttgfYQp9Z4pLUKed+sfEN2BSRyPIS/HBf+4MQscLVQnbtVhnJ8mnyT8wp2aArdGY rHVKjcb4+iVd2OugQfEaDXevZm4UMn4dG90PFG65g7Zf2BE/cakVUd4xJ1FVz/snZB OBMMqlebwgT/Q== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Filipe Manana , Johannes Thumshirn , David Sterba , Sasha Levin , clm@fb.com, josef@toxicpanda.com, linux-btrfs@vger.kernel.org Subject: [PATCH AUTOSEL 6.12 078/486] btrfs: get zone unusable bytes while holding lock at btrfs_reclaim_bgs_work() Date: Mon, 5 May 2025 18:32:34 -0400 Message-Id: <20250505223922.2682012-78-sashal@kernel.org> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20250505223922.2682012-1-sashal@kernel.org> References: <20250505223922.2682012-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore X-stable-base: Linux 6.12.26 Content-Transfer-Encoding: 8bit From: Filipe Manana [ Upstream commit 1283b8c125a83bf7a7dbe90c33d3472b6d7bf612 ] At btrfs_reclaim_bgs_work(), we are grabbing a block group's zone unusable bytes while not under the protection of the block group's spinlock, so this can trigger race reports from KCSAN (or similar tools) since that field is typically updated while holding the lock, such as at __btrfs_add_free_space_zoned() for example. Fix this by grabbing the zone unusable bytes while we are still in the critical section holding the block group's spinlock, which is right above where we are currently grabbing it. Reviewed-by: Johannes Thumshirn Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin --- fs/btrfs/block-group.c | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/fs/btrfs/block-group.c b/fs/btrfs/block-group.c index 4423d8b716a58..aa8656c8b7e7e 100644 --- a/fs/btrfs/block-group.c +++ b/fs/btrfs/block-group.c @@ -1891,6 +1891,17 @@ void btrfs_reclaim_bgs_work(struct work_struct *work) up_write(&space_info->groups_sem); goto next; } + + /* + * Cache the zone_unusable value before turning the block group + * to read only. As soon as the block group is read only it's + * zone_unusable value gets moved to the block group's read-only + * bytes and isn't available for calculations anymore. We also + * cache it before unlocking the block group, to prevent races + * (reports from KCSAN and such tools) with tasks updating it. + */ + zone_unusable = bg->zone_unusable; + spin_unlock(&bg->lock); spin_unlock(&space_info->lock); @@ -1907,13 +1918,6 @@ void btrfs_reclaim_bgs_work(struct work_struct *work) goto next; } - /* - * Cache the zone_unusable value before turning the block group - * to read only. As soon as the blog group is read only it's - * zone_unusable value gets moved to the block group's read-only - * bytes and isn't available for calculations anymore. - */ - zone_unusable = bg->zone_unusable; ret = inc_block_group_ro(bg, 0); up_write(&space_info->groups_sem); if (ret < 0) -- 2.39.5