From mboxrd@z Thu Jan 1 00:00:00 1970 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 97885C64EC4 for ; Fri, 10 Mar 2023 12:36:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229814AbjCJMgV (ORCPT ); Fri, 10 Mar 2023 07:36:21 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47346 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230515AbjCJMgM (ORCPT ); Fri, 10 Mar 2023 07:36:12 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 96F6F11050D for ; Fri, 10 Mar 2023 04:35:45 -0800 (PST) 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 2DB82B82292 for ; Fri, 10 Mar 2023 12:35:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPS id A2877C433EF for ; Fri, 10 Mar 2023 12:35:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1678451742; bh=LY7DNygh9UDqHoFOmuPjhP2YMpt71dMzZlWV1gDnBLg=; h=From:To:Subject:Date:From; b=dr2DJCuLQ0xWtBndbVbTqR/fumcObMwOfXyq5qxzM+l/o7+5W+96gYQh3LOU4dUwx lr1IiHzTBaHaoQP0yE81mlEJDCSTHEYqNIWTlT2uSSM64+bBTWQS4sQVdLeP2umLMg ALZI97aYhB8VWUCMB/7497bUnJIun39sCTROhnp9//El9AjbayZ0Ls0syP5jiMylXM dxikkfqv/cuIykp5DURrAMV0/Y6PO2jHrKBWzxAwwx1KGI7OXlNBWgZ3qqZrh7/+Jq boEDs+pLNNH5jp9Z11v5agCW+iOu1katpdpqlu4hCcBaDrFbyJ8xZCXdZlvo4Soejn J8uUOcuv0E8VQ== Received: by aws-us-west-2-korg-bugzilla-1.web.codeaurora.org (Postfix, from userid 48) id 8BE9CC43143; Fri, 10 Mar 2023 12:35:42 +0000 (UTC) From: bugzilla-daemon@kernel.org To: linux-ext4@vger.kernel.org Subject: [Bug 217171] New: ext4: stale buffer loading from last failed mounting Date: Fri, 10 Mar 2023 12:35:42 +0000 X-Bugzilla-Reason: None X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: AssignedTo fs_ext4@kernel-bugs.osdl.org X-Bugzilla-Product: File System X-Bugzilla-Component: ext4 X-Bugzilla-Version: 2.5 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: chengzhihao1@huawei.com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: fs_ext4@kernel-bugs.osdl.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version cf_kernel_version rep_platform op_sys cf_tree bug_status bug_severity priority component assigned_to reporter cf_regression Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugzilla.kernel.org/ Auto-Submitted: auto-generated MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org https://bugzilla.kernel.org/show_bug.cgi?id=3D217171 Bug ID: 217171 Summary: ext4: stale buffer loading from last failed mounting Product: File System Version: 2.5 Kernel Version: 6.3.0-rc1 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: ext4 Assignee: fs_ext4@kernel-bugs.osdl.org Reporter: chengzhihao1@huawei.com Regression: No Following process makes ext4 load stale buffer heads from last failed mounting in a new mounting operation: mount_bdev ext4_fill_super | ext4_load_and_init_journal | ext4_load_journal | jbd2_journal_load | load_superblock | journal_get_superblock | set_buffer_verified(bh) // buffer head is verified | jbd2_journal_recover // failed caused by EIO | goto failed_mount3a // skip 'sb->s_root' initialization deactivate_locked_super kill_block_super generic_shutdown_super if (sb->s_root) // false, skip ext4_put_super->invalidate_bdev-> // invalidate_mapping_pages->mapping_evict_folio-> // filemap_release_folio->try_to_free_buffers, which // cannot drop buffer head. blkdev_put blkdev_put_whole if (atomic_dec_and_test(&bdev->bd_openers)) // false, systemd-udev happens to open the device. Then // blkdev_flush_mapping->kill_bdev->truncate_inode_pages-> // truncate_inode_folio->truncate_cleanup_folio-> // folio_invalidate->block_invalidate_folio-> // filemap_release_folio->try_to_free_buffers will be skipped, // dropping buffer head is missed again. Second mount: ext4_fill_super ext4_load_and_init_journal ext4_load_journal ext4_get_journal jbd2_journal_init_inode journal_init_common bh =3D getblk_unmovable bh =3D __find_get_block // Found stale bh in last failed mounting journal->j_sb_buffer =3D bh jbd2_journal_load load_superblock journal_get_superblock if (buffer_verified(bh)) // true, skip journal->j_format_version =3D 2, value is 0 jbd2_journal_recover do_one_pass next_log_block +=3D count_tags(journal, bh) // According to journal_tag_bytes(), 'tag_bytes' calculating is // affected by jbd2_has_feature_csum3(), jbd2_has_feature_csum3() // returns false because 'j->j_format_version >=3D 2' is not true, // then we get wrong next_log_block. The do_one_pass may exit // early whenoccuring non JBD2_MAGIC_NUMBER in 'next_log_block'. The filesystem is corrupted here, journal is partially replayed, and new journal sequence number actually is already used by last mounting. --=20 You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.=