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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHk-=whd9rDePO5M6roDcxvb9EWNTQ2FuLd3rWKWHQ03FqT2ZQ@mail.gmail.com>
Date:   Mon, 1 Mar 2021 11:42:41 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     David Sterba <dsterba@...e.com>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Ira Weiny <ira.weiny@...el.com>, Linux-MM <linux-mm@...ck.org>
Subject: Re: [GIT PULL] Kmap conversions for 5.12, take 2

On Mon, Mar 1, 2021 at 8:52 AM David Sterba <dsterba@...e.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