> >OK -- I'm curious though: what's wrong with my explanation above that > >ipsq_try_enter() will always trivially succeed because ipsq_writer == > >curthread && reentry_ok? > > > I think you said the same thing in a different way. I tried to explain the > reasoning in a different way to come to the same conclusion.
I see. > >I still don't see the problem -- e.g., when ip_rput_dlpi_writer() > >processes a DL_NOTE_LINK_UP, it checks to see if it actually represents a > >link state change. If not, it's ignored. > > In this case there may be no harm, at worst we may end up doing some > extra work, for example if the driver sent up a DL_NOTE_LINK_DOWN > followed by DL_NOTE_LINK_UP on getting a DL_BIND. Yep. > To me, the test is whether the DL_NOTE is truly asynchronous or in > response to some IP request. If it is the former then it is a > NEW_OP. Otherwise it is CUR_OP. I guess the difficulty is that we > don't really know. The DL_NOTE may be sent truly asynchronously when a > link goes down as pulling a cable, or in response to IP asking the > driver to turn the link on or off. My view is that DL_NOTIFY_IND's are inherently asynchronous and cannot be correlated with any specific previous request. That is, regardless of my new code, if IP gets a DL_NOTE_LINK_DOWN message, there's no way for it to know whether it was because it asked the link to be brought down, or whether a switch was powered off at just the right moment. So, if there's a need for a request/response protocol for specific operations (such as forcing a link down) then let's add one rather than complicate the notification logic. But so far there seems no need, so I don't see any cause for concern here. > ipif_down() -> ipif_down_delete_ire, ire_walk_ill_mrtun should take care > of it, since you are downing > all the ipifs of the ill. I see. I've updated http://atlantic.east/ws/meem/physaddr/webrev; please let me know if the revised ip_reprocess_ioctl() and ill_set_phys_addr_tail() match what you wanted. -- meem
