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 Not Applicable - Unit
Tests Not Applicable
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 1
Eventually 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.