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

Powered by blists - more mailing lists