All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.ibm.com>
To: Alexander Potapenko <glider@google.com>
Cc: hpa@zytor.com, peterz@infradead.org,
	linux-kernel@vger.kernel.org, dvyukov@google.com,
	jyknight@google.com, x86@kernel.org, mingo@redhat.com
Subject: Re: [PATCH] x86/asm: use memory clobber in bitops that touch arbitrary memory
Date: Mon, 1 Apr 2019 12:12:16 -0700	[thread overview]
Message-ID: <20190401191216.GP4102@linux.ibm.com> (raw)
In-Reply-To: <20190401162408.249668-1-glider@google.com>

On Mon, Apr 01, 2019 at 06:24:08PM +0200, Alexander Potapenko wrote:
> Certain bit operations that read/write bits take a base pointer and an
> arbitrarily large offset to address the bit relative to that base.
> Inline assembly constraints aren't expressive enough to tell the
> compiler that the assembly directive is going to touch a specific memory
> location of unknown size, therefore we have to use the "memory" clobber
> to indicate that the assembly is going to access memory locations other
> than those listed in the inputs/outputs.
> 
> This particular patch leads to size increase of 124 kernel functions in
> a defconfig build. For some of them the diff is in NOP operations, other
> end up re-reading values from memory and may potentially slow down the
> execution. But without these clobbers the compiler is free to cache
> the contents of the bitmaps and use them as if they weren't changed by
> the inline assembly.
> 
> Signed-off-by: Alexander Potapenko <glider@google.com>
> Cc: Dmitry Vyukov <dvyukov@google.com>
> Cc: Paul E. McKenney <paulmck@linux.ibm.com>
> Cc: H. Peter Anvin <hpa@zytor.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: James Y Knight <jyknight@google.com>

Reviewed-by: Paul E. McKenney <paulmck@linux.ibm.com>

> ---
>  arch/x86/include/asm/bitops.h | 14 +++++++-------
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/x86/include/asm/bitops.h b/arch/x86/include/asm/bitops.h
> index d153d570bb04..20e4950827d9 100644
> --- a/arch/x86/include/asm/bitops.h
> +++ b/arch/x86/include/asm/bitops.h
> @@ -111,7 +111,7 @@ clear_bit(long nr, volatile unsigned long *addr)
>  	} else {
>  		asm volatile(LOCK_PREFIX __ASM_SIZE(btr) " %1,%0"
>  			: BITOP_ADDR(addr)
> -			: "Ir" (nr));
> +			: "Ir" (nr) : "memory");
>  	}
>  }
>  
> @@ -131,7 +131,7 @@ static __always_inline void clear_bit_unlock(long nr, volatile unsigned long *ad
>  
>  static __always_inline void __clear_bit(long nr, volatile unsigned long *addr)
>  {
> -	asm volatile(__ASM_SIZE(btr) " %1,%0" : ADDR : "Ir" (nr));
> +	asm volatile(__ASM_SIZE(btr) " %1,%0" : ADDR : "Ir" (nr) : "memory");
>  }
>  
>  static __always_inline bool clear_bit_unlock_is_negative_byte(long nr, volatile unsigned long *addr)
> @@ -176,7 +176,7 @@ static __always_inline void __clear_bit_unlock(long nr, volatile unsigned long *
>   */
>  static __always_inline void __change_bit(long nr, volatile unsigned long *addr)
>  {
> -	asm volatile(__ASM_SIZE(btc) " %1,%0" : ADDR : "Ir" (nr));
> +	asm volatile(__ASM_SIZE(btc) " %1,%0" : ADDR : "Ir" (nr) : "memory");
>  }
>  
>  /**
> @@ -197,7 +197,7 @@ static __always_inline void change_bit(long nr, volatile unsigned long *addr)
>  	} else {
>  		asm volatile(LOCK_PREFIX __ASM_SIZE(btc) " %1,%0"
>  			: BITOP_ADDR(addr)
> -			: "Ir" (nr));
> +			: "Ir" (nr) : "memory");
>  	}
>  }
>  
> @@ -243,7 +243,7 @@ static __always_inline bool __test_and_set_bit(long nr, volatile unsigned long *
>  	asm(__ASM_SIZE(bts) " %2,%1"
>  	    CC_SET(c)
>  	    : CC_OUT(c) (oldbit), ADDR
> -	    : "Ir" (nr));
> +	    : "Ir" (nr) : "memory");
>  	return oldbit;
>  }
>  
> @@ -283,7 +283,7 @@ static __always_inline bool __test_and_clear_bit(long nr, volatile unsigned long
>  	asm volatile(__ASM_SIZE(btr) " %2,%1"
>  		     CC_SET(c)
>  		     : CC_OUT(c) (oldbit), ADDR
> -		     : "Ir" (nr));
> +		     : "Ir" (nr) : "memory");
>  	return oldbit;
>  }
>  
> @@ -326,7 +326,7 @@ static __always_inline bool variable_test_bit(long nr, volatile const unsigned l
>  	asm volatile(__ASM_SIZE(bt) " %2,%1"
>  		     CC_SET(c)
>  		     : CC_OUT(c) (oldbit)
> -		     : "m" (*(unsigned long *)addr), "Ir" (nr));
> +		     : "m" (*(unsigned long *)addr), "Ir" (nr) : "memory");
>  
>  	return oldbit;
>  }
> -- 
> 2.21.0.392.gf8f6787159e-goog
> 


  reply	other threads:[~2019-04-01 19:12 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-01 16:24 [PATCH] x86/asm: use memory clobber in bitops that touch arbitrary memory Alexander Potapenko
2019-04-01 19:12 ` Paul E. McKenney [this message]
2019-04-02  7:26 ` Peter Zijlstra
2019-04-02  8:59   ` Alexander Potapenko
2019-04-02 11:31     ` Alexander Potapenko

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=20190401191216.GP4102@linux.ibm.com \
    --to=paulmck@linux.ibm.com \
    --cc=dvyukov@google.com \
    --cc=glider@google.com \
    --cc=hpa@zytor.com \
    --cc=jyknight@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=x86@kernel.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.