All of lore.kernel.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 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.