> Nothing seems abnormal with this except for the fact that the
> SIOCSLIFNAME ioctl is not completing. Why is it stuck? There is no
> other kernel thread processing this ioctl stuck on any lock or waiting
> to enter the ipsq. Something seems deeply amiss with the ipsq logic
> somewhere, and I could use a hand figuring this out.
>
> The ipsq_t in question has no current writer, but has a pending mp:
>
> > 0xcfa6b100::print ipsq_t
> {
> ipsq_lock = {
> _opaque = [ 0, 0 ]
> }
> ipsq_reentry_cnt = 0
> ipsq_writer = 0
> ipsq_flags = 0
> ipsq_xopq_mphead = 0xdd270a00
> ipsq_xopq_mptail = 0xdd27fac0
> ipsq_mphead = 0
> ipsq_mptail = 0
> ipsq_current_ioctl = 0
> ipsq_current_done = 0 (B_FALSE)
> ipsq_current_ipif = 0xd9c0bb4c
> ipsq_pending_ipif = 0xd9c0bb4c
> ipsq_pending_mp = 0xdd270840
> ipsq_next = 0
> ipsq_refs = 0x1
> ipsq_phyint_list = 0xcfdb524c
> ipsq_split = 0 (B_FALSE)
> ipsq_waitfor = 0x2
> ...
>
> The fact that ipsq_current_ioctl is 0 is odd to me. Why is this ipsq
> stuck if there's no pending ioctl?
You've deadlocked. The problem is that ip_join_allmulti() has bumped the
refcount on the ill and is waiting to enter the IPSQ, while the current
thread inside the IPSQ is waiting for the ill refcounts to drop
(ipsq_waitfor is 2 AKA ILL_DOWN). This is exactly the sort of problem I
was worried about when I warned about using ipsq_enter() a few weeks back.
You should use ipsq_try_enter(), which will enqueue the request if it
cannot immediately complete.
--
meem
