From nobody Wed Jul 1 00:49:40 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 009CFC433EF for ; Thu, 6 Jan 2022 02:45:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344985AbiAFCpx (ORCPT ); Wed, 5 Jan 2022 21:45:53 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41138 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344971AbiAFCpn (ORCPT ); Wed, 5 Jan 2022 21:45:43 -0500 Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 42CECC061245 for ; Wed, 5 Jan 2022 18:45:43 -0800 (PST) Received: by mail-pl1-x62e.google.com with SMTP id s15so1488954plg.12 for ; Wed, 05 Jan 2022 18:45:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20210112.gappssmtp.com; s=20210112; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=mr4s4nuuaCvYTCilFynb0p++Jy6qt5NsbzJkkeE6Tok=; b=M4TAkqJVQ9rDDfSXIEgYs/IT84za+xvc43NVzidRcWVDZKI6wsVv6lacZmG2ifuBAE EykRtEwmsJ5rdUfmQ2Flvz1K6k/58tOF78Hd7OVp77QDixo1TQqzmmIvJEQ7TN3SXCJz ZRz5dIdoIjhWR8TnGcWRGBG6MrYgZ3m95s9vRHeLFbeDJgv2zjiZ4N3AfBR2gS+uNugm cAIFCiCPFxZOoUGwER5r9NCpbq6mB6gdeLzcDAbsYvFK9IAhfNr9DgJ/eXEBnw1249oY KiqqsHi9q6WcOezgTlDIlaBkN/4+kqIldfZtnLUHmho3QI75V2gxKeoOgsH7Xy32doKC faTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=mr4s4nuuaCvYTCilFynb0p++Jy6qt5NsbzJkkeE6Tok=; b=Dq2gxkz9buDcmGgg4T1X+XLYjVOnZPtd/3lL9p2qL1/hMLa6IFHpo5XGfI2azo6Hfl VRKuRO6FZKTEb5kaW3E9pJnVR8oXeDCsIUGDz5W79W7hxfRLwatBLWhV03FlGgPYa4Q6 mi9vzn4NVdlCK2JGNK7N95ndcw2OnvqJZeih+WPvmGkXtL08okERcxSa1M8qsqu4DF+c e/oQ8daUjRHh67vAKw24z7j2aNYquhpKb4kw+1znDSwBcUS/S6gHYFzc3isdscnu4pj+ Zw9GszZMac0HhWGEnCDhHHj22aVPgmYuuReSdYt+Npk2X4I9duCjzVxA6WaoyyOwpuZQ vIcA== X-Gm-Message-State: AOAM531TsimqStJ246pGHnlCBsHWh6QGwJVZi/IxgP97tvpTW0hbBBc5 sh469tBedKJrC0/RCzbtMe4sVQ== X-Google-Smtp-Source: ABdhPJx34uGjbIZlUgC88uc5Ej7PFAD+EtASR7A6Sjy4wMXo+eQZ+yW4KKAPqEepMsxRxIp7pNdsPQ== X-Received: by 2002:a17:90b:4f4a:: with SMTP id pj10mr7561838pjb.112.1641437142813; Wed, 05 Jan 2022 18:45:42 -0800 (PST) Received: from yinxin.bytedance.net ([139.177.225.251]) by smtp.gmail.com with ESMTPSA id p12sm414244pfo.95.2022.01.05.18.45.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 05 Jan 2022 18:45:42 -0800 (PST) From: Xin Yin To: harshadshirwadkar@gmail.com, tytso@mit.edu, adilger.kernel@dilger.ca Cc: linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org, Xin Yin Subject: [PATCH 1/2] ext4: prevent used blocks from being allocated during fast commit replay Date: Thu, 6 Jan 2022 10:45:17 +0800 Message-Id: <20220106024518.8161-2-yinxin.x@bytedance.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220106024518.8161-1-yinxin.x@bytedance.com> References: <20220106024518.8161-1-yinxin.x@bytedance.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" during fast commit replay procedure, we clear inode blocks bitmap in ext4_ext_clear_bb(), this may cause ext4_mb_new_blocks_simple() allocate blocks still in use. make ext4_fc_record_regions() also record physical disk regions used by inodes during replay procedure. Then ext4_mb_new_blocks_simple() can excludes these blocks in use. Signed-off-by: Xin Yin Reviewed-by: Harshad Shirwadkar --- fs/ext4/ext4.h | 2 ++ fs/ext4/extents.c | 4 ++++ fs/ext4/fast_commit.c | 11 ++++++++--- 3 files changed, 14 insertions(+), 3 deletions(-) diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h index 82fa51d6f145..7b0686758691 100644 --- a/fs/ext4/ext4.h +++ b/fs/ext4/ext4.h @@ -2932,6 +2932,8 @@ bool ext4_fc_replay_check_excluded(struct super_block= *sb, ext4_fsblk_t block); void ext4_fc_replay_cleanup(struct super_block *sb); int ext4_fc_commit(journal_t *journal, tid_t commit_tid); int __init ext4_fc_init_dentry_cache(void); +int ext4_fc_record_regions(struct super_block *sb, int ino, + ext4_lblk_t lblk, ext4_fsblk_t pblk, int len, int replay); =20 /* mballoc.c */ extern const struct seq_operations ext4_mb_seq_groups_ops; diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c index c3e76a5de661..9b6c76629c93 100644 --- a/fs/ext4/extents.c +++ b/fs/ext4/extents.c @@ -6096,11 +6096,15 @@ int ext4_ext_clear_bb(struct inode *inode) =20 ext4_mb_mark_bb(inode->i_sb, path[j].p_block, 1, 0); + ext4_fc_record_regions(inode->i_sb, inode->i_ino, + 0, path[j].p_block, 1, 1); } ext4_ext_drop_refs(path); kfree(path); } ext4_mb_mark_bb(inode->i_sb, map.m_pblk, map.m_len, 0); + ext4_fc_record_regions(inode->i_sb, inode->i_ino, + map.m_lblk, map.m_pblk, map.m_len, 1); } cur =3D cur + map.m_len; } diff --git a/fs/ext4/fast_commit.c b/fs/ext4/fast_commit.c index 23d13983a281..f0cd20f5fe5e 100644 --- a/fs/ext4/fast_commit.c +++ b/fs/ext4/fast_commit.c @@ -1567,13 +1567,15 @@ static int ext4_fc_replay_create(struct super_block= *sb, struct ext4_fc_tl *tl, * Record physical disk regions which are in use as per fast commit area. = Our * simple replay phase allocator excludes these regions from allocation. */ -static int ext4_fc_record_regions(struct super_block *sb, int ino, - ext4_lblk_t lblk, ext4_fsblk_t pblk, int len) +int ext4_fc_record_regions(struct super_block *sb, int ino, + ext4_lblk_t lblk, ext4_fsblk_t pblk, int len, int replay) { struct ext4_fc_replay_state *state; struct ext4_fc_alloc_region *region; =20 state =3D &EXT4_SB(sb)->s_fc_replay_state; + if (replay && state->fc_regions_used !=3D state->fc_regions_valid) + state->fc_regions_used =3D state->fc_regions_valid; if (state->fc_regions_used =3D=3D state->fc_regions_size) { state->fc_regions_size +=3D EXT4_FC_REPLAY_REALLOC_INCREMENT; @@ -1591,6 +1593,9 @@ static int ext4_fc_record_regions(struct super_block = *sb, int ino, region->pblk =3D pblk; region->len =3D len; =20 + if (replay) + state->fc_regions_valid++; + return 0; } =20 @@ -1938,7 +1943,7 @@ static int ext4_fc_replay_scan(journal_t *journal, ret =3D ext4_fc_record_regions(sb, le32_to_cpu(ext.fc_ino), le32_to_cpu(ex->ee_block), ext4_ext_pblock(ex), - ext4_ext_get_actual_len(ex)); + ext4_ext_get_actual_len(ex), 0); if (ret < 0) break; ret =3D JBD2_FC_REPLAY_CONTINUE; --=20 2.20.1 From nobody Wed Jul 1 00:49:40 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 147AEC433FE for ; Thu, 6 Jan 2022 02:45:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344993AbiAFCp4 (ORCPT ); Wed, 5 Jan 2022 21:45:56 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41174 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344981AbiAFCpt (ORCPT ); Wed, 5 Jan 2022 21:45:49 -0500 Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EDB1DC06118A for ; Wed, 5 Jan 2022 18:45:48 -0800 (PST) Received: by mail-pg1-x536.google.com with SMTP id r5so1342785pgi.6 for ; Wed, 05 Jan 2022 18:45:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20210112.gappssmtp.com; s=20210112; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=pB9ixd309jdajttTHm9n2WuXxz/2zgca6PMdCtbA1H8=; b=sqp4SRvOVax4jD2sd2uTEErw/3HlMsCT8Kq+lArtmcRL/R/BceBTImeqHLY/+V1ki2 ofzk1QXs3EsDndi+227ANu85vtUI16kMg+j7kYkuDxGG5VDag5qC9M9VL+e7EVa8Xi1d p/u7MtxcJndcyKPPP3U8SVB8I+5j1jum55VV6QQla4hvmjw0xAX+uBu4scGSEOw2XnBl BL/A5Ir5y3s2oUXUH6nHmaEJlzoSGjuJebXDQkQ5nQSQvirX+okqc9ts0+5jCEPEEOlY AsLDgcwVfn3e65XkOEZL3qT4Xx6UAeXZ1LHxEeMKZ7ZcAGo5wpmCF3UbkdYttekugo84 c9KQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=pB9ixd309jdajttTHm9n2WuXxz/2zgca6PMdCtbA1H8=; b=BJcDgp1WjMIps9fbw08su7njQ2bQv5WHUpXQ8yB4e/wvUQXZgA5/CXHl2XF/TkCPIT PfIsIk4DKV94EataBicZHRGh4NlM6MZElxBvrrz1Tpi/lFWWdVQ3YjlZAdEW6b0N6cYm OBOpJ455zANucDAGbNI48b3Pk+kzERXN9m3C3IDFhXOuc45styNLqTYlU81voP59/2+h y3r/7krsX2tCCj378nF4NRLPo2zCUEgluMTuOjbxFaeyBNh751O/x4nptBihvWZi4axC Qfy/3WrEyUOw5X3BiA/5pdPKKjv5xS9oE1oTltuxj3IuvyR4ctoxEMOYqYTS9IWaiofA 0ctA== X-Gm-Message-State: AOAM530pSxK12dOw8PX43Rc+G3hHc7grO7Z9sRKWbBqWf8z6pBYhnHRo xDS8OPYo8G74anP1iIdxJGFMXFuTIbqc2A== X-Google-Smtp-Source: ABdhPJz1EAGyp79Lg8XVJc3VyhIObQSQ4Y2rSML71svFGe1MFS8/xezpM7v46uLzSYa389+jmuPzUg== X-Received: by 2002:a05:6a00:174d:b0:4bb:cbd7:c556 with SMTP id j13-20020a056a00174d00b004bbcbd7c556mr49331875pfc.26.1641437148543; Wed, 05 Jan 2022 18:45:48 -0800 (PST) Received: from yinxin.bytedance.net ([139.177.225.251]) by smtp.gmail.com with ESMTPSA id p12sm414244pfo.95.2022.01.05.18.45.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 05 Jan 2022 18:45:48 -0800 (PST) From: Xin Yin To: harshadshirwadkar@gmail.com, tytso@mit.edu, adilger.kernel@dilger.ca Cc: linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org, Xin Yin Subject: [PATCH 2/2] ext4: modify the logic of ext4_mb_new_blocks_simple Date: Thu, 6 Jan 2022 10:45:18 +0800 Message-Id: <20220106024518.8161-3-yinxin.x@bytedance.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220106024518.8161-1-yinxin.x@bytedance.com> References: <20220106024518.8161-1-yinxin.x@bytedance.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" for now in ext4_mb_new_blocks_simple, if we found a block which should be excluded then will switch to next group, this may probably cause 'group' run out of range. change to check next block in the same group when get a block should be excluded. Also change the searche range to EXT4_CLUSTERS_PER_GROUP and add error checking. Signed-off-by: Xin Yin --- fs/ext4/mballoc.c | 26 +++++++++++++++++--------- 1 file changed, 17 insertions(+), 9 deletions(-) diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c index 215b7068f548..31a00b473f3e 100644 --- a/fs/ext4/mballoc.c +++ b/fs/ext4/mballoc.c @@ -5757,7 +5757,8 @@ static ext4_fsblk_t ext4_mb_new_blocks_simple(handle_= t *handle, struct super_block *sb =3D ar->inode->i_sb; ext4_group_t group; ext4_grpblk_t blkoff; - int i =3D sb->s_blocksize; + ext4_grpblk_t max =3D EXT4_CLUSTERS_PER_GROUP(sb); + ext4_grpblk_t i =3D 0; ext4_fsblk_t goal, block; struct ext4_super_block *es =3D EXT4_SB(sb)->s_es; =20 @@ -5779,19 +5780,26 @@ static ext4_fsblk_t ext4_mb_new_blocks_simple(handl= e_t *handle, ext4_get_group_no_and_offset(sb, max(ext4_group_first_block_no(sb, group), goal), NULL, &blkoff); - i =3D mb_find_next_zero_bit(bitmap_bh->b_data, sb->s_blocksize, + while (1) { + i =3D mb_find_next_zero_bit(bitmap_bh->b_data, max, blkoff); + if (i >=3D max) + break; + if (ext4_fc_replay_check_excluded(sb, + ext4_group_first_block_no(sb, group) + i)) { + blkoff =3D i + 1; + } else + break; + } brelse(bitmap_bh); - if (i >=3D sb->s_blocksize) - continue; - if (ext4_fc_replay_check_excluded(sb, - ext4_group_first_block_no(sb, group) + i)) - continue; - break; + if (i < max) + break; } =20 - if (group >=3D ext4_get_groups_count(sb) && i >=3D sb->s_blocksize) + if (group >=3D ext4_get_groups_count(sb) || i >=3D max) { + *errp =3D -ENOSPC; return 0; + } =20 block =3D ext4_group_first_block_no(sb, group) + i; ext4_mb_mark_bb(sb, block, 1, 1); --=20 2.20.1