On Thu, Dec 20, 2018 at 12:23:46PM +0900, Tomasz Figa wrote:
> I haven't been following the problems with virtually tagged cases,
> would you mind sharing some background, so that we can consider it
> when adding non-consistent allocations to VB2?
The problem exists at least partially with the current consistent
allocator, and we need to fix it. My non-coherent series does not have
it, but we would add it if we allowed virtual remapping.
The problem with get_sgtable is that it creates aliasing of kernel
virtual addresses used to access memory and thus the cache. We have
the mapping return from dma_alloc_*, which in case of a remap contains
a vmap/ioremap style address that is different from the kernel direct
mapping address you get from using page_address/kmap on the pages
backing that mapping. (assuming you even have pages - in a few corner
cases we don't and the whole interface concept breaks down).
This creates various problems as the the scatterlist returned from
get_stable now gives a second way to access this memory through direct
mapping addresses in the pages contained in it, but as soon as we do
that we:
a) don't use the nocache mapping used by the coherent allocator if that
is on a per-mapping basis (which it is for many architectures), so
you do get data in the cache even when that might not be assumed
b) if the data returned from dma_alloc_coherent was not actually a
remap but a special pool of non-cached address the cache flushing
instructions might be invalid and caused problems
c) any cache flushing now operates on just those direct mappings, which
in case of the non-coherent allocator and access through the
remapped address does the wrong thing for virtually tagged caches
