On Thu, Jan 04, 2007 at 09:04:29AM -0800, Ben Greear wrote:

Jarek Poplawski wrote:

quoted

On Thu, Jan 04, 2007 at 09:27:07PM +1100, Herbert Xu wrote:
 

quoted

On Thu, Jan 04, 2007 at 09:50:14AM +0100, Jarek Poplawski wrote:
   

quoted

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.