Messages in this thread | | | Date | Mon, 21 May 2001 03:37:06 +0200 | From | Andrea Arcangeli <> | Subject | Re: alpha iommu fixes |
| |
On Sun, May 20, 2001 at 06:07:17PM -0700, David S. Miller wrote: > > Andrea Arcangeli writes: > > > [..] Even sparc64's fancy > > > iommu-based pci_map_single() always succeeds. > > > > Whatever sparc64 does to hide the driver bugs you can break it if you > > pci_map 4G+1 bytes of phyical memory. > > Which is an utterly stupid thing to do. > > Please construct a plausable situation where this would occur legally > and not be a driver bug, given the maximum number of PCI busses and > slots found on sparc64 and the maximum _concurrent_ usage of PCI dma > space for any given driver (which isn't doing something stupid).
Assume I have a dozen of PCI cards that does DMA using SG tables that can map up to some houndred mbytes of ram each, so I can just program the cards to start the dma on those houndred mbyte of ram, most of the time the I/O is not simulaneous, but very rarely it happens to be simultaneous and in turn it tries to pci_map_sg more than 4G of physical ram. After that sparc64 iommu code will say "bye bye" and the machine will crash because the nic driver is not checking for pci_map_single faliures.
I don't see why the above scenario should be classified as stupid. such pci_map_* API and the device drivers have to be generic.
It's like if you say me that there's no need to check for alloc_pages(GFP_ATOMIC) faliures in the device drivers because all machines you are using have 256G of ram and you never use all the physical ram with your workloads. I would never buy such an argument.
Furthmore currently (2.4.5pre3) on alpha you only need to ask the iommu to map more than 128mbyte of ram to crash (I increased it to 512mbyte at least, Jay said my first patch that increased it to 1G is risky because some device gets confused by bus addresses at around -1M and we keep the dynamic window above 3G, 512M should still be enough to cover 99% of hardware configurations I agree on that but this is not a good excuse to left all device drivers buggy just because those bugs doesn't trigger in all the hardware configurations out there).
Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |