RE: [RFC PATCH 2/2] hv_netvsc: back GPADL buffers with kmalloc + decrypt + vmap

From: Kameron Carr <[email protected]> Sent: Friday, July 31,=
 2026 12:06 PM
>=20
> On Friday, July 24, 2026 12:37 PM, Michael Kelley wrote:
> > From: Kameron Carr <[email protected]> Sent: Tuesday, Jul=
y 21, 2026 12:57 PM
> [...]
> > > +	/*
> > > +	 * @order monotonically decreases across iterations
> > > +	 *
> > > +	 * Use __GFP_NORETRY | __GFP_NOWARN to avoid OOM-killing, but try
> > > +	 * harder at order 0 since that is the final fallback.
> > > +	 */
> > > +	order =3D min_t(unsigned int, MAX_PAGE_ORDER, ilog2(nr_pages));
> >
> > Prefer using min() instead of min_t(). For normal integer values,
> > min() should work correctly.
>=20
> Using min() compiled fine on ARM, but x86 is throwing a compile error.
>=20
>     drivers/hv/channel.c: In function 'vmbus_alloc_buffer':
>     ././include/linux/compiler_types.h:699:45: error: call to
>     '__compiletime_assert_518' declared with attribute error: min(order, =
(
>     __builtin_constant_p(remaining) ? ((remaining) < 2 ? 0 : 63 -
>     __builtin_clzll(remaining)) : (sizeof(remaining) <=3D 4) ?
>     __ilog2_u32(remaining) : __ilog2_u64(remaining) )) signedness error
>=20
> In my v3 I may go back to using min_t. Please let me know if a cast (or
> some other method) is preferred.

Hmmm. I don't get the same compile error on x86/x64. Maybe it is
related to compiler and version, or the kernel code base against which
the patch is being built. Probably you didn't see a problem on arm64
because of some such difference. FWIW, I built with gcc 11.4.0 against
linux-next20260726.  What is the compiler and base kernel info where
you saw the error and on arm64 where you didn't?

 Michael