public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: cdall@linaro.org (Christoffer Dall)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 3/6] kvm: arm64: Convert kvm_set_s2pte_readonly() from inline asm to cmpxchg()
Date: Wed, 2 Aug 2017 14:48:04 +0200	[thread overview]
Message-ID: <20170802124804.GL5176@cbox> (raw)
In-Reply-To: <20170802091536.xqhy7vcsamoa46ah@armageddon.cambridge.arm.com>

On Wed, Aug 02, 2017 at 10:15:36AM +0100, Catalin Marinas wrote:
> Hi Christoffer,
> 
> On Tue, Aug 01, 2017 at 01:16:18PM +0200, Christoffer Dall wrote:
> > On Tue, Jul 25, 2017 at 02:53:05PM +0100, Catalin Marinas wrote:
> > > +	pteval_t old_pteval, pteval;
> > > +
> > > +	do {
> > > +		pteval = old_pteval = READ_ONCE(pte_val(*pte));
> > > +		pteval &= ~PTE_S2_RDWR;
> > > +		pteval |= PTE_S2_RDONLY;
> > > +	} while (cmpxchg_relaxed(&pte_val(*pte), old_pteval, pteval) !=
> > > +		 old_pteval);
> > 
> > I'm wondering if the READ_ONCE for old_pteval is strictly necessary, or
> > if that's really for the pteval.  Actually, I'm a little unsure whether
> > this is equivalent to
> > 
> > 	old_pteval = READ_ONCE(pte_val(*pte));
> > 	pteval = old_pteval;
> > 
> > or
> > 
> > 	old_pteval = READ_ONCE(pte_val(*pte));
> > 	pteval = READ_ONCE(pte_val(*pte));
> > 
> > I think it's the former, which I also think is correct,
> 
> I think so too.
> 
> > but the reason
> > I'm going down this road is that we have a use of cmpxchg() in the VGIC
> > code, which doesn't use READ_ONCE for the old value (~
> > vgic-mmio-v3.c:404), and I also found other occurences of this in the
> > kernel, so I'm wondering if the VGIC code is broken or we're being
> > overly careful here, or if this is necessary because hardware can update
> > the value behind our backs in this case?
> 
> We use it because the compiler may decide it's short on registers and
> instead of saving old_pteval on the stack it reads it again from memory
> just before cmpxchg, so we would miss any update to *pte done by the
> hardware. In practice, I've never seen (on arm64) gcc generating two
> loads to *pte without READ_ONCE but maybe I haven't tried hard enough.
> 
> We should probably fix the VGIC code as well as a precaution, just in
> case the compiler tries to get smarter in the future.
> 

Sounds like a plan, I'll cook up a patch.

Thanks,
-Christoffer

  reply	other threads:[~2017-08-02 12:48 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-25 13:53 [PATCH 0/6] Rework the pte handling for hardware AF/DBM Catalin Marinas
2017-07-25 13:53 ` [PATCH 1/6] arm64: Fix potential race with hardware DBM in ptep_set_access_flags() Catalin Marinas
2017-08-01 17:03   ` Will Deacon
2017-08-02  9:01     ` Catalin Marinas
2017-07-25 13:53 ` [PATCH 2/6] arm64: Convert pte handling from inline asm to using (cmp)xchg Catalin Marinas
2017-08-17 12:59   ` Will Deacon
2017-08-18 16:15     ` Catalin Marinas
2017-07-25 13:53 ` [PATCH 3/6] kvm: arm64: Convert kvm_set_s2pte_readonly() from inline asm to cmpxchg() Catalin Marinas
2017-08-01 11:16   ` Christoffer Dall
2017-08-02  9:15     ` Catalin Marinas
2017-08-02 12:48       ` Christoffer Dall [this message]
2017-07-25 13:53 ` [PATCH 4/6] arm64: Move PTE_RDONLY bit handling out of set_pte_at() Catalin Marinas
2017-08-17 13:27   ` Will Deacon
2017-08-18 15:59     ` Catalin Marinas
2017-07-25 13:53 ` [PATCH 5/6] arm64: Ignore hardware dirty bit updates in ptep_set_wrprotect() Catalin Marinas
2017-08-17 13:37   ` Will Deacon
2017-08-18 15:58     ` Catalin Marinas
2017-07-25 13:53 ` [PATCH 6/6] arm64: Remove the CONFIG_ARM64_HW_AFDBM option Catalin Marinas
2017-08-17 13:31   ` Will Deacon
2017-08-18 15:54     ` Catalin Marinas
2017-08-16 17:16 ` [PATCH 0/6] Rework the pte handling for hardware AF/DBM Catalin Marinas

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=20170802124804.GL5176@cbox \
    --to=cdall@linaro.org \
    --cc=linux-arm-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox