On Thu, Jan 04, 2007 at 09:04:29AM -0800, Ben Greear wrote: > Jarek Poplawski wrote: > >On Thu, Jan 04, 2007 at 09:27:07PM +1100, Herbert Xu wrote: > > > >>On Thu, Jan 04, 2007 at 09:50:14AM +0100, Jarek Poplawski wrote: > >> > >>>Could you explain? I can see some inet_rtm_newaddr > >>>interrupted. For me it could be e.g.: > >>> > >>>after > >>>vconfig add eth0 9 > >>> > >>>ip addr add dev eth0.9 ... > >>> > >>Whether eth0.9 is up or not does not affect this at all. The spin > >>locks are initialised (and used) when the first IPv4 address is added, > >>not when the device comes up. > >> > > > >I understand this. I consider IFF_UP as a sign all > >initialisations (open functions including) are > >completed and there is permission for working (so > >logically, if I would do eth0.9 down all traffic > >should be stopped, what probably isn't true now). > > > It is certainly valid for an interface to be IF_UP, but have no IP > address. My application > does bring the network device up before it assigns the IP, for instance.
Yes, but I think in any case it isn't races safe now with vlans. I thought more about the reverse situation where skb->dev !IFF_UP could be unnecessarily processed. But the same should be valid according to the rest of initializations which are done during address assigning. > There may be other issues with IF_UP, but that could be handled with a > different > investigation. If you have a particular test case that fails with > 802.1Q VLANs, then > I will be happy to work on it... Sorry, I even didn't use this yet... Wish you sunny weekend, Jarek P. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html