On Thu, Jul 12, 2012 at 04:30:13PM -0700, Ansis Atteka wrote:
> On Thu, Jul 12, 2012 at 4:05 PM, Ben Pfaff <[email protected]> wrote:
>
> > The implementation of "ofctl/block" used a nested poll loop, with an inner
> > call to unixctl_server_run(). This poll loop always ran inside an outer
> > call to unixctl_server_run(), since that's the context within which unixctl
> > command implementations run. That means that, if a unixctl connection got
> > closed within the inner poll loop, and the outer poll loop happened to be
> > processing the same unixctl connection, then the outer poll loop would
> > dereference data in the freed connection.
> >
> > The simplest solution is to avoid a nested poll loop, so that's what this
> > commit does.
> >
> > This didn't cause a failure in the unit tests on i386 (which is why I
> > didn't catch it before pushing) but it did, reliably, on x86-64, and it
> > showed up in valgrind everywhere.
> >
> > Signed-off-by: Ben Pfaff <[email protected]>
[...]
> > static void
> > ofctl_unblock(struct unixctl_conn *conn, int argc OVS_UNUSED,
> > - const char *argv[] OVS_UNUSED, void *block_)
> > + const char *argv[] OVS_UNUSED, void *blocked_)
> > {
> > - struct block_aux *block = block_;
> > + bool *blocked = blocked_;
> >
> > - if (!block->blocked) {
> > - unixctl_command_reply(conn, "not blocking");
> > - } else {
> > - block->blocked = false;
> > + if (*blocked) {
> > + *blocked = false;
> > unixctl_command_reply(conn, NULL);
> > + } else {
> > + unixctl_command_reply(conn, "not blocking");
> >
> Shouldn't this be "not unblocking"? maybe I am missing something....
It's meant to report that we're currently not blocking, so that
there's nothing to unblock.
In retrospect, that's confusing.
I changed the message to "already unblocked". I hope that's better.
> Other than that fixes the build for me and looks good.
Thanks. I'll push this soon.
_______________________________________________
dev mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/dev
