dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Lucas De Marchi <lucas.demarchi@intel.com>
To: Gustavo Sousa <gustavo.sousa@intel.com>
Cc: "Christian König" <christian.koenig@amd.com>,
	intel-gfx@lists.freedesktop.org,
	"Kevin Brodsky" <kevin.brodsky@arm.com>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	intel-xe@lists.freedesktop.org,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Alex Deucher" <alexander.deucher@amd.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
	"Masahiro Yamada" <masahiroy@kernel.org>
Subject: Re: [Intel-xe] [PATCH 2/3] linux/bits.h: Add fixed-width GENMASK and BIT macros
Date: Tue, 9 May 2023 14:34:51 -0700	[thread overview]
Message-ID: <iakuowef3ysobpcpa6f74kolw44zyjepb5byjxljp4mxuwunkn@rdegvnuzbnmi> (raw)
In-Reply-To: <168364083689.27719.2337781022536351304@gjsousa-mobl2>

On Tue, May 09, 2023 at 11:00:36AM -0300, Gustavo Sousa wrote:
>Quoting Lucas De Marchi (2023-05-09 02:14:02)
>>Add GENMASK_U32(), GENMASK_U16() and GENMASK_U8()  macros to create
>>masks for fixed-width types and also the corresponding BIT_U32(),
>>BIT_U16() and BIT_U8().
>>
>>All of those depend on a new "U" suffix added to the integer constant.
>>Due to naming clashes it's better to call the macro U32. Since C doesn't
>>have a proper suffix for short and char types, the U16 and U18 variants
>>just use U32 with one additional check in the BIT_* macros to make
>>sure the compiler gives an error when the those types overflow.
>>The BIT_U16() and BIT_U8() need the help of GENMASK_INPUT_CHECK(),
>>as otherwise they would allow an invalid bit to be passed. Hence
>>implement them in include/linux/bits.h rather than together with
>>the other BIT* variants.
>>
>>The following test file is is used to test this:
>>
>>        $ cat mask.c
>>        #include <linux/types.h>
>>        #include <linux/bits.h>
>>
>>        static const u32 a = GENMASK_U32(31, 0);
>>        static const u16 b = GENMASK_U16(15, 0);
>>        static const u8 c = GENMASK_U8(7, 0);
>>        static const u32 x = BIT_U32(31);
>>        static const u16 y = BIT_U16(15);
>>        static const u8 z = BIT_U8(7);
>>
>>        #if FAIL
>>        static const u32 a2 = GENMASK_U32(32, 0);
>>        static const u16 b2 = GENMASK_U16(16, 0);
>>        static const u8 c2 = GENMASK_U8(8, 0);
>>        static const u32 x2 = BIT_U32(32);
>>        static const u16 y2 = BIT_U16(16);
>>        static const u8 z2 = BIT_U8(8);
>>        #endif
>>
>>Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
>>---
>> include/linux/bits.h       | 22 ++++++++++++++++++++++
>> include/uapi/linux/const.h |  2 ++
>> include/vdso/const.h       |  1 +
>> 3 files changed, 25 insertions(+)
>>
>>diff --git a/include/linux/bits.h b/include/linux/bits.h
>>index 7c0cf5031abe..ff4786c99b8c 100644
>>--- a/include/linux/bits.h
>>+++ b/include/linux/bits.h
>>@@ -42,4 +42,26 @@
>> #define GENMASK_ULL(h, l) \
>>        (GENMASK_INPUT_CHECK(h, l) + __GENMASK_ULL(h, l))
>>
>>+#define __GENMASK_U32(h, l) \
>>+  (((~U32(0)) - (U32(1) << (l)) + 1) & \
>>+   (~U32(0) >> (32 - 1 - (h))))
>>+#define GENMASK_U32(h, l) \
>>+  (GENMASK_INPUT_CHECK(h, l) + __GENMASK_U32(h, l))
>>+
>>+#define __GENMASK_U16(h, l) \
>>+  ((U32(0xffff) - (U32(1) << (l)) + 1) & \
>>+   (U32(0xffff) >> (16 - 1 - (h))))
>>+#define GENMASK_U16(h, l) \
>>+  (GENMASK_INPUT_CHECK(h, l) + __GENMASK_U16(h, l))
>>+
>>+#define __GENMASK_U8(h, l) \
>>+  (((U32(0xff)) - (U32(1) << (l)) + 1) & \
>>+   (U32(0xff) >> (8 - 1 - (h))))
>>+#define GENMASK_U8(h, l) \
>>+  (GENMASK_INPUT_CHECK(h, l) + __GENMASK_U8(h, l))
>
>I wonder if we should use BIT_U* variants in the above to ensure the values are
>valid. If so, we get a nice boundary check and we also can use a single
>definition for the mask generation:
>
>  #define __GENMASK_U32(h, l) \
>          (((~U32(0)) - (U32(1) << (l)) + 1) & \
>           (~U32(0) >> (32 - 1 - (h))))

the boundary for h and l are already covered here because (32 - 1 - (h))
would lead to a negative value if h >= 32. Similar reason for l

Doing ~U32(0) didn't work for me as it wouldn't catch the invalid values
due to expanding to U32_MAX


>  #define GENMASK_U32(h, l) \
>          (GENMASK_INPUT_CHECK(h, l) + __GENMASK_U32(BIT_U32(h), BIT_U32(l)))

							^^^^
that doesn't really work as BIT_U32(h) would expand here,
creating the equivalent of

	~U32(0) >> (32 - 1 - (BIT_U32(h))),

which is not what we want

>  #define GENMASK_U16(h, l) \
>          (GENMASK_INPUT_CHECK(h, l) + __GENMASK_U32(BIT_U16(h), BIT_U16(l)))
>  #define GENMASK_U8(h, l) \
>          (GENMASK_INPUT_CHECK(h, l) + __GENMASK_U32(BIT_U8(h), BIT_U8(l)))
>
>>+
>>+#define BIT_U32(nr)       _BITU32(nr)
>>+#define BIT_U16(nr)       (GENMASK_INPUT_CHECK(16 - 1, nr) + (U32(1) << (nr)))
>>+#define BIT_U8(nr)        (GENMASK_INPUT_CHECK(32 - 1, nr) + (U32(1) << (nr)))
>
>Shouldn't this be GENMASK_INPUT_CHECK(8 - 1, nr)?

ugh, good catch. Thanks

I will think if I can come up with something that reuses a single
__GENMASK_U(). Meanwhile I improved my negative tests to cover more
cases.

Lucas De Marchi



>
>--
>Gustavo Sousa
>
>>+
>> #endif /* __LINUX_BITS_H */
>>diff --git a/include/uapi/linux/const.h b/include/uapi/linux/const.h
>>index a429381e7ca5..3a4e152520f4 100644
>>--- a/include/uapi/linux/const.h
>>+++ b/include/uapi/linux/const.h
>>@@ -22,9 +22,11 @@
>> #define _AT(T,X)       ((T)(X))
>> #endif
>>
>>+#define _U32(x)           (_AC(x, U))
>> #define _UL(x)         (_AC(x, UL))
>> #define _ULL(x)                (_AC(x, ULL))
>>
>>+#define _BITU32(x)        (_U32(1) << (x))
>> #define _BITUL(x)      (_UL(1) << (x))
>> #define _BITULL(x)     (_ULL(1) << (x))
>>
>>diff --git a/include/vdso/const.h b/include/vdso/const.h
>>index 94b385ad438d..417384a9795b 100644
>>--- a/include/vdso/const.h
>>+++ b/include/vdso/const.h
>>@@ -4,6 +4,7 @@
>>
>> #include <uapi/linux/const.h>
>>
>>+#define U32(x)            (_U32(x))
>> #define UL(x)          (_UL(x))
>> #define ULL(x)         (_ULL(x))
>>
>>--
>>2.40.1
>>

  reply	other threads:[~2023-05-09 21:35 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-09  5:14 [PATCH 0/3] Fixed-width mask/bit helpers Lucas De Marchi
2023-05-09  5:14 ` [PATCH 1/3] drm/amd: Remove wrapper macros over get_u{32,16,8} Lucas De Marchi
2023-05-09  5:14 ` [PATCH 2/3] linux/bits.h: Add fixed-width GENMASK and BIT macros Lucas De Marchi
2023-05-09 14:00   ` [Intel-xe] " Gustavo Sousa
2023-05-09 21:34     ` Lucas De Marchi [this message]
2023-05-10 12:18   ` kernel test robot
2023-05-12 11:14   ` Andy Shevchenko
2023-05-12 11:25     ` Jani Nikula
2023-05-12 11:32       ` Andy Shevchenko
2023-05-12 11:45         ` Jani Nikula
2023-06-15 15:53           ` Andy Shevchenko
2023-06-20 14:47             ` Jani Nikula
2023-06-20 14:55               ` Andy Shevchenko
2023-06-20 17:25                 ` [Intel-xe] " Lucas De Marchi
2023-06-20 17:41                   ` Andy Shevchenko
2023-06-20 18:02                     ` Lucas De Marchi
2023-06-20 18:19                     ` Jani Nikula
2023-05-12 16:29     ` Lucas De Marchi
2023-06-15 15:58       ` Andy Shevchenko
2023-06-22  2:20   ` Yury Norov
2023-06-22  6:15     ` Lucas De Marchi
2023-06-22 14:59       ` Yury Norov
2024-01-18 20:42     ` Re: [Intel-xe] " Lucas De Marchi
2024-01-18 21:48       ` Yury Norov
2024-01-18 23:25         ` Lucas De Marchi
2024-01-19  2:01           ` Yury Norov
2024-01-19 15:07             ` Lucas De Marchi
2023-05-09  5:14 ` [PATCH 3/3] drm/i915: Temporary conversion to new GENMASK/BIT macros Lucas De Marchi
2023-05-09  7:57   ` Jani Nikula
2023-05-09  8:15     ` Lucas De Marchi

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=iakuowef3ysobpcpa6f74kolw44zyjepb5byjxljp4mxuwunkn@rdegvnuzbnmi \
    --to=lucas.demarchi@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=alexander.deucher@amd.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=christian.koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gustavo.sousa@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=kevin.brodsky@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masahiroy@kernel.org \
    --cc=tglx@linutronix.de \
    /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).