From patchwork Mon Oct 24 11:31:17 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 8636 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp420965wru; Mon, 24 Oct 2022 05:19:19 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6ahwZ6g7qG0oG5nTwey82Wim+fqj73CIdAol12BW5z0g/bFLITvLpjjGwJg8kpBb/nnWDU X-Received: by 2002:a17:906:5dd8:b0:78d:efa7:f78d with SMTP id p24-20020a1709065dd800b0078defa7f78dmr27729406ejv.641.1666613959056; Mon, 24 Oct 2022 05:19:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666613959; cv=none; d=google.com; s=arc-20160816; b=YVm199aSgLJr+JNU4eLytZEWEqB0S0ZSely/iqHg0+eHWUc2AstQImFkhe/tZt5jKZ axbfUciWP0kSC6Ml3+Q9vrKjb/24wPu+6RNif901mGdCXEHzW3e3R9iGgwtTmPF4RdIO tV5NMotnWUb6y3eCH+qt5Vr4Ibt2ANeY9agjbEctNo+O88ju1h9349mRFVq8zJzloNWo YJjK5kR/PEDaQZaXZMkRakM9lTe6odYn/S/W58sWUv5UssVUnqkiSXjqN149rz2Ni7Ay yeHvVYE5DxOCliWpyoIYHKMWKCRSUQ4N+9kPBXABfijTtlqSNuRBSprocK8mh8oq8Ge1 QUwA== 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=1GTd04xr45r8QYY/A9UzaP8zmYL13RIrVodPoZSAS5I=; b=0+Bvr3VfH86ipUEx5MFwz5rGfLwUb3BmfPjqUr45hMrScHijXAn0s5VByMKMEkKIdn D7bqVUOgVZhW/3zmYuymdUeex6FqE2ixYtt9JWOQeQugTRgrDs9ipL9gOXKEuOSv7dpX bVEBJZcy/RKsefTjI3XRS1GP3OrwHWD3/TPhTOXKAADRVgG41sHa0wjRYBtbIiyejqBi +6PnkiI7JS/JkSKPuVx96h8tmcs5KlAKK/GImtO89Acwzek6p0E5B2gTuxWTDJTwNyI1 S2g/7orUQxv3RaUVTP9ofqkURMhDGzSvKb9gl2G/vyoI826I2HpIdqBmxSyItN5WBAF6 s3/Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=0CzFl04h; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id s5-20020a056402164500b00461ebe2a168si873457edx.447.2022.10.24.05.18.54; Mon, 24 Oct 2022 05:19:19 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=0CzFl04h; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 S230138AbiJXMNg (ORCPT + 99 others); Mon, 24 Oct 2022 08:13:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59528 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232440AbiJXMMw (ORCPT ); Mon, 24 Oct 2022 08:12:52 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AF113A1BD; Mon, 24 Oct 2022 04:54:24 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id D93D6B81144; Mon, 24 Oct 2022 11:52:20 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3A2FBC433C1; Mon, 24 Oct 2022 11:52:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1666612339; bh=ryw8RjTm44Jgi9Xgr6nzwugNpPMq9/+jR2HPtMHVXao=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=0CzFl04hFuQMJ/3bGv4fKJzzNc5Pe0doX5k3XPTwObe+Pprijxm8+IQNi2ypFIO26 9JznBNRLPa6j6+y16UJtCi3o2boLnMAm86eW7nF+KJ0B2otk8dxOOChNpKDclmGGgn 1IMKYbCsstQI7jIQ8bp2lt9xvUlegv9FiEQIRKCA= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Zhang Qilong , Chao Yu , Jaegeuk Kim , Sasha Levin Subject: [PATCH 4.14 160/210] f2fs: fix race condition on setting FI_NO_EXTENT flag Date: Mon, 24 Oct 2022 13:31:17 +0200 Message-Id: <20221024113002.169798376@linuxfoundation.org> X-Mailer: git-send-email 2.38.1 In-Reply-To: <20221024112956.797777597@linuxfoundation.org> References: <20221024112956.797777597@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 X-Spam-Status: No, score=-7.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1747571398649460036?= X-GMAIL-MSGID: =?utf-8?q?1747571398649460036?= From: Zhang Qilong [ Upstream commit 07725adc55c0a414c10acb5c8c86cea34b95ddef ] The following scenarios exist. process A: process B: ->f2fs_drop_extent_tree ->f2fs_update_extent_cache_range ->f2fs_update_extent_tree_range ->write_lock ->set_inode_flag ->is_inode_flag_set ->__free_extent_tree // Shouldn't // have been // cleaned up // here ->write_lock In this case, the "FI_NO_EXTENT" flag is set between f2fs_update_extent_tree_range and is_inode_flag_set by other process. it leads to clearing the whole exten tree which should not have happened. And we fix it by move the setting it to the range of write_lock. Fixes:5f281fab9b9a3 ("f2fs: disable extent_cache for fcollapse/finsert inodes") Signed-off-by: Zhang Qilong Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin --- fs/f2fs/extent_cache.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/fs/f2fs/extent_cache.c b/fs/f2fs/extent_cache.c index aff6c2ed1c02..042c9d4f73cf 100644 --- a/fs/f2fs/extent_cache.c +++ b/fs/f2fs/extent_cache.c @@ -709,9 +709,8 @@ void f2fs_drop_extent_tree(struct inode *inode) if (!f2fs_may_extent_tree(inode)) return; - set_inode_flag(inode, FI_NO_EXTENT); - write_lock(&et->lock); + set_inode_flag(inode, FI_NO_EXTENT); __free_extent_tree(sbi, et); __drop_largest_extent(inode, 0, UINT_MAX); write_unlock(&et->lock);