linux-kernel - Re: [patch] scsi: revert "[SCSI] Get rid of scsi

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: <alpine.LFD.1.00.0801021245460.32517@woody.linux-foundation.org>
Date:	Wed, 2 Jan 2008 12:49:32 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Christoph Hellwig <hch@...radead.org>
cc:	Matthew Wilcox <matthew@....cx>,
	James Bottomley <James.Bottomley@...senPartnership.com>,
	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [patch] scsi: revert "[SCSI] Get rid of scsi_cmnd->done"

On Wed, 2 Jan 2008, Christoph Hellwig wrote:
> 
> I think you misunderstood Matthew here.  REQ_TYPE_BLOCK_PC is indeed
> used by any kind of SG_IO or similar passthrough no matter where it
> originates.  And exactly because REQ_TYPE_BLOCK_PC are entirely passthru
> the actual driver (sd, sr or sg) is not doing the actual command
> completion but it's handled in the scsi layer because it's exactly
> the same no matter what driver it came on.

You say that, but you then ignore that something *did* change.

Maybe it's not that one suspicious test. Maybe it's somethign else. But 
that commit was confirmed to break something, almost two months ago. You 
guys seem to be in denial, and saying "it didn't change anything".

And no, waiting for more reporters when one reporter has already narrowed 
it down to the exact (smallish) commit, is simply not good. Either you can 
fix it by looking at the source, or it gets reverted.

I was hoping somebody in SCSI-land would actually look at the commit and 
try to find out what's wrong, instead of all of you apparently trying to 
say "nothing is wrong".

I hate the excuses of "but, but, but.. it *should* work". It doesn't. Face 
that, *then* you can argue about why.

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