Thanks. I pushed this one to master and branch-1.[3456].
I see that Pravin already reviewed it but the second patch can wait
until tomorrow at least.
On Mon, Feb 27, 2012 at 05:28:22PM -0800, Ethan Jackson wrote:
> 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 <b...@nicira.com> 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 <b...@nicira.com>
> > ---
> > 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
> > dev@openvswitch.org
> > http://openvswitch.org/mailman/listinfo/dev
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
