This feature was included only to allow Citrix QA to run some tests that
interacted directly with the bridge. This feature hasn't been turned on
for some time, so it should not be necessary any longer.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Besides the user introduced in this commit, the new Netlink-based datapath
communication code will use this function.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Jesse Gross <jesse@nicira.com>
Reported-by: Justin Pettit <jpettit@nicira.com>
It's better to use HAVE_NLA_NUL_STRING than a version check because the
Xen 2.6.18 kernels backport NLA_NUL_STRING and the nla_policy changes.
Just defining NLA_NUL_STRING to an innocuous value doesn't work, because
Linux before 2.6.19 doesn't define a 'len' member in struct nla_policy at
all (it was named 'minlen' and had different semantics), so attempting to
initialize it caused compile errors.
Grouping things this way also makes it clearer what needs to be deleted
when upstreaming.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Jesse Gross <jesse@nicira.com>
I had completely forgotten that we had a top-level compat.h and compat26.h.
It's better to distribute their contents to individual compat headers, so
this commit does so and deletes them.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Jesse Gross <jesse@nicira.com>
Currently we use a fairly complicated method of generating the
bridge ID, since the actual struct is only available in a header
file private to the Linux bridge. The current method appears to
be correct but is difficult to reason about. This replaces it
with a simple memcpy, which is more analogous to what the Linux
bridge does.
Flagged by sparse.
Signed-off-by: Jesse Gross <jesse@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
This patch checks that the user calling ioctl() to create, delete, or
modify bridges has the CAP_NET_ADMIN capability. This prevents
unpriviledged users from modifying the bridge configuration through
brcompatd. The checks are actually the same performed in
net/bridge/br_ioctl.c by the Linux kernel.
Signed-off-by: Vivien Bernet-Rollande <vbr@soprive.net>
Signed-off-by: Jesse Gross <jesse@nicira.com>
Signed-off-by: Joe Perches <joe@perches.com>
Acked-by: Simon Horman <horms@verge.net.au>
[Jesse: Added missing pr_fmt in vport-gre.c and dp_sysfs_dp.c]
Signed-off-by: Jesse Gross <jesse@nicira.com>
In some places we would put the return type on the same line as
the rest of the function definition and other places we wouldn't.
Reformat everything to match kernel style.
We previously required that brcompat_mod be loaded before any datapaths
were created, because creation and destruction of datapaths and ports
differed when brcompat_mod was loaded, but the latter is no longer the
case so there is no reason for the former anymore.
The Citrix QA scripts assume that "brctl show" will show a topology as if
the Linux bridge were still in use; that is, as if there were one bridge
per VLAN and as if bonds were network devices of their own instead of
separate devices. However, we were showing the datapath topology, i.e.
all VLANs and bond devices lumped together into a single datapath. This
commit fixes the VLAN end of the problem, by moving the implementation of
the ioctls that brctl uses into userspace in ovs-brcompatd and putting the
necessary translation logic into ovs-brcompatd.
By itself, this commit does not fix the problem for bonds: the port name
for a bond does not (normally) under Open vSwitch exist as an actual
Linux network device, and thus it has no ifindex, and so ovs-brcompatd
can't pass it back to the kernel to report to brctl. This fix will have
to wait for another commit.
Bug NIC-19.
In the past problems have arisen due to the different ways that datapaths
are created and destroyed in the three different cases:
1. sysfs supported, brcompat_mod loaded.
2. sysfs supported, brcompat_mod not loaded.
3. sysfs not supported.
The brcompat_mod loaded versus not loaded distinction is the stickiest
because we have to do all the calls into brcompat_mod through hook
functions, which in turn causes pressure to keep the number of hook
functions small and well-defined, which makes it really difficult to put
the hook call points at exactly the right place. Witness, for example,
this piece of code in datapath.c:
int dp_del_port(struct net_bridge_port *p)
{
ASSERT_RTNL();
#ifdef SUPPORT_SYSFS
if (p->port_no != ODPP_LOCAL && dp_del_if_hook)
sysfs_remove_link(&p->dp->ifobj, p->dev->name);
#endif
The code inside the #ifdef is logically part of the brcompat_mod sysfs
support, but the author of this code (quite reasonably) didn't want to
add a hook function call there. After all, what would you call the
hook function? There's no obvious name from the dp_del_port() caller's
perspective.
All this argues that sysfs support should be in openvswitch_mod itself,
since it has to be tightly integrated, not bolted on. So this commit
moves it there.
Now, this is not to say that openvswitch_mod should actually be
implementing bridge-compatible sysfs. In the future, it probably should
not be; rather, it should implement something appropriate for Open vSwitch
datapaths instead. But right now we have bridge-compatible sysfs, and so
that's what this commit moves.
In an upcoming change, brcompat will need to receive bulk data from
ovs-brcompatd. The existing brcompat infrastructure for receiving data
only supports returning an error code, so this commit adds the ability to
receive an arbitrary sk_buff and updates the existing users to handle it.
