linux-ext4 - [PATCH v2 0/5] ext4: try to fix up es regressions

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]

Message-Id: <1362579435-6333-1-git-send-email-wenqing.lz@taobao.com>
Date:	Wed,  6 Mar 2013 22:17:10 +0800
From:	Zheng Liu <gnehzuil.liu@...il.com>
To:	linux-ext4@...r.kernel.org
Cc:	Zheng Liu <wenqing.lz@...bao.com>, "Theodore Ts'o" <tytso@....edu>,
	Dmitry Monakhov <dmonakhov@...nvz.org>
Subject: [PATCH v2 0/5] ext4: try to fix up es regressions

Hi all,

The patch series tries to fixup some regressions after applied the extent
status tree.  These patches have rebased against the latest dev branch of
ext4 and have been tested by xfstests.

After rebased the latest dev branch, two patches have been dropped because
they have been applied into the branch.  A new patch is added, which tries
to fix up a wrong return value in ext4_split_extent().  Otherwise, there
are two major changes in this version.  The first one is to improve the
self-testing-infrastructure according to Dmitry's comment.  The second one
is to improve the zero out code.

After applied this patch series, I havn't seen the warning messages from
self-testing infrastructure except the following cases.

 - xfstests #13 with bigalloc or with no journal
 - xfstests #223 with dioread_nolock
The reason is that when we lookup a block mapping from status tree
i_data_sem locking won't be taken.  So there is a race window that an 
unwritten extent could be converted by end_io when we compare the result
between extent tree and status tree.

Dmitry, Ted, could you please confirm that this patch series can fix the
defrag regression?  Thank you so much.  Until now I run #300 and #301 a
lot times but I failed to hit this regression. :-(

*Big Note*
When I am testing this patch series, I found some regressions in dev branch.
Here is a note.  These regressions could be hitted by running test case
serveral times.  So If we just run xfstests one time, they could be missed.

 - xfstests #74 with data=journal
 - xfstests #83 with bigalloc
Some threads could be blocked for 120s.

 - xfstests #247 with data=journal
Some warning messages are printed by ext4_releasepage.  We hit
WARN_ON(PageChecked(page)) in this function.  But the test case itself can
pass.

 - xfstests #269 with dioread_nolock
The system will hang

I don't paste full details here to make description clearly.  I will go on
tracing these problems.  I am happy to provide full details if some one
want to take a close look at these problems.

v2 <- v1:
 * Improve self-testing infrastructure
 * Improve zero out code
 * Fix a wrong return value in ext4_split_extent

v1: http://permalink.gmane.org/gmane.comp.file-systems.ext4/37338

Thanks,
						- Zheng

Dmitry Monakhov (1):
  ext4: add self-testing infrastructure to do a sanity check

Zheng Liu (4):
  ext4: improve ext4_es_can_be_merged() to avoid a potential overflow
  ext4: fix wrong m_len value after unwritten extent conversion
  ext4: update extent status tree after an extent is zeroed out
  ext4: fix wrong the number of the allocted blocks in
    ext4_split_extent

 fs/ext4/extents.c        |  45 ++++++++--
 fs/ext4/extents_status.c | 212 +++++++++++++++++++++++++++++++++++++++++++++--
 fs/ext4/extents_status.h |   9 ++
 fs/ext4/inode.c          | 106 ++++++++++++++++++++++++
 4 files changed, 362 insertions(+), 10 deletions(-)

-- 
1.7.12.rc2.18.g61b472e

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html