Peter Memishian wrote: > > 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. > > Because of ...? > Because quite a bit of the mac and dls state is protected by the perimeter. If we need to access that state it would be an issue. Currently I have been able to get away with it, but I am not sure if that would hold in the long run. You can take a look at dls_devnet_stat_update(). The webrev is at
http://jurassic-x4600.sfbay/net/infotech/export/fix-ws/webrev/ I have just started a gldv3 test suite run. Cathy: Can you please take a look at the webrev, since most of the fix is in dls_mgmt.c > > 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. > > So then I'd be forced to defer the KSTAT_UPDATE to a taskq? That'd be > pretty ugly. > > Also, how does all of this fit in with the rules described atop mac.c? > That doesn't talk about the kstat interface. I didn't anticipate the usage either. But before that if you can check whether the fix works for you, we can then see... Thirumalai
