linux-ext4 - Re: [PATCH] ext4: memory leakage in ext4_mb

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:	Mon, 5 Apr 2010 08:42:23 -0400
From:	tytso@....edu
To:	jing zhang <zj.barak@...il.com>
Cc:	Eric Sandeen <sandeen@...hat.com>,
	"Aneesh Kumar K. V" <aneesh.kumar@...ux.vnet.ibm.com>,
	linux-ext4 <linux-ext4@...r.kernel.org>,
	Andreas Dilger <adilger@....com>,
	Dave Kleikamp <shaggy@...ux.vnet.ibm.com>
Subject: Re: [PATCH] ext4: memory leakage in ext4_mb_init()

On Mon, Apr 05, 2010 at 01:08:58PM +0800, jing zhang wrote:
> 
> Before linux-2.6.32 is released, would you like tell me, how is ext4 tested?
> Is tough testing able to catch all bugs?

For one thing, we use the XFSQA (aka xfstests) test suite.  I usually
run the "quick" set of tests between each commit, and I run a much
longer "auto" test suite before submitting a set of patches to Linus.

For specific patches, we also like to be able to test it specifically.
So often we'll create a small filesystem image and then see what the
file system does with and without the patch.  For example, if we're
worried that a specific file system corruption will cause a BUG_ON,
we'll create a small file system, corrupt it using the debugfs tool,
and then demonstrate that without the patch, we get the BUG_ON.  With
the patch applied, the BUG_ON should go away.

So the patch-specific tests are there so we can make sure the patch
does what we think it should, and it fixes the problem it claims to
fix.  The XFSQA test suite is to there to make sure that we don't
accidentally introduce bugs while trying to improve the file system.

And of course, the final safeguard is patch review by others.  This is
where decent comments and making sure the code is maintainable is
critically important.  Since this takes other developer's time,
especially senior developers like Eric and myself's time, which is
rather valuable and hard to find, it's why patch submitters need
shoulder more of the work in terms of refining patches and
resubmitting new versions of the patches.

						- Ted

P.S.  Yes, Eric was absolutely correct.  I wanted to know how much
testing you had been doing on your patches before submitting them.  At
least few of your patches have caused me to wonder whether the patches
had gone through sufficient testing.
--
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