From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B9CB5C43603 for ; Sun, 15 Dec 2019 11:08:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 901412072B for ; Sun, 15 Dec 2019 11:08:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1576408126; bh=ZpOS/eqB9p7DoYScquunfoaA5X1/WnyxqfK4MIOMs+E=; h=Subject:To:Cc:From:Date:List-ID:From; b=QaLMiaZXCRoATGx1B2nkfkgGU4aW9uMNAX/1J/aJE0cQtxQrNGTx1qTzuU88LQLuY DizrN9I8GC1Yqt4WChH+n/YuRB9pHIDUQHepl5ikMTxYyxBBFhBEf16FkiS0O0EKbV iG8tqZS2JS2CrLbjz26r0yVw6/PpqwThXk9uayec= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726112AbfLOLIq (ORCPT ); Sun, 15 Dec 2019 06:08:46 -0500 Received: from wout4-smtp.messagingengine.com ([64.147.123.20]:38633 "EHLO wout4-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726094AbfLOLIq (ORCPT ); Sun, 15 Dec 2019 06:08:46 -0500 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 61C85672; Sun, 15 Dec 2019 06:08:45 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Sun, 15 Dec 2019 06:08:45 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=jm1vKz vOriBxQpj9JHv//g26VEnPxgDfyS9ZFAD7/HI=; b=S8U1GN8kWJq+E3WmgKtIWf 0nIatp/DomVmkDxDkloL2apNGxz7GF9kJMjEw7C92adCHblt7PRABs4f5wMLzh0e 2DoluKyL4PiQfJnO3nStk3UUBs7tOTsTiUOSOdypQSQPoRmh/ZQSUrM2wTXVT08V fozCyKs3VPKSjtf5zo5+NjrL8Q5rBg20j7sF2ZsvY/yrXngRiMRgxv14SiHkhDe0 Aro8Wul+zxNZLygqHLdlak8WRoMvh+wxUt1iu3fmx3tekJcCON8U+bh+dxnmZuL6 MTXuQaj6v7qEVvCak69WBNVxUoIWRlCdWfjsnNltwvtYy5t5ag2OE+1AyAweVVDQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrvddtfedgvdehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefuvffhfffkgggtgfesthekredttd dtlfenucfhrhhomhepoehgrhgvghhkhheslhhinhhugihfohhunhgurghtihhonhdrohhr gheqnecukfhppeekfedrkeeirdekledruddtjeenucfrrghrrghmpehmrghilhhfrhhomh epghhrvghgsehkrhhorghhrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) by mail.messagingengine.com (Postfix) with ESMTPA id 7839A8005C; Sun, 15 Dec 2019 06:08:44 -0500 (EST) Subject: FAILED: patch "[PATCH] btrfs: use btrfs_block_group_cache_done in update_block_group" failed to apply to 4.14-stable tree To: josef@toxicpanda.com, dsterba@suse.com, nborisov@suse.com Cc: From: Date: Sun, 15 Dec 2019 12:08:43 +0100 Message-ID: <1576408123214174@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ANSI_X3.4-1968 Content-Transfer-Encoding: 8bit Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to . thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From a60adce85f4bb5c1ef8ffcebadd702cafa2f3696 Mon Sep 17 00:00:00 2001 From: Josef Bacik Date: Tue, 24 Sep 2019 16:50:44 -0400 Subject: [PATCH] btrfs: use btrfs_block_group_cache_done in update_block_group When free'ing extents in a block group we check to see if the block group is not cached, and then cache it if we need to. However we'll just carry on as long as we're loading the cache. This is problematic because we are dirtying the block group here. If we are fast enough we could do a transaction commit and clear the free space cache while we're still loading the space cache in another thread. This truncates the free space inode, which will keep it from loading the space cache. Fix this by using the btrfs_block_group_cache_done helper so that we try to load the space cache unconditionally here, which will result in the caller waiting for the fast caching to complete and keep us from truncating the free space inode. CC: stable@vger.kernel.org # 4.4+ Signed-off-by: Josef Bacik Reviewed-by: Nikolay Borisov Signed-off-by: David Sterba diff --git a/fs/btrfs/block-group.c b/fs/btrfs/block-group.c index 384659dc7818..540a7a63601e 100644 --- a/fs/btrfs/block-group.c +++ b/fs/btrfs/block-group.c @@ -2661,7 +2661,7 @@ int btrfs_update_block_group(struct btrfs_trans_handle *trans, * is because we need the unpinning stage to actually add the * space back to the block group, otherwise we will leak space. */ - if (!alloc && cache->cached == BTRFS_CACHE_NO) + if (!alloc && !btrfs_block_group_cache_done(cache)) btrfs_cache_block_group(cache, 1); byte_in_group = bytenr - cache->key.objectid;