linux-ext4 - Re: [PATCH] ext4: attempt to shrink directory on dentry removal

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]

Date:   Mon, 26 Aug 2019 22:27:57 -0400
From:   "Theodore Y. Ts'o" <tytso@....edu>
To:     Andreas Dilger <adilger@...ger.ca>
Cc:     Harshad Shirwadkar <harshadshirwadkar@...il.com>,
        linux-ext4@...r.kernel.org
Subject: Re: [PATCH] ext4: attempt to shrink directory on dentry removal

On Sun, Aug 25, 2019 at 11:07:46PM -0600, Andreas Dilger wrote:
> This may not always detect empty directory blocks properly, because
> ext4_generic_delete_entry() will only merge deleted entries with the
> previous entry.  It at least appears possible that if entries are not
> deleted in the proper order (e.g. in reverse of the order they are
> listed in the directory) there may be multiple empty entries in a block,
> and the above check will fail.

I don't think that's a problem.  We always merge with the previous
entry, whether it's an empty/deleted entry or an in-use entry.  So
long as all implementations do this, it works just fine.  If there is
an ext2/3/4 implementation which deletes the entry by simply clearing
the inode number *without* merging with the previous one, it's
possible that we might get confused.

But that's easily fixed, too.  In ext4_generic_delete_entry(), we just
need to add a check so that we check to see if the subsequent entry
(if it exists) has a zero de->inode value.  If so, then we absorb the
current directory entry to include the deleted subsequent entry and
repeat the check.

						- Ted