Message ID | cover.1614616683.git.dsterba@suse.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | [GIT,PULL] Kmap conversions for 5.12, take 2 | expand |
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
The pull request you sent on Mon, 1 Mar 2021 17:50:13 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git kmap-conversion-for-5.12
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/7a7fd0de4a9804299793e564a555a49c1fc924cb
Thank you!