From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D89491DDC22; Thu, 30 Jan 2025 14:15:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1738246551; cv=none; b=FOFsPY8k3Gi2RD97vXx1Rbi362ZDIiaZ+t7SRJIRXrbt5qW9yfozk3ejBdkIzGyW2EEpoj4gZ8xgJmcuZ2Hw6l/pNOgAt3s1eFkpTwgkbZE0qLpisFQf2pGvZy3+elVQnNN9Mp7rQbromssSmUpP9kBGohaMzL6f68NEHYIoT+c= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1738246551; c=relaxed/simple; bh=qfWP0gMwouGu2bS34AyVR3J5qEoRH94ERzMgy43XIBE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Z5ysG/w92AN8ZeyZMnQBaueDs9kpA0I5yFvtDSuHOEmOASuhig6nO1ML53RtLV5HMLJNRz8KjKM85vnOKzH7fjrM57lMBV/vfYVosf0KiOyi2blK3xnscMHC6rOlH7aZ72ZJFFqaQ5Gufwm0AO6+Mxw6bxPX8v2N3X0UXndsdBU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=ek3d8ehA; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="ek3d8ehA" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 15AC4C4CED2; Thu, 30 Jan 2025 14:15:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1738246551; bh=qfWP0gMwouGu2bS34AyVR3J5qEoRH94ERzMgy43XIBE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ek3d8ehAP+t4M+CHhPOnsflmuFSGBGLyQYkUFApmc3reqdci1Bz6jhMzKfS/ZhsDY ZNvGnKsVThpMc7hxo1Fm/7cuUdFusmtH2KOgB6pWHj0Py6hXnhPVD1yWrdIKtyn10f A9I52OXxceOH+Cov6z16J3FLrHUZVLjV8TM7EwLA= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, "Luis Henriques (SUSE)" , Theodore Tso , stable@kernel.org, Bruno VERNAY , Victor Giraud Subject: [PATCH 6.6 31/43] ext4: fix access to uninitialised lock in fc replay path Date: Thu, 30 Jan 2025 14:59:38 +0100 Message-ID: <20250130133500.153996883@linuxfoundation.org> X-Mailer: git-send-email 2.48.1 In-Reply-To: <20250130133458.903274626@linuxfoundation.org> References: <20250130133458.903274626@linuxfoundation.org> User-Agent: quilt/0.68 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 6.6-stable review patch. If anyone has any objections, please let me know. ------------------ From: Luis Henriques (SUSE) commit 23dfdb56581ad92a9967bcd720c8c23356af74c1 upstream. The following kernel trace can be triggered with fstest generic/629 when executed against a filesystem with fast-commit feature enabled: INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. CPU: 0 PID: 866 Comm: mount Not tainted 6.10.0+ #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x66/0x90 register_lock_class+0x759/0x7d0 __lock_acquire+0x85/0x2630 ? __find_get_block+0xb4/0x380 lock_acquire+0xd1/0x2d0 ? __ext4_journal_get_write_access+0xd5/0x160 _raw_spin_lock+0x33/0x40 ? __ext4_journal_get_write_access+0xd5/0x160 __ext4_journal_get_write_access+0xd5/0x160 ext4_reserve_inode_write+0x61/0xb0 __ext4_mark_inode_dirty+0x79/0x270 ? ext4_ext_replay_set_iblocks+0x2f8/0x450 ext4_ext_replay_set_iblocks+0x330/0x450 ext4_fc_replay+0x14c8/0x1540 ? jread+0x88/0x2e0 ? rcu_is_watching+0x11/0x40 do_one_pass+0x447/0xd00 jbd2_journal_recover+0x139/0x1b0 jbd2_journal_load+0x96/0x390 ext4_load_and_init_journal+0x253/0xd40 ext4_fill_super+0x2cc6/0x3180 ... In the replay path there's an attempt to lock sbi->s_bdev_wb_lock in function ext4_check_bdev_write_error(). Unfortunately, at this point this spinlock has not been initialized yet. Moving it's initialization to an earlier point in __ext4_fill_super() fixes this splat. Signed-off-by: Luis Henriques (SUSE) Link: https://patch.msgid.link/20240718094356.7863-1-luis.henriques@linux.dev Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Bruno VERNAY Signed-off-by: Victor Giraud Signed-off-by: Greg Kroah-Hartman --- fs/ext4/super.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/fs/ext4/super.c +++ b/fs/ext4/super.c @@ -5366,6 +5366,8 @@ static int __ext4_fill_super(struct fs_c INIT_LIST_HEAD(&sbi->s_orphan); /* unlinked but open files */ mutex_init(&sbi->s_orphan_lock); + spin_lock_init(&sbi->s_bdev_wb_lock); + ext4_fast_commit_init(sb); sb->s_root = NULL; @@ -5586,7 +5588,6 @@ static int __ext4_fill_super(struct fs_c * Save the original bdev mapping's wb_err value which could be * used to detect the metadata async write error. */ - spin_lock_init(&sbi->s_bdev_wb_lock); errseq_check_and_advance(&sb->s_bdev->bd_inode->i_mapping->wb_err, &sbi->s_bdev_wb_err); EXT4_SB(sb)->s_mount_state |= EXT4_ORPHAN_FS;