All of lore.kernel.org
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: Michael Matz <matz@suse.de>, luto@amacapital.net
Cc: mingo@kernel.org, tglx@linutronix.de, oleg@redhat.com,
	brgerst@gmail.com, mcgrof@suse.com, dave.hansen@linux.intel.com,
	akpm@linux-foundation.org, dvlasenk@redhat.com,
	peterz@infradead.org, torvalds@linux-foundation.org,
	linux-kernel@vger.kernel.org, toshi.kani@hp.com, luto@kernel.org,
	aryabinin@virtuozzo.com, hpa@zytor.com,
	linux-tip-commits@vger.kernel.org
Subject: [PATCH -v1.1] x86/mm: Fix INVPCID asm constraint
Date: Wed, 10 Feb 2016 15:51:16 +0100	[thread overview]
Message-ID: <20160210145116.GF23914@pd.tnic> (raw)
In-Reply-To: <alpine.LSU.2.20.1602101439540.20277@wotan.suse.de>

On Wed, Feb 10, 2016 at 02:48:02PM +0100, Michael Matz wrote:
> Hi,
> 
> On Wed, 10 Feb 2016, Borislav Petkov wrote:
> 
> > --- a/arch/x86/include/asm/tlbflush.h
> > +++ b/arch/x86/include/asm/tlbflush.h
> > @@ -23,7 +23,7 @@ static inline void __invpcid(unsigned long pcid, unsigned long addr,
> >  	 * invpcid (%rcx), %rax in long mode.
> >  	 */
> >  	asm volatile (".byte 0x66, 0x0f, 0x38, 0x82, 0x01"
> > -		      : : "m" (desc), "a" (type), "c" (desc) : "memory");
> > +		      : : "m" (*desc), "a" (type), "c" (desc) : "memory");
> 
> That still doesn't do what you want.  Arrays in C are funny.  *desc is 
> exactly equivalent to desc[0], _not_ to the whole array,

Doh!

> indeed there's no C syntax to name an lvalue of array type in normal
> expressions. You need to jump through hoops for this:
>
>   "m" (*(struct {unsigned long x[2];} *)desc)

Aha! That's why we wrapped the array in clwb() in a struct too, btw:

static inline void clwb(volatile void *__p)
{
        volatile struct { char x[64]; } *p = __p;
	...

> It'd probably be easier to simply declare the descriptor as a struct, 
> rather than an array, then the original syntax would have been mostly 
> correct:
> 
>   struct {u64 d[2];} desc = { pcid, addr };
>   asm ... "m" (desc), "c" (&desc)

Sounds better. Done. How does that below look like?

Thanks Micha!

---
From: Borislav Petkov <bp@suse.de>
Date: Wed, 10 Feb 2016 12:53:48 +0100
Subject: [PATCH -v1.1] x86/mm: Fix INVPCID asm constraint
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

So we want to specify the dependency on both @pcid and @addr so that the
compiler doesn't reorder accesses to them *before* the TLB flush. But
for that to work, we need to express this properly in the inline asm and
deref the whole desc array, not the pointer to it. See clwb() for an
example.

This fixes the build error on 32-bit:

  arch/x86/include/asm/tlbflush.h: In function ‘__invpcid’:
  arch/x86/include/asm/tlbflush.h:26:18: error: memory input 0 is not directly addressable

which gcc4.7 caught but 5.x didn't. Which is strange. :-\

Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Luis R. Rodriguez <mcgrof@suse.com>
Cc: Michael Matz <matz@suse.de>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Toshi Kani <toshi.kani@hp.com>
Cc: linux-mm@kvack.org
---
 arch/x86/include/asm/tlbflush.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/tlbflush.h b/arch/x86/include/asm/tlbflush.h
index 6f9e27aa2aaf..c24b4224d439 100644
--- a/arch/x86/include/asm/tlbflush.h
+++ b/arch/x86/include/asm/tlbflush.h
@@ -11,7 +11,7 @@
 static inline void __invpcid(unsigned long pcid, unsigned long addr,
 			     unsigned long type)
 {
-	u64 desc[2] = { pcid, addr };
+	struct { u64 d[2]; } desc = { { pcid, addr } };
 
 	/*
 	 * The memory clobber is because the whole point is to invalidate
@@ -23,7 +23,7 @@ static inline void __invpcid(unsigned long pcid, unsigned long addr,
 	 * invpcid (%rcx), %rax in long mode.
 	 */
 	asm volatile (".byte 0x66, 0x0f, 0x38, 0x82, 0x01"
-		      : : "m" (desc), "a" (type), "c" (desc) : "memory");
+		      : : "m" (desc), "a" (type), "c" (&desc) : "memory");
 }
 
 #define INVPCID_TYPE_INDIV_ADDR		0
-- 
2.3.5

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.

  reply	other threads:[~2016-02-10 14:51 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-29 19:42 [PATCH v3 0/3] x86/mm: INVPCID support Andy Lutomirski
2016-01-29 19:42 ` Andy Lutomirski
2016-01-29 19:42 ` [PATCH v3 1/3] x86/mm: Add INVPCID helpers Andy Lutomirski
2016-01-29 19:42   ` Andy Lutomirski
2016-02-09 16:07   ` [tip:x86/mm] " tip-bot for Andy Lutomirski
2016-02-10 12:08     ` Borislav Petkov
2016-02-10 13:48       ` Michael Matz
2016-02-10 14:51         ` Borislav Petkov [this message]
2016-02-11  2:48           ` [PATCH -v1.1] x86/mm: Fix INVPCID asm constraint Andy Lutomirski
2016-01-29 19:42 ` [PATCH v3 2/3] x86/mm: Add a noinvpcid option to turn off INVPCID Andy Lutomirski
2016-01-29 19:42   ` Andy Lutomirski
2016-02-09 16:07   ` [tip:x86/mm] x86/mm: Add a 'noinvpcid' boot " tip-bot for Andy Lutomirski
2016-01-29 19:42 ` [PATCH v3 3/3] x86/mm: If INVPCID is available, use it to flush global mappings Andy Lutomirski
2016-01-29 19:42   ` Andy Lutomirski
2016-02-09 16:08   ` [tip:x86/mm] " tip-bot for Andy Lutomirski
2016-02-01 10:51 ` [PATCH v3 0/3] x86/mm: INVPCID support Borislav Petkov

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=20160210145116.GF23914@pd.tnic \
    --to=bp@alien8.de \
    --cc=akpm@linux-foundation.org \
    --cc=aryabinin@virtuozzo.com \
    --cc=brgerst@gmail.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=dvlasenk@redhat.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tip-commits@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=luto@kernel.org \
    --cc=matz@suse.de \
    --cc=mcgrof@suse.com \
    --cc=mingo@kernel.org \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=toshi.kani@hp.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.