[ovs-dev] [PATCH] dpif-linux: Don't reset kernel upcall_pids unintentionally.

Ben Pfaff blp at nicira.com
Sat Oct 8 00:57:58 UTC 2011


On Fri, Oct 07, 2011 at 05:05:15PM -0700, Jesse Gross wrote:
> On Fri, Oct 7, 2011 at 4:42 PM, Ben Pfaff <blp at nicira.com> wrote:
> > Commit b063d9f0 "datapath: Use unicast Netlink sockets for upcalls" that
> > introduced an 'upcall_pid' member into struct dpif_linux_vport, struct
> > dpif_linux_dp, and struct dpif_linux_flow neglected to do so only if the
> > member was nonzero. ??This caused every datapath, vport, and flow operation
> > to supply an upcall_pid. ??In particular, the netdev_set_config() called at
> > startup when a vport already existed caused the upcall_pid for that vport
> > to be reset to 0, which in turn caused all packets received on the vport to
> > be dropped instead of forwarded to ovs-vswitchd.
> >
> > Reported-by: Shih-Hao Li <shli at nicira.com>
> 
> I think we actually want to distinguish between unset and zero.  When
> the listen_mask indicates that a packet type shouldn't be received
> then we intentionally generate an upcall_pid of 0 to shut off those
> types of upcalls.  Most of dpif-linux.c deals with this by simply
> always including the appropriate upcall_pid but that was missed for
> the calls in netdev-vport.  At this point, nothing ever turns off
> parts of listen_mask, so it doesn't really matter but that was the
> intention.

I actually understood these two cases as I wrote up the commit, but I
didn't see anything that currently needed to take advantage of it so I
ignored it.

I can fix it up to separate "no change" and "set to zero", though, if
you prefer.



More information about the dev mailing list