> >Since this qwriter_ip() is for CUR_OP and reentry_ok (the last parameter) > >is set to B_FALSE, ip_rput_dlpi_writer() will never be called. Since it's > >not called, ill_dlpi_done() is never called, and thus we will never send > >the deferred DL_DETACH_REQ. > > In reality the unplumb thread never releases the ipsq once it enters > the ipq in ip_modclose(). The cv_wait is done while holding the ipsq, > and after the qprocsoff, ipsq_flush() gets rid of all enqueued messages > trying to become writer. So irrespective of the 'reentry_ok' we are not > going to process the DL_OK_ACK !
Indeed. > One possibility is to call ill_dlpi_done() after the cv_wait() in > ill_delete_tail(). The DL_OK_ACK message itself should just be freed > by ip_rput_dlpi() (instead of calling qwriter_ip) after clearing the > ILL_DL_UNBIND_IN_PROGRESS. Yes, that's possible. Alternatively, we could make it safe to call ill_dlpi_done() from ip_rput_dlpi(). In my workspace I've been working on, I've already made it safe to call ill_dlpi_done() without being writer (not a big change -- ill_dlpi_pending and ill_dlpi_deferred are now protected by ill_lock rather than the IPSQ). > >Seems like the simplest fix for a lot of this brokenness is to simply not > >try to send the DL_DETACH_REQ. As per the bugs above, it seems like we've > >accidentally not been sending it for a while, and no one has complained. > >Further, the DLPI specification does not require that one do a detach > >prior to close -- so I think IP is within its rights to skip the detach. > >Thoughts? > > > I don't have the DLPI spec handy. Is the optional part because some > drivers could be type 1 or is it optional even for type 2 drivers ? > Anyway I would not worry too much about it, making things simpler is better. > As more and more drivers become GLDv3, this is even less of an issue. As Jim said, it's optional because a DLPI consumer is always free to close a DLPI stream -- and in fact, most DLPI userland consumers (dhcpagent, snoop, ifconfig) do not bother doing a DL_DETACH. > P.S. If you see on10, the result is still the same, we probably don't > send detach. We just do a sequence of ill_dlpi_send an then do a qprocsoff. > So only the 1st request may go down. The same is true even in S9 and > earlier... This just seems to reaffirm my case for removing the DL_DETACH handling from IP. -- meem
