> > http://zhadum.east.sun.com/ws/clearview/clearview-ipmpdev/webrev
>
> I took me a while to go back and wrap my head around this code, and
> based on our conversation yesterday, I think the fix makes sense. I
> don't see any obvious issues. One tricky bit was figuring out how we're
> sure that we won't accidentally neglect to start the mld timers in some
> cases, but metaphorically speaking, I believe that the last one to leave
> the room will indeed shut off the lights.
Yes, and by having the last one do it we know there's no risk of deadlock.
I've updated the webrev with some comment fixes to the IPSQ fix, and a
couple of other fixes:
1. A number of old comments in in.mpathd referred to "NIC" where
it either meant "IP interface" or "datalink"; I've cleaned
these up.
2. Some diagnostic messages from in.mpathd were a little hard to
parse, and have been revised (I noticed these while updating
the in.mpathd manpage).
3. In the edge case where multicast probes are being used and
there's a group failure (e.g., a switch goes down), then
in.mpathd fails the group and all the interfaces in the group,
but ipmpstat confusingly reports a PROBE state of "unknown".
While this is not incorrect (in.mpathd no longer has probe
targets since the group has failed), it can cause confusion.
As such, I've reordered the tests in ifprobestate() so that
ipmpstat reports a PROBE state of "failed".
4. I've updated the comments for several IFF_* constants in
<net/if.h> to match the comments I'm providing in the manpage
updates.
5. As part of the fix for 6775871, I added an ASSERT() that
ire_arpresolve() is only passed IRE_CACHE entries. It turns
out there's a Nevada edge-case where it's erroneously passed
IRE_BROADCAST entries, covered by 6782947. Since that bug will
take a while to fix, I've removed the ASSERT() for now so that
we can continue with our testing.
The webrev has been updated.
--
meem
