From patchwork Sat Oct 22 07:26:55 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 7527 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4242:0:0:0:0:0 with SMTP id s2csp1105795wrr; Sat, 22 Oct 2022 01:36:12 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6M5fU7XdMQ37KTxl07+jpTRrxdu0FsRIgPGRpq+BS/UC0/tsazX8ctif4/obTuB3QWBpIE X-Received: by 2002:aa7:8a05:0:b0:56a:fd17:6720 with SMTP id m5-20020aa78a05000000b0056afd176720mr6118385pfa.1.1666427772292; Sat, 22 Oct 2022 01:36:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666427772; cv=none; d=google.com; s=arc-20160816; b=fo9tvu71dFDb58sbPJopsJd6M6fk+q5wvWpqAFNypBXhVI5uxAdVxyjs6aj/6JbBcO JH21GwTirlm6IbRzhw/9h0uV7SPXNzIW4N6weIYXRGOAXqdlAAGW6NT7F8H4hDnPOOxk eUj7GNfPHgnUP8SynpZ8MNGtHToL0DbVRTvgupqoExQ5ki70LJOWky0HYWo4WLV79mG6 JQ7O83OW68ri5uOxU8c8H6b9bPcWR9Dcx0fQT2TS/lKoquDKYigm7veT6D/zrZ8dau82 LEa9G5IzDF3lVrhrlkX/QIkn0YTldjEdpQnR9C54qpUeq5fz0f+UyHsLsBnN1Os4sHqG bPJQ== 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=mRjNevsjHmu6soZypnH8AnuQIel6+ino/dMijUWye8w=; b=zdXaRCg6P24nwR/Y73+/NPDpYIyINM4Trp9gxdyxeePwAMcaPLzba4V+2djF7hQ9cf aE/H+tT2EHTI7Ik+cQjY9iJ3ycb8vxvTeb7bPxyFpg4OqZIm38cX6IVHvxbksJIwGEnS Q7a/L3smiVW2lo6wbZp5gYdKkBMOuH9seXisJjITAZRDyf/OBrXUviLd53WPGT6btIRw /jSQyvqQig95htNi1fyrOpvaZUbg7qyrrdCkjXEdtowziGhmnXEHWjWGjf1mtDDuIJ8s GE/JEdHCDoshhmOQXXSgpMBXfOQOPjWW5h9kjK1g7CCiWxhafgQKBuAWHeIuUkXDNeOW UBvg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=qRLNu5E7; 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 20-20020a631154000000b0043c0b452d3csi29495349pgr.69.2022.10.22.01.35.56; Sat, 22 Oct 2022 01:36:12 -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=qRLNu5E7; 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 S233869AbiJVIXp (ORCPT + 99 others); Sat, 22 Oct 2022 04:23:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56472 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233843AbiJVIVq (ORCPT ); Sat, 22 Oct 2022 04:21:46 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EC9F013A582; Sat, 22 Oct 2022 00:59:03 -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 dfw.source.kernel.org (Postfix) with ESMTPS id 6566560ADC; Sat, 22 Oct 2022 07:59:03 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3DEB0C433D6; Sat, 22 Oct 2022 07:59:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1666425542; bh=VvCdVM0o6p1PxXk6TZ1vPl1OdkJWcfXxLrIRwfpPLSI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=qRLNu5E7b33lgKGI/7FnKUbAiodRumhfvj9BrAuueiwae6ys/UDWn59E6BBGo/bA4 ULTkhE0aK41dpe3LCYGDLGzoK7LF0Ut/5souDfi7ty2jXE35FTLNt5TOniUZGW7l8g Hh6/qnBD5veXTKcBCFdm6vHUHBHCwdkcQhJ72VZc= 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 5.19 536/717] f2fs: fix race condition on setting FI_NO_EXTENT flag Date: Sat, 22 Oct 2022 09:26:55 +0200 Message-Id: <20221022072522.027714075@linuxfoundation.org> X-Mailer: git-send-email 2.38.1 In-Reply-To: <20221022072415.034382448@linuxfoundation.org> References: <20221022072415.034382448@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 X-Spam-Status: No, score=-7.3 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?1747376167628804008?= X-GMAIL-MSGID: =?utf-8?q?1747376167628804008?= 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 866e72b29bd5..761fd42c93f2 100644 --- a/fs/f2fs/extent_cache.c +++ b/fs/f2fs/extent_cache.c @@ -804,9 +804,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); if (et->largest.len) { et->largest.len = 0;