Message-ID: <92caaf7b-92a6-8485-d53e-728c3aac30c3@redhat.com>
Date:   Thu, 17 Mar 2022 10:00:10 +0100
From:   David Hildenbrand <david@...hat.com>
To:     Yang Shi <shy828301@...il.com>
Cc:     linux-kernel@...r.kernel.org,
        Andrew Morton <akpm@...ux-foundation.org>,
        Hugh Dickins <hughd@...gle.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        David Rientjes <rientjes@...gle.com>,
        Shakeel Butt <shakeelb@...gle.com>,
        John Hubbard <jhubbard@...dia.com>,
        Jason Gunthorpe <jgg@...dia.com>,
        Mike Kravetz <mike.kravetz@...cle.com>,
        Mike Rapoport <rppt@...ux.ibm.com>,
        "Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>,
        Matthew Wilcox <willy@...radead.org>,
        Vlastimil Babka <vbabka@...e.cz>, Jann Horn <jannh@...gle.com>,
        Michal Hocko <mhocko@...nel.org>,
        Nadav Amit <namit@...are.com>, Rik van Riel <riel@...riel.com>,
        Roman Gushchin <guro@...com>,
        Andrea Arcangeli <aarcange@...hat.com>,
        Peter Xu <peterx@...hat.com>,
        Donald Dutile <ddutile@...hat.com>,
        Christoph Hellwig <hch@....de>,
        Oleg Nesterov <oleg@...hat.com>, Jan Kara <jack@...e.cz>,
        Liang Zhang <zhangliang5@...wei.com>,
        Pedro Gomes <pedrodemargomes@...il.com>,
        Oded Gabbay <oded.gabbay@...il.com>, linux-mm@...ck.org
Subject: Re: [PATCH v2 04/15] mm/rmap: split page_dup_rmap() into
 page_dup_file_rmap() and page_try_dup_anon_rmap()

On 16.03.22 21:02, Yang Shi wrote:
> On Tue, Mar 15, 2022 at 3:50 AM David Hildenbrand <david@...hat.com> wrote:
>>
>> ... and move the special check for pinned pages into
>> page_try_dup_anon_rmap() to prepare for tracking exclusive anonymous
>> pages via a new pageflag, clearing it only after making sure that there
>> are no GUP pins on the anonymous page.
>>
>> We really only care about pins on anonymous pages, because they are
>> prone to getting replaced in the COW handler once mapped R/O. For !anon
>> pages in cow-mappings (!VM_SHARED && VM_MAYWRITE) we shouldn't really
>> care about that, at least not that I could come up with an example.
>>
>> Let's drop the is_cow_mapping() check from page_needs_cow_for_dma(), as we
>> know we're dealing with anonymous pages. Also, drop the handling of
>> pinned pages from copy_huge_pud() and add a comment if ever supporting
>> anonymous pages on the PUD level.
>>
>> This is a preparation for tracking exclusivity of anonymous pages in
>> the rmap code, and disallowing marking a page shared (-> failing to
>> duplicate) if there are GUP pins on a page.
>>
>> RFC notes: if I'm missing something important for !anon pages, we could
>>            similarly handle it via page_try_dup_file_rmap().
>>
>> Signed-off-by: David Hildenbrand <david@...hat.com>
>> ---
>>  include/linux/mm.h   |  5 +----
>>  include/linux/rmap.h | 48 +++++++++++++++++++++++++++++++++++++++++++-
>>  mm/huge_memory.c     | 27 ++++++++-----------------
>>  mm/hugetlb.c         | 16 ++++++++-------
>>  mm/memory.c          | 17 +++++++++++-----
>>  mm/migrate.c         |  2 +-
>>  6 files changed, 78 insertions(+), 37 deletions(-)
>>
>> diff --git a/include/linux/mm.h b/include/linux/mm.h
>> index 391b950e919d..63ee06001189 100644
>> --- a/include/linux/mm.h
>> +++ b/include/linux/mm.h
>> @@ -1322,16 +1322,13 @@ static inline bool is_cow_mapping(vm_flags_t flags)
>>
>>  /*
>>   * This should most likely only be called during fork() to see whether we
>> - * should break the cow immediately for a page on the src mm.
>> + * should break the cow immediately for an anon page on the src mm.
>>   *
>>   * The caller has to hold the PT lock and the vma->vm_mm->->write_protect_seq.
>>   */
>>  static inline bool page_needs_cow_for_dma(struct vm_area_struct *vma,
>>                                           struct page *page)
>>  {
>> -       if (!is_cow_mapping(vma->vm_flags))
>> -               return false;
>> -
>>         VM_BUG_ON(!(raw_read_seqcount(&vma->vm_mm->write_protect_seq) & 1));
>>
>>         if (!test_bit(MMF_HAS_PINNED, &vma->vm_mm->flags))
>> diff --git a/include/linux/rmap.h b/include/linux/rmap.h
>> index e704b1a4c06c..92c3585b8c6a 100644
>> --- a/include/linux/rmap.h
>> +++ b/include/linux/rmap.h
>> @@ -180,11 +180,57 @@ void hugepage_add_anon_rmap(struct page *, struct vm_area_struct *,
>>  void hugepage_add_new_anon_rmap(struct page *, struct vm_area_struct *,
>>                                 unsigned long);
>>
>> -static inline void page_dup_rmap(struct page *page, bool compound)
>> +static inline void __page_dup_rmap(struct page *page, bool compound)
>>  {
>>         atomic_inc(compound ? compound_mapcount_ptr(page) : &page->_mapcount);
>>  }
>>
>> +static inline void page_dup_file_rmap(struct page *page, bool compound)
>> +{
>> +       __page_dup_rmap(page, compound);
>> +}
>> +
>> +/**
>> + * page_try_dup_anon_rmap - try duplicating a mapping of an already mapped
>> + *                         anonymous page
>> + * @page: the page to duplicate the mapping for
>> + * @compound: the page is mapped as compound or as a small page
>> + * @vma: the source vma
>> + *
>> + * The caller needs to hold the PT lock and the vma->vma_mm->write_protect_seq.
>> + *
>> + * Duplicating the mapping can only fail if the page may be pinned; device
>> + * private pages cannot get pinned and consequently this function cannot fail.
>> + *
>> + * If duplicating the mapping succeeds, the page has to be mapped R/O into
>> + * the parent and the child. It must *not* get mapped writable after this call.
>> + *
>> + * Returns 0 if duplicating the mapping succeeded. Returns -EBUSY otherwise.
>> + */
>> +static inline int page_try_dup_anon_rmap(struct page *page, bool compound,
>> +                                        struct vm_area_struct *vma)
>> +{
>> +       VM_BUG_ON_PAGE(!PageAnon(page), page);
>> +
>> +       /*
>> +        * If this page may have been pinned by the parent process,
>> +        * don't allow to duplicate the mapping but instead require to e.g.,
>> +        * copy the page immediately for the child so that we'll always
>> +        * guarantee the pinned page won't be randomly replaced in the
>> +        * future on write faults.
>> +        */
>> +       if (likely(!is_device_private_page(page) &&
>> +           unlikely(page_needs_cow_for_dma(vma, page))))
>> +               return -EBUSY;
>> +
>> +       /*
>> +        * It's okay to share the anon page between both processes, mapping
>> +        * the page R/O into both processes.
>> +        */
>> +       __page_dup_rmap(page, compound);
>> +       return 0;
>> +}
>> +
>>  /*
>>   * Called from mm/vmscan.c to handle paging out
>>   */
>> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
>> index cda88d8ac1bd..c126d728b8de 100644
>> --- a/mm/huge_memory.c
>> +++ b/mm/huge_memory.c
>> @@ -1097,23 +1097,16 @@ int copy_huge_pmd(struct mm_struct *dst_mm, struct mm_struct *src_mm,
>>         src_page = pmd_page(pmd);
>>         VM_BUG_ON_PAGE(!PageHead(src_page), src_page);
>>
>> -       /*
>> -        * If this page is a potentially pinned page, split and retry the fault
>> -        * with smaller page size.  Normally this should not happen because the
>> -        * userspace should use MADV_DONTFORK upon pinned regions.  This is a
>> -        * best effort that the pinned pages won't be replaced by another
>> -        * random page during the coming copy-on-write.
>> -        */
>> -       if (unlikely(page_needs_cow_for_dma(src_vma, src_page))) {
>> +       get_page(src_page);
>> +       if (unlikely(page_try_dup_anon_rmap(src_page, true, src_vma))) {
>> +               /* Page maybe pinned: split and retry the fault on PTEs. */
>> +               put_page(src_page);
> 
> Do we have to do the get_page()/put_page() sequence? It seems we don't
> have to get the page before calling page_try_dup_anon_rmap(), right?
> We just need to bump page refcount when dupping rmap successfully. So
> we could do:
> 
> if (unlikely(page_try_dup_anon_rmap(src_page, true, src_vma))) {
>     /* do something */
> }
> 
> get_page(src_page)

I refrained from doing that in this series because I wasn't able to
convince myself that it is completely sane.

Increasing the refcount before the mapcount here results in an
interesting property (when unmap is done similarly, in reverse order):
reading a snapshot of page_count()+mapcount() at a random point in
time guarantees that page_count() >= mapcount.

Now, the issue I see with changing that is the following: We seem
to have some code that tries detecting additional references on a
mapped page. While such checks can deal with false positives ("there
is an additional reference"), false negatives ("these is no
additional reference") could be bad.

One example I stumbled over is KSM code:


		/*
		 * Check that no O_DIRECT or similar I/O is in progress on the
		 * page
		 */
		if (page_mapcount(page) + 1 + swapped != page_count(page)) {
			set_pte_at(mm, pvmw.address, pvmw.pte, entry);
			goto out_unlock;
		}


Imagine there is an additional reference but another process sharing the
page did the mapcount++ but not the refcount++ yet. You'd get a false negative.


Now, I'm not sure if there is anything else protecting us from this,
however, it rather made me be very careful about changing the order
of things here. So in the context of this patch, I won't be messing with
the order.

Thanks!

-- 
Thanks,

David / dhildenb

Powered by blists - more mailing lists