more iommu sg merging fallout

[David Miller <davem@davemloft.net>]

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().