All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anshuman Khandual <anshuman.khandual@arm.com>
To: Will Deacon <will@kernel.org>, Steve Capper <steve.capper@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	David Hildenbrand <david@redhat.com>,
	Mike Kravetz <mike.kravetz@oracle.com>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"Aneesh Kumar K . V" <aneesh.kumar@linux.ibm.com>,
	Peter Zijlstra <peterz@infradead.org>,
	nd@arm.com
Subject: Re: VM_BUG_ON(!tlb->end) on munmap() with CONT hugetlb pages
Date: Mon, 9 May 2022 16:49:25 +0530	[thread overview]
Message-ID: <84b579b2-7528-3d3c-02e4-29586791432f@arm.com> (raw)
In-Reply-To: <20220506124909.GA22892@willie-the-truck>



On 5/6/22 18:19, Will Deacon wrote:
> On Wed, Mar 23, 2022 at 04:34:26PM +0000, Steve Capper wrote:
>>
>>
>> On 23/03/2022 16:21, Catalin Marinas wrote:
>>> On Wed, Mar 23, 2022 at 11:51:25AM +0000, Steve Capper wrote:
>>>> On 22/03/2022 17:56, Catalin Marinas wrote:
>>>>> At a quick look, we wouldn't have a problem with missing TLB flushing
>>>>> since huge_ptep_get_and_clear() does this for contiguous PTEs. Not sure
>>>>> why it needs this though, Steve added it in commit d8bdcff28764. I think
>>>>> we can defer this flushing to tlb_remove_page_size().
>>>>
>>>> The TLB flush in huge_ptep_get_and_clear() was added because it was called
>>>> by hugetlb_change_protection() without any flushing. The concern was that,
>>>> without the flush, it would be possible to get to different views of the
>>>> same contiguous huge page. (Being contiguous they were not changed en masse
>>>> atomically).
>>>
>>> Maybe the code paths have been changed since but looking at
>>> hugetlb_change_protection(), we have huge_ptep_modify_prot_start()
>>> calling huge_ptep_get_and_clear() which AFAICT only needs to clear the
>>> ptes. huge_ptep_modify_prot_commit() calls set_huge_pte_at() which does
>>> another pte clearing + TLBI (clear_flush()) before setting the new ptes.
>>> So we do the pte clearing and TLBI twice already.
>>>
>>
>> Thanks, yeah indeed the code has changed and the flush should be removed
>> from the arm64 huge_ptep_get_and_clear.
> 
> Did anybody send a patch for this?

Planning to send a patch which drops TLB flushing from get_clear_flush() and
also renames it as required. Something like this but just slightly tested.

diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
index cbace1c9e137..acdaeb3b9356 100644
--- a/arch/arm64/mm/hugetlbpage.c
+++ b/arch/arm64/mm/hugetlbpage.c
@@ -166,7 +166,7 @@ static inline int num_contig_ptes(unsigned long size, size_t *pgsize)
  *
  * This helper performs the break step.
  */
-static pte_t get_clear_flush(struct mm_struct *mm,
+static pte_t get_clear_contig(struct mm_struct *mm,
                             unsigned long addr,
                             pte_t *ptep,
                             unsigned long pgsize,
@@ -190,11 +190,6 @@ static pte_t get_clear_flush(struct mm_struct *mm,
                if (pte_young(pte))
                        orig_pte = pte_mkyoung(orig_pte);
        }
-
-       if (valid) {
-               struct vm_area_struct vma = TLB_FLUSH_VMA(mm, 0);
-               flush_tlb_range(&vma, saddr, addr);
-       }
        return orig_pte;
 }
 
@@ -392,7 +387,7 @@ pte_t huge_ptep_get_and_clear(struct mm_struct *mm,
 
        ncontig = find_num_contig(mm, addr, ptep, &pgsize);
 
-       return get_clear_flush(mm, addr, ptep, pgsize, ncontig);
+       return get_clear_contig(mm, addr, ptep, pgsize, ncontig);
 }
 
 /*
@@ -443,7 +438,7 @@ int huge_ptep_set_access_flags(struct vm_area_struct *vma,
        if (!__cont_access_flags_changed(ptep, pte, ncontig))
                return 0;
 
-       orig_pte = get_clear_flush(vma->vm_mm, addr, ptep, pgsize, ncontig);
+       orig_pte = get_clear_contig(vma->vm_mm, addr, ptep, pgsize, ncontig);
 
        /* Make sure we don't lose the dirty or young state */
        if (pte_dirty(orig_pte))
@@ -476,7 +471,7 @@ void huge_ptep_set_wrprotect(struct mm_struct *mm,
        ncontig = find_num_contig(mm, addr, ptep, &pgsize);
        dpfn = pgsize >> PAGE_SHIFT;
 
-       pte = get_clear_flush(mm, addr, ptep, pgsize, ncontig);
+       pte = get_clear_contig(mm, addr, ptep, pgsize, ncontig);
        pte = pte_wrprotect(pte);
 
        hugeprot = pte_pgprot(pte);


  reply	other threads:[~2022-05-09 11:18 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-28 15:39 VM_BUG_ON(!tlb->end) on munmap() with CONT hugetlb pages David Hildenbrand
2022-03-01  0:26 ` Mike Kravetz
2022-03-07 23:06   ` Mike Kravetz
2022-03-21 16:34     ` David Hildenbrand
2022-03-22 17:56       ` Catalin Marinas
2022-03-23 11:51         ` Steve Capper
2022-03-23 16:21           ` Catalin Marinas
2022-03-23 16:34             ` Steve Capper
2022-03-23 17:21               ` Mike Kravetz
2022-05-06 12:49               ` Will Deacon
2022-05-09 11:19                 ` Anshuman Khandual [this message]
2022-05-09 12:11                   ` Catalin Marinas
2022-05-11  3:42                     ` Anshuman Khandual

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=84b579b2-7528-3d3c-02e4-29586791432f@arm.com \
    --to=anshuman.khandual@arm.com \
    --cc=aneesh.kumar@linux.ibm.com \
    --cc=catalin.marinas@arm.com \
    --cc=david@redhat.com \
    --cc=linux-mm@kvack.org \
    --cc=mike.kravetz@oracle.com \
    --cc=nd@arm.com \
    --cc=peterz@infradead.org \
    --cc=steve.capper@arm.com \
    --cc=will@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 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.