All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vlastimil Babka <vbabka@suse.cz>
To: David Hildenbrand <david@redhat.com>, linux-kernel@vger.kernel.org
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Hugh Dickins <hughd@google.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	David Rientjes <rientjes@google.com>,
	Shakeel Butt <shakeelb@google.com>,
	John Hubbard <jhubbard@nvidia.com>,
	Jason Gunthorpe <jgg@nvidia.com>,
	Mike Kravetz <mike.kravetz@oracle.com>,
	Mike Rapoport <rppt@linux.ibm.com>,
	Yang Shi <shy828301@gmail.com>,
	"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>,
	Matthew Wilcox <willy@infradead.org>,
	Jann Horn <jannh@google.com>, Michal Hocko <mhocko@kernel.org>,
	Nadav Amit <namit@vmware.com>, Rik van Riel <riel@surriel.com>,
	Roman Gushchin <guro@fb.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Peter Xu <peterx@redhat.com>, Donald Dutile <ddutile@redhat.com>,
	Christoph Hellwig <hch@lst.de>, Oleg Nesterov <oleg@redhat.com>,
	Jan Kara <jack@suse.cz>, Liang Zhang <zhangliang5@huawei.com>,
	Pedro Gomes <pedrodemargomes@gmail.com>,
	Oded Gabbay <oded.gabbay@gmail.com>,
	linux-mm@kvack.org
Subject: Re: [PATCH v3 16/16] mm/gup: sanity-check with CONFIG_DEBUG_VM that anonymous pages are exclusive when (un)pinning
Date: Fri, 22 Apr 2022 08:54:06 +0200	[thread overview]
Message-ID: <85079e4e-eedc-4f7e-a41c-50bda76f484d@suse.cz> (raw)
In-Reply-To: <31b37b7c-a969-eec2-bdff-a7e4dca9b770@redhat.com>

On 4/21/22 11:15, David Hildenbrand wrote:
> On 19.04.22 19:40, Vlastimil Babka wrote:
>> On 3/29/22 18:04, David Hildenbrand wrote:
>>> Let's verify when (un)pinning anonymous pages that we always deal with
>>> exclusive anonymous pages, which guarantees that we'll have a reliable
>>> PIN, meaning that we cannot end up with the GUP pin being inconsistent
>>> with he pages mapped into the page tables due to a COW triggered
>>> by a write fault.
>>>
>>> When pinning pages, after conditionally triggering GUP unsharing of
>>> possibly shared anonymous pages, we should always only see exclusive
>>> anonymous pages. Note that anonymous pages that are mapped writable
>>> must be marked exclusive, otherwise we'd have a BUG.
>>>
>>> When pinning during ordinary GUP, simply add a check after our
>>> conditional GUP-triggered unsharing checks. As we know exactly how the
>>> page is mapped, we know exactly in which page we have to check for
>>> PageAnonExclusive().
>>>
>>> When pinning via GUP-fast we have to be careful, because we can race with
>>> fork(): verify only after we made sure via the seqcount that we didn't
>>> race with concurrent fork() that we didn't end up pinning a possibly
>>> shared anonymous page.
>>>
>>> Similarly, when unpinning, verify that the pages are still marked as
>>> exclusive: otherwise something turned the pages possibly shared, which
>>> can result in random memory corruptions, which we really want to catch.
>>>
>>> With only the pinned pages at hand and not the actual page table entries
>>> we have to be a bit careful: hugetlb pages are always mapped via a
>>> single logical page table entry referencing the head page and
>>> PG_anon_exclusive of the head page applies. Anon THP are a bit more
>>> complicated, because we might have obtained the page reference either via
>>> a PMD or a PTE -- depending on the mapping type we either have to check
>>> PageAnonExclusive of the head page (PMD-mapped THP) or the tail page
>>> (PTE-mapped THP) applies: as we don't know and to make our life easier,
>>> check that either is set.
>>>
>>> Take care to not verify in case we're unpinning during GUP-fast because
>>> we detected concurrent fork(): we might stumble over an anonymous page
>>> that is now shared.
>>>
>>> Signed-off-by: David Hildenbrand <david@redhat.com>
>> 
>> Acked-by: Vlastimil Babka <vbabka@suse.cz>
>> 
>> Nits:
>> 
>>> @@ -510,6 +563,10 @@ static struct page *follow_page_pte(struct vm_area_struct *vma,
>>>  		page = ERR_PTR(-EMLINK);
>>>  		goto out;
>>>  	}
>>> +
>>> +	VM_BUG_ON((flags & FOLL_PIN) && PageAnon(page) &&
>>> +		  !PageAnonExclusive(page));
>> 
>> Do we rather want VM_BUG_ON_PAGE? Also for the same tests in mm/huge*.c below.
> 
> Make sense, thanks:

LGTM

> diff --git a/mm/gup.c b/mm/gup.c
> index 5c17d4816441..46ffd8c51c6e 100644
> --- a/mm/gup.c
> +++ b/mm/gup.c
> @@ -564,8 +564,8 @@ static struct page *follow_page_pte(struct vm_area_struct *vma,
>                 goto out;
>         }
>  
> -       VM_BUG_ON((flags & FOLL_PIN) && PageAnon(page) &&
> -                 !PageAnonExclusive(page));
> +       VM_BUG_ON_PAGE((flags & FOLL_PIN) && PageAnon(page) &&
> +                      !PageAnonExclusive(page), page);
>  
>         /* try_grab_page() does nothing unless FOLL_GET or FOLL_PIN is set. */
>         if (unlikely(!try_grab_page(page, flags))) {
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index 390f22334ee9..a2f44d8d3d47 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -1392,8 +1392,8 @@ struct page *follow_trans_huge_pmd(struct vm_area_struct *vma,
>         if (!pmd_write(*pmd) && gup_must_unshare(flags, page))
>                 return ERR_PTR(-EMLINK);
>  
> -       VM_BUG_ON((flags & FOLL_PIN) && PageAnon(page) &&
> -                 !PageAnonExclusive(page));
> +       VM_BUG_ON_PAGE((flags & FOLL_PIN) && PageAnon(page) &&
> +                       !PageAnonExclusive(page), page);
>  
>         if (!try_grab_page(page, flags))
>                 return ERR_PTR(-ENOMEM);
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 8a635b5b5270..0ba2b1930b21 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -6100,8 +6100,8 @@ long follow_hugetlb_page(struct mm_struct *mm, struct vm_area_struct *vma,
>                 pfn_offset = (vaddr & ~huge_page_mask(h)) >> PAGE_SHIFT;
>                 page = pte_page(huge_ptep_get(pte));
>  
> -               VM_BUG_ON((flags & FOLL_PIN) && PageAnon(page) &&
> -                         !PageAnonExclusive(page));
> +               VM_BUG_ON_PAGE((flags & FOLL_PIN) && PageAnon(page) &&
> +                              !PageAnonExclusive(page), page);
>  
>                 /*
>                  * If subpage information not requested, update counters
> 
> 
> 


  reply	other threads:[~2022-04-22  6:54 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-29 16:04 [PATCH v3 00/16] mm: COW fixes part 2: reliable GUP pins of anonymous pages David Hildenbrand
2022-03-29 16:04 ` [PATCH v3 01/16] mm/rmap: fix missing swap_free() in try_to_unmap() after arch_unmap_one() failed David Hildenbrand
2022-04-11 16:04   ` Vlastimil Babka
2022-03-29 16:04 ` [PATCH v3 02/16] mm/hugetlb: take src_mm->write_protect_seq in copy_hugetlb_page_range() David Hildenbrand
2022-04-11 16:15   ` Vlastimil Babka
2022-03-29 16:04 ` [PATCH v3 03/16] mm/memory: slightly simplify copy_present_pte() David Hildenbrand
2022-04-11 16:38   ` Vlastimil Babka
2022-03-29 16:04 ` [PATCH v3 04/16] mm/rmap: split page_dup_rmap() into page_dup_file_rmap() and page_try_dup_anon_rmap() David Hildenbrand
2022-04-11 18:18   ` Vlastimil Babka
2022-04-12  8:06     ` David Hildenbrand
2022-03-29 16:04 ` [PATCH v3 05/16] mm/rmap: convert RMAP flags to a proper distinct rmap_t type David Hildenbrand
2022-04-12  8:11   ` Vlastimil Babka
2022-03-29 16:04 ` [PATCH v3 06/16] mm/rmap: remove do_page_add_anon_rmap() David Hildenbrand
2022-04-12  8:13   ` Vlastimil Babka
2022-03-29 16:04 ` [PATCH v3 07/16] mm/rmap: pass rmap flags to hugepage_add_anon_rmap() David Hildenbrand
2022-04-12  8:37   ` Vlastimil Babka
2022-03-29 16:04 ` [PATCH v3 08/16] mm/rmap: drop "compound" parameter from page_add_new_anon_rmap() David Hildenbrand
2022-04-12  8:47   ` Vlastimil Babka
2022-04-12  9:37     ` David Hildenbrand
2022-04-13 12:26       ` Matthew Wilcox
2022-04-13 12:28         ` David Hildenbrand
2022-04-13 12:48           ` Matthew Wilcox
2022-04-13 16:20             ` David Hildenbrand
2022-03-29 16:04 ` [PATCH v3 09/16] mm/rmap: use page_move_anon_rmap() when reusing a mapped PageAnon() page exclusively David Hildenbrand
2022-04-12  9:26   ` Vlastimil Babka
2022-04-12  9:28     ` David Hildenbrand
2022-03-29 16:04 ` [PATCH v3 10/16] mm/huge_memory: remove outdated VM_WARN_ON_ONCE_PAGE from unmap_page() David Hildenbrand
2022-04-12  9:37   ` Vlastimil Babka
2022-03-29 16:04 ` [PATCH v3 11/16] mm/page-flags: reuse PG_mappedtodisk as PG_anon_exclusive for PageAnon() pages David Hildenbrand
2022-04-13  8:25   ` Vlastimil Babka
2022-04-13 10:28     ` David Hildenbrand
2022-04-13 14:55       ` Vlastimil Babka
2022-03-29 16:04 ` [PATCH v3 12/16] mm: remember exclusively mapped anonymous pages with PG_anon_exclusive David Hildenbrand
2022-04-13 16:28   ` Vlastimil Babka
2022-04-13 16:39     ` David Hildenbrand
2022-04-13 18:28       ` Vlastimil Babka
2022-04-19 16:46         ` David Hildenbrand
2022-04-13 18:29   ` Vlastimil Babka
2022-03-29 16:04 ` [PATCH v3 13/16] mm/gup: disallow follow_page(FOLL_PIN) David Hildenbrand
2022-04-14 15:18   ` Vlastimil Babka
2022-03-29 16:04 ` [PATCH v3 14/16] mm: support GUP-triggered unsharing of anonymous pages David Hildenbrand
2022-04-14 17:15   ` Vlastimil Babka
2022-04-19 16:29     ` David Hildenbrand
2022-04-19 16:31       ` Vlastimil Babka
2022-03-29 16:04 ` [PATCH v3 15/16] mm/gup: trigger FAULT_FLAG_UNSHARE when R/O-pinning a possibly shared anonymous page David Hildenbrand
2022-04-19 15:56   ` Vlastimil Babka
2022-03-29 16:04 ` [PATCH v3 16/16] mm/gup: sanity-check with CONFIG_DEBUG_VM that anonymous pages are exclusive when (un)pinning David Hildenbrand
2022-04-19 17:40   ` Vlastimil Babka
2022-04-21  9:15     ` David Hildenbrand
2022-04-22  6:54       ` Vlastimil Babka [this message]
2022-03-29 16:09 ` [PATCH v3 00/16] mm: COW fixes part 2: reliable GUP pins of anonymous pages 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=85079e4e-eedc-4f7e-a41c-50bda76f484d@suse.cz \
    --to=vbabka@suse.cz \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=david@redhat.com \
    --cc=ddutile@redhat.com \
    --cc=guro@fb.com \
    --cc=hch@lst.de \
    --cc=hughd@google.com \
    --cc=jack@suse.cz \
    --cc=jannh@google.com \
    --cc=jgg@nvidia.com \
    --cc=jhubbard@nvidia.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=mike.kravetz@oracle.com \
    --cc=namit@vmware.com \
    --cc=oded.gabbay@gmail.com \
    --cc=oleg@redhat.com \
    --cc=pedrodemargomes@gmail.com \
    --cc=peterx@redhat.com \
    --cc=riel@surriel.com \
    --cc=rientjes@google.com \
    --cc=rppt@linux.ibm.com \
    --cc=shakeelb@google.com \
    --cc=shy828301@gmail.com \
    --cc=torvalds@linux-foundation.org \
    --cc=willy@infradead.org \
    --cc=zhangliang5@huawei.com \
    /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.