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

From: Kameron Carr <[email protected]> Sent: Monday, August 3=
, 2026 10:40 AM
>=20
> On Saturday, August 1, 2026 9:17 PM, Michael Kelley wrote:
> > From: Kameron Carr <[email protected]> Sent: Friday, July=
 31, 2026 12:06 PM
> > >
> > > On Friday, July 24, 2026 12:37 PM, Michael Kelley wrote:
> > > > From: Kameron Carr <[email protected]> Sent: Tuesday,=
 July 21, 2026 12:57 PM
> > > [...]
> > > > > +	/*
> > > > > +	 * @order monotonically decreases across iterations
> > > > > +	 *
> > > > > +	 * Use __GFP_NORETRY | __GFP_NOWARN to avoid OOM-killing, but t=
ry
> > > > > +	 * 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.
> > >
> > > Using min() compiled fine on ARM, but x86 is throwing a compile error=
.
> > >
> > >     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(ord=
er,
> (
> > >     __builtin_constant_p(remaining) ? ((remaining) < 2 ? 0 : 63 -
> > >     __builtin_clzll(remaining)) : (sizeof(remaining) <=3D 4) ?
> > >     __ilog2_u32(remaining) : __ilog2_u64(remaining) )) signedness err=
or
> > >
> > > 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?
>=20
> In both cases, I built against hyperv-next (a4ffc59).
> On ARM64 I used gcc 13.2.0; on x86 I used 13.3.0.
>=20
> To do a fair comparison, I
>  * downgraded my x86 environment to gcc 13.2.0
>  * started with `make defconfig`
>  * enabled Hyper-V and NetVSC in the config (=3Dy)
>=20
> I saw the same behavior where there was no error on ARM and compile failu=
re
> on x86.
>=20

Really weird. I compiled on x86/x64 with gcc 13.3.0, and saw no
problem. This was against the official 7.1.0 release source code.
Then I grabbed hyperv-next (the tag "hyperv-next-signed-20260621"
specifically), added your patches, and again using gcc 13.3.0 I
built with no problem. Are you using the same local copy of the
source code for arm64 and x86/x64 builds? If not, I wonder if
your local x86/x64 source code tree is somehow corrupt or not
what you think it is.

My .config file is different from yours. I did not try starting fresh
with make defconfig and then enable Hyper-V and netvsc.

Michael