All of lore.kernel.org
 help / color / mirror / Atom feed
From: alankao@andestech.com (Alan Kao)
To: linux-riscv@lists.infradead.org
Subject: [sw-dev] About the Use of sfence.vma in Kernel
Date: Mon, 5 Nov 2018 08:49:29 +0800	[thread overview]
Message-ID: <20181105004929.GA4735@andestech.com> (raw)
In-Reply-To: <20181101090015.GA6997@andestech.com>

Hi Palmer,

I believe the code in arch/riscv/mm/fault.c is mostly from you.
Do you have any comments on this?

On Thu, Nov 01, 2018 at 05:00:15PM +0800, Alan Kao wrote:
> Hi all,
> 
> As mentioned in the Privileged Spec about sfence.vma instruction:
> 
> > The supervisor memory-management fence instruction SFENCE.VMA is used
> > to synchronize updates to in-memory memory-management data structures 
> > with current execution.  Instruction execution causes implicit reads 
> > and writes to these data structures;  however, these implicit references
> > are ordinarily not ordered with respect to loads and stores in the instruction
> > stream.
> >
> > Executing an SFENCE.VMA instruction guarantees that any stores in the
> > instruction stream prior to the SFENCE.VMA are ordered before all implicit
> > references subsequent to the SFENCE.VMA.
> 
> It naturally follows that we should use sfence.vma once the page table is
> modified.  There are several examples in the kernel already, such as
> 
> alloc_set_pte (in mm/memory.c):
> ...
>         set_pte_at(vma->vm_mm, vmf->address, vmf->pte, entry);
>         /* no need to invalidate: a not-present page won't be cached */
>         update_mmu_cache(vma, vmf->address, vmf->pte);
> ...
> where the update_mmu_cache function eventually issues a sfence.vma.
> 
> I was interested if it is always the case and did some research.  RV64 uses
> 3-level of page table entry, pud, pmd and pte, so I traced a little bit about
> the code flow after set_pud, set_pmd and set_pte.
> 
> It turns out that some of the calls to them are not followed by a
> sfence.vma.  For an instance, in the vmalloc_fault region in do_page_fault,
> there is no sfence.vma or calls to it after set_pgd, which directs to set_pud
> later.
> 
> Are they bugs or I just misunderstand the instruction?  As the kernel has
> already been stable for quite a while now, it is not likely to be a critical
> bug.
> 
> Any clarification will highly appreciated.
> 
> Many thanks,
> Alan Kao
> 
> -- 
> You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+unsubscribe at groups.riscv.org.
> To post to this group, send email to sw-dev at groups.riscv.org.
> Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.
> To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/20181101090015.GA6997%40andestech.com.

WARNING: multiple messages have this Message-ID (diff)
From: Alan Kao <alankao@andestech.com>
To: <palmer@sifive.com>
Cc: linux-riscv@lists.infradead.org, sw-dev@groups.riscv.org,
	greentime@andestech.com
Subject: Re: [sw-dev] About the Use of sfence.vma in Kernel
Date: Mon, 5 Nov 2018 08:49:29 +0800	[thread overview]
Message-ID: <20181105004929.GA4735@andestech.com> (raw)
Message-ID: <20181105004929.6tg7icdY2YsJVH5dlW3Cado-PQuE7Cx7H-KEjJ8t0JA@z> (raw)
In-Reply-To: <20181101090015.GA6997@andestech.com>

Hi Palmer,

I believe the code in arch/riscv/mm/fault.c is mostly from you.
Do you have any comments on this?

On Thu, Nov 01, 2018 at 05:00:15PM +0800, Alan Kao wrote:
> Hi all,
> 
> As mentioned in the Privileged Spec about sfence.vma instruction:
> 
> > The supervisor memory-management fence instruction SFENCE.VMA is used
> > to synchronize updates to in-memory memory-management data structures 
> > with current execution.  Instruction execution causes implicit reads 
> > and writes to these data structures;  however, these implicit references
> > are ordinarily not ordered with respect to loads and stores in the instruction
> > stream.
> >
> > Executing an SFENCE.VMA instruction guarantees that any stores in the
> > instruction stream prior to the SFENCE.VMA are ordered before all implicit
> > references subsequent to the SFENCE.VMA.
> 
> It naturally follows that we should use sfence.vma once the page table is
> modified.  There are several examples in the kernel already, such as
> 
> alloc_set_pte (in mm/memory.c):
> ...
>         set_pte_at(vma->vm_mm, vmf->address, vmf->pte, entry);
>         /* no need to invalidate: a not-present page won't be cached */
>         update_mmu_cache(vma, vmf->address, vmf->pte);
> ...
> where the update_mmu_cache function eventually issues a sfence.vma.
> 
> I was interested if it is always the case and did some research.  RV64 uses
> 3-level of page table entry, pud, pmd and pte, so I traced a little bit about
> the code flow after set_pud, set_pmd and set_pte.
> 
> It turns out that some of the calls to them are not followed by a
> sfence.vma.  For an instance, in the vmalloc_fault region in do_page_fault,
> there is no sfence.vma or calls to it after set_pgd, which directs to set_pud
> later.
> 
> Are they bugs or I just misunderstand the instruction?  As the kernel has
> already been stable for quite a while now, it is not likely to be a critical
> bug.
> 
> Any clarification will highly appreciated.
> 
> Many thanks,
> Alan Kao
> 
> -- 
> You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+unsubscribe@groups.riscv.org.
> To post to this group, send email to sw-dev@groups.riscv.org.
> Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.
> To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/20181101090015.GA6997%40andestech.com.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  reply	other threads:[~2018-11-05  0:49 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-01  9:00 About the Use of sfence.vma in Kernel Alan Kao
2018-11-01  9:00 ` Alan Kao
2018-11-05  0:49 ` Alan Kao [this message]
2018-11-05  0:49   ` [sw-dev] " Alan Kao
2018-11-06  2:33   ` Palmer Dabbelt
2018-11-06  2:33     ` Palmer Dabbelt
2018-11-06  7:49     ` Alan Kao
2018-11-06  7:49       ` Alan Kao
2018-11-06  8:03     ` Andreas Schwab
2018-11-06  8:03       ` Andreas Schwab
2018-11-07 15:51       ` Palmer Dabbelt
2018-11-07 15:51         ` Palmer Dabbelt
2018-11-06 10:46     ` Nick Kossifidis
2018-11-06 10:46       ` Nick Kossifidis

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=20181105004929.GA4735@andestech.com \
    --to=alankao@andestech.com \
    --cc=linux-riscv@lists.infradead.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.