OpenBSD Journal

d2k17 Hackathon Report: Ken Westerback on XS_NO_CCB removal and dhclient link detection

Contributed by rueda on from the sequential improvement dept.

Our second d2k17 report is from Ken Westerback (krw@), who writes:

I arrived at Starnberg with a clear and overriding focus -- to finally expunge the obsolete XS_NO_CCB construct from our SCSI code. In fact I was so focused on this issue I walked right past my pre-d2k17 hotel and wandered the streets of Starnberg for 30 minutes until I found it sitting right across the street from the BahnHof I started at.

Once I got to the hackroom the next day and established communications with sf@, we quickly got the vioblk, vioscsi and scsi XS_NO_CCB removal code tested and committed. Over the next few days, despite repeated interruptions described below, XS_NO_CCB stayed out of the tree and a number of associated cleanups and code simplifications were committed by sf@, mlarkin@ and myself. In particular the vioblk queues were doubled in size to 128, a limit which appears to be imposed by deeper code. At the moment this has little impact but work is progressing to attempt asynchronous i/o in virtio devices.

In the middle of this important work, henning@ tapped me on the shoulder and complained that dhclient was abusing his, hmm, specialized vlan + static routes setup. i.e. dhclient was starting up, then noticing that the vlan device has a new LLADDR and immediately restarting. Which meant the "!route ..." statement in his hostname.vlanNN file was being executed before the interface had a lease in place. Which was bad.

I admitted there had been a change in dhclient to get the LLADDR earlier but didn't understand how this could possibly impact the setup. As it turns out vlan devices were not inheriting their LLADDR at creation time, among other possible milestones that might impact LLADDR. After some back and forth discussion among mpi@, dlg@ and myself a change was committed to ensure vlan interfaces have a valid LLADDR under most conceivable circumstances. Problem solved!

Well, ...

Unfortunately, even with a valid LLADDR the vlan interface was misbehaving on startup when the parent interface did not have link. e.g. if the wired interface was unplugged. More poking showed that vlan did not implement the SIOCGIFMEDIA ioctl. So dhclient assumed the vlan link was up and immediately started pumping out packets that went nowhere. mpi@ put together a diff that implemented SIOCGIFMEDIA by passing such requests to the parent interface. Problem solved!

Well, ...

In putting together the diff, mpi@ spotted the the incredibly old and crufty way dhclient detected link state. He recommended using getifaddr() information instead. Which I happily committed as it simplified the code and likely simplified future pledge(2) work. Problem solved!

Well, ...

People immediately noticed that the new dhclient link detection was bogus for wifi interfaces. This resulted in some soul and code searching that revealed that wifi interfaces were not setting their link state to LINK_DOWN when it was appropriate to do so. Instead they left the link state as LINK_UNKNOWN. Which dhclient has to interpret as the link might be up. stsp@ quickly fixed this by having the wifi interfaces set link state appropriately. Problem solved!

Silence ... Yay!

A final pass through the virtio code to replace a local DBGPRINT() macro with DPRINTF/DNPRINTF and the hackathon was over.

Excellent venue. Excellent organization. Excellent results! Thanks to our hosts, organizers, sponsors and attendees!

Thanks very much, Ken!

(Comments are closed)


Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]