Garrett D'Amore wrote: > I'm planning on putting back the fixes in the following webrev. This > changes the notification in Nemo somewhat, hopefully to be a lot more > robust. > > It fixes in particular 6508900, which basically states that i_mac_notify > can fail, and when it does, it spams the log. (Worse, it can fail to > call qenable() which could lead to an apparent hang on transmit, etc.) > > (It can fail due to resource shortage.) My solution is to use a > separate thread, bit mask, and condition variable. > > The webrev is at http://cr.opensolaris.org/~gdamore/mac-notify/ > > Have a look if you're interested. (I think I have my 2 needed > reviewers, but I won't complain if others give me feedback.) > > -- Garrett > Garrett,
I had a look of your change, and I have several questions: - What prevent new mac notifications come in between Line 1429 and Line 1441? If new mac notifications can come in, the thread will exit because the check on Line 217 would passes, then the system will wait for ever on Line 1444-1445? I think more reasonable way is for i_mac_notify() to do nothing if ((bits & (1 << MAC_NNOTE)) != 0), and to have i_mac_notify_thread() to only exit after it finishes to process each notification bits. - Why we need the notification quiesce twice? One on Line 1426-1429, another on Line 1439-1448? Thanks - Cathy _______________________________________________ networking-discuss mailing list [email protected]
