Conflicting type `dev_addr_set` after upgrade to kernel 4.18.0-365

[syslogic]

I've did a distro upgrade from centos-linux to centos-stream (as it may not be uncommon due to repository changes).

$ make
make -C vmmon-only 
make[1]: Entering directory '/vmware-host-modules/vmmon-only'
Using kernel build system.
make -C /lib/modules/4.18.0-365.el8.x86_64/build/include/.. SUBDIRS=$PWD SRCROOT=$PWD/. \
  MODULEBUILDDIR= modules
make[2]: Entering directory '/usr/src/kernels/4.18.0-365.el8.x86_64'
  Building modules, stage 2.
  MODPOST 1 modules
make[2]: Leaving directory '/usr/src/kernels/4.18.0-365.el8.x86_64'
make -C $PWD SRCROOT=$PWD/. \
  MODULEBUILDDIR= postbuild
make[2]: Entering directory '/vmware-host-modules/vmmon-only'
make[2]: 'postbuild' is up to date.
make[2]: Leaving directory '/vmware-host-modules/vmmon-only'
cp -f vmmon.ko ./../vmmon.o
make[1]: Leaving directory '/vmware-host-modules/vmmon-only'
make -C vmnet-only 
make[1]: Entering directory '/vmware-host-modules/vmnet-only'
Using kernel build system.
make -C /lib/modules/4.18.0-365.el8.x86_64/build/include/.. SUBDIRS=$PWD SRCROOT=$PWD/. \
  MODULEBUILDDIR= modules
make[2]: Entering directory '/usr/src/kernels/4.18.0-365.el8.x86_64'
  CC [M]  /vmware-host-modules/vmnet-only/netif.o
/vmware-host-modules/vmnet-only/netif.c:90:1: error: conflicting types for ‘__dev_addr_set’
 __dev_addr_set(struct net_device *dev, const void *addr, size_t len)
 ^~~~~~~~~~~~~~
In file included from /vmware-host-modules/vmnet-only/netif.c:29:
./include/linux/netdevice.h:4567:1: note: previous definition of ‘__dev_addr_set’ was here
 __dev_addr_set(struct net_device *dev, const u8 *addr, size_t len)
 ^~~~~~~~~~~~~~
/vmware-host-modules/vmnet-only/netif.c:95:13: error: redefinition of ‘dev_addr_set’
 static void dev_addr_set(struct net_device *dev, const u8 *addr)
             ^~~~~~~~~~~~
In file included from /vmware-host-modules/vmnet-only/netif.c:29:
./include/linux/netdevice.h:4572:20: note: previous definition of ‘dev_addr_set’ was here
 static inline void dev_addr_set(struct net_device *dev, const u8 *addr)
                    ^~~~~~~~~~~~
make[3]: *** [scripts/Makefile.build:316: /vmware-host-modules/vmnet-only/netif.o] Error 1
make[2]: *** [Makefile:1577: _module_/vmware-host-modules/vmnet-only] Error 2
make[2]: Leaving directory '/usr/src/kernels/4.18.0-365.el8.x86_64'
make[1]: *** [Makefile:117: vmnet.ko] Error 2
make[1]: Leaving directory '/vmware-host-modules/vmnet-only'
make: *** [Makefile:21: vmnet-only] Error 2

With centos-linux-release it still worked ...that was kernel 348.7-1.

$ rpm -q centos-stream-release
centos-stream-release-8.6-1.el8.noarch

---

The conflicting type-definition seems to be here: https://github.com/mkubecek/vmware-host-modules/blob/workstation-16.2.1/vmnet-only/netif.c#L90

Without the declaration, it builds. The question might be, why it even enters that branch? Common sense may suggest that < KERNEL_VERSION(5, 15, 0) is a wrongful condition ...

#if LINUX_VERSION_CODE < KERNEL_VERSION(5, 15, 0)
static void
__dev_addr_set(struct net_device *dev, const void *addr, size_t len)
{
	memcpy(dev->dev_addr, addr, len);
}

static void dev_addr_set(struct net_device *dev, const u8 *addr)
{
	__dev_addr_set(dev, addr, dev->addr_len);
}
#endif

[syslogic]

When I change the condition, it also builds; where RHEL_RELEASE_VERSION(8, 6) means it starts failing with 8.6-1:

#if (LINUX_VERSION_CODE < KERNEL_VERSION(5, 15, 0) && \
     RHEL_RELEASE_CODE < RHEL_RELEASE_VERSION(8, 6))

For openSUSE this could be fixed similarly, when knowing with which release version the kernel headers may have changed. I mean, one needs a combined check; when checking for KERNEL_VERSION(5, 15, 0) does not suffice; eg. || SUSE_RELEASE_CODE < SUSE_RELEASE_VERSION(X, Y). Also not sure if this would work for Rocky Linux 8, which is currently RHEL_RELEASE_VERSION(8, 5), which is kernel 348.12-2.

[mkubecek]

It certainly cannot be done like this as it would break build on any non-RHEL kernel. But we can do something like commit 5383a0266396. Did you check that the dev_addr_set() helper has not been backported into RHEL 8.5 codestream?

[syslogic]

I think the main difference may be the distribution channel, as I switched from CentOS Linux 8 to CentOS Stream 8; eg:

dnf swap centos-linux-repos centos-stream-repos
dnf distro-sync

According to the error message, the method exists in ./include/linux/netdevice.h:4567. It's still kind of difficult to pin down alike that; couldn't pointer to function be used? I mean, instead of assuming that the function may or may not exists, checking for it. They don't publish source RPM for the the rolling release, besides the kernel-headers, there's just vault.centos.org left.

[ilp1968]

It certainly cannot be done like this as it would break build on any non-RHEL kernel. But we can do something like commit 5383a02. Did you check that the dev_addr_set() helper has not been backported into RHEL 8.5 codestream?

After some delay I upgraded my RHEL 8.6 to the latest patchset and must confirm: the dev_addr_set() helper has not been backported yet (both methods are unconditionally defined). I used @syslogic 's "trick" patching the version locally to have vmmon compile.

My current uname: ~]$ uname -a Linux rhel8-lfou92s 4.18.0-372.9.1.el8.x86_64 #1 SMP Fri Apr 15 22:12:19 EDT 2022 x86_64 x86_64 x86_64 GNU/Linux

[mkubecek]

Both workstation-16.2.4 and workstation-17.0.0 should build now against RHEL 8.3-8.7 and 9.0-9.2.

Feel free to reopen if something is still broken, finding relevant kernel-devel packages for RHEL/CentOS/Rocky/whatever was a bit tricky which was why wasn't really eager to dive into this.

[ilp1968]

Dear @mkubecek, a BIG THANK YOU! And Kudos for fixing this. Just installed VMWare-Workstation-17.0.0 on RHEL 8.7 without a single hiccup using your modules. -Igor

[mkubecek]

Thank you for the feedback. I'm sorry that it took so long, the biggest problem was collecting the relevant kernel devel packages and testing all of them to find out which backport went where. This was really tricky for 9.x line where CentOS stream repository provides only 9.2, Rocky Linux repository provides 9.0 but 9.1 is only a pre-release there and I was only able to find a git repository with the source and had to make it ready myself.

[ilp1968]

Hi Michal, I had a workaround so the issue did not really block me. Updating to vmware workstation 17 without having to patch anything was a great experience nevertheless. BR, Igor -edit: removed quoted text