[lkml]   [2006]   [Feb]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] ipr: don't doublefree pages from scatterlist
From: Hugh Dickins <>
Date: Mon, 6 Feb 2006 09:32:54 +0000 (GMT)

> From looking at the source, the architectures I found to be doing
> scatterlist coalescing in some cases were alpha, ia64, parisc (some
> code under drivers), powerpc, sparc64 and x86_64.
> I agree with you that it would be possible for them to do the coalescing
> by just adjusting dma_address and dma_length (though it's architecture-
> dependent whether there are such fields at all), not interfering with
> the input page and length; and maybe some of them do proceed that way.
> I didn't find the coalescing code in any of them very easy to follow.
> So please examine arch/x86_64/kernel/pci_gart.c gart_map_sg (and
> dma_map_cont which it calls): x86_64 was the architecture on which
> the problem was really found with drivers/scsi/st.c, and avoided
> by that boot option iommu=nomerge.
> Lines like "*sout = *s;" and "*sout = sg[start];" are structure-
> copying whole scallerlist entries from one position in the list
> to another, without explicit mention of the page and length fields.

That's a bug, frankly. Sparc64 doesn't need to do anything like
that. Spamming the page pointers is really really bogus and I'm
surprised this doesn't make more stuff explode.

It was never the intention to allow the DMA mapping support code
to modify the page, offset, and length members of the scatterlist.
Only the DMA components.

I'd really prefer that those assignments get fixed and an explicit
note added to Documentation/DMA-mapping.txt about this.

It's rediculious that these generic subsystem drivers need to
know about this. :)

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-02-06 10:48    [W:0.135 / U:5.172 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site