|
Description
|
When dlmgmtd receives a door upcall as a result of a device attaching, it always writes to /etc/dladm/datalink.conf, even when it replaces an existing link entry that does not need changing. For example, if an existing device re-attaches and nothing has changed regarding its configuration, dlmgmtd blindly re-writes its datalink configuration line in /etc/dladm/datalink.conf. This means that the modification time for /etc/dladm/datalink.conf doesn't reflect when the file was effectively modified or when a change to persistent datalink configuration was made, but rather when the last device happenes to have attached and dls made an upcall to dlmgmtd (at the very least, this was the last time the system booted). This is misleading.
The code in question is in dlmgmt_upcall_create(), where we unconditionally always call dlmgmt_write_db_entry():
158
159 done:
160 if ((err == 0) && ((err = dlmgmt_write_db_entry(linkp->ll_linkid
,
161 linkp->ll_flags)) != 0) && created) {
162 (void) dlmgmt_destroy_common(linkp, flags);
163 }
164
This bug was found when we noticed that /etc/dladm/datalink.conf's modification time was being updated every few seconds on jurassic-x4600.sfbay. This was because on a debug kernel, the system attempts to unload every module periodically, and this was causing net_dacf's postattach routine to be continuously called for every device on the system, triggering upcalls to dlmgmtd. The postattach behavior on detach is likely a separate bug, and this is covered by 6729153.
|
