On 6/7/18 1:28 PM, Ben Hutchings wrote:
On Mon, 2018-05-28 at 11:59 +0200, Greg Kroah-Hartman wrote:
4.4-stable review patch. If anyone has any objections, please let me know.
From: Joe Jin joe.jin@oracle.com
commit 4855c92dbb7b3b85c23e88ab7ca04f99b9677b41 upstream.
When run raidconfig from Dom0 we found that the Xen DMA heap is reduced, but Dom Heap is increased by the same size. Tracing raidconfig we found that the related ioctl() in megaraid_sas will call dma_alloc_coherent() to apply memory. If the memory allocated by Dom0 is not in the DMA area, it will exchange memory with Xen to meet the requiment. Later drivers call dma_free_coherent() to free the memory, on xen_swiotlb_free_coherent() the check condition (dev_addr + size - 1 <= dma_mask) is always false,
I think this was meant to say (dev_addr + size - 1 > dma_mask), i.e.
Hi Ben,
Yes you are right, sorry I made the mistake, thanks for catch it. Is there any way to fix description from git repo?
Regards, Joe
the condition that is replaced by this commit. If that's always false, the new condition (the logical inverse) must always be true.
[...]
--- a/drivers/xen/swiotlb-xen.c +++ b/drivers/xen/swiotlb-xen.c @@ -359,7 +359,7 @@ xen_swiotlb_free_coherent(struct device * physical address */ phys = xen_bus_to_phys(dev_addr);
- if (((dev_addr + size - 1 > dma_mask)) ||
- if (((dev_addr + size - 1 <= dma_mask)) ||
range_straddles_page_boundary(phys, size)) xen_destroy_contiguous_region(phys, order);
So now we will always call xen_destroy_contiguous_region(), whether or not xen_create_contiguous_region() was called during allocation. Is that really the intent? If so, the entire condition could be removed to make this clear.
Alternately, if the commit message is correct, the condition could be simplified to range_straddles_page_boundary(...).
But I'm not at all convinced that either of these is correct. It seems like you need to either find a way of distinguishing between memory allocated with or without the use of xen_create_contiguous_region(), or to use it unconditionally.
Ben.