lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 5 Jan 2007 14:55:05 +0100
From:	Jarek Poplawski <>
To:	Ben Greear <>
Cc:	Herbert Xu <>,
	David Stevens <>,
Subject: Re: BUG: soft lockup detected on CPU#0!  ( plus hacks)

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
More majordomo info at

Powered by blists - more mailing lists