Message-Id: <1236124861.24019.78.camel@localhost.localdomain>
Date:	Wed, 04 Mar 2009 00:01:01 +0000
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Jan Engelhardt <jengelh@...ozas.de>,
	Boaz Harrosh <bharrosh@...asas.com>,
	linux-scsi@...r.kernel.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-rt-users@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: Large amount of scsi-sgpool objects

On Wed, 2009-03-04 at 00:03 +0100, Ingo Molnar wrote:
> * James Bottomley <James.Bottomley@...senPartnership.com> wrote:
> 
> > On Tue, 2009-03-03 at 22:44 +0100, Ingo Molnar wrote:
> > > * James Bottomley <James.Bottomley@...senPartnership.com> wrote:
> > > > > > So the real question is why does the -rt tree even have 
> > > > > > patches not in the vanilla SCSI tree?  This type of cockup 
> > > > > > clearly demonstrates why it's a bad idea.
> > > > > 
> > > > > Believe me, i have better things to do than to track down your 
> > > > > regressions. I applied a fix/test patch sent to me by SCSI 
> > > > > folks.
> > > > 
> > > > Look, I've no problem with you collecting random patches.  I 
> > > > have a problem when you start pushing random SCSI patches into 
> > > > other trees. [...]
> > > 
> > > Both -tip and -rt are generic trees and there's a connection 
> > > between them that the maintainers of both are one and the same 
> > > set of people.
> > > 
> > > So i'm not sure on what grounds you purport to be able to 
> > > prevent fixes from flowing from -tip into -rt and vice versa.
> > > 
> > > You have no monopoly on the propagation and testing of SCSI 
> > > fixes. We picked up a v1 patch from the SCSI list and did not 
> > > add nor remove anything from it.
> > 
> > OK, let me try and make the problem simpler for you:  If you pick up
> > random patches outside of your area [...]
> 
> Dude, lets make it clear to you: it is not "your area" that you 
> own in any way and you have no monopoly on SCSI fixes.

The fact that I can spot a missing release buffers and you, apparently,
can't does lend credence to a claim of greater expertise in the SCSI
area.

>  We acted 
> out of necessity because the SCSI tree is taking very long to 
> get fixes upstream.

To get upstream, there first has to be a fix.  I've already explained
why I don't think the patch in question is a fix.

> I reported this lockup bug to you on _January 15th_, more than 
> one and a half months ago - and it's still unfixed even today. 
> Alan sent his v2 fix on Feburary 19th - two weeks ago.

OK, so why don't you humour me and try applying the diagnostic patch I
sent you on the 24th of January?  I think there's a loop in I/O
completion caused by some type of timing race, and starved list handling
is the prime candidate.

>  We are 
> not asking you for much, is it really that hard to act like a 
> proper maintainer and get critical fixes upstream in a timely 
> manner?

You're asking me to ignore root cause analysis and push patches as "bug
fixes" just because they hide the problem on your machine.

> Again, i repeat, i picked up a v1 patch from the SCSI list that 
> i reported and which patch was sent to me. I did that in the 
> hope to fix a serious lockup bug that is still unfixed in the 
> upstream kernel here and today. That kind of bug can cause data 
> corruption and is serious and you should have given full, high 
> priority attention to it - but you didnt.
> 
> A v2 patch was sent too but i missed it because it had the exact 
> same subject line and no 'v2' in its title.
> 
> I did not do this out of fun - i did it to address a serious 
> regression that was unfixed upstream.
> 
> If there's a failure here it's yours: your latency and 
> unreliability in SCSI bug fixing is forcing generic trees like 
> -tip or -rt (or -mm) to carry SCSI fixes while it should be 
> _your_ responsibility to act quickly to bugreports and get 
> critical fixes upstream as soon as possible.

Well, you not responding to requests for information for three weeks
(before deciding the it was unnecessary to provide it) may have helped
elongate the time scale ...

However, I'm not really interested in recriminations.  Since you already
know better than me what the bug is, simply explain here what the patch
actually fixes and it can go upstream with my blessing and whatever ego
boosting praise you require.

James


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

Powered by blists - more mailing lists