linux-kernel - Re: [PATCH] mm/huge_memory: conditionally call maybe_mkwrite() and drop pte_wrprotect() in __split_huge_pmd

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: <81a2070a-f7aa-2185-8211-26b57815e968@redhat.com>
Date:   Tue, 11 Apr 2023 16:18:57 +0200
From:   David Hildenbrand <david@...hat.com>
To:     linux-kernel@...r.kernel.org
Cc:     linux-mm@...ck.org, linux-kselftest@...r.kernel.org,
        sparclinux@...r.kernel.org
Subject: Re: [PATCH] mm/huge_memory: conditionally call maybe_mkwrite() and
 drop pte_wrprotect() in __split_huge_pmd_locked()

On 11.04.23 16:15, David Hildenbrand wrote:
> No need to call maybe_mkwrite() to then wrprotect if the source PMD was not
> writable.
> 
> It's worth nothing that this now allows for PTEs to be writable even if
> the source PMD was not writable: if vma->vm_page_prot includes write
> permissions.
> 
> As documented in commit 931298e103c2 ("mm/userfaultfd: rely on
> vma->vm_page_prot in uffd_wp_range()"), any mechanism that intends to
> have pages wrprotected (COW, writenotify, mprotect, uffd-wp, softdirty,
> ...) has to properly adjust vma->vm_page_prot upfront, to not include
> write permissions. If vma->vm_page_prot includes write permissions, the
> PTE/PMD can be writable as default.
> 
> This now mimics the handling in mm/migrate.c:remove_migration_pte() and in
> mm/huge_memory.c:remove_migration_pmd(), which has been in place for a
> long time (except that 96a9c287e25d ("mm/migrate: fix wrongly apply write
> bit after mkdirty on sparc64") temporarily changed it).
> 
> Signed-off-by: David Hildenbrand <david@...hat.com>
> ---

Ignore this one, it's a duplicate of 6/6 and I forgot to delete that 
patch before triggering git send-email ...

-- 
Thanks,

David / dhildenb