linux-kernel - Re: [PATCH v4 3/8] bits: introduce fixed-type genmasks

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Z8lqtLrlIv75lK5d@smile.fi.intel.com>
Date: Thu, 6 Mar 2025 11:28:20 +0200
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Vincent Mailhol <mailhol.vincent@...adoo.fr>
Cc: Yury Norov <yury.norov@...il.com>,
	Lucas De Marchi <lucas.demarchi@...el.com>,
	Rasmus Villemoes <linux@...musvillemoes.dk>,
	Jani Nikula <jani.nikula@...ux.intel.com>,
	Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>,
	Rodrigo Vivi <rodrigo.vivi@...el.com>,
	Tvrtko Ursulin <tursulin@...ulin.net>,
	David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, intel-gfx@...ts.freedesktop.org,
	dri-devel@...ts.freedesktop.org,
	Andi Shyti <andi.shyti@...ux.intel.com>,
	David Laight <David.Laight@...lab.com>,
	Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
	Jani Nikula <jani.nikula@...el.com>
Subject: Re: [PATCH v4 3/8] bits: introduce fixed-type genmasks

On Thu, Mar 06, 2025 at 06:22:33PM +0900, Vincent Mailhol wrote:
> On 06/03/2025 at 04:45, Andy Shevchenko wrote:
> >>> But GENMASK_U128() becomes a special case now.
> >>> The 128-bit GENMASK is unsued, but it's exported in uapi. Is there any
> >>> simple way to end up with a common implementation for all fixed-type
> >>> GENMASKs?
> >>
> >> What bothers me is that the 128 bit types are not something available on
> >> all architectures, c.f. the CONFIG_ARCH_SUPPORTS_INT128. So, I would
> >> need a U128() equivalent to the ULL() but which does not break on
> >> architectures which do not support 128 bits integers.
> >>
> >> This is where I am stuck. If someone can guide me on how to write a
> >> robust U128() macro, then I think the common implementation could be
> >> feasible.
> > 
> > I think we may leave that U128 stuff alone for now.
> 
> I found the solution! The trick is to use type_max() from overflow.h.
> 
> With this, GENMASK_TYPE() becomes:
> 
>   #define GENMASK_TYPE(t, h, l)					\
>   	((t)(GENMASK_INPUT_CHECK(h, l) +			\
>   	     (type_max(t) << (l) &				\
>   	      type_max(t) >> (BITS_PER_TYPE(t) - 1 - (h)))))
> 
> and works with all the GENMASK variants, including the U128 one! The
> unit tests under lib/test_bits.c are all green.
> 
> Of course, this does *not* work in assembly. But as explained before,
> GENMASK_TYPE() is guarded by a #if !defined(__ASSEMBLY__), so all good!
> 
> The question raised by Yury on whether or not we should keep
> __GENMASK_U128() in the uapi still remains. And in full honesty, I will
> not touch that one. This is not in the scope of this series.

I vote for not touching it right now independently on its destiny.

-- 
With Best Regards,
Andy Shevchenko