Why can't ttm_tt_swapout() handle uncached or WC BOs?

[Dave Airlie]

On Fri, 18 Sep 2020 at 00:49, Christian König <christian.koenig at amd.com> wrote:
>
> Am 17.09.20 um 16:44 schrieb Michel Dänzer:
> > On 2020-09-17 2:20 p.m., Christian König wrote:
> >> Hi guys,
> >>
> >> Michel once submitted a patch to fix triggering this BUG_ON in
> >> ttm_tt_swapout():
> >>
> >>> BUG_ON(ttm->caching_state != tt_cached);
> >>
> >> Now my question is does anybody know why we have that in the first
> >> place?
> >>
> >> The only problematic thing I can see is calling copy_highpage() and
> >> that one is just doing a kmap_atomic()/kunmap_atomic() on the source
> >> and destination.
> >>
> >> I can't see why it should be problematic for this temporary mapping
> >> to be cached instead of uncached or WC?
> >>
> >> Does anybody has any idea?
> >
> > One thing is that AFAIK some (ARM?) CPUs can get very upset when
> > there's both a cached and uncacheable mapping for the same physical page.
>
> Good point, but I already considered this.
>
> If there is another mapping for that page left we are completely busted
> anyway since we are currently changing the underlying storage.
>

It's not just ARM of course, x86 PAT also has many issues about
multiple mappings of the same backing page with different attributes.

The only mappings might be in the linear mapping, since not all pages
we get here will necessarily be high pages I assume and therefore
could have a linear mapping. If we've changed the linear mapping to
non-cached, then create a cached kmap I'm not 100% that won't cause
issues.

but this is a definite maze of twisty passages and I'd probably need
to sit down and break it a bit more.

Dave.