Re: [GIT PULL] Kmap conversions for 5.12, take 2

[Linus Torvalds <torvalds@linux-foundation.org>]

On Mon, Mar 1, 2021 at 8:52 AM David Sterba <dsterba@suse.com> wrote:
>
> Ira Weiny (6):
>       mm/highmem: Lift memcpy_[to|from]_page to core
>       mm/highmem: Convert memcpy_[to|from]_page() to kmap_local_page()
>       mm/highmem: Introduce memcpy_page(), memmove_page(), and memset_page()
>       mm/highmem: Add VM_BUG_ON() to mem*_page() calls
>       btrfs: use memcpy_[to|from]_page() and kmap_local_page()
>       btrfs: use copy_highpage() instead of 2 kmaps()

So I've pulled this now, although I still end up wondering about one case there:

-       char *map;
-
-       map = kmap(page);
-       memcpy(map, data_start, datal);
+       memcpy_to_page(page, 0, data_start, datal);
        flush_dcache_page(page);
-       kunmap(page);

where that flush_dcache_page() is now done outside the kmap of the page.

If you have an architecture that does both (a) highmem and (b) virtual
caches, it means that the "memcpy_to_page()" gets done using one
virtual address, and the flush_dcache_page() could in theory be done
using another virtual address.

I do not believe this is a problem in practice (flush_dcache_page()
might have to kmap it again, but presumably get the same virtual
address, although who the heck knows). And I personally don't know
that we should even care any more - I've been arguing that we should
start deprecating highmem entirely, and while there are 32-bit arm
chips that still use them, I hope to $DEITY that those ARM chips
aren't the garbage virtual cached ones.

Furthermore, I think that kunmap() always guaranteed that the cache
was flushed anyway before unmapping, because anything else would have
been too broken for words anyway. So I think _all_ of those
flush_dcache_page() cases were just largely bogus.

I can't be bothered to really look into it, because at some point,
crap hardware is just too crap to even care about. Pure virtual caches
are where I personally say "I don't care". But I'm mentioning it
because there might be some masochistic person out there that finds
this issue interesting, and wants to do some self-flagellation to dive
into this all and make sure it's ok.

           Linus