From: Yury Norov <yury.norov@gmail.com>
To: Alexander Lobakin <alexandr.lobakin@intel.com>
Cc: Arnd Bergmann <arnd@arndb.de>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Richard Henderson <rth@twiddle.net>,
Matt Turner <mattst88@gmail.com>, Brian Cain <bcain@quicinc.com>,
Geert Uytterhoeven <geert@linux-m68k.org>,
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>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-alpha@vger.kernel.org, linux-hexagon@vger.kernel.org,
linux-ia64@vger.kernel.org, linux-m68k@lists.linux-m68k.org,
linux-sh@vger.kernel.org, sparclinux@vger.kernel.org,
linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/6] bitops: unify non-atomic bitops prototypes across architectures
Date: Mon, 6 Jun 2022 13:48:50 -0700 [thread overview]
Message-ID: <Yp5oMmzNlq+Ut4So@yury-laptop> (raw)
In-Reply-To: <20220606114908.962562-5-alexandr.lobakin@intel.com>
On Mon, Jun 06, 2022 at 01:49:05PM +0200, Alexander Lobakin 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
>
> 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 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>
> ---
Reviewed-by: Yury Norov <yury.norov@gmail.com>
[...]
> diff --git a/include/linux/bitops.h b/include/linux/bitops.h
> index 7aaed501f768..5520ac9b1c24 100644
> --- a/include/linux/bitops.h
> +++ b/include/linux/bitops.h
> @@ -26,12 +26,25 @@ extern unsigned int __sw_hweight16(unsigned int w);
> extern unsigned int __sw_hweight32(unsigned int w);
> extern unsigned long __sw_hweight64(__u64 w);
>
> +#include <asm-generic/bitops/generic-non-atomic.h>
> +
> /*
> * Include this here because some architectures need generic_ffs/fls in
> * scope
> */
> #include <asm/bitops.h>
>
> +/* Check that the bitops prototypes are sane */
> +#define __check_bitop_pr(name) static_assert(__same_type(name, gen_##name))
> +__check_bitop_pr(__set_bit);
> +__check_bitop_pr(__clear_bit);
> +__check_bitop_pr(__change_bit);
> +__check_bitop_pr(__test_and_set_bit);
> +__check_bitop_pr(__test_and_clear_bit);
> +__check_bitop_pr(__test_and_change_bit);
> +__check_bitop_pr(test_bit);
> +#undef __check_bitop_pr
This one is amazing trick! And the series is good overall. Do you want me to
take it in bitmap tree, when it's ready, or you'll move it somehow else?
Thanks,
Yury
next prev parent reply other threads:[~2022-06-06 20:59 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-06 11:49 [PATCH 0/6] bitops: let optimize out non-atomic bitops on compile-time constants Alexander Lobakin
2022-06-06 11:49 ` [PATCH 1/6] ia64, processor: fix -Wincompatible-pointer-types in ia64_get_irr() Alexander Lobakin
2022-06-06 11:49 ` [PATCH 2/6] bitops: always define asm-generic non-atomic bitops Alexander Lobakin
2022-06-06 12:44 ` Mark Rutland
2022-06-06 14:21 ` Alexander Lobakin
2022-06-06 11:49 ` [PATCH 3/6] bitops: define gen_test_bit() the same way as the rest of functions Alexander Lobakin
2022-06-06 16:19 ` Mark Rutland
2022-06-07 13:43 ` Marco Elver
2022-06-07 15:57 ` Alexander Lobakin
2022-06-07 16:15 ` Marco Elver
2022-06-07 16:28 ` Andy Shevchenko
2022-06-06 11:49 ` [PATCH 4/6] bitops: unify non-atomic bitops prototypes across architectures Alexander Lobakin
2022-06-06 16:25 ` Mark Rutland
2022-06-06 20:48 ` Yury Norov [this message]
2022-06-07 11:03 ` Alexander Lobakin
2022-06-06 11:49 ` [PATCH 5/6] bitops: wrap non-atomic bitops with a transparent macro Alexander Lobakin
2022-06-06 16:27 ` Mark Rutland
2022-06-07 10:57 ` Alexander Lobakin
2022-06-07 11:07 ` Alexander Lobakin
2022-06-06 11:49 ` [PATCH 6/6] bitops: let optimize out non-atomic bitops on compile-time constants Alexander Lobakin
2022-06-06 13:50 ` [PATCH 0/6] " Mark Rutland
2022-06-07 12:45 ` Geert Uytterhoeven
2022-06-07 15:47 ` Alexander Lobakin
2022-06-08 9:55 ` Geert Uytterhoeven
2022-06-08 13:31 ` 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=Yp5oMmzNlq+Ut4So@yury-laptop \
--to=yury.norov@gmail.com \
--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=geert@linux-m68k.org \
--cc=gregkh@linuxfoundation.org \
--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=mattst88@gmail.com \
--cc=peterz@infradead.org \
--cc=rth@twiddle.net \
--cc=sparclinux@vger.kernel.org \
--cc=tony.luck@intel.com \
--cc=ysato@users.sourceforge.jp \
/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).