linux-kernel - Re: [PATCH 0/21] MSI rework

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: <m1ps705ka1.fsf@ebiederm.dsl.xmission.com>
Date:	Fri, 23 Mar 2007 04:25:26 -0600
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	michael@...erman.id.au
Cc:	Greg KH <greg@...ah.com>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	linux-pci@...ey.karlin.mff.cuni.cz,
	"David S. Miller" <davem@...emloft.net>,
	linux-kernel@...r.kernel.org, Andrew Morton <akpm@...l.org>,
	daniel.e.wolstenholme@...el.com
Subject: Re: [PATCH 0/21] MSI rework

Michael Ellerman <michael@...erman.id.au> writes:

> On Thu, 2007-03-22 at 15:08 -0700, Greg KH wrote:
>> On Fri, Mar 23, 2007 at 09:02:16AM +1100, Benjamin Herrenschmidt wrote:
>> > > > i.e.  First the simple bug fixes that should purely be restructure of
>> > > > msi.c with no affect on anything outside of it.
>> > > > 
>> > > > And then get into the architecture enhancements.
>> > > 
>> > > I agree, care to break these down into a smaller series of patches that
>> > > can go into -mm for testing?
>> > 
>> > I don't see the point in breaking the serie... you can bisect half way
>> > through if necessary... it's made of small patches that are done, afaik,
>> > in such a way that the whole thing should still work at any level in the
>> > serie.
>> > 
>> > The serie just expresses the dependency between them.
>> 
>> Ok, then which patches in the series should be acceptable to take right
>> now for 2.6.22?  The "clean up the BUG" ones?
>
> The series is already very verbose, I don't think I can split most of
> them any smaller without producing an unbuildable kernel.

That wasn't the request.

> I think 1 up to and including 11 are safe as houses, they shouldn't have
> any effect other than to clean up the code.
>
> The rest make functional changes, but they're all quite small, self
> contained, and easily bisectable. I'd certainly like Eric to have a look
> at them, but at some point I think we're just going to have to bite the
> bullet and merge them, and see what we get in the way of bug reports.

What I wanted was the patches organized into functional groups that
were small enough to review as a unit.  (Feed the existing patches slower
please).

This seems to be to much change to read and review as a unit, I just get
bleary eyed, and start to get confused.

So far I have found one subtle bug.  Where admittedly my code wasn't as
obvious as it could be and you were proposing to use an irq that had already
been freed.

What I had hoped we can do is you would send a handful at a time I
would review them.  Then we could get the next handful.  I expect
doing it that way it should take about a week to get through them all.

I guess I can try going through the review that way as well.  Pick a
subset of what you have sent and review it very carefully, and the
next day pick a different subset.  

I have been sufficiently active in this code lately that I think I can
do a good review, and I want to.  Unfortunately I'm only human and
a good review is nearly as much work as writing the patches myself
which means it takes time.

Eric
-
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/