Messages in this thread | | | Date | Tue, 05 Feb 2008 20:41:38 -0800 (PST) | Subject | more iommu sg merging fallout | From | David Miller <> |
| |
The sparc64 change:
commit fde6a3c82d67f592eb587be4d12222b0ae6d4321 Author: FUJITA Tomonori <tomof@acm.org> Date: Mon Feb 4 22:28:02 2008 -0800
iommu sg merging: sparc64: make iommu respect the segment size limits This patch makes iommu respect segment size limits when merging sg lists. Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Cc: Jeff Garzik <jeff@garzik.org> Cc: James Bottomley <James.Bottomley@steeleye.com> Acked-by: Jens Axboe <jens.axboe@oracle.com> Cc: "David S. Miller" <davem@davemloft.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
has significant errors and is going to eat people's disks, as it just nearly did to mine.
Typically what you'll see are NULL pointer derefernces in dma_4v_map_sg() and dma_4u_map_sg() and then the kernel usually craps on your superblock very shortly thereafter.
The changeset above modified only prepare_sg() but that is only the first pass of the SG mapping algorithm of the sparc64 IOMMU layer.
The second pass that fills in the entries depends upon how the first pass does things. So if you change the first pass decision making you have to update the second pass's as well.
That second pass is implemented in fill_sg() (there is a version in both arch/sparc64/kernel/iommu.c and arch/sparc64/kernel/pci_sun4v.c), which probably needs new logic as was added to prepare_sg() to handle dma_get_max_seg_size().
| |