On 4/7/2015 2:00 AM, David Daney wrote:
From: David Daney <david.daney@xxxxxxxxxx>Hi David,
The dma_alloc_coherent() function returns a virtual address which can
be used for coherent access to the underlying memory. On some
architectures, like arm64, undefined behavior results if this memory is
also accessed via virtual mappings that are not coherent. Because of
their undefined nature, operations like virt_to_page() return garbage
when passed virtual addresses obtained from dma_alloc_coherent(). Any
subsequent mappings via vmap() of the garbage page values are unusable
and result in bad things like bus errors (synchronous aborts in ARM64
The MLX4 driver contains code that does the equivalent of:
This results in an OOPs when the device is opened.
To fix this...
Always use result of dma_alloc_coherent() directly.
I'm not sure this solution is good enough for the common case(s).
Typical allocation size will be around 64KB (with default 1K ring size).
We can't rely on the system to always provide us with that amount of contiguous memory.
Current code allocation scheme is more robust, max_direct is typically 2 * PAGE_SIZE,
so pages from order 1 are far more available then higher order.
I need to check why the code is written as it is today, and not as in this RFC (which is much more trivial).
I'll continue to investigate tomorrow, will get back with some answers.
Remove 'max_direct' parameter to mlx4_buf_alloc(), as it is unused,
and adjust all callers.
Remove mlx4_en_map_buffer() and mlx4_en_unmap_buffer() as they now do
nothing, and adjust all callers.
Remove 'page_list' element from struct mlx4_buf as it is unused.
Signed-off-by: David Daney <david.daney@xxxxxxxxxx>