> 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 ...? > 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? -- meem
