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:	Wed, 4 Mar 2009 21:09:41 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Andrew Morton <akpm@...ux-foundation.org>
cc:	Ingo Molnar <mingo@...e.hu>, stefanr@...6.in-berlin.de,
	efault@....de, James.Bottomley@...senPartnership.com,
	jengelh@...ozas.de, bharrosh@...asas.com,
	linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-rt-users@...r.kernel.org
Subject: Re: Large amount of scsi-sgpool objects

On Wed, 4 Mar 2009, Andrew Morton wrote:
> On Wed, 4 Mar 2009 12:24:55 +0100
> Ingo Molnar <mingo@...e.hu> wrote:
> 
> > FYI, we still have not tracked down the SCSI bug. Latest 
> > tip:master is able to boot and work on the affected systems, 
> > while the upstream kernel does not even boot because the fix (or 
> > the revert, should the fix be deemed unwanted) is stuck in the 
> > SCSI tree.
> 
> <wakes up>
> 
> There are fixes in the scsi tree?
> 
> Does the scsi tree fix all the regressions which you guys are seeing?
> 
> I must say that it seems to be awfully late in the cycle to have this
> amount of breakage remaining in mainline when we know exactly which
> patches need to be reverted to unbreak things.

We are looking at two breakages:

1) the hang which is observed on AIC7xxx, which is identified (Ingo
tracked it down to a bunch of commits). There is a tentative fix right
now, which needs more testing and the ack of James. James has some
objections which stalled the fix, but I did not come around to dig
into this yet as I'm busy with #2.

2) a crash caused by blk_rq_map_sg() using more sg entries than the
code which setup the request estimated. That one is dangerous, it
already trashed a complete filesystem. I'm in the process of providing
the necessary debug data, as I found a way to reproduce the problem
halfsways.

Thanks,

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