Re: [ovs-dev] [PATCH net] gso: do GSO for local skb with size bigger than MTU

于 2015年01月07日 03:11, Jesse Gross 写道: One of the reasons for only doing path MTU discovery >>for L3 is that it operates seamlessly as part of normal operation - >>there is no need to forge addresses or potentially generate ICMP when >>on an L2 network. However, this ignores the IP handling that is

Re: [ovs-dev] bug in flow stats for VLAN acceleration?

Ben, Thanks for addressing this issue. I found that it was just merged into master. I will verify the new behavior first and then start working on fixing NetFlow part. Will keep you posted. Regards, --- Motonori Shindo 2015-01-01 1:48 GMT+09:00 Ben Pfaff : > I sent out a patch that should fix

Re: [ovs-dev] [PATCH 1/8] datapath: Account for rename to vlan_insert_tag_set_proto()

On Tue, Jan 6, 2015 at 6:10 PM, Thomas Graf wrote: > __vlan_put_tag() was renamed to vlan_insert_tag_set_proto() with > the argument list kept intact. > > Upstream: 62749e ("vlan: rename __vlan_put_tag to vlan_insert_tag_set_proto") > Signed-off-by: Thomas Graf Looks good to me. Acked-by: Pravin

Re: [ovs-dev] [PATCH 1/6] vxlan: Allow for VXLAN extensions to be implemented

On Tue, Jan 6, 2015 at 6:05 PM, Thomas Graf wrote: > The VXLAN receive code is currently conservative in what it accepts and > will reject any frame that uses any of the reserved VXLAN protocol fields. > The VXLAN draft specifies that "reserved fields MUST be set to zero on > transmit and ignored

Re: [ovs-dev] [PATCH 2/6] vxlan: Group Policy extension

On Tue, Jan 6, 2015 at 6:05 PM, Thomas Graf wrote: > +struct vxlan_gbp { > +#ifdef __LITTLE_ENDIAN_BITFIELD > + __u8reserved_flags1:3, ... > + __be16 policy_id; > +} __packed; are you sure that compiler will be smart enough to do single short load when you pack u8 + struct vxlan_g

[ovs-dev] [PATCH 6/8] datapath: replace remaining users of arch_fast_hash with jhash

This patch effectively reverts commit 500f80872645 ("net: ovs: use CRC32 accelerated flow hash if available"), and other remaining arch_fast_hash() users such as from nfsd via commit 6282cd565553 ("NFSD: Don't hand out delegations for 30 seconds after recalling them.") where it has been used as a h

[ovs-dev] [PATCH 7/8] datapath: Account for new flags args of vxlan_sock_add()

The upstream commit 359a0ea ("vxlan: Add support for UDP checksums (v4 sending, v6 zero csums)") has introduced a new flags argument to vxlan_sock_add(). OVS does not pass any flags at this point, thus specyfing 0 will be compatible with both the old ipv6 bool and the new u32 flags argument. Upst

[ovs-dev] [PATCH 8/8] travis: Update build matrix to include latest stable kernels

Signed-off-by: Thomas Graf --- .travis.yml | 17 + 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/.travis.yml b/.travis.yml index 7056f54..1ffd15a 100644 --- a/.travis.yml +++ b/.travis.yml @@ -7,16 +7,17 @@ before_install: ./.travis/prepare.sh env: - OPTS="--

[ovs-dev] [PATCH 5/8] datapath: introduce rtnl ops stub

This stub now allows userspace to see IFLA_INFO_KIND for ovs master and IFLA_INFO_SLAVE_KIND for slave. Upstream: 5b9e7e16 ("openvswitch: introduce rtnl ops stub") Signed-off-by: Thomas Graf --- datapath/datapath.c | 9 - datapath/vport-internal_dev.c | 15 +++ dat

[ovs-dev] [PATCH 4/8] datapath: move vlan pop/push functions into common code

So it can be used from out of openvswitch code. Did couple of cosmetic changes on the way, namely variable naming and adding support for 8021AD proto. Note on backwards compatability: Unlike the upstream version, the backport of skb_vlan_push() does not support translating a hardware accelerated 8

[ovs-dev] [PATCH 3/8] datapath: move make_writable helper into common code

note that skb_make_writable already exists in net/netfilter/core.c but does something slightly different. Upstream: e219512 ("net: move make_writable helper into common code") Signed-off-by: Thomas Graf --- acinclude.m4 | 1 + datapath/actions.c

[ovs-dev] [PATCH 2/8] datapath: Add __vlan_insert_tag() compat helper if not available

Since older kernels do not have skb->vlan_proto, it is assumed that kernels which don't provide their own __vlan_insert_tag() will also not have skb->vlan_proto. The backwards compat function therefore only supports ETH_P_8021Q as the protocol type. Upstream: 15255a43 ("vlan: introduce __vlan_inse

[ovs-dev] [PATCH 1/8] datapath: Account for rename to vlan_insert_tag_set_proto()

__vlan_put_tag() was renamed to vlan_insert_tag_set_proto() with the argument list kept intact. Upstream: 62749e ("vlan: rename __vlan_put_tag to vlan_insert_tag_set_proto") Signed-off-by: Thomas Graf --- acinclude.m4 | 1 + datapath/actions.c

[ovs-dev] [PATCH 0/8 v3] Datapath backports to support 3.18.x, net, net-next

This series includes several backports which affect the datapath and brings it closer to upstream. It also allows to build the datapath against current net and net-next kernels. v3: - As requested by Pravin: - Convert compat code to use vlan_insert_tag_set_proto() - Remove any reference to

[ovs-dev] [PATCH 5/6] openvswitch: Rename GENEVE_TUN_OPTS() to TUN_METADATA_OPTS()

A subsequent patch will introduce VXLAN options. Rename the existing GENEVE_TUN_OPTS() to reflect its extended purpose of carrying generic tunnel metadata options. Signed-off-by: Thomas Graf --- net/openvswitch/flow.c | 2 +- net/openvswitch/flow.h | 14 +++--- net/openv

[ovs-dev] [PATCH 6/6] openvswitch: Support VXLAN Group Policy extension

Introduces support for the group policy extension to the VXLAN virtual port. The extension is disabled by default and only enabled if the user has provided the respective configuration. ovs-vsctl add-port br0 vxlan0 -- \ set Interface vxlan0 type=vxlan options:exts=gbp The configuration in

[ovs-dev] [PATCH 2/6] vxlan: Group Policy extension

Implements supports for the Group Policy VXLAN extension [0] to provide a lightweight and simple security label mechanism across network peers based on VXLAN. The security context and associated metadata is mapped to/from skb->mark. This allows further mapping to a SELinux context using SECMARK, to

[ovs-dev] [PATCH 4/6] vxlan: Fail build if VXLAN header is misdefined

Due to the complexity of struct vxlanhdr, protect against unwanted and undesired changes by failing the build if the size of the struct changes. Signed-off-by: Thomas Graf --- drivers/net/vxlan.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c inde

[ovs-dev] [PATCH 3/6] vxlan: Only bind to sockets with correct extensions enabled

A VXLAN net_device looking for an appropriate socket may only consider a socket which has the exact set of extensions enabled. If none can be found, a new socket must be created. The OVS VXLAN port is kept unaware of extensions at this point. Signed-off-by: Thomas Graf --- drivers/net/vxlan.c

[ovs-dev] [PATCH 1/6] vxlan: Allow for VXLAN extensions to be implemented

The VXLAN receive code is currently conservative in what it accepts and will reject any frame that uses any of the reserved VXLAN protocol fields. The VXLAN draft specifies that "reserved fields MUST be set to zero on transmit and ignored on receive.". Retain the current conservative parsing behav

[ovs-dev] [PATCH 0/6 net-next] VXLAN Group Policy Extension

Implements supports for the Group Policy VXLAN extension [0] to provide a lightweight and simple security label mechanism across network peers based on VXLAN. The security context and associated metadata is mapped to/from skb->mark. This allows further mapping to a SELinux context using SECMARK, to

Re: [ovs-dev] [PATCH] Vagrant: Add steps when pulling from git tree to INSTALL.md

On 01/06/15 at 09:45pm, Flavio Leitner wrote: > On Wednesday, January 07, 2015 12:35:45 AM Thomas Graf wrote: > > I left this out because other similar sections such as testsuite, ryu, > > oftest, ... also assume a configured (and built) local source tree. > > What about create a small section to

Re: [ovs-dev] [PATCH] Vagrant: Add steps when pulling from git tree to INSTALL.md

On Wednesday, January 07, 2015 12:35:45 AM Thomas Graf wrote: > On 01/06/15 at 09:29pm, Flavio Leitner wrote: > > There are a couple missing steps needed in order to > > build the Vagrantfile. This patch adds them to the > > INSTALL.md file. > > > > Signed-off-by: Flavio Leitner > > Agreed that

Re: [ovs-dev] [PATCH] Vagrant: Add steps when pulling from git tree to INSTALL.md

On 01/06/15 at 09:29pm, Flavio Leitner wrote: > There are a couple missing steps needed in order to > build the Vagrantfile. This patch adds them to the > INSTALL.md file. > > Signed-off-by: Flavio Leitner Agreed that it's a good idea to mention this requirement. Should we refer to the "Buildi

Re: [ovs-dev] [PATCH] Vagrant: Add steps when pulling from git tree to INSTALL.md

On Tue, Jan 06, 2015 at 09:29:04PM -0200, Flavio Leitner wrote: > There are a couple missing steps needed in order to > build the Vagrantfile. This patch adds them to the > INSTALL.md file. > > Signed-off-by: Flavio Leitner Thomas, I assume you'll review this? __

Re: [ovs-dev] [PATCH v2] SECURITY: New document describing proposed security process for OVS.

Oops, I committed this at the same time you sent your message. Thanks for agreeing (in IRC) to send it as a patch tomorrow. On Tue, Jan 6, 2015 at 3:21 PM, Flavio Leitner wrote: > On Tuesday, January 06, 2015 10:22:10 AM Ben Pfaff wrote: >> Open vSwitch needs some kind of process for handling vu

[ovs-dev] [PATCH] Vagrant: Add steps when pulling from git tree to INSTALL.md

There are a couple missing steps needed in order to build the Vagrantfile. This patch adds them to the INSTALL.md file. Signed-off-by: Flavio Leitner --- INSTALL.md | 12 1 file changed, 12 insertions(+) diff --git a/INSTALL.md b/INSTALL.md index 122c362..64a189b 100644 --- a/INST

Re: [ovs-dev] [PATCH v2] SECURITY: New document describing proposed security process for OVS.

On Wed, Jan 07, 2015 at 12:17:45AM +0100, Thomas Graf wrote: > On 01/06/15 at 10:22am, Ben Pfaff wrote: > > Open vSwitch needs some kind of process for handling vulnerabilities. So > > far, we've been pretty lucky that way, but it can't last forever, and I > > think we'll be better off if we have

Re: [ovs-dev] [PATCH v2] SECURITY: New document describing proposed security process for OVS.

On Tuesday, January 06, 2015 10:22:10 AM Ben Pfaff wrote: > Open vSwitch needs some kind of process for handling vulnerabilities. So > far, we've been pretty lucky that way, but it can't last forever, and I > think we'll be better off if we have at least the outline of an established > process whe

Re: [ovs-dev] [PATCH v2] SECURITY: New document describing proposed security process for OVS.

On 01/06/15 at 10:22am, Ben Pfaff wrote: > Open vSwitch needs some kind of process for handling vulnerabilities. So > far, we've been pretty lucky that way, but it can't last forever, and I > think we'll be better off if we have at least the outline of an established > process whenever a significa

Re: [ovs-dev] [PATCH] vagrant: Provide basic Vagrantfile

On 01/06/15 at 11:34am, Andy Zhou wrote: > We have been think about adding unit tests the kernel module. Any > plans or objections to develop kmod unit tests on top of this patch? No objections at all. This is exactly where I want to go with this. Please go ahead. I have some other things to com

Re: [ovs-dev] [PATCH] tests: Make test independent of the hash function.

On Tue, Jan 06, 2015 at 03:11:33PM -0800, Jarno Rajahalme wrote: > Otherwise compiling with -msse4.2 (or -march=native on a SSE4.2 > capable CPU) will produce a test failure due to the CRC32-based hash > function being different from mhash. > > Signed-off-by: Jarno Rajahalme Acked-by: Ben Pfaff

[ovs-dev] [PATCH] tests: Make test independent of the hash function.

Otherwise compiling with -msse4.2 (or -march=native on a SSE4.2 capable CPU) will produce a test failure due to the CRC32-based hash function being different from mhash. Signed-off-by: Jarno Rajahalme --- tests/ofproto-dpif.at |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --

Re: [ovs-dev] [PATCH 2/2] miniflow: Use 64-bit data.

On Jan 6, 2015, at 1:20 PM, Ben Pfaff wrote: > On Tue, Jan 06, 2015 at 11:03:15AM -0800, Jarno Rajahalme wrote: >> >> On Jan 5, 2015, at 2:39 PM, Ben Pfaff wrote: >> >>> On Mon, Jan 05, 2015 at 02:15:13PM -0800, Ben Pfaff wrote: On Mon, Jan 05, 2015 at 02:08:41PM -0800, Jarno Rajahalme w

Re: [ovs-dev] [PATCH 1/2] hash: Add hash_add64().

On Dec 29, 2014, at 2:12 PM, Ben Pfaff wrote: > On Wed, Dec 17, 2014 at 10:30:41AM -0800, Jarno Rajahalme wrote: >> Add support for adding 64-bit words to hashes. This will be used by >> subsequent patches. >> >> Signed-off-by: Jarno Rajahalme > > I noticed that hash_words64() takes a 64-bit

Re: [ovs-dev] [PATCH 1/8] datapath: Account for rename to vlan_insert_tag_set_proto()

On 01/06/15 at 01:46pm, Pravin Shelar wrote: > On Fri, Jan 2, 2015 at 10:35 AM, Thomas Graf wrote: > > __vlan_put_tag() was renamed to vlan_insert_tag_set_proto() with > > the argument list kept intact. > > > > Upstream: 62749e ("vlan: rename __vlan_put_tag to > > vlan_insert_tag_set_proto") > >

[ovs-dev] [PATCH] vlog: Rename the currently used term 'facility' to 'destination'.

In OVS, we currently use the term 'facility' to mean the place where we log (syslog, console or file). In Linux's syslog() and rfc5424, the term 'facility' is used to specify what type of program is logging the message (e.g: LOG_DAEMON). This causes confusion while reading vlog's code. This commit

Re: [ovs-dev] [PATCH v2.1 2/2] [RFC] classifier: Add support for conjunctive matches.

I’ll review the v3 when ready, Jarno On Dec 30, 2014, at 4:30 PM, Ben Pfaff wrote: > A "conjunctive match" allows higher-level matches in the flow table, such > as set membership matches, without causing a cross-product explosion for > multidimensional matches. Please refer to the documentat

Re: [ovs-dev] [PATCH 5/8] datapath: introduce rtnl ops stub

On Fri, Jan 2, 2015 at 10:35 AM, Thomas Graf wrote: > This stub now allows userspace to see IFLA_INFO_KIND for ovs master and > IFLA_INFO_SLAVE_KIND for slave. > > Upstream: 5b9e7e16 ("openvswitch: introduce rtnl ops stub") > Signed-off-by: Thomas Graf Acked-by: Pravin B Shelar

Re: [ovs-dev] [PATCH 8/8] travis: Update build matrix to include latest stable kernels

On Fri, Jan 2, 2015 at 10:35 AM, Thomas Graf wrote: > Signed-off-by: Thomas Graf Acked-by: Pravin B Shelar Thanks for all patches. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH 7/8] datapath: Account for new flags args of vxlan_sock_add()

On Fri, Jan 2, 2015 at 10:35 AM, Thomas Graf wrote: > The upstream commit 359a0ea > ("vxlan: Add support for UDP checksums (v4 sending, v6 zero csums)") > has introduced a new flags argument to vxlan_sock_add(). > > OVS does not pass any flags at this point, thus specyfing 0 will be > compatible w

Re: [ovs-dev] [PATCH 6/8] datapath: replace remaining users of arch_fast_hash with jhash

On Fri, Jan 2, 2015 at 10:35 AM, Thomas Graf wrote: > This patch effectively reverts commit 500f80872645 ("net: ovs: use CRC32 > accelerated flow hash if available"), and other remaining arch_fast_hash() > users such as from nfsd via commit 6282cd565553 ("NFSD: Don't hand out > delegations for 30

Re: [ovs-dev] [PATCH 4/8] datapath: move vlan pop/push functions into common code

On Fri, Jan 2, 2015 at 10:35 AM, Thomas Graf wrote: > So it can be used from out of openvswitch code. > Did couple of cosmetic changes on the way, namely variable naming and > adding support for 8021AD proto. > > Note on backwards compatability: > Unlike the upstream version, the backport of skb_v

Re: [ovs-dev] [PATCH 3/8] datapath: move make_writable helper into common code

On Fri, Jan 2, 2015 at 10:35 AM, Thomas Graf wrote: > note that skb_make_writable already exists in net/netfilter/core.c > but does something slightly different. > > Upstream: e219512 ("net: move make_writable helper into common code") > Signed-off-by: Thomas Graf Acked-by: Pravin B Shelar

Re: [ovs-dev] [PATCH 2/8] datapath: Add __vlan_insert_tag() compat helper if not available

On Fri, Jan 2, 2015 at 10:35 AM, Thomas Graf wrote: > Since older kernels do not have skb->vlan_proto, it is assumed that > kernels which don't provide their own __vlan_insert_tag() will also > not have skb->vlan_proto. The backwards compat function therefore > only supports ETH_P_8021Q as the pro

Re: [ovs-dev] [PATCH 1/8] datapath: Account for rename to vlan_insert_tag_set_proto()

On Fri, Jan 2, 2015 at 10:35 AM, Thomas Graf wrote: > __vlan_put_tag() was renamed to vlan_insert_tag_set_proto() with > the argument list kept intact. > > Upstream: 62749e ("vlan: rename __vlan_put_tag to vlan_insert_tag_set_proto") > Signed-off-by: Thomas Graf > --- You can rename __vlan_put_ta

Re: [ovs-dev] [PATCH 2/2] miniflow: Use 64-bit data.

On Tue, Jan 06, 2015 at 11:03:15AM -0800, Jarno Rajahalme wrote: > > On Jan 5, 2015, at 2:39 PM, Ben Pfaff wrote: > > > On Mon, Jan 05, 2015 at 02:15:13PM -0800, Ben Pfaff wrote: > >> On Mon, Jan 05, 2015 at 02:08:41PM -0800, Jarno Rajahalme wrote: > >>> > >>> On Dec 29, 2014, at 2:27 PM, Ben P

Re: [ovs-dev] PERSONAL GIFT FROM ME TO YOU

I'm making a free-will financial donation. Reply to partake {m_schaeff...@aol.com} Maria Schaeffler​​ This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please

Re: [ovs-dev] [PATCH] vagrant: Provide basic Vagrantfile

We have been think about adding unit tests the kernel module. Any plans or objections to develop kmod unit tests on top of this patch? Before seeing this patch, I played with UML (user mode linux) with some limited success. ___ dev mailing list dev@ope

Re: [ovs-dev] [PATCH net] gso: do GSO for local skb with size bigger than MTU

On Tue, Jan 6, 2015 at 4:34 AM, Fan Du wrote: > > On 2015/1/6 1:58, Jesse Gross wrote: >> >> On Mon, Jan 5, 2015 at 1:02 AM, Fan Du >> wrote: >>> >>> 于 2014年12月03日 10:31, Du, Fan 写道: >>> > -Original Message- > From: Thomas Graf [mailto:t...@infradead.org] On Behalf Of Thomas

Re: [ovs-dev] [PATCH 2/2] miniflow: Use 64-bit data.

On Jan 5, 2015, at 2:39 PM, Ben Pfaff wrote: > On Mon, Jan 05, 2015 at 02:15:13PM -0800, Ben Pfaff wrote: >> On Mon, Jan 05, 2015 at 02:08:41PM -0800, Jarno Rajahalme wrote: >>> >>> On Dec 29, 2014, at 2:27 PM, Ben Pfaff wrote: >>> On Wed, Dec 17, 2014 at 10:30:42AM -0800, Jarno Rajahalm

Re: [ovs-dev] [PATCH] ofproto-dpif: Do not allow recirc_id freed by non-owning ofproto.

Thx, applied to master, On Tue, Jan 6, 2015 at 9:35 AM, Ben Pfaff wrote: > On Mon, Dec 29, 2014 at 02:18:21PM -0800, Alex Wang wrote: > > This commit changes the VLOG_ERR (for warning unmatched ofproto) > > in ofproto_dpif_free_recirc_id() to an assert statement, so that > > recirc_id is never a

Re: [ovs-dev] [branch-2.3] ofproto-dpif-upcall: Make handler always call poll_block.

Thx for the review, applied to branch-2.3 Master has already done the similar thing, and there is no need to backport to branch-2.1 On Tue, Jan 6, 2015 at 9:32 AM, Ben Pfaff wrote: > On Mon, Dec 29, 2014 at 04:06:55PM -0800, Alex Wang wrote: > > This commit makes handler threads always call pol

Re: [ovs-dev] [PATCH v2] SECURITY: New document describing proposed security process for OVS.

> On Jan 6, 2015, at 10:29 AM, Justin Pettit wrote: > > >> On Jan 6, 2015, at 10:22 AM, Ben Pfaff wrote: >> >> Open vSwitch needs some kind of process for handling vulnerabilities. So >> far, we've been pretty lucky that way, but it can't last forever, and I >> think we'll be better off if w

Re: [ovs-dev] [PATCH v2] SECURITY: New document describing proposed security process for OVS.

> On Jan 6, 2015, at 10:22 AM, Ben Pfaff wrote: > > Open vSwitch needs some kind of process for handling vulnerabilities. So > far, we've been pretty lucky that way, but it can't last forever, and I > think we'll be better off if we have at least the outline of an established > process whenever

[ovs-dev] [PATCH v2] SECURITY: New document describing proposed security process for OVS.

Open vSwitch needs some kind of process for handling vulnerabilities. So far, we've been pretty lucky that way, but it can't last forever, and I think we'll be better off if we have at least the outline of an established process whenever a significant vulnerability comes along. Here's my draft of

Re: [ovs-dev] [PATCH RFC] SECURITY: New document describing proposed security process for OVS.

On Tue, Jan 06, 2015 at 09:49:16AM -0800, Justin Pettit wrote: > > > On Jan 2, 2015, at 1:44 PM, Ben Pfaff wrote: > > > > +When the embargo expires, push the (reviewed) patches to appropriate > > +branches, post the patches to the ovs-dev mailing list (noting that > > +they have already been rev

Re: [ovs-dev] [PATCH RFC] SECURITY: New document describing proposed security process for OVS.

On Mon, Jan 05, 2015 at 02:23:45PM -0200, Flavio Leitner wrote: > On Friday, January 02, 2015 01:44:49 PM Ben Pfaff wrote: > > Open vSwitch needs some kind of process for handling vulnerabilities. So > > far, we've been pretty lucky that way, but it can't last forever, and I > > think we'll be bet

Re: [ovs-dev] [PATCH RFC] SECURITY: New document describing proposed security process for OVS.

> On Jan 6, 2015, at 10:09 AM, Ben Pfaff wrote: > > On Tue, Jan 06, 2015 at 09:59:28AM -0800, Justin Pettit wrote: >> On Jan 5, 2015, at 7:04 AM, Jiri Benc wrote: >>> >>> On Fri, 2 Jan 2015 13:44:49 -0800, Ben Pfaff wrote: >>> +Step 4: Embargoed Disclosure +

Re: [ovs-dev] [PATCH RFC] SECURITY: New document describing proposed security process for OVS.

On Tue, Jan 6, 2015 at 11:58 AM, Ben Pfaff wrote: > On Mon, Jan 05, 2015 at 09:29:47AM -0600, Kyle Mestery wrote: > > On Mon, Jan 5, 2015 at 9:23 AM, Jiri Benc wrote: > > > > > On Fri, 2 Jan 2015 17:57:14 -0800, Ben Pfaff wrote: > > > > 1) Consider provisions for ensuring privacy and integri

Re: [ovs-dev] [PATCH RFC] SECURITY: New document describing proposed security process for OVS.

On Tue, Jan 06, 2015 at 09:59:28AM -0800, Justin Pettit wrote: > On Jan 5, 2015, at 7:04 AM, Jiri Benc wrote: > > > > On Fri, 2 Jan 2015 13:44:49 -0800, Ben Pfaff wrote: > > > >> +Step 4: Embargoed Disclosure > >> + > >> + > >> +The security advisory and patches are

Re: [ovs-dev] [PATCH RFC] SECURITY: New document describing proposed security process for OVS.

On Mon, Jan 05, 2015 at 02:30:10PM -0200, Flavio Leitner wrote: > On Friday, January 02, 2015 05:57:14 PM Ben Pfaff wrote: > > On Fri, Jan 02, 2015 at 01:44:49PM -0800, Ben Pfaff wrote: > > > Open vSwitch needs some kind of process for handling vulnerabilities. So > > > far, we've been pretty luck

Re: [ovs-dev] [PATCH RFC] SECURITY: New document describing proposed security process for OVS.

On Mon, Jan 05, 2015 at 06:01:14PM +0100, Thomas Graf wrote: > On 01/05/15 at 04:23pm, Jiri Benc wrote: > > On Fri, 2 Jan 2015 17:57:14 -0800, Ben Pfaff wrote: > > > 1) Consider provisions for ensuring privacy and integrity of > > > communications around disclosure (eg, use PGP for all comm

Re: [ovs-dev] [PATCH RFC] SECURITY: New document describing proposed security process for OVS.

> On Jan 5, 2015, at 8:23 AM, Flavio Leitner wrote: > > My concern is with open communications. It should be > possible to anyone to report the issue, but further communications > should be authenticated and closed to avoid someone else to > fake messages/patches, etc. > > Is the mailing list

Re: [ovs-dev] [PATCH RFC] SECURITY: New document describing proposed security process for OVS.

On Jan 5, 2015, at 7:04 AM, Jiri Benc wrote: > > On Fri, 2 Jan 2015 13:44:49 -0800, Ben Pfaff wrote: > >> +Step 4: Embargoed Disclosure >> + >> + >> +The security advisory and patches are sent to downstream stakeholders, >> +with an embargo date and time set to 3 to

Re: [ovs-dev] [PATCH RFC] SECURITY: New document describing proposed security process for OVS.

On Mon, Jan 05, 2015 at 09:29:47AM -0600, Kyle Mestery wrote: > On Mon, Jan 5, 2015 at 9:23 AM, Jiri Benc wrote: > > > On Fri, 2 Jan 2015 17:57:14 -0800, Ben Pfaff wrote: > > > 1) Consider provisions for ensuring privacy and integrity of > > > communications around disclosure (eg, use PGP

Re: [ovs-dev] [PATCH RFC] SECURITY: New document describing proposed security process for OVS.

On Mon, Jan 05, 2015 at 04:23:59PM +0100, Jiri Benc wrote: > On Fri, 2 Jan 2015 17:57:14 -0800, Ben Pfaff wrote: > > 1) Consider provisions for ensuring privacy and integrity of > > communications around disclosure (eg, use PGP for all comms). > > That never hurts. I'd argue that's not str

Re: [ovs-dev] [PATCH RFC] SECURITY: New document describing proposed security process for OVS.

> On Jan 2, 2015, at 1:44 PM, Ben Pfaff wrote: > > +When the embargo expires, push the (reviewed) patches to appropriate > +branches, post the patches to the ovs-dev mailing list (noting that > +they have already been reviewed and applied), post the security > +advisory to appropriate mailing li

Re: [ovs-dev] [PATCH] ofproto-dpif: Do not allow recirc_id freed by non-owning ofproto.

On Mon, Dec 29, 2014 at 02:18:21PM -0800, Alex Wang wrote: > This commit changes the VLOG_ERR (for warning unmatched ofproto) > in ofproto_dpif_free_recirc_id() to an assert statement, so that > recirc_id is never allowed to be freed by non-owning ofproto. > > Suggested-by: Ben Pfaff > Signed-off

Re: [ovs-dev] [branch-2.3] ofproto-dpif-upcall: Make handler always call poll_block.

On Mon, Dec 29, 2014 at 04:06:55PM -0800, Alex Wang wrote: > This commit makes handler threads always call poll_block() at > the end of each handling cycle. If there are upcalls received > in the current cycle, the handler will register to wake up > immediately. Otherwise, it will wait on both th

Re: [ovs-dev] [PATCH] ofproto: Don't count hidden rules in table stats.

On Mon, Jan 05, 2015 at 01:03:59PM -0800, Jarno Rajahalme wrote: > Looks good to me, with a small nit/comment below, > > Acked-by: Jarno Rajahalme > > Jarno > > On Jan 1, 2015, at 11:06 AM, Ben Pfaff wrote: > > > The hidden rules created by in-band control and fail-open should not be > > in

Re: [ovs-dev] [PATCH] datapath-windows: set the nlBuf tail properly

Hi Nithin, https://github.com/openvswitch/ovs-issues/issues/59 was solved some time ago. I don't remember exactly the patch. I will close the issue. Thanks, Alin. -Mesaj original- De la: Nithin Raju [mailto:nit...@vmware.com] Trimis: Monday, January 5, 2015 10:36 PM Către: Alin Serdea

Re: [ovs-dev] [PATCH] datapath: Consistently include VLAN header in flow and port stats.

On Fri, Jan 02, 2015 at 06:16:17PM -0800, Pravin Shelar wrote: > On Fri, Jan 2, 2015 at 3:03 PM, Ben Pfaff wrote: > > Pravin, you already acked this on netdev. This is the crossport to > > the OVS tree. I didn't know whether the netdev ack was good enough to > > just push to OVS too, so to play

Re: [ovs-dev] [PATCH] datapath: Consistently include VLAN header in flow and port stats.

On Fri, Jan 02, 2015 at 06:16:33PM -0800, Pravin Shelar wrote: > On Fri, Jan 2, 2015 at 2:54 PM, Ben Pfaff wrote: > > Until now, when VLAN acceleration was in use, the bytes of the VLAN header > > were not included in port or flow byte counters. They were however > > included when VLAN accelerati

Re: [ovs-dev] [PATCH] datapath-windows: set the nlBuf tail properly

On Mon, Jan 05, 2015 at 07:17:01PM +, Alin Serdean wrote: > Move the the tail of the netlink buffer accordingly to the input data. > Currently _MapFlowStatsToNlStats overrides the netlink header information. > > > Signed-off-by: Alin Gabriel Serdean Applied, thanks!

Re: [ovs-dev] Building OVS on Ubuntu 12.04 stuck in atomic operation unit test

On Mon, Jan 05, 2015 at 09:01:38PM +0900, Motonori Shindo wrote: > When building OVS (the latest master) under Ubuntu 12.04, it stuck at the > unit test "test atomic operations” and never finishes (or it could just be > unbearably slow). This problem doesn’t happen in Ubuntu 14.04, however. > >

Re: [ovs-dev] [PATCH] configure.ac: Enable 'tar-ustar' by default

On Tue, Jan 06, 2015 at 09:14:51AM +, Finucane, Stephen wrote: > > On Mon, Jan 05, 2015 at 08:57:48AM +, Finucane, Stephen wrote: > > > > On Fri, Dec 19, 2014 at 10:19:10AM +, Stephen Finucane wrote: > > > > > Automake defaults to the 'v7' legacy tar format in GNU tar, through > > > > >

Re: [ovs-dev] Procedures to compile OVS code

[dropping discuss-request, which is not a mailing list] On Tue, Jan 06, 2015 at 04:23:58PM +0530, tech_kals Kals wrote: > 1) could you please let me know how can i compile OVS code ? I would like > to add few debugs to understand the code flow. Can someone help me ? Read INSTALL.md. > 2) Is the

Re: [ovs-dev] [PATCH v4 3/3] datapath-windows: Add a WFP system provider

On Tue, Jan 06, 2015 at 10:56:49AM +, Sorin Vinturis wrote: > This patch was enforced by the WHCK logo testing. In order to pass the > Windows Filtering Platform tests we need to add a persistent system > provider. > > Signed-off-by: Sorin Vinturis > Reported-by: Sorin Vinturis > Reported-at

[ovs-dev] [PATCH v4 3/3] datapath-windows: Add a WFP system provider

This patch was enforced by the WHCK logo testing. In order to pass the Windows Filtering Platform tests we need to add a persistent system provider. Signed-off-by: Sorin Vinturis Reported-by: Sorin Vinturis Reported-at: https://github.com/openvswitch/ovs-issues/issues/65 Acked-by: Nithin Raju -

[ovs-dev] Procedures to compile OVS code

Hi Experts, 1) could you please let me know how can i compile OVS code ? I would like to add few debugs to understand the code flow. Can someone help me ? 2) Is there any way to enable debugs on OVS code ? Thanks, Tech.Kals ___ dev mailing list dev@o

Re: [ovs-dev] [PATCH net] gso: do GSO for local skb with size bigger than MTU

On 2015/1/6 1:58, Jesse Gross wrote: On Mon, Jan 5, 2015 at 1:02 AM, Fan Du wrote: 于 2014年12月03日 10:31, Du, Fan 写道: -Original Message- From: Thomas Graf [mailto:t...@infradead.org] On Behalf Of Thomas Graf Sent: Wednesday, December 3, 2014 1:42 AM To: Michael S. Tsirkin Cc: Du, Fan

Re: [ovs-dev] [PATCH] configure.ac: Enable 'tar-ustar' by default

> On Mon, Jan 05, 2015 at 08:57:48AM +, Finucane, Stephen wrote: > > > On Fri, Dec 19, 2014 at 10:19:10AM +, Stephen Finucane wrote: > > > > Automake defaults to the 'v7' legacy tar format in GNU tar, through > > > > passing of the '-o' parameter to GNU tar. Enabling this option > results >