linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Frederic Weisbecker <fweisbec@gmail.com>
To: Ingo Molnar <mingo@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH v2] atomic: Fix bugs in 'fetch_or()' and rename it to 'xchg_or()'
Date: Tue, 15 Mar 2016 18:08:37 +0100	[thread overview]
Message-ID: <20160315170835.GA5058@lerouge> (raw)
In-Reply-To: <20160315122145.GA7225@gmail.com>


Thanks a lot for fixing this!
Some comments below:

On Tue, Mar 15, 2016 at 01:21:45PM +0100, Ingo Molnar wrote:
> Linus noticed a couple of problems with the fetch_or() implementation introduced
> by 5fd7a09cfb8c ("atomic: Export fetch_or()"):
> 
>  - Sloppy macro implementation: 'mask' and 'ptr' is evaluated multiple times,
>    which will break if arguments have side effects. Also, it uses 
>    double-underscore temporary variables - which is dangerous as low level asm 
>    ones are using those too and they may alias in unexpected ways.
> 
>  - Sloppy semantics: the naming and structure of the macro is ambigious, with
>    no well-defined semantics. It's neither an atomic nor a cmpxchg() interface,
>    but still it lives in include/linux/atomic.h.
> 
> Solve this by:
> 
>  - Extracting the arguments into helper variables once, and never
>    using the original arguments from that point on. This makes it
>    pretty clear that there can be no unwanted macro evaluation
>    side effects.
> 
>  - Using single-underscore temporary variables.
> 
>  - Renaming fetch_or() to xchg_or(), recognizing that the semantics
>    are xchg()-alike.

I wouldn't mind that much having xchg_or() but I think Peterz has good arguments in favour
of keeping the original name.

> 
> Also propagate the rename to the call sites.
> 
> Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Chris Metcalf <cmetcalf@ezchip.com>
> Cc: Christoph Lameter <cl@linux.com>
> Cc: Frederic Weisbecker <fweisbec@gmail.com>
> Cc: Luiz Capitulino <lcapitulino@redhat.com>
> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Rik van Riel <riel@redhat.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Viresh Kumar <viresh.kumar@linaro.org>
> Link: http://lkml.kernel.org/r/20160315093245.GA7943@gmail.com
> Signed-off-by: Ingo Molnar <mingo@kernel.org>
> ---
>  include/linux/atomic.h   | 26 ++++++++++++++++----------
>  kernel/sched/core.c      |  2 +-
>  kernel/time/tick-sched.c |  4 ++--
>  3 files changed, 19 insertions(+), 13 deletions(-)
> 
> diff --git a/include/linux/atomic.h b/include/linux/atomic.h
> index 6c502cb13c95..7bc5297bcca8 100644
> --- a/include/linux/atomic.h
> +++ b/include/linux/atomic.h
> @@ -549,22 +549,28 @@ static inline int atomic_dec_if_positive(atomic_t *v)
>  #endif
>  
>  /**
> - * fetch_or - perform *ptr |= mask and return old value of *ptr
> - * @ptr: pointer to value
> + * xchg_or - perform *ptr |= mask atomically and return old value of *ptr
> + * @ptr: pointer to value (cmpxchg() compatible integer pointer type)
>   * @mask: mask to OR on the value
>   *
> - * cmpxchg based fetch_or, macro so it works for different integer types
> + * cmpxchg() based, it's a macro so it works for different integer types.
>   */
> -#ifndef fetch_or
> -#define fetch_or(ptr, mask)						\
> -({	typeof(*(ptr)) __old, __val = *(ptr);				\
> +#ifndef xchg_or
> +# define xchg_or(ptr, mask)						\
> +({									\
> +	typeof(ptr)  _ptr  = (ptr);					\

Can we add a comment above to prevent from future mistakes with cmpxchg
variables aliasing?

I'm suprised that GCC doesn't warn about that actually.

  parent reply	other threads:[~2016-03-15 17:08 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-14 12:32 [GIT PULL] NOHZ updates for v4.6 Ingo Molnar
2016-03-15  2:44 ` Linus Torvalds
2016-03-15  8:42   ` Peter Zijlstra
2016-03-15  9:49     ` Ingo Molnar
2016-03-15  9:32   ` [PATCH] atomic: Fix bugs in 'fetch_or()' and rename it to 'xchg_or()' Ingo Molnar
2016-03-15 10:50     ` Peter Zijlstra
2016-03-15 12:08       ` Ingo Molnar
2016-03-15 12:42         ` Peter Zijlstra
2016-03-15 11:06     ` Peter Zijlstra
2016-03-15 11:59     ` Peter Zijlstra
2016-03-15 12:01     ` Ingo Molnar
2016-03-15 12:32       ` Ingo Molnar
2016-03-15 12:37         ` Ingo Molnar
2016-03-15 13:17         ` Peter Zijlstra
2016-03-15 12:21     ` [PATCH v2] " Ingo Molnar
2016-03-15 13:26       ` Peter Zijlstra
2016-03-16  8:04         ` Ingo Molnar
2016-03-16  8:29           ` Peter Zijlstra
2016-03-15 17:08       ` Frederic Weisbecker [this message]
2016-03-16  8:14         ` Ingo Molnar
2016-03-17  0:54           ` Frederic Weisbecker
2016-03-15 16:18     ` [PATCH] " Linus Torvalds
2016-03-15  9:53   ` [PATCH] nohz: Change tick_dep_mask from 'unsigned long' to 'unsigned int' Ingo Molnar
2016-03-15 12:15     ` Ingo Molnar
2016-03-15 16:30       ` Linus Torvalds
2016-03-15 17:28         ` Frederic Weisbecker
2016-03-15 17:36           ` Linus Torvalds

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=20160315170835.GA5058@lerouge \
    --to=fweisbec@gmail.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.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;
as well as URLs for NNTP newsgroup(s).