VMware Communities
FamPhetial
Contributor
Contributor

kernel trace for vmnet1/8: netdevice: vmnet1: Incorrect netdev->dev_addr

My vmware is working fine. I have several VMs running. But I am annoyed by kernel traces in the journal related to vmnet1 and vmnet8 interfaces. The traces appear with any kernel 5.15.x, 5.,17.x and the new 5.18

How can I fix that?

Example for vmnet1:

Mai 26 06:32:06 rakete kernel: vmnet1: Current addr: 00 50 56 c0 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00>
Mai 26 06:32:06 rakete kernel: vmnet1: Expected addr: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00>
Mai 26 06:32:06 rakete kernel: ------------[ cut here ]------------
Mai 26 06:32:06 rakete kernel: netdevice: vmnet1: Incorrect netdev->dev_addr
Mai 26 06:32:06 rakete kernel: WARNING: CPU: 17 PID: 4613 at net/core/dev_addr_lists.c:517 dev_addr_check.cold+0x43/0x74
Mai 26 06:32:06 rakete kernel: Modules linked in: qrtr cfg80211 ccm algif_aead cbc des_generic libdes ecb algif_skcipher cmac>
Mai 26 06:32:06 rakete kernel: spl(OE) crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel crypto_sim>
Mai 26 06:32:06 rakete kernel: CPU: 17 PID: 4613 Comm: vmware-networks Tainted: P OE 5.18.0-arch1-1 #1 b71a70fe>
Mai 26 06:32:06 rakete kernel: Hardware name: Gigabyte Technology Co., Ltd. X570 AORUS ULTRA/X570 AORUS ULTRA, BIOS F36c 05/1>
Mai 26 06:32:06 rakete kernel: RIP: 0010:dev_addr_check.cold+0x43/0x74
Mai 26 06:32:06 rakete kernel: Code: 01 e8 7d 1f fb ff 0f 0b 48 c7 c5 87 22 89 b8 80 3b 00 75 27 48 c7 c6 92 22 89 b8 48 89 e>
Mai 26 06:32:06 rakete kernel: RSP: 0018:ffffc33a01d93ba8 EFLAGS: 00010286
Mai 26 06:32:06 rakete kernel: RAX: 0000000000000000 RBX: ffff9e900d41d000 RCX: 0000000000000027
Mai 26 06:32:06 rakete kernel: RDX: ffff9e9efee616a8 RSI: 0000000000000001 RDI: ffff9e9efee616a0
Mai 26 06:32:06 rakete kernel: RBP: ffffffffb887908e R08: 0000000000000000 R09: ffffc33a01d939b8
Mai 26 06:32:06 rakete kernel: R10: 0000000000000003 R11: ffff9e9f3f2a25a8 R12: ffffffffc05a13c0
Mai 26 06:32:06 rakete kernel: R13: ffff9e900d41d268 R14: 0000000000000000 R15: 0000000000000001
Mai 26 06:32:06 rakete kernel: FS: 00007f8b6f010240(0000) GS:ffff9e9efee40000(0000) knlGS:0000000000000000
Mai 26 06:32:06 rakete kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Mai 26 06:32:06 rakete kernel: CR2: 00005610a3da4568 CR3: 000000013a232000 CR4: 0000000000750ee0
Mai 26 06:32:06 rakete kernel: PKRU: 55555554
Mai 26 06:32:06 rakete kernel: Call Trace:
Mai 26 06:32:06 rakete kernel: <TASK>
Mai 26 06:32:06 rakete kernel: __dev_open+0x3f/0x1a0
Mai 26 06:32:06 rakete kernel: ? bpf_lsm_capset+0x10/0x10
Mai 26 06:32:06 rakete kernel: ? security_capable+0x44/0x60
Mai 26 06:32:06 rakete kernel: __dev_change_flags+0x1d7/0x250
Mai 26 06:32:06 rakete kernel: dev_change_flags+0x26/0x60
Mai 26 06:32:06 rakete kernel: devinet_ioctl+0x377/0x7d0
Mai 26 06:32:06 rakete kernel: ? inet_ioctl+0x1af/0x1e0
Mai 26 06:32:06 rakete kernel: inet_ioctl+0x1af/0x1e0
Mai 26 06:32:06 rakete kernel: ? dev_get_by_name_rcu+0x67/0x80
Mai 26 06:32:06 rakete kernel: sock_do_ioctl+0x7e/0x120
Mai 26 06:32:06 rakete kernel: sock_ioctl+0xee/0x330
Mai 26 06:32:06 rakete kernel: ? __x64_sys_ioctl+0x91/0xc0
Mai 26 06:32:06 rakete kernel: __x64_sys_ioctl+0x91/0xc0
Mai 26 06:32:06 rakete kernel: do_syscall_64+0x5f/0x90
Mai 26 06:32:06 rakete kernel: ? syscall_exit_to_user_mode+0x26/0x50
Mai 26 06:32:06 rakete kernel: ? __x64_sys_socket+0x17/0x20
Mai 26 06:32:06 rakete kernel: ? do_syscall_64+0x6b/0x90
Mai 26 06:32:06 rakete kernel: ? do_syscall_64+0x6b/0x90
Mai 26 06:32:06 rakete kernel: ? do_syscall_64+0x6b/0x90
Mai 26 06:32:06 rakete kernel: ? exc_page_fault+0x74/0x170
Mai 26 06:32:06 rakete kernel: entry_SYSCALL_64_after_hwframe+0x44/0xae
Mai 26 06:32:06 rakete kernel: RIP: 0033:0x7f8b6ef07b1f
Mai 26 06:32:06 rakete kernel: Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 2>
Mai 26 06:32:06 rakete kernel: RSP: 002b:00007ffccf9c6580 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
Mai 26 06:32:06 rakete kernel: RAX: ffffffffffffffda RBX: 00007ffccf9c6630 RCX: 00007f8b6ef07b1f
Mai 26 06:32:06 rakete kernel: RDX: 00007ffccf9c6630 RSI: 0000000000008914 RDI: 0000000000000005
Mai 26 06:32:06 rakete kernel: RBP: 0000000000000005 R08: 00007ffccf9c65f0 R09: 0000000000000004
Mai 26 06:32:06 rakete kernel: R10: 0000000000000011 R11: 0000000000000246 R12: 00007ffccf9c65f0
Mai 26 06:32:06 rakete kernel: R13: 00007ffccf9c6600 R14: 00007ffccf9c6610 R15: 0000000000000000
Mai 26 06:32:06 rakete kernel: </TASK>
Mai 26 06:32:06 rakete kernel: ---[ end trace 0000000000000000 ]---

Reply
0 Kudos
4 Replies
mkubecek
Hot Shot
Hot Shot

As unpatched modules from VMware stopped do not even build against 5.18 kernel, I assume you are using some patched ones. Can you tell us which exactly?

Reply
0 Kudos
FamPhetial
Contributor
Contributor

I am using the package vmware-workstation 16.2.3-2 on Arch Linux. The package contains two patch files: vmmon.patch and vmnet.patch

 

Here is vmnet.patch:

--- a/vmnet/Makefile
+++ b/vmnet/Makefile
@@ -43,7 +43,11 @@ INCLUDE += -I$(SRCROOT)/shared
endif


+ifdef KVERSION
+VM_UNAME = $(KVERSION)
+else
VM_UNAME = $(shell uname -r)
+endif

# Header directory for the running kernel
ifdef LINUXINCLUDE
--- a/vmnet/userif.c
+++ b/vmnet/userif.c
# Fixing VMWare Player on Linux when using DHCP addresses: https://www.nikhef.nl/~janjust/vmnet/
@@ -998,6 +998,9 @@
userIf = (VNetUserIF *)port->jack.private;
hubJack = port->jack.peer;

+ /* never send link down events */
+ if (!linkUp) return 0;
+
if (port->jack.state == FALSE || hubJack == NULL) {
return -EINVAL;
}
From 9a6a17fe0bc6d1ab9e0e0dfa8d587b12a21cd49e Mon Sep 17 00:00:00 2001
From: Michal Kubecek <mkubecek@suse.cz>
Date: Sun, 17 Oct 2021 17:06:26 +0200
Subject: [PATCH] modules: include <linux/stdarg.h> when available

Workstation/Player code changes between 16.1.2 and 16.2.0 added some
includes of <stdarg.h> which is interpreted as regular (userspace) header
file in /usr/include. Shortly before that, mainline commit c0891ac15f04
("isystem: ship and use stdarg.h") added minimalistic kernel version of
stdarg.h to avoid including userspace headers from kernel code. As the
kernel version is sometimes included via other header files, build against
5.15 kernel results in a lot of warnings (about redefined va_* macros).

Include <stdarg.h> when building against kernel < 5.15 and <linux/stdarg.h>
when building against kernel >= 5.15.
---
vmmon-only/include/vm_assert.h | 4 ++++
vmnet-only/vm_assert.h | 4 ++++
2 files changed, 8 insertions(+)

diff --git a/vmnet-only/vm_assert.h b/vmnet-only/vm_assert.h
index cf34446..430c74d 100644
--- a/vmnet-only/vm_assert.h
+++ b/vmnet-only/vm_assert.h
@@ -40,7 +40,11 @@

// XXX not necessary except some places include vm_assert.h improperly
#include "vm_basic_types.h"
+#if LINUX_VERSION_CODE < KERNEL_VERSION(5, 15, 0)
#include <stdarg.h>
+#else
+#include <linux/stdarg.h>
+#endif

#ifdef __cplusplus
extern "C" {
From 4232f780eb114f22498f3274eaeef81d8c63f2ab Mon Sep 17 00:00:00 2001
From: Michal Kubecek <mkubecek@suse.cz>
Date: Tue, 9 Nov 2021 09:01:57 +0100
Subject: [PATCH] modules: fix stddef.h include

After mainline commit 04e85bbf71c9 ("isystem: delete global -isystem
compile option") in 5.16-rc1, vm_basic_types.h in both vmmon and vmnet
does not find (userspace) stddef.h any more. As it should not include this
header anyway, fix the include directives to include stddef.h from kernel.

Kernel version of stddef.h has been available since the beginning of git so
that it is safe to include it regardless of kernel version.
---
vmmon-only/include/vm_basic_defs.h | 2 +-
vmnet-only/vm_basic_defs.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/vmnet-only/vm_basic_defs.h b/vmnet-only/vm_basic_defs.h
index 0ec30b3..b920e2d 100644
--- a/vmnet-only/vm_basic_defs.h
+++ b/vmnet-only/vm_basic_defs.h
@@ -51,7 +51,7 @@
* C90 7.17, C99 7.19, C11 7.19
*/
#if !defined(VMKERNEL)
-# include <stddef.h>
+# include <linux/stddef.h>
#else
/*
* Vmkernel's bogus __FreeBSD__ value causes gcc <stddef.h> to break.
From 409623bd4693afada659af82e823a6291f70797a Mon Sep 17 00:00:00 2001
From: Michal Kubecek <mkubecek@suse.cz>
Date: Mon, 4 Apr 2022 02:05:17 +0200
Subject: [PATCH] vmnet: use netif_rx() on newer kernels

In mainline 5.18-rc1, commit baebdf48c360 ("net: dev: Makes sure netif_rx()
can be invoked in any context.") allows calling netif_rx() from any context
and commit 2655926aea9b ("net: Remove netif_rx_any_context() and
netif_rx_ni().") drops netif_rx_ni() as it is no longer needed.

Replace calls of netif_rx_ni() in VNetBridgeReceiveFromVNet() and
VNetNetIfReceive() by netif_rx() when building against kernel 5.18 and
newer.
---
vmnet-only/bridge.c | 2 +-
vmnet-only/compat_netdevice.h | 9 +++++++++
vmnet-only/netif.c | 2 +-
3 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/vmnet-only/bridge.c b/vmnet-only/bridge.c
index c84f8ee..d6bd3c4 100644
--- a/vmnet-only/bridge.c
+++ b/vmnet-only/bridge.c
@@ -691,7 +691,7 @@ VNetBridgeReceiveFromVNet(VNetJack *this, // IN: jack
* not do it, or netif_rx_ni() will deadlock on the cli() lock --hpreg
*/

- netif_rx_ni(clone);
+ compat_netif_rx_ni(clone);
# if LOGLEVEL >= 4
do_gettimeofday(&vnetTime);
# endif
diff --git a/vmnet-only/compat_netdevice.h b/vmnet-only/compat_netdevice.h
index bb5001b..c6cc706 100644
--- a/vmnet-only/compat_netdevice.h
+++ b/vmnet-only/compat_netdevice.h
@@ -196,4 +196,13 @@ typedef u32 compat_netdev_features_t;
#define compat_netif_trans_update(d) do { (d)->trans_start = jiffies; } while (0)
#endif

+static inline int compat_netif_rx_ni(struct sk_buff *skb)
+{
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 18, 0)
+ return netif_rx(skb);
+#else
+ return netif_rx_ni(skb);
+#endif
+}
+
#endif /* __COMPAT_NETDEVICE_H__ */
diff --git a/vmnet-only/netif.c b/vmnet-only/netif.c
index 8c3bbf8..35256a0 100644
--- a/vmnet-only/netif.c
+++ b/vmnet-only/netif.c
@@ -345,7 +345,7 @@ VNetNetIfReceive(VNetJack *this, // IN: jack
/* send to the host interface */
skb->dev = netIf->dev;
skb->protocol = eth_type_trans(skb, netIf->dev);
- netif_rx_ni(skb);
+ compat_netif_rx_ni(skb);
netIf->stats.rx_packets++;

return;

 

Here is vmon.patch:

--- a/vmmon/Makefile
+++ b/vmmon/Makefile
@@ -43,7 +43,11 @@ INCLUDE += -I$(SRCROOT)/shared
endif


+ifdef KVERSION
+VM_UNAME = $(KVERSION)
+else
VM_UNAME = $(shell uname -r)
+endif

# Header directory for the running kernel
ifdef LINUXINCLUDE
From 9a6a17fe0bc6d1ab9e0e0dfa8d587b12a21cd49e Mon Sep 17 00:00:00 2001
From: Michal Kubecek <mkubecek@suse.cz>
Date: Sun, 17 Oct 2021 17:06:26 +0200
Subject: [PATCH] modules: include <linux/stdarg.h> when available

Workstation/Player code changes between 16.1.2 and 16.2.0 added some
includes of <stdarg.h> which is interpreted as regular (userspace) header
file in /usr/include. Shortly before that, mainline commit c0891ac15f04
("isystem: ship and use stdarg.h") added minimalistic kernel version of
stdarg.h to avoid including userspace headers from kernel code. As the
kernel version is sometimes included via other header files, build against
5.15 kernel results in a lot of warnings (about redefined va_* macros).

Include <stdarg.h> when building against kernel < 5.15 and <linux/stdarg.h>
when building against kernel >= 5.15.
---
vmmon-only/include/vm_assert.h | 4 ++++
vmnet-only/vm_assert.h | 4 ++++
2 files changed, 8 insertions(+)

diff --git a/vmmon-only/include/vm_assert.h b/vmmon-only/include/vm_assert.h
index 4a69dcc..2817a08 100644
--- a/vmmon-only/include/vm_assert.h
+++ b/vmmon-only/include/vm_assert.h
@@ -40,7 +40,11 @@

// XXX not necessary except some places include vm_assert.h improperly
#include "vm_basic_types.h"
+#if LINUX_VERSION_CODE < KERNEL_VERSION(5, 15, 0)
#include <stdarg.h>
+#else
+#include <linux/stdarg.h>
+#endif

#ifdef __cplusplus
extern "C" {
From 4232f780eb114f22498f3274eaeef81d8c63f2ab Mon Sep 17 00:00:00 2001
From: Michal Kubecek <mkubecek@suse.cz>
Date: Tue, 9 Nov 2021 09:01:57 +0100
Subject: [PATCH] modules: fix stddef.h include

After mainline commit 04e85bbf71c9 ("isystem: delete global -isystem
compile option") in 5.16-rc1, vm_basic_types.h in both vmmon and vmnet
does not find (userspace) stddef.h any more. As it should not include this
header anyway, fix the include directives to include stddef.h from kernel.

Kernel version of stddef.h has been available since the beginning of git so
that it is safe to include it regardless of kernel version.
---
vmmon-only/include/vm_basic_defs.h | 2 +-
vmnet-only/vm_basic_defs.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/vmmon-only/include/vm_basic_defs.h b/vmmon-only/include/vm_basic_defs.h
index 0ec30b3..b920e2d 100644
--- a/vmmon-only/include/vm_basic_defs.h
+++ b/vmmon-only/include/vm_basic_defs.h
@@ -51,7 +51,7 @@
* C90 7.17, C99 7.19, C11 7.19
*/
#if !defined(VMKERNEL)
-# include <stddef.h>
+# include <linux/stddef.h>
#else
/*
* Vmkernel's bogus __FreeBSD__ value causes gcc <stddef.h> to break.
From 16d490ae022d7fc4ca867971e20e2dcd59e6ca5a Mon Sep 17 00:00:00 2001
From: Michal Kubecek <mkubecek@suse.cz>
Date: Mon, 4 Apr 2022 01:57:28 +0200
Subject: [PATCH] vmmon: do not rely on HAVE_GET_KERNEL_NOFAULT

Mainline commit 34737e269803 ("uaccess: add generic
__{get,put}_kernel_nofault") in 5.18-rc1 removes HAVE_GET_KERNEL_NOFAULT
macro as all architectures can use get_kernel_nofault() now. Check for
existence of __get_kernel_nofault() instead and add also a version check in
case it stops being a macro or is removed in the future.
---
vmmon-only/linux/hostif.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/vmmon-only/linux/hostif.c b/vmmon-only/linux/hostif.c
index a21c300..b6326e9 100644
--- a/vmmon-only/linux/hostif.c
+++ b/vmmon-only/linux/hostif.c
@@ -2356,7 +2356,8 @@ isVAReadable(VA r) // IN:
int ret;

r = APICR_TO_ADDR(r, APICR_VERSION);
-#ifdef HAVE_GET_KERNEL_NOFAULT
+#if defined(HAVE_GET_KERNEL_NOFAULT) || defined(__get_kernel_nofault) || \
+ (LINUX_VERSION_CODE >= KERNEL_VERSION(5, 18, 0))
ret = get_kernel_nofault(dummy, (void *)r);
#else
{

 

 

 

Reply
0 Kudos
mkubecek
Hot Shot
Hot Shot

This patch should help.

Tags (1)
FamPhetial
Contributor
Contributor

That patch works very well!

Thank you.

Reply
0 Kudos