I forgot. Thanks for the reminder. I've done it now.
On Wed, May 07, 2014 at 02:11:23PM -0700, Andy Zhou wrote: > I assume you will back port this to branch-2.2 > > On Wed, May 7, 2014 at 1:13 PM, Ben Pfaff <b...@nicira.com> wrote: > > 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
