linux-kernel - Re: Large amount of scsi-sgpool objects

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:	Tue, 03 Mar 2009 22:39:50 +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
Subject: Re: Large amount of scsi-sgpool objects

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 and apply them without any quality
control (like code inspections, or even understanding how the patches
work) you've created a suspect and quality compromised tree.   This is
fine for your own work and others to test and report back (although the
list will start to see your bug reports as correspondingly lower quality
if you have a high proportion of self induced failures like this one).

However, if you base a feature tree off this compromised tree, now
you're causing extra work for other maintainers who see problems
reported with this tree, and have to take the time to investigate what's
going on.

Worse, supposing there is a genuine SCSI bug exposed by the -rt tree
(say something timing or interrupt related).  So I ask the reporter to
retry with the regular kernel tree and the bug goes away. Now everyone
will think "Oh, it's just because of some SCSI crap Ingo put in his
tree".  Result: the bug goes undiagnosed until it bites several people
in the field, which is an avoidable result.

The executive summary is that your "it works for me, so I'm putting it
in my tree" attitude is damaging our quality process.

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/