All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jerome Glisse <jglisse@redhat.com>
To: Joel Fernandes <joelaf@google.com>
Cc: "open list:MEMORY MANAGEMENT" <linux-mm@kvack.org>,
	Jann Horn <jannh@google.com>,
	"Kirill A. Shutemov" <kirill@shutemov.name>,
	kirill.shutemov@linux.intel.com, Minchan Kim <minchan@kernel.org>,
	Ramon Pantin <pantin@google.com>
Subject: Re: Question about ptep_get_and_clear and TLB flush
Date: Mon, 29 Oct 2018 12:10:34 -0400	[thread overview]
Message-ID: <20181029161033.GA30742@redhat.com> (raw)
In-Reply-To: <CAJWu+oqnGC6FFZP5Trxh=WKHwAM3LM1c1mbhtJsh1yoh=ABi0g@mail.gmail.com>

On Thu, Oct 18, 2018 at 11:04:02PM -0700, Joel Fernandes wrote:
> Hello friends,
> I was trying to understand the safety of this piece of code in
> move_ptes in mremap.c
> Here we have some code that does this in a loop:
> 
> for (; old_addr < old_end; old_pte++, old_addr += PAGE_SIZE,
>  new_pte++, new_addr += PAGE_SIZE) {
>   if (pte_none(*old_pte))
>        continue;
>     pte = ptep_get_and_clear(mm, old_addr, old_pte);
>     if (pte_present(pte) && pte_dirty(pte))
>          force_flush = true;
>     pte = move_pte(pte, new_vma->vm_page_prot, old_addr, new_addr);
>     pte = move_soft_dirty_pte(pte);
>     set_pte_at(mm, new_addr, new_pte, pte);
> }
> 
> If I understand correctly, the ptep_get_and_clear is needed to
> atomically get and clear the page table entry so that we do not miss
> any other bits in PTE that may get set but have not been read, before
> we clear it. Such as the dirty bit.
> 
> My question is, After the ptep_get_and_clear runs, what happens if
> another CPU has a valid TLB entry for this old_addr and does a
> memory-write *before* the TLBs are flushed. Would that not cause us to
> lose the dirty bit? Once set_pte_at runs, it would be using the PTE
> fetched earlier which did not have the dirty bit set. This seems wrong
> to me. What do you think?
> 

https://yarchive.net/comp/linux/x86_tlb.html

      parent reply	other threads:[~2018-10-29 16:10 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-19  6:04 Question about ptep_get_and_clear and TLB flush Joel Fernandes
2018-10-21  3:33 ` Joel Fernandes
2018-10-29 16:10 ` Jerome Glisse [this message]

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=20181029161033.GA30742@redhat.com \
    --to=jglisse@redhat.com \
    --cc=jannh@google.com \
    --cc=joelaf@google.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=kirill@shutemov.name \
    --cc=linux-mm@kvack.org \
    --cc=minchan@kernel.org \
    --cc=pantin@google.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.