Patch Detail
get:
Show a patch.
patch:
Update a patch.
put:
Update a patch.
GET /api/1.2/patches/2211753/?format=api
{ "id": 2211753, "url": "http://patchwork.ozlabs.org/api/1.2/patches/2211753/?format=api", "web_url": "http://patchwork.ozlabs.org/project/linux-ext4/patch/20260317084624.457185-4-me@linux.beauty/", "project": { "id": 8, "url": "http://patchwork.ozlabs.org/api/1.2/projects/8/?format=api", "name": "Linux ext4 filesystem development", "link_name": "linux-ext4", "list_id": "linux-ext4.vger.kernel.org", "list_email": "linux-ext4@vger.kernel.org", "web_url": null, "scm_url": null, "webscm_url": null, "list_archive_url": "", "list_archive_url_format": "", "commit_url_format": "" }, "msgid": "<20260317084624.457185-4-me@linux.beauty>", "list_archive_url": null, "date": "2026-03-17T08:46:18", "name": "[RFC,v5,3/7] ext4: fast commit: avoid waiting for FC_COMMITTING", "commit_ref": null, "pull_url": null, "state": "superseded", "archived": false, "hash": "549604a537ee06402d24f85a64b87d87f0c9ef17", "submitter": { "id": 84264, "url": "http://patchwork.ozlabs.org/api/1.2/people/84264/?format=api", "name": "Li Chen", "email": "me@linux.beauty" }, "delegate": null, "mbox": "http://patchwork.ozlabs.org/project/linux-ext4/patch/20260317084624.457185-4-me@linux.beauty/mbox/", "series": [ { "id": 496215, "url": "http://patchwork.ozlabs.org/api/1.2/series/496215/?format=api", "web_url": "http://patchwork.ozlabs.org/project/linux-ext4/list/?series=496215", "date": "2026-03-17T08:46:15", "name": "ext4: fast commit: snapshot inode state for FC log", "version": 5, "mbox": "http://patchwork.ozlabs.org/series/496215/mbox/" } ], "comments": "http://patchwork.ozlabs.org/api/patches/2211753/comments/", "check": "pending", "checks": "http://patchwork.ozlabs.org/api/patches/2211753/checks/", "tags": {}, "related": [], "headers": { "Return-Path": "\n <SRS0=6tr1=BR=vger.kernel.org=linux-ext4+bounces-15100-patchwork-incoming=ozlabs.org@ozlabs.org>", "X-Original-To": [ "incoming@patchwork.ozlabs.org", "linux-ext4@vger.kernel.org" ], "Delivered-To": [ "patchwork-incoming@legolas.ozlabs.org", "patchwork-incoming@ozlabs.org" ], "Authentication-Results": [ "legolas.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=linux.beauty header.i=me@linux.beauty\n header.a=rsa-sha256 header.s=zmail header.b=c6is9a4J;\n\tdkim-atps=neutral", "legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=ozlabs.org\n (client-ip=2404:9400:2221:ea00::3; helo=mail.ozlabs.org;\n envelope-from=srs0=6tr1=br=vger.kernel.org=linux-ext4+bounces-15100-patchwork-incoming=ozlabs.org@ozlabs.org;\n receiver=patchwork.ozlabs.org)", "gandalf.ozlabs.org;\n arc=pass smtp.remote-ip=\"2600:3c0a:e001:db::12fc:5321\"\n arc.chain=\"subspace.kernel.org:zohomail.com\"", "gandalf.ozlabs.org;\n dmarc=pass (p=none dis=none) header.from=linux.beauty", "gandalf.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=linux.beauty header.i=me@linux.beauty\n header.a=rsa-sha256 header.s=zmail header.b=c6is9a4J;\n\tdkim-atps=neutral", "gandalf.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c0a:e001:db::12fc:5321; helo=sea.lore.kernel.org;\n envelope-from=linux-ext4+bounces-15100-patchwork-incoming=ozlabs.org@vger.kernel.org;\n receiver=ozlabs.org)", "smtp.subspace.kernel.org;\n\tdkim=pass (1024-bit key) header.d=linux.beauty header.i=me@linux.beauty\n header.b=\"c6is9a4J\"", "smtp.subspace.kernel.org;\n arc=pass smtp.client-ip=136.143.188.15", "smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=linux.beauty", "smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=linux.beauty" ], "Received": [ "from mail.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1 raw public key)\n server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fZm1c4n6cz1y1P\n\tfor <incoming@patchwork.ozlabs.org>; Tue, 17 Mar 2026 19:52:36 +1100 (AEDT)", "from mail.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3])\n\tby gandalf.ozlabs.org (Postfix) with ESMTP id 4fZm1c45Mfz4w93\n\tfor <incoming@patchwork.ozlabs.org>; Tue, 17 Mar 2026 19:52:36 +1100 (AEDT)", "by gandalf.ozlabs.org (Postfix)\n\tid 4fZm1c416Bz4w9k; Tue, 17 Mar 2026 19:52:36 +1100 (AEDT)", "from sea.lore.kernel.org (sea.lore.kernel.org\n [IPv6:2600:3c0a:e001:db::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby gandalf.ozlabs.org (Postfix) with ESMTPS id 4fZm1Y0lK4z4w93\n\tfor <patchwork-incoming@ozlabs.org>; Tue, 17 Mar 2026 19:52:33 +1100 (AEDT)", "from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sea.lore.kernel.org (Postfix) with ESMTP id 6EE853084606\n\tfor <patchwork-incoming@ozlabs.org>; Tue, 17 Mar 2026 08:49:52 +0000 (UTC)", "from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id CAF3039D6E6;\n\tTue, 17 Mar 2026 08:49:51 +0000 (UTC)", "from sender4-op-o15.zoho.com (sender4-op-o15.zoho.com\n [136.143.188.15])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 1C59538E5FB;\n\tTue, 17 Mar 2026 08:49:49 +0000 (UTC)", "by mx.zohomail.com with SMTPS id 1773737208088894.5171387213331;\n\tTue, 17 Mar 2026 01:46:48 -0700 (PDT)" ], "ARC-Seal": [ "i=3; a=rsa-sha256; d=ozlabs.org; s=201707; t=1773737556; cv=pass;\n\tb=vmhcV0tjvp+9ZyxGGwzO2uaw8dm33dVOS5oRr/uhCdPaZg/kg5ik8WNELlw3Tb2lAtDcq7L4M1nDTGWYQsAUpPc87Hjzo6AYqYjgY959p9KIcfX+8bU0dGeX1A0aT9T/0VCdsB6b7i1e3JStjLKm1Se8Rmv8GaNOJiW1ijQVs8lMznHFIGF+4U2oD+g+ytOwPhOo7zzwFV8jYJcUs4lMjWi1XWGBmmtZhpeq/m0XryzKkvvOIrTn6rVjs7NpXpo9hASNwjw4EU+QDjLoqDs85WUdxGIzwT4dVLRaJ37rN78Fp0mgYp92ZMTn2g71nAUUlj1Ye76seVe7HZUZgZNdKA==", "i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1773737391; cv=pass;\n b=jdVFBx8WrLnWLydB/tDj1+B65pljkJMDd6ircaU25+SsWrhlgr69Zad4HDpDKxjjeADY31wK67S56emo2EtH9wAm2V10otVtbXZxg+sbpRRdYRHF7sg8/z9YaPe0a+aVpfuZvKcPVNZyTHRyWMKJlL6bKFjZ9SeE2ia18kdW0hk=", "i=1; a=rsa-sha256; t=1773737209; cv=none;\n\td=zohomail.com; s=zohoarc;\n\tb=WEIKXD/YrSSc+qTIYeqX7SIoFrR63L4eLEE7YQ6g5ph1Lw3MS6iAjC660F+haVV8oQQ02nxNSEtcU5Ut2vmWA+Ps67Drf/iDMDrCbL/EO4M/5s2CTUpnas7umH+issHNT7K+pEjcobJdIlLwUVL0tIoYBtr+7eeFvHRXlKZk/r0=" ], "ARC-Message-Signature": [ "i=3; a=rsa-sha256; d=ozlabs.org; s=201707;\n\tt=1773737556; c=relaxed/relaxed;\n\tbh=qv6DBDYs13J886EVaIT8yAfNm0oWJjrv2U9oQFtiPUw=;\n\th=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References:\n\t MIME-Version;\n b=ryRO2qvMCTLkKuxNRDVb4nCYO9QpDZ2OCZWbK83wiJdvdPjy3Eo2tsMZoWyjJ9wQG9TPr8eEmZy/tty1BiTFX/auWNJuAp+OxAuBoCQcUWCR7oBx2JZn0csBTkS/bphc7XJbmQ/ip0rLVnbmYPeI/euyq2iME/TxV0JCposFPUdsyhrph5FbGGuA0w5lg7E1H7aSXLkkB0T4yxRaQvTUZa1vJ1IPCFMMZlWBqVSK5/dfTCdhvH11CBuRwT1LimekYrWGwXIJBBHGyKIhEoedMM30RYQ5+KGbur+jzcW+DwV95JKz8LLUvKKvP71L//f55f1s+KYM1gQOzKOq3h2Omg==", "i=2; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1773737391; c=relaxed/simple;\n\tbh=0LFQzupkBR4VlUUJEDt/SKjIMv0DlWRAXdGj2rGHxCE=;\n\th=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References:\n\t MIME-Version;\n b=uclR3R3/KzdsH+bm7zN4a6A9sE06CrXb6txAgZ/6+p+rd0G0MYqnRhsspc/TIpCiqC8TUZPmZVi3iJDr5hzVqyaAO0/xlW9LfBaN00SbST298us3sYcDYLxgA+v/x5VVQHmbT6sb3iSCpyiIinxmJPGv4YayBtJ3StjRh8uNGQo=", "i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com;\n s=zohoarc;\n\tt=1773737209;\n h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To;\n\tbh=qv6DBDYs13J886EVaIT8yAfNm0oWJjrv2U9oQFtiPUw=;\n\tb=fz/gFHAHTObAjNsAqgE56aOr5S5yGBEQtxxpUaH7LXOr7JWVhDEwFDVcFVqwfSebsWue5HQOsqxgfUxpfCywSLLIsCXeHRLwg4kndUc9nYZ4EvO1IqNLuSOTCAaf3YyBVoZp84rAo+MbzscSoCG6H9bBJ/l7ILBvK4Bnz106KjQ=" ], "ARC-Authentication-Results": [ "i=3; gandalf.ozlabs.org;\n dmarc=pass (p=none dis=none) header.from=linux.beauty;\n dkim=pass (1024-bit key;\n unprotected) header.d=linux.beauty header.i=me@linux.beauty\n header.a=rsa-sha256 header.s=zmail header.b=c6is9a4J; dkim-atps=neutral;\n spf=pass (client-ip=2600:3c0a:e001:db::12fc:5321; helo=sea.lore.kernel.org;\n envelope-from=linux-ext4+bounces-15100-patchwork-incoming=ozlabs.org@vger.kernel.org;\n receiver=ozlabs.org) smtp.mailfrom=vger.kernel.org", "i=2; smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=linux.beauty;\n spf=pass smtp.mailfrom=linux.beauty;\n dkim=pass (1024-bit key) header.d=linux.beauty header.i=me@linux.beauty\n header.b=c6is9a4J; arc=pass smtp.client-ip=136.143.188.15", "i=1; mx.zohomail.com;\n\tdkim=pass header.i=linux.beauty;\n\tspf=pass smtp.mailfrom=me@linux.beauty;\n\tdmarc=pass header.from=<me@linux.beauty>" ], "DKIM-Signature": "v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1773737209;\n\ts=zmail; d=linux.beauty; i=me@linux.beauty;\n\th=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-ID:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Message-Id:Reply-To;\n\tbh=qv6DBDYs13J886EVaIT8yAfNm0oWJjrv2U9oQFtiPUw=;\n\tb=c6is9a4JnY0RhU7WkymDB0WyrYOLlwcmTrx0SUCtozbWICS7v4/5Et6JTsblQMLB\n\tmlVixT3MWQyM2/kyqAy546nmAj/o/EMFhn6RW1WoilrXBQ1kDXwcarriCVsn1n5ZlFP\n\t7cey+vojgiqDORpZxs4ContyT9DNt5dicXdwirfk=", "From": "Li Chen <me@linux.beauty>", "To": "Zhang Yi <yi.zhang@huaweicloud.com>,\n\tTheodore Ts'o <tytso@mit.edu>,\n\tAndreas Dilger <adilger.kernel@dilger.ca>,\n\tlinux-ext4@vger.kernel.org,\n\tlinux-kernel@vger.kernel.org", "Cc": "Steven Rostedt <rostedt@goodmis.org>,\n\tMasami Hiramatsu <mhiramat@kernel.org>,\n\tMathieu Desnoyers <mathieu.desnoyers@efficios.com>,\n\tlinux-trace-kernel@vger.kernel.org,\n\tLi Chen <me@linux.beauty>", "Subject": "[RFC v5 3/7] ext4: fast commit: avoid waiting for FC_COMMITTING", "Date": "Tue, 17 Mar 2026 16:46:18 +0800", "Message-ID": "<20260317084624.457185-4-me@linux.beauty>", "X-Mailer": "git-send-email 2.53.0", "In-Reply-To": "<20260317084624.457185-1-me@linux.beauty>", "References": "<20260317084624.457185-1-me@linux.beauty>", "Precedence": "bulk", "X-Mailing-List": "linux-ext4@vger.kernel.org", "List-Id": "<linux-ext4.vger.kernel.org>", "List-Subscribe": "<mailto:linux-ext4+subscribe@vger.kernel.org>", "List-Unsubscribe": "<mailto:linux-ext4+unsubscribe@vger.kernel.org>", "MIME-Version": "1.0", "Content-Transfer-Encoding": "8bit", "X-ZohoMailClient": "External", "X-Spam-Status": "No, score=-1.2 required=5.0 tests=ARC_SIGNED,ARC_VALID,\n\tDKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DMARC_PASS,\n\tHEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,\n\tSPF_PASS autolearn=disabled version=4.0.1", "X-Spam-Checker-Version": "SpamAssassin 4.0.1 (2024-03-25) on gandalf.ozlabs.org" }, "content": "ext4_fc_track_inode() can be called while holding i_data_sem (e.g.\nfallocate). Waiting for EXT4_STATE_FC_COMMITTING in that case risks an\nABBA deadlock: i_data_sem -> wait(FC_COMMITTING) vs FC_COMMITTING ->\nwait(i_data_sem) in the commit task.\n\nNow that fast commit snapshots inode state at commit time, updates during\nlog writing do not need to block. Drop the wait and lockdep assertion in\next4_fc_track_inode(), and make ext4_fc_del() wait for FC_COMMITTING so an\ninode cannot be removed while the commit thread is still using it.\n\nWhen an inode is modified during a fast commit, mark it with\nEXT4_STATE_FC_REQUEUE so cleanup keeps it queued for the next fast commit.\nThis is needed because jbd2_fc_end_commit() invokes the cleanup callback\nwith tid == 0, so tid-based requeue logic would requeue every inode.\n\nTesting: tracepoint ext4:ext4_fc_commit_stop with two fsyncs in the same\ntransaction. nblks is the number of journal blocks written for that fast\ncommit. Before this change, the second fsync still wrote almost the same\nfast commit log (nblks 10->9), because tid == 0 in jbd2_fc_end_commit()\ncaused the tid-based requeue logic to keep all inodes queued. After this\nchange, only inodes modified during the commit are requeued, and the\nsecond fsync wrote a nearly empty fast commit (nblks 10->1).\n\nSigned-off-by: Li Chen <me@linux.beauty>\n---\n fs/ext4/ext4.h | 1 +\n fs/ext4/fast_commit.c | 111 ++++++++++++++++++++----------------------\n 2 files changed, 53 insertions(+), 59 deletions(-)", "diff": "diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h\nindex 2e1681057196a..68a64fa0be926 100644\n--- a/fs/ext4/ext4.h\n+++ b/fs/ext4/ext4.h\n@@ -2004,6 +2004,7 @@ enum {\n \tEXT4_STATE_FC_COMMITTING,\t/* Fast commit ongoing */\n \tEXT4_STATE_FC_FLUSHING_DATA,\t/* Fast commit flushing data */\n \tEXT4_STATE_ORPHAN_FILE,\t\t/* Inode orphaned in orphan file */\n+\tEXT4_STATE_FC_REQUEUE,\t\t/* Inode modified during fast commit */\n };\n \n #define EXT4_INODE_BIT_FNS(name, field, offset)\t\t\t\t\\\ndiff --git a/fs/ext4/fast_commit.c b/fs/ext4/fast_commit.c\nindex d5c28304e8181..809170d46167b 100644\n--- a/fs/ext4/fast_commit.c\n+++ b/fs/ext4/fast_commit.c\n@@ -61,9 +61,8 @@\n * setting \"EXT4_STATE_FC_COMMITTING\" state, and snapshot the inode state\n * needed for log writing.\n * [5] Unlock the journal by calling jbd2_journal_unlock_updates(). This allows\n- * starting of new handles. If new handles try to start an update on\n- * any of the inodes that are being committed, ext4_fc_track_inode()\n- * will block until those inodes have finished the fast commit.\n+ * starting of new handles. Updates to inodes being fast committed are\n+ * tracked for requeue rather than blocking.\n * [6] Commit all the directory entry updates in the fast commit space.\n * [7] Commit all the changed inodes in the fast commit space.\n * [8] Write tail tag (this tag ensures the atomicity, please read the following\n@@ -217,6 +216,7 @@ void ext4_fc_init_inode(struct inode *inode)\n \n \text4_fc_reset_inode(inode);\n \text4_clear_inode_state(inode, EXT4_STATE_FC_COMMITTING);\n+\text4_clear_inode_state(inode, EXT4_STATE_FC_REQUEUE);\n \tINIT_LIST_HEAD(&ei->i_fc_list);\n \tINIT_LIST_HEAD(&ei->i_fc_dilist);\n \tei->i_fc_snap = NULL;\n@@ -251,22 +251,30 @@ void ext4_fc_del(struct inode *inode)\n \t}\n \n \t/*\n-\t * Since ext4_fc_del is called from ext4_evict_inode while having a\n-\t * handle open, there is no need for us to wait here even if a fast\n-\t * commit is going on. That is because, if this inode is being\n-\t * committed, ext4_mark_inode_dirty would have waited for inode commit\n-\t * operation to finish before we come here. So, by the time we come\n-\t * here, inode's EXT4_STATE_FC_COMMITTING would have been cleared. So,\n-\t * we shouldn't see EXT4_STATE_FC_COMMITTING to be set on this inode\n-\t * here.\n-\t *\n-\t * We may come here without any handles open in the \"no_delete\" case of\n-\t * ext4_evict_inode as well. However, if that happens, we first mark the\n-\t * file system as fast commit ineligible anyway. So, even in that case,\n-\t * it is okay to remove the inode from the fc list.\n+\t * Wait for ongoing fast commit to finish. We cannot remove the inode\n+\t * from fast commit lists while it is being committed.\n \t */\n-\tWARN_ON(ext4_test_inode_state(inode, EXT4_STATE_FC_COMMITTING)\n-\t\t&& !ext4_test_mount_flag(inode->i_sb, EXT4_MF_FC_INELIGIBLE));\n+\twhile (ext4_test_inode_state(inode, EXT4_STATE_FC_COMMITTING)) {\n+#if (BITS_PER_LONG < 64)\n+\t\tDEFINE_WAIT_BIT(wait, &ei->i_state_flags,\n+\t\t\t\tEXT4_STATE_FC_COMMITTING);\n+\t\twq = bit_waitqueue(&ei->i_state_flags,\n+\t\t\t\t EXT4_STATE_FC_COMMITTING);\n+#else\n+\t\tDEFINE_WAIT_BIT(wait, &ei->i_flags,\n+\t\t\t\tEXT4_STATE_FC_COMMITTING);\n+\t\twq = bit_waitqueue(&ei->i_flags,\n+\t\t\t\t EXT4_STATE_FC_COMMITTING);\n+#endif\n+\t\tprepare_to_wait(wq, &wait.wq_entry, TASK_UNINTERRUPTIBLE);\n+\t\tif (ext4_test_inode_state(inode, EXT4_STATE_FC_COMMITTING)) {\n+\t\t\text4_fc_unlock(inode->i_sb, alloc_ctx);\n+\t\t\tschedule();\n+\t\t\talloc_ctx = ext4_fc_lock(inode->i_sb);\n+\t\t}\n+\t\tfinish_wait(wq, &wait.wq_entry);\n+\t}\n+\n \twhile (ext4_test_inode_state(inode, EXT4_STATE_FC_FLUSHING_DATA)) {\n #if (BITS_PER_LONG < 64)\n \t\tDEFINE_WAIT_BIT(wait, &ei->i_state_flags,\n@@ -287,19 +295,22 @@ void ext4_fc_del(struct inode *inode)\n \t\t}\n \t\tfinish_wait(wq, &wait.wq_entry);\n \t}\n+\n \text4_fc_free_inode_snap(inode);\n \tlist_del_init(&ei->i_fc_list);\n \n \t/*\n-\t * Since this inode is getting removed, let's also remove all FC\n-\t * dentry create references, since it is not needed to log it anyways.\n+\t * Since this inode is getting removed, let's also remove all FC dentry\n+\t * create references, since it is not needed to log it anyways.\n \t */\n \tif (list_empty(&ei->i_fc_dilist)) {\n \t\text4_fc_unlock(inode->i_sb, alloc_ctx);\n \t\treturn;\n \t}\n \n-\tfc_dentry = list_first_entry(&ei->i_fc_dilist, struct ext4_fc_dentry_update, fcd_dilist);\n+\tfc_dentry = list_first_entry(&ei->i_fc_dilist,\n+\t\t\t\t struct ext4_fc_dentry_update,\n+\t\t\t\t fcd_dilist);\n \tWARN_ON(fc_dentry->fcd_op != EXT4_FC_TAG_CREAT);\n \tlist_del_init(&fc_dentry->fcd_list);\n \tlist_del_init(&fc_dentry->fcd_dilist);\n@@ -371,6 +382,8 @@ static int ext4_fc_track_template(\n \n \ttid = handle->h_transaction->t_tid;\n \tspin_lock(&ei->i_fc_lock);\n+\tif (ext4_test_inode_state(inode, EXT4_STATE_FC_COMMITTING))\n+\t\text4_set_inode_state(inode, EXT4_STATE_FC_REQUEUE);\n \tif (tid == ei->i_sync_tid) {\n \t\tupdate = true;\n \t} else {\n@@ -557,8 +570,6 @@ static int __track_inode(handle_t *handle, struct inode *inode, void *arg,\n \n void ext4_fc_track_inode(handle_t *handle, struct inode *inode)\n {\n-\tstruct ext4_inode_info *ei = EXT4_I(inode);\n-\twait_queue_head_t *wq;\n \tint ret;\n \n \tif (S_ISDIR(inode->i_mode))\n@@ -577,29 +588,11 @@ void ext4_fc_track_inode(handle_t *handle, struct inode *inode)\n \t\treturn;\n \n \t/*\n-\t * If we come here, we may sleep while waiting for the inode to\n-\t * commit. We shouldn't be holding i_data_sem when we go to sleep since\n-\t * the commit path needs to grab the lock while committing the inode.\n+\t * Fast commit snapshots inode state at commit time, so there's no need\n+\t * to wait for EXT4_STATE_FC_COMMITTING here. If the inode is already\n+\t * on the commit queue, ext4_fc_cleanup() will requeue it for the new\n+\t * transaction once the current commit finishes.\n \t */\n-\tlockdep_assert_not_held(&ei->i_data_sem);\n-\n-\twhile (ext4_test_inode_state(inode, EXT4_STATE_FC_COMMITTING)) {\n-#if (BITS_PER_LONG < 64)\n-\t\tDEFINE_WAIT_BIT(wait, &ei->i_state_flags,\n-\t\t\t\tEXT4_STATE_FC_COMMITTING);\n-\t\twq = bit_waitqueue(&ei->i_state_flags,\n-\t\t\t\t EXT4_STATE_FC_COMMITTING);\n-#else\n-\t\tDEFINE_WAIT_BIT(wait, &ei->i_flags,\n-\t\t\t\tEXT4_STATE_FC_COMMITTING);\n-\t\twq = bit_waitqueue(&ei->i_flags,\n-\t\t\t\t EXT4_STATE_FC_COMMITTING);\n-#endif\n-\t\tprepare_to_wait(wq, &wait.wq_entry, TASK_UNINTERRUPTIBLE);\n-\t\tif (ext4_test_inode_state(inode, EXT4_STATE_FC_COMMITTING))\n-\t\t\tschedule();\n-\t\tfinish_wait(wq, &wait.wq_entry);\n-\t}\n \n \t/*\n \t * From this point on, this inode will not be committed either\n@@ -1525,32 +1518,32 @@ static void ext4_fc_cleanup(journal_t *journal, int full, tid_t tid)\n \n \talloc_ctx = ext4_fc_lock(sb);\n \twhile (!list_empty(&sbi->s_fc_q[FC_Q_MAIN])) {\n+\t\tbool requeue;\n+\n \t\tei = list_first_entry(&sbi->s_fc_q[FC_Q_MAIN],\n \t\t\t\t\tstruct ext4_inode_info,\n \t\t\t\t\ti_fc_list);\n \t\tlist_del_init(&ei->i_fc_list);\n \t\text4_fc_free_inode_snap(&ei->vfs_inode);\n+\t\tspin_lock(&ei->i_fc_lock);\n+\t\tif (full)\n+\t\t\trequeue = !tid_geq(tid, ei->i_sync_tid);\n+\t\telse\n+\t\t\trequeue = ext4_test_inode_state(&ei->vfs_inode,\n+\t\t\t\t\t\t\tEXT4_STATE_FC_REQUEUE);\n+\t\tif (!requeue)\n+\t\t\text4_fc_reset_inode(&ei->vfs_inode);\n+\t\text4_clear_inode_state(&ei->vfs_inode, EXT4_STATE_FC_REQUEUE);\n \t\text4_clear_inode_state(&ei->vfs_inode,\n \t\t\t\t EXT4_STATE_FC_COMMITTING);\n-\t\tif (tid_geq(tid, ei->i_sync_tid)) {\n-\t\t\text4_fc_reset_inode(&ei->vfs_inode);\n-\t\t} else if (full) {\n-\t\t\t/*\n-\t\t\t * We are called after a full commit, inode has been\n-\t\t\t * modified while the commit was running. Re-enqueue\n-\t\t\t * the inode into STAGING, which will then be splice\n-\t\t\t * back into MAIN. This cannot happen during\n-\t\t\t * fastcommit because the journal is locked all the\n-\t\t\t * time in that case (and tid doesn't increase so\n-\t\t\t * tid check above isn't reliable).\n-\t\t\t */\n+\t\tspin_unlock(&ei->i_fc_lock);\n+\t\tif (requeue)\n \t\t\tlist_add_tail(&ei->i_fc_list,\n \t\t\t\t &sbi->s_fc_q[FC_Q_STAGING]);\n-\t\t}\n \t\t/*\n \t\t * Make sure clearing of EXT4_STATE_FC_COMMITTING is\n \t\t * visible before we send the wakeup. Pairs with implicit\n-\t\t * barrier in prepare_to_wait() in ext4_fc_track_inode().\n+\t\t * barrier in prepare_to_wait() in ext4_fc_del().\n \t\t */\n \t\tsmp_mb();\n #if (BITS_PER_LONG < 64)\n", "prefixes": [ "RFC", "v5", "3/7" ] }