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

From: Kameron Carr <[email protected]> Sent: Wednesday, Augus=
t 5, 2026 10:16 AM

[snip]

> > > > >
> > > > > Using min() compiled fine on ARM, but x86 is throwing a compile e=
rror.
> > > > >
> > > > >     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
> > > > >
> > > > > In my v3 I may go back to using min_t. Please let me know if a ca=
st (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 wh=
ich
> > > > the patch is being built. Probably you didn't see a problem on arm6=
4
> > > > because of some such difference. FWIW, I built with gcc 11.4.0 agai=
nst
> > > > linux-next20260726.  What is the compiler and base kernel info wher=
e
> > > > you saw the error and on arm64 where you didn't?
> > >
> > > In both cases, I built against hyperv-next (a4ffc59).
> > > On ARM64 I used gcc 13.2.0; on x86 I used 13.3.0.
> > >
> > > 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)
> > >
> > > I saw the same behavior where there was no error on ARM and compile f=
ailure
> > > on x86.
> > >
> >
> > 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.
>=20
> Automated testing is picking up the same compiler error
> https://lore.kernel.org/all/[email protected]/=
=20
>=20
>     tree:      net-next
>     arch:      amd64
>     compiler:  Debian clang version 22.1.8
>=20
> This points to a real issue, not a corruption issue.
>=20
> I believe the right course is to explicitly do an unsigned comparison
> instead of relying on the compiler to allow a comparison between a
> signed and unsigned value.
>=20

Agreed.  I don't have any ideas at the moment on how to
further investigate why it's OK sometimes and other times not.

Michael