2010-12-10 09:51:03 -08:00
|
|
|
|
/*
|
2014-01-13 13:50:22 -08:00
|
|
|
|
* Copyright (c) 2008, 2009, 2010, 2011, 2012, 2013, 2014 Nicira, Inc.
|
2010-12-10 09:51:03 -08:00
|
|
|
|
*
|
|
|
|
|
* Licensed under the Apache License, Version 2.0 (the "License");
|
|
|
|
|
* you may not use this file except in compliance with the License.
|
|
|
|
|
* You may obtain a copy of the License at:
|
|
|
|
|
*
|
|
|
|
|
* http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
|
*
|
|
|
|
|
* Unless required by applicable law or agreed to in writing, software
|
|
|
|
|
* distributed under the License is distributed on an "AS IS" BASIS,
|
|
|
|
|
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
|
|
|
* See the License for the specific language governing permissions and
|
|
|
|
|
* limitations under the License.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include <config.h>
|
|
|
|
|
#include "netlink-socket.h"
|
|
|
|
|
#include <errno.h>
|
|
|
|
|
#include <inttypes.h>
|
|
|
|
|
#include <stdlib.h>
|
|
|
|
|
#include <sys/types.h>
|
2011-10-14 13:55:00 -07:00
|
|
|
|
#include <sys/uio.h>
|
2010-12-10 09:51:03 -08:00
|
|
|
|
#include <unistd.h>
|
|
|
|
|
#include "coverage.h"
|
|
|
|
|
#include "dynamic-string.h"
|
2011-01-11 11:02:32 -08:00
|
|
|
|
#include "hash.h"
|
|
|
|
|
#include "hmap.h"
|
2010-12-10 09:51:03 -08:00
|
|
|
|
#include "netlink.h"
|
|
|
|
|
#include "netlink-protocol.h"
|
|
|
|
|
#include "ofpbuf.h"
|
2013-06-19 11:39:11 -07:00
|
|
|
|
#include "ovs-thread.h"
|
2010-12-10 09:51:03 -08:00
|
|
|
|
#include "poll-loop.h"
|
2014-02-27 14:13:06 -08:00
|
|
|
|
#include "seq.h"
|
2011-01-11 16:05:37 -08:00
|
|
|
|
#include "socket-util.h"
|
2011-10-14 13:55:00 -07:00
|
|
|
|
#include "util.h"
|
2010-12-10 09:51:03 -08:00
|
|
|
|
#include "vlog.h"
|
|
|
|
|
|
|
|
|
|
VLOG_DEFINE_THIS_MODULE(netlink_socket);
|
|
|
|
|
|
|
|
|
|
COVERAGE_DEFINE(netlink_overflow);
|
|
|
|
|
COVERAGE_DEFINE(netlink_received);
|
2011-07-27 14:56:03 -07:00
|
|
|
|
COVERAGE_DEFINE(netlink_recv_jumbo);
|
2010-12-10 09:51:03 -08:00
|
|
|
|
COVERAGE_DEFINE(netlink_sent);
|
|
|
|
|
|
|
|
|
|
/* Linux header file confusion causes this to be undefined. */
|
|
|
|
|
#ifndef SOL_NETLINK
|
|
|
|
|
#define SOL_NETLINK 270
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
/* A single (bad) Netlink message can in theory dump out many, many log
|
|
|
|
|
* messages, so the burst size is set quite high here to avoid missing useful
|
|
|
|
|
* information. Also, at high logging levels we log *all* Netlink messages. */
|
|
|
|
|
static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(60, 600);
|
|
|
|
|
|
netlink: Postpone choosing sequence numbers until send time.
Choosing sequence numbers at time of creating a packet means that
nl_sock_transact_multiple() has to search for the sequence number
of a reply, because the sequence numbers of the requests aren't
necessarily sequential. This commit makes it possible to avoid
the search, by deferring choice of sequence numbers until the
time that we send the packets. It doesn't actually modify
nl_sock_transact_multiple(), which will happen in a later commit.
Previously, I was concerned about a theoretical race condition
described in a comment in the old versino of this code:
This implementation uses sequence numbers that are unique
process-wide, to avoid a hypothetical race: send request, close
socket, open new socket that reuses the old socket's PID value,
send request on new socket, receive reply from kernel to old
socket but with same PID and sequence number. (This race could be
avoided other ways, e.g. by preventing PIDs from being quickly
reused).
However, I no longer believe that this can be a real problem,
because Netlink operates synchronously. The reply to a request
will always arrive before the socket can be closed and a new
socket opened with the old socket's PID.
Signed-off-by: Ben Pfaff <blp@nicira.com>
2012-04-16 16:01:01 -07:00
|
|
|
|
static uint32_t nl_sock_allocate_seq(struct nl_sock *, unsigned int n);
|
2010-12-10 09:51:03 -08:00
|
|
|
|
static void log_nlmsg(const char *function, int error,
|
2011-01-18 14:07:52 -08:00
|
|
|
|
const void *message, size_t size, int protocol);
|
2010-12-10 09:51:03 -08:00
|
|
|
|
|
|
|
|
|
/* Netlink sockets. */
|
|
|
|
|
|
2013-04-09 11:18:27 -07:00
|
|
|
|
struct nl_sock {
|
2010-12-10 09:51:03 -08:00
|
|
|
|
int fd;
|
netlink: Postpone choosing sequence numbers until send time.
Choosing sequence numbers at time of creating a packet means that
nl_sock_transact_multiple() has to search for the sequence number
of a reply, because the sequence numbers of the requests aren't
necessarily sequential. This commit makes it possible to avoid
the search, by deferring choice of sequence numbers until the
time that we send the packets. It doesn't actually modify
nl_sock_transact_multiple(), which will happen in a later commit.
Previously, I was concerned about a theoretical race condition
described in a comment in the old versino of this code:
This implementation uses sequence numbers that are unique
process-wide, to avoid a hypothetical race: send request, close
socket, open new socket that reuses the old socket's PID value,
send request on new socket, receive reply from kernel to old
socket but with same PID and sequence number. (This race could be
avoided other ways, e.g. by preventing PIDs from being quickly
reused).
However, I no longer believe that this can be a real problem,
because Netlink operates synchronously. The reply to a request
will always arrive before the socket can be closed and a new
socket opened with the old socket's PID.
Signed-off-by: Ben Pfaff <blp@nicira.com>
2012-04-16 16:01:01 -07:00
|
|
|
|
uint32_t next_seq;
|
2010-12-10 09:51:03 -08:00
|
|
|
|
uint32_t pid;
|
2011-01-18 14:07:52 -08:00
|
|
|
|
int protocol;
|
2011-10-14 13:55:00 -07:00
|
|
|
|
unsigned int rcvbuf; /* Receive buffer size (SO_RCVBUF). */
|
2010-12-10 09:51:03 -08:00
|
|
|
|
};
|
|
|
|
|
|
2011-10-14 13:55:00 -07:00
|
|
|
|
/* Compile-time limit on iovecs, so that we can allocate a maximum-size array
|
|
|
|
|
* of iovecs on the stack. */
|
|
|
|
|
#define MAX_IOVS 128
|
|
|
|
|
|
|
|
|
|
/* Maximum number of iovecs that may be passed to sendmsg, capped at a
|
|
|
|
|
* minimum of _XOPEN_IOV_MAX (16) and a maximum of MAX_IOVS.
|
|
|
|
|
*
|
|
|
|
|
* Initialized by nl_sock_create(). */
|
|
|
|
|
static int max_iovs;
|
|
|
|
|
|
2013-04-29 13:57:50 -07:00
|
|
|
|
static int nl_pool_alloc(int protocol, struct nl_sock **sockp);
|
|
|
|
|
static void nl_pool_release(struct nl_sock *);
|
2010-12-10 09:51:03 -08:00
|
|
|
|
|
|
|
|
|
/* Creates a new netlink socket for the given netlink 'protocol'
|
|
|
|
|
* (NETLINK_ROUTE, NETLINK_GENERIC, ...). Returns 0 and sets '*sockp' to the
|
2013-04-29 13:57:50 -07:00
|
|
|
|
* new socket if successful, otherwise returns a positive errno value. */
|
2010-12-10 09:51:03 -08:00
|
|
|
|
int
|
2011-01-09 16:57:45 -08:00
|
|
|
|
nl_sock_create(int protocol, struct nl_sock **sockp)
|
2010-12-10 09:51:03 -08:00
|
|
|
|
{
|
2013-06-19 11:39:11 -07:00
|
|
|
|
static struct ovsthread_once once = OVSTHREAD_ONCE_INITIALIZER;
|
2010-12-10 09:51:03 -08:00
|
|
|
|
struct nl_sock *sock;
|
|
|
|
|
struct sockaddr_nl local, remote;
|
2011-11-14 10:10:58 -08:00
|
|
|
|
socklen_t local_size;
|
netlink-socket: Increase Netlink socket receive buffer size.
Open vSwitch userspace can set up flows at a high rate, but it is somewhat
"bursty" in opportunities to set up flows, by which I mean that OVS sets up
a batch of flows, then goes off and does some other work for a while, then
sets up another batch of flows, and so on. The result is that, if a large
number of packets that need flow setups come in all at once, then some of
them can overflow the relatively small kernel-to-user buffers.
This commit increases the kernel-to-user buffers from the default of
approximately 120 kB each to 1 MB each. In one somewhat synthetic test
case that I ran based on an "hping3" that generated a load of about 20,000
new flows per second (including both requests and replies), this reduced
the packets dropped at the kernel-to-user interface from about 30% to none.
I expect that it will similarly improve packet loss in workloads where
flow arrival is not easily predictable.
(This has little effect on workloads generated by "ovs-benchmark rate"
because that benchmark is effectively "self-clocking", that is, a new flow
is triggered only by a reply to a request made earlier, which means that
the number of buffered packets at any given has a known, constant upper
limit.)
Bug #10210.
Signed-off-by: Ben Pfaff <blp@nicira.com>
2012-03-15 21:15:38 -07:00
|
|
|
|
int rcvbuf;
|
2010-12-10 09:51:03 -08:00
|
|
|
|
int retval = 0;
|
|
|
|
|
|
2013-06-19 11:39:11 -07:00
|
|
|
|
if (ovsthread_once_start(&once)) {
|
2011-10-14 13:55:00 -07:00
|
|
|
|
int save_errno = errno;
|
|
|
|
|
errno = 0;
|
|
|
|
|
|
|
|
|
|
max_iovs = sysconf(_SC_UIO_MAXIOV);
|
|
|
|
|
if (max_iovs < _XOPEN_IOV_MAX) {
|
|
|
|
|
if (max_iovs == -1 && errno) {
|
2013-06-24 10:54:49 -07:00
|
|
|
|
VLOG_WARN("sysconf(_SC_UIO_MAXIOV): %s", ovs_strerror(errno));
|
2011-10-14 13:55:00 -07:00
|
|
|
|
}
|
|
|
|
|
max_iovs = _XOPEN_IOV_MAX;
|
|
|
|
|
} else if (max_iovs > MAX_IOVS) {
|
|
|
|
|
max_iovs = MAX_IOVS;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
errno = save_errno;
|
2013-06-19 11:39:11 -07:00
|
|
|
|
ovsthread_once_done(&once);
|
2011-10-14 13:55:00 -07:00
|
|
|
|
}
|
|
|
|
|
|
2010-12-10 09:51:03 -08:00
|
|
|
|
*sockp = NULL;
|
2013-04-26 14:15:37 -07:00
|
|
|
|
sock = xmalloc(sizeof *sock);
|
2010-12-10 09:51:03 -08:00
|
|
|
|
|
|
|
|
|
sock->fd = socket(AF_NETLINK, SOCK_RAW, protocol);
|
|
|
|
|
if (sock->fd < 0) {
|
2013-06-24 10:54:49 -07:00
|
|
|
|
VLOG_ERR("fcntl: %s", ovs_strerror(errno));
|
2010-12-10 09:51:03 -08:00
|
|
|
|
goto error;
|
|
|
|
|
}
|
2011-01-18 14:07:52 -08:00
|
|
|
|
sock->protocol = protocol;
|
netlink: Postpone choosing sequence numbers until send time.
Choosing sequence numbers at time of creating a packet means that
nl_sock_transact_multiple() has to search for the sequence number
of a reply, because the sequence numbers of the requests aren't
necessarily sequential. This commit makes it possible to avoid
the search, by deferring choice of sequence numbers until the
time that we send the packets. It doesn't actually modify
nl_sock_transact_multiple(), which will happen in a later commit.
Previously, I was concerned about a theoretical race condition
described in a comment in the old versino of this code:
This implementation uses sequence numbers that are unique
process-wide, to avoid a hypothetical race: send request, close
socket, open new socket that reuses the old socket's PID value,
send request on new socket, receive reply from kernel to old
socket but with same PID and sequence number. (This race could be
avoided other ways, e.g. by preventing PIDs from being quickly
reused).
However, I no longer believe that this can be a real problem,
because Netlink operates synchronously. The reply to a request
will always arrive before the socket can be closed and a new
socket opened with the old socket's PID.
Signed-off-by: Ben Pfaff <blp@nicira.com>
2012-04-16 16:01:01 -07:00
|
|
|
|
sock->next_seq = 1;
|
2010-12-10 09:51:03 -08:00
|
|
|
|
|
netlink-socket: Increase Netlink socket receive buffer size.
Open vSwitch userspace can set up flows at a high rate, but it is somewhat
"bursty" in opportunities to set up flows, by which I mean that OVS sets up
a batch of flows, then goes off and does some other work for a while, then
sets up another batch of flows, and so on. The result is that, if a large
number of packets that need flow setups come in all at once, then some of
them can overflow the relatively small kernel-to-user buffers.
This commit increases the kernel-to-user buffers from the default of
approximately 120 kB each to 1 MB each. In one somewhat synthetic test
case that I ran based on an "hping3" that generated a load of about 20,000
new flows per second (including both requests and replies), this reduced
the packets dropped at the kernel-to-user interface from about 30% to none.
I expect that it will similarly improve packet loss in workloads where
flow arrival is not easily predictable.
(This has little effect on workloads generated by "ovs-benchmark rate"
because that benchmark is effectively "self-clocking", that is, a new flow
is triggered only by a reply to a request made earlier, which means that
the number of buffered packets at any given has a known, constant upper
limit.)
Bug #10210.
Signed-off-by: Ben Pfaff <blp@nicira.com>
2012-03-15 21:15:38 -07:00
|
|
|
|
rcvbuf = 1024 * 1024;
|
|
|
|
|
if (setsockopt(sock->fd, SOL_SOCKET, SO_RCVBUFFORCE,
|
|
|
|
|
&rcvbuf, sizeof rcvbuf)) {
|
2012-08-17 15:40:03 -07:00
|
|
|
|
/* Only root can use SO_RCVBUFFORCE. Everyone else gets EPERM.
|
|
|
|
|
* Warn only if the failure is therefore unexpected. */
|
2013-04-11 11:33:24 -07:00
|
|
|
|
if (errno != EPERM) {
|
2012-08-17 15:40:03 -07:00
|
|
|
|
VLOG_WARN_RL(&rl, "setting %d-byte socket receive buffer failed "
|
2013-06-24 10:54:49 -07:00
|
|
|
|
"(%s)", rcvbuf, ovs_strerror(errno));
|
2012-08-17 15:40:03 -07:00
|
|
|
|
}
|
netlink-socket: Increase Netlink socket receive buffer size.
Open vSwitch userspace can set up flows at a high rate, but it is somewhat
"bursty" in opportunities to set up flows, by which I mean that OVS sets up
a batch of flows, then goes off and does some other work for a while, then
sets up another batch of flows, and so on. The result is that, if a large
number of packets that need flow setups come in all at once, then some of
them can overflow the relatively small kernel-to-user buffers.
This commit increases the kernel-to-user buffers from the default of
approximately 120 kB each to 1 MB each. In one somewhat synthetic test
case that I ran based on an "hping3" that generated a load of about 20,000
new flows per second (including both requests and replies), this reduced
the packets dropped at the kernel-to-user interface from about 30% to none.
I expect that it will similarly improve packet loss in workloads where
flow arrival is not easily predictable.
(This has little effect on workloads generated by "ovs-benchmark rate"
because that benchmark is effectively "self-clocking", that is, a new flow
is triggered only by a reply to a request made earlier, which means that
the number of buffered packets at any given has a known, constant upper
limit.)
Bug #10210.
Signed-off-by: Ben Pfaff <blp@nicira.com>
2012-03-15 21:15:38 -07:00
|
|
|
|
}
|
|
|
|
|
|
2011-10-14 13:55:00 -07:00
|
|
|
|
retval = get_socket_rcvbuf(sock->fd);
|
|
|
|
|
if (retval < 0) {
|
|
|
|
|
retval = -retval;
|
|
|
|
|
goto error;
|
|
|
|
|
}
|
|
|
|
|
sock->rcvbuf = retval;
|
|
|
|
|
|
2011-11-14 10:10:58 -08:00
|
|
|
|
/* Connect to kernel (pid 0) as remote address. */
|
2010-12-10 09:51:03 -08:00
|
|
|
|
memset(&remote, 0, sizeof remote);
|
|
|
|
|
remote.nl_family = AF_NETLINK;
|
|
|
|
|
remote.nl_pid = 0;
|
|
|
|
|
if (connect(sock->fd, (struct sockaddr *) &remote, sizeof remote) < 0) {
|
2013-06-24 10:54:49 -07:00
|
|
|
|
VLOG_ERR("connect(0): %s", ovs_strerror(errno));
|
2011-11-14 10:10:58 -08:00
|
|
|
|
goto error;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Obtain pid assigned by kernel. */
|
|
|
|
|
local_size = sizeof local;
|
|
|
|
|
if (getsockname(sock->fd, (struct sockaddr *) &local, &local_size) < 0) {
|
2013-06-24 10:54:49 -07:00
|
|
|
|
VLOG_ERR("getsockname: %s", ovs_strerror(errno));
|
2011-11-14 10:10:58 -08:00
|
|
|
|
goto error;
|
|
|
|
|
}
|
|
|
|
|
if (local_size < sizeof local || local.nl_family != AF_NETLINK) {
|
|
|
|
|
VLOG_ERR("getsockname returned bad Netlink name");
|
|
|
|
|
retval = EINVAL;
|
|
|
|
|
goto error;
|
2010-12-10 09:51:03 -08:00
|
|
|
|
}
|
2011-11-14 10:10:58 -08:00
|
|
|
|
sock->pid = local.nl_pid;
|
2010-12-10 09:51:03 -08:00
|
|
|
|
|
|
|
|
|
*sockp = sock;
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
error:
|
|
|
|
|
if (retval == 0) {
|
|
|
|
|
retval = errno;
|
|
|
|
|
if (retval == 0) {
|
|
|
|
|
retval = EINVAL;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
if (sock->fd >= 0) {
|
|
|
|
|
close(sock->fd);
|
|
|
|
|
}
|
|
|
|
|
free(sock);
|
|
|
|
|
return retval;
|
|
|
|
|
}
|
|
|
|
|
|
netlink-socket: Make dumping and doing transactions on same nl_sock safe.
It's not safe to use a single Netlink fd to do multiple operations in an
synchronous way. Some of the limitations are fundamental; for example, the
kernel only supports a single "dump" operation at a time. Others are
limitations imposed by the OVS coding style; for example, our Netlink
library is not callback based, so nothing can be done about incoming
messages that can't be handled immediately. Regardless, in OVS multicast
groups, transactions, and dumps cannot coexist on a single nl_sock.
This is only mildly irritating at the moment, but it will become much worse
later on, when dpif-linux shifts to using Netlink dumps for listing various
kinds of datapath entities. When that happens, a dump will be in progress
in situations where the dpif-linux client might want to do other
operations. For example, it is reasonable for the client to list flows
and, in the middle, look up information on vports mentioned in those flows.
It might be possible to simply ban and avoid such nested operations--I have
not even audited the source tree to find out whether we do anything like
that already--but that seems like an unnecessary cramp on our coding style.
Furthermore, it's difficult to explain and justify without understanding
the implementation.
This patch takes another approach, by improving the Netlink socket library
to avoid artificial constraints. When an operation, or a dump, or joining
a multicast group would cause a problem, this patch makes the library
transparently create a separate Netlink socket. This solves the problem
without putting any onerous restrictions on use.
This commit also slightly simplifies netdev_vport_reset_names(). It had
been written to destroy the dump object before the Netlink socket that it
used, but this is no longer necessary and doing it in the opposite order
saved a few lines of code.
Reviewed by Ethan Jackson <ethan@nicira.com>.
2011-01-22 15:23:10 -08:00
|
|
|
|
/* Creates a new netlink socket for the same protocol as 'src'. Returns 0 and
|
|
|
|
|
* sets '*sockp' to the new socket if successful, otherwise returns a positive
|
|
|
|
|
* errno value. */
|
|
|
|
|
int
|
|
|
|
|
nl_sock_clone(const struct nl_sock *src, struct nl_sock **sockp)
|
|
|
|
|
{
|
|
|
|
|
return nl_sock_create(src->protocol, sockp);
|
|
|
|
|
}
|
|
|
|
|
|
2010-12-10 09:51:03 -08:00
|
|
|
|
/* Destroys netlink socket 'sock'. */
|
|
|
|
|
void
|
|
|
|
|
nl_sock_destroy(struct nl_sock *sock)
|
|
|
|
|
{
|
|
|
|
|
if (sock) {
|
2013-04-29 13:57:50 -07:00
|
|
|
|
close(sock->fd);
|
|
|
|
|
free(sock);
|
2010-12-10 09:51:03 -08:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2011-01-09 16:57:45 -08:00
|
|
|
|
/* Tries to add 'sock' as a listener for 'multicast_group'. Returns 0 if
|
|
|
|
|
* successful, otherwise a positive errno value.
|
|
|
|
|
*
|
2011-09-22 11:36:39 -07:00
|
|
|
|
* A socket that is subscribed to a multicast group that receives asynchronous
|
|
|
|
|
* notifications must not be used for Netlink transactions or dumps, because
|
|
|
|
|
* transactions and dumps can cause notifications to be lost.
|
|
|
|
|
*
|
2011-01-09 16:57:45 -08:00
|
|
|
|
* Multicast group numbers are always positive.
|
|
|
|
|
*
|
|
|
|
|
* It is not an error to attempt to join a multicast group to which a socket
|
|
|
|
|
* already belongs. */
|
|
|
|
|
int
|
|
|
|
|
nl_sock_join_mcgroup(struct nl_sock *sock, unsigned int multicast_group)
|
|
|
|
|
{
|
|
|
|
|
if (setsockopt(sock->fd, SOL_NETLINK, NETLINK_ADD_MEMBERSHIP,
|
|
|
|
|
&multicast_group, sizeof multicast_group) < 0) {
|
|
|
|
|
VLOG_WARN("could not join multicast group %u (%s)",
|
2013-06-24 10:54:49 -07:00
|
|
|
|
multicast_group, ovs_strerror(errno));
|
2011-01-09 16:57:45 -08:00
|
|
|
|
return errno;
|
|
|
|
|
}
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Tries to make 'sock' stop listening to 'multicast_group'. Returns 0 if
|
|
|
|
|
* successful, otherwise a positive errno value.
|
|
|
|
|
*
|
|
|
|
|
* Multicast group numbers are always positive.
|
|
|
|
|
*
|
|
|
|
|
* It is not an error to attempt to leave a multicast group to which a socket
|
|
|
|
|
* does not belong.
|
|
|
|
|
*
|
|
|
|
|
* On success, reading from 'sock' will still return any messages that were
|
|
|
|
|
* received on 'multicast_group' before the group was left. */
|
|
|
|
|
int
|
|
|
|
|
nl_sock_leave_mcgroup(struct nl_sock *sock, unsigned int multicast_group)
|
|
|
|
|
{
|
|
|
|
|
if (setsockopt(sock->fd, SOL_NETLINK, NETLINK_DROP_MEMBERSHIP,
|
|
|
|
|
&multicast_group, sizeof multicast_group) < 0) {
|
|
|
|
|
VLOG_WARN("could not leave multicast group %u (%s)",
|
2013-06-24 10:54:49 -07:00
|
|
|
|
multicast_group, ovs_strerror(errno));
|
2011-01-09 16:57:45 -08:00
|
|
|
|
return errno;
|
|
|
|
|
}
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
netlink-socket: Make dumping and doing transactions on same nl_sock safe.
It's not safe to use a single Netlink fd to do multiple operations in an
synchronous way. Some of the limitations are fundamental; for example, the
kernel only supports a single "dump" operation at a time. Others are
limitations imposed by the OVS coding style; for example, our Netlink
library is not callback based, so nothing can be done about incoming
messages that can't be handled immediately. Regardless, in OVS multicast
groups, transactions, and dumps cannot coexist on a single nl_sock.
This is only mildly irritating at the moment, but it will become much worse
later on, when dpif-linux shifts to using Netlink dumps for listing various
kinds of datapath entities. When that happens, a dump will be in progress
in situations where the dpif-linux client might want to do other
operations. For example, it is reasonable for the client to list flows
and, in the middle, look up information on vports mentioned in those flows.
It might be possible to simply ban and avoid such nested operations--I have
not even audited the source tree to find out whether we do anything like
that already--but that seems like an unnecessary cramp on our coding style.
Furthermore, it's difficult to explain and justify without understanding
the implementation.
This patch takes another approach, by improving the Netlink socket library
to avoid artificial constraints. When an operation, or a dump, or joining
a multicast group would cause a problem, this patch makes the library
transparently create a separate Netlink socket. This solves the problem
without putting any onerous restrictions on use.
This commit also slightly simplifies netdev_vport_reset_names(). It had
been written to destroy the dump object before the Netlink socket that it
used, but this is no longer necessary and doing it in the opposite order
saved a few lines of code.
Reviewed by Ethan Jackson <ethan@nicira.com>.
2011-01-22 15:23:10 -08:00
|
|
|
|
static int
|
2012-07-05 08:41:03 -07:00
|
|
|
|
nl_sock_send__(struct nl_sock *sock, const struct ofpbuf *msg,
|
|
|
|
|
uint32_t nlmsg_seq, bool wait)
|
2010-12-10 09:51:03 -08:00
|
|
|
|
{
|
|
|
|
|
struct nlmsghdr *nlmsg = nl_msg_nlmsghdr(msg);
|
|
|
|
|
int error;
|
|
|
|
|
|
2014-03-30 01:31:50 -07:00
|
|
|
|
nlmsg->nlmsg_len = ofpbuf_size(msg);
|
2012-07-05 08:41:03 -07:00
|
|
|
|
nlmsg->nlmsg_seq = nlmsg_seq;
|
2010-12-10 09:51:03 -08:00
|
|
|
|
nlmsg->nlmsg_pid = sock->pid;
|
|
|
|
|
do {
|
|
|
|
|
int retval;
|
2014-03-30 01:31:50 -07:00
|
|
|
|
retval = send(sock->fd, ofpbuf_data(msg), ofpbuf_size(msg), wait ? 0 : MSG_DONTWAIT);
|
2010-12-10 09:51:03 -08:00
|
|
|
|
error = retval < 0 ? errno : 0;
|
|
|
|
|
} while (error == EINTR);
|
2014-03-30 01:31:50 -07:00
|
|
|
|
log_nlmsg(__func__, error, ofpbuf_data(msg), ofpbuf_size(msg), sock->protocol);
|
2010-12-10 09:51:03 -08:00
|
|
|
|
if (!error) {
|
|
|
|
|
COVERAGE_INC(netlink_sent);
|
|
|
|
|
}
|
|
|
|
|
return error;
|
|
|
|
|
}
|
|
|
|
|
|
netlink-socket: Make dumping and doing transactions on same nl_sock safe.
It's not safe to use a single Netlink fd to do multiple operations in an
synchronous way. Some of the limitations are fundamental; for example, the
kernel only supports a single "dump" operation at a time. Others are
limitations imposed by the OVS coding style; for example, our Netlink
library is not callback based, so nothing can be done about incoming
messages that can't be handled immediately. Regardless, in OVS multicast
groups, transactions, and dumps cannot coexist on a single nl_sock.
This is only mildly irritating at the moment, but it will become much worse
later on, when dpif-linux shifts to using Netlink dumps for listing various
kinds of datapath entities. When that happens, a dump will be in progress
in situations where the dpif-linux client might want to do other
operations. For example, it is reasonable for the client to list flows
and, in the middle, look up information on vports mentioned in those flows.
It might be possible to simply ban and avoid such nested operations--I have
not even audited the source tree to find out whether we do anything like
that already--but that seems like an unnecessary cramp on our coding style.
Furthermore, it's difficult to explain and justify without understanding
the implementation.
This patch takes another approach, by improving the Netlink socket library
to avoid artificial constraints. When an operation, or a dump, or joining
a multicast group would cause a problem, this patch makes the library
transparently create a separate Netlink socket. This solves the problem
without putting any onerous restrictions on use.
This commit also slightly simplifies netdev_vport_reset_names(). It had
been written to destroy the dump object before the Netlink socket that it
used, but this is no longer necessary and doing it in the opposite order
saved a few lines of code.
Reviewed by Ethan Jackson <ethan@nicira.com>.
2011-01-22 15:23:10 -08:00
|
|
|
|
/* Tries to send 'msg', which must contain a Netlink message, to the kernel on
|
2014-03-30 01:31:50 -07:00
|
|
|
|
* 'sock'. nlmsg_len in 'msg' will be finalized to match ofpbuf_size(msg), nlmsg_pid
|
2012-07-05 08:41:03 -07:00
|
|
|
|
* will be set to 'sock''s pid, and nlmsg_seq will be initialized to a fresh
|
|
|
|
|
* sequence number, before the message is sent.
|
netlink-socket: Make dumping and doing transactions on same nl_sock safe.
It's not safe to use a single Netlink fd to do multiple operations in an
synchronous way. Some of the limitations are fundamental; for example, the
kernel only supports a single "dump" operation at a time. Others are
limitations imposed by the OVS coding style; for example, our Netlink
library is not callback based, so nothing can be done about incoming
messages that can't be handled immediately. Regardless, in OVS multicast
groups, transactions, and dumps cannot coexist on a single nl_sock.
This is only mildly irritating at the moment, but it will become much worse
later on, when dpif-linux shifts to using Netlink dumps for listing various
kinds of datapath entities. When that happens, a dump will be in progress
in situations where the dpif-linux client might want to do other
operations. For example, it is reasonable for the client to list flows
and, in the middle, look up information on vports mentioned in those flows.
It might be possible to simply ban and avoid such nested operations--I have
not even audited the source tree to find out whether we do anything like
that already--but that seems like an unnecessary cramp on our coding style.
Furthermore, it's difficult to explain and justify without understanding
the implementation.
This patch takes another approach, by improving the Netlink socket library
to avoid artificial constraints. When an operation, or a dump, or joining
a multicast group would cause a problem, this patch makes the library
transparently create a separate Netlink socket. This solves the problem
without putting any onerous restrictions on use.
This commit also slightly simplifies netdev_vport_reset_names(). It had
been written to destroy the dump object before the Netlink socket that it
used, but this is no longer necessary and doing it in the opposite order
saved a few lines of code.
Reviewed by Ethan Jackson <ethan@nicira.com>.
2011-01-22 15:23:10 -08:00
|
|
|
|
*
|
|
|
|
|
* Returns 0 if successful, otherwise a positive errno value. If
|
|
|
|
|
* 'wait' is true, then the send will wait until buffer space is ready;
|
|
|
|
|
* otherwise, returns EAGAIN if the 'sock' send buffer is full. */
|
|
|
|
|
int
|
|
|
|
|
nl_sock_send(struct nl_sock *sock, const struct ofpbuf *msg, bool wait)
|
2012-07-05 08:41:03 -07:00
|
|
|
|
{
|
|
|
|
|
return nl_sock_send_seq(sock, msg, nl_sock_allocate_seq(sock, 1), wait);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Tries to send 'msg', which must contain a Netlink message, to the kernel on
|
2014-03-30 01:31:50 -07:00
|
|
|
|
* 'sock'. nlmsg_len in 'msg' will be finalized to match ofpbuf_size(msg), nlmsg_pid
|
2012-07-05 08:41:03 -07:00
|
|
|
|
* will be set to 'sock''s pid, and nlmsg_seq will be initialized to
|
|
|
|
|
* 'nlmsg_seq', before the message is sent.
|
|
|
|
|
*
|
|
|
|
|
* Returns 0 if successful, otherwise a positive errno value. If
|
|
|
|
|
* 'wait' is true, then the send will wait until buffer space is ready;
|
|
|
|
|
* otherwise, returns EAGAIN if the 'sock' send buffer is full.
|
|
|
|
|
*
|
|
|
|
|
* This function is suitable for sending a reply to a request that was received
|
|
|
|
|
* with sequence number 'nlmsg_seq'. Otherwise, use nl_sock_send() instead. */
|
|
|
|
|
int
|
|
|
|
|
nl_sock_send_seq(struct nl_sock *sock, const struct ofpbuf *msg,
|
|
|
|
|
uint32_t nlmsg_seq, bool wait)
|
netlink-socket: Make dumping and doing transactions on same nl_sock safe.
It's not safe to use a single Netlink fd to do multiple operations in an
synchronous way. Some of the limitations are fundamental; for example, the
kernel only supports a single "dump" operation at a time. Others are
limitations imposed by the OVS coding style; for example, our Netlink
library is not callback based, so nothing can be done about incoming
messages that can't be handled immediately. Regardless, in OVS multicast
groups, transactions, and dumps cannot coexist on a single nl_sock.
This is only mildly irritating at the moment, but it will become much worse
later on, when dpif-linux shifts to using Netlink dumps for listing various
kinds of datapath entities. When that happens, a dump will be in progress
in situations where the dpif-linux client might want to do other
operations. For example, it is reasonable for the client to list flows
and, in the middle, look up information on vports mentioned in those flows.
It might be possible to simply ban and avoid such nested operations--I have
not even audited the source tree to find out whether we do anything like
that already--but that seems like an unnecessary cramp on our coding style.
Furthermore, it's difficult to explain and justify without understanding
the implementation.
This patch takes another approach, by improving the Netlink socket library
to avoid artificial constraints. When an operation, or a dump, or joining
a multicast group would cause a problem, this patch makes the library
transparently create a separate Netlink socket. This solves the problem
without putting any onerous restrictions on use.
This commit also slightly simplifies netdev_vport_reset_names(). It had
been written to destroy the dump object before the Netlink socket that it
used, but this is no longer necessary and doing it in the opposite order
saved a few lines of code.
Reviewed by Ethan Jackson <ethan@nicira.com>.
2011-01-22 15:23:10 -08:00
|
|
|
|
{
|
2012-07-05 08:41:03 -07:00
|
|
|
|
return nl_sock_send__(sock, msg, nlmsg_seq, wait);
|
netlink-socket: Make dumping and doing transactions on same nl_sock safe.
It's not safe to use a single Netlink fd to do multiple operations in an
synchronous way. Some of the limitations are fundamental; for example, the
kernel only supports a single "dump" operation at a time. Others are
limitations imposed by the OVS coding style; for example, our Netlink
library is not callback based, so nothing can be done about incoming
messages that can't be handled immediately. Regardless, in OVS multicast
groups, transactions, and dumps cannot coexist on a single nl_sock.
This is only mildly irritating at the moment, but it will become much worse
later on, when dpif-linux shifts to using Netlink dumps for listing various
kinds of datapath entities. When that happens, a dump will be in progress
in situations where the dpif-linux client might want to do other
operations. For example, it is reasonable for the client to list flows
and, in the middle, look up information on vports mentioned in those flows.
It might be possible to simply ban and avoid such nested operations--I have
not even audited the source tree to find out whether we do anything like
that already--but that seems like an unnecessary cramp on our coding style.
Furthermore, it's difficult to explain and justify without understanding
the implementation.
This patch takes another approach, by improving the Netlink socket library
to avoid artificial constraints. When an operation, or a dump, or joining
a multicast group would cause a problem, this patch makes the library
transparently create a separate Netlink socket. This solves the problem
without putting any onerous restrictions on use.
This commit also slightly simplifies netdev_vport_reset_names(). It had
been written to destroy the dump object before the Netlink socket that it
used, but this is no longer necessary and doing it in the opposite order
saved a few lines of code.
Reviewed by Ethan Jackson <ethan@nicira.com>.
2011-01-22 15:23:10 -08:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int
|
2012-04-09 15:35:29 -07:00
|
|
|
|
nl_sock_recv__(struct nl_sock *sock, struct ofpbuf *buf, bool wait)
|
2010-12-10 09:51:03 -08:00
|
|
|
|
{
|
2012-04-09 15:35:29 -07:00
|
|
|
|
/* We can't accurately predict the size of the data to be received. The
|
|
|
|
|
* caller is supposed to have allocated enough space in 'buf' to handle the
|
|
|
|
|
* "typical" case. To handle exceptions, we make available enough space in
|
|
|
|
|
* 'tail' to allow Netlink messages to be up to 64 kB long (a reasonable
|
|
|
|
|
* figure since that's the maximum length of a Netlink attribute). */
|
2010-12-10 09:51:03 -08:00
|
|
|
|
struct nlmsghdr *nlmsghdr;
|
2012-04-09 15:35:29 -07:00
|
|
|
|
uint8_t tail[65536];
|
2011-07-27 14:56:03 -07:00
|
|
|
|
struct iovec iov[2];
|
|
|
|
|
struct msghdr msg;
|
|
|
|
|
ssize_t retval;
|
2014-06-30 14:57:42 -07:00
|
|
|
|
int error;
|
2011-07-27 14:56:03 -07:00
|
|
|
|
|
2012-11-06 13:14:55 -08:00
|
|
|
|
ovs_assert(buf->allocated >= sizeof *nlmsghdr);
|
2012-04-09 15:35:29 -07:00
|
|
|
|
ofpbuf_clear(buf);
|
2010-12-10 09:51:03 -08:00
|
|
|
|
|
2014-03-30 01:31:50 -07:00
|
|
|
|
iov[0].iov_base = ofpbuf_base(buf);
|
2012-04-09 15:35:29 -07:00
|
|
|
|
iov[0].iov_len = buf->allocated;
|
2011-07-27 14:56:03 -07:00
|
|
|
|
iov[1].iov_base = tail;
|
2012-04-09 15:35:29 -07:00
|
|
|
|
iov[1].iov_len = sizeof tail;
|
2011-07-27 14:56:03 -07:00
|
|
|
|
|
|
|
|
|
memset(&msg, 0, sizeof msg);
|
|
|
|
|
msg.msg_iov = iov;
|
|
|
|
|
msg.msg_iovlen = 2;
|
|
|
|
|
|
2014-06-30 14:57:42 -07:00
|
|
|
|
/* Receive a Netlink message from the kernel.
|
|
|
|
|
*
|
|
|
|
|
* This works around a kernel bug in which the kernel returns an error code
|
|
|
|
|
* as if it were the number of bytes read. It doesn't actually modify
|
|
|
|
|
* anything in the receive buffer in that case, so we can initialize the
|
|
|
|
|
* Netlink header with an impossible message length and then, upon success,
|
|
|
|
|
* check whether it changed. */
|
|
|
|
|
nlmsghdr = ofpbuf_base(buf);
|
2010-12-10 09:51:03 -08:00
|
|
|
|
do {
|
2014-06-30 14:57:42 -07:00
|
|
|
|
nlmsghdr->nlmsg_len = UINT32_MAX;
|
2011-07-27 14:56:03 -07:00
|
|
|
|
retval = recvmsg(sock->fd, &msg, wait ? 0 : MSG_DONTWAIT);
|
2014-06-30 14:57:42 -07:00
|
|
|
|
error = (retval < 0 ? errno
|
|
|
|
|
: retval == 0 ? ECONNRESET /* not possible? */
|
|
|
|
|
: nlmsghdr->nlmsg_len != UINT32_MAX ? 0
|
2014-07-10 14:32:10 -07:00
|
|
|
|
: retval);
|
2014-06-30 14:57:42 -07:00
|
|
|
|
} while (error == EINTR);
|
|
|
|
|
if (error) {
|
2011-07-27 14:56:03 -07:00
|
|
|
|
if (error == ENOBUFS) {
|
|
|
|
|
/* Socket receive buffer overflow dropped one or more messages that
|
|
|
|
|
* the kernel tried to send to us. */
|
|
|
|
|
COVERAGE_INC(netlink_overflow);
|
|
|
|
|
}
|
|
|
|
|
return error;
|
2010-12-10 09:51:03 -08:00
|
|
|
|
}
|
2011-07-27 14:56:03 -07:00
|
|
|
|
|
2010-12-10 09:51:03 -08:00
|
|
|
|
if (msg.msg_flags & MSG_TRUNC) {
|
2013-11-25 23:38:48 -08:00
|
|
|
|
VLOG_ERR_RL(&rl, "truncated message (longer than %"PRIuSIZE" bytes)",
|
2012-04-09 15:35:29 -07:00
|
|
|
|
sizeof tail);
|
2011-07-27 14:56:03 -07:00
|
|
|
|
return E2BIG;
|
2010-12-10 09:51:03 -08:00
|
|
|
|
}
|
|
|
|
|
|
2011-07-27 14:56:03 -07:00
|
|
|
|
if (retval < sizeof *nlmsghdr
|
2010-12-10 09:51:03 -08:00
|
|
|
|
|| nlmsghdr->nlmsg_len < sizeof *nlmsghdr
|
2011-07-27 14:56:03 -07:00
|
|
|
|
|| nlmsghdr->nlmsg_len > retval) {
|
2014-06-11 09:14:54 -07:00
|
|
|
|
VLOG_ERR_RL(&rl, "received invalid nlmsg (%"PRIuSIZE" bytes < %"PRIuSIZE")",
|
2012-04-09 15:35:29 -07:00
|
|
|
|
retval, sizeof *nlmsghdr);
|
2010-12-10 09:51:03 -08:00
|
|
|
|
return EPROTO;
|
|
|
|
|
}
|
|
|
|
|
|
2014-03-30 01:31:50 -07:00
|
|
|
|
ofpbuf_set_size(buf, MIN(retval, buf->allocated));
|
2012-04-09 15:35:29 -07:00
|
|
|
|
if (retval > buf->allocated) {
|
|
|
|
|
COVERAGE_INC(netlink_recv_jumbo);
|
|
|
|
|
ofpbuf_put(buf, tail, retval - buf->allocated);
|
|
|
|
|
}
|
|
|
|
|
|
2014-03-30 01:31:50 -07:00
|
|
|
|
log_nlmsg(__func__, 0, ofpbuf_data(buf), ofpbuf_size(buf), sock->protocol);
|
2010-12-10 09:51:03 -08:00
|
|
|
|
COVERAGE_INC(netlink_received);
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2012-04-09 15:35:29 -07:00
|
|
|
|
/* Tries to receive a Netlink message from the kernel on 'sock' into 'buf'. If
|
|
|
|
|
* 'wait' is true, waits for a message to be ready. Otherwise, fails with
|
|
|
|
|
* EAGAIN if the 'sock' receive buffer is empty.
|
|
|
|
|
*
|
|
|
|
|
* The caller must have initialized 'buf' with an allocation of at least
|
|
|
|
|
* NLMSG_HDRLEN bytes. For best performance, the caller should allocate enough
|
|
|
|
|
* space for a "typical" message.
|
|
|
|
|
*
|
|
|
|
|
* On success, returns 0 and replaces 'buf''s previous content by the received
|
|
|
|
|
* message. This function expands 'buf''s allocated memory, as necessary, to
|
|
|
|
|
* hold the actual size of the received message.
|
netlink-socket: Make dumping and doing transactions on same nl_sock safe.
It's not safe to use a single Netlink fd to do multiple operations in an
synchronous way. Some of the limitations are fundamental; for example, the
kernel only supports a single "dump" operation at a time. Others are
limitations imposed by the OVS coding style; for example, our Netlink
library is not callback based, so nothing can be done about incoming
messages that can't be handled immediately. Regardless, in OVS multicast
groups, transactions, and dumps cannot coexist on a single nl_sock.
This is only mildly irritating at the moment, but it will become much worse
later on, when dpif-linux shifts to using Netlink dumps for listing various
kinds of datapath entities. When that happens, a dump will be in progress
in situations where the dpif-linux client might want to do other
operations. For example, it is reasonable for the client to list flows
and, in the middle, look up information on vports mentioned in those flows.
It might be possible to simply ban and avoid such nested operations--I have
not even audited the source tree to find out whether we do anything like
that already--but that seems like an unnecessary cramp on our coding style.
Furthermore, it's difficult to explain and justify without understanding
the implementation.
This patch takes another approach, by improving the Netlink socket library
to avoid artificial constraints. When an operation, or a dump, or joining
a multicast group would cause a problem, this patch makes the library
transparently create a separate Netlink socket. This solves the problem
without putting any onerous restrictions on use.
This commit also slightly simplifies netdev_vport_reset_names(). It had
been written to destroy the dump object before the Netlink socket that it
used, but this is no longer necessary and doing it in the opposite order
saved a few lines of code.
Reviewed by Ethan Jackson <ethan@nicira.com>.
2011-01-22 15:23:10 -08:00
|
|
|
|
*
|
2012-04-09 15:35:29 -07:00
|
|
|
|
* On failure, returns a positive errno value and clears 'buf' to zero length.
|
|
|
|
|
* 'buf' retains its previous memory allocation.
|
|
|
|
|
*
|
|
|
|
|
* Regardless of success or failure, this function resets 'buf''s headroom to
|
|
|
|
|
* 0. */
|
netlink-socket: Make dumping and doing transactions on same nl_sock safe.
It's not safe to use a single Netlink fd to do multiple operations in an
synchronous way. Some of the limitations are fundamental; for example, the
kernel only supports a single "dump" operation at a time. Others are
limitations imposed by the OVS coding style; for example, our Netlink
library is not callback based, so nothing can be done about incoming
messages that can't be handled immediately. Regardless, in OVS multicast
groups, transactions, and dumps cannot coexist on a single nl_sock.
This is only mildly irritating at the moment, but it will become much worse
later on, when dpif-linux shifts to using Netlink dumps for listing various
kinds of datapath entities. When that happens, a dump will be in progress
in situations where the dpif-linux client might want to do other
operations. For example, it is reasonable for the client to list flows
and, in the middle, look up information on vports mentioned in those flows.
It might be possible to simply ban and avoid such nested operations--I have
not even audited the source tree to find out whether we do anything like
that already--but that seems like an unnecessary cramp on our coding style.
Furthermore, it's difficult to explain and justify without understanding
the implementation.
This patch takes another approach, by improving the Netlink socket library
to avoid artificial constraints. When an operation, or a dump, or joining
a multicast group would cause a problem, this patch makes the library
transparently create a separate Netlink socket. This solves the problem
without putting any onerous restrictions on use.
This commit also slightly simplifies netdev_vport_reset_names(). It had
been written to destroy the dump object before the Netlink socket that it
used, but this is no longer necessary and doing it in the opposite order
saved a few lines of code.
Reviewed by Ethan Jackson <ethan@nicira.com>.
2011-01-22 15:23:10 -08:00
|
|
|
|
int
|
2012-04-09 15:35:29 -07:00
|
|
|
|
nl_sock_recv(struct nl_sock *sock, struct ofpbuf *buf, bool wait)
|
netlink-socket: Make dumping and doing transactions on same nl_sock safe.
It's not safe to use a single Netlink fd to do multiple operations in an
synchronous way. Some of the limitations are fundamental; for example, the
kernel only supports a single "dump" operation at a time. Others are
limitations imposed by the OVS coding style; for example, our Netlink
library is not callback based, so nothing can be done about incoming
messages that can't be handled immediately. Regardless, in OVS multicast
groups, transactions, and dumps cannot coexist on a single nl_sock.
This is only mildly irritating at the moment, but it will become much worse
later on, when dpif-linux shifts to using Netlink dumps for listing various
kinds of datapath entities. When that happens, a dump will be in progress
in situations where the dpif-linux client might want to do other
operations. For example, it is reasonable for the client to list flows
and, in the middle, look up information on vports mentioned in those flows.
It might be possible to simply ban and avoid such nested operations--I have
not even audited the source tree to find out whether we do anything like
that already--but that seems like an unnecessary cramp on our coding style.
Furthermore, it's difficult to explain and justify without understanding
the implementation.
This patch takes another approach, by improving the Netlink socket library
to avoid artificial constraints. When an operation, or a dump, or joining
a multicast group would cause a problem, this patch makes the library
transparently create a separate Netlink socket. This solves the problem
without putting any onerous restrictions on use.
This commit also slightly simplifies netdev_vport_reset_names(). It had
been written to destroy the dump object before the Netlink socket that it
used, but this is no longer necessary and doing it in the opposite order
saved a few lines of code.
Reviewed by Ethan Jackson <ethan@nicira.com>.
2011-01-22 15:23:10 -08:00
|
|
|
|
{
|
2012-04-09 15:35:29 -07:00
|
|
|
|
return nl_sock_recv__(sock, buf, wait);
|
2011-10-14 13:55:00 -07:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
nl_sock_record_errors__(struct nl_transaction **transactions, size_t n,
|
|
|
|
|
int error)
|
|
|
|
|
{
|
|
|
|
|
size_t i;
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < n; i++) {
|
2012-04-09 15:35:29 -07:00
|
|
|
|
struct nl_transaction *txn = transactions[i];
|
|
|
|
|
|
|
|
|
|
txn->error = error;
|
|
|
|
|
if (txn->reply) {
|
|
|
|
|
ofpbuf_clear(txn->reply);
|
|
|
|
|
}
|
2011-10-14 13:55:00 -07:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int
|
|
|
|
|
nl_sock_transact_multiple__(struct nl_sock *sock,
|
|
|
|
|
struct nl_transaction **transactions, size_t n,
|
|
|
|
|
size_t *done)
|
|
|
|
|
{
|
2012-04-09 15:35:29 -07:00
|
|
|
|
uint64_t tmp_reply_stub[1024 / 8];
|
|
|
|
|
struct nl_transaction tmp_txn;
|
|
|
|
|
struct ofpbuf tmp_reply;
|
|
|
|
|
|
|
|
|
|
uint32_t base_seq;
|
2011-10-14 13:55:00 -07:00
|
|
|
|
struct iovec iovs[MAX_IOVS];
|
|
|
|
|
struct msghdr msg;
|
|
|
|
|
int error;
|
|
|
|
|
int i;
|
|
|
|
|
|
2012-04-09 15:35:29 -07:00
|
|
|
|
base_seq = nl_sock_allocate_seq(sock, n);
|
2011-10-14 13:55:00 -07:00
|
|
|
|
*done = 0;
|
|
|
|
|
for (i = 0; i < n; i++) {
|
2012-04-09 15:35:29 -07:00
|
|
|
|
struct nl_transaction *txn = transactions[i];
|
|
|
|
|
struct nlmsghdr *nlmsg = nl_msg_nlmsghdr(txn->request);
|
2011-10-14 13:55:00 -07:00
|
|
|
|
|
2014-03-30 01:31:50 -07:00
|
|
|
|
nlmsg->nlmsg_len = ofpbuf_size(txn->request);
|
2012-04-09 15:35:29 -07:00
|
|
|
|
nlmsg->nlmsg_seq = base_seq + i;
|
2011-10-14 13:55:00 -07:00
|
|
|
|
nlmsg->nlmsg_pid = sock->pid;
|
|
|
|
|
|
2014-03-30 01:31:50 -07:00
|
|
|
|
iovs[i].iov_base = ofpbuf_data(txn->request);
|
|
|
|
|
iovs[i].iov_len = ofpbuf_size(txn->request);
|
2011-10-14 13:55:00 -07:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
memset(&msg, 0, sizeof msg);
|
|
|
|
|
msg.msg_iov = iovs;
|
|
|
|
|
msg.msg_iovlen = n;
|
|
|
|
|
do {
|
|
|
|
|
error = sendmsg(sock->fd, &msg, 0) < 0 ? errno : 0;
|
|
|
|
|
} while (error == EINTR);
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < n; i++) {
|
2012-04-09 15:35:29 -07:00
|
|
|
|
struct nl_transaction *txn = transactions[i];
|
2011-10-14 13:55:00 -07:00
|
|
|
|
|
2014-03-30 01:31:50 -07:00
|
|
|
|
log_nlmsg(__func__, error, ofpbuf_data(txn->request), ofpbuf_size(txn->request),
|
2011-10-14 13:55:00 -07:00
|
|
|
|
sock->protocol);
|
|
|
|
|
}
|
|
|
|
|
if (!error) {
|
|
|
|
|
COVERAGE_ADD(netlink_sent, n);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (error) {
|
|
|
|
|
return error;
|
|
|
|
|
}
|
|
|
|
|
|
2012-04-09 15:35:29 -07:00
|
|
|
|
ofpbuf_use_stub(&tmp_reply, tmp_reply_stub, sizeof tmp_reply_stub);
|
|
|
|
|
tmp_txn.request = NULL;
|
|
|
|
|
tmp_txn.reply = &tmp_reply;
|
|
|
|
|
tmp_txn.error = 0;
|
2011-10-14 13:55:00 -07:00
|
|
|
|
while (n > 0) {
|
2012-04-09 15:35:29 -07:00
|
|
|
|
struct nl_transaction *buf_txn, *txn;
|
|
|
|
|
uint32_t seq;
|
|
|
|
|
|
|
|
|
|
/* Find a transaction whose buffer we can use for receiving a reply.
|
|
|
|
|
* If no such transaction is left, use tmp_txn. */
|
|
|
|
|
buf_txn = &tmp_txn;
|
|
|
|
|
for (i = 0; i < n; i++) {
|
|
|
|
|
if (transactions[i]->reply) {
|
|
|
|
|
buf_txn = transactions[i];
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
2011-10-14 13:55:00 -07:00
|
|
|
|
|
2012-04-09 15:35:29 -07:00
|
|
|
|
/* Receive a reply. */
|
|
|
|
|
error = nl_sock_recv__(sock, buf_txn->reply, false);
|
|
|
|
|
if (error) {
|
|
|
|
|
if (error == EAGAIN) {
|
|
|
|
|
nl_sock_record_errors__(transactions, n, 0);
|
|
|
|
|
*done += n;
|
|
|
|
|
error = 0;
|
|
|
|
|
}
|
|
|
|
|
break;
|
2011-10-14 13:55:00 -07:00
|
|
|
|
}
|
|
|
|
|
|
2012-04-09 15:35:29 -07:00
|
|
|
|
/* Match the reply up with a transaction. */
|
|
|
|
|
seq = nl_msg_nlmsghdr(buf_txn->reply)->nlmsg_seq;
|
|
|
|
|
if (seq < base_seq || seq >= base_seq + n) {
|
|
|
|
|
VLOG_DBG_RL(&rl, "ignoring unexpected seq %#"PRIx32, seq);
|
2011-10-14 13:55:00 -07:00
|
|
|
|
continue;
|
|
|
|
|
}
|
2012-04-09 15:35:29 -07:00
|
|
|
|
i = seq - base_seq;
|
|
|
|
|
txn = transactions[i];
|
2011-10-14 13:55:00 -07:00
|
|
|
|
|
2012-04-09 15:35:29 -07:00
|
|
|
|
/* Fill in the results for 'txn'. */
|
|
|
|
|
if (nl_msg_nlmsgerr(buf_txn->reply, &txn->error)) {
|
|
|
|
|
if (txn->reply) {
|
|
|
|
|
ofpbuf_clear(txn->reply);
|
|
|
|
|
}
|
|
|
|
|
if (txn->error) {
|
2011-10-14 13:55:00 -07:00
|
|
|
|
VLOG_DBG_RL(&rl, "received NAK error=%d (%s)",
|
2013-06-24 10:54:49 -07:00
|
|
|
|
error, ovs_strerror(txn->error));
|
2011-10-14 13:55:00 -07:00
|
|
|
|
}
|
|
|
|
|
} else {
|
2012-04-09 15:35:29 -07:00
|
|
|
|
txn->error = 0;
|
|
|
|
|
if (txn->reply && txn != buf_txn) {
|
|
|
|
|
/* Swap buffers. */
|
|
|
|
|
struct ofpbuf *reply = buf_txn->reply;
|
|
|
|
|
buf_txn->reply = txn->reply;
|
|
|
|
|
txn->reply = reply;
|
|
|
|
|
}
|
2011-10-14 13:55:00 -07:00
|
|
|
|
}
|
|
|
|
|
|
2012-04-09 15:35:29 -07:00
|
|
|
|
/* Fill in the results for transactions before 'txn'. (We have to do
|
|
|
|
|
* this after the results for 'txn' itself because of the buffer swap
|
|
|
|
|
* above.) */
|
|
|
|
|
nl_sock_record_errors__(transactions, i, 0);
|
|
|
|
|
|
|
|
|
|
/* Advance. */
|
2011-10-14 13:55:00 -07:00
|
|
|
|
*done += i + 1;
|
|
|
|
|
transactions += i + 1;
|
|
|
|
|
n -= i + 1;
|
2012-04-09 15:35:29 -07:00
|
|
|
|
base_seq += i + 1;
|
2011-10-14 13:55:00 -07:00
|
|
|
|
}
|
2012-04-09 15:35:29 -07:00
|
|
|
|
ofpbuf_uninit(&tmp_reply);
|
2011-10-14 13:55:00 -07:00
|
|
|
|
|
2012-04-09 15:35:29 -07:00
|
|
|
|
return error;
|
2011-10-14 13:55:00 -07:00
|
|
|
|
}
|
|
|
|
|
|
2012-04-09 15:35:29 -07:00
|
|
|
|
/* Sends the 'request' member of the 'n' transactions in 'transactions' on
|
|
|
|
|
* 'sock', in order, and receives responses to all of them. Fills in the
|
2011-10-14 13:55:00 -07:00
|
|
|
|
* 'error' member of each transaction with 0 if it was successful, otherwise
|
2012-04-09 15:35:29 -07:00
|
|
|
|
* with a positive errno value. If 'reply' is nonnull, then it will be filled
|
|
|
|
|
* with the reply if the message receives a detailed reply. In other cases,
|
|
|
|
|
* i.e. where the request failed or had no reply beyond an indication of
|
|
|
|
|
* success, 'reply' will be cleared if it is nonnull.
|
2011-10-14 13:55:00 -07:00
|
|
|
|
*
|
|
|
|
|
* The caller is responsible for destroying each request and reply, and the
|
|
|
|
|
* transactions array itself.
|
|
|
|
|
*
|
|
|
|
|
* Before sending each message, this function will finalize nlmsg_len in each
|
2012-04-09 15:35:29 -07:00
|
|
|
|
* 'request' to match the ofpbuf's size, set nlmsg_pid to 'sock''s pid, and
|
|
|
|
|
* initialize nlmsg_seq.
|
2011-10-14 13:55:00 -07:00
|
|
|
|
*
|
|
|
|
|
* Bare Netlink is an unreliable transport protocol. This function layers
|
|
|
|
|
* reliable delivery and reply semantics on top of bare Netlink. See
|
|
|
|
|
* nl_sock_transact() for some caveats.
|
|
|
|
|
*/
|
|
|
|
|
void
|
|
|
|
|
nl_sock_transact_multiple(struct nl_sock *sock,
|
|
|
|
|
struct nl_transaction **transactions, size_t n)
|
|
|
|
|
{
|
|
|
|
|
int max_batch_count;
|
|
|
|
|
int error;
|
|
|
|
|
|
|
|
|
|
if (!n) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* In theory, every request could have a 64 kB reply. But the default and
|
|
|
|
|
* maximum socket rcvbuf size with typical Dom0 memory sizes both tend to
|
|
|
|
|
* be a bit below 128 kB, so that would only allow a single message in a
|
|
|
|
|
* "batch". So we assume that replies average (at most) 4 kB, which allows
|
|
|
|
|
* a good deal of batching.
|
|
|
|
|
*
|
|
|
|
|
* In practice, most of the requests that we batch either have no reply at
|
|
|
|
|
* all or a brief reply. */
|
|
|
|
|
max_batch_count = MAX(sock->rcvbuf / 4096, 1);
|
|
|
|
|
max_batch_count = MIN(max_batch_count, max_iovs);
|
|
|
|
|
|
|
|
|
|
while (n > 0) {
|
|
|
|
|
size_t count, bytes;
|
|
|
|
|
size_t done;
|
|
|
|
|
|
|
|
|
|
/* Batch up to 'max_batch_count' transactions. But cap it at about a
|
|
|
|
|
* page of requests total because big skbuffs are expensive to
|
|
|
|
|
* allocate in the kernel. */
|
|
|
|
|
#if defined(PAGESIZE)
|
|
|
|
|
enum { MAX_BATCH_BYTES = MAX(1, PAGESIZE - 512) };
|
|
|
|
|
#else
|
|
|
|
|
enum { MAX_BATCH_BYTES = 4096 - 512 };
|
|
|
|
|
#endif
|
2014-03-30 01:31:50 -07:00
|
|
|
|
bytes = ofpbuf_size(transactions[0]->request);
|
2011-10-14 13:55:00 -07:00
|
|
|
|
for (count = 1; count < n && count < max_batch_count; count++) {
|
2014-03-30 01:31:50 -07:00
|
|
|
|
if (bytes + ofpbuf_size(transactions[count]->request) > MAX_BATCH_BYTES) {
|
2011-10-14 13:55:00 -07:00
|
|
|
|
break;
|
|
|
|
|
}
|
2014-03-30 01:31:50 -07:00
|
|
|
|
bytes += ofpbuf_size(transactions[count]->request);
|
2011-10-14 13:55:00 -07:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
error = nl_sock_transact_multiple__(sock, transactions, count, &done);
|
|
|
|
|
transactions += done;
|
|
|
|
|
n -= done;
|
|
|
|
|
|
|
|
|
|
if (error == ENOBUFS) {
|
|
|
|
|
VLOG_DBG_RL(&rl, "receive buffer overflow, resending request");
|
|
|
|
|
} else if (error) {
|
2013-06-24 10:54:49 -07:00
|
|
|
|
VLOG_ERR_RL(&rl, "transaction error (%s)", ovs_strerror(error));
|
2011-10-14 13:55:00 -07:00
|
|
|
|
nl_sock_record_errors__(transactions, n, error);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2010-12-10 09:51:03 -08:00
|
|
|
|
/* Sends 'request' to the kernel via 'sock' and waits for a response. If
|
|
|
|
|
* successful, returns 0. On failure, returns a positive errno value.
|
|
|
|
|
*
|
|
|
|
|
* If 'replyp' is nonnull, then on success '*replyp' is set to the kernel's
|
|
|
|
|
* reply, which the caller is responsible for freeing with ofpbuf_delete(), and
|
|
|
|
|
* on failure '*replyp' is set to NULL. If 'replyp' is null, then the kernel's
|
|
|
|
|
* reply, if any, is discarded.
|
|
|
|
|
*
|
netlink: Postpone choosing sequence numbers until send time.
Choosing sequence numbers at time of creating a packet means that
nl_sock_transact_multiple() has to search for the sequence number
of a reply, because the sequence numbers of the requests aren't
necessarily sequential. This commit makes it possible to avoid
the search, by deferring choice of sequence numbers until the
time that we send the packets. It doesn't actually modify
nl_sock_transact_multiple(), which will happen in a later commit.
Previously, I was concerned about a theoretical race condition
described in a comment in the old versino of this code:
This implementation uses sequence numbers that are unique
process-wide, to avoid a hypothetical race: send request, close
socket, open new socket that reuses the old socket's PID value,
send request on new socket, receive reply from kernel to old
socket but with same PID and sequence number. (This race could be
avoided other ways, e.g. by preventing PIDs from being quickly
reused).
However, I no longer believe that this can be a real problem,
because Netlink operates synchronously. The reply to a request
will always arrive before the socket can be closed and a new
socket opened with the old socket's PID.
Signed-off-by: Ben Pfaff <blp@nicira.com>
2012-04-16 16:01:01 -07:00
|
|
|
|
* Before the message is sent, nlmsg_len in 'request' will be finalized to
|
2014-03-30 01:31:50 -07:00
|
|
|
|
* match ofpbuf_size(msg), nlmsg_pid will be set to 'sock''s pid, and nlmsg_seq will
|
netlink: Postpone choosing sequence numbers until send time.
Choosing sequence numbers at time of creating a packet means that
nl_sock_transact_multiple() has to search for the sequence number
of a reply, because the sequence numbers of the requests aren't
necessarily sequential. This commit makes it possible to avoid
the search, by deferring choice of sequence numbers until the
time that we send the packets. It doesn't actually modify
nl_sock_transact_multiple(), which will happen in a later commit.
Previously, I was concerned about a theoretical race condition
described in a comment in the old versino of this code:
This implementation uses sequence numbers that are unique
process-wide, to avoid a hypothetical race: send request, close
socket, open new socket that reuses the old socket's PID value,
send request on new socket, receive reply from kernel to old
socket but with same PID and sequence number. (This race could be
avoided other ways, e.g. by preventing PIDs from being quickly
reused).
However, I no longer believe that this can be a real problem,
because Netlink operates synchronously. The reply to a request
will always arrive before the socket can be closed and a new
socket opened with the old socket's PID.
Signed-off-by: Ben Pfaff <blp@nicira.com>
2012-04-16 16:01:01 -07:00
|
|
|
|
* be initialized, NLM_F_ACK will be set in nlmsg_flags.
|
2010-12-10 09:51:03 -08:00
|
|
|
|
*
|
|
|
|
|
* The caller is responsible for destroying 'request'.
|
|
|
|
|
*
|
|
|
|
|
* Bare Netlink is an unreliable transport protocol. This function layers
|
|
|
|
|
* reliable delivery and reply semantics on top of bare Netlink.
|
|
|
|
|
*
|
|
|
|
|
* In Netlink, sending a request to the kernel is reliable enough, because the
|
|
|
|
|
* kernel will tell us if the message cannot be queued (and we will in that
|
|
|
|
|
* case put it on the transmit queue and wait until it can be delivered).
|
|
|
|
|
*
|
|
|
|
|
* Receiving the reply is the real problem: if the socket buffer is full when
|
|
|
|
|
* the kernel tries to send the reply, the reply will be dropped. However, the
|
|
|
|
|
* kernel sets a flag that a reply has been dropped. The next call to recv
|
|
|
|
|
* then returns ENOBUFS. We can then re-send the request.
|
|
|
|
|
*
|
|
|
|
|
* Caveats:
|
|
|
|
|
*
|
|
|
|
|
* 1. Netlink depends on sequence numbers to match up requests and
|
|
|
|
|
* replies. The sender of a request supplies a sequence number, and
|
|
|
|
|
* the reply echos back that sequence number.
|
|
|
|
|
*
|
|
|
|
|
* This is fine, but (1) some kernel netlink implementations are
|
|
|
|
|
* broken, in that they fail to echo sequence numbers and (2) this
|
|
|
|
|
* function will drop packets with non-matching sequence numbers, so
|
|
|
|
|
* that only a single request can be usefully transacted at a time.
|
|
|
|
|
*
|
|
|
|
|
* 2. Resending the request causes it to be re-executed, so the request
|
|
|
|
|
* needs to be idempotent.
|
|
|
|
|
*/
|
|
|
|
|
int
|
2011-10-14 13:55:00 -07:00
|
|
|
|
nl_sock_transact(struct nl_sock *sock, const struct ofpbuf *request,
|
|
|
|
|
struct ofpbuf **replyp)
|
2010-12-10 09:51:03 -08:00
|
|
|
|
{
|
2011-10-14 13:55:00 -07:00
|
|
|
|
struct nl_transaction *transactionp;
|
|
|
|
|
struct nl_transaction transaction;
|
2010-12-10 09:51:03 -08:00
|
|
|
|
|
2012-07-13 16:00:29 -07:00
|
|
|
|
transaction.request = CONST_CAST(struct ofpbuf *, request);
|
2012-04-09 15:35:29 -07:00
|
|
|
|
transaction.reply = replyp ? ofpbuf_new(1024) : NULL;
|
2011-10-14 13:55:00 -07:00
|
|
|
|
transactionp = &transaction;
|
2012-04-09 15:35:29 -07:00
|
|
|
|
|
2011-10-14 13:55:00 -07:00
|
|
|
|
nl_sock_transact_multiple(sock, &transactionp, 1);
|
2012-04-09 15:35:29 -07:00
|
|
|
|
|
2010-12-10 09:51:03 -08:00
|
|
|
|
if (replyp) {
|
2012-04-09 15:35:29 -07:00
|
|
|
|
if (transaction.error) {
|
|
|
|
|
ofpbuf_delete(transaction.reply);
|
|
|
|
|
*replyp = NULL;
|
|
|
|
|
} else {
|
|
|
|
|
*replyp = transaction.reply;
|
|
|
|
|
}
|
2010-12-10 09:51:03 -08:00
|
|
|
|
}
|
2012-04-09 15:35:29 -07:00
|
|
|
|
|
2011-10-14 13:55:00 -07:00
|
|
|
|
return transaction.error;
|
2010-12-10 09:51:03 -08:00
|
|
|
|
}
|
|
|
|
|
|
2011-01-11 16:05:37 -08:00
|
|
|
|
/* Drain all the messages currently in 'sock''s receive queue. */
|
|
|
|
|
int
|
|
|
|
|
nl_sock_drain(struct nl_sock *sock)
|
|
|
|
|
{
|
|
|
|
|
return drain_rcvbuf(sock->fd);
|
|
|
|
|
}
|
|
|
|
|
|
2013-04-29 13:57:50 -07:00
|
|
|
|
/* Starts a Netlink "dump" operation, by sending 'request' to the kernel on a
|
|
|
|
|
* Netlink socket created with the given 'protocol', and initializes 'dump' to
|
|
|
|
|
* reflect the state of the operation.
|
2010-12-10 09:51:03 -08:00
|
|
|
|
*
|
2014-01-13 13:50:22 -08:00
|
|
|
|
* 'request' must contain a Netlink message. Before sending the message,
|
|
|
|
|
* nlmsg_len will be finalized to match request->size, and nlmsg_pid will be
|
|
|
|
|
* set to the Netlink socket's pid. NLM_F_DUMP and NLM_F_ACK will be set in
|
|
|
|
|
* nlmsg_flags.
|
2010-12-10 09:51:03 -08:00
|
|
|
|
*
|
2013-04-29 13:57:50 -07:00
|
|
|
|
* The design of this Netlink socket library ensures that the dump is reliable.
|
2010-12-10 09:51:03 -08:00
|
|
|
|
*
|
2014-01-13 13:50:22 -08:00
|
|
|
|
* This function provides no status indication. nl_dump_done() provides an
|
|
|
|
|
* error status for the entire dump operation.
|
2010-12-10 09:51:03 -08:00
|
|
|
|
*
|
2014-01-13 13:50:22 -08:00
|
|
|
|
* The caller must eventually destroy 'request'.
|
2010-12-10 09:51:03 -08:00
|
|
|
|
*/
|
|
|
|
|
void
|
2013-04-29 13:57:50 -07:00
|
|
|
|
nl_dump_start(struct nl_dump *dump, int protocol, const struct ofpbuf *request)
|
2010-12-10 09:51:03 -08:00
|
|
|
|
{
|
2014-02-27 14:13:06 -08:00
|
|
|
|
int status = nl_pool_alloc(protocol, &dump->sock);
|
|
|
|
|
|
|
|
|
|
if (status) {
|
2013-04-29 13:57:50 -07:00
|
|
|
|
return;
|
netlink-socket: Make dumping and doing transactions on same nl_sock safe.
It's not safe to use a single Netlink fd to do multiple operations in an
synchronous way. Some of the limitations are fundamental; for example, the
kernel only supports a single "dump" operation at a time. Others are
limitations imposed by the OVS coding style; for example, our Netlink
library is not callback based, so nothing can be done about incoming
messages that can't be handled immediately. Regardless, in OVS multicast
groups, transactions, and dumps cannot coexist on a single nl_sock.
This is only mildly irritating at the moment, but it will become much worse
later on, when dpif-linux shifts to using Netlink dumps for listing various
kinds of datapath entities. When that happens, a dump will be in progress
in situations where the dpif-linux client might want to do other
operations. For example, it is reasonable for the client to list flows
and, in the middle, look up information on vports mentioned in those flows.
It might be possible to simply ban and avoid such nested operations--I have
not even audited the source tree to find out whether we do anything like
that already--but that seems like an unnecessary cramp on our coding style.
Furthermore, it's difficult to explain and justify without understanding
the implementation.
This patch takes another approach, by improving the Netlink socket library
to avoid artificial constraints. When an operation, or a dump, or joining
a multicast group would cause a problem, this patch makes the library
transparently create a separate Netlink socket. This solves the problem
without putting any onerous restrictions on use.
This commit also slightly simplifies netdev_vport_reset_names(). It had
been written to destroy the dump object before the Netlink socket that it
used, but this is no longer necessary and doing it in the opposite order
saved a few lines of code.
Reviewed by Ethan Jackson <ethan@nicira.com>.
2011-01-22 15:23:10 -08:00
|
|
|
|
}
|
netlink: Postpone choosing sequence numbers until send time.
Choosing sequence numbers at time of creating a packet means that
nl_sock_transact_multiple() has to search for the sequence number
of a reply, because the sequence numbers of the requests aren't
necessarily sequential. This commit makes it possible to avoid
the search, by deferring choice of sequence numbers until the
time that we send the packets. It doesn't actually modify
nl_sock_transact_multiple(), which will happen in a later commit.
Previously, I was concerned about a theoretical race condition
described in a comment in the old versino of this code:
This implementation uses sequence numbers that are unique
process-wide, to avoid a hypothetical race: send request, close
socket, open new socket that reuses the old socket's PID value,
send request on new socket, receive reply from kernel to old
socket but with same PID and sequence number. (This race could be
avoided other ways, e.g. by preventing PIDs from being quickly
reused).
However, I no longer believe that this can be a real problem,
because Netlink operates synchronously. The reply to a request
will always arrive before the socket can be closed and a new
socket opened with the old socket's PID.
Signed-off-by: Ben Pfaff <blp@nicira.com>
2012-04-16 16:01:01 -07:00
|
|
|
|
|
|
|
|
|
nl_msg_nlmsghdr(request)->nlmsg_flags |= NLM_F_DUMP | NLM_F_ACK;
|
2014-02-27 14:13:06 -08:00
|
|
|
|
status = nl_sock_send__(dump->sock, request,
|
|
|
|
|
nl_sock_allocate_seq(dump->sock, 1), true);
|
|
|
|
|
atomic_init(&dump->status, status << 1);
|
2014-01-21 11:29:26 -08:00
|
|
|
|
dump->nl_seq = nl_msg_nlmsghdr(request)->nlmsg_seq;
|
2014-02-27 14:13:06 -08:00
|
|
|
|
dump->status_seq = seq_create();
|
netlink-socket: Work around kernel Netlink dump thread races.
The Linux kernel Netlink implementation has two races that cause problems
for processes that attempt to dump a table in a multithreaded manner.
The first race is in the structure of the kernel netlink_recv() function.
This function pulls a message from the socket queue and, if there is none,
reports EAGAIN:
skb = skb_recv_datagram(sk, flags, noblock, &err);
if (skb == NULL)
goto out;
Only if a message is successfully read from the socket queue does the
function, toward the end, try to queue up a new message to be dumped:
if (nlk->cb && atomic_read(&sk->sk_rmem_alloc) <= sk->sk_rcvbuf / 2) {
ret = netlink_dump(sk);
if (ret) {
sk->sk_err = ret;
sk->sk_error_report(sk);
}
}
This means that if thread A reads a message from a dump, then thread B
attempts to read one before A queues up the next, B will get EAGAIN. This
means that, following EAGAIN, B needs to wait until A returns to userspace
before it tries to read the socket again. nl_dump_next() already does
this, using 'dump->status_seq' (although the need for it has never been
explained clearly, to my knowledge).
The second race is more serious. Suppose thread X and thread Y both
simultaneously attempt to queue up a new message to be dumped, using the
call to netlink_dump() quoted above. netlink_dump() begins with:
mutex_lock(nlk->cb_mutex);
cb = nlk->cb;
if (cb == NULL) {
err = -EINVAL;
goto errout_skb;
}
Suppose that X gets cb_mutex first and finds that the dump is complete. It
will therefore, toward the end of netlink_dump(), clear nlk->cb to NULL to
indicate that no dump is in progress and release the mutex:
nlk->cb = NULL;
mutex_unlock(nlk->cb_mutex);
When Y grabs cb_mutex afterward, it will see that nlk->cb is NULL and
return -EINVAL as quoted above. netlink_recv() stuffs -EINVAL in sk_err,
but that error is not reported immediately; instead, it is saved for the
next read from the socket. Since Open vSwitch maintains a pool of Netlink
sockets, that next failure can crop up pretty much anywhere. One of the
worst places for it to crop up is in the execution of a later transaction
(e.g. in nl_sock_transact_multiple__()), because userspace treats Netlink
transactions as idempotent and will re-execute them when socket errors
occur. For a transaction that sends a packet, this causes packet
duplication, which we actually observed in practice. (ENOBUFS should
actually cause transactions to be re-executed in many cases, but EINVAL
should not; this is a separate bug in the userspace netlink code.)
VMware-BZ: #1283188
Reported-and-tested-by: Alex Wang <alexw@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Alex Wang <alexw@nicira.com>
2014-07-10 16:48:16 -07:00
|
|
|
|
ovs_mutex_init(&dump->mutex);
|
2010-12-10 09:51:03 -08:00
|
|
|
|
}
|
|
|
|
|
|
2014-02-27 14:13:05 -08:00
|
|
|
|
/* Attempts to retrieve another reply from 'dump' into 'buffer'. 'dump' must
|
|
|
|
|
* have been initialized with nl_dump_start(), and 'buffer' must have been
|
|
|
|
|
* initialized. 'buffer' should be at least NL_DUMP_BUFSIZE bytes long.
|
2010-12-10 09:51:03 -08:00
|
|
|
|
*
|
2014-07-14 13:40:18 -07:00
|
|
|
|
* If successful, returns true and points 'reply->data' and
|
|
|
|
|
* 'ofpbuf_size(reply)' to the message that was retrieved. The caller must not
|
|
|
|
|
* modify 'reply' (because it points within 'buffer', which will be used by
|
|
|
|
|
* future calls to this function).
|
|
|
|
|
*
|
|
|
|
|
* On failure, returns false and sets 'reply->data' to NULL and
|
|
|
|
|
* 'ofpbuf_size(reply)' to 0. Failure might indicate an actual error or merely
|
|
|
|
|
* the end of replies. An error status for the entire dump operation is
|
|
|
|
|
* provided when it is completed by calling nl_dump_done().
|
2014-02-27 14:13:06 -08:00
|
|
|
|
*
|
|
|
|
|
* Multiple threads may call this function, passing the same nl_dump, however
|
|
|
|
|
* each must provide independent buffers. This function may cache multiple
|
|
|
|
|
* replies in the buffer, and these will be processed before more replies are
|
|
|
|
|
* fetched. When this function returns false, other threads may continue to
|
|
|
|
|
* process replies in their buffers, but they will not fetch more replies.
|
2010-12-10 09:51:03 -08:00
|
|
|
|
*/
|
|
|
|
|
bool
|
2014-02-27 14:13:05 -08:00
|
|
|
|
nl_dump_next(struct nl_dump *dump, struct ofpbuf *reply, struct ofpbuf *buffer)
|
2010-12-10 09:51:03 -08:00
|
|
|
|
{
|
|
|
|
|
struct nlmsghdr *nlmsghdr;
|
2014-02-27 14:13:06 -08:00
|
|
|
|
int error = 0;
|
2010-12-10 09:51:03 -08:00
|
|
|
|
|
2014-03-30 01:31:50 -07:00
|
|
|
|
ofpbuf_set_data(reply, NULL);
|
|
|
|
|
ofpbuf_set_size(reply, 0);
|
2010-12-10 09:51:03 -08:00
|
|
|
|
|
2014-02-27 14:13:06 -08:00
|
|
|
|
/* If 'buffer' is empty, fetch another batch of nlmsgs. */
|
2014-03-30 01:31:50 -07:00
|
|
|
|
while (!ofpbuf_size(buffer)) {
|
2014-02-27 14:13:06 -08:00
|
|
|
|
unsigned int status;
|
|
|
|
|
int retval, seq;
|
|
|
|
|
|
|
|
|
|
seq = seq_read(dump->status_seq);
|
|
|
|
|
atomic_read(&dump->status, &status);
|
|
|
|
|
if (status) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
netlink-socket: Work around kernel Netlink dump thread races.
The Linux kernel Netlink implementation has two races that cause problems
for processes that attempt to dump a table in a multithreaded manner.
The first race is in the structure of the kernel netlink_recv() function.
This function pulls a message from the socket queue and, if there is none,
reports EAGAIN:
skb = skb_recv_datagram(sk, flags, noblock, &err);
if (skb == NULL)
goto out;
Only if a message is successfully read from the socket queue does the
function, toward the end, try to queue up a new message to be dumped:
if (nlk->cb && atomic_read(&sk->sk_rmem_alloc) <= sk->sk_rcvbuf / 2) {
ret = netlink_dump(sk);
if (ret) {
sk->sk_err = ret;
sk->sk_error_report(sk);
}
}
This means that if thread A reads a message from a dump, then thread B
attempts to read one before A queues up the next, B will get EAGAIN. This
means that, following EAGAIN, B needs to wait until A returns to userspace
before it tries to read the socket again. nl_dump_next() already does
this, using 'dump->status_seq' (although the need for it has never been
explained clearly, to my knowledge).
The second race is more serious. Suppose thread X and thread Y both
simultaneously attempt to queue up a new message to be dumped, using the
call to netlink_dump() quoted above. netlink_dump() begins with:
mutex_lock(nlk->cb_mutex);
cb = nlk->cb;
if (cb == NULL) {
err = -EINVAL;
goto errout_skb;
}
Suppose that X gets cb_mutex first and finds that the dump is complete. It
will therefore, toward the end of netlink_dump(), clear nlk->cb to NULL to
indicate that no dump is in progress and release the mutex:
nlk->cb = NULL;
mutex_unlock(nlk->cb_mutex);
When Y grabs cb_mutex afterward, it will see that nlk->cb is NULL and
return -EINVAL as quoted above. netlink_recv() stuffs -EINVAL in sk_err,
but that error is not reported immediately; instead, it is saved for the
next read from the socket. Since Open vSwitch maintains a pool of Netlink
sockets, that next failure can crop up pretty much anywhere. One of the
worst places for it to crop up is in the execution of a later transaction
(e.g. in nl_sock_transact_multiple__()), because userspace treats Netlink
transactions as idempotent and will re-execute them when socket errors
occur. For a transaction that sends a packet, this causes packet
duplication, which we actually observed in practice. (ENOBUFS should
actually cause transactions to be re-executed in many cases, but EINVAL
should not; this is a separate bug in the userspace netlink code.)
VMware-BZ: #1283188
Reported-and-tested-by: Alex Wang <alexw@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Alex Wang <alexw@nicira.com>
2014-07-10 16:48:16 -07:00
|
|
|
|
/* Take the mutex here to avoid an in-kernel race. If two threads try
|
|
|
|
|
* to read from a Netlink dump socket at once, then the socket error
|
|
|
|
|
* can be set to EINVAL, which will be encountered on the next recv on
|
|
|
|
|
* that socket, which could be anywhere due to the way that we pool
|
|
|
|
|
* Netlink sockets. Serializing the recv calls avoids the issue. */
|
|
|
|
|
ovs_mutex_lock(&dump->mutex);
|
2014-02-27 14:13:06 -08:00
|
|
|
|
retval = nl_sock_recv__(dump->sock, buffer, false);
|
netlink-socket: Work around kernel Netlink dump thread races.
The Linux kernel Netlink implementation has two races that cause problems
for processes that attempt to dump a table in a multithreaded manner.
The first race is in the structure of the kernel netlink_recv() function.
This function pulls a message from the socket queue and, if there is none,
reports EAGAIN:
skb = skb_recv_datagram(sk, flags, noblock, &err);
if (skb == NULL)
goto out;
Only if a message is successfully read from the socket queue does the
function, toward the end, try to queue up a new message to be dumped:
if (nlk->cb && atomic_read(&sk->sk_rmem_alloc) <= sk->sk_rcvbuf / 2) {
ret = netlink_dump(sk);
if (ret) {
sk->sk_err = ret;
sk->sk_error_report(sk);
}
}
This means that if thread A reads a message from a dump, then thread B
attempts to read one before A queues up the next, B will get EAGAIN. This
means that, following EAGAIN, B needs to wait until A returns to userspace
before it tries to read the socket again. nl_dump_next() already does
this, using 'dump->status_seq' (although the need for it has never been
explained clearly, to my knowledge).
The second race is more serious. Suppose thread X and thread Y both
simultaneously attempt to queue up a new message to be dumped, using the
call to netlink_dump() quoted above. netlink_dump() begins with:
mutex_lock(nlk->cb_mutex);
cb = nlk->cb;
if (cb == NULL) {
err = -EINVAL;
goto errout_skb;
}
Suppose that X gets cb_mutex first and finds that the dump is complete. It
will therefore, toward the end of netlink_dump(), clear nlk->cb to NULL to
indicate that no dump is in progress and release the mutex:
nlk->cb = NULL;
mutex_unlock(nlk->cb_mutex);
When Y grabs cb_mutex afterward, it will see that nlk->cb is NULL and
return -EINVAL as quoted above. netlink_recv() stuffs -EINVAL in sk_err,
but that error is not reported immediately; instead, it is saved for the
next read from the socket. Since Open vSwitch maintains a pool of Netlink
sockets, that next failure can crop up pretty much anywhere. One of the
worst places for it to crop up is in the execution of a later transaction
(e.g. in nl_sock_transact_multiple__()), because userspace treats Netlink
transactions as idempotent and will re-execute them when socket errors
occur. For a transaction that sends a packet, this causes packet
duplication, which we actually observed in practice. (ENOBUFS should
actually cause transactions to be re-executed in many cases, but EINVAL
should not; this is a separate bug in the userspace netlink code.)
VMware-BZ: #1283188
Reported-and-tested-by: Alex Wang <alexw@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Alex Wang <alexw@nicira.com>
2014-07-10 16:48:16 -07:00
|
|
|
|
ovs_mutex_unlock(&dump->mutex);
|
|
|
|
|
|
2010-12-10 09:51:03 -08:00
|
|
|
|
if (retval) {
|
2014-02-27 14:13:05 -08:00
|
|
|
|
ofpbuf_clear(buffer);
|
2014-02-27 14:13:06 -08:00
|
|
|
|
if (retval == EAGAIN) {
|
|
|
|
|
nl_sock_wait(dump->sock, POLLIN);
|
|
|
|
|
seq_wait(dump->status_seq, seq);
|
|
|
|
|
poll_block();
|
|
|
|
|
continue;
|
|
|
|
|
} else {
|
|
|
|
|
error = retval;
|
|
|
|
|
goto exit;
|
2010-12-10 09:51:03 -08:00
|
|
|
|
}
|
|
|
|
|
}
|
2014-02-27 14:13:06 -08:00
|
|
|
|
|
|
|
|
|
nlmsghdr = nl_msg_nlmsghdr(buffer);
|
|
|
|
|
if (dump->nl_seq != nlmsghdr->nlmsg_seq) {
|
|
|
|
|
VLOG_DBG_RL(&rl, "ignoring seq %#"PRIx32" != expected %#"PRIx32,
|
|
|
|
|
nlmsghdr->nlmsg_seq, dump->nl_seq);
|
|
|
|
|
ofpbuf_clear(buffer);
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (nl_msg_nlmsgerr(buffer, &retval) && retval) {
|
|
|
|
|
VLOG_INFO_RL(&rl, "netlink dump request error (%s)",
|
|
|
|
|
ovs_strerror(retval));
|
|
|
|
|
error = retval == EAGAIN ? EPROTO : retval;
|
|
|
|
|
ofpbuf_clear(buffer);
|
|
|
|
|
goto exit;
|
|
|
|
|
}
|
2010-12-10 09:51:03 -08:00
|
|
|
|
}
|
|
|
|
|
|
2014-02-27 14:13:06 -08:00
|
|
|
|
/* Fetch the next nlmsg in the current batch. */
|
2014-02-27 14:13:05 -08:00
|
|
|
|
nlmsghdr = nl_msg_next(buffer, reply);
|
2010-12-10 09:51:03 -08:00
|
|
|
|
if (!nlmsghdr) {
|
|
|
|
|
VLOG_WARN_RL(&rl, "netlink dump reply contains message fragment");
|
2014-02-27 14:13:06 -08:00
|
|
|
|
error = EPROTO;
|
2010-12-10 09:51:03 -08:00
|
|
|
|
} else if (nlmsghdr->nlmsg_type == NLMSG_DONE) {
|
2014-02-27 14:13:06 -08:00
|
|
|
|
error = EOF;
|
2010-12-10 09:51:03 -08:00
|
|
|
|
}
|
|
|
|
|
|
2014-02-27 14:13:06 -08:00
|
|
|
|
exit:
|
|
|
|
|
if (error == EOF) {
|
|
|
|
|
unsigned int old;
|
|
|
|
|
atomic_or(&dump->status, 1, &old);
|
|
|
|
|
seq_change(dump->status_seq);
|
|
|
|
|
} else if (error) {
|
|
|
|
|
atomic_store(&dump->status, error << 1);
|
|
|
|
|
seq_change(dump->status_seq);
|
|
|
|
|
}
|
|
|
|
|
return !error;
|
2010-12-10 09:51:03 -08:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Completes Netlink dump operation 'dump', which must have been initialized
|
|
|
|
|
* with nl_dump_start(). Returns 0 if the dump operation was error-free,
|
|
|
|
|
* otherwise a positive errno value describing the problem. */
|
|
|
|
|
int
|
|
|
|
|
nl_dump_done(struct nl_dump *dump)
|
|
|
|
|
{
|
2014-02-27 14:13:06 -08:00
|
|
|
|
int status;
|
2014-02-27 14:13:05 -08:00
|
|
|
|
|
2010-12-10 09:51:03 -08:00
|
|
|
|
/* Drain any remaining messages that the client didn't read. Otherwise the
|
2013-04-29 13:57:50 -07:00
|
|
|
|
* kernel will continue to queue them up and waste buffer space.
|
|
|
|
|
*
|
|
|
|
|
* XXX We could just destroy and discard the socket in this case. */
|
2014-02-27 14:13:06 -08:00
|
|
|
|
atomic_read(&dump->status, &status);
|
|
|
|
|
if (!status) {
|
|
|
|
|
uint64_t tmp_reply_stub[NL_DUMP_BUFSIZE / 8];
|
|
|
|
|
struct ofpbuf reply, buf;
|
|
|
|
|
|
|
|
|
|
ofpbuf_use_stub(&buf, tmp_reply_stub, sizeof tmp_reply_stub);
|
|
|
|
|
while (nl_dump_next(dump, &reply, &buf)) {
|
|
|
|
|
/* Nothing to do. */
|
2010-12-10 09:51:03 -08:00
|
|
|
|
}
|
2014-02-27 14:13:06 -08:00
|
|
|
|
atomic_read(&dump->status, &status);
|
|
|
|
|
ovs_assert(status);
|
|
|
|
|
ofpbuf_uninit(&buf);
|
2010-12-10 09:51:03 -08:00
|
|
|
|
}
|
2013-04-29 13:57:50 -07:00
|
|
|
|
nl_pool_release(dump->sock);
|
2014-02-27 14:13:06 -08:00
|
|
|
|
seq_destroy(dump->status_seq);
|
netlink-socket: Work around kernel Netlink dump thread races.
The Linux kernel Netlink implementation has two races that cause problems
for processes that attempt to dump a table in a multithreaded manner.
The first race is in the structure of the kernel netlink_recv() function.
This function pulls a message from the socket queue and, if there is none,
reports EAGAIN:
skb = skb_recv_datagram(sk, flags, noblock, &err);
if (skb == NULL)
goto out;
Only if a message is successfully read from the socket queue does the
function, toward the end, try to queue up a new message to be dumped:
if (nlk->cb && atomic_read(&sk->sk_rmem_alloc) <= sk->sk_rcvbuf / 2) {
ret = netlink_dump(sk);
if (ret) {
sk->sk_err = ret;
sk->sk_error_report(sk);
}
}
This means that if thread A reads a message from a dump, then thread B
attempts to read one before A queues up the next, B will get EAGAIN. This
means that, following EAGAIN, B needs to wait until A returns to userspace
before it tries to read the socket again. nl_dump_next() already does
this, using 'dump->status_seq' (although the need for it has never been
explained clearly, to my knowledge).
The second race is more serious. Suppose thread X and thread Y both
simultaneously attempt to queue up a new message to be dumped, using the
call to netlink_dump() quoted above. netlink_dump() begins with:
mutex_lock(nlk->cb_mutex);
cb = nlk->cb;
if (cb == NULL) {
err = -EINVAL;
goto errout_skb;
}
Suppose that X gets cb_mutex first and finds that the dump is complete. It
will therefore, toward the end of netlink_dump(), clear nlk->cb to NULL to
indicate that no dump is in progress and release the mutex:
nlk->cb = NULL;
mutex_unlock(nlk->cb_mutex);
When Y grabs cb_mutex afterward, it will see that nlk->cb is NULL and
return -EINVAL as quoted above. netlink_recv() stuffs -EINVAL in sk_err,
but that error is not reported immediately; instead, it is saved for the
next read from the socket. Since Open vSwitch maintains a pool of Netlink
sockets, that next failure can crop up pretty much anywhere. One of the
worst places for it to crop up is in the execution of a later transaction
(e.g. in nl_sock_transact_multiple__()), because userspace treats Netlink
transactions as idempotent and will re-execute them when socket errors
occur. For a transaction that sends a packet, this causes packet
duplication, which we actually observed in practice. (ENOBUFS should
actually cause transactions to be re-executed in many cases, but EINVAL
should not; this is a separate bug in the userspace netlink code.)
VMware-BZ: #1283188
Reported-and-tested-by: Alex Wang <alexw@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Alex Wang <alexw@nicira.com>
2014-07-10 16:48:16 -07:00
|
|
|
|
ovs_mutex_destroy(&dump->mutex);
|
2014-02-27 14:13:06 -08:00
|
|
|
|
return status >> 1;
|
2010-12-10 09:51:03 -08:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Causes poll_block() to wake up when any of the specified 'events' (which is
|
|
|
|
|
* a OR'd combination of POLLIN, POLLOUT, etc.) occur on 'sock'. */
|
|
|
|
|
void
|
|
|
|
|
nl_sock_wait(const struct nl_sock *sock, short int events)
|
|
|
|
|
{
|
|
|
|
|
poll_fd_wait(sock->fd, events);
|
|
|
|
|
}
|
2011-09-16 09:37:16 -07:00
|
|
|
|
|
2011-11-28 09:29:18 -08:00
|
|
|
|
/* Returns the underlying fd for 'sock', for use in "poll()"-like operations
|
|
|
|
|
* that can't use nl_sock_wait().
|
|
|
|
|
*
|
|
|
|
|
* It's a little tricky to use the returned fd correctly, because nl_sock does
|
|
|
|
|
* "copy on write" to allow a single nl_sock to be used for notifications,
|
|
|
|
|
* transactions, and dumps. If 'sock' is used only for notifications and
|
|
|
|
|
* transactions (and never for dump) then the usage is safe. */
|
|
|
|
|
int
|
|
|
|
|
nl_sock_fd(const struct nl_sock *sock)
|
|
|
|
|
{
|
|
|
|
|
return sock->fd;
|
|
|
|
|
}
|
|
|
|
|
|
2011-09-16 09:37:16 -07:00
|
|
|
|
/* Returns the PID associated with this socket. */
|
|
|
|
|
uint32_t
|
|
|
|
|
nl_sock_pid(const struct nl_sock *sock)
|
|
|
|
|
{
|
|
|
|
|
return sock->pid;
|
|
|
|
|
}
|
2010-12-10 09:51:03 -08:00
|
|
|
|
|
|
|
|
|
/* Miscellaneous. */
|
|
|
|
|
|
2011-01-11 11:02:32 -08:00
|
|
|
|
struct genl_family {
|
|
|
|
|
struct hmap_node hmap_node;
|
|
|
|
|
uint16_t id;
|
|
|
|
|
char *name;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static struct hmap genl_families = HMAP_INITIALIZER(&genl_families);
|
|
|
|
|
|
2010-12-10 09:51:03 -08:00
|
|
|
|
static const struct nl_policy family_policy[CTRL_ATTR_MAX + 1] = {
|
|
|
|
|
[CTRL_ATTR_FAMILY_ID] = {.type = NL_A_U16},
|
2011-09-12 18:57:50 -07:00
|
|
|
|
[CTRL_ATTR_MCAST_GROUPS] = {.type = NL_A_NESTED, .optional = true},
|
2010-12-10 09:51:03 -08:00
|
|
|
|
};
|
|
|
|
|
|
2011-01-11 11:02:32 -08:00
|
|
|
|
static struct genl_family *
|
|
|
|
|
find_genl_family_by_id(uint16_t id)
|
|
|
|
|
{
|
|
|
|
|
struct genl_family *family;
|
|
|
|
|
|
|
|
|
|
HMAP_FOR_EACH_IN_BUCKET (family, hmap_node, hash_int(id, 0),
|
|
|
|
|
&genl_families) {
|
|
|
|
|
if (family->id == id) {
|
|
|
|
|
return family;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
define_genl_family(uint16_t id, const char *name)
|
|
|
|
|
{
|
|
|
|
|
struct genl_family *family = find_genl_family_by_id(id);
|
|
|
|
|
|
|
|
|
|
if (family) {
|
|
|
|
|
if (!strcmp(family->name, name)) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
free(family->name);
|
|
|
|
|
} else {
|
|
|
|
|
family = xmalloc(sizeof *family);
|
|
|
|
|
family->id = id;
|
|
|
|
|
hmap_insert(&genl_families, &family->hmap_node, hash_int(id, 0));
|
|
|
|
|
}
|
|
|
|
|
family->name = xstrdup(name);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static const char *
|
|
|
|
|
genl_family_to_name(uint16_t id)
|
|
|
|
|
{
|
|
|
|
|
if (id == GENL_ID_CTRL) {
|
|
|
|
|
return "control";
|
|
|
|
|
} else {
|
|
|
|
|
struct genl_family *family = find_genl_family_by_id(id);
|
|
|
|
|
return family ? family->name : "unknown";
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2011-08-23 13:13:34 -07:00
|
|
|
|
static int
|
2011-09-09 10:21:49 -07:00
|
|
|
|
do_lookup_genl_family(const char *name, struct nlattr **attrs,
|
|
|
|
|
struct ofpbuf **replyp)
|
2010-12-10 09:51:03 -08:00
|
|
|
|
{
|
|
|
|
|
struct nl_sock *sock;
|
|
|
|
|
struct ofpbuf request, *reply;
|
2011-09-09 10:21:49 -07:00
|
|
|
|
int error;
|
2010-12-10 09:51:03 -08:00
|
|
|
|
|
2011-09-09 10:21:49 -07:00
|
|
|
|
*replyp = NULL;
|
|
|
|
|
error = nl_sock_create(NETLINK_GENERIC, &sock);
|
|
|
|
|
if (error) {
|
|
|
|
|
return error;
|
2010-12-10 09:51:03 -08:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ofpbuf_init(&request, 0);
|
|
|
|
|
nl_msg_put_genlmsghdr(&request, 0, GENL_ID_CTRL, NLM_F_REQUEST,
|
|
|
|
|
CTRL_CMD_GETFAMILY, 1);
|
|
|
|
|
nl_msg_put_string(&request, CTRL_ATTR_FAMILY_NAME, name);
|
2011-09-09 10:21:49 -07:00
|
|
|
|
error = nl_sock_transact(sock, &request, &reply);
|
2010-12-10 09:51:03 -08:00
|
|
|
|
ofpbuf_uninit(&request);
|
2011-09-09 10:21:49 -07:00
|
|
|
|
if (error) {
|
2010-12-10 09:51:03 -08:00
|
|
|
|
nl_sock_destroy(sock);
|
2011-09-09 10:21:49 -07:00
|
|
|
|
return error;
|
2010-12-10 09:51:03 -08:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (!nl_policy_parse(reply, NLMSG_HDRLEN + GENL_HDRLEN,
|
2011-09-09 10:21:49 -07:00
|
|
|
|
family_policy, attrs, ARRAY_SIZE(family_policy))
|
|
|
|
|
|| nl_attr_get_u16(attrs[CTRL_ATTR_FAMILY_ID]) == 0) {
|
2010-12-10 09:51:03 -08:00
|
|
|
|
nl_sock_destroy(sock);
|
|
|
|
|
ofpbuf_delete(reply);
|
2011-09-09 10:21:49 -07:00
|
|
|
|
return EPROTO;
|
2010-12-10 09:51:03 -08:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
nl_sock_destroy(sock);
|
2011-09-09 10:21:49 -07:00
|
|
|
|
*replyp = reply;
|
|
|
|
|
return 0;
|
2010-12-10 09:51:03 -08:00
|
|
|
|
}
|
|
|
|
|
|
2011-08-23 13:13:34 -07:00
|
|
|
|
/* Finds the multicast group called 'group_name' in genl family 'family_name'.
|
|
|
|
|
* When successful, writes its result to 'multicast_group' and returns 0.
|
2011-09-12 18:57:50 -07:00
|
|
|
|
* Otherwise, clears 'multicast_group' and returns a positive error code.
|
2013-08-26 23:53:17 -07:00
|
|
|
|
*/
|
2011-08-23 13:13:34 -07:00
|
|
|
|
int
|
|
|
|
|
nl_lookup_genl_mcgroup(const char *family_name, const char *group_name,
|
2013-08-26 23:53:17 -07:00
|
|
|
|
unsigned int *multicast_group)
|
2011-08-23 13:13:34 -07:00
|
|
|
|
{
|
|
|
|
|
struct nlattr *family_attrs[ARRAY_SIZE(family_policy)];
|
2011-10-05 09:36:11 -07:00
|
|
|
|
const struct nlattr *mc;
|
2011-09-09 10:21:49 -07:00
|
|
|
|
struct ofpbuf *reply;
|
2011-08-23 13:13:34 -07:00
|
|
|
|
unsigned int left;
|
2011-09-09 10:21:49 -07:00
|
|
|
|
int error;
|
2011-08-23 13:13:34 -07:00
|
|
|
|
|
|
|
|
|
*multicast_group = 0;
|
2011-09-09 10:21:49 -07:00
|
|
|
|
error = do_lookup_genl_family(family_name, family_attrs, &reply);
|
|
|
|
|
if (error) {
|
|
|
|
|
return error;
|
2011-08-23 13:13:34 -07:00
|
|
|
|
}
|
|
|
|
|
|
2011-09-12 18:57:50 -07:00
|
|
|
|
if (!family_attrs[CTRL_ATTR_MCAST_GROUPS]) {
|
2013-08-26 23:53:17 -07:00
|
|
|
|
error = EPROTO;
|
2011-09-12 18:57:50 -07:00
|
|
|
|
goto exit;
|
|
|
|
|
}
|
|
|
|
|
|
2011-10-05 09:36:11 -07:00
|
|
|
|
NL_NESTED_FOR_EACH (mc, left, family_attrs[CTRL_ATTR_MCAST_GROUPS]) {
|
2011-08-23 13:13:34 -07:00
|
|
|
|
static const struct nl_policy mc_policy[] = {
|
|
|
|
|
[CTRL_ATTR_MCAST_GRP_ID] = {.type = NL_A_U32},
|
|
|
|
|
[CTRL_ATTR_MCAST_GRP_NAME] = {.type = NL_A_STRING},
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct nlattr *mc_attrs[ARRAY_SIZE(mc_policy)];
|
|
|
|
|
const char *mc_name;
|
|
|
|
|
|
|
|
|
|
if (!nl_parse_nested(mc, mc_policy, mc_attrs, ARRAY_SIZE(mc_policy))) {
|
2011-09-09 10:21:49 -07:00
|
|
|
|
error = EPROTO;
|
|
|
|
|
goto exit;
|
2011-08-23 13:13:34 -07:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
mc_name = nl_attr_get_string(mc_attrs[CTRL_ATTR_MCAST_GRP_NAME]);
|
|
|
|
|
if (!strcmp(group_name, mc_name)) {
|
|
|
|
|
*multicast_group =
|
|
|
|
|
nl_attr_get_u32(mc_attrs[CTRL_ATTR_MCAST_GRP_ID]);
|
2011-09-09 10:21:49 -07:00
|
|
|
|
error = 0;
|
|
|
|
|
goto exit;
|
2011-08-23 13:13:34 -07:00
|
|
|
|
}
|
|
|
|
|
}
|
2011-09-09 10:21:49 -07:00
|
|
|
|
error = EPROTO;
|
2011-08-23 13:13:34 -07:00
|
|
|
|
|
2011-09-09 10:21:49 -07:00
|
|
|
|
exit:
|
|
|
|
|
ofpbuf_delete(reply);
|
|
|
|
|
return error;
|
2011-08-23 13:13:34 -07:00
|
|
|
|
}
|
|
|
|
|
|
2010-12-10 09:51:03 -08:00
|
|
|
|
/* If '*number' is 0, translates the given Generic Netlink family 'name' to a
|
|
|
|
|
* number and stores it in '*number'. If successful, returns 0 and the caller
|
|
|
|
|
* may use '*number' as the family number. On failure, returns a positive
|
|
|
|
|
* errno value and '*number' caches the errno value. */
|
|
|
|
|
int
|
|
|
|
|
nl_lookup_genl_family(const char *name, int *number)
|
|
|
|
|
{
|
|
|
|
|
if (*number == 0) {
|
2011-09-09 10:21:49 -07:00
|
|
|
|
struct nlattr *attrs[ARRAY_SIZE(family_policy)];
|
|
|
|
|
struct ofpbuf *reply;
|
|
|
|
|
int error;
|
|
|
|
|
|
|
|
|
|
error = do_lookup_genl_family(name, attrs, &reply);
|
|
|
|
|
if (!error) {
|
|
|
|
|
*number = nl_attr_get_u16(attrs[CTRL_ATTR_FAMILY_ID]);
|
|
|
|
|
define_genl_family(*number, name);
|
|
|
|
|
} else {
|
|
|
|
|
*number = -error;
|
|
|
|
|
}
|
|
|
|
|
ofpbuf_delete(reply);
|
|
|
|
|
|
2012-11-06 13:14:55 -08:00
|
|
|
|
ovs_assert(*number != 0);
|
2010-12-10 09:51:03 -08:00
|
|
|
|
}
|
|
|
|
|
return *number > 0 ? 0 : -*number;
|
|
|
|
|
}
|
2013-04-29 13:57:50 -07:00
|
|
|
|
|
|
|
|
|
struct nl_pool {
|
|
|
|
|
struct nl_sock *socks[16];
|
|
|
|
|
int n;
|
|
|
|
|
};
|
|
|
|
|
|
Use "error-checking" mutexes in place of other kinds wherever possible.
We've seen a number of deadlocks in the tree since thread safety was
introduced. So far, all of these are self-deadlocks, that is, a single
thread acquiring a lock and then attempting to re-acquire the same lock
recursively. When this has happened, the process simply hung, and it was
somewhat difficult to find the cause.
POSIX "error-checking" mutexes check for this specific problem (and
others). This commit switches from other types of mutexes to
error-checking mutexes everywhere that we can, that is, everywhere that
we're not using recursive mutexes. This ought to help find problems more
quickly in the future.
There might be performance advantages to other kinds of mutexes in some
cases. However, the existing mutex type choices were just guesses, so I'd
rather go for easy detection of errors until we know that other mutex
types actually perform better in specific cases. Also, I did a quick
microbenchmark of glibc mutex types on my host and found that the
error checking mutexes weren't any slower than the other types, at least
when the mutex is uncontended.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Ethan Jackson <ethan@nicira.com>
2013-08-20 13:40:02 -07:00
|
|
|
|
static struct ovs_mutex pool_mutex = OVS_MUTEX_INITIALIZER;
|
2013-07-30 15:31:48 -07:00
|
|
|
|
static struct nl_pool pools[MAX_LINKS] OVS_GUARDED_BY(pool_mutex);
|
2013-04-29 13:57:50 -07:00
|
|
|
|
|
|
|
|
|
static int
|
|
|
|
|
nl_pool_alloc(int protocol, struct nl_sock **sockp)
|
|
|
|
|
{
|
2013-06-19 11:39:11 -07:00
|
|
|
|
struct nl_sock *sock = NULL;
|
2013-04-29 13:57:50 -07:00
|
|
|
|
struct nl_pool *pool;
|
|
|
|
|
|
|
|
|
|
ovs_assert(protocol >= 0 && protocol < ARRAY_SIZE(pools));
|
|
|
|
|
|
2013-07-30 15:31:48 -07:00
|
|
|
|
ovs_mutex_lock(&pool_mutex);
|
2013-04-29 13:57:50 -07:00
|
|
|
|
pool = &pools[protocol];
|
|
|
|
|
if (pool->n > 0) {
|
2013-06-19 11:39:11 -07:00
|
|
|
|
sock = pool->socks[--pool->n];
|
|
|
|
|
}
|
2013-07-30 15:31:48 -07:00
|
|
|
|
ovs_mutex_unlock(&pool_mutex);
|
2013-06-19 11:39:11 -07:00
|
|
|
|
|
|
|
|
|
if (sock) {
|
|
|
|
|
*sockp = sock;
|
2013-04-29 13:57:50 -07:00
|
|
|
|
return 0;
|
|
|
|
|
} else {
|
|
|
|
|
return nl_sock_create(protocol, sockp);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
nl_pool_release(struct nl_sock *sock)
|
|
|
|
|
{
|
|
|
|
|
if (sock) {
|
|
|
|
|
struct nl_pool *pool = &pools[sock->protocol];
|
|
|
|
|
|
2013-07-30 15:31:48 -07:00
|
|
|
|
ovs_mutex_lock(&pool_mutex);
|
2013-04-29 13:57:50 -07:00
|
|
|
|
if (pool->n < ARRAY_SIZE(pool->socks)) {
|
|
|
|
|
pool->socks[pool->n++] = sock;
|
2013-06-19 11:39:11 -07:00
|
|
|
|
sock = NULL;
|
2013-04-29 13:57:50 -07:00
|
|
|
|
}
|
2013-07-30 15:31:48 -07:00
|
|
|
|
ovs_mutex_unlock(&pool_mutex);
|
2013-06-19 11:39:11 -07:00
|
|
|
|
|
|
|
|
|
nl_sock_destroy(sock);
|
2013-04-29 13:57:50 -07:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int
|
|
|
|
|
nl_transact(int protocol, const struct ofpbuf *request,
|
|
|
|
|
struct ofpbuf **replyp)
|
|
|
|
|
{
|
|
|
|
|
struct nl_sock *sock;
|
|
|
|
|
int error;
|
|
|
|
|
|
|
|
|
|
error = nl_pool_alloc(protocol, &sock);
|
|
|
|
|
if (error) {
|
|
|
|
|
*replyp = NULL;
|
|
|
|
|
return error;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
error = nl_sock_transact(sock, request, replyp);
|
|
|
|
|
|
|
|
|
|
nl_pool_release(sock);
|
|
|
|
|
return error;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
|
nl_transact_multiple(int protocol,
|
|
|
|
|
struct nl_transaction **transactions, size_t n)
|
|
|
|
|
{
|
|
|
|
|
struct nl_sock *sock;
|
|
|
|
|
int error;
|
|
|
|
|
|
|
|
|
|
error = nl_pool_alloc(protocol, &sock);
|
|
|
|
|
if (!error) {
|
|
|
|
|
nl_sock_transact_multiple(sock, transactions, n);
|
|
|
|
|
nl_pool_release(sock);
|
|
|
|
|
} else {
|
|
|
|
|
nl_sock_record_errors__(transactions, n, error);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2010-12-10 09:51:03 -08:00
|
|
|
|
|
netlink: Postpone choosing sequence numbers until send time.
Choosing sequence numbers at time of creating a packet means that
nl_sock_transact_multiple() has to search for the sequence number
of a reply, because the sequence numbers of the requests aren't
necessarily sequential. This commit makes it possible to avoid
the search, by deferring choice of sequence numbers until the
time that we send the packets. It doesn't actually modify
nl_sock_transact_multiple(), which will happen in a later commit.
Previously, I was concerned about a theoretical race condition
described in a comment in the old versino of this code:
This implementation uses sequence numbers that are unique
process-wide, to avoid a hypothetical race: send request, close
socket, open new socket that reuses the old socket's PID value,
send request on new socket, receive reply from kernel to old
socket but with same PID and sequence number. (This race could be
avoided other ways, e.g. by preventing PIDs from being quickly
reused).
However, I no longer believe that this can be a real problem,
because Netlink operates synchronously. The reply to a request
will always arrive before the socket can be closed and a new
socket opened with the old socket's PID.
Signed-off-by: Ben Pfaff <blp@nicira.com>
2012-04-16 16:01:01 -07:00
|
|
|
|
static uint32_t
|
|
|
|
|
nl_sock_allocate_seq(struct nl_sock *sock, unsigned int n)
|
|
|
|
|
{
|
|
|
|
|
uint32_t seq = sock->next_seq;
|
|
|
|
|
|
|
|
|
|
sock->next_seq += n;
|
|
|
|
|
|
|
|
|
|
/* Make it impossible for the next request for sequence numbers to wrap
|
|
|
|
|
* around to 0. Start over with 1 to avoid ever using a sequence number of
|
|
|
|
|
* 0, because the kernel uses sequence number 0 for notifications. */
|
|
|
|
|
if (sock->next_seq >= UINT32_MAX / 2) {
|
|
|
|
|
sock->next_seq = 1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return seq;
|
|
|
|
|
}
|
|
|
|
|
|
2010-12-10 09:51:03 -08:00
|
|
|
|
static void
|
2011-01-11 11:02:32 -08:00
|
|
|
|
nlmsghdr_to_string(const struct nlmsghdr *h, int protocol, struct ds *ds)
|
2010-12-10 09:51:03 -08:00
|
|
|
|
{
|
|
|
|
|
struct nlmsg_flag {
|
|
|
|
|
unsigned int bits;
|
|
|
|
|
const char *name;
|
|
|
|
|
};
|
|
|
|
|
static const struct nlmsg_flag flags[] = {
|
|
|
|
|
{ NLM_F_REQUEST, "REQUEST" },
|
|
|
|
|
{ NLM_F_MULTI, "MULTI" },
|
|
|
|
|
{ NLM_F_ACK, "ACK" },
|
|
|
|
|
{ NLM_F_ECHO, "ECHO" },
|
|
|
|
|
{ NLM_F_DUMP, "DUMP" },
|
|
|
|
|
{ NLM_F_ROOT, "ROOT" },
|
|
|
|
|
{ NLM_F_MATCH, "MATCH" },
|
|
|
|
|
{ NLM_F_ATOMIC, "ATOMIC" },
|
|
|
|
|
};
|
|
|
|
|
const struct nlmsg_flag *flag;
|
|
|
|
|
uint16_t flags_left;
|
|
|
|
|
|
|
|
|
|
ds_put_format(ds, "nl(len:%"PRIu32", type=%"PRIu16,
|
|
|
|
|
h->nlmsg_len, h->nlmsg_type);
|
|
|
|
|
if (h->nlmsg_type == NLMSG_NOOP) {
|
|
|
|
|
ds_put_cstr(ds, "(no-op)");
|
|
|
|
|
} else if (h->nlmsg_type == NLMSG_ERROR) {
|
|
|
|
|
ds_put_cstr(ds, "(error)");
|
|
|
|
|
} else if (h->nlmsg_type == NLMSG_DONE) {
|
|
|
|
|
ds_put_cstr(ds, "(done)");
|
|
|
|
|
} else if (h->nlmsg_type == NLMSG_OVERRUN) {
|
|
|
|
|
ds_put_cstr(ds, "(overrun)");
|
|
|
|
|
} else if (h->nlmsg_type < NLMSG_MIN_TYPE) {
|
|
|
|
|
ds_put_cstr(ds, "(reserved)");
|
2011-01-11 11:02:32 -08:00
|
|
|
|
} else if (protocol == NETLINK_GENERIC) {
|
|
|
|
|
ds_put_format(ds, "(%s)", genl_family_to_name(h->nlmsg_type));
|
2010-12-10 09:51:03 -08:00
|
|
|
|
} else {
|
|
|
|
|
ds_put_cstr(ds, "(family-defined)");
|
|
|
|
|
}
|
|
|
|
|
ds_put_format(ds, ", flags=%"PRIx16, h->nlmsg_flags);
|
|
|
|
|
flags_left = h->nlmsg_flags;
|
|
|
|
|
for (flag = flags; flag < &flags[ARRAY_SIZE(flags)]; flag++) {
|
|
|
|
|
if ((flags_left & flag->bits) == flag->bits) {
|
|
|
|
|
ds_put_format(ds, "[%s]", flag->name);
|
|
|
|
|
flags_left &= ~flag->bits;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
if (flags_left) {
|
|
|
|
|
ds_put_format(ds, "[OTHER:%"PRIx16"]", flags_left);
|
|
|
|
|
}
|
2011-11-14 10:10:58 -08:00
|
|
|
|
ds_put_format(ds, ", seq=%"PRIx32", pid=%"PRIu32,
|
|
|
|
|
h->nlmsg_seq, h->nlmsg_pid);
|
2010-12-10 09:51:03 -08:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static char *
|
2011-01-18 14:07:52 -08:00
|
|
|
|
nlmsg_to_string(const struct ofpbuf *buffer, int protocol)
|
2010-12-10 09:51:03 -08:00
|
|
|
|
{
|
|
|
|
|
struct ds ds = DS_EMPTY_INITIALIZER;
|
|
|
|
|
const struct nlmsghdr *h = ofpbuf_at(buffer, 0, NLMSG_HDRLEN);
|
|
|
|
|
if (h) {
|
2011-01-11 11:02:32 -08:00
|
|
|
|
nlmsghdr_to_string(h, protocol, &ds);
|
2010-12-10 09:51:03 -08:00
|
|
|
|
if (h->nlmsg_type == NLMSG_ERROR) {
|
|
|
|
|
const struct nlmsgerr *e;
|
|
|
|
|
e = ofpbuf_at(buffer, NLMSG_HDRLEN,
|
|
|
|
|
NLMSG_ALIGN(sizeof(struct nlmsgerr)));
|
|
|
|
|
if (e) {
|
|
|
|
|
ds_put_format(&ds, " error(%d", e->error);
|
|
|
|
|
if (e->error < 0) {
|
2013-06-24 10:54:49 -07:00
|
|
|
|
ds_put_format(&ds, "(%s)", ovs_strerror(-e->error));
|
2010-12-10 09:51:03 -08:00
|
|
|
|
}
|
|
|
|
|
ds_put_cstr(&ds, ", in-reply-to(");
|
2011-01-11 11:02:32 -08:00
|
|
|
|
nlmsghdr_to_string(&e->msg, protocol, &ds);
|
2010-12-10 09:51:03 -08:00
|
|
|
|
ds_put_cstr(&ds, "))");
|
|
|
|
|
} else {
|
|
|
|
|
ds_put_cstr(&ds, " error(truncated)");
|
|
|
|
|
}
|
|
|
|
|
} else if (h->nlmsg_type == NLMSG_DONE) {
|
|
|
|
|
int *error = ofpbuf_at(buffer, NLMSG_HDRLEN, sizeof *error);
|
|
|
|
|
if (error) {
|
|
|
|
|
ds_put_format(&ds, " done(%d", *error);
|
|
|
|
|
if (*error < 0) {
|
2013-06-24 10:54:49 -07:00
|
|
|
|
ds_put_format(&ds, "(%s)", ovs_strerror(-*error));
|
2010-12-10 09:51:03 -08:00
|
|
|
|
}
|
|
|
|
|
ds_put_cstr(&ds, ")");
|
|
|
|
|
} else {
|
|
|
|
|
ds_put_cstr(&ds, " done(truncated)");
|
|
|
|
|
}
|
2011-01-18 14:07:52 -08:00
|
|
|
|
} else if (protocol == NETLINK_GENERIC) {
|
|
|
|
|
struct genlmsghdr *genl = nl_msg_genlmsghdr(buffer);
|
|
|
|
|
if (genl) {
|
|
|
|
|
ds_put_format(&ds, ",genl(cmd=%"PRIu8",version=%"PRIu8")",
|
|
|
|
|
genl->cmd, genl->version);
|
|
|
|
|
}
|
2010-12-10 09:51:03 -08:00
|
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
ds_put_cstr(&ds, "nl(truncated)");
|
|
|
|
|
}
|
|
|
|
|
return ds.string;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
log_nlmsg(const char *function, int error,
|
2011-01-18 14:07:52 -08:00
|
|
|
|
const void *message, size_t size, int protocol)
|
2010-12-10 09:51:03 -08:00
|
|
|
|
{
|
|
|
|
|
struct ofpbuf buffer;
|
|
|
|
|
char *nlmsg;
|
|
|
|
|
|
|
|
|
|
if (!VLOG_IS_DBG_ENABLED()) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ofpbuf_use_const(&buffer, message, size);
|
2011-01-18 14:07:52 -08:00
|
|
|
|
nlmsg = nlmsg_to_string(&buffer, protocol);
|
2013-06-24 10:54:49 -07:00
|
|
|
|
VLOG_DBG_RL(&rl, "%s (%s): %s", function, ovs_strerror(error), nlmsg);
|
2010-12-10 09:51:03 -08:00
|
|
|
|
free(nlmsg);
|
|
|
|
|
}
|