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.0801021227140.32517@woody.linux-foundation.org>
Date:	Wed, 2 Jan 2008 12:45:25 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	James Bottomley <James.Bottomley@...senPartnership.com>
cc:	Matthew Wilcox <matthew@....cx>, 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, James Bottomley wrote:
> 
> OK ... I'll revert it.  However, I still think it's the wrong course of
> action, because as far as my analysis goes, this code is functionally
> equivalent to what went before with the exception that we now rely on
> the request->cmd_type information in the post processing (previously we
> just relied on the cmnd->done pointer).

To say that another way:

 "the code is functionally equivalent, EXCEPT IT ISN'T, and it's 
  known to be broken".

wouldn't you say my version is more honest and correct?

The old code did a per-command callback. The new one doesn't. The code was 
*supposed* to be equivalent, but it clearly isn't. Why argue the point?

And no, maybe it's not that REQ_TYPE_BLOCK_PC should be calling ->done, 
maybe it's that some REQ_TYPE_FS commands should *not* be calling ->done. 
Or maybe we somehow got the wrong ->done in the first place, because we 
now get it from a different source.

I don't know, but what I'm arguing (very strongly) against is this 
attitude of "we don't know what's wrong, but wë́'ll leave it broken because 
we can't be bothered to figure it out".

That is exactly what reverting is there for. It doesn't matter one *whit* 
if the new code is cleaner and prettier, if it doesn't work.

			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/