Panic in propagate_priority() [5.3-BETA2] (fwd)

[Patrick Guelat]

On Wed, 1 Sep 2004, John Baldwin wrote:

> Seems the thread has an inhibitor of TDI_IWAIT which it should never be in
> when it gets to this point.  Perhaps a lock was leaked from an interrupt
> handler.  Running with INVARIANTS + WITNESS might help to catch this.
> WITNESS especially might help as it would give a warning about what handler
> returns with a lock held and which lock and where the lock was acquired.

Tried with INVARIANTS and WITNESS .. no lor etc. happening, just the
panic in propagate_priority(). This 'rip' lock is used both by netinet
and netinet6, might this be a problem in this case ? OSPF6 uses a raw-ip
socket to send ipv6 dgrams which are then encapsulated in gif0 in a raw ipv4
packet maybe using the lock twice ?

BTW: This was working on 5.2-CURRENT with a kernel from around mid june.

-Patrick

I wrote:

> I'm trying to run OSPF6 on a gif-tunnel between a Cisco-7206VXR
> and a box running 5.3-BETA2 and get a panic everytime I start ospf6d (from 
> /usr/ports/net/quagga).
> 
> It always ends in a panic in propagate_priority(), sometimes I get the 
> following panic-message:
> 
>    panic: process 37 (swi1: net):1 holds rip but isn't blocked on a lock
> 
> "rip" is the lock defined in netinet/raw_ip.c which is also used by
> the netinet6/raw_ip6.c.
> 
> Tracing the userland-part nearly always ends at the sendmsg(2)
> call on the raw socket, but sometimes the panic also occurs some time before 
> ospf6d sends it's first hello message (maybe during
> the reception of the ipv6 ospf packet from the cisco ?)