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

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

Date:	Sun, 4 Apr 2010 14:08:45 -0400
From:	tytso@....edu
To:	jing zhang <zj.barak@...il.com>
Cc:	"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 Sun, Apr 04, 2010 at 09:05:14AM +0800, jing zhang wrote:
> 
> Without the cool git, though I am learning how to take advantage of
> it, I could not manage all the patches delivered. In fact, I dig the
> patches with UltraEdit for modifying the C code, Cygwin for git and
> diff -Npu, and virtual machine for compiling. My kid, 11 years old
> boy, has to share the HP notebook with me playing games.

How much testing are you doing before submitting patches, out of
curiosity?

> I resolve conflicts and dependencies between patches in the way that
> they are carried out by independent guys, since I am told that git is
> cool enough. But indeed I created so many hard work for you, sorry.

Having independent patches is actually better --- but I think you're
misunderstanding what I was complaining about before.  Patches should
that are accepted into mainline should do one and only one thing.  So
if someone suggests that you make changes to your submitted patch,
ideally what you should do is to resubmit the patch with the fixes ---
and not submit a patch which is a delta to the previous one.

This is especially true if the original patch is buggy; one of the
things we try very hard to maintain is that the kernel tree compile
cleanly, and pass the regression test suite, between every single
commit.  In other words, we try to avoid knowingly introducing a
regression in a patch and fixing it in a subsequent patch.  This
allows things like "git bisect" to work, and it also makes it easier
for people to look at the commit history to understand why certain
changes were made, and especially when trying to find how a bug was
introduced into ext4.  Ultimately, this is about keeping the kernel
source code easily maintainable.  This means that incrased code
complexity has to be justified, and code and code changes have to be
meticulously documented.

Best regards,

					- Ted
--
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