Peter Memishian wrote: > > > > I think dls_devnet_stat_update doen't need the mac perimeter itself. > > > > Instead it needs to increment the dd_ref of the dls_devnet_t to make > > > > sure it can't disappear. That should synchronize > > > > dls_devnet_stat_create/update/destroy functions. A related thing is > that > > > > the functions will have to drop i_dls_devnet_lock before calling > kstat > > > > functions so that the order is kstat internal lock (or perimeter) -> > > > > i_dls_devnet_lock. I will try this and let you know, so that you can > try > > > > the stress test on it (unless you have already coded up a fix). > > > > > > That'd be great -- I have not coded up a fix. Is this really the only > > > case in which IP may make a downcall which requires entering the > perimeter? > > > > Hopefully. (sans bugs) At a high level DLPI control paths and ioctls > > that need the mac perimeter go through the DLD task queue mechanism. The > > function call based capability negotiation factors the perimeter hierarchy. > > I see. Do you have an ETA on when you'll have a fix for me to try? > > Thanks! >
I am half way through it, so if it works, it should be ready in a few hours. But after looking at it a bit more, I am wondering if this is a new usage issue. Currently KSTAT_UPDATE seems to be mostly driven from the top by a userland thread going down and doing a kstat_ioctl in which case we won't have the deadlock you pointed out. In my proposed fix (yet to try out), I avoid grabbing the mac perimeter in the call from KSTAT_UPDATE. But I am not sure if this may be too limiting in the future. The other option is to formalize the current usage model and limit calling KSTAT_UPDATE to threads coming down directly from the top (i.e. prohibit interrupt threads or upcall threads from making this call) which could also be limiting. Thirumalai
