linux-kernel - Re: SCSI breakage on non-cache coherent architectures

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] [day] [month] [year] [list]

Date:	Tue, 20 Nov 2007 17:09:18 -0600
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	benh@...nel.crashing.org
Cc:	Roland Dreier <rdreier@...co.com>,
	Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
	David Miller <davem@...emloft.net>,
	linux-kernel@...r.kernel.org, linux-scsi@...r.kernel.org,
	rmk@....linux.org.uk
Subject: Re: SCSI breakage on non-cache coherent architectures


On Wed, 2007-11-21 at 09:39 +1100, Benjamin Herrenschmidt wrote:
> On Tue, 2007-11-20 at 15:10 -0600, James Bottomley wrote:
> > We're talking about trying to fix this for 2.4; which is already at
> > -rc3 ... Is an entire arch change for dma alignment really a merge
> > candidate at this stage?
> 
> Well, as I said before... it's a matter of what seems to be the less
> likely to break something right ?
> 
> On one side,  I'm doing surgery on code I barely know, the scsi error
> handling, and now it seems I also have to fixup a handful of drivers
> that aren't the most obvious pieces of code around.
> 
> On the other side, Roland proposal is basically just adding a macro that
> can be empty for everybody but a handful of archs, and stick it onto one
> field in one structure...

Yes ... it's the getting arch owner agreement to send the patch that
slightly worries me.

> The later has about 0 chances to actually break something or cause a
> regression. I wouldn't say that about the former.
> 
> Now, I will see if I manage to fixup the NCR drivers to pass a
> pre-allocated buffer (USB storage I think can pass NULL as it's not
> calling prep in atomic context). But then, it complicates the matter
> because that means "restore" will have to know whether prep allocated
> the buffer or not, thus more fields to add to the save struct, it's
> getting messy, unless we decide -all- callers are responsible for the
> buffer allocation (hrm... maybe the best approach).

Sorry, yes, that's what I was thinking ... identically to the way the
struct scsi_eh_save is handled ... or indeed as an extra pointer field
inside scsi_eh_save.

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/