{"push_id":708532049,"size":5,"distinct_size":5,"ref":"refs/heads/master","head":"5bb08b0ef605a9b164399bd74a194ae1b921c3ea","before":"bd8baf47a11a00563f7096ea51f4fc9446a321c0","commits":[{"sha":"eaac0f22b95c34e99a4c14910359148726f9725c","author":{"email":"a5c95b3d7cb4d0ae05a15c79c79ab458dc2c8f9e@nicira.com","name":"Jesse Gross"},"message":"tunneling: Don't match on source IP address for native tunnels.\n\nWhen doing native tunneling, we look at packets destined to the\nlocal port to see if they match tunnel protocols that we should\nintercept. The criteria are IP protocol, destination UDP port, etc.\n\nHowever, we also look at the source IP address of the packets. This\nshould be a function of the port-based tunnel layer and not the\ntunnel receive code itself. For comparison, the kernel tunnel code\nhas no idea about the IP addresses of its link partners. If port\nbased tunnel is desired, it can be handled using the normal port\ntunnel layer, regardless of whether the packets originally came\nfrom userspace or the kernel.\n\nFor port based tunneling, this bug has no effect - the check is\nsimply redundant. However, it breaks flow-based native tunnels\nbecause the remote IP address is not known at port creation time.\n\nCC: Pravin Shelar <pshelar@nicira.com>\nReported-by: David Griswold <David.Griswold@overturenetworks.com>\nTested-by: David Griswold <David.Griswold@overturenetworks.com>\nSigned-off-by: Jesse Gross <jesse@nicira.com>","distinct":true,"url":"https://api.github.com/repos/commodo/ovs/commits/eaac0f22b95c34e99a4c14910359148726f9725c"},{"sha":"e3a4416aa5d706be158c6a2a1957616eb849d307","author":{"email":"6f50513b21952446fbc8c95a8f361b7aa434b7c7@nicira.com","name":"Ben Pfaff"},"message":"expr: Fix typo in comment.\n\nSigned-off-by: Ben Pfaff <blp@nicira.com>\nAcked-by: Andy Zhou <azhou@nicira.com>","distinct":true,"url":"https://api.github.com/repos/commodo/ovs/commits/e3a4416aa5d706be158c6a2a1957616eb849d307"},{"sha":"f08e39dd023ff27c32166b76d6906fbf20f78991","author":{"email":"6f50513b21952446fbc8c95a8f361b7aa434b7c7@nicira.com","name":"Ben Pfaff"},"message":"ofp-actions: Support mixing \"conjunction\" and \"note\" actions.\n\nIt doesn't make sense to mix \"conjunction\" actions with most other kinds\nof actions.  That's because flows with \"conjunction\" actions aren't ever\nactually executed, so any actions mixed up with them would never do\nanything useful.  \"note\" actions are a little different because they never\ndo anything useful anyway: they are just there to allow a controller to\nannotate flows.  It makes as much sense to annotate a flow with\n\"conjunction\" actions as it does to annotate any other flow, so this\ncommit makes this possible.\n\nRequested-by: Soner Sevinc <sevincs@vmware.com>\nSigned-off-by: Ben Pfaff <blp@nicira.com>\nAcked-by: Andy Zhou <azhou@nicira.com>","distinct":true,"url":"https://api.github.com/repos/commodo/ovs/commits/f08e39dd023ff27c32166b76d6906fbf20f78991"},{"sha":"daab0ae6bb558411f24cee6a7bb32599a5f9e363","author":{"email":"6f50513b21952446fbc8c95a8f361b7aa434b7c7@nicira.com","name":"Ben Pfaff"},"message":"ofproto: Fix use-after-free in bridge destruction with groups.\n\nGroups were not destroyed until after lots of other important bridge\ndata had been destroyed, including the connection manager.  There was an\nindirect dependency on the connection manager for bridge destruction\nbecause destroying a group also destroys all of the flows that reference\nthe group, which in turn causes the ofmonitor to be invoked to report that\nthe flows had been destroyed.  This commit fixes the problem by destroying\ngroups earlier.\n\nThe problem can be observed by reverting the code changes in this commit\nthen running \"make check-valgrind\" with the test that this commit\nintroduces.\n\nReported-by: Simon Horman <simon.horman@netronome.com>\nSigned-off-by: Ben Pfaff <blp@nicira.com>\nReviewed-by: Simon Horman <simon.horman@netronome.com>","distinct":true,"url":"https://api.github.com/repos/commodo/ovs/commits/daab0ae6bb558411f24cee6a7bb32599a5f9e363"},{"sha":"5bb08b0ef605a9b164399bd74a194ae1b921c3ea","author":{"email":"a5c95b3d7cb4d0ae05a15c79c79ab458dc2c8f9e@nicira.com","name":"Jesse Gross"},"message":"tunneling: Userspace datapath support for Geneve options.\n\nCurrently the userspace datapath only supports Geneve in a\nbasic mode - without options - since the rest of userspace\npreviously didn't support options either. This enables the\nuserspace datapath to send and receive options as well.\n\nThe receive path for extracting the tunnel options isn't entirely\noptimal because it does a lookup on the options on a per-packet\nbasis, rather than per-flow like the kernel does. This is not\nas straightforward to do in the userspace datapath since there\nis no translation step between packet formats used in packet vs.\nflow lookup. This can be optimized in the future and in the\nmeantime option support is still useful for testing and simulation.\n\nSigned-off-by: Jesse Gross <jesse@nicira.com>\nAcked-by: Ben Pfaff <blp@nicira.com>","distinct":true,"url":"https://api.github.com/repos/commodo/ovs/commits/5bb08b0ef605a9b164399bd74a194ae1b921c3ea"}]}