From: Baokun Li <libaokun1@huawei.com>
To: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
Cc: <linux-ext4@vger.kernel.org>, <tytso@mit.edu>, <jack@suse.cz>,
<harshads@google.com>, Baokun Li <libaokun1@huawei.com>,
Yang Erkun <yangerkun@huawei.com>
Subject: Re: [PATCH v7 9/9] ext4: hold s_fc_lock while during fast commit
Date: Mon, 13 Jan 2025 22:16:30 +0800 [thread overview]
Message-ID: <40b04c68-377b-4770-bff1-ecff8afa70e9@huawei.com> (raw)
In-Reply-To: <20240818040356.241684-11-harshadshirwadkar@gmail.com>
Hi Harshad,
On 2024/8/18 12:03, Harshad Shirwadkar wrote:
> Leaving s_fc_lock in between during commit in ext4_fc_perform_commit()
> function leaves room for subtle concurrency bugs where ext4_fc_del() may
> delete an inode from the fast commit list, leaving list in an inconsistent
> state. Also, this patch converts s_fc_lock to mutex type so that it can be
> held when kmem_cache_* functions are called.
>
> Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
> ---
> fs/ext4/ext4.h | 2 +-
> fs/ext4/fast_commit.c | 91 +++++++++++++++++--------------------------
> fs/ext4/super.c | 2 +-
> 3 files changed, 38 insertions(+), 57 deletions(-)
>
> diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
> index 4ecb63f95..a1acd34ff 100644
> --- a/fs/ext4/ext4.h
> +++ b/fs/ext4/ext4.h
> @@ -1748,7 +1748,7 @@ struct ext4_sb_info {
> * following fields:
> * ei->i_fc_list, s_fc_dentry_q, s_fc_q, s_fc_bytes, s_fc_bh.
> */
> - spinlock_t s_fc_lock;
> + struct mutex s_fc_lock;
> struct buffer_head *s_fc_bh;
> struct ext4_fc_stats s_fc_stats;
> tid_t s_fc_ineligible_tid;
> diff --git a/fs/ext4/fast_commit.c b/fs/ext4/fast_commit.c
> index 7525450f1..c3627efd9 100644
> --- a/fs/ext4/fast_commit.c
> +++ b/fs/ext4/fast_commit.c
> @@ -236,9 +236,9 @@ void ext4_fc_del(struct inode *inode)
> if (ext4_fc_disabled(inode->i_sb))
> return;
>
> - spin_lock(&EXT4_SB(inode->i_sb)->s_fc_lock);
> + mutex_lock(&EXT4_SB(inode->i_sb)->s_fc_lock);
> if (list_empty(&ei->i_fc_list) && list_empty(&ei->i_fc_dilist)) {
> - spin_unlock(&EXT4_SB(inode->i_sb)->s_fc_lock);
> + mutex_unlock(&EXT4_SB(inode->i_sb)->s_fc_lock);
> return;
> }
>
> @@ -266,7 +266,7 @@ void ext4_fc_del(struct inode *inode)
> * dentry create references, since it is not needed to log it anyways.
> */
> if (list_empty(&ei->i_fc_dilist)) {
> - spin_unlock(&sbi->s_fc_lock);
> + mutex_unlock(&sbi->s_fc_lock);
> return;
> }
>
> @@ -276,7 +276,7 @@ void ext4_fc_del(struct inode *inode)
> list_del_init(&fc_dentry->fcd_dilist);
>
> WARN_ON(!list_empty(&ei->i_fc_dilist));
> - spin_unlock(&sbi->s_fc_lock);
> + mutex_unlock(&sbi->s_fc_lock);
>
> if (fc_dentry->fcd_name.name &&
> fc_dentry->fcd_name.len > DNAME_INLINE_LEN)
> @@ -306,10 +306,10 @@ void ext4_fc_mark_ineligible(struct super_block *sb, int reason, handle_t *handl
> sbi->s_journal->j_running_transaction->t_tid : 0;
> read_unlock(&sbi->s_journal->j_state_lock);
> }
> - spin_lock(&sbi->s_fc_lock);
> + mutex_lock(&sbi->s_fc_lock);
> if (tid_gt(tid, sbi->s_fc_ineligible_tid))
> sbi->s_fc_ineligible_tid = tid;
> - spin_unlock(&sbi->s_fc_lock);
> + mutex_unlock(&sbi->s_fc_lock);
> WARN_ON(reason >= EXT4_FC_REASON_MAX);
> sbi->s_fc_stats.fc_ineligible_reason_count[reason]++;
> }
> @@ -349,14 +349,14 @@ static int ext4_fc_track_template(
> if (!enqueue)
> return ret;
>
> - spin_lock(&sbi->s_fc_lock);
> + mutex_lock(&sbi->s_fc_lock);
> if (list_empty(&EXT4_I(inode)->i_fc_list))
> list_add_tail(&EXT4_I(inode)->i_fc_list,
> (sbi->s_journal->j_flags & JBD2_FULL_COMMIT_ONGOING ||
> sbi->s_journal->j_flags & JBD2_FAST_COMMIT_ONGOING) ?
> &sbi->s_fc_q[FC_Q_STAGING] :
> &sbi->s_fc_q[FC_Q_MAIN]);
> - spin_unlock(&sbi->s_fc_lock);
> + mutex_unlock(&sbi->s_fc_lock);
>
> return ret;
> }
> @@ -414,7 +414,8 @@ static int __track_dentry_update(struct inode *inode, void *arg, bool update)
> }
> node->fcd_name.len = dentry->d_name.len;
> INIT_LIST_HEAD(&node->fcd_dilist);
> - spin_lock(&sbi->s_fc_lock);
> + INIT_LIST_HEAD(&node->fcd_list);
> + mutex_lock(&sbi->s_fc_lock);
> if (sbi->s_journal->j_flags & JBD2_FULL_COMMIT_ONGOING ||
> sbi->s_journal->j_flags & JBD2_FAST_COMMIT_ONGOING)
> list_add_tail(&node->fcd_list,
> @@ -435,7 +436,7 @@ static int __track_dentry_update(struct inode *inode, void *arg, bool update)
> WARN_ON(!list_empty(&ei->i_fc_dilist));
> list_add_tail(&node->fcd_dilist, &ei->i_fc_dilist);
> }
> - spin_unlock(&sbi->s_fc_lock);
> + mutex_unlock(&sbi->s_fc_lock);
> spin_lock(&ei->i_fc_lock);
>
> return 0;
> @@ -955,15 +956,15 @@ static int ext4_fc_submit_inode_data_all(journal_t *journal)
> struct ext4_inode_info *ei;
> int ret = 0;
>
> - spin_lock(&sbi->s_fc_lock);
> + mutex_lock(&sbi->s_fc_lock);
> list_for_each_entry(ei, &sbi->s_fc_q[FC_Q_MAIN], i_fc_list) {
> - spin_unlock(&sbi->s_fc_lock);
> + mutex_unlock(&sbi->s_fc_lock);
> ret = jbd2_submit_inode_data(journal, ei->jinode);
> if (ret)
> return ret;
> - spin_lock(&sbi->s_fc_lock);
> + mutex_lock(&sbi->s_fc_lock);
> }
> - spin_unlock(&sbi->s_fc_lock);
> + mutex_unlock(&sbi->s_fc_lock);
>
We're also seeing a similar race condition here. This issue was encountered
while running `kvm-xfstests -c ext4/adv -C 500 generic/241`:
P1 | P2
----------------------------------------------------
evict
ext4_evict_inode
ext4_free_inode
ext4_clear_inode
ext4_fc_del(inode)
ext4_sync_file
ext4_fsync_journal
ext4_fc_commit
ext4_fc_perform_commit
ext4_fc_submit_inode_data_all
-- spin_lock(&sbi->s_fc_lock);
list_for_each_entry(i_fc_list)
-- spin_unlock(&sbi->s_fc_lock);
-- spin_lock(&sbi->s_fc_lock)
if (!list_empty(&ei->i_fc_list))
list_del_init(&ei->i_fc_list);
-- spin_unlock(&sbi->s_fc_lock);
jbd2_free_inode(EXT4_I(inode)->jinode)
EXT4_I(inode)->jinode = NULL
jbd2_submit_inode_data
journal->j_submit_inode_data_buffers
ext4_journal_submit_inode_data_buffers
ext4_should_journal_data(jinode->i_vfs_inode)
// a. jinode may use-after-free !!!
ext4_inode_journal_mode(inode)
EXT4_JOURNAL(inode)
(inode)->i_sb
// b. inode may null-ptr-deref !!!
-- spin_lock(&sbi->s_fc_lock);
-- spin_unlock(&sbi->s_fc_lock);
By the way, the WARN_ON added in patch 5 can detect this issue without
enabling KASAN, but patch 5 also introduced softlocks and other UAFs.
Regards,
Baokun
next prev parent reply other threads:[~2025-01-13 14:16 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-18 4:03 [PATCH] ext4: convert i_fc_lock to spinlock Harshad Shirwadkar
2024-08-18 4:03 ` [PATCH v7 0/9] Ext4 Fast Commit Performance Patchset Harshad Shirwadkar
2024-08-18 4:49 ` harshad shirwadkar
2024-08-18 4:03 ` [PATCH v7 1/9] ext4: convert i_fc_lock to spinlock Harshad Shirwadkar
2024-08-18 4:03 ` [PATCH v7 2/9] ext4: for committing inode, make ext4_fc_track_inode wait Harshad Shirwadkar
2024-12-12 22:00 ` Jan Kara
2024-12-13 15:10 ` Jan Kara
2025-04-14 16:57 ` harshad shirwadkar
2024-08-18 4:03 ` [PATCH v7 3/9] ext4: mark inode dirty before grabbing i_data_sem in ext4_setattr Harshad Shirwadkar
2024-12-12 21:57 ` Jan Kara
2024-08-18 4:03 ` [PATCH v7 4/9] ext4: rework fast commit commit path Harshad Shirwadkar
2024-12-13 15:12 ` Jan Kara
2024-08-18 4:03 ` [PATCH v7 5/9] ext4: drop i_fc_updates from inode fc info Harshad Shirwadkar
2024-08-18 4:03 ` [PATCH v7 6/9] ext4: update code documentation Harshad Shirwadkar
2024-12-13 15:15 ` Jan Kara
2024-08-18 4:03 ` [PATCH v7 7/9] ext4: temporarily elevate commit thread priority Harshad Shirwadkar
2024-08-18 4:03 ` [PATCH v7 8/9] ext4: make fast commit ineligible on ext4_reserve_inode_write failure Harshad Shirwadkar
2024-12-16 10:40 ` Jan Kara
2024-08-18 4:03 ` [PATCH v7 9/9] ext4: hold s_fc_lock while during fast commit Harshad Shirwadkar
2024-12-16 10:50 ` Jan Kara
2025-01-13 14:16 ` Baokun Li [this message]
2025-04-14 16:59 ` harshad shirwadkar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=40b04c68-377b-4770-bff1-ecff8afa70e9@huawei.com \
--to=libaokun1@huawei.com \
--cc=harshads@google.com \
--cc=harshadshirwadkar@gmail.com \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
--cc=yangerkun@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox