configure: Remove --with-build-number.

From early days, Nicira used the --with-build-number option to configure to
stamp our internal builds.  We've since switched to another scheme, so
this option is obsolete.

Good riddance.

Signed-off-by: Ben Pfaff <blp@nicira.com>
idl: Move vswitch-idl to libopenvswitch.

This is cleaner then having multiple programs build the idl
independently.

Signed-off-by: Ethan Jackson <ethan@nicira.com>
netdev-linux: Fix use-after-free when netdev_dump_queues() deletes queues.

iface_configure_qos() passes a callback to netdev_dump_queues() that can
delete queues.  The netdev-linux implementation of this function was
unprepared for the callback to delete queues, so this could cause a
use-after-free.  This fixes the problem in netdev_linux_dump_queues() and
documents that netdev_dump_queues() implementations must support deletions
in the callback.

Found by valgrind:

==1593== Invalid read of size 8
==1593==    at 0x4A8C43: netdev_linux_dump_queues (hmap.h:326)
==1593==    by 0x4305F7: bridge_reconfigure (bridge.c:3084)
==1593==    by 0x431384: bridge_run (bridge.c:1892)
==1593==    by 0x432749: main (ovs-vswitchd.c:96)
==1593==  Address 0x632e078 is 8 bytes inside a block of size 32 free'd
==1593==    at 0x4C240FD: free (vg_replace_malloc.c:366)
==1593==    by 0x4A4D74: hfsc_class_delete (netdev-linux.c:3250)
==1593==    by 0x42AA59: iface_delete_queues (bridge.c:3055)
==1593==    by 0x4A8C8C: netdev_linux_dump_queues (netdev-linux.c:1881)
==1593==    by 0x4305F7: bridge_reconfigure (bridge.c:3084)
==1593==    by 0x431384: bridge_run (bridge.c:1892)

Bug #10164.
Reported-by: Ram Jothikumar <ram@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
cfm: Support random VLAN tag for CCM PDUs.

CCM PDUs may take a different path through the network depending on
the VLAN tag they carry.  In order to exercise these paths, it
may be advantageous to use a random VLAN tag.

Signed-off-by: Ethan Jackson <ethan@nicira.com>
xenserver: Verify updates in ovs-xapi-sync.

This prevents potential race conditions when updating database
tables.

Signed-off-by: Ethan Jackson <ethan@nicira.com>
ovs-vsctl: Allow "fake bridges" to be created for VLAN 0.

A fake bridge for VLAN 0 is useful, because it provides a way to create
access ports for VLAN 0.  There is no good reason to prevent it.

NIC-464.
Reported-by: Rob Hoes <Rob.Hoes@citrix.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
learn: Initialize cookie_mask in constructed flow_mod.

Otherwise the "learn" action may not correctly set the cookie in flows that
it creates.

Found by valgrind.

Signed-off-by: Ben Pfaff <blp@nicira.com>
ofproto-dpif: Fix return type of rule_calculate_tag().

tag_type is currently uint32_t but using uint32_t directly is conceptually
wrong.

Signed-off-by: Ben Pfaff <blp@nicira.com>
hmap: New function hmap_contains().

This is useful in a situation where one knows that an hmap_node is in some
hmap, but it's not certain which one, and one needs to know whether it is
in a particular one.  This is not a very common case; I don't see any
potential users in the current tree, although an upcoming commit will add
one.

Signed-off-by: Ben Pfaff <blp@nicira.com>
ofproto-dpif: Avoid segfault deleting facets that execute LEARN actions.

"ovs-ofctl del-flows <bridge>" can result in the following call path:

  delete_flows_loose() in ofproto.c
    -> collect_rules_loose() -- uses 'ofproto_node' inside 'struct rule'
    -> rule_destruct() in ofproto-dpif.c
      -> facet_revalidate()
        -> facet_remove()
          -> facet_flush_stats()
            -> facet_account()
              -> xlate_actions()
                -> xlate_learn_action()
                  -> ofproto_flow_mod() back in ofproto.c
                    -> modify_flow_strict()
                      -> collect_rules_strict() -- also uses 'ofproto_node'

which goes "boom" when we fall back up the call chain because the nested
use of ofproto_node steps on the outer use of ofproto_node.

This commit fixes the problem by refusing to translate "learn" actions
within facet_flush_stats(), breaking the doubled use.

Another possible approach would be to switch to another way to keep track
of rules in the flow_mod implementations, so that there'd be no fighting
over 'ofproto_node'.  But then "ovs-ofctl del-flows" might still leave some
flows around (ones created by "learn" actions as flows are accounted as
facets get deleted), which would be surprising behavior.  And it seems in
general a bad idea to allow recursive flow_mods; the consequences have not
been carefully thought through.

Before this commit, one can reproduce the problem by running an "hping3"
between a couple of VMs plus the following commands on OVS in the middle.
Sometimes you have to run them a few times:

    ovs-ofctl del-flows br0
    ovs-ofctl add-flow br0 "table=0 actions=learn(table=1, \
              idle_timeout=600, NXM_OF_VLAN_TCI[0..11], \
              NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[], \
              output:NXM_OF_IN_PORT[], fin_idle_timeout=10), resubmit(,1)"
    ovs-ofctl add-flow br0 "table=1 priority=0 actions=flood"

This commit has a side effect that leftover unaccounted packets no longer
update the timeouts in MAC learning actions in some cases, when the facets
that cause updates are deleted.  At most one second of updates should  be
lost.

Bug #10184.
Reported-by: Michael Mao <mmao@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
ofproto-dpif: Fix tag caching for learned flows.

This code in xlate_table_action() is supposed to tag flows in tables that
have special forms so that changes do not require revalidating every flow.
When rule->tag is nonzero, its value can be used, because we know in this
case that rule->cr.wc is the same as table->other_table->wc and that thus
rule->tag caches the return value of the rule_calculate_tag() expression.
When rule->tag is zero (a "catchall" rule) we need to calculate the tag
manually because we have no way to cache it in that case.

I discovered this bug by running an "hping3" between a couple of VMs plus
the following commands on OVS in the middle:

    ovs-ofctl del-flows br0
    ovs-ofctl add-flow br0 "table=0 actions=learn(table=1, \
              idle_timeout=600, NXM_OF_VLAN_TCI[0..11], \
              NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[], \
              output:NXM_OF_IN_PORT[], fin_idle_timeout=10), resubmit(,1)"
    ovs-ofctl add-flow br0 "table=1 priority=0 actions=flood"

Without this patch, flows don't get properly invalidated upon initial MAC
learning, so one sees warnings like the following:

    in_port(2),eth(src=50:54:00:00:00:05,dst=50:54:00:00:00:07),
    eth_type(0x0800),ipv4(src=192.168.0.1,dst=192.168.0.2,proto=6,tos=0,
    ttl=64,frag=no),tcp(src=13966,dst=0): inconsistency in subfacet
    (actions were: 3,0,1) (correct actions: 1)

This patch fixes the problem and thus avoids these warnings.

Signed-off-by: Ben Pfaff <blp@nicira.com>
documentation: use correct rundir in INSTALL.Linux to terminate OVS

This patch fixes a minor documentation flaw where INSTALL.Linux uses
incorrect path to find ovsdb-server and ovs-vswitchd PIDs. The default
rundir is actually /usr/local/var/run/openvswitch/ instead of
/usr/local/var/run/.

Signed-off-by: Ansis Atteka <aatteka@nicira.com>
WHY-OVS: Update to reflect OVS's inclusion in Linux 3.3.

Signed-off-by: Justin Pettit <jpettit@nicira.com>
Suggested-by: Martin Casado <casado@nicira.com>