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  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]
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

Powered by blists - more mailing lists