When dpif_linux_refresh_channels() refreshes the set of channels when
the number of handlers changes, it destroys all the dpif's channels and
sets dpif->uc_array_size to 0. If the port dump later in the function
turns up no ports (which generally indicates a bug), then no channels will
be allocated and thus dpif->uc_array_size will remain 0 and 'channels' will
be null in each handler. This is self-consistent, at least, but
dpif_linux_port_get_pid__() was still willing in this situation to
try to access element 0 of the set of channels, dereferencing a null
pointer.
This fixes the problem.
I encountered this while looking at a bug that I had introduced during
development that caused the port dump to always be empty. It would be
difficult to encounter in normal use.
Signed-off-by: Ben Pfaff <b...@nicira.com>
---
lib/dpif-linux.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/dpif-linux.c b/lib/dpif-linux.c
index bc284ab..ba4294f 100644
--- a/lib/dpif-linux.c
+++ b/lib/dpif-linux.c
@@ -825,7 +825,7 @@ dpif_linux_port_get_pid__(const struct dpif_linux *dpif,
odp_port_t port_no,
uint32_t port_idx = odp_to_u32(port_no);
uint32_t pid = 0;
- if (dpif->handlers) {
+ if (dpif->handlers && dpif->uc_array_size > 0) {
/* The ODPP_NONE "reserved" port number uses the "ovs-system"'s
* channel, since it is not heavily loaded. */
uint32_t idx = port_idx >= dpif->uc_array_size ? 0 : port_idx;
--
1.7.10.4
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
