All of lore.kernel.org
 help / color / mirror / Atom feed
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Alexander Lobakin <alexandr.lobakin@intel.com>
Cc: Arnd Bergmann <arnd@arndb.de>, Yury Norov <yury.norov@gmail.com>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Matt Turner <mattst88@gmail.com>, Brian Cain <bcain@quicinc.com>,
	Yoshinori Sato <ysato@users.sourceforge.jp>,
	Rich Felker <dalias@libc.org>,
	"David S. Miller" <davem@davemloft.net>,
	Kees Cook <keescook@chromium.org>,
	"Peter Zijlstra (Intel)" <peterz@infradead.org>,
	Marco Elver <elver@google.com>, Borislav Petkov <bp@suse.de>,
	Tony Luck <tony.luck@intel.com>,
	Maciej Fijalkowski <maciej.fijalkowski@intel.com>,
	Jesse Brandeburg <jesse.brandeburg@intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	alpha <linux-alpha@vger.kernel.org>,
	"open list:QUALCOMM HEXAGON..." <linux-hexagon@vger.kernel.org>,
	"linux-ia64@vger.kernel.org" <linux-ia64@vger.kernel.org>,
	linux-m68k <linux-m68k@lists.linux-m68k.org>,
	Linux-sh list <linux-sh@vger.kernel.org>,
	sparclinux <sparclinux@vger.kernel.org>,
	Linux-Arch <linux-arch@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 3/7] bitops: unify non-atomic bitops prototypes across architectures
Date: Wed, 6 Jul 2022 12:07:33 +0200	[thread overview]
Message-ID: <CAMuHMdWqxqg7JubLK=KOX-V8JjoMbEKRPON+WhST=GKcjn8Y+w@mail.gmail.com> (raw)
In-Reply-To: <20220617144031.2549432-4-alexandr.lobakin@intel.com>

On Fri, Jun 17, 2022 at 7:09 PM Alexander Lobakin
<alexandr.lobakin@intel.com> wrote:
> Currently, there is a mess with the prototypes of the non-atomic
> bitops across the different architectures:
>
> ret     bool, int, unsigned long
> nr      int, long, unsigned int, unsigned long
> addr    volatile unsigned long *, volatile void *
>
> Thankfully, it doesn't provoke any bugs, but can sometimes make
> the compiler angry when it's not handy at all.
> Adjust all the prototypes to the following standard:
>
> ret     bool                            retval can be only 0 or 1
> nr      unsigned long                   native; signed makes no sense
> addr    volatile unsigned long *        bitmaps are arrays of ulongs
>
> Next, some architectures don't define 'arch_' versions as they don't
> support instrumentation, others do. To make sure there is always the
> same set of callables present and to ease any potential future
> changes, make them all follow the rule:
>  * architecture-specific files define only 'arch_' versions;
>  * non-prefixed versions can be defined only in asm-generic files;
> and place the non-prefixed definitions into a new file in
> asm-generic to be included by non-instrumented architectures.
>
> Finally, add some static assertions in order to prevent people from
> making a mess in this room again.
> I also used the %__always_inline attribute consistently, so that
> they always get resolved to the actual operations.
>
> Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Signed-off-by: Alexander Lobakin <alexandr.lobakin@intel.com>
> Acked-by: Mark Rutland <mark.rutland@arm.com>
> Reviewed-by: Yury Norov <yury.norov@gmail.com>

>  arch/m68k/include/asm/bitops.h                | 49 +++++++++++++------

Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

WARNING: multiple messages have this Message-ID (diff)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Alexander Lobakin <alexandr.lobakin@intel.com>
Cc: Arnd Bergmann <arnd@arndb.de>, Yury Norov <yury.norov@gmail.com>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Matt Turner <mattst88@gmail.com>, Brian Cain <bcain@quicinc.com>,
	Yoshinori Sato <ysato@users.sourceforge.jp>,
	Rich Felker <dalias@libc.org>,
	"David S. Miller" <davem@davemloft.net>,
	Kees Cook <keescook@chromium.org>,
	"Peter Zijlstra (Intel)" <peterz@infradead.org>,
	Marco Elver <elver@google.com>, Borislav Petkov <bp@suse.de>,
	Tony Luck <tony.luck@intel.com>,
	Maciej Fijalkowski <maciej.fijalkowski@intel.com>,
	Jesse Brandeburg <jesse.brandeburg@intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	alpha <linux-alpha@vger.kernel.org>,
	"open list:QUALCOMM HEXAGON..." <linux-hexagon@vger.kernel.org>,
	"linux-ia64@vger.kernel.org" <linux-ia64@vger.kernel.org>,
	linux-m68k <linux-m68k@lists.linux-m68k.org>,
	Linux-sh list <linux-sh@vger.kernel.org>,
	sparclinux <sparclinux@vger.kernel.org>,
	Linux-Arch <linux-arch@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 3/7] bitops: unify non-atomic bitops prototypes across architectures
Date: Wed, 06 Jul 2022 10:07:33 +0000	[thread overview]
Message-ID: <CAMuHMdWqxqg7JubLK=KOX-V8JjoMbEKRPON+WhST=GKcjn8Y+w@mail.gmail.com> (raw)
In-Reply-To: <20220617144031.2549432-4-alexandr.lobakin@intel.com>

On Fri, Jun 17, 2022 at 7:09 PM Alexander Lobakin
<alexandr.lobakin@intel.com> wrote:
> Currently, there is a mess with the prototypes of the non-atomic
> bitops across the different architectures:
>
> ret     bool, int, unsigned long
> nr      int, long, unsigned int, unsigned long
> addr    volatile unsigned long *, volatile void *
>
> Thankfully, it doesn't provoke any bugs, but can sometimes make
> the compiler angry when it's not handy at all.
> Adjust all the prototypes to the following standard:
>
> ret     bool                            retval can be only 0 or 1
> nr      unsigned long                   native; signed makes no sense
> addr    volatile unsigned long *        bitmaps are arrays of ulongs
>
> Next, some architectures don't define 'arch_' versions as they don't
> support instrumentation, others do. To make sure there is always the
> same set of callables present and to ease any potential future
> changes, make them all follow the rule:
>  * architecture-specific files define only 'arch_' versions;
>  * non-prefixed versions can be defined only in asm-generic files;
> and place the non-prefixed definitions into a new file in
> asm-generic to be included by non-instrumented architectures.
>
> Finally, add some static assertions in order to prevent people from
> making a mess in this room again.
> I also used the %__always_inline attribute consistently, so that
> they always get resolved to the actual operations.
>
> Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Signed-off-by: Alexander Lobakin <alexandr.lobakin@intel.com>
> Acked-by: Mark Rutland <mark.rutland@arm.com>
> Reviewed-by: Yury Norov <yury.norov@gmail.com>

>  arch/m68k/include/asm/bitops.h                | 49 +++++++++++++------

Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

WARNING: multiple messages have this Message-ID (diff)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Alexander Lobakin <alexandr.lobakin@intel.com>
Cc: Arnd Bergmann <arnd@arndb.de>, Yury Norov <yury.norov@gmail.com>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Matt Turner <mattst88@gmail.com>, Brian Cain <bcain@quicinc.com>,
	Yoshinori Sato <ysato@users.sourceforge.jp>,
	Rich Felker <dalias@libc.org>,
	"David S. Miller" <davem@davemloft.net>,
	Kees Cook <keescook@chromium.org>,
	"Peter Zijlstra (Intel)" <peterz@infradead.org>,
	Marco Elver <elver@google.com>, Borislav Petkov <bp@suse.de>,
	Tony Luck <tony.luck@intel.com>,
	Maciej Fijalkowski <maciej.fijalkowski@intel.com>,
	Jesse Brandeburg <jesse.brandeburg@intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	alpha <linux-alpha@vger.kernel.org>,
	"open list:QUALCOMM HEXAGON..." <linux-hexagon@vger.kernel.org>
Subject: Re: [PATCH v3 3/7] bitops: unify non-atomic bitops prototypes across architectures
Date: Wed, 6 Jul 2022 12:07:33 +0200	[thread overview]
Message-ID: <CAMuHMdWqxqg7JubLK=KOX-V8JjoMbEKRPON+WhST=GKcjn8Y+w@mail.gmail.com> (raw)
In-Reply-To: <20220617144031.2549432-4-alexandr.lobakin@intel.com>

On Fri, Jun 17, 2022 at 7:09 PM Alexander Lobakin
<alexandr.lobakin@intel.com> wrote:
> Currently, there is a mess with the prototypes of the non-atomic
> bitops across the different architectures:
>
> ret     bool, int, unsigned long
> nr      int, long, unsigned int, unsigned long
> addr    volatile unsigned long *, volatile void *
>
> Thankfully, it doesn't provoke any bugs, but can sometimes make
> the compiler angry when it's not handy at all.
> Adjust all the prototypes to the following standard:
>
> ret     bool                            retval can be only 0 or 1
> nr      unsigned long                   native; signed makes no sense
> addr    volatile unsigned long *        bitmaps are arrays of ulongs
>
> Next, some architectures don't define 'arch_' versions as they don't
> support instrumentation, others do. To make sure there is always the
> same set of callables present and to ease any potential future
> changes, make them all follow the rule:
>  * architecture-specific files define only 'arch_' versions;
>  * non-prefixed versions can be defined only in asm-generic files;
> and place the non-prefixed definitions into a new file in
> asm-generic to be included by non-instrumented architectures.
>
> Finally, add some static assertions in order to prevent people from
> making a mess in this room again.
> I also used the %__always_inline attribute consistently, so that
> they always get resolved to the actual operations.
>
> Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Signed-off-by: Alexander Lobakin <alexandr.lobakin@intel.com>
> Acked-by: Mark Rutland <mark.rutland@arm.com>
> Reviewed-by: Yury Norov <yury.norov@gmail.com>

>  arch/m68k/include/asm/bitops.h                | 49 +++++++++++++------

Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>

Gr{oetje,eeting}s,

                        Geert

  parent reply	other threads:[~2022-07-06 10:14 UTC|newest]

Thread overview: 93+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-19  9:20 [alobakin:bitops 3/7] block/elevator.c:222:9: sparse: sparse: cast from restricted req_flags_t kernel test robot
2022-06-17 14:40 ` [PATCH v3 0/7] bitops: let optimize out non-atomic bitops on compile-time constants Alexander Lobakin
2022-06-17 14:40   ` Alexander Lobakin
2022-06-17 14:40   ` Alexander Lobakin
2022-06-17 14:40   ` [PATCH v3 1/7] ia64, processor: fix -Wincompatible-pointer-types in ia64_get_irr() Alexander Lobakin
2022-06-17 14:40     ` Alexander Lobakin
2022-06-17 14:40     ` Alexander Lobakin
2022-06-17 14:40   ` [PATCH v3 2/7] bitops: always define asm-generic non-atomic bitops Alexander Lobakin
2022-06-17 14:40     ` Alexander Lobakin
2022-06-17 14:40     ` Alexander Lobakin
2022-06-20  9:49     ` Marco Elver
2022-06-20  9:49       ` Marco Elver
2022-06-20  9:49       ` Marco Elver
2022-06-17 14:40   ` [PATCH v3 3/7] bitops: unify non-atomic bitops prototypes across architectures Alexander Lobakin
2022-06-17 14:40     ` Alexander Lobakin
2022-06-17 14:40     ` Alexander Lobakin
2022-06-20 10:02     ` Andy Shevchenko
2022-06-20 10:02       ` Andy Shevchenko
2022-06-20 10:02       ` Andy Shevchenko
2022-07-06 10:07     ` Geert Uytterhoeven [this message]
2022-07-06 10:07       ` Geert Uytterhoeven
2022-07-06 10:07       ` Geert Uytterhoeven
2022-06-17 14:40   ` [PATCH v3 4/7] bitops: define const_*() versions of the non-atomics Alexander Lobakin
2022-06-17 14:40     ` Alexander Lobakin
2022-06-17 14:40     ` Alexander Lobakin
2022-06-20  9:49     ` Marco Elver
2022-06-20  9:49       ` Marco Elver
2022-06-20  9:49       ` Marco Elver
2022-06-20 10:03     ` Andy Shevchenko
2022-06-20 10:03       ` Andy Shevchenko
2022-06-20 10:03       ` Andy Shevchenko
2022-06-17 14:40   ` [PATCH v3 5/7] bitops: wrap non-atomic bitops with a transparent macro Alexander Lobakin
2022-06-17 14:40     ` Alexander Lobakin
2022-06-17 14:40     ` Alexander Lobakin
2022-06-20  9:50     ` Marco Elver
2022-06-20  9:50       ` Marco Elver
2022-06-20  9:50       ` Marco Elver
2022-06-20 10:08     ` Andy Shevchenko
2022-06-20 10:08       ` Andy Shevchenko
2022-06-20 10:08       ` Andy Shevchenko
2022-06-17 14:40   ` [PATCH v3 6/7] bitops: let optimize out non-atomic bitops on compile-time constants Alexander Lobakin
2022-06-17 14:40     ` Alexander Lobakin
2022-06-17 14:40     ` Alexander Lobakin
2022-06-20  9:51     ` Marco Elver
2022-06-20  9:51       ` Marco Elver
2022-06-20  9:51       ` Marco Elver
2022-06-20 10:05     ` Andy Shevchenko
2022-06-20 10:05       ` Andy Shevchenko
2022-06-20 10:05       ` Andy Shevchenko
2022-06-20 13:12       ` Alexander Lobakin
2022-06-20 13:12         ` Alexander Lobakin
2022-06-20 13:12         ` Alexander Lobakin
2022-06-17 14:40   ` [PATCH v3 7/7] lib: test_bitmap: add compile-time optimization/evaluations assertions Alexander Lobakin
2022-06-17 14:40     ` Alexander Lobakin
2022-06-17 14:40     ` Alexander Lobakin
2022-06-20 10:07     ` Andy Shevchenko
2022-06-20 10:07       ` Andy Shevchenko
2022-06-20 10:07       ` Andy Shevchenko
2022-06-20 12:07   ` [PATCH v3 0/7] bitops: let optimize out non-atomic bitops on compile-time constants Geert Uytterhoeven
2022-06-20 12:07     ` Geert Uytterhoeven
2022-06-20 12:07     ` Geert Uytterhoeven
2022-06-20 13:22     ` Alexander Lobakin
2022-06-20 13:22       ` Alexander Lobakin
2022-06-20 13:22       ` Alexander Lobakin
2022-06-20 13:51   ` [alobakin:bitops 3/7] block/elevator.c:222:9: sparse: sparse: cast from restricted req_flags_t Alexander Lobakin
2022-06-20 13:51     ` Alexander Lobakin
2022-06-20 13:51     ` Alexander Lobakin
2022-06-20 15:18     ` Andy Shevchenko
2022-06-20 15:18       ` Andy Shevchenko
2022-06-20 15:18       ` Andy Shevchenko
2022-06-20 15:18       ` Andy Shevchenko
2022-06-20 15:27       ` Alexander Lobakin
2022-06-20 15:27         ` Alexander Lobakin
2022-06-20 15:27         ` Alexander Lobakin
2022-06-20 19:21     ` Luc Van Oostenryck
2022-06-20 19:21       ` Luc Van Oostenryck
2022-06-20 19:21       ` Luc Van Oostenryck
2022-06-20 19:21       ` Luc Van Oostenryck
2022-06-20 14:19   ` [PATCH v3 0/7] bitops: let optimize out non-atomic bitops on compile-time constants Mark Rutland
2022-06-20 14:19     ` Mark Rutland
2022-06-20 14:19     ` Mark Rutland
2022-06-20 15:08     ` Alexander Lobakin
2022-06-20 15:08       ` Alexander Lobakin
2022-06-20 15:08       ` Alexander Lobakin
2022-06-21  6:03       ` Mark Rutland
2022-06-21  6:03         ` Mark Rutland
2022-06-21  6:03         ` Mark Rutland
2022-06-21 17:39       ` Yury Norov
2022-06-21 17:39         ` Yury Norov
2022-06-21 17:39         ` Yury Norov
2022-06-21 18:51         ` Alexander Lobakin
2022-06-21 18:51           ` Alexander Lobakin
2022-06-21 18:51           ` Alexander Lobakin

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='CAMuHMdWqxqg7JubLK=KOX-V8JjoMbEKRPON+WhST=GKcjn8Y+w@mail.gmail.com' \
    --to=geert@linux-m68k.org \
    --cc=alexandr.lobakin@intel.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=arnd@arndb.de \
    --cc=bcain@quicinc.com \
    --cc=bp@suse.de \
    --cc=dalias@libc.org \
    --cc=davem@davemloft.net \
    --cc=elver@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jesse.brandeburg@intel.com \
    --cc=keescook@chromium.org \
    --cc=linux-alpha@vger.kernel.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-hexagon@vger.kernel.org \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-m68k@lists.linux-m68k.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=maciej.fijalkowski@intel.com \
    --cc=mark.rutland@arm.com \
    --cc=mattst88@gmail.com \
    --cc=peterz@infradead.org \
    --cc=sparclinux@vger.kernel.org \
    --cc=tony.luck@intel.com \
    --cc=ysato@users.sourceforge.jp \
    --cc=yury.norov@gmail.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.