This looks good to me, I'm not planning to review the second patch of the series.
Ethan On Mon, Feb 27, 2012 at 17:03, Ben Pfaff <[email protected]> wrote: > The kernel will report a vport with the given name in any datapath, but > userspace only wants a vport with the given name in a specific datapath. > Receiving information on a vport in an unexpected datapath yields bizarre > and hard-to-debug problems. > > Signed-off-by: Ben Pfaff <[email protected]> > --- > lib/dpif-linux.c | 12 +++++++++--- > 1 files changed, 9 insertions(+), 3 deletions(-) > > diff --git a/lib/dpif-linux.c b/lib/dpif-linux.c > index ad67ae7..7013bc5 100644 > --- a/lib/dpif-linux.c > +++ b/lib/dpif-linux.c > @@ -418,9 +418,15 @@ dpif_linux_port_query__(const struct dpif *dpif, > uint32_t port_no, > > error = dpif_linux_vport_transact(&request, &reply, &buf); > if (!error) { > - dpif_port->name = xstrdup(reply.name); > - dpif_port->type = xstrdup(netdev_vport_get_netdev_type(&reply)); > - dpif_port->port_no = reply.port_no; > + if (reply.dp_ifindex != request.dp_ifindex) { > + /* A query by name reported that 'port_name' is in some datapath > + * other than 'dpif', but the caller wants to know about 'dpif'. > */ > + error = ENODEV; > + } else { > + dpif_port->name = xstrdup(reply.name); > + dpif_port->type = xstrdup(netdev_vport_get_netdev_type(&reply)); > + dpif_port->port_no = reply.port_no; > + } > ofpbuf_delete(buf); > } > return error; > -- > 1.7.2.5 > > _______________________________________________ > dev mailing list > [email protected] > http://openvswitch.org/mailman/listinfo/dev _______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
