Received: by 2002:a05:6359:c8b:b0:c7:702f:21d4 with SMTP id go11csp3060721rwb; Thu, 29 Sep 2022 20:22:40 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4Nz/5FSMLVpYNtYqYrkymvK0+ibZzjHh6vanUuHc8YSEKlUohuiVtEcq+7l3M/m56+kQPV X-Received: by 2002:a05:6a00:1486:b0:557:f3c7:219f with SMTP id v6-20020a056a00148600b00557f3c7219fmr7046989pfu.0.1664508160141; Thu, 29 Sep 2022 20:22:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1664508160; cv=none; d=google.com; s=arc-20160816; b=Wwr1jxvm9+eZgnCd2PFluCbF9J9HsRtXj0EE4yMs1L5SOdHjsOueIjLcJdftN9b9q2 y3jnV/gyvYGfK1oRMe8qTlcnAYnp5w5iAUyR1Ztr4wFpH7BmjpYTpibkwC145UA+nFhQ SED7ylrG07ShtbG58ozx9d0ceoJYs3p2Vp8uXZ8Ss21KRj8KO5hJxq7ZicvTRtZfvrUA 7rDFBF6iFRbtvJ2XBxmG986X+TO/mRXBGiaC43/2evrQO3G9jVxNuh/5I1QBqlQO9uJE irlQA33VKXcrTR0HtDYuFHRdtZmJEgQ4C8IdPNpHaHmd+tK0ZHCa5Z6PGYFmGeJFKZ1U PMRQ== 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 :dkim-signature; bh=wbmc59Hi5lkZ5pGKDWQ/rsCK/98T7RRRP7hGWZ8JwOQ=; b=YMc5lYSURM/AdUzEleYh9PO0hj5gEN+Fz4jv5QD0704JtXhmV3BJxqyuT1CGZBKyzG 7ombwakJ5kJcdGNcAba/4nVikdjZxg8FB3SxTuw/Ox0JNerzDHmt3DoQ+dnbPNJl7eZN 82dbCMVFz1q2umhShwNGPYZhHBNBYKb4Ms5Q04McmaoRW6VqI77PlO2+YqXfhP0UiyrG GuOf9tsvbNktPD09Ph/zUNCSp+r5KKzLvpjSa5aPA09uDlRF1IZjkpNp6weAYmyCGgpX sY39mCn86ulqx/0OuP3+kNEJ9YheoZG1lFX0WHdZsF54dIBUGJcMZYs9VLuqTfbr1zo2 q7aQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@mit.edu header.s=outgoing header.b=ConY56k7; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mit.edu Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id k10-20020a056a00134a00b005409c35a01dsi1308038pfu.351.2022.09.29.20.22.21; Thu, 29 Sep 2022 20:22:40 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-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=fail header.i=@mit.edu header.s=outgoing header.b=ConY56k7; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mit.edu Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230056AbiI3DUv (ORCPT + 99 others); Thu, 29 Sep 2022 23:20:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60628 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230079AbiI3DUg (ORCPT ); Thu, 29 Sep 2022 23:20:36 -0400 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6E9093F316; Thu, 29 Sep 2022 20:20:06 -0700 (PDT) Received: from cwcc.thunk.org (pool-173-48-120-46.bstnma.fios.verizon.net [173.48.120.46]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 28U3Jljv002400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 29 Sep 2022 23:19:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1664507990; bh=wbmc59Hi5lkZ5pGKDWQ/rsCK/98T7RRRP7hGWZ8JwOQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=ConY56k7wJo43xZentvhnzG8bGYK8Da+W7WpuSnN9c4Wtn6sPuRc5/khav9wV+D7i xD9VCQ0iqhiYMpCuc/bHSz5LTwMG98leNn4ZUVdVhQ8xX3+Zkw+WeRWrH6/HP+GmJp pa9zFhk5dYjlZ8BizQXr8UxNQpXn402oNhA3g8a28Vi+0U+Jua6XUPtiEH8UKVHE1C W+8CN2Xe6Vh0zdCjJ1EbHHB2MXV22EjsefFonJ8jO4D6aczTL5jTvcJUrHcQlc0z+9 ioHXqMKgPq+9xr0sPfA6buihy9FkJ6q1fB2BEvV7qLIV+dc2K5vk0w4Ig6jfjcMpgQ q1fGSeYhMZoMQ== Received: by cwcc.thunk.org (Postfix, from userid 15806) id 8A5A915C343F; Thu, 29 Sep 2022 23:19:47 -0400 (EDT) From: "Theodore Ts'o" To: adilger.kernel@dilger.ca, chengzhihao1@huawei.com, jack@suse.cz Cc: "Theodore Ts'o" , linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org, yukuai3@huawei.com Subject: Re: [PATCH v2] ext4: Fix dir corruption when ext4_dx_add_entry() fails Date: Thu, 29 Sep 2022 23:19:32 -0400 Message-Id: <166450797716.256913.17964821049214407214.b4-ty@mit.edu> X-Mailer: git-send-email 2.31.0 In-Reply-To: <20220911045204.516460-1-chengzhihao1@huawei.com> References: <20220911045204.516460-1-chengzhihao1@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_NONE 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-ext4@vger.kernel.org On Sun, 11 Sep 2022 12:52:04 +0800, Zhihao Cheng wrote: > Following process may lead to fs corruption: > 1. ext4_create(dir/foo) > ext4_add_nondir > ext4_add_entry > ext4_dx_add_entry > a. add_dirent_to_buf > ext4_mark_inode_dirty > ext4_handle_dirty_metadata // dir inode bh is recorded into journal > b. ext4_append // dx_get_count(entries) == dx_get_limit(entries) > ext4_bread(EXT4_GET_BLOCKS_CREATE) > ext4_getblk > ext4_map_blocks > ext4_ext_map_blocks > ext4_mb_new_blocks > dquot_alloc_block > dquot_alloc_space_nodirty > inode_add_bytes // update dir's i_blocks > ext4_ext_insert_extent > ext4_ext_dirty // record extent bh into journal > ext4_handle_dirty_metadata(bh) > // record new block into journal > inode->i_size += inode->i_sb->s_blocksize // new size(in mem) > c. ext4_handle_dirty_dx_node(bh2) > // record dir's new block(dx_node) into journal > d. ext4_handle_dirty_dx_node((frame - 1)->bh) > e. ext4_handle_dirty_dx_node(frame->bh) > f. do_split // ret err! > g. add_dirent_to_buf > ext4_mark_inode_dirty(dir) // update raw_inode on disk(skipped) > 2. fsck -a /dev/sdb > drop last block(dx_node) which beyonds dir's i_size. > /dev/sdb: recovering journal > /dev/sdb contains a file system with errors, check forced. > /dev/sdb: Inode 12, end of extent exceeds allowed value > (logical block 128, physical block 3938, len 1) > 3. fsck -fn /dev/sdb > dx_node->entry[i].blk > dir->i_size > Pass 2: Checking directory structure > Problem in HTREE directory inode 12 (/dir): bad block number 128. > Clear HTree index? no > Problem in HTREE directory inode 12: block #3 has invalid depth (2) > Problem in HTREE directory inode 12: block #3 has bad max hash > Problem in HTREE directory inode 12: block #3 not referenced > > [...] Applied, thanks! [1/1] ext4: Fix dir corruption when ext4_dx_add_entry() fails commit: 7a3584fd605e6a72036c5759a6e9ed2c46d14899 Best regards, -- Theodore Ts'o