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:   Wed, 30 Aug 2017 01:43:30 -0600
From:   Andreas Dilger <adilger@...ger.ca>
To:     Theodore Ts'o <tytso@....edu>
Cc:     linux-ext4@...r.kernel.org
Subject: Re: e2fsck: set dir_nlink feature if large dir exists


> On Aug 29, 2017, at 8:20 PM, Theodore Ts'o <tytso@....edu> wrote:
> 
> On Fri, Aug 18, 2017 at 12:19:42PM -0600, Andreas Dilger wrote:
>> If there is a directory with more than EXT2_LINK_MAX (65000)
>> subdirectories, but the DIR_NLINK feature is not set in the
>> superblock, the feature should be set before continuing on
>> to change the on-disk directory link count to 1.
>> 
>> While most filesystems should have DIR_NLINK set (it was set
>> by default for all ext4 filesystems, and the kernel before
>> 4.12 automatically set it if the directory link count grew
>> too large), it is possible that this flag is lost due to disk
>> corruption or for an upgraded filesystem.  We no longer want
>> the kernel to automatically enable this feature.
>> 
>> Addresses: https://bugzilla.kernel.org/show_bug.cgi?id=196405
>> Signed-off-by: Andreas Dilger <adilger@...ger.ca>
> 
> The f_large_dir test is now failing after I apply this patch:
> 
> debugfs 1.43.6 (29-Aug-2017)
> ./test_one: 38: /usr/projects/e2fsprogs/e2fsprogs/tests/f_large_dir/script: arithmetic expression: division by zero: "i / ELAPSED"
> f_large_dir: optimize 3 level htree directories: failed

You must have a faster test system than I do...

I can send an updated patch with a fix for this, as well as the
improvement for expand_dir as previously discussed.

On a related note, I was trying to implement the optimization for
more efficient ext2fs_link() insertion, but this has proven to be
much more complex than I expected.  I was thinking I would just
call the link_proc() function directly to handle insertion of the
new name, using block number of the previous caller.  However, this
function depends on the directory leaf buffers having been read
from disk, and being passed a dirent pointer to the free space after
being called through a series of callback indirections.

I thought it would be a bit cleaner to call ext2fs_process_dir_block()
(despite the warning that this function is for internal use only)
with the previously saved block numbers, but that also depends on
the dir_context state being initialzed, which didn't seem very clean.

Am I doing down the wrong road here?

Cheers, Andreas






Download attachment "signature.asc" of type "application/pgp-signature" (196 bytes)

Powered by blists - more mailing lists