ioctl(2)'s with integer argument shall pass command argument by value,
not by pointer.  The ioctl(2) manual page is not very clear about that.
See sys/kern/sys_generic.c:sys_ioctl() near IOC_VOID.
Details
Details
- Reviewers
 markj bz grehan - Group Reviewers
 bhyve - Commits
 - rGef161a35012f: bhyve: fix arguments to ioctl(VMIO_SIOCSIFFLAGS)
rGabf5807ffc36: bhyve: fix arguments to ioctl(VMIO_SIOCSIFFLAGS)
rG6f1ccbd58790: bhyve: fix arguments to ioctl(VMIO_SIOCSIFFLAGS)
rGf407a72a506d: bhyve: fix arguments to ioctl(VMIO_SIOCSIFFLAGS) 
Diff Detail
Diff Detail
- Repository
 - rG FreeBSD src repository
 - Lint
 Lint Passed - Unit
 No Test Coverage - Build Status
 Buildable 54171 Build 51061: arc lint + arc unit 
Event Timeline
Comment Actions
This is how bug manifests itself:
>dtrace -n 'fbt::tunioctl:entry /execname == "bhyve" && args[1] == 0x20045600/ { printf("%x", *(int *)args[2]); }'
Before:
  5  13039                   tunioctl:entry 20045600 d5dea838
  2  13039                   tunioctl:entry 20045600 8751d008
  2  13039                   tunioctl:entry 20045600 93248d28
  4  13039                   tunioctl:entry 20045600 d85557a8
After:
dtrace: description 'fbt::tunioctl:entry ' matched 1 probe
CPU     ID                    FUNCTION:NAME
  7  13039                   tunioctl:entry 1Eventually it ends up with setting NOARP flag on the vmnet interface. On CURRENT the bug could be masked either by INVARIANTS in the kernel or by MALLOC_PRODUCTION in the userland.
P.S. See also 9fddcc6661d2cf7bb8e704308437d2b1674b50be
Comment Actions
Thank you. :(
The bug is in releng/14.0. Could you please make sure this makes it there too? I can help get that done if needed.