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
| ||
|
Message-ID: <20130308131841.GD18986@gmail.com> Date: Fri, 8 Mar 2013 21:18:41 +0800 From: Zheng Liu <gnehzuil.liu@...il.com> To: Dmitry Monakhov <dmonakhov@...nvz.org> Cc: linux-ext4@...r.kernel.org, Zheng Liu <wenqing.lz@...bao.com>, Theodore Ts'o <tytso@....edu> Subject: Re: [PATCH v2 0/5] ext4: try to fix up es regressions On Thu, Mar 07, 2013 at 08:08:47PM +0400, Dmitry Monakhov wrote: > On Wed, 6 Mar 2013 22:17:10 +0800, Zheng Liu <gnehzuil.liu@...il.com> wrote: > > 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. :-( > Good work. All my tests now succeed (no error, no warning, no bugons), Great! Thanks for your confirmation. > BUT 301'th (in terms of git://oss.sgi.com/xfs/cmds/xfstests.git) > result in massive memory leakage > about 8gb in an hour > #while true; do ./check 301 ;done > I suspect that 'struct ext4_ext_path' is leaked somewhere, I'm not > even sure that it is new one. Thanks for the reminder. Maybe there still has some bugs in extent tree. I will look at it. Regards, - Zheng -- 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