linux-ext4 - Re: [PATCH 2/2] resize2fs: fix overhead calculation for meta

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:	Wed, 5 Sep 2012 00:55:48 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Yongqiang Yang <xiaoqiangnk@...il.com>
Cc:	Anssi Hannula <anssi.hannula@....fi>,
	Kevin Liao <kevinlia@...il.com>,
	Ext4 Developers List <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH 2/2] resize2fs: fix overhead calculation for meta_bg file
 systems

On Wed, Sep 05, 2012 at 10:10:29AM +0800, Yongqiang Yang wrote:
> Hi Anssi,
> 
> The bug was fixed for a while, please check the patches:
> [PATCH 1/2] ext4: teach resize report old blocks count correctly
> [PATCH 2/2] ext4: ignore last group without enough space when resizing
> 
> Please have a try!!!

Yongqiang,

In the future, if a patch is going to fix a BUG_ON or kernel crash,
please state so explicitly in the commit description along with
instructions about how to reproduce the problem.  The urgency of a
patch which (for example) fixes a debugging printk (such as your 1/2
patch above) is quite different from a patch which causes a kernel
BUG_ON.

One of the reasons why I hadn't gotten around to processing your
patches until now was partially because I knew there was a lot of
testing and fixing before the patches were fully baked (as soon as I
started doing testing I found all sorts of other problems, which I had
to fix), but also because the commit descriptions were not clear
enough.

Patches where it's obvious what they fix, and where there is a clear
explanation about what they fix and the priority of their fix makes
life easier for me, and makes it more likely that I can process the
patches quickly.

Also, if you have a follow-on set of patches which is dependent on the
initila set of patches, it's very helpful to resend a v2 version of
the patches so that it's clear how the patches fit together.

I'll take care of these two extra patches, and then you'll see me send
out a -v2 set of the patches which contain all of the online resize
patches rebased to the latest kernel and tested as much as possible.
In general, though, in order for me to scale, I really need ext4
developers to do as much of this testing, rebasing, and reposting
patches as possible, and for other ext4 developers to review the
patches.  If I have to do all of this myself, patches will flow into
mainline more slowly, and we'll start accumulating a much longer
backlog.

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