linux-kernel - Re: PROBLEM REMAINS: [sata_nv ADMA breaks ATAPI] Crash on accessing DVD-RAM

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]

Message-Id: <1200363823.3159.107.camel@localhost.localdomain>
Date:	Mon, 14 Jan 2008 20:23:43 -0600
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	Robert Hancock <hancockr@...w.ca>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>, Alexander <aledin@...l.ru>,
	linux-kernel@...r.kernel.org, ide <linux-ide@...r.kernel.org>,
	Jeff Garzik <jeff@...zik.org>, Tejun Heo <htejun@...il.com>
Subject: Re: PROBLEM REMAINS: [sata_nv ADMA breaks
	ATAPI]	Crash	on	accessing DVD-RAM


On Mon, 2008-01-14 at 19:41 -0600, Robert Hancock wrote:
> James Bottomley wrote:
> > On Sun, 2008-01-13 at 16:29 +0000, Alan Cox wrote:
> >>> Yes, I concur for the short term.  The other two possible courses of
> >>> action either involve long discussions (the different device one) or
> >>> you'll never quite be sure you got all the paths (the GFP_DMA32 one).
> >>> At least with this one, you know everything will work.
> >> The different device one is tricky because the PCI layer is involved in
> >> mapping on some systems so you can't just magic up a platform device for
> >> it. Putting a mask on the block queue might perhaps work as a model
> >> which avoids breaking stuff by suprise, with the device left at 32bit
> >> masking.
> > 
> > Actually, you might be able to ... that's why I'm suggesting it.  There
> > are two pieces of information the arch layer needs to know:  what is the
> > dma_mask and where is the iommu/bridge/whatever.  When we went to the
> > generic dma_map_ API on parisc, we found you simply get the one from
> > struct device and for the other you walk up the device tree until you
> > find what you're looking for.
> > 
> > I'm not suggesting we invent a dummy pci_device ... I'm suggesting we
> > dma_map on the existing scsi_device, which is properly parented to the
> > pci_device.  The problem with this approach will be any architecture
> > which blindly expects dma_map converts to pci_dma_map; however, I'm not
> > sure we have any of those left.
> 
> I've tried the dumb solution of setting the mask on the PCI device (for 
> both ports) whenever an ATAPI device is detected, and ran into problems 
> with that. If we really need to keep the block queue bounce limit and 
> DMA mask the same, then we then have to set the bounce limit on both 
> ports as well. If you blindly do that from slave_config, though, then 
> you blow up since on the first port's initial slave_config the block 
> queue for the second port isn't allocated yet, so you'd have to detect 
> that case somehow. And if it's done via hotplug after the other port is 
> already in use, it'll be changing the limits on a port that's in active 
> use, which seems like it could be a bit racy.
> 
> So, any ideas? Maybe using the separate struct device is the easiest 
> solution, if it'll work..

Right, and the separate struct device exists already in the
scsi_device ... the problem currently is that this isn't the device we
map with, but it could easily become so ... provided the architectures
support it.

This isn't a quick fix solution ... it will involve quite a bit of
device use rethreading through both scsi and ata, so it might be wise to
get linux-arch buy in first.

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/