From patchwork Thu Jun 29 12:00:32 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kemeng Shi X-Patchwork-Id: 114144 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:994d:0:b0:3d9:f83d:47d9 with SMTP id k13csp9379480vqr; Wed, 28 Jun 2023 21:04:19 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7wjk6p64U4inNaO/h331vZ4R9NQ8F0lEUOywBK4Zdjumvm/+pldWLoSVUpROZpNKC4U/cM X-Received: by 2002:a17:90b:51c9:b0:262:ba7e:df16 with SMTP id sf9-20020a17090b51c900b00262ba7edf16mr14434839pjb.6.1688011459190; Wed, 28 Jun 2023 21:04:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1688011459; cv=none; d=google.com; s=arc-20160816; b=ajhspyh5pQUNUdT9WT4g/3CFcEA6NYcI0mbPyeUL0SBC8CqbKedR7RPxAPU0iUWrqj JKRnMxsEBPsrWAcXREItncOTQLtUy0pzXlGcPrt5CoibhRDYCkXddyC6Jve9j33QDZ6B VtQYpgy8YJ4+qfsZ5jAcedhQURHKXrQUpMVskMzb+vy2YvTm6Sgo1qTsZDmVdUuMmFEI Jwtb8s4RXvQ/56vmunBh+gOwOwsDTJh0/nomujFvw259bCz2fS8kjiJlCenaHF0Y8Pa5 Fy6Vj29pVfCKvJGvzqKBUNViLQiah1cKy4p+L1frwpeIkKU3JzE/rvWyLWePXsq/q146 A4Pw== 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 :references:in-reply-to:message-id:date:subject:cc:to:from; bh=4jWWciF2CCDZ/Y3v43oUKeyJFiomqCHVdih8Pzvky7c=; fh=eu2llfKjKKC0QBUtW6YWJ13du6subP7SB8ZN6DjSWMA=; b=EywjYNMsC2QwroycYmLTD86BkYgeP8ZFV2G9bVcr6Ajp8zIxSC7DTFvvRdZT3fT8j8 IXH+lgMOH0vS4JrUh25u0G9zZR0m3z45HEdH1YStrndtu77ydej4e4mYcnt+Nsgvjm5S tajV29gYUN7iWhwTZd7ZOazkyKgyahdbKzYs/dmZs44C9ej7op/PNRGwbY8zkJVU+Xt4 9mqpGLYaHg7QxLmu9PKlZhgpYhjvNxc6gAr+9E++C+JTapMElj+REwQxh2XLAUeyEtim Ec6feegSve0U/4G8BFT0q21Sc5qS9Iq37OlNED1CUKzZwPqUU/59CySS+8fAE7aoCf1w uAFw== ARC-Authentication-Results: i=1; mx.google.com; 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 Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id c15-20020a17090a558f00b0023a177c4951si10355993pji.39.2023.06.28.21.04.06; Wed, 28 Jun 2023 21:04: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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231996AbjF2EAQ (ORCPT + 99 others); Thu, 29 Jun 2023 00:00:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44288 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230476AbjF2D7x (ORCPT ); Wed, 28 Jun 2023 23:59:53 -0400 Received: from dggsgout12.his.huawei.com (unknown [45.249.212.56]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BBE7B130; Wed, 28 Jun 2023 20:59:51 -0700 (PDT) Received: from mail02.huawei.com (unknown [172.30.67.143]) by dggsgout12.his.huawei.com (SkyGuard) with ESMTP id 4Qs4TZ0nSnz4f3mLf; Thu, 29 Jun 2023 11:59:46 +0800 (CST) Received: from huaweicloud.com (unknown [10.175.124.27]) by APP2 (Coremail) with SMTP id Syh0CgC3quiwAZ1kw6DMMg--.26995S3; Thu, 29 Jun 2023 11:59:48 +0800 (CST) From: Kemeng Shi To: tytso@mit.edu, adilger.kernel@dilger.ca Cc: linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH 01/13] ext4: correct offset of gdb backup in non meta_bg group to update_backups Date: Thu, 29 Jun 2023 20:00:32 +0800 Message-Id: <20230629120044.1261968-2-shikemeng@huaweicloud.com> X-Mailer: git-send-email 2.30.0 In-Reply-To: <20230629120044.1261968-1-shikemeng@huaweicloud.com> References: <20230629120044.1261968-1-shikemeng@huaweicloud.com> MIME-Version: 1.0 X-CM-TRANSID: Syh0CgC3quiwAZ1kw6DMMg--.26995S3 X-Coremail-Antispam: 1UD129KBjvJXoW7tw1fKF4fAry3Ww4fuw4rXwb_yoW8AFWDpw 4qkr18Gry8KrWDua1xA340gryFkw48Ga4jvrW3Zw1UuFy7Jas7WF97tF95AF4jqFZ3AFn7 WFWa934UAwn7J3DanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUBjb4IE77IF4wAFF20E14v26r4j6ryUM7CY07I20VC2zVCF04k2 6cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M280x2IEY4vEnII2IxkI6r1a6r45M2 8IrcIa0xkI8VA2jI8067AKxVWUGwA2048vs2IY020Ec7CjxVAFwI0_Jrv_JF4l8cAvFVAK 0II2c7xJM28CjxkF64kEwVA0rcxSw2x7M28EF7xvwVC0I7IYx2IY67AKxVW7JVWDJwA2z4 x0Y4vE2Ix0cI8IcVCY1x0267AKxVW8Jr0_Cr1UM28EF7xvwVC2z280aVAFwI0_GcCE3s1l 84ACjcxK6I8E87Iv6xkF7I0E14v26rxl6s0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I 8CrVACY4xI64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AK xVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41l42xK82IYc2Ij64 vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUJVWUGwC20s026x8G jcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r126r1DMIIYrxkI7VAKI48JMIIF0xvE2I x0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0xvE42xK 8VAvwI8IcIk0rVWUJVWUCwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I 0E14v26r1j6r4UYxBIdaVFxhVjvjDU0xZFpf9x07js2-5UUUUU= X-CM-SenderInfo: 5vklyvpphqwq5kxd4v5lfo033gof0z/ X-CFilter-Loop: Reflected X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_00,DATE_IN_FUTURE_06_12, KHOP_HELO_FCRDNS,SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE 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?1770008303747085507?= X-GMAIL-MSGID: =?utf-8?q?1770008303747085507?= Commit 0aeaa2559d6d5 ("ext4: fix corruption when online resizing a 1K bigalloc fs") found that primary superblock's offset in its group is not equal to offset of backup superblock in its group when block size is 1K and bigalloc is enabled. As group descriptor blocks are right after superblock, we can't pass block number of gdb to update_backups for the same reason. The root casue of the issue above is that leading 1K padding block is count as data block offset for primary block while backup block has no padding block offset in its group. Remove padding data block count to fix the issue for gdb backups. For meta_bg case, update_backups treat blk_off as block number, do no conversion in this case. Signed-off-by: Kemeng Shi Reviewed-by: Theodore Ts'o --- fs/ext4/resize.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/fs/ext4/resize.c b/fs/ext4/resize.c index 0361c20910de..87cd5b07a970 100644 --- a/fs/ext4/resize.c +++ b/fs/ext4/resize.c @@ -1601,6 +1601,8 @@ static int ext4_flex_group_add(struct super_block *sb, int gdb_num_end = ((group + flex_gd->count - 1) / EXT4_DESC_PER_BLOCK(sb)); int meta_bg = ext4_has_feature_meta_bg(sb); + sector_t padding_blocks = meta_bg ? 0 : sbi->s_sbh->b_blocknr - + ext4_group_first_block_no(sb, 0); sector_t old_gdb = 0; update_backups(sb, ext4_group_first_block_no(sb, 0), @@ -1612,8 +1614,8 @@ static int ext4_flex_group_add(struct super_block *sb, gdb_num); if (old_gdb == gdb_bh->b_blocknr) continue; - update_backups(sb, gdb_bh->b_blocknr, gdb_bh->b_data, - gdb_bh->b_size, meta_bg); + update_backups(sb, gdb_bh->b_blocknr - padding_blocks, + gdb_bh->b_data, gdb_bh->b_size, meta_bg); old_gdb = gdb_bh->b_blocknr; } }