linux-ext4 - Re: [PATCH 3/5] ext4: Speedup ext4 orphan inode handling

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YRaPNaukNFEObAvJ@mit.edu>
Date:   Fri, 13 Aug 2021 11:26:45 -0400
From:   "Theodore Ts'o" <tytso@....edu>
To:     Jan Kara <jack@...e.cz>
Cc:     linux-ext4@...r.kernel.org
Subject: Re: [PATCH 3/5] ext4: Speedup ext4 orphan inode handling

On Fri, Aug 13, 2021 at 02:34:34PM +0200, Jan Kara wrote:
> Actually, in the orphan list code, we leave the inode in the on-disk list
> but remove it from the in-memory list - see how
> list_del_init(&ei->i_orphan) is called very early in ext4_orphan_del(). The
> reason for this unconditional deletion is that if we do not remove the
> inode from the in-memory orphan list, the filesystem will complain and
> corrupt memory on unmount.
> 
> Also note that leaving inode in the on-disk orphan list actually does no
> serious harm. Because the orphan cleanup code just checks i_nlink and
> i_disksize and truncates inode down to current i_disksize and removes inode
> completely if i_nlink is 0. So even if an inode on the orphan list gets
> reused, orphan cleanup will just do nothing for it. So the worst problem
> that will likely happen is that on-disk orphan linked list becomes
> corrupted but there's no data loss AFAICT.
> 
> Is it clearer now or am I missing something?

Yes, you're right, I misread the code.  Thanks for clarifying.

Can you send the final spin of this patch set?  I think we're all set
for this patch series.

Reviewed-by: Theodore Ts'o <tytso@....edu>

						- Ted