* [PATCH bpf-next 2/6] bpf: Sync bpf.h to tools/
From: Andrey Ignatov @ 2018-07-12 0:33 UTC (permalink / raw)
To: netdev; +Cc: Andrey Ignatov, ast, daniel, brakmo, kernel-team
In-Reply-To: <cover.1531355394.git.rdna@fb.com>
Sync BPF_SOCK_OPS_TCP_LISTEN_CB related UAPI changes to tools/.
Signed-off-by: Andrey Ignatov <rdna@fb.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
---
tools/include/uapi/linux/bpf.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
index 59b19b6a40d7..3b0ab93bc94f 100644
--- a/tools/include/uapi/linux/bpf.h
+++ b/tools/include/uapi/linux/bpf.h
@@ -2555,6 +2555,9 @@ enum {
* Arg1: old_state
* Arg2: new_state
*/
+ BPF_SOCK_OPS_TCP_LISTEN_CB, /* Called on listen(2), right after
+ * socket transition to LISTEN state.
+ */
};
/* List of TCP states. There is a build check in net/ipv4/tcp.c to detect
--
2.17.1
^ permalink raw reply related
* [PATCH bpf-next 4/6] selftests/bpf: Switch test_tcpbpf_user to cgroup_helpers
From: Andrey Ignatov @ 2018-07-12 0:33 UTC (permalink / raw)
To: netdev; +Cc: Andrey Ignatov, ast, daniel, brakmo, kernel-team
In-Reply-To: <cover.1531355394.git.rdna@fb.com>
Switch to cgroup_helpers to simplify the code and fix cgroup cleanup:
before cgroup was not cleaned up after the test.
It also removes SYSTEM macro, that only printed error, but didn't
terminate the test.
Signed-off-by: Andrey Ignatov <rdna@fb.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
---
tools/testing/selftests/bpf/Makefile | 1 +
.../testing/selftests/bpf/test_tcpbpf_user.c | 55 +++++++------------
2 files changed, 22 insertions(+), 34 deletions(-)
diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile
index 7a6214e9ae58..478bf1bcbbf5 100644
--- a/tools/testing/selftests/bpf/Makefile
+++ b/tools/testing/selftests/bpf/Makefile
@@ -61,6 +61,7 @@ $(OUTPUT)/test_dev_cgroup: cgroup_helpers.c
$(OUTPUT)/test_sock: cgroup_helpers.c
$(OUTPUT)/test_sock_addr: cgroup_helpers.c
$(OUTPUT)/test_sockmap: cgroup_helpers.c
+$(OUTPUT)/test_tcpbpf_user: cgroup_helpers.c
$(OUTPUT)/test_progs: trace_helpers.c
$(OUTPUT)/get_cgroup_id_user: cgroup_helpers.c
diff --git a/tools/testing/selftests/bpf/test_tcpbpf_user.c b/tools/testing/selftests/bpf/test_tcpbpf_user.c
index 84ab5163c828..fa97ec6428de 100644
--- a/tools/testing/selftests/bpf/test_tcpbpf_user.c
+++ b/tools/testing/selftests/bpf/test_tcpbpf_user.c
@@ -1,25 +1,18 @@
// SPDX-License-Identifier: GPL-2.0
#include <stdio.h>
#include <stdlib.h>
-#include <stdio.h>
#include <unistd.h>
#include <errno.h>
-#include <signal.h>
#include <string.h>
-#include <assert.h>
-#include <linux/perf_event.h>
-#include <linux/ptrace.h>
#include <linux/bpf.h>
-#include <sys/ioctl.h>
-#include <sys/time.h>
#include <sys/types.h>
-#include <sys/stat.h>
-#include <fcntl.h>
#include <bpf/bpf.h>
#include <bpf/libbpf.h>
-#include "bpf_util.h"
+
#include "bpf_rlimit.h"
-#include <linux/perf_event.h>
+#include "bpf_util.h"
+#include "cgroup_helpers.h"
+
#include "test_tcpbpf.h"
static int bpf_find_map(const char *test, struct bpf_object *obj,
@@ -35,42 +28,32 @@ static int bpf_find_map(const char *test, struct bpf_object *obj,
return bpf_map__fd(map);
}
-#define SYSTEM(CMD) \
- do { \
- if (system(CMD)) { \
- printf("system(%s) FAILS!\n", CMD); \
- } \
- } while (0)
-
int main(int argc, char **argv)
{
const char *file = "test_tcpbpf_kern.o";
struct tcpbpf_globals g = {0};
- int cg_fd, prog_fd, map_fd;
+ const char *cg_path = "/foo";
bool debug_flag = false;
int error = EXIT_FAILURE;
struct bpf_object *obj;
- char cmd[100], *dir;
- struct stat buffer;
+ int prog_fd, map_fd;
+ int cg_fd = -1;
__u32 key = 0;
- int pid;
int rv;
if (argc > 1 && strcmp(argv[1], "-d") == 0)
debug_flag = true;
- dir = "/tmp/cgroupv2/foo";
+ if (setup_cgroup_environment())
+ goto err;
+
+ cg_fd = create_and_get_cgroup(cg_path);
+ if (!cg_fd)
+ goto err;
- if (stat(dir, &buffer) != 0) {
- SYSTEM("mkdir -p /tmp/cgroupv2");
- SYSTEM("mount -t cgroup2 none /tmp/cgroupv2");
- SYSTEM("mkdir -p /tmp/cgroupv2/foo");
- }
- pid = (int) getpid();
- sprintf(cmd, "echo %d >> /tmp/cgroupv2/foo/cgroup.procs", pid);
- SYSTEM(cmd);
+ if (join_cgroup(cg_path))
+ goto err;
- cg_fd = open(dir, O_DIRECTORY, O_RDONLY);
if (bpf_prog_load(file, BPF_PROG_TYPE_SOCK_OPS, &obj, &prog_fd)) {
printf("FAILED: load_bpf_file failed for: %s\n", file);
goto err;
@@ -83,7 +66,10 @@ int main(int argc, char **argv)
goto err;
}
- SYSTEM("./tcp_server.py");
+ if (system("./tcp_server.py")) {
+ printf("FAILED: TCP server\n");
+ goto err;
+ }
map_fd = bpf_find_map(__func__, obj, "global_map");
if (map_fd < 0)
@@ -123,6 +109,7 @@ int main(int argc, char **argv)
error = 0;
err:
bpf_prog_detach(cg_fd, BPF_CGROUP_SOCK_OPS);
+ close(cg_fd);
+ cleanup_cgroup_environment();
return error;
-
}
--
2.17.1
^ permalink raw reply related
* [PATCH bpf-next 3/6] selftests/bpf: Fix const'ness in cgroup_helpers
From: Andrey Ignatov @ 2018-07-12 0:33 UTC (permalink / raw)
To: netdev; +Cc: Andrey Ignatov, ast, daniel, brakmo, kernel-team
In-Reply-To: <cover.1531355394.git.rdna@fb.com>
Lack of const in cgroup helpers signatures forces to write ugly client
code. Fix it.
Signed-off-by: Andrey Ignatov <rdna@fb.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
---
tools/testing/selftests/bpf/cgroup_helpers.c | 6 +++---
tools/testing/selftests/bpf/cgroup_helpers.h | 6 +++---
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/tools/testing/selftests/bpf/cgroup_helpers.c b/tools/testing/selftests/bpf/cgroup_helpers.c
index c87b4e052ce9..cf16948aad4a 100644
--- a/tools/testing/selftests/bpf/cgroup_helpers.c
+++ b/tools/testing/selftests/bpf/cgroup_helpers.c
@@ -118,7 +118,7 @@ static int join_cgroup_from_top(char *cgroup_path)
*
* On success, it returns 0, otherwise on failure it returns 1.
*/
-int join_cgroup(char *path)
+int join_cgroup(const char *path)
{
char cgroup_path[PATH_MAX + 1];
@@ -158,7 +158,7 @@ void cleanup_cgroup_environment(void)
* On success, it returns the file descriptor. On failure it returns 0.
* If there is a failure, it prints the error to stderr.
*/
-int create_and_get_cgroup(char *path)
+int create_and_get_cgroup(const char *path)
{
char cgroup_path[PATH_MAX + 1];
int fd;
@@ -186,7 +186,7 @@ int create_and_get_cgroup(char *path)
* which is an invalid cgroup id.
* If there is a failure, it prints the error to stderr.
*/
-unsigned long long get_cgroup_id(char *path)
+unsigned long long get_cgroup_id(const char *path)
{
int dirfd, err, flags, mount_id, fhsize;
union {
diff --git a/tools/testing/selftests/bpf/cgroup_helpers.h b/tools/testing/selftests/bpf/cgroup_helpers.h
index 20a4a5dcd469..d64bb8957090 100644
--- a/tools/testing/selftests/bpf/cgroup_helpers.h
+++ b/tools/testing/selftests/bpf/cgroup_helpers.h
@@ -9,10 +9,10 @@
__FILE__, __LINE__, clean_errno(), ##__VA_ARGS__)
-int create_and_get_cgroup(char *path);
-int join_cgroup(char *path);
+int create_and_get_cgroup(const char *path);
+int join_cgroup(const char *path);
int setup_cgroup_environment(void);
void cleanup_cgroup_environment(void);
-unsigned long long get_cgroup_id(char *path);
+unsigned long long get_cgroup_id(const char *path);
#endif
--
2.17.1
^ permalink raw reply related
* [PATCH bpf-next 6/6] selftests/bpf: Test case for BPF_SOCK_OPS_TCP_LISTEN_CB
From: Andrey Ignatov @ 2018-07-12 0:33 UTC (permalink / raw)
To: netdev; +Cc: Andrey Ignatov, ast, daniel, brakmo, kernel-team
In-Reply-To: <cover.1531355394.git.rdna@fb.com>
Cover new TCP-BPF callback in test_tcpbpf: when listen() is called on
socket, set BPF_SOCK_OPS_STATE_CB_FLAG so that BPF_SOCK_OPS_STATE_CB
callback can be called on future state transition, and when such a
transition happens (TCP_LISTEN -> TCP_CLOSE), track it in the map and
verify it in user space later.
Signed-off-by: Andrey Ignatov <rdna@fb.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
---
tools/testing/selftests/bpf/test_tcpbpf.h | 1 +
tools/testing/selftests/bpf/test_tcpbpf_kern.c | 17 ++++++++++++-----
tools/testing/selftests/bpf/test_tcpbpf_user.c | 4 +++-
3 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/tools/testing/selftests/bpf/test_tcpbpf.h b/tools/testing/selftests/bpf/test_tcpbpf.h
index 2fe43289943c..7bcfa6207005 100644
--- a/tools/testing/selftests/bpf/test_tcpbpf.h
+++ b/tools/testing/selftests/bpf/test_tcpbpf.h
@@ -12,5 +12,6 @@ struct tcpbpf_globals {
__u32 good_cb_test_rv;
__u64 bytes_received;
__u64 bytes_acked;
+ __u32 num_listen;
};
#endif
diff --git a/tools/testing/selftests/bpf/test_tcpbpf_kern.c b/tools/testing/selftests/bpf/test_tcpbpf_kern.c
index 3e645ee41ed5..4b7fd540cea9 100644
--- a/tools/testing/selftests/bpf/test_tcpbpf_kern.c
+++ b/tools/testing/selftests/bpf/test_tcpbpf_kern.c
@@ -96,15 +96,22 @@ int bpf_testcb(struct bpf_sock_ops *skops)
if (!gp)
break;
g = *gp;
- g.total_retrans = skops->total_retrans;
- g.data_segs_in = skops->data_segs_in;
- g.data_segs_out = skops->data_segs_out;
- g.bytes_received = skops->bytes_received;
- g.bytes_acked = skops->bytes_acked;
+ if (skops->args[0] == BPF_TCP_LISTEN) {
+ g.num_listen++;
+ } else {
+ g.total_retrans = skops->total_retrans;
+ g.data_segs_in = skops->data_segs_in;
+ g.data_segs_out = skops->data_segs_out;
+ g.bytes_received = skops->bytes_received;
+ g.bytes_acked = skops->bytes_acked;
+ }
bpf_map_update_elem(&global_map, &key, &g,
BPF_ANY);
}
break;
+ case BPF_SOCK_OPS_TCP_LISTEN_CB:
+ bpf_sock_ops_cb_flags_set(skops, BPF_SOCK_OPS_STATE_CB_FLAG);
+ break;
default:
rv = -1;
}
diff --git a/tools/testing/selftests/bpf/test_tcpbpf_user.c b/tools/testing/selftests/bpf/test_tcpbpf_user.c
index 971f1644b9c7..a275c2971376 100644
--- a/tools/testing/selftests/bpf/test_tcpbpf_user.c
+++ b/tools/testing/selftests/bpf/test_tcpbpf_user.c
@@ -37,7 +37,8 @@ int verify_result(const struct tcpbpf_globals *result)
(1 << BPF_SOCK_OPS_ACTIVE_ESTABLISHED_CB) |
(1 << BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB) |
(1 << BPF_SOCK_OPS_NEEDS_ECN) |
- (1 << BPF_SOCK_OPS_STATE_CB));
+ (1 << BPF_SOCK_OPS_STATE_CB) |
+ (1 << BPF_SOCK_OPS_TCP_LISTEN_CB));
EXPECT_EQ(expected_events, result->event_map, "#" PRIx32);
EXPECT_EQ(501ULL, result->bytes_received, "llu");
@@ -46,6 +47,7 @@ int verify_result(const struct tcpbpf_globals *result)
EXPECT_EQ(1, result->data_segs_out, PRIu32);
EXPECT_EQ(0x80, result->bad_cb_test_rv, PRIu32);
EXPECT_EQ(0, result->good_cb_test_rv, PRIu32);
+ EXPECT_EQ(1, result->num_listen, PRIu32);
return 0;
err:
--
2.17.1
^ permalink raw reply related
* [PATCH bpf-next 0/6] TCP-BPF callback for listening sockets
From: Andrey Ignatov @ 2018-07-12 0:33 UTC (permalink / raw)
To: netdev; +Cc: Andrey Ignatov, ast, daniel, brakmo, kernel-team
This patchset adds TCP-BPF callback for listening sockets.
Patch 0001 provides more details and is the main patch in the set.
Patch 0006 adds selftest for the new callback.
Other patches are bug fixes and improvements in TCP-BPF selftest to make it
easier to extend in 0006.
Andrey Ignatov (6):
bpf: Add BPF_SOCK_OPS_TCP_LISTEN_CB
bpf: Sync bpf.h to tools/
selftests/bpf: Fix const'ness in cgroup_helpers
selftests/bpf: Switch test_tcpbpf_user to cgroup_helpers
selftests/bpf: Better verification in test_tcpbpf
selftests/bpf: Test case for BPF_SOCK_OPS_TCP_LISTEN_CB
include/uapi/linux/bpf.h | 3 +
net/ipv4/af_inet.c | 1 +
tools/include/uapi/linux/bpf.h | 3 +
tools/testing/selftests/bpf/Makefile | 1 +
tools/testing/selftests/bpf/cgroup_helpers.c | 6 +-
tools/testing/selftests/bpf/cgroup_helpers.h | 6 +-
tools/testing/selftests/bpf/test_tcpbpf.h | 1 +
.../testing/selftests/bpf/test_tcpbpf_kern.c | 17 ++-
.../testing/selftests/bpf/test_tcpbpf_user.c | 119 +++++++++---------
9 files changed, 88 insertions(+), 69 deletions(-)
--
2.17.1
^ permalink raw reply
* [net-next, 1/3] tcp: convert icsk_user_timeout from jiffies to msecs
From: Jon Maxwell @ 2018-07-12 0:36 UTC (permalink / raw)
To: davem
Cc: edumazet, ncardwell, David.Laight, kuznet, yoshfuji, netdev,
linux-kernel, jmaxwell
This is a preparatory commit for an upcoming patch that improves the socket
TCP_USER_TIMEOUT option accuracy. Implement Eric Dumazets idea to convert
icsk->icsk_user_timeout from jiffies to msecs. To eliminate the
msecs_to_jiffies() and jiffies_to_msecs() dance in future.
There will 3 patches in this series. [net-next, 2/3] will create a seperate
helper routine called tcp_retransmit_stamp() as per Neal Cardwells suggestion.
Finally [net-next, 3/3] will implement a new routine called
tcp_clamp_rto_to_user_timeout() to calculate the rto so that TCP_USER_TIMEOUT
is more accurate. As a result of the final patch it won't have the
msecs_to_jiffies() and jiffies_to_msecs() dance that David Laight was concerned
about.
Signed-off-by: Jon Maxwell <jmaxwell37@gmail.com>
---
net/ipv4/tcp.c | 4 ++--
net/ipv4/tcp_timer.c | 8 ++++----
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index e3704a49164b..9d900162f16a 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -2984,7 +2984,7 @@ static int do_tcp_setsockopt(struct sock *sk, int level,
if (val < 0)
err = -EINVAL;
else
- icsk->icsk_user_timeout = msecs_to_jiffies(val);
+ icsk->icsk_user_timeout = val;
break;
case TCP_FASTOPEN:
@@ -3440,7 +3440,7 @@ static int do_tcp_getsockopt(struct sock *sk, int level,
break;
case TCP_USER_TIMEOUT:
- val = jiffies_to_msecs(icsk->icsk_user_timeout);
+ val = icsk->icsk_user_timeout;
break;
case TCP_FASTOPEN:
diff --git a/net/ipv4/tcp_timer.c b/net/ipv4/tcp_timer.c
index 3b3611729928..fa34984d0b12 100644
--- a/net/ipv4/tcp_timer.c
+++ b/net/ipv4/tcp_timer.c
@@ -183,8 +183,9 @@ static bool retransmits_timed_out(struct sock *sk,
else
timeout = ((2 << linear_backoff_thresh) - 1) * rto_base +
(boundary - linear_backoff_thresh) * TCP_RTO_MAX;
+ timeout = jiffies_to_msecs(timeout);
}
- return (tcp_time_stamp(tcp_sk(sk)) - start_ts) >= jiffies_to_msecs(timeout);
+ return (tcp_time_stamp(tcp_sk(sk)) - start_ts) >= timeout;
}
/* A write timeout has occurred. Process the after effects. */
@@ -337,8 +338,7 @@ static void tcp_probe_timer(struct sock *sk)
if (!start_ts)
skb->skb_mstamp = tp->tcp_mstamp;
else if (icsk->icsk_user_timeout &&
- (s32)(tcp_time_stamp(tp) - start_ts) >
- jiffies_to_msecs(icsk->icsk_user_timeout))
+ (s32)(tcp_time_stamp(tp) - start_ts) > icsk->icsk_user_timeout)
goto abort;
max_probes = sock_net(sk)->ipv4.sysctl_tcp_retries2;
@@ -672,7 +672,7 @@ static void tcp_keepalive_timer (struct timer_list *t)
* to determine when to timeout instead.
*/
if ((icsk->icsk_user_timeout != 0 &&
- elapsed >= icsk->icsk_user_timeout &&
+ elapsed >= msecs_to_jiffies(icsk->icsk_user_timeout) &&
icsk->icsk_probes_out > 0) ||
(icsk->icsk_user_timeout == 0 &&
icsk->icsk_probes_out >= keepalive_probes(tp))) {
--
2.13.6
^ permalink raw reply related
* Apply for a 3% loan...
From: Matt Adams @ 2018-07-12 0:19 UTC (permalink / raw)
To: Recipients
Hello, We offer L oans at 3% interest rate per annum. If intereted, contact me with amount needed and L oan duration for more details...
^ permalink raw reply
* Re: [PATCH bpf 0/4] Consistent sendmsg error reporting in AF_XDP
From: Alexei Starovoitov @ 2018-07-11 23:48 UTC (permalink / raw)
To: Magnus Karlsson
Cc: bjorn.topel, ast, daniel, netdev, eric.dumazet, qi.z.zhang, pavel
In-Reply-To: <1531296772-28850-1-git-send-email-magnus.karlsson@intel.com>
On Wed, Jul 11, 2018 at 10:12:48AM +0200, Magnus Karlsson wrote:
> This patch set adjusts the AF_XDP TX error reporting so that it becomes
> consistent between copy mode and zero-copy. First some background:
>
> Copy-mode for TX uses the SKB path in which the action of sending the
> packet is performed from process context using the sendmsg
> syscall. Completions are usually done asynchronously from NAPI mode by
> using a TX interrupt. In this mode, send errors can be returned back
> through the syscall.
>
> In zero-copy mode both the sending of the packet and the completions
> are done asynchronously from NAPI mode for performance reasons. In
> this mode, the sendmsg syscall only makes sure that the TX NAPI loop
> will be run that performs both the actions of sending and
> completing. In this mode it is therefore not possible to return errors
> through the sendmsg syscall as the sending is done from the NAPI
> loop. Note that it is possible to implement a synchronous send with
> our API, but in our benchmarks that made the TX performance drop by
> nearly half due to synchronization requirements and cache line
> bouncing. But for some netdevs this might be preferable so let us
> leave it up to the implementation to decide.
>
> The problem is that the current code base returns some errors in
> copy-mode that are not possible to return in zero-copy mode. This
> patch set aligns them so that the two modes always return the same
> error code. We achieve this by removing some of the errors returned by
> sendmsg in copy-mode (and in one case adding an error message for
> zero-copy mode) and offering alternative error detection methods that
> are consistent between the two modes.
>
> The structure of the patch set is as follows:
>
> Patch 1: removes the ENXIO return code from copy-mode when someone has
> forcefully changed the number of queues on the device so that the
> queue bound to the socket is no longer available. Just silently stop
> sending anything as in zero-copy mode.
>
> Patch 2: stop returning EAGAIN in copy mode when the completion queue
> is full as zero-copy does not do this. Instead this situation can be
> detected by comparing the head and tail pointers of the completion
> queue in both modes. In any case, EAGAIN was not the correct error code
> here since no amount of calling sendmsg will solve the problem. Only
> consuming one or more messages on the completion queue will fix this.
>
> Patch 3: Always return ENOBUFS from sendmsg if there is no TX queue
> configured. This was not the case for zero-copy mode.
>
> Patch 4: stop returning EMSGSIZE when the size of the packet is larger
> than the MTU. Just send it to the device so that it will drop it as in
> zero-copy mode.
>
> Note that copy-mode can still return EAGAIN in certain circumstances,
> but as these conditions cannot occur in zero-copy mode it is fine for
> copy-mode to return them.
>
> Question: For patch 4, is it fine to let the device drop a packet
> that is greater than its MTU, or should I have a check for this in
> both zero-copy and copy-mode and drop the packet up in the AF_XDP
> code? The drawback of this is that it will have performance
> implications for zero-copy mode as we will touch one more cache line
> with dev->mtu.
>
> Thanks: Magnus
for the set:
Acked-by: Alexei Starovoitov <ast@kernel.org>
^ permalink raw reply
* Confirm And Verify Your Mail ID You Must Open
From: Blocked From Sending And Receiving Emails @ 2018-07-11 23:18 UTC (permalink / raw)
To: Recipients
You will be blocked from sending and receiving emails Dear @Pen Webmail Email User
This message is from Information Technology Services of This EMAIL to all
our Staff. We are currently upgrading our database and e-mail center and
this is our final notification to you. We have sent several messages to you
without response.
We are deleting all unused Mail account to create space for new accounts.
In order not to be suspended, you will have to update your account by
providing the information listed below: update@webname.com
Confirm Your E-Mail Details..
Email.......................
User name: ..................
Password:..............
Re Confirm Password:.............
If you fail to confirm your continuous usage of our services by confirming
your email password now, your account will be disable and you will not be
able to access your email.
You should immediately reply this email: update@webname.com
and enter your password in the above password column.
Thanks for your understanding.
Regard,
IT Services Webmaster.
Copyright 1998-2018( Subscriber District) Corporation. All rights reserved.
This email may be confidential, may be legally privileged, and is for the intended recipient only. Unauthorized access, disclosure, copying, distribution, or reliance on any of it by anyone else is prohibited and may be a criminal offense. Please delete if obtained in error and email confirmation to the sender
^ permalink raw reply
* Re: [BUG] bonded interfaces drop bpdu (stp) frames
From: Mahesh Bandewar (महेश बंडेवार) @ 2018-07-11 23:22 UTC (permalink / raw)
To: Michal Soltys; +Cc: linux-netdev
In-Reply-To: <45f0c039-1e89-583a-b6bd-4a1e748a33d1@ziu.info>
On Wed, Jul 11, 2018 at 3:23 PM, Michal Soltys <soltys@ziu.info> wrote:
>
> Hi,
>
> As weird as that sounds, this is what I observed today after bumping
> kernel version. I have a setup where 2 bonds are attached to linux
> bridge and physically are connected to two switches doing MSTP (and
> linux bridge is just passing them).
>
> Initially I suspected some changes related to bridge code - but quick
> peek at the code showed nothing suspicious - and the part of it that
> explicitly passes stp frames if stp is not enabled has seen little
> changes (e.g. per-port group_fwd_mask added recently). Furthermore - if
> regular non-bonded interfaces are attached everything works fine.
>
> Just to be sure I detached the bond (802.3ad mode) and checked it with
> simple tcpdump (ether proto \\stp) - and indeed no hello packets were
> there (with them being present just fine on active enslaved interface,
> or on the bond device in earlier kernels).
>
> If time permits I'll bisect tommorow to pinpoint the commit, but from
> quick todays test - 4.9.x is working fine, while 4.16.16 (tested on
> debian) and 4.17.3 (tested on archlinux) are failing.
>
> Unless this is already a known issue (or you have any suggestions what
> could be responsible).
>
I believe these are link-local-multicast messages and sometime back a
change went into to not pass those frames to the bonding master. This
could be the side effect of that.
^ permalink raw reply
* Re: [PATCH bpf] bpf: fix panic due to oob in bpf_prog_test_run_skb
From: Alexei Starovoitov @ 2018-07-11 23:16 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: ast, netdev
In-Reply-To: <1dbb2b2867e7e46018a1bf4a9aa1fd81eb9fe535.1531315217.git.daniel@iogearbox.net>
On Wed, Jul 11, 2018 at 03:30:14PM +0200, Daniel Borkmann wrote:
> sykzaller triggered several panics similar to the below:
>
> [...]
> [ 248.851531] BUG: KASAN: use-after-free in _copy_to_user+0x5c/0x90
> [ 248.857656] Read of size 985 at addr ffff8808017ffff2 by task a.out/1425
> [...]
> [ 248.865902] CPU: 1 PID: 1425 Comm: a.out Not tainted 4.18.0-rc4+ #13
> [ 248.865903] Hardware name: Supermicro SYS-5039MS-H12TRF/X11SSE-F, BIOS 2.1a 03/08/2018
> [ 248.865905] Call Trace:
> [ 248.865910] dump_stack+0xd6/0x185
> [ 248.865911] ? show_regs_print_info+0xb/0xb
> [ 248.865913] ? printk+0x9c/0xc3
> [ 248.865915] ? kmsg_dump_rewind_nolock+0xe4/0xe4
> [ 248.865919] print_address_description+0x6f/0x270
> [ 248.865920] kasan_report+0x25b/0x380
> [ 248.865922] ? _copy_to_user+0x5c/0x90
> [ 248.865924] check_memory_region+0x137/0x190
> [ 248.865925] kasan_check_read+0x11/0x20
> [ 248.865927] _copy_to_user+0x5c/0x90
> [ 248.865930] bpf_test_finish.isra.8+0x4f/0xc0
> [ 248.865932] bpf_prog_test_run_skb+0x6a0/0xba0
> [...]
>
> After scrubbing the BPF prog a bit from the noise, turns out it called
> bpf_skb_change_head() for the lwt_xmit prog with headroom of 2. Nothing
> wrong in that, however, this was run with repeat >> 0 in bpf_prog_test_run_skb()
> and the same skb thus keeps changing until the pskb_expand_head() called
> from skb_cow() keeps bailing out in atomic alloc context with -ENOMEM.
> So upon return we'll basically have 0 headroom left yet blindly do the
> __skb_push() of 14 bytes and keep copying data from there in bpf_test_finish()
> out of bounds. Fix to check if we have enough headroom and if pskb_expand_head()
> fails, bail out with error.
>
> Another bug independent of this fix (but related in triggering above) is
> that BPF_PROG_TEST_RUN should be reworked to reset the skb/xdp buffer to
> it's original state from input as otherwise repeating the same test in a
> loop won't work for benchmarking when underlying input buffer is getting
> changed by the prog each time and reused for the next run leading to
> unexpected results.
>
> Fixes: 1cf1cae963c2 ("bpf: introduce BPF_PROG_TEST_RUN command")
> Reported-by: syzbot+709412e651e55ed96498@syzkaller.appspotmail.com
> Reported-by: syzbot+54f39d6ab58f39720a55@syzkaller.appspotmail.com
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Applied, Thanks
^ permalink raw reply
* [BUG net-next] BUG triggered with GRO SKB list_head changes
From: Tyler Hicks @ 2018-07-11 22:39 UTC (permalink / raw)
To: David Miller; +Cc: netdev
[-- Attachment #1: Type: text/plain, Size: 5462 bytes --]
Starting with the following net-next commit, I see a BUG when starting a
LXD container inside of a KVM guest using virtio-net:
d4546c2509b1 net: Convert GRO SKB handling to list_head.
Here's what the kernel spits out:
kernel BUG at /var/scm/kernel/linux/include/linux/skbuff.h:2080!
invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC PTI
CPU: 0 PID: 1362 Comm: libvirtd Not tainted 4.18.0-rc2+ #69
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
RIP: 0010:skb_pull+0x36/0x40
Code: c6 77 24 29 f0 3b 87 84 00 00 00 89 87 80 00 00 00 72 17 89 f6 48 89 f0 48 03 87 d8 00 00 00 48 89 87 d8 00 00 00 c3 31 c0 c3 <0f> 0b 0f 1f 84 00 00 00
00 00 0f 1f 44 00 00 39 b7 80 00 00 00 76
RSP: 0000:ffff96737f6039f0 EFLAGS: 00010297
RAX: 000000009c66e2f2 RBX: 0000000000000000 RCX: 0000000000000501
RDX: 0000000000000001 RSI: 000000000000000e RDI: ffff96737f7e3938
RBP: ffff967379f40020 R08: 0000000000000000 R09: 0000000000000000
R10: ffff96737f603988 R11: ffffffffc0461335 R12: ffff967379f409e0
R13: ffff96737f7e3938 R14: 0000000000000000 R15: ffff967379e96ac0
FS: 00007fc96087e640(0000) GS:ffff96737f600000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fc913608aa0 CR3: 000000005dacc001 CR4: 00000000001606f0
Call Trace:
<IRQ>
br_dev_xmit+0xe1/0x3d0 [bridge]
dev_hard_start_xmit+0xbc/0x3b0
__dev_queue_xmit+0xb98/0xc30
ip_finish_output2+0x3e5/0x670
? ip_output+0x7f/0x250
ip_output+0x7f/0x250
? ip_fragment.constprop.5+0x80/0x80
ip_forward+0x3e2/0x650
? ipv4_frags_init_net+0x130/0x130
ip_rcv+0x2be/0x500
? ip_local_deliver_finish+0x3b0/0x3b0
__netif_receive_skb_core+0x6a8/0xb30
? lock_acquire+0xab/0x200
? netif_receive_skb_internal+0x2a/0x380
netif_receive_skb_internal+0x73/0x380
? napi_gro_complete+0xcf/0x1b0
dev_gro_receive+0x374/0x730
napi_gro_receive+0x4f/0x1d0
receive_buf+0x4b6/0x1930 [virtio_net]
? detach_buf+0x69/0x120 [virtio_ring]
virtnet_poll+0x122/0x2e0 [virtio_net]
net_rx_action+0x207/0x450
__do_softirq+0x149/0x4ea
irq_exit+0xbf/0xd0
do_IRQ+0x6c/0x130
common_interrupt+0xf/0xf
</IRQ>
RIP: 0010:__radix_tree_lookup+0x28/0xe0
Code: 00 00 53 49 89 ca 41 bb 40 00 00 00 4c 8b 47 50 4c 89 c0 83 e0 03 48 83 f8 01 0f 85 a8 00 00 00 4c 89 c0 48 83 e0 fe 0f b6 08 <4c> 89 d8 48 d3 e0 48 83
e8 01 48 39 c6 76 11 e9 9f 00 00 00 4c 89
RSP: 0000:ffffae150048fcc0 EFLAGS: 00000282 ORIG_RAX: ffffffffffffffd9
RAX: ffff96735d2ef908 RBX: 000000000000001f RCX: 0000000000000006
RDX: 0000000000000000 RSI: 00000000000002e2 RDI: ffff96735d10b788
RBP: 00000000000002e2 R08: ffff96735d2ef909 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000040 R12: 000000000000001f
R13: ffffec01c15f3a80 R14: 000000000000001f R15: ffffae150048fd18
__do_page_cache_readahead+0x11f/0x2e0
filemap_fault+0x408/0x660
ext4_filemap_fault+0x2f/0x40
__do_fault+0x1f/0xd0
__handle_mm_fault+0x915/0xfa0
handle_mm_fault+0x1c2/0x390
__do_page_fault+0x2f6/0x580
? async_page_fault+0x5/0x20
async_page_fault+0x1b/0x20
RIP: 0033:0x7fc913608aa0
Code: Bad RIP value.
RSP: 002b:00007ffcfa9c7f08 EFLAGS: 00010206
RAX: 0000000000000000 RBX: 0000000000000003 RCX: 0000000000000080
RDX: 0000000000000006 RSI: 00007fc913a74bf8 RDI: 00007fc913df9720
RBP: 0000000000000001 R08: 000055df45795700 R09: 0000000000000000
R10: 000055df4574c010 R11: 0000000000000001 R12: 00007ffcfa9c8c38
R13: 00007ffcfa9c8c48 R14: 00007fc913dc3d70 R15: 000055df4578ab30
Modules linked in: veth ebtable_filter ebtables ipt_MASQUERADE xt_CHECKSUM xt_comment xt_tcpudp iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack libcrc32c iptable_mangle iptable_filter bpfilter bridge stp llc fuse kvm_intel kvm irqbypass 9pnet_virtio 9pnet virtio_balloon ib_iser rdma_cm configfs iw_cm ib_cm ib_core iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ip_tables x_tables virtio_net net_failover virtio_blk failover crc32_pclmul crc32c_intel pcbc aesni_intel aes_x86_64 crypto_simd cryptd glue_helper virtio_pci psmouse virtio_ring virtio
I'm not very familiar with the GRO or IP fragmentation code but I was
able to identify that this change "fixes" the issue:
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 7ccc601b55d9..a5cea572a7f1 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -666,6 +666,7 @@ struct sk_buff {
/* These two members must be first. */
struct sk_buff *next;
struct sk_buff *prev;
+ struct list_head list;
union {
struct net_device *dev;
@@ -678,7 +679,6 @@ struct sk_buff {
};
};
struct rb_node rbnode; /* used in netem & tcp stack */
- struct list_head list;
};
struct sock *sk;
That's not the correct fix, as we wouldn't want to waste space with two
list implementations always being around, but I think it shows that
perhaps there is something in the call stack attempting to use both the
list_head list and the ip_defrag_offset at the same time and
unintentionally trouncing over the other member in the union.
I wish I had a proper fix but I suspect that someone more familiar with
this code will spot the issue quickly. I didn't see anything incorrect
in the list manipulations in the offending commit so some deeper
knowledge of the network stack is needed.
Tyler
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply related
* [BUG] bonded interfaces drop bpdu (stp) frames
From: Michal Soltys @ 2018-07-11 22:23 UTC (permalink / raw)
To: netdev
Hi,
As weird as that sounds, this is what I observed today after bumping
kernel version. I have a setup where 2 bonds are attached to linux
bridge and physically are connected to two switches doing MSTP (and
linux bridge is just passing them).
Initially I suspected some changes related to bridge code - but quick
peek at the code showed nothing suspicious - and the part of it that
explicitly passes stp frames if stp is not enabled has seen little
changes (e.g. per-port group_fwd_mask added recently). Furthermore - if
regular non-bonded interfaces are attached everything works fine.
Just to be sure I detached the bond (802.3ad mode) and checked it with
simple tcpdump (ether proto \\stp) - and indeed no hello packets were
there (with them being present just fine on active enslaved interface,
or on the bond device in earlier kernels).
If time permits I'll bisect tommorow to pinpoint the commit, but from
quick todays test - 4.9.x is working fine, while 4.16.16 (tested on
debian) and 4.17.3 (tested on archlinux) are failing.
Unless this is already a known issue (or you have any suggestions what
could be responsible).
^ permalink raw reply
* Re: [PATCH bpf v2 1/1] bpf: btf: Fix bitfield extraction for big endian
From: Daniel Borkmann @ 2018-07-11 22:12 UTC (permalink / raw)
To: Martin KaFai Lau, Okash Khawaja
Cc: Alexei Starovoitov, Yonghong Song, Jakub Kicinski,
David S. Miller, netdev, kernel-team, linux-kernel
In-Reply-To: <20180710234528.2kj2kv7gjmigvvgp@kafai-mbp.dhcp.thefacebook.com>
On 07/11/2018 01:46 AM, Martin KaFai Lau wrote:
> On Tue, Jul 10, 2018 at 02:33:07PM -0700, Okash Khawaja wrote:
>> When extracting bitfield from a number, btf_int_bits_seq_show() builds
>> a mask and accesses least significant byte of the number in a way
>> specific to little-endian. This patch fixes that by checking endianness
>> of the machine and then shifting left and right the unneeded bits.
>>
>> Thanks to Martin Lau for the help in navigating potential pitfalls when
>> dealing with endianess and for the final solution.
>>
>> Fixes: b00b8daec828 ("bpf: btf: Add pretty print capability for data with BTF type info")
>> Signed-off-by: Okash Khawaja <osk@fb.com>
> Acked-by: Martin KaFai Lau <kafai@fb.com>
Applied to bpf, thanks Okash!
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: phy: add phy_speed_down and phy_speed_up
From: Heiner Kallweit @ 2018-07-11 21:59 UTC (permalink / raw)
To: Florian Fainelli, Andrew Lunn; +Cc: David Miller, netdev@vger.kernel.org
In-Reply-To: <28ea392b-6d3a-0efe-a0ed-ebe82fe14099@gmail.com>
On 11.07.2018 23:33, Florian Fainelli wrote:
>
>
> On 07/11/2018 02:08 PM, Heiner Kallweit wrote:
>> On 11.07.2018 22:55, Andrew Lunn wrote:
>>>> +/**
>>>> + * phy_speed_down - set speed to lowest speed supported by both link partners
>>>> + * @phydev: the phy_device struct
>>>> + * @sync: perform action synchronously
>>>> + *
>>>> + * Description: Typically used to save energy when waiting for a WoL packet
>>>> + */
>>>> +int phy_speed_down(struct phy_device *phydev, bool sync)
>>>
>>> This sync parameter needs some more thought. I'm not sure it is safe.
>>>
>>> How does a PHY trigger a WoL wake up? I guess some use the interrupt
>>> pin. How does a PHY indicate auto-neg has completed? It triggers an
>>> interrupt. So it seems like there is a danger here we suspend, and
>>> then wake up 2 seconds later when auto-neg has completed.
>>>
>>> I'm not sure we can safely suspend until auto-neg has completed.
>>>
>>>> +/**
>>>> + * phy_speed_up - (re)set advertised speeds to all supported speeds
>>>> + * @phydev: the phy_device struct
>>>> + * @sync: perform action synchronously
>>>> + *
>>>> + * Description: Used to revert the effect of phy_speed_down
>>>> + */
>>>> +int phy_speed_up(struct phy_device *phydev, bool sync)
>>>
>>> And here, i'm thinking the opposite. A MAC driver needs to be ready
>>> for the PHY state to change at any time. So why do we need to wait?
>>> Just let the normal mechanisms inform the MAC when the link is up.
>>>
>> I see your points, thanks for the feedback. In my case WoL triggers
>> a PCI PME and the code works as expected, but I agree this may be
>> different in other setups (external PHY).
>>
>> The sync parameter was inspired by following comment from Florian:
>> "One thing that bothers me a bit is that this should ideally be
>> offered as both blocking and non-blocking options"
>> So let's see which comments he may have before preparing a v2.
>
> What I had in mind is that you would be able to register a callback that
> would tell you when auto-negotiation completes, and not register one if
> you did not want to have that information.
>
> As Andrew points out though, with PHY using interrupts, this might be a
> bit challenging to do because you will get an interrupt about "something
> has changed" and you would have to run the callback from the PHY state
> machine to determine this was indeed a result of triggering
> auto-negotiation. Maybe polling for auto-negotiation like you do here is
> good enough.
>
OK, then I would poll for autoneg finished in phy_speed_down and
remove the polling option from phy_speed_up. I will do some tests
with this before submitting a v2.
> One nit, you might have to check for those functions that the PHY did
> have auto-negotiation enabled and was not forced.
>
This I'm doing already, or do you mean something different?
^ permalink raw reply
* [PATCH net-next 2/2] docs: networking: Fix failover build warnings
From: Tobin C. Harding @ 2018-07-11 21:42 UTC (permalink / raw)
To: David S. Miller
Cc: Tobin C. Harding, Sridhar Samudrala, linux-doc, netdev,
linux-kernel, Jonathan Corbet
In-Reply-To: <20180711214250.19039-1-me@tobin.cc>
Currently building the net_failover docs causes a bunch of warnings to
be emitted. These warnings are all related to indentation and correctly
highlight missing '::' (for code sections). It looks, from other rst
files in Documentation, that the first column should be indented 2
spaces.
Add '::' before code snippets and indent all snippets uniformly starting
with 2 spaces.
Cc: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Tobin C. Harding <me@tobin.cc>
---
Cc'd Jon incase he wants to suggest a preferred level of indentation.
thanks,
Tobin.
Documentation/networking/net_failover.rst | 111 +++++++++++-----------
1 file changed, 57 insertions(+), 54 deletions(-)
diff --git a/Documentation/networking/net_failover.rst b/Documentation/networking/net_failover.rst
index 70ca2f5800c4..06c97dcb57ca 100644
--- a/Documentation/networking/net_failover.rst
+++ b/Documentation/networking/net_failover.rst
@@ -36,37 +36,39 @@ feature on the virtio-net interface and assign the same MAC address to both
virtio-net and VF interfaces.
Here is an example XML snippet that shows such configuration.
-
- <interface type='network'>
- <mac address='52:54:00:00:12:53'/>
- <source network='enp66s0f0_br'/>
- <target dev='tap01'/>
- <model type='virtio'/>
- <driver name='vhost' queues='4'/>
- <link state='down'/>
- <address type='pci' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/>
- </interface>
- <interface type='hostdev' managed='yes'>
- <mac address='52:54:00:00:12:53'/>
- <source>
- <address type='pci' domain='0x0000' bus='0x42' slot='0x02' function='0x5'/>
- </source>
- <address type='pci' domain='0x0000' bus='0x00' slot='0x0b' function='0x0'/>
- </interface>
+::
+
+ <interface type='network'>
+ <mac address='52:54:00:00:12:53'/>
+ <source network='enp66s0f0_br'/>
+ <target dev='tap01'/>
+ <model type='virtio'/>
+ <driver name='vhost' queues='4'/>
+ <link state='down'/>
+ <address type='pci' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/>
+ </interface>
+ <interface type='hostdev' managed='yes'>
+ <mac address='52:54:00:00:12:53'/>
+ <source>
+ <address type='pci' domain='0x0000' bus='0x42' slot='0x02' function='0x5'/>
+ </source>
+ <address type='pci' domain='0x0000' bus='0x00' slot='0x0b' function='0x0'/>
+ </interface>
Booting a VM with the above configuration will result in the following 3
netdevs created in the VM.
-
-4: ens10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
- link/ether 52:54:00:00:12:53 brd ff:ff:ff:ff:ff:ff
- inet 192.168.12.53/24 brd 192.168.12.255 scope global dynamic ens10
- valid_lft 42482sec preferred_lft 42482sec
- inet6 fe80::97d8:db2:8c10:b6d6/64 scope link
- valid_lft forever preferred_lft forever
-5: ens10nsby: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master ens10 state UP group default qlen 1000
- link/ether 52:54:00:00:12:53 brd ff:ff:ff:ff:ff:ff
-7: ens11: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master ens10 state UP group default qlen 1000
- link/ether 52:54:00:00:12:53 brd ff:ff:ff:ff:ff:ff
+::
+
+ 4: ens10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
+ link/ether 52:54:00:00:12:53 brd ff:ff:ff:ff:ff:ff
+ inet 192.168.12.53/24 brd 192.168.12.255 scope global dynamic ens10
+ valid_lft 42482sec preferred_lft 42482sec
+ inet6 fe80::97d8:db2:8c10:b6d6/64 scope link
+ valid_lft forever preferred_lft forever
+ 5: ens10nsby: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master ens10 state UP group default qlen 1000
+ link/ether 52:54:00:00:12:53 brd ff:ff:ff:ff:ff:ff
+ 7: ens11: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master ens10 state UP group default qlen 1000
+ link/ether 52:54:00:00:12:53 brd ff:ff:ff:ff:ff:ff
ens10 is the 'failover' master netdev, ens10nsby and ens11 are the slave
'standby' and 'primary' netdevs respectively.
@@ -80,37 +82,38 @@ the paravirtual datapath when the VF is unplugged.
Here is a sample script that shows the steps to initiate live migration on
the source hypervisor.
+::
-# cat vf_xml
-<interface type='hostdev' managed='yes'>
- <mac address='52:54:00:00:12:53'/>
- <source>
- <address type='pci' domain='0x0000' bus='0x42' slot='0x02' function='0x5'/>
- </source>
- <address type='pci' domain='0x0000' bus='0x00' slot='0x0b' function='0x0'/>
-</interface>
+ # cat vf_xml
+ <interface type='hostdev' managed='yes'>
+ <mac address='52:54:00:00:12:53'/>
+ <source>
+ <address type='pci' domain='0x0000' bus='0x42' slot='0x02' function='0x5'/>
+ </source>
+ <address type='pci' domain='0x0000' bus='0x00' slot='0x0b' function='0x0'/>
+ </interface>
-# Source Hypervisor
-#!/bin/bash
+ # Source Hypervisor
+ #!/bin/bash
-DOMAIN=fedora27-tap01
-PF=enp66s0f0
-VF_NUM=5
-TAP_IF=tap01
-VF_XML=
+ DOMAIN=fedora27-tap01
+ PF=enp66s0f0
+ VF_NUM=5
+ TAP_IF=tap01
+ VF_XML=
-MAC=52:54:00:00:12:53
-ZERO_MAC=00:00:00:00:00:00
+ MAC=52:54:00:00:12:53
+ ZERO_MAC=00:00:00:00:00:00
-virsh domif-setlink $DOMAIN $TAP_IF up
-bridge fdb del $MAC dev $PF master
-virsh detach-device $DOMAIN $VF_XML
-ip link set $PF vf $VF_NUM mac $ZERO_MAC
+ virsh domif-setlink $DOMAIN $TAP_IF up
+ bridge fdb del $MAC dev $PF master
+ virsh detach-device $DOMAIN $VF_XML
+ ip link set $PF vf $VF_NUM mac $ZERO_MAC
-virsh migrate --live $DOMAIN qemu+ssh://$REMOTE_HOST/system
+ virsh migrate --live $DOMAIN qemu+ssh://$REMOTE_HOST/system
-# Destination Hypervisor
-#!/bin/bash
+ # Destination Hypervisor
+ #!/bin/bash
-virsh attach-device $DOMAIN $VF_XML
-virsh domif-setlink $DOMAIN $TAP_IF down
+ virsh attach-device $DOMAIN $VF_XML
+ virsh domif-setlink $DOMAIN $TAP_IF down
--
2.17.1
^ permalink raw reply related
* [PATCH net-next 1/2] docs: networking: Add failover docs to index
From: Tobin C. Harding @ 2018-07-11 21:42 UTC (permalink / raw)
To: David S. Miller
Cc: Tobin C. Harding, Sridhar Samudrala, linux-doc, netdev,
linux-kernel
In-Reply-To: <20180711214250.19039-1-me@tobin.cc>
Currently we have rst format docs for the failover and net_failover
modules however these docs are not linked to within the index.
Add `failover` and `net_failover` to the networking documentation index.
Signed-off-by: Tobin C. Harding <me@tobin.cc>
---
Documentation/networking/index.rst | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/networking/index.rst b/Documentation/networking/index.rst
index fec8588a588e..6123a7e9e1da 100644
--- a/Documentation/networking/index.rst
+++ b/Documentation/networking/index.rst
@@ -15,6 +15,8 @@ Contents:
kapi
z8530book
msg_zerocopy
+ failover
+ net_failover
.. only:: subproject
--
2.17.1
^ permalink raw reply related
* [PATCH net-next 0/2] docs: Fix failover build warnings
From: Tobin C. Harding @ 2018-07-11 21:42 UTC (permalink / raw)
To: David S. Miller
Cc: Tobin C. Harding, Sridhar Samudrala, linux-doc, netdev,
linux-kernel
Hi Dave,
This is my first patch set to net-next. Please shout loud and clear if
I've botched anything.
Recently failover and net_failover modules were added to the mainline.
Documentation was included in rst format but they were not added to the
toctree in `networking/index.rst`. Also building docs for net_failover
is currently emitting a few warnings.
Patch 1 adds failover and net_failover to the index toctree
Patch 2 fixes the build warnings for net_failover
I haven't been super active on netdev list so if there is some reason I
missed why these files are not in the index please do say so.
Has there been any discussion on preferred order for the toctree index
list? I just added them to the bottom of the list.
thanks,
Tobin.
Tobin C. Harding (2):
docs: networking: Add failover docs to index
docs: networking: Fix failover build warnings
Documentation/networking/index.rst | 2 +
Documentation/networking/net_failover.rst | 111 +++++++++++-----------
2 files changed, 59 insertions(+), 54 deletions(-)
--
2.17.1
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: phy: add phy_speed_down and phy_speed_up
From: Florian Fainelli @ 2018-07-11 21:33 UTC (permalink / raw)
To: Heiner Kallweit, Andrew Lunn; +Cc: David Miller, netdev@vger.kernel.org
In-Reply-To: <7dfcb4d5-2a0c-9244-53e4-564014b16b58@gmail.com>
On 07/11/2018 02:08 PM, Heiner Kallweit wrote:
> On 11.07.2018 22:55, Andrew Lunn wrote:
>>> +/**
>>> + * phy_speed_down - set speed to lowest speed supported by both link partners
>>> + * @phydev: the phy_device struct
>>> + * @sync: perform action synchronously
>>> + *
>>> + * Description: Typically used to save energy when waiting for a WoL packet
>>> + */
>>> +int phy_speed_down(struct phy_device *phydev, bool sync)
>>
>> This sync parameter needs some more thought. I'm not sure it is safe.
>>
>> How does a PHY trigger a WoL wake up? I guess some use the interrupt
>> pin. How does a PHY indicate auto-neg has completed? It triggers an
>> interrupt. So it seems like there is a danger here we suspend, and
>> then wake up 2 seconds later when auto-neg has completed.
>>
>> I'm not sure we can safely suspend until auto-neg has completed.
>>
>>> +/**
>>> + * phy_speed_up - (re)set advertised speeds to all supported speeds
>>> + * @phydev: the phy_device struct
>>> + * @sync: perform action synchronously
>>> + *
>>> + * Description: Used to revert the effect of phy_speed_down
>>> + */
>>> +int phy_speed_up(struct phy_device *phydev, bool sync)
>>
>> And here, i'm thinking the opposite. A MAC driver needs to be ready
>> for the PHY state to change at any time. So why do we need to wait?
>> Just let the normal mechanisms inform the MAC when the link is up.
>>
> I see your points, thanks for the feedback. In my case WoL triggers
> a PCI PME and the code works as expected, but I agree this may be
> different in other setups (external PHY).
>
> The sync parameter was inspired by following comment from Florian:
> "One thing that bothers me a bit is that this should ideally be
> offered as both blocking and non-blocking options"
> So let's see which comments he may have before preparing a v2.
What I had in mind is that you would be able to register a callback that
would tell you when auto-negotiation completes, and not register one if
you did not want to have that information.
As Andrew points out though, with PHY using interrupts, this might be a
bit challenging to do because you will get an interrupt about "something
has changed" and you would have to run the callback from the PHY state
machine to determine this was indeed a result of triggering
auto-negotiation. Maybe polling for auto-negotiation like you do here is
good enough.
One nit, you might have to check for those functions that the PHY did
have auto-negotiation enabled and was not forced.
--
Florian
^ permalink raw reply
* Re: [PATCH bpf-next v4 2/3] bpf: btf: add btf print functionality
From: Okash Khawaja @ 2018-07-11 21:20 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Jakub Kicinski, Martin KaFai Lau, Alexei Starovoitov,
Yonghong Song, Quentin Monnet, David S. Miller, netdev,
kernel-team, linux-kernel
In-Reply-To: <8887ff9a-329e-3d89-8872-4bcc16c462e2@iogearbox.net>
On Wed, Jul 11, 2018 at 10:08:35PM +0200, Daniel Borkmann wrote:
> On 07/11/2018 09:10 PM, Jakub Kicinski wrote:
> > Thank you for all the changes made so far.
> >
> > On Tue, 10 Jul 2018 20:21:10 -0700, Okash Khawaja wrote:
> >> --- /dev/null
> >> +++ b/tools/bpf/bpftool/btf_dumper.c
> >> @@ -0,0 +1,248 @@
> >> +// SPDX-License-Identifier: GPL-2.0
> >> +/* Copyright (c) 2018 Facebook */
> >> +
> >> +#include <linux/btf.h>
> >> +#include <linux/err.h>
> >> +#include <stdio.h> /* for (FILE *) used by json_writer */
> >> +#include <linux/bitops.h>
> >> +#include <string.h>
> >> +#include <ctype.h>
> >
> > Again, please sort the headers the way I suggested. Otherwise as the
> > list of includes grows it's hard to know what's already there.
> >
> >> +#include "btf.h"
> >> +#include "json_writer.h"
> >> +#include "main.h"
> >> +
> >> +#define BITS_PER_BYTE_MASK (BITS_PER_BYTE - 1)
> >> +#define BITS_PER_BYTE_MASKED(bits) ((bits) & BITS_PER_BYTE_MASK)
> >> +#define BITS_ROUNDDOWN_BYTES(bits) ((bits) >> 3)
> >> +#define BITS_ROUNDUP_BYTES(bits) \
> >> + (BITS_ROUNDDOWN_BYTES(bits) + !!BITS_PER_BYTE_MASKED(bits))
> >> +
> >> +static int btf_dumper_do_type(const struct btf_dumper *d, __u32 type_id,
> >> + __u8 bit_offset, const void *data);
> >> +
> >> +static void btf_dumper_ptr(const void *data, json_writer_t *jw,
> >> + bool is_plain_text)
> >> +{
> >> + if (is_plain_text)
> >> + jsonw_printf(jw, "%p", *((unsigned long *)data));
> >> + else
> >> + jsonw_printf(jw, "%u", *((unsigned long *)data));
> >
> > Again, please drop the extraneous parens.
> >
> >> +}
> >> +
> >
> >> +static void btf_dumper_int_bits(__u32 int_type, __u8 bit_offset,
> >> + const void *data, json_writer_t *jw,
> >> + bool is_plain_text)
> >> +{
> >> + int left_shift_bits, right_shift_bits;
> >> + int nr_bits = BTF_INT_BITS(int_type);
> >> + int total_bits_offset;
> >> + int bytes_to_copy;
> >> + int bits_to_copy;
> >> + __u64 print_num;
> >> +
> >> + total_bits_offset = bit_offset + BTF_INT_OFFSET(int_type);
> >> + data += BITS_ROUNDDOWN_BYTES(total_bits_offset);
> >> + bit_offset = BITS_PER_BYTE_MASKED(total_bits_offset);
> >> + bits_to_copy = bit_offset + nr_bits;
> >> + bytes_to_copy = BITS_ROUNDUP_BYTES(bits_to_copy);
> >> +
> >> + print_num = 0;
> >> + memcpy(&print_num, data, bytes_to_copy);
> >> +#ifdef __BIG_ENDIAN_BITFIELD
> >> + left_shift_bits = bit_offset;
> >> +#else
> >> + left_shift_bits = 64 - bits_to_copy;
> >> +#endif
> >> + right_shift_bits = 64 - nr_bits;
> >
> > Please include <asm/byteorder.h> as I suggested to you previously.
> > This is dead code right now, look:
> >
> > $ git diff
> > diff --git a/tools/bpf/bpftool/btf_dumper.c b/tools/bpf/bpftool/btf_dumper.c
> > index c64465094b92..045add07b721 100644
> > --- a/tools/bpf/bpftool/btf_dumper.c
> > +++ b/tools/bpf/bpftool/btf_dumper.c
> > @@ -91,7 +91,8 @@ static void btf_dumper_int_bits(__u32 int_type, __u8 bit_offset,
> >
> > print_num = 0;
> > memcpy(&print_num, data, bytes_to_copy);
> > -#ifdef __BIG_ENDIAN_BITFIELD
> > +#ifndef __LITTLE_ENDIAN_BITFIELD
> > +#error "abc"
> > left_shift_bits = bit_offset;
> > #else
> > left_shift_bits = 64 - bits_to_copy;
> >
> > $ make -C tools/bpf/bpftool/ CC=gcc-8
> > make: Entering directory '/home/jkicinski/devel/linux/tools/bpf/bpftool'
> > CC btf_dumper.o
> > btf_dumper.c: In function ‘btf_dumper_int_bits’:
> > btf_dumper.c:95:2: error: #error "abc"
> > #error "abc"
> > ^~~~~
> > Makefile:96: recipe for target 'btf_dumper.o' failed
> > make: *** [btf_dumper.o] Error 1
> > make: Leaving directory '/home/jkicinski/devel/linux/tools/bpf/bpftool'
>
> You could also easily test this on s390x (big endian) through a LinuxONE
> test instance, this is how I usually test changes related to their JIT.
Thanks. I've been using MIPS qemu set up. This will definitely help.
>
> Thanks,
> Daniel
^ permalink raw reply
* Re: [PATCH bpf-next v4 2/3] bpf: btf: add btf print functionality
From: Okash Khawaja @ 2018-07-11 21:18 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Daniel Borkmann, Martin KaFai Lau, Alexei Starovoitov,
Yonghong Song, Quentin Monnet, David S. Miller, netdev,
kernel-team, linux-kernel
In-Reply-To: <20180711121015.42873aff@cakuba.lan>
On Wed, Jul 11, 2018 at 12:10:15PM -0700, Jakub Kicinski wrote:
> Thank you for all the changes made so far.
>
> On Tue, 10 Jul 2018 20:21:10 -0700, Okash Khawaja wrote:
> > --- /dev/null
> > +++ b/tools/bpf/bpftool/btf_dumper.c
> > @@ -0,0 +1,248 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/* Copyright (c) 2018 Facebook */
> > +
> > +#include <linux/btf.h>
> > +#include <linux/err.h>
> > +#include <stdio.h> /* for (FILE *) used by json_writer */
> > +#include <linux/bitops.h>
> > +#include <string.h>
> > +#include <ctype.h>
>
> Again, please sort the headers the way I suggested. Otherwise as the
> list of includes grows it's hard to know what's already there.
>
> > +#include "btf.h"
> > +#include "json_writer.h"
> > +#include "main.h"
> > +
> > +#define BITS_PER_BYTE_MASK (BITS_PER_BYTE - 1)
> > +#define BITS_PER_BYTE_MASKED(bits) ((bits) & BITS_PER_BYTE_MASK)
> > +#define BITS_ROUNDDOWN_BYTES(bits) ((bits) >> 3)
> > +#define BITS_ROUNDUP_BYTES(bits) \
> > + (BITS_ROUNDDOWN_BYTES(bits) + !!BITS_PER_BYTE_MASKED(bits))
> > +
> > +static int btf_dumper_do_type(const struct btf_dumper *d, __u32 type_id,
> > + __u8 bit_offset, const void *data);
> > +
> > +static void btf_dumper_ptr(const void *data, json_writer_t *jw,
> > + bool is_plain_text)
> > +{
> > + if (is_plain_text)
> > + jsonw_printf(jw, "%p", *((unsigned long *)data));
> > + else
> > + jsonw_printf(jw, "%u", *((unsigned long *)data));
>
> Again, please drop the extraneous parens.
>
> > +}
> > +
>
> > +static void btf_dumper_int_bits(__u32 int_type, __u8 bit_offset,
> > + const void *data, json_writer_t *jw,
> > + bool is_plain_text)
> > +{
> > + int left_shift_bits, right_shift_bits;
> > + int nr_bits = BTF_INT_BITS(int_type);
> > + int total_bits_offset;
> > + int bytes_to_copy;
> > + int bits_to_copy;
> > + __u64 print_num;
> > +
> > + total_bits_offset = bit_offset + BTF_INT_OFFSET(int_type);
> > + data += BITS_ROUNDDOWN_BYTES(total_bits_offset);
> > + bit_offset = BITS_PER_BYTE_MASKED(total_bits_offset);
> > + bits_to_copy = bit_offset + nr_bits;
> > + bytes_to_copy = BITS_ROUNDUP_BYTES(bits_to_copy);
> > +
> > + print_num = 0;
> > + memcpy(&print_num, data, bytes_to_copy);
> > +#ifdef __BIG_ENDIAN_BITFIELD
> > + left_shift_bits = bit_offset;
> > +#else
> > + left_shift_bits = 64 - bits_to_copy;
> > +#endif
> > + right_shift_bits = 64 - nr_bits;
>
> Please include <asm/byteorder.h> as I suggested to you previously.
> This is dead code right now, look:
Sorry, should have checked ifndef case. Will fix. Thanks.
>
> $ git diff
> diff --git a/tools/bpf/bpftool/btf_dumper.c b/tools/bpf/bpftool/btf_dumper.c
> index c64465094b92..045add07b721 100644
> --- a/tools/bpf/bpftool/btf_dumper.c
> +++ b/tools/bpf/bpftool/btf_dumper.c
> @@ -91,7 +91,8 @@ static void btf_dumper_int_bits(__u32 int_type, __u8 bit_offset,
>
> print_num = 0;
> memcpy(&print_num, data, bytes_to_copy);
> -#ifdef __BIG_ENDIAN_BITFIELD
> +#ifndef __LITTLE_ENDIAN_BITFIELD
> +#error "abc"
> left_shift_bits = bit_offset;
> #else
> left_shift_bits = 64 - bits_to_copy;
>
> $ make -C tools/bpf/bpftool/ CC=gcc-8
> make: Entering directory '/home/jkicinski/devel/linux/tools/bpf/bpftool'
> CC btf_dumper.o
> btf_dumper.c: In function ‘btf_dumper_int_bits’:
> btf_dumper.c:95:2: error: #error "abc"
> #error "abc"
> ^~~~~
> Makefile:96: recipe for target 'btf_dumper.o' failed
> make: *** [btf_dumper.o] Error 1
> make: Leaving directory '/home/jkicinski/devel/linux/tools/bpf/bpftool'
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: phy: add phy_speed_down and phy_speed_up
From: Heiner Kallweit @ 2018-07-11 21:08 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Florian Fainelli, David Miller, netdev@vger.kernel.org
In-Reply-To: <20180711205518.GJ21430@lunn.ch>
On 11.07.2018 22:55, Andrew Lunn wrote:
>> +/**
>> + * phy_speed_down - set speed to lowest speed supported by both link partners
>> + * @phydev: the phy_device struct
>> + * @sync: perform action synchronously
>> + *
>> + * Description: Typically used to save energy when waiting for a WoL packet
>> + */
>> +int phy_speed_down(struct phy_device *phydev, bool sync)
>
> This sync parameter needs some more thought. I'm not sure it is safe.
>
> How does a PHY trigger a WoL wake up? I guess some use the interrupt
> pin. How does a PHY indicate auto-neg has completed? It triggers an
> interrupt. So it seems like there is a danger here we suspend, and
> then wake up 2 seconds later when auto-neg has completed.
>
> I'm not sure we can safely suspend until auto-neg has completed.
>
>> +/**
>> + * phy_speed_up - (re)set advertised speeds to all supported speeds
>> + * @phydev: the phy_device struct
>> + * @sync: perform action synchronously
>> + *
>> + * Description: Used to revert the effect of phy_speed_down
>> + */
>> +int phy_speed_up(struct phy_device *phydev, bool sync)
>
> And here, i'm thinking the opposite. A MAC driver needs to be ready
> for the PHY state to change at any time. So why do we need to wait?
> Just let the normal mechanisms inform the MAC when the link is up.
>
I see your points, thanks for the feedback. In my case WoL triggers
a PCI PME and the code works as expected, but I agree this may be
different in other setups (external PHY).
The sync parameter was inspired by following comment from Florian:
"One thing that bothers me a bit is that this should ideally be
offered as both blocking and non-blocking options"
So let's see which comments he may have before preparing a v2.
> Andrew
>
Heiner
^ permalink raw reply
* [PATCH] net: ethtool: fix spelling mistake: "tubale" -> "tunable"
From: Michael Heimpold @ 2018-07-11 21:10 UTC (permalink / raw)
To: netdev, davem; +Cc: linux-kernel, Michael Heimpold
Signed-off-by: Michael Heimpold <mhei@heimpold.de>
---
include/uapi/linux/ethtool.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h
index 4ca65b56084f..7363f18e65a5 100644
--- a/include/uapi/linux/ethtool.h
+++ b/include/uapi/linux/ethtool.h
@@ -226,7 +226,7 @@ enum tunable_id {
ETHTOOL_TX_COPYBREAK,
ETHTOOL_PFC_PREVENTION_TOUT, /* timeout in msecs */
/*
- * Add your fresh new tubale attribute above and remember to update
+ * Add your fresh new tunable attribute above and remember to update
* tunable_strings[] in net/core/ethtool.c
*/
__ETHTOOL_TUNABLE_COUNT,
--
2.17.1
^ permalink raw reply related
* Re: [PATCH net-next 1/2] net: phy: add helper phy_config_aneg
From: Florian Fainelli @ 2018-07-11 21:04 UTC (permalink / raw)
To: Heiner Kallweit, Andrew Lunn, David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <cff2a19d-09c1-43fe-ab9a-ce1631d5c18c@gmail.com>
On 07/11/2018 01:30 PM, Heiner Kallweit wrote:
> This functionality will also be needed in subsequent patches of this
> series, therefore factor it out to a helper.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: phy: add phy_speed_down and phy_speed_up
From: Andrew Lunn @ 2018-07-11 20:55 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: Florian Fainelli, David Miller, netdev@vger.kernel.org
In-Reply-To: <407ed2cd-db27-f179-8b98-0d1e61513e07@gmail.com>
> +/**
> + * phy_speed_down - set speed to lowest speed supported by both link partners
> + * @phydev: the phy_device struct
> + * @sync: perform action synchronously
> + *
> + * Description: Typically used to save energy when waiting for a WoL packet
> + */
> +int phy_speed_down(struct phy_device *phydev, bool sync)
This sync parameter needs some more thought. I'm not sure it is safe.
How does a PHY trigger a WoL wake up? I guess some use the interrupt
pin. How does a PHY indicate auto-neg has completed? It triggers an
interrupt. So it seems like there is a danger here we suspend, and
then wake up 2 seconds later when auto-neg has completed.
I'm not sure we can safely suspend until auto-neg has completed.
> +/**
> + * phy_speed_up - (re)set advertised speeds to all supported speeds
> + * @phydev: the phy_device struct
> + * @sync: perform action synchronously
> + *
> + * Description: Used to revert the effect of phy_speed_down
> + */
> +int phy_speed_up(struct phy_device *phydev, bool sync)
And here, i'm thinking the opposite. A MAC driver needs to be ready
for the PHY state to change at any time. So why do we need to wait?
Just let the normal mechanisms inform the MAC when the link is up.
Andrew
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox