linux-ext4 - ext34_free

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 for Android: free password hash cracker in your pocket

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

Date:	Wed, 14 Apr 2010 15:19:47 +0400
From:	Dmitry Monakhov <dmonakhov@...nvz.org>
To:	ext4 development <linux-ext4@...r.kernel.org>
Cc:	Jan Kara <jack@...e.cz>
Subject: ext34_free_inode's mess

I've finally automated my favorite testcase (see attachment), 
before i've run it by hand.
And sometimes i've saw following complain from fsck:
fsck.ext4 -f -n /dev/sdb2
...
Pass 5: Checking group summary information
Inode bitmap differences:  -93582
Fix? no

Free inodes count wrong for group #12 (4634, counted=4633).
Fix? no

Free inodes count wrong (35610, counted=35609).
Fix? no
...

I've started to look an inode bitmap manipulation code paths
and found strange logic in ext{3,4}_free_inode functions

1) Group lock acquired twice for bitmap and for group_desc.
   There are not any advantage from this double locking, only
   error path(where the bit is already cleared) takes an
   advantage from this locking schema.
   It is reasonable to batch it in to one locking block.
2) if we failed to read gdp then bh2 is undefined so
   may result in oops due to undefince pointer dereferance.
3) if we failed to get write_access to gdp we skip
   handle_dirty_metadata for inode_bitmap which is also a bug.

I've redesigned free_inode logic(see later two emails) and
currently i'm not able to reproduce the bug, but i can not
guarantee it is goes away.

View attachment "0001-xfstests-dev-add-one-more-stress-test.patch" of type "text/plain" (4376 bytes)