linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland@arm.com>
To: Matthias Kaehlcke <mka@chromium.org>
Cc: "Catalin Marinas" <catalin.marinas@arm.com>,
	"Will Deacon" <will.deacon@arm.com>,
	"Christoffer Dall" <christoffer.dall@linaro.org>,
	"Marc Zyngier" <marc.zyngier@arm.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Radim Krčmář" <rkrcmar@redhat.com>, "Tejun Heo" <tj@kernel.org>,
	"Christoph Lameter" <cl@linux.com>,
	"Vladimir Murzin" <vladimir.murzin@arm.com>,
	"Ard Biesheuvel" <ard.biesheuvel@linaro.org>,
	linux-arm-kernel@lists.infradead.org,
	kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	"Grant Grundler" <grundler@chromium.org>,
	"Greg Hackmann" <ghackmann@google.com>,
	"Michael Davidson" <md@google.com>
Subject: Re: [PATCH v2] arm64: Add ASM modifier for xN register operands
Date: Thu, 27 Apr 2017 12:02:56 +0100	[thread overview]
Message-ID: <20170427110256.GC31337@leverpostej> (raw)
In-Reply-To: <20170426214616.142580-1-mka@chromium.org>

Hi,

On Wed, Apr 26, 2017 at 02:46:16PM -0700, Matthias Kaehlcke wrote:
> Many inline assembly statements don't include the 'x' modifier when
> using xN registers as operands. This is perfectly valid, however it
> causes clang to raise warnings like this:
> 
> warning: value size does not match register size specified by the
>   constraint and modifier [-Wasm-operand-widths]
> ...
> arch/arm64/include/asm/barrier.h:62:23: note: expanded from macro
>   '__smp_store_release'
>     asm volatile ("stlr %1, %0"
> 
> Add the modifiers to keep clang happy.

If we're going to make this consistent, it would make sense to similarly
annotate 'w' regs. That will make it easier going forward to enforce a
policy that registers are suitably annotated.

Also, there's a risk that we silently mask a bug here, for which clang's
warning is legitimate, so we need to review this very carefully...

> 
> Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
> ---
> Changes in v2:
> - also add modifiers to multiline ASM statements in include/asm/
>   {atomic_ll_sc.h,irqflags.h,pgtable.h,uaccess.h,word-at-a-time.h}
>   that were missed on v1
> 
>  arch/arm64/include/asm/arch_gicv3.h     |  2 +-
>  arch/arm64/include/asm/atomic_ll_sc.h   | 36 ++++++++++++++++-----------------
>  arch/arm64/include/asm/barrier.h        |  4 ++--
>  arch/arm64/include/asm/io.h             | 24 +++++++++++-----------
>  arch/arm64/include/asm/irqflags.h       | 10 ++++-----
>  arch/arm64/include/asm/kvm_hyp.h        | 10 ++++-----
>  arch/arm64/include/asm/kvm_mmu.h        | 12 +++++------
>  arch/arm64/include/asm/percpu.h         |  4 ++--
>  arch/arm64/include/asm/pgtable.h        | 20 +++++++++---------
>  arch/arm64/include/asm/sysreg.h         |  4 ++--
>  arch/arm64/include/asm/uaccess.h        | 14 ++++++-------
>  arch/arm64/include/asm/word-at-a-time.h | 14 ++++++-------
>  arch/arm64/kernel/armv8_deprecated.c    |  4 ++--
>  arch/arm64/kernel/probes/kprobes.c      |  2 +-
>  arch/arm64/kvm/hyp/switch.c             |  4 ++--
>  15 files changed, 82 insertions(+), 82 deletions(-)

... to that end, could you split these into a few patches?

That way, knowledgeable people can focus their review on the code they
understand.

That doesn't need to be a patch per file; all the KVM bits can be
collated in one patch, for example. However, the atomics, kvm, and
uaccess+word-at-a-time bits should certainly be separate patches given
their (existing) complexity.

Otherwise, I have a couple of comments below.

> diff --git a/arch/arm64/include/asm/arch_gicv3.h b/arch/arm64/include/asm/arch_gicv3.h
> index f37e3a21f6e7..ba54e5bee885 100644
> --- a/arch/arm64/include/asm/arch_gicv3.h
> +++ b/arch/arm64/include/asm/arch_gicv3.h
> @@ -166,7 +166,7 @@ static inline void gic_write_sre(u32 val)
>  
>  static inline void gic_write_bpr1(u32 val)
>  {
> -	asm volatile("msr_s " __stringify(ICC_BPR1_EL1) ", %0" : : "r" (val));
> +	asm volatile("msr_s " __stringify(ICC_BPR1_EL1) ", %x0" : : "r" (val));
>  }

Please make this use write_sysreg_s() instead, i.e.

static inline void gic_write_bpr1(u32 val)
{
	write_sysreg_s(var, ICC_BPR1_EL1);
}

... that uses the 'x' modifier internally, and it's what we do for the
other GIC sysreg accesors.

This accessor was missed by commit:

  d44ffa5ae70a15a1 ("irqchip/gic-v3: Convert arm64 GIC accessors to {read,write}_sysreg_s")

... because it was added concurrently by commitL

  91ef84428a86b75a ("irqchip/gic-v3: Reset BPR during initialization")

... i.e. it was not deliberately omitted.

[...]

> -	asm volatile("strb %w0, [%1]" : : "rZ" (val), "r" (addr));
> +	asm volatile("strb %w0, [%x1]" : : "rZ" (val), "r" (addr));

In general, the '[%xN]' pattern looks *very* suspicious to me. Any
address must be 64-bit, so this would mask a legitimate warning.

Given the prototype of this function the code if fine either way, but
were we to refactor things (e.g. making this a macro), that might not be
true.

... so I'm not sure it make sense to alter instances used for addresses.

Thanks,
Mark.

  reply	other threads:[~2017-04-27 11:04 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-26 21:46 [PATCH v2] arm64: Add ASM modifier for xN register operands Matthias Kaehlcke
2017-04-27 11:02 ` Mark Rutland [this message]
2017-04-27 22:52   ` Matthias Kaehlcke
2017-04-28  7:18     ` Ard Biesheuvel
2017-04-28  9:53       ` Mark Rutland
2017-04-28 10:20         ` Ard Biesheuvel
2017-04-28 10:32           ` Mark Rutland
2017-04-28 14:33       ` Mark Rutland
2017-04-28 14:43         ` Ard Biesheuvel
2017-04-28 14:47           ` Will Deacon
2017-04-28 19:08         ` Matthias Kaehlcke

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=20170427110256.GC31337@leverpostej \
    --to=mark.rutland@arm.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=catalin.marinas@arm.com \
    --cc=christoffer.dall@linaro.org \
    --cc=cl@linux.com \
    --cc=ghackmann@google.com \
    --cc=grundler@chromium.org \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marc.zyngier@arm.com \
    --cc=md@google.com \
    --cc=mka@chromium.org \
    --cc=pbonzini@redhat.com \
    --cc=rkrcmar@redhat.com \
    --cc=tj@kernel.org \
    --cc=vladimir.murzin@arm.com \
    --cc=will.deacon@arm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).