On Wed, May 07, 2014 at 01:01:56PM -0700, Andy Zhou wrote: > On Wed, May 7, 2014 at 12:13 PM, Andy Zhou <az...@nicira.com> wrote: > > I am looking at it. > > > > On Tue, May 6, 2014 at 12:50 PM, Ben Pfaff <b...@nicira.com> wrote: > >> Commit 2a3fb0aa3c (lacp: Don't lock potentially uninitialized mutex in > >> lacp_status().) fixed one bug related to acquiring the file scope 'mutex' > >> without initializing it. However, there was at least one other, in > >> lacp_unixctl_show(). One could just fix that one problem, but that leaves > >> the possibility that I might have missed one or two more. This commit > >> fixes the problem for good, by adding a helper that initializes the mutex > >> and then acquires it. > > This makes the lacp locking somewhat different from other modules. > > The logic looks fine. > Acked-by: Andy Zhou <az...@nicira.com>
Thanks. I think it's OK for the locking to be a little different here. > >> It's not entirely clear why 'mutex' is a recursive mutex. I think that it > >> might be just because of the callback in lacp_run(). An alternate fix, > >> therefore, would be to eliminate the callback and therefore the need for > >> runtime initialization of the mutex. > > It seems when we send a lacp packet out while holding the mutex, > compose_output_action__ could > send it right back lacp via process_special(). May be we can queue up > the packets in lacp_run, > and call send_pdu outside of lock? Yes, that's what I concluded too. I'll push this in a minute. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
