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: <1174892991.4782.11.camel@concordia.ozlabs.ibm.com>
Date:	Mon, 26 Mar 2007 17:09:51 +1000
From:	Michael Ellerman <michael@...erman.id.au>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
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

On Fri, 2007-03-23 at 04:25 -0600, Eric W. Biederman wrote:
> 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.  

OK. For starters, do you want to review the first eleven as I've sent
them already, that saves spamming everyone again.

If you're OK with those eleven, then I'll send the remaining 10 or so
later in the week, broken up into (sort-of) functional groups.

cheers

-- 
Michael Ellerman
OzLabs, IBM Australia Development Lab

wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person

Download attachment "signature.asc" of type "application/pgp-signature" (190 bytes)