From: Mike Kravetz <mike.kravetz@oracle.com>
To: David Hildenbrand <david@redhat.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, stable@vger.kernel.org
Subject: Re: [PATCH v2 1/2] mm/hugetlb: fix hugetlb not supporting softdirty tracking
Date: Thu, 11 Aug 2022 11:27:32 -0700 [thread overview]
Message-ID: <YvVKFLHSY6QDFzaJ@monkey> (raw)
In-Reply-To: <20220811103435.188481-2-david@redhat.com>
On 08/11/22 12:34, David Hildenbrand wrote:
> Staring at hugetlb_wp(), one might wonder where all the logic for shared
> mappings is when stumbling over a write-protected page in a shared
> mapping. In fact, there is none, and so far we thought we could get
> away with that because e.g., mprotect() should always do the right thing
> and map all pages directly writable.
>
> Looks like we were wrong:
>
> --------------------------------------------------------------------------
> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
> #include <fcntl.h>
> #include <unistd.h>
> #include <errno.h>
> #include <sys/mman.h>
>
> #define HUGETLB_SIZE (2 * 1024 * 1024u)
>
> static void clear_softdirty(void)
> {
> int fd = open("/proc/self/clear_refs", O_WRONLY);
> const char *ctrl = "4";
> int ret;
>
> if (fd < 0) {
> fprintf(stderr, "open(clear_refs) failed\n");
> exit(1);
> }
> ret = write(fd, ctrl, strlen(ctrl));
> if (ret != strlen(ctrl)) {
> fprintf(stderr, "write(clear_refs) failed\n");
> exit(1);
> }
> close(fd);
> }
>
> int main(int argc, char **argv)
> {
> char *map;
> int fd;
>
> fd = open("/dev/hugepages/tmp", O_RDWR | O_CREAT);
> if (!fd) {
> fprintf(stderr, "open() failed\n");
> return -errno;
> }
> if (ftruncate(fd, HUGETLB_SIZE)) {
> fprintf(stderr, "ftruncate() failed\n");
> return -errno;
> }
>
> map = mmap(NULL, HUGETLB_SIZE, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
> if (map == MAP_FAILED) {
> fprintf(stderr, "mmap() failed\n");
> return -errno;
> }
>
> *map = 0;
>
> if (mprotect(map, HUGETLB_SIZE, PROT_READ)) {
> fprintf(stderr, "mmprotect() failed\n");
> return -errno;
> }
>
> clear_softdirty();
>
> if (mprotect(map, HUGETLB_SIZE, PROT_READ|PROT_WRITE)) {
> fprintf(stderr, "mmprotect() failed\n");
> return -errno;
> }
>
> *map = 0;
>
> return 0;
> }
> --------------------------------------------------------------------------
>
> Above test fails with SIGBUS when there is only a single free hugetlb page.
> # echo 1 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages
> # ./test
> Bus error (core dumped)
>
> And worse, with sufficient free hugetlb pages it will map an anonymous page
> into a shared mapping, for example, messing up accounting during unmap
> and breaking MAP_SHARED semantics:
> # echo 2 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages
> # ./test
> # cat /proc/meminfo | grep HugePages_
> HugePages_Total: 2
> HugePages_Free: 1
> HugePages_Rsvd: 18446744073709551615
> HugePages_Surp: 0
>
> Reason in this particular case is that vma_wants_writenotify() will
> return "true", removing VM_SHARED in vma_set_page_prot() to map pages
> write-protected. Let's teach vma_wants_writenotify() that hugetlb does not
> support softdirty tracking.
>
> Fixes: 64e455079e1b ("mm: softdirty: enable write notifications on VMAs after VM_SOFTDIRTY cleared")
> Cc: <stable@vger.kernel.org> # v3.18+
> Signed-off-by: David Hildenbrand <david@redhat.com>
> ---
> mm/mmap.c | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
Thanks,
Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
--
Mike Kravetz
>
> diff --git a/mm/mmap.c b/mm/mmap.c
> index c035020d0c89..9d780f415be3 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -1646,8 +1646,11 @@ int vma_wants_writenotify(struct vm_area_struct *vma, pgprot_t vm_page_prot)
> pgprot_val(vm_pgprot_modify(vm_page_prot, vm_flags)))
> return 0;
>
> - /* Do we need to track softdirty? */
> - if (vma_soft_dirty_enabled(vma))
> + /*
> + * Do we need to track softdirty? hugetlb does not support softdirty
> + * tracking yet.
> + */
> + if (vma_soft_dirty_enabled(vma) && !is_vm_hugetlb_page(vma))
> return 1;
>
> /* Specialty mapping? */
> --
> 2.35.3
>
>
next prev parent reply other threads:[~2022-08-11 18:27 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-11 10:34 [PATCH v2 0/2] mm/hugetlb: fix write-fault handling for shared mappings David Hildenbrand
2022-08-11 10:34 ` [PATCH v2 1/2] mm/hugetlb: fix hugetlb not supporting softdirty tracking David Hildenbrand
2022-08-11 18:27 ` Mike Kravetz [this message]
2022-08-11 10:34 ` [PATCH v2 2/2] mm/hugetlb: support write-faults in shared mappings David Hildenbrand
2022-08-11 13:59 ` Peter Xu
2022-08-11 16:24 ` David Hildenbrand
2022-08-11 18:59 ` Mike Kravetz
2022-08-15 13:35 ` Gerald Schaefer
2022-08-15 15:07 ` David Hildenbrand
2022-08-15 15:59 ` Gerald Schaefer
2022-08-15 18:03 ` David Hildenbrand
2022-08-15 18:38 ` Gerald Schaefer
2022-08-15 21:43 ` Mike Kravetz
2022-08-16 9:33 ` Gerald Schaefer
2022-08-16 20:43 ` David Hildenbrand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YvVKFLHSY6QDFzaJ@monkey \
--to=mike.kravetz@oracle.com \
--cc=david@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox