On Mon, 2008-09-08 at 08:02 -0700, Erik Nordmark wrote: > Sebastien Roy wrote: > > > All of these cases could be addressed easily if we either always had a > > conn_t, or the DB_CRED(mp) were accurate at the hook locations (except > > for kernel-generated packets...). Ignoring the fact that IP data-path > > refactoring will blow this all up, I know that the former isn't true > > today, but I wonder if the latter is. Do you know? Could (until > > data-path refactoring delivers) we simply use DB_CRED() in all cases > > instead of the source IP address? > > We do not set db_credp for all transmitted packets.
Drats. > And since it is a > scaling problem (crhold/crrele end up clobbering the same refcnt per > userid) there is work in Volo to further reduce use of db_credp. We > currently do set it all the time when TX is in use, but that doesn't > help here. Indeed. > > Thus I think the best thing you can do for now is the source address lookup. Agreed. > >> But if we do that things will not be symmetric with the receive side > >> (the destination zoneid on the receive side to be specific.) > >> For instance, while we can know the sending zoneid when SO_ALLZONES is > >> used, on the receive side it isn't until we hit the top of IP (looking > >> for a conn_t) that we can tell that SO_ALLZONES was used. Likewise for > >> the TX shared IP address; we do a fanout once we know the label. (Hmm we > >> do know the db_credp early on in ip_input with TX; I don't know if the > >> cred has the zoneid set at that point in time though.) > > > > tsol_get_pkt_label() fixes the label in the db_credp early on (early > > enough), then the ipobs code does a tsol_packet_to_zoneid(mp) which > > turns this label to an accurate zoneid. > > Be careful in how db_credp is overloaded. > The db_credp set in tsol_get_pkt_label() is based on the *sender's* > label, and it isn't a complete db_credp (I think cr_zone might be NULL; > I remember being bitten by something in that space.) > In any case, that isn't always the same as the *receiving* zone; with > MLP the application might run in a zone which has a different label the > the sender. > > Thus it is the case that we do not know for sure the zone in which the > receiving application runs until we have located the conn_t. Okay, so this indeed needs to be looked at more carefully. It may very well be that we cannot reliably obtain correct zoneid's in the TX case. If that's true, then a compromise would be to document that the /dev/ipnet nodes do not receive any packets in TX non-global zones. > You could argue that the cases when we could get it wrong (by looking at > db_credp when TX is used are insignificant or unimportant; e.g., if TX > prevents ngzs from using snoop in any case (I don't know if TX does > that; just speculating.)) > > But my point is that some significant care is required in such an argument. Agreed. > > The PSARC materials (2006/475) contain some discussion on how > > DL_PROMISC_MULTI causes the ip module to enable DL_PROMISC_MULTI on the > > underlying device so that we can have observability of all multicast > > traffic, and not just the traffic associated with joined groups. > > But for both multicast and broadcast I assume you restrict it to ills on > which the zone has an ipif. Is that correct? The interface index of the received (or transmitted) packet must match the interface index associated with the node being observed. Does that answer your question? > >> In my head it also isn't clear how to handle certain transmitted packets > >> generated by the kernel. The tricky one is IPv6 ND packets where we've > >> had various attempts at determining the zoneid. The ND packets, just > >> like ARP packets, are essentially sent as a part of a service which is > >> shared for all the zones (the ARP and NCE information is shared for all > >> the zones.) However, the ND (and ARP) packets have a source IP address > >> which is assigned to some zone. I don't know if the current onnv-gate > >> code uses that as the zoneid passed to ip_output. > > > > Good question. The definition of "correctness" isn't all too clear to > > me either. Using the zoneid associated with the source address would > > allow zones to view ND packets sent on their behalf. On the other hand, > > since the "process" of neighbor-discovery is essentially in the global > > zone and the packets are generated from the global zone (but this is not > > well-defined, but then again zones in general are poorly defined), > > associating those packets with the global zone would not seem > > incorrect. :-( > > Zones are well-defined; it is merely shared-IP zones that have > definitional problems. Yes, and that's what I was thinking. My fingers accidentally wrote something more general and less in-line with my actual opinion. :-) Thanks, -Seb
