From: Vincent Donnefort <vdonnefort@google.com>
To: David Hildenbrand <david@redhat.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Andrew Morton <akpm@linux-foundation.org>,
Dan Williams <dan.j.williams@intel.com>,
rostedt@goodmis.org
Subject: Re: [PATCH v1 1/2] mm/memory: cleanly support zeropage in vm_insert_page*(), vm_map_pages*() and vmf_insert_mixed()
Date: Fri, 17 May 2024 16:07:31 +0100 [thread overview]
Message-ID: <Zkdys7YKC5pe1vAu@google.com> (raw)
In-Reply-To: <20240430204044.52755-2-david@redhat.com>
Hi David,
[...]
> -static int validate_page_before_insert(struct page *page)
> +static bool vm_mixed_zeropage_allowed(struct vm_area_struct *vma)
> +{
> + VM_WARN_ON_ONCE(vma->vm_flags & VM_PFNMAP);
> + /*
> + * Whoever wants to forbid the zeropage after some zeropages
> + * might already have been mapped has to scan the page tables and
> + * bail out on any zeropages. Zeropages in COW mappings can
> + * be unshared using FAULT_FLAG_UNSHARE faults.
> + */
> + if (mm_forbids_zeropage(vma->vm_mm))
> + return false;
> + /* zeropages in COW mappings are common and unproblematic. */
> + if (is_cow_mapping(vma->vm_flags))
> + return true;
> + /* Mappings that do not allow for writable PTEs are unproblematic. */
> + if (!(vma->vm_flags & (VM_WRITE | VM_MAYWRITE)))
> + return false;
Shouldn't we return true here?
> + /*
> + * Why not allow any VMA that has vm_ops->pfn_mkwrite? GUP could
> + * find the shared zeropage and longterm-pin it, which would
> + * be problematic as soon as the zeropage gets replaced by a different
> + * page due to vma->vm_ops->pfn_mkwrite, because what's mapped would
> + * now differ to what GUP looked up. FSDAX is incompatible to
> + * FOLL_LONGTERM and VM_IO is incompatible to GUP completely (see
> + * check_vma_flags).
> + */
> + return vma->vm_ops && vma->vm_ops->pfn_mkwrite &&
> + (vma_is_fsdax(vma) || vma->vm_flags & VM_IO);
> +}
> +
[...]
>
> -/*
> - * This is the old fallback for page remapping.
> - *
> - * For historical reasons, it only allows reserved pages. Only
> - * old drivers should use this, and they needed to mark their
> - * pages reserved for the old functions anyway.
> - */
> static int insert_page(struct vm_area_struct *vma, unsigned long addr,
> struct page *page, pgprot_t prot)
> {
> @@ -2023,7 +2065,7 @@ static int insert_page(struct vm_area_struct *vma, unsigned long addr,
> pte_t *pte;
> spinlock_t *ptl;
>
> - retval = validate_page_before_insert(page);
> + retval = validate_page_before_insert(vma, page);
> if (retval)
> goto out;
> retval = -ENOMEM;
> @@ -2043,7 +2085,7 @@ static int insert_page_in_batch_locked(struct vm_area_struct *vma, pte_t *pte,
>
> if (!page_count(page))
> return -EINVAL;
This test here prevents inserting the zero-page.
> - err = validate_page_before_insert(page);
> + err = validate_page_before_insert(vma, page);
> if (err)
> return err;
> return insert_page_into_pte_locked(vma, pte, addr, page, prot);
> @@ -2149,7 +2191,8 @@ EXPORT_SYMBOL(vm_insert_pages);
> * @page: source kernel page
> *
> * This allows drivers to insert individual pages they've allocated
> - * into a user vma.
> + * into a user vma. The zeropage is supported in some VMAs,
> + * see vm_mixed_zeropage_allowed().
> *
> * The page has to be a nice clean _individual_ kernel allocation.
> * If you allocate a compound page, you need to have marked it as
> @@ -2195,6 +2238,8 @@ EXPORT_SYMBOL(vm_insert_page);
> * @offset: user's requested vm_pgoff
> *
> * This allows drivers to map range of kernel pages into a user vma.
> + * The zeropage is supported in some VMAs, see
> + * vm_mixed_zeropage_allowed().
> *
> * Return: 0 on success and error code otherwise.
> */
> @@ -2410,8 +2455,11 @@ vm_fault_t vmf_insert_pfn(struct vm_area_struct *vma, unsigned long addr,
> }
> EXPORT_SYMBOL(vmf_insert_pfn);
>
> -static bool vm_mixed_ok(struct vm_area_struct *vma, pfn_t pfn)
next prev parent reply other threads:[~2024-05-17 15:07 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-30 20:40 [PATCH v1 0/2] mm/memory: cleanly support zeropage in vm_insert_page*(), vm_map_pages*() and vmf_insert_mixed() David Hildenbrand
2024-04-30 20:40 ` [PATCH v1 1/2] " David Hildenbrand
2024-05-17 15:07 ` Vincent Donnefort [this message]
2024-05-21 8:25 ` David Hildenbrand
2024-05-21 9:06 ` Vincent Donnefort
2024-05-21 9:18 ` David Hildenbrand
2024-05-21 10:10 ` Vincent Donnefort
2024-04-30 20:40 ` [PATCH v1 2/2] mm/rmap: sanity check that zeropages are not passed to RMAP 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=Zkdys7YKC5pe1vAu@google.com \
--to=vdonnefort@google.com \
--cc=akpm@linux-foundation.org \
--cc=dan.j.williams@intel.com \
--cc=david@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=rostedt@goodmis.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.