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, 3 Mar 2009 22:44:54 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	James Bottomley <James.Bottomley@...senPartnership.com>
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


* James Bottomley <James.Bottomley@...senPartnership.com> wrote:

> On Tue, 2009-03-03 at 20:22 +0100, Ingo Molnar wrote:
> > * James Bottomley <James.Bottomley@...senPartnership.com> wrote:
> > 
> > > On Tue, 2009-03-03 at 17:08 +0100, Jan Engelhardt wrote:
> > > > On Tuesday 2009-03-03 16:21, James Bottomley wrote:
> > > > >> > $ slabtop
> > > > >> >   OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME                   
> > > > >> > 818616 818616 100%    0.16K  34109       24    136436K sgpool-8
> > > > >> > 253692 253692 100%    0.62K  42282        6    169128K sgpool-32
> > > > >> >  52017  52016  99%    2.50K  17339        3    138712K sgpool-128
> > > > >> >  26220  26219  99%    0.31K   2185       12      8740K sgpool-16
> > > > >> >   8927   8574  96%    0.03K     79      113       316K size-32
> > > > >> 
> > > > >> Looks like a leak, by failing to call scsi_release_buffers()
> > > > >> somehow. (Which was changed recently)
> > > > >
> > > > >Firstly, I have to say I don't see this in the mainline tree, so could
> > > > >you try that with your setup just to verify (git head at 2.6.29-rc6).
> > > > 
> > > > Yes, looking at the rt patch (in broken-out it's in origin.diff),
> > > > it seems a bit obvious - the scsi_release_buffers is not called anymore:
> > > 
> > > OK, this is a bad patch, so just revert it.  It was posted to 
> > > linux-scsi initially in this form before the author posted a 
> > > new one with the missing release buffers added.  It looks like 
> > > the first incarnation got pulled into the -rt tree for some 
> > > reasons.
> > 
> > Uhm. I applied a test-patch from Alan Stern, to possibly fix an 
> > SCSI lockup with aic7xxx that _I_ reported to you and then to 
> > the scsi-list.
> > 
> > You were Cc:-ed to that test patch and to my bugreport as well, 
> > all the way. Do you claim that you dont remember it?
> 
> ?  If I've just quoted the patch above why would I not remember it now.
> I've just said it's the cause of the problems in the -rt tree.
> 
> > The saga is still documented in tip:out-of-tree (which is a 
> > special branch with out-of-tree hotfixes):
> > 
> >  7e4cbd1: fix "scsi: aic7xxx hang since v2.6.28-rc1"
> >  e027abc: scsi: temporarily undo scsi reverts
> >  813104e: Revert "[SCSI] simplify scsi_io_completion()"
> >  84db545: Revert "[SCSI] Fix uninitialized variable error in scsi_io_completion"
> >  0eb6038: Revert "[SCSI] Fix error handling for DIF/DIX"
> >  3cd94dd: Revert "[SCSI] scsi_lib: don't decrement busy counters when inserting commands"
> >  c27aed5: Revert "[SCSI] scsi_lib: fix DID_RESET status problems"
> > 
> > I wasnt Cc:-ed on the updated patch AFAICS, so i didnt pick it 
> > up.
> 
> Actually, you were cc'd, you probably just missed it.

Correct, see my earlier reply to Alan Stern for the details of 
why it got missed.

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

Yes, v1 was buggy and I missed the v2 patch because it had the 
same subject line and no easily visible differentiator that it 
was a v2 patch.

In fact you should be happy that people are helping you out 
fixing your bugs. I never even thought of flaming anyone for 
having picked up a v1 scheduler fix and getting burned by it 
while a v2 existed. I find it unexplainable and irrational that 
you feel the need to do so for SCSI fixes.

	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/