linux-kernel - Re: [PATCH 3/3] blktrace: fix the original blktrace

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]

Message-ID: <20090326133732.GA14822@elte.hu>
Date:	Thu, 26 Mar 2009 14:37:32 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Jens Axboe <jens.axboe@...cle.com>
Cc:	Li Zefan <lizf@...fujitsu.com>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 3/3] blktrace: fix the original blktrace


* Jens Axboe <jens.axboe@...cle.com> wrote:

> > One is introduced by "block: get rid of the manual directory counting in blktrace"
> > (f48fc4d32e24c0b6a18aad30305d819bcc68c049). Two are "blktrace: port to tracepoints"
> > (5f3ea37c7716db4e894a480e0c18b24399595b6b). Both commits are in mainline.
> > 
> > Since 2 of the bugs will rarely happen in real-life, and the 3rd 
> > one is a small issue, and we were so close to the release of 
> > .29, so I sent the fixes for -tip tree but not mainline. But if 
> > we are going merge tip/blktrace to .31, I guess it's better to 
> > merge that 3 fixes to .30?
> 
> Since you are the person that worked on it most lately, your 
> opinion matters the most. What do you think, is it ready for 
> 2.6.30 or should it wait for .31?

Yeah. Li, Arnaldo, what do you think?

Delaying them would be quite painful at this stage though - the 
blktrace plugin conversion was done with (ahem) your initial support 
so the commits got (foolishly, in hindsight ;-) interwoven into 300 
commits of the 2.6.30 tracing tree.

Delaying them would also be technically baseless - there are no 
known regressions or bugs in this code. (If you know about bugs then 
please speak up so we can fix them! ;-)

At this last minute stage we can do two things: merge it now or if 
you NAK it then we'll rebase the last ~2 months of the tracing tree 
with hundreds of commits (sigh), destroy its true history in the 
process and eradicate the blktrace bits.

I'd like to avoid the second option if possible as it destroys real 
value (these changes are really nice improvements, a lot of work 
went into them and there's no open regressions so i can see no 
objective reason why they couldnt go upstream now) but it's your 
choice really, you maintain block/* :-)

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/