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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2B374C369CB for ; Wed, 23 Apr 2025 20:30:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 208696B0010; Wed, 23 Apr 2025 16:30:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1B7F96B0011; Wed, 23 Apr 2025 16:30:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 07F1A6B0012; Wed, 23 Apr 2025 16:30:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id DD7606B0010 for ; Wed, 23 Apr 2025 16:30:32 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 1A7EC57C78 for ; Wed, 23 Apr 2025 20:30:33 +0000 (UTC) X-FDA: 83366451546.23.8F102E2 Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by imf15.hostedemail.com (Postfix) with ESMTP id 4940DA0006 for ; Wed, 23 Apr 2025 20:30:31 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=TGUzH74f; spf=pass (imf15.hostedemail.com: domain of mcgrof@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=mcgrof@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1745440231; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=m2mtU6aDdxuIKsw5nKIe/OvXLW/yWCCiA5ukKIo3XPE=; b=zkEaX/wfzeee98pgRxzBMkoldtkqs/69ryDRvR2Mnj60xqgdIB2oWf6lq97UkY5iq7ROWZ oTExG3/rUb4z5ycHnfN50NtPPBm3Ui+opRJgGga0Vm7er79l+zxNYhhOsjnqNH9QFrZSYA RXbH9rzSzv1H3MG3SnFDpsyNfCIAXZE= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=TGUzH74f; spf=pass (imf15.hostedemail.com: domain of mcgrof@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=mcgrof@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1745440231; a=rsa-sha256; cv=none; b=P6yDD6I4YVOFeE/TwNOaNx41X5TL+ox7B66ccUCauuQgpx+sQ8IFODK71Auf2IQPJ+ajO2 RuZGJlPKWBgm4PpvrBfqdTEImT7JWNhbvRMr85h9jOFAVqlqOtVJlY2/sSvZiE/EU8gJRX WcEQRLBK50gexY1fBk2G+PXpJ/UTan4= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 41B724A732; Wed, 23 Apr 2025 20:30:28 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1D447C4CEE2; Wed, 23 Apr 2025 20:30:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1745440229; bh=zfnpkNpzO3aNFO+OP3lzklECKkdME0YLtwNkLDKthmg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=TGUzH74f/LbW6NCs62Zff+JfuLGq6keOuX4IvbzDuB7DNJNOg0P2wi/F/C8ehdk/k ko8avwyRSiYSNEzgOsF4orsz8i9yDCmLrQxklSvOxJvkHTtlgat36TbLOwMPEdgKks KqHhJjwCXz5fTZQzE9VhKvnXn4xGy5U/r+Dj3pIlWPS9FsefEAqf4rDvIG4/soxd3m QrGvXKFNUMWec92qJbCiTboJ5duU4pSb/Wu0PuCu6Hh2mhTKjgtQG2gC3sbfUSoxRP w2Ye2tW/1DgeFAXPwVlFyc7gyNmbc/Ij6EHFU/3HxoeSkLq0+6GWFKN4+/OrtRCoKf y27BZigv4ldQA== Date: Wed, 23 Apr 2025 13:30:27 -0700 From: Luis Chamberlain To: Jan Kara Cc: dave@stgolabs.net, brauner@kernel.org, tytso@mit.edu, adilger.kernel@dilger.ca, linux-ext4@vger.kernel.org, riel@surriel.com, willy@infradead.org, hannes@cmpxchg.org, oliver.sang@intel.com, david@redhat.com, axboe@kernel.dk, hare@suse.de, david@fromorbit.com, djwong@kernel.org, ritesh.list@gmail.com, linux-fsdevel@vger.kernel.org, linux-block@vger.kernel.org, linux-mm@kvack.org, gost.dev@samsung.com, p.raghav@samsung.com, da.gomez@samsung.com, syzbot+f3c6fda1297c748a7076@syzkaller.appspotmail.com Subject: Re: [PATCH v2 1/8] migrate: fix skipping metadata buffer heads on migration Message-ID: References: <20250410014945.2140781-1-mcgrof@kernel.org> <20250410014945.2140781-2-mcgrof@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: rxnkfjau17iwgqrrqau6pmwnsybfrpaf X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 4940DA0006 X-Rspam-User: X-HE-Tag: 1745440231-285232 X-HE-Meta: U2FsdGVkX1+dArDQj3dBWCawwTycHtIg1sWkbGgFDbcrZ2BEbTq/80sPaWimTPsJLoK2jSJ5MT7FJceay0GSys5FbBr5CGm+s2byS2gyCTK6UWcb1j9+qlfq0TLN5PBeHgL4iilhceNOdY0DeQQsoJM3SOV+A7SK2/FXTFO3Kl0uIzOkfqAcq/W7MhBxZug6eHUMKRzQdtkppTdTvYdXOXiT3AxTWm+TsjLalqM91H3t2snbnRC3wBSqD9XYEVzjo4juMETFkdH2I1tTX4XVowg5Sr3DZa4dpiuYAMblUEFi0pWPJWhbb/X+FvLkGxgK5VHyAOq+YzQ2ILYDABAzxbbYBN1WlXGTkKSguqaVS0JdpKvDc/XmoHQQr8Uyrtf5lyb48Ghn063AmLjerAFlCR6xk9OpYwpqXft4xiEDBA8IVqqNUiHgkTOeRfOSE5eogFN73qyYAob8PckZakHO8JCxn2pG8U1fBbILDzncMavzekBPA7FCCGcOT9IZNOFgdTv3Tivr9h3VNa9N2T8W4s34FQy+GVhIbtjgV+i+j3ZI/hNUcZJLGPLMCyCkqsrSpj08pZJ8XjltePwPZYxok9ZRXFYFTTabNmO/TJv1uvYx2fbpUxm4I17CxE3s61cmISd2/v/IQlxsk/TCm9P8zqeNsHKKPkgtnezT+Br0lyKsfbakm3yNLxf+gaxFcpcfvX5IaUMzHTlMl3u5m+eCjlTzZXzUwdCpKdrhtsNT3lHNuZ3XcTECjFBNSnu0YPuNSsnIBOxPb55LTNeMsgZ5eWeU8kSVLevb1jHN3Ljt/vkeit4SVNqQ4bQUg+mMkrytJohQ6Ivxv/sG+E/MuStCII39AgZJGFZjb1Z5XctVdboYL954ZxbybdTJx9eLxkS5hi7tSiKQZJ6mtbJ7YhC9hAY8KFLJVhDp4oUkV3hiJa/IF9ItUtvnuzL+o5dEqWudqZ1ON5B8TOnVbSGSsa9 DaFlc2uE yOlRWmbzZkRRPfj7KN2xhnwakQ0UmM0+TZ6nYc8+r6XzixOyW4OGnH9JrhFkPKP6DweJWQpPtcJA9flVqgsnd+NSuAA0jB3Yv0UjPNCFKlJZPyVXtQ539LtDlCd0xver3vgEvWg9e2AelftWxm/GgmONxMNT6bblB4E72vzDzAQPijkB6DCV6IM8gwog4NqbK5+jz2ALJY2sZMZH1KDtvqBIgbS3wOk+15N9Y+Q1OdBEXyTzixOoVoJ3s82AOQRI1DxIzjKz3/AC0BI6V7oGZHSb2jtw+bxrTN4QiF96jTZavNwPeFnVW/K87cqMKNxaiV5ZyQa1v164TgkUgxGQgUnyneSq+2V0cWbYw5ZO2xG7Dpy/DEMpTYcAwRh6y+iAT8augYyvQsDCG125x2BfvhehrYnWWbfLfEEZWNNHdikFjjsteh7L3ppBxheNVYk22v5T2Jf44mH2sp2usbZ3wgI/iVb//lFMGCwhP X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Wed, Apr 23, 2025 at 07:09:28PM +0200, Jan Kara wrote: > On Wed 16-04-25 09:58:30, Luis Chamberlain wrote: > > On Tue, Apr 15, 2025 at 06:28:55PM +0200, Jan Kara wrote: > > > > So I tried: > > > > > > > > root@e1-ext4-2k /var/lib/xfstests # fsck /dev/loop5 -y 2>&1 > log > > > > e2fsck 1.47.2 (1-Jan-2025) > > > > root@e1-ext4-2k /var/lib/xfstests # wc -l log > > > > 16411 log > > > > > > Can you share the log please? > > > > Sure, here you go: > > > > https://github.com/linux-kdevops/20250416-ext4-jbd2-bh-migrate-corruption > > > > The last trace-0004.txt is a fresh one with Davidlohr's patches > > applied. It has trace-0004-fsck.txt. > > Thanks for the data! I was staring at them for some time and at this point > I'm leaning towards a conclusion that this is actually not a case of > metadata corruption but rather a bug in ext4 transaction credit computation > that is completely independent of page migration. > > Based on the e2fsck log you've provided the only damage in the filesystem > is from the aborted transaction handle in the middle of extent tree growth. > So nothing points to a lost metadata write or anything like that. And the > credit reservation for page writeback is indeed somewhat racy - we reserve > number of transaction credits based on current tree depth. However by the > time we get to ext4_ext_map_blocks() another process could have modified > the extent tree so we may need to modify more blocks than we originally > expected and reserved credits for. > > Can you give attached patch a try please? > > Honza > -- > Jan Kara > SUSE Labs, CR > From 4c53fb9f4b9b3eb4a579f69b7adcb6524d55629c Mon Sep 17 00:00:00 2001 > From: Jan Kara > Date: Wed, 23 Apr 2025 18:10:54 +0200 > Subject: [PATCH] ext4: Fix calculation of credits for extent tree modification > > Luis and David are reporting that after running generic/750 test for 90+ > hours on 2k ext4 filesystem, they are able to trigger a warning in > jbd2_journal_dirty_metadata() complaining that there are not enough > credits in the running transaction started in ext4_do_writepages(). > > Indeed the code in ext4_do_writepages() is racy and the extent tree can > change between the time we compute credits necessary for extent tree > computation and the time we actually modify the extent tree. Thus it may > happen that the number of credits actually needed is higher. Modify > ext4_ext_index_trans_blocks() to count with the worst case of maximum > tree depth. > > Link: https://lore.kernel.org/all/20250415013641.f2ppw6wov4kn4wq2@offworld > Reported-by: Davidlohr Bueso > Reported-by: Luis Chamberlain > Signed-off-by: Jan Kara I kicked off tests! Let's see after ~ 90 hours! Luis