Herbert Xu wrote: > David Miller <[EMAIL PROTECTED]> wrote: > >>I think I see what might be the problem, nlk->cb_mutex is set >>to "rtnl_mutex" and this is used for other purposes in various >>code paths here, maybe there is a double mutex_unlock() or >>similar due to that? > > > Indeed, the RTNL is held during the processing of all RTNETLINK > messages so we'd be trying to lock it recursively here which is > not allowed.
No, it is released before calling netlink_dump_start(). > Actually I'm not quite sure what the benefit is for allowing an > override CB mutex. Since we still have to take it and we always > allocate memory for a mutex anyway this would seem to be strictly > worse than just using our own mutex. The idea was that netlink families that don't want to consistently hold the same mutex used for queue processing during the entire dump operation can still have per-socket mutexes just to protect the callback data and have concurrent dump continuations. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
