On Mon, 04 Jan 2010 18:17:48 -0500 Anurag Maskey <Anurag.Maskey at Sun.COM> wrote:
> > >> http://zhadum.east/export/ws/am223141/checkout-area/nwam1-fixes/webrev/ > >> > >> 13416 "dhcp,static" ipv4 address not working > >> http://defect.opensolaris.org/bz/show_bug.cgi?id=13416 > >> > >> The routing socket listener threads should listen for RTM_CHGADDR and > >> RTM_FREEADDR messages. Also, the routing socket messages do not contain > >> the lifnum anymore, just the interface name is present; so we walk the > >> interface list and match the address to determine the lifnum. > >> > > routing_events.c:232,340 What is this? We should treat this like an XXX > > and remove or make more meaningful. > > > that is an artifact of the phase 0.5 code. I've removed it. > > I am guessing the following comments refer to routing_events.c (and not > interface.c) ACCEPT > > > interface.c:225,243-252 When I got to 243 I remembering that back at > > 225 I wondered if this would work for at least deladdr. I thought > > routing messages were async with the actual changes so that by the type > > you got the deladdr the address might/probably wouldn't be on the > > interface independent of how it was assigned. > > > This is a good point. I didn't realize that. The routing socket > messages are asynchronous. I went back and looked at the debug logs and > found cases where the ifname could not be found because the address on > the interface is different than what's on the routing socket message. > This does present a major issue for us. The routing socket messages > don't contain the lifnum anymore. The lifnums are required to get the > flags for the correct logical interface in > nwamd_ncu_handle_if_state_event(). I am gonna have to think about > this. Anyone have any idea on how to deal with the situation here? The > problem is figuring out what lifnum the routing socket message is for. Keep a way around to map the triple (address, name, lifnum) and a shadow of the flags. Use that structure to see if you can find the interface. If it is still around use the existing flags otherwise the shadow for any decisions. Since this is really only an issue as the address is disappearing that seems sufficient? > > > interface.c:271,358 These bother me. Major failures (inability to get > > information or to enqueue a state change) happen and we do nothing > > about it. Both of these if they ever happen will make the system act > > strangely. > > > yes, we do log the failure and then move on with the failures here (and > other places in nwamd). any suggestions what should be done? I saw we logged. But we really don't recover. In the first case I think we can (re)cover by keeping a shadow copy of the information. In the second case we could create our own event allocator. Preallocate a set number of events. If they were all used up we could just block waiting for one to be released which should happen soon. Michael > > Anurag >
