linux-ext4 - Query regarding fast_commit replay of inode

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 21 Feb 2022 13:29:38 +0530
From:   Ritesh Harjani <riteshh@...ux.ibm.com>
To:     Harshad Shirwadkar <harshadshirwadkar@...il.com>,
        "Theodore Ts'o" <tytso@....edu>
Cc:     linux-ext4 <linux-ext4@...r.kernel.org>, Jan Kara <jack@...e.cz>
Subject: Query regarding fast_commit replay of inode

Hello Ted/Harshad,

I think we did discuss this once before, but I am unable to recollect the exact
reasoning for this. So question is - why do we have to call ext4_ext_clear_bb()
from ext4_fc_replay_inode()?

I was just thinking if this is suboptimal and if it can be optimized. But before
working on that problem, I wanted to again understand the right reasoning behind
choosing this approach in the first place.

Could you please help with this again?

ext4_fc_replay_inode()
<..>
	inode = ext4_iget(sb, ino, EXT4_IGET_NORMAL);
	if (!IS_ERR(inode)) {
		ext4_ext_clear_bb(inode);
		iput(inode);
	}
<..>

I will document it this time, so that I don't have to keep coming to this
everytime I look into fc replay code.

Thanks again for your help!!
-ritesh