Bug #12355
closedvnic_unicast_add() can return uninitialised diag value
100%
Description
I noticed this in OmniOS when side-pulling network overlay support from SmartOS, but it's a general problem with VNICs.
vnic_unicast_add()
calls into mac_unicast_add
passing in a pointer to a mac_diag_t
. If the call fails then, if there is additional diagnostic information available, mac sets that value; however it does not do this for all failures.
The specific problem I saw in OmniOS was that attempting to bring up a vnic early during boot would report an error.
root@bloody:~# dladm up-vnic ovnic0 dladm: could not bring up vnic 'ovnic0': invalid MAC address length
That's a completely spurious error. The real problem is that the kernel couldn't bind a socket to a particular IP address, vnic_ioc_create()
is returning 126 (EADDRNOTAVAIL) - note that I get a different error message this time "invalid factory MAC address slot"
root@bloody:~# dtrace -n 'fbt:::return/arg1==126/{}' -c 'dladm up-vnic ovnic0' dtrace: description 'fbt:::return' matched 33364 probes dladm: could not bring up vnic 'ovnic0': invalid factory MAC address slot dtrace: pid 1192 has exited CPU ID FUNCTION:NAME 7 64450 vnic_dev_create:return 7 64382 vnic_ioc_create:return
Updated by Andy Fiddaman almost 4 years ago
- Category set to networking
- Status changed from New to In Progress
- Assignee set to Andy Fiddaman
- Difficulty changed from Medium to Bite-size
Updated by Andy Fiddaman over 3 years ago
Tested this on OmniOS and confirmed that `dladm` shows the correct error message after this change.
Updated by Electric Monk over 3 years ago
- Status changed from In Progress to Closed
- % Done changed from 0 to 100
git commit ea7201620ceafab72b37e65bea4ec461dd27089d
commit ea7201620ceafab72b37e65bea4ec461dd27089d Author: Andy Fiddaman <omnios@citrus-it.co.uk> Date: 2020-03-10T08:44:02.000Z 12355 vnic_unicast_add() can return uninitialised diag value Reviewed by: Robert Mustacchi <rm@fingolfin.org> Reviewed by: Dominik Hassler <hadfl@omniosce.org> Approved by: Joshua M. Clulow <josh@sysmgr.org>