* Re: [RFC PATCH net-next V2 0/6] XDP rx handler
From: Jason Wang @ 2018-08-16 4:24 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: David Ahern, Jesper Dangaard Brouer, netdev, linux-kernel, ast,
daniel, mst
In-Reply-To: <20180816040517.7vjm4bwxosyzvapu@ast-mbp.dhcp.thefacebook.com>
On 2018年08月16日 12:05, Alexei Starovoitov wrote:
> On Thu, Aug 16, 2018 at 11:34:20AM +0800, Jason Wang wrote:
>>> Nothing about the topology is hard coded. The idea is to mimic a
>>> hardware pipeline and acknowledging that a port device can have an
>>> arbitrary layers stacked on it - multiple vlan devices, bonds, macvlans, etc
>> I may miss something but BPF forbids loop. Without a loop how can we make
>> sure all stacked devices is enumerated correctly without knowing the
>> topology in advance?
> not following. why do you need a loop to implement macvlan as an xdp prog?
> if loop is needed, such algorithm is not going to scale whether
> it's implemented as bpf program or as in-kernel c code.
David said the port can have arbitrary layers stacked on it. So if we
try to enumerate them before making forwarding decisions purely by BPF
program, it looks to me a loop is needed here.
Thanks
^ permalink raw reply
* Re: [PATCH stable 4.4 1/9] Revert "tcp: detect malicious patterns in tcp_collapse_ofo_queue()"
From: maowenan @ 2018-08-16 1:55 UTC (permalink / raw)
To: Greg KH; +Cc: dwmw2, netdev, eric.dumazet, edumazet, davem, ycheng, jdw
In-Reply-To: <20180815131807.GA31330@kroah.com>
On 2018/8/15 21:18, Greg KH wrote:
> On Wed, Aug 15, 2018 at 09:21:00PM +0800, Mao Wenan wrote:
>> This reverts commit dc6ae4dffd656811dee7151b19545e4cd839d378.
>
> I need a reason why, and a signed-off-by line :(
stable 4.4 only back port two patches to fix CVE-2018-5390, I have tested they can't
fix fully because of simple queue used in lower version, so we need change simple queue
to RB tree to finally resolve. But 9f5afeae have many conflicts with tcp: detect malicious patterns in tcp_collapse_ofo_queue()
and tcp: avoid collapses in tcp_prune_queue() if possible, and there are patch series from Eric in mainline to fix CVE-2018-5390,
so I need revert part of patches in stable 4.4 firstly, then apply 9f5afeae, and reapply five patches from Eric.
9f5afeae tcp: use an RB tree for ooo receive queue
>
> thanks,
>
> greg k-h
>
>
^ permalink raw reply
* [PATCH stable 4.4 1/9] Revert "tcp: detect malicious patterns in tcp_collapse_ofo_queue()"
From: Mao Wenan @ 2018-08-16 2:50 UTC (permalink / raw)
To: dwmw2, gregkh, netdev, eric.dumazet, edumazet, davem, ycheng, jdw; +Cc: stable
In-Reply-To: <1534387810-121428-1-git-send-email-maowenan@huawei.com>
This reverts commit dc6ae4dffd656811dee7151b19545e4cd839d378.
We need change simple queue to RB tree to finally fix CVE-2018-5390, So
revert this patch firstly because of many conflicts when we want to apply
previous patch 9f5afeae(tcp: use an RB tree for ooo receive queue), after
this we will reapply patch series from Eric.
Signed-off-by: Mao Wenan <maowenan@huawei.com>
---
net/ipv4/tcp_input.c | 16 ++--------------
1 file changed, 2 insertions(+), 14 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 4a261e0..995b2bc 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -4791,7 +4791,6 @@ restart:
static void tcp_collapse_ofo_queue(struct sock *sk)
{
struct tcp_sock *tp = tcp_sk(sk);
- u32 range_truesize, sum_tiny = 0;
struct sk_buff *skb = skb_peek(&tp->out_of_order_queue);
struct sk_buff *head;
u32 start, end;
@@ -4801,7 +4800,6 @@ static void tcp_collapse_ofo_queue(struct sock *sk)
start = TCP_SKB_CB(skb)->seq;
end = TCP_SKB_CB(skb)->end_seq;
- range_truesize = skb->truesize;
head = skb;
for (;;) {
@@ -4816,24 +4814,14 @@ static void tcp_collapse_ofo_queue(struct sock *sk)
if (!skb ||
after(TCP_SKB_CB(skb)->seq, end) ||
before(TCP_SKB_CB(skb)->end_seq, start)) {
- /* Do not attempt collapsing tiny skbs */
- if (range_truesize != head->truesize ||
- end - start >= SKB_WITH_OVERHEAD(SK_MEM_QUANTUM)) {
- tcp_collapse(sk, &tp->out_of_order_queue,
- head, skb, start, end);
- } else {
- sum_tiny += range_truesize;
- if (sum_tiny > sk->sk_rcvbuf >> 3)
- return;
- }
-
+ tcp_collapse(sk, &tp->out_of_order_queue,
+ head, skb, start, end);
head = skb;
if (!skb)
break;
/* Start new segment */
start = TCP_SKB_CB(skb)->seq;
end = TCP_SKB_CB(skb)->end_seq;
- range_truesize = skb->truesize;
} else {
if (before(TCP_SKB_CB(skb)->seq, start))
start = TCP_SKB_CB(skb)->seq;
--
1.8.3.1
^ permalink raw reply related
* [PATCH stable 4.4 2/9] Revert "tcp: avoid collapses in tcp_prune_queue() if possible"
From: Mao Wenan @ 2018-08-16 2:50 UTC (permalink / raw)
To: dwmw2, gregkh, netdev, eric.dumazet, edumazet, davem, ycheng, jdw; +Cc: stable
In-Reply-To: <1534387810-121428-1-git-send-email-maowenan@huawei.com>
This reverts commit 5fbec4801264cb3279ef6ac9c70bcbe2aaef89d5.
We need change simple queue to RB tree to finally fix CVE-2018-5390, So
revert this patch firstly because of many conflicts when we want to apply
previous patch 9f5afeae(tcp: use an RB tree for ooo receive queue), after
this we will reapply patch series from Eric.
Signed-off-by: Mao Wenan <maowenan@huawei.com>
---
net/ipv4/tcp_input.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 995b2bc..df2f342 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -4877,9 +4877,6 @@ static int tcp_prune_queue(struct sock *sk)
else if (tcp_under_memory_pressure(sk))
tp->rcv_ssthresh = min(tp->rcv_ssthresh, 4U * tp->advmss);
- if (atomic_read(&sk->sk_rmem_alloc) <= sk->sk_rcvbuf)
- return 0;
-
tcp_collapse_ofo_queue(sk);
if (!skb_queue_empty(&sk->sk_receive_queue))
tcp_collapse(sk, &sk->sk_receive_queue,
--
1.8.3.1
^ permalink raw reply related
* [PATCH stable 4.4 6/9] tcp: avoid collapses in tcp_prune_queue() if possible
From: Mao Wenan @ 2018-08-16 2:50 UTC (permalink / raw)
To: dwmw2, gregkh, netdev, eric.dumazet, edumazet, davem, ycheng, jdw; +Cc: stable
In-Reply-To: <1534387810-121428-1-git-send-email-maowenan@huawei.com>
From: Eric Dumazet <edumazet@google.com>
[ Upstream commit f4a3313d8e2ca9fd8d8f45e40a2903ba782607e7 ]
Right after a TCP flow is created, receiving tiny out of order
packets allways hit the condition :
if (atomic_read(&sk->sk_rmem_alloc) >= sk->sk_rcvbuf)
tcp_clamp_window(sk);
tcp_clamp_window() increases sk_rcvbuf to match sk_rmem_alloc
(guarded by tcp_rmem[2])
Calling tcp_collapse_ofo_queue() in this case is not useful,
and offers a O(N^2) surface attack to malicious peers.
Better not attempt anything before full queue capacity is reached,
forcing attacker to spend lots of resource and allow us to more
easily detect the abuse.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
Acked-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Mao Wenan <maowenan@huawei.com>
---
net/ipv4/tcp_input.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 32225dc..77130ae 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -4948,6 +4948,9 @@ static int tcp_prune_queue(struct sock *sk)
else if (tcp_under_memory_pressure(sk))
tp->rcv_ssthresh = min(tp->rcv_ssthresh, 4U * tp->advmss);
+ if (atomic_read(&sk->sk_rmem_alloc) <= sk->sk_rcvbuf)
+ return 0;
+
tcp_collapse_ofo_queue(sk);
if (!skb_queue_empty(&sk->sk_receive_queue))
tcp_collapse(sk, &sk->sk_receive_queue, NULL,
--
1.8.3.1
^ permalink raw reply related
* [PATCH stable 4.4 3/9] tcp: increment sk_drops for dropped rx packets
From: Mao Wenan @ 2018-08-16 2:50 UTC (permalink / raw)
To: dwmw2, gregkh, netdev, eric.dumazet, edumazet, davem, ycheng, jdw; +Cc: stable
In-Reply-To: <1534387810-121428-1-git-send-email-maowenan@huawei.com>
From: Eric Dumazet <edumazet@google.com>
[ Upstream commit 532182cd610782db8c18230c2747626562032205 ]
Now ss can report sk_drops, we can instruct TCP to increment
this per socket counter when it drops an incoming frame, to refine
monitoring and debugging.
Following patch takes care of listeners drops.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Mao Wenan <maowenan@huawei.com>
---
include/net/sock.h | 7 +++++++
net/ipv4/tcp_input.c | 33 ++++++++++++++++++++-------------
net/ipv4/tcp_ipv4.c | 1 +
net/ipv6/tcp_ipv6.c | 1 +
4 files changed, 29 insertions(+), 13 deletions(-)
diff --git a/include/net/sock.h b/include/net/sock.h
index 3d5ff74..5770757 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -2139,6 +2139,13 @@ sock_skb_set_dropcount(const struct sock *sk, struct sk_buff *skb)
SOCK_SKB_CB(skb)->dropcount = atomic_read(&sk->sk_drops);
}
+static inline void sk_drops_add(struct sock *sk, const struct sk_buff *skb)
+{
+ int segs = max_t(u16, 1, skb_shinfo(skb)->gso_segs);
+
+ atomic_add(segs, &sk->sk_drops);
+}
+
void __sock_recv_timestamp(struct msghdr *msg, struct sock *sk,
struct sk_buff *skb);
void __sock_recv_wifi_status(struct msghdr *msg, struct sock *sk,
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index df2f342..5fb4e80 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -4296,6 +4296,12 @@ static bool tcp_try_coalesce(struct sock *sk,
return true;
}
+static void tcp_drop(struct sock *sk, struct sk_buff *skb)
+{
+ sk_drops_add(sk, skb);
+ __kfree_skb(skb);
+}
+
/* This one checks to see if we can put data from the
* out_of_order queue into the receive_queue.
*/
@@ -4320,7 +4326,7 @@ static void tcp_ofo_queue(struct sock *sk)
__skb_unlink(skb, &tp->out_of_order_queue);
if (!after(TCP_SKB_CB(skb)->end_seq, tp->rcv_nxt)) {
SOCK_DEBUG(sk, "ofo packet was already received\n");
- __kfree_skb(skb);
+ tcp_drop(sk, skb);
continue;
}
SOCK_DEBUG(sk, "ofo requeuing : rcv_next %X seq %X - %X\n",
@@ -4372,7 +4378,7 @@ static void tcp_data_queue_ofo(struct sock *sk, struct sk_buff *skb)
if (unlikely(tcp_try_rmem_schedule(sk, skb, skb->truesize))) {
NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_TCPOFODROP);
- __kfree_skb(skb);
+ tcp_drop(sk, skb);
return;
}
@@ -4436,7 +4442,7 @@ static void tcp_data_queue_ofo(struct sock *sk, struct sk_buff *skb)
if (!after(end_seq, TCP_SKB_CB(skb1)->end_seq)) {
/* All the bits are present. Drop. */
NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_TCPOFOMERGE);
- __kfree_skb(skb);
+ tcp_drop(sk, skb);
skb = NULL;
tcp_dsack_set(sk, seq, end_seq);
goto add_sack;
@@ -4475,7 +4481,7 @@ static void tcp_data_queue_ofo(struct sock *sk, struct sk_buff *skb)
tcp_dsack_extend(sk, TCP_SKB_CB(skb1)->seq,
TCP_SKB_CB(skb1)->end_seq);
NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_TCPOFOMERGE);
- __kfree_skb(skb1);
+ tcp_drop(sk, skb1);
}
add_sack:
@@ -4558,12 +4564,13 @@ err:
static void tcp_data_queue(struct sock *sk, struct sk_buff *skb)
{
struct tcp_sock *tp = tcp_sk(sk);
- int eaten = -1;
bool fragstolen = false;
+ int eaten = -1;
- if (TCP_SKB_CB(skb)->seq == TCP_SKB_CB(skb)->end_seq)
- goto drop;
-
+ if (TCP_SKB_CB(skb)->seq == TCP_SKB_CB(skb)->end_seq) {
+ __kfree_skb(skb);
+ return;
+ }
skb_dst_drop(skb);
__skb_pull(skb, tcp_hdr(skb)->doff * 4);
@@ -4645,7 +4652,7 @@ out_of_window:
tcp_enter_quickack_mode(sk, TCP_MAX_QUICKACKS);
inet_csk_schedule_ack(sk);
drop:
- __kfree_skb(skb);
+ tcp_drop(sk, skb);
return;
}
@@ -5220,7 +5227,7 @@ syn_challenge:
return true;
discard:
- __kfree_skb(skb);
+ tcp_drop(sk, skb);
return false;
}
@@ -5438,7 +5445,7 @@ csum_error:
TCP_INC_STATS_BH(sock_net(sk), TCP_MIB_INERRS);
discard:
- __kfree_skb(skb);
+ tcp_drop(sk, skb);
}
EXPORT_SYMBOL(tcp_rcv_established);
@@ -5668,7 +5675,7 @@ static int tcp_rcv_synsent_state_process(struct sock *sk, struct sk_buff *skb,
TCP_DELACK_MAX, TCP_RTO_MAX);
discard:
- __kfree_skb(skb);
+ tcp_drop(sk, skb);
return 0;
} else {
tcp_send_ack(sk);
@@ -6025,7 +6032,7 @@ int tcp_rcv_state_process(struct sock *sk, struct sk_buff *skb)
if (!queued) {
discard:
- __kfree_skb(skb);
+ tcp_drop(sk, skb);
}
return 0;
}
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index eeda67c..01715fc 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -1716,6 +1716,7 @@ discard_it:
return 0;
discard_and_relse:
+ sk_drops_add(sk, skb);
sock_put(sk);
goto discard_it;
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index 90abe88..d6c1911 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -1505,6 +1505,7 @@ discard_it:
return 0;
discard_and_relse:
+ sk_drops_add(sk, skb);
sock_put(sk);
goto discard_it;
--
1.8.3.1
^ permalink raw reply related
* [PATCH stable 4.4 4/9] tcp: use an RB tree for ooo receive queue
From: Mao Wenan @ 2018-08-16 2:50 UTC (permalink / raw)
To: dwmw2, gregkh, netdev, eric.dumazet, edumazet, davem, ycheng, jdw; +Cc: stable
In-Reply-To: <1534387810-121428-1-git-send-email-maowenan@huawei.com>
From: Yaogong Wang <wygivan@google.com>
[ Upstream commit 9f5afeae51526b3ad7b7cb21ee8b145ce6ea7a7a ]
Over the years, TCP BDP has increased by several orders of magnitude,
and some people are considering to reach the 2 Gbytes limit.
Even with current window scale limit of 14, ~1 Gbytes maps to ~740,000
MSS.
In presence of packet losses (or reorders), TCP stores incoming packets
into an out of order queue, and number of skbs sitting there waiting for
the missing packets to be received can be in the 10^5 range.
Most packets are appended to the tail of this queue, and when
packets can finally be transferred to receive queue, we scan the queue
from its head.
However, in presence of heavy losses, we might have to find an arbitrary
point in this queue, involving a linear scan for every incoming packet,
throwing away cpu caches.
This patch converts it to a RB tree, to get bounded latencies.
Yaogong wrote a preliminary patch about 2 years ago.
Eric did the rebase, added ofo_last_skb cache, polishing and tests.
Tested with network dropping between 1 and 10 % packets, with good
success (about 30 % increase of throughput in stress tests)
Next step would be to also use an RB tree for the write queue at sender
side ;)
Signed-off-by: Yaogong Wang <wygivan@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Yuchung Cheng <ycheng@google.com>
Cc: Neal Cardwell <ncardwell@google.com>
Cc: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
Acked-By: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Mao Wenan <maowenan@huawei.com>
---
include/linux/skbuff.h | 8 ++
include/linux/tcp.h | 7 +-
include/net/tcp.h | 2 +-
net/core/skbuff.c | 19 +++
net/ipv4/tcp.c | 4 +-
net/ipv4/tcp_input.c | 354 +++++++++++++++++++++++++++--------------------
net/ipv4/tcp_ipv4.c | 2 +-
net/ipv4/tcp_minisocks.c | 1 -
8 files changed, 241 insertions(+), 156 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index c28bd8b..a490dd7 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -2273,6 +2273,8 @@ static inline void __skb_queue_purge(struct sk_buff_head *list)
kfree_skb(skb);
}
+void skb_rbtree_purge(struct rb_root *root);
+
void *netdev_alloc_frag(unsigned int fragsz);
struct sk_buff *__netdev_alloc_skb(struct net_device *dev, unsigned int length,
@@ -2807,6 +2809,12 @@ static inline int pskb_trim_rcsum(struct sk_buff *skb, unsigned int len)
return __pskb_trim(skb, len);
}
+#define rb_to_skb(rb) rb_entry_safe(rb, struct sk_buff, rbnode)
+#define skb_rb_first(root) rb_to_skb(rb_first(root))
+#define skb_rb_last(root) rb_to_skb(rb_last(root))
+#define skb_rb_next(skb) rb_to_skb(rb_next(&(skb)->rbnode))
+#define skb_rb_prev(skb) rb_to_skb(rb_prev(&(skb)->rbnode))
+
#define skb_queue_walk(queue, skb) \
for (skb = (queue)->next; \
skb != (struct sk_buff *)(queue); \
diff --git a/include/linux/tcp.h b/include/linux/tcp.h
index 5b6df1a..747404d 100644
--- a/include/linux/tcp.h
+++ b/include/linux/tcp.h
@@ -279,10 +279,9 @@ struct tcp_sock {
struct sk_buff* lost_skb_hint;
struct sk_buff *retransmit_skb_hint;
- /* OOO segments go in this list. Note that socket lock must be held,
- * as we do not use sk_buff_head lock.
- */
- struct sk_buff_head out_of_order_queue;
+ /* OOO segments go in this rbtree. Socket lock must be held. */
+ struct rb_root out_of_order_queue;
+ struct sk_buff *ooo_last_skb; /* cache rb_last(out_of_order_queue) */
/* SACKs data, these 2 need to be together (see tcp_options_write) */
struct tcp_sack_block duplicate_sack[1]; /* D-SACK block */
diff --git a/include/net/tcp.h b/include/net/tcp.h
index cac4a6ad..8bc259d 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -649,7 +649,7 @@ static inline void tcp_fast_path_check(struct sock *sk)
{
struct tcp_sock *tp = tcp_sk(sk);
- if (skb_queue_empty(&tp->out_of_order_queue) &&
+ if (RB_EMPTY_ROOT(&tp->out_of_order_queue) &&
tp->rcv_wnd &&
atomic_read(&sk->sk_rmem_alloc) < sk->sk_rcvbuf &&
!tp->urg_data)
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 55be076..9703924 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -2378,6 +2378,25 @@ void skb_queue_purge(struct sk_buff_head *list)
EXPORT_SYMBOL(skb_queue_purge);
/**
+ * skb_rbtree_purge - empty a skb rbtree
+ * @root: root of the rbtree to empty
+ *
+ * Delete all buffers on an &sk_buff rbtree. Each buffer is removed from
+ * the list and one reference dropped. This function does not take
+ * any lock. Synchronization should be handled by the caller (e.g., TCP
+ * out-of-order queue is protected by the socket lock).
+ */
+void skb_rbtree_purge(struct rb_root *root)
+{
+ struct sk_buff *skb, *next;
+
+ rbtree_postorder_for_each_entry_safe(skb, next, root, rbnode)
+ kfree_skb(skb);
+
+ *root = RB_ROOT;
+}
+
+/**
* skb_queue_head - queue a buffer at the list head
* @list: list to use
* @newsk: buffer to queue
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index a0f0a7d..8bd2874 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -382,7 +382,7 @@ void tcp_init_sock(struct sock *sk)
struct inet_connection_sock *icsk = inet_csk(sk);
struct tcp_sock *tp = tcp_sk(sk);
- __skb_queue_head_init(&tp->out_of_order_queue);
+ tp->out_of_order_queue = RB_ROOT;
tcp_init_xmit_timers(sk);
tcp_prequeue_init(tp);
INIT_LIST_HEAD(&tp->tsq_node);
@@ -2240,7 +2240,7 @@ int tcp_disconnect(struct sock *sk, int flags)
tcp_clear_xmit_timers(sk);
__skb_queue_purge(&sk->sk_receive_queue);
tcp_write_queue_purge(sk);
- __skb_queue_purge(&tp->out_of_order_queue);
+ skb_rbtree_purge(&tp->out_of_order_queue);
inet->inet_dport = 0;
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 5fb4e80..12edc4f 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -4073,7 +4073,7 @@ static void tcp_fin(struct sock *sk)
/* It _is_ possible, that we have something out-of-order _after_ FIN.
* Probably, we should reset in this case. For now drop them.
*/
- __skb_queue_purge(&tp->out_of_order_queue);
+ skb_rbtree_purge(&tp->out_of_order_queue);
if (tcp_is_sack(tp))
tcp_sack_reset(&tp->rx_opt);
sk_mem_reclaim(sk);
@@ -4233,7 +4233,7 @@ static void tcp_sack_remove(struct tcp_sock *tp)
int this_sack;
/* Empty ofo queue, hence, all the SACKs are eaten. Clear. */
- if (skb_queue_empty(&tp->out_of_order_queue)) {
+ if (RB_EMPTY_ROOT(&tp->out_of_order_queue)) {
tp->rx_opt.num_sacks = 0;
return;
}
@@ -4309,10 +4309,13 @@ static void tcp_ofo_queue(struct sock *sk)
{
struct tcp_sock *tp = tcp_sk(sk);
__u32 dsack_high = tp->rcv_nxt;
+ bool fin, fragstolen, eaten;
struct sk_buff *skb, *tail;
- bool fragstolen, eaten;
+ struct rb_node *p;
- while ((skb = skb_peek(&tp->out_of_order_queue)) != NULL) {
+ p = rb_first(&tp->out_of_order_queue);
+ while (p) {
+ skb = rb_entry(p, struct sk_buff, rbnode);
if (after(TCP_SKB_CB(skb)->seq, tp->rcv_nxt))
break;
@@ -4322,9 +4325,10 @@ static void tcp_ofo_queue(struct sock *sk)
dsack_high = TCP_SKB_CB(skb)->end_seq;
tcp_dsack_extend(sk, TCP_SKB_CB(skb)->seq, dsack);
}
+ p = rb_next(p);
+ rb_erase(&skb->rbnode, &tp->out_of_order_queue);
- __skb_unlink(skb, &tp->out_of_order_queue);
- if (!after(TCP_SKB_CB(skb)->end_seq, tp->rcv_nxt)) {
+ if (unlikely(!after(TCP_SKB_CB(skb)->end_seq, tp->rcv_nxt))) {
SOCK_DEBUG(sk, "ofo packet was already received\n");
tcp_drop(sk, skb);
continue;
@@ -4336,12 +4340,19 @@ static void tcp_ofo_queue(struct sock *sk)
tail = skb_peek_tail(&sk->sk_receive_queue);
eaten = tail && tcp_try_coalesce(sk, tail, skb, &fragstolen);
tcp_rcv_nxt_update(tp, TCP_SKB_CB(skb)->end_seq);
+ fin = TCP_SKB_CB(skb)->tcp_flags & TCPHDR_FIN;
if (!eaten)
__skb_queue_tail(&sk->sk_receive_queue, skb);
- if (TCP_SKB_CB(skb)->tcp_flags & TCPHDR_FIN)
- tcp_fin(sk);
- if (eaten)
+ else
kfree_skb_partial(skb, fragstolen);
+
+ if (unlikely(fin)) {
+ tcp_fin(sk);
+ /* tcp_fin() purges tp->out_of_order_queue,
+ * so we must end this loop right now.
+ */
+ break;
+ }
}
}
@@ -4371,8 +4382,10 @@ static int tcp_try_rmem_schedule(struct sock *sk, struct sk_buff *skb,
static void tcp_data_queue_ofo(struct sock *sk, struct sk_buff *skb)
{
struct tcp_sock *tp = tcp_sk(sk);
+ struct rb_node **p, *q, *parent;
struct sk_buff *skb1;
u32 seq, end_seq;
+ bool fragstolen;
tcp_ecn_check_ce(sk, skb);
@@ -4387,88 +4400,86 @@ static void tcp_data_queue_ofo(struct sock *sk, struct sk_buff *skb)
inet_csk_schedule_ack(sk);
NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_TCPOFOQUEUE);
+ seq = TCP_SKB_CB(skb)->seq;
+ end_seq = TCP_SKB_CB(skb)->end_seq;
SOCK_DEBUG(sk, "out of order segment: rcv_next %X seq %X - %X\n",
- tp->rcv_nxt, TCP_SKB_CB(skb)->seq, TCP_SKB_CB(skb)->end_seq);
+ tp->rcv_nxt, seq, end_seq);
- skb1 = skb_peek_tail(&tp->out_of_order_queue);
- if (!skb1) {
+ p = &tp->out_of_order_queue.rb_node;
+ if (RB_EMPTY_ROOT(&tp->out_of_order_queue)) {
/* Initial out of order segment, build 1 SACK. */
if (tcp_is_sack(tp)) {
tp->rx_opt.num_sacks = 1;
- tp->selective_acks[0].start_seq = TCP_SKB_CB(skb)->seq;
- tp->selective_acks[0].end_seq =
- TCP_SKB_CB(skb)->end_seq;
+ tp->selective_acks[0].start_seq = seq;
+ tp->selective_acks[0].end_seq = end_seq;
}
- __skb_queue_head(&tp->out_of_order_queue, skb);
+ rb_link_node(&skb->rbnode, NULL, p);
+ rb_insert_color(&skb->rbnode, &tp->out_of_order_queue);
+ tp->ooo_last_skb = skb;
goto end;
}
- seq = TCP_SKB_CB(skb)->seq;
- end_seq = TCP_SKB_CB(skb)->end_seq;
-
- if (seq == TCP_SKB_CB(skb1)->end_seq) {
- bool fragstolen;
-
- if (!tcp_try_coalesce(sk, skb1, skb, &fragstolen)) {
- __skb_queue_after(&tp->out_of_order_queue, skb1, skb);
- } else {
- tcp_grow_window(sk, skb);
- kfree_skb_partial(skb, fragstolen);
- skb = NULL;
+ /* In the typical case, we are adding an skb to the end of the list.
+ * Use of ooo_last_skb avoids the O(Log(N)) rbtree lookup.
+ */
+ if (tcp_try_coalesce(sk, tp->ooo_last_skb, skb, &fragstolen)) {
+coalesce_done:
+ tcp_grow_window(sk, skb);
+ kfree_skb_partial(skb, fragstolen);
+ skb = NULL;
+ goto add_sack;
+ }
+
+ /* Find place to insert this segment. Handle overlaps on the way. */
+ parent = NULL;
+ while (*p) {
+ parent = *p;
+ skb1 = rb_entry(parent, struct sk_buff, rbnode);
+ if (before(seq, TCP_SKB_CB(skb1)->seq)) {
+ p = &parent->rb_left;
+ continue;
}
- if (!tp->rx_opt.num_sacks ||
- tp->selective_acks[0].end_seq != seq)
- goto add_sack;
-
- /* Common case: data arrive in order after hole. */
- tp->selective_acks[0].end_seq = end_seq;
- goto end;
- }
-
- /* Find place to insert this segment. */
- while (1) {
- if (!after(TCP_SKB_CB(skb1)->seq, seq))
- break;
- if (skb_queue_is_first(&tp->out_of_order_queue, skb1)) {
- skb1 = NULL;
- break;
+ if (before(seq, TCP_SKB_CB(skb1)->end_seq)) {
+ if (!after(end_seq, TCP_SKB_CB(skb1)->end_seq)) {
+ /* All the bits are present. Drop. */
+ NET_INC_STATS(sock_net(sk),
+ LINUX_MIB_TCPOFOMERGE);
+ __kfree_skb(skb);
+ skb = NULL;
+ tcp_dsack_set(sk, seq, end_seq);
+ goto add_sack;
+ }
+ if (after(seq, TCP_SKB_CB(skb1)->seq)) {
+ /* Partial overlap. */
+ tcp_dsack_set(sk, seq, TCP_SKB_CB(skb1)->end_seq);
+ } else {
+ /* skb's seq == skb1's seq and skb covers skb1.
+ * Replace skb1 with skb.
+ */
+ rb_replace_node(&skb1->rbnode, &skb->rbnode,
+ &tp->out_of_order_queue);
+ tcp_dsack_extend(sk,
+ TCP_SKB_CB(skb1)->seq,
+ TCP_SKB_CB(skb1)->end_seq);
+ NET_INC_STATS(sock_net(sk),
+ LINUX_MIB_TCPOFOMERGE);
+ __kfree_skb(skb1);
+ goto add_sack;
+ }
+ } else if (tcp_try_coalesce(sk, skb1, skb, &fragstolen)) {
+ goto coalesce_done;
}
- skb1 = skb_queue_prev(&tp->out_of_order_queue, skb1);
+ p = &parent->rb_right;
}
- /* Do skb overlap to previous one? */
- if (skb1 && before(seq, TCP_SKB_CB(skb1)->end_seq)) {
- if (!after(end_seq, TCP_SKB_CB(skb1)->end_seq)) {
- /* All the bits are present. Drop. */
- NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_TCPOFOMERGE);
- tcp_drop(sk, skb);
- skb = NULL;
- tcp_dsack_set(sk, seq, end_seq);
- goto add_sack;
- }
- if (after(seq, TCP_SKB_CB(skb1)->seq)) {
- /* Partial overlap. */
- tcp_dsack_set(sk, seq,
- TCP_SKB_CB(skb1)->end_seq);
- } else {
- if (skb_queue_is_first(&tp->out_of_order_queue,
- skb1))
- skb1 = NULL;
- else
- skb1 = skb_queue_prev(
- &tp->out_of_order_queue,
- skb1);
- }
- }
- if (!skb1)
- __skb_queue_head(&tp->out_of_order_queue, skb);
- else
- __skb_queue_after(&tp->out_of_order_queue, skb1, skb);
+ /* Insert segment into RB tree. */
+ rb_link_node(&skb->rbnode, parent, p);
+ rb_insert_color(&skb->rbnode, &tp->out_of_order_queue);
- /* And clean segments covered by new one as whole. */
- while (!skb_queue_is_last(&tp->out_of_order_queue, skb)) {
- skb1 = skb_queue_next(&tp->out_of_order_queue, skb);
+ /* Remove other segments covered by skb. */
+ while ((q = rb_next(&skb->rbnode)) != NULL) {
+ skb1 = rb_entry(q, struct sk_buff, rbnode);
if (!after(end_seq, TCP_SKB_CB(skb1)->seq))
break;
@@ -4477,12 +4488,15 @@ static void tcp_data_queue_ofo(struct sock *sk, struct sk_buff *skb)
end_seq);
break;
}
- __skb_unlink(skb1, &tp->out_of_order_queue);
+ rb_erase(&skb1->rbnode, &tp->out_of_order_queue);
tcp_dsack_extend(sk, TCP_SKB_CB(skb1)->seq,
TCP_SKB_CB(skb1)->end_seq);
NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_TCPOFOMERGE);
tcp_drop(sk, skb1);
}
+ /* If there is no skb after us, we are the last_skb ! */
+ if (!q)
+ tp->ooo_last_skb = skb;
add_sack:
if (tcp_is_sack(tp))
@@ -4621,13 +4635,13 @@ queue_and_out:
if (TCP_SKB_CB(skb)->tcp_flags & TCPHDR_FIN)
tcp_fin(sk);
- if (!skb_queue_empty(&tp->out_of_order_queue)) {
+ if (!RB_EMPTY_ROOT(&tp->out_of_order_queue)) {
tcp_ofo_queue(sk);
/* RFC2581. 4.2. SHOULD send immediate ACK, when
* gap in queue is filled.
*/
- if (skb_queue_empty(&tp->out_of_order_queue))
+ if (RB_EMPTY_ROOT(&tp->out_of_order_queue))
inet_csk(sk)->icsk_ack.pingpong = 0;
}
@@ -4679,48 +4693,76 @@ drop:
tcp_data_queue_ofo(sk, skb);
}
+static struct sk_buff *tcp_skb_next(struct sk_buff *skb, struct sk_buff_head *list)
+{
+ if (list)
+ return !skb_queue_is_last(list, skb) ? skb->next : NULL;
+
+ return rb_entry_safe(rb_next(&skb->rbnode), struct sk_buff, rbnode);
+}
+
static struct sk_buff *tcp_collapse_one(struct sock *sk, struct sk_buff *skb,
- struct sk_buff_head *list)
+ struct sk_buff_head *list,
+ struct rb_root *root)
{
- struct sk_buff *next = NULL;
+ struct sk_buff *next = tcp_skb_next(skb, list);
- if (!skb_queue_is_last(list, skb))
- next = skb_queue_next(list, skb);
+ if (list)
+ __skb_unlink(skb, list);
+ else
+ rb_erase(&skb->rbnode, root);
- __skb_unlink(skb, list);
__kfree_skb(skb);
NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_TCPRCVCOLLAPSED);
return next;
}
+/* Insert skb into rb tree, ordered by TCP_SKB_CB(skb)->seq */
+static void tcp_rbtree_insert(struct rb_root *root, struct sk_buff *skb)
+{
+ struct rb_node **p = &root->rb_node;
+ struct rb_node *parent = NULL;
+ struct sk_buff *skb1;
+
+ while (*p) {
+ parent = *p;
+ skb1 = rb_entry(parent, struct sk_buff, rbnode);
+ if (before(TCP_SKB_CB(skb)->seq, TCP_SKB_CB(skb1)->seq))
+ p = &parent->rb_left;
+ else
+ p = &parent->rb_right;
+ }
+ rb_link_node(&skb->rbnode, parent, p);
+ rb_insert_color(&skb->rbnode, root);
+}
+
/* Collapse contiguous sequence of skbs head..tail with
* sequence numbers start..end.
*
- * If tail is NULL, this means until the end of the list.
+ * If tail is NULL, this means until the end of the queue.
*
* Segments with FIN/SYN are not collapsed (only because this
* simplifies code)
*/
static void
-tcp_collapse(struct sock *sk, struct sk_buff_head *list,
- struct sk_buff *head, struct sk_buff *tail,
- u32 start, u32 end)
+tcp_collapse(struct sock *sk, struct sk_buff_head *list, struct rb_root *root,
+ struct sk_buff *head, struct sk_buff *tail, u32 start, u32 end)
{
- struct sk_buff *skb, *n;
+ struct sk_buff *skb = head, *n;
+ struct sk_buff_head tmp;
bool end_of_skbs;
/* First, check that queue is collapsible and find
- * the point where collapsing can be useful. */
- skb = head;
+ * the point where collapsing can be useful.
+ */
restart:
- end_of_skbs = true;
- skb_queue_walk_from_safe(list, skb, n) {
- if (skb == tail)
- break;
+ for (end_of_skbs = true; skb != NULL && skb != tail; skb = n) {
+ n = tcp_skb_next(skb, list);
+
/* No new bits? It is possible on ofo queue. */
if (!before(start, TCP_SKB_CB(skb)->end_seq)) {
- skb = tcp_collapse_one(sk, skb, list);
+ skb = tcp_collapse_one(sk, skb, list, root);
if (!skb)
break;
goto restart;
@@ -4738,13 +4780,10 @@ restart:
break;
}
- if (!skb_queue_is_last(list, skb)) {
- struct sk_buff *next = skb_queue_next(list, skb);
- if (next != tail &&
- TCP_SKB_CB(skb)->end_seq != TCP_SKB_CB(next)->seq) {
- end_of_skbs = false;
- break;
- }
+ if (n && n != tail &&
+ TCP_SKB_CB(skb)->end_seq != TCP_SKB_CB(n)->seq) {
+ end_of_skbs = false;
+ break;
}
/* Decided to skip this, advance start seq. */
@@ -4754,17 +4793,22 @@ restart:
(TCP_SKB_CB(skb)->tcp_flags & (TCPHDR_SYN | TCPHDR_FIN)))
return;
+ __skb_queue_head_init(&tmp);
+
while (before(start, end)) {
int copy = min_t(int, SKB_MAX_ORDER(0, 0), end - start);
struct sk_buff *nskb;
nskb = alloc_skb(copy, GFP_ATOMIC);
if (!nskb)
- return;
+ break;
memcpy(nskb->cb, skb->cb, sizeof(skb->cb));
TCP_SKB_CB(nskb)->seq = TCP_SKB_CB(nskb)->end_seq = start;
- __skb_queue_before(list, skb, nskb);
+ if (list)
+ __skb_queue_before(list, skb, nskb);
+ else
+ __skb_queue_tail(&tmp, nskb); /* defer rbtree insertion */
skb_set_owner_r(nskb, sk);
/* Copy data, releasing collapsed skbs. */
@@ -4782,14 +4826,17 @@ restart:
start += size;
}
if (!before(start, TCP_SKB_CB(skb)->end_seq)) {
- skb = tcp_collapse_one(sk, skb, list);
+ skb = tcp_collapse_one(sk, skb, list, root);
if (!skb ||
skb == tail ||
(TCP_SKB_CB(skb)->tcp_flags & (TCPHDR_SYN | TCPHDR_FIN)))
- return;
+ goto end;
}
}
}
+end:
+ skb_queue_walk_safe(&tmp, skb, n)
+ tcp_rbtree_insert(root, skb);
}
/* Collapse ofo queue. Algorithm: select contiguous sequence of skbs
@@ -4798,43 +4845,43 @@ restart:
static void tcp_collapse_ofo_queue(struct sock *sk)
{
struct tcp_sock *tp = tcp_sk(sk);
- struct sk_buff *skb = skb_peek(&tp->out_of_order_queue);
- struct sk_buff *head;
+ struct sk_buff *skb, *head;
+ struct rb_node *p;
u32 start, end;
- if (!skb)
+ p = rb_first(&tp->out_of_order_queue);
+ skb = rb_entry_safe(p, struct sk_buff, rbnode);
+new_range:
+ if (!skb) {
+ p = rb_last(&tp->out_of_order_queue);
+ /* Note: This is possible p is NULL here. We do not
+ * use rb_entry_safe(), as ooo_last_skb is valid only
+ * if rbtree is not empty.
+ */
+ tp->ooo_last_skb = rb_entry(p, struct sk_buff, rbnode);
return;
-
+ }
start = TCP_SKB_CB(skb)->seq;
end = TCP_SKB_CB(skb)->end_seq;
- head = skb;
-
- for (;;) {
- struct sk_buff *next = NULL;
- if (!skb_queue_is_last(&tp->out_of_order_queue, skb))
- next = skb_queue_next(&tp->out_of_order_queue, skb);
- skb = next;
+ for (head = skb;;) {
+ skb = tcp_skb_next(skb, NULL);
- /* Segment is terminated when we see gap or when
- * we are at the end of all the queue. */
+ /* Range is terminated when we see a gap or when
+ * we are at the queue end.
+ */
if (!skb ||
after(TCP_SKB_CB(skb)->seq, end) ||
before(TCP_SKB_CB(skb)->end_seq, start)) {
- tcp_collapse(sk, &tp->out_of_order_queue,
+ tcp_collapse(sk, NULL, &tp->out_of_order_queue,
head, skb, start, end);
- head = skb;
- if (!skb)
- break;
- /* Start new segment */
+ goto new_range;
+ }
+
+ if (unlikely(before(TCP_SKB_CB(skb)->seq, start)))
start = TCP_SKB_CB(skb)->seq;
+ if (after(TCP_SKB_CB(skb)->end_seq, end))
end = TCP_SKB_CB(skb)->end_seq;
- } else {
- if (before(TCP_SKB_CB(skb)->seq, start))
- start = TCP_SKB_CB(skb)->seq;
- if (after(TCP_SKB_CB(skb)->end_seq, end))
- end = TCP_SKB_CB(skb)->end_seq;
- }
}
}
@@ -4845,23 +4892,36 @@ static void tcp_collapse_ofo_queue(struct sock *sk)
static bool tcp_prune_ofo_queue(struct sock *sk)
{
struct tcp_sock *tp = tcp_sk(sk);
- bool res = false;
+ struct rb_node *node, *prev;
- if (!skb_queue_empty(&tp->out_of_order_queue)) {
- NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_OFOPRUNED);
- __skb_queue_purge(&tp->out_of_order_queue);
+ if (RB_EMPTY_ROOT(&tp->out_of_order_queue))
+ return false;
- /* Reset SACK state. A conforming SACK implementation will
- * do the same at a timeout based retransmit. When a connection
- * is in a sad state like this, we care only about integrity
- * of the connection not performance.
- */
- if (tp->rx_opt.sack_ok)
- tcp_sack_reset(&tp->rx_opt);
+ NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_OFOPRUNED);
+
+ node = &tp->ooo_last_skb->rbnode;
+ do {
+ prev = rb_prev(node);
+ rb_erase(node, &tp->out_of_order_queue);
+ __kfree_skb(rb_to_skb(node));
sk_mem_reclaim(sk);
- res = true;
- }
- return res;
+ if (atomic_read(&sk->sk_rmem_alloc) <= sk->sk_rcvbuf &&
+ !tcp_under_memory_pressure(sk))
+ break;
+
+ node = prev;
+ } while (node);
+ tp->ooo_last_skb = rb_entry(prev, struct sk_buff, rbnode);
+
+ /* Reset SACK state. A conforming SACK implementation will
+ * do the same at a timeout based retransmit. When a connection
+ * is in a sad state like this, we care only about integrity
+ * of the connection not performance.
+ */
+ if (tp->rx_opt.sack_ok)
+ tcp_sack_reset(&tp->rx_opt);
+
+ return true;
}
/* Reduce allocated memory if we can, trying to get
@@ -4886,7 +4946,7 @@ static int tcp_prune_queue(struct sock *sk)
tcp_collapse_ofo_queue(sk);
if (!skb_queue_empty(&sk->sk_receive_queue))
- tcp_collapse(sk, &sk->sk_receive_queue,
+ tcp_collapse(sk, &sk->sk_receive_queue, NULL,
skb_peek(&sk->sk_receive_queue),
NULL,
tp->copied_seq, tp->rcv_nxt);
@@ -4991,7 +5051,7 @@ static void __tcp_ack_snd_check(struct sock *sk, int ofo_possible)
/* We ACK each frame or... */
tcp_in_quickack_mode(sk) ||
/* We have out of order data. */
- (ofo_possible && skb_peek(&tp->out_of_order_queue))) {
+ (ofo_possible && !RB_EMPTY_ROOT(&tp->out_of_order_queue))) {
/* Then ack it now */
tcp_send_ack(sk);
} else {
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 01715fc..ee8399f 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -1830,7 +1830,7 @@ void tcp_v4_destroy_sock(struct sock *sk)
tcp_write_queue_purge(sk);
/* Cleans up our, hopefully empty, out_of_order_queue. */
- __skb_queue_purge(&tp->out_of_order_queue);
+ skb_rbtree_purge(&tp->out_of_order_queue);
#ifdef CONFIG_TCP_MD5SIG
/* Clean up the MD5 key list, if any */
diff --git a/net/ipv4/tcp_minisocks.c b/net/ipv4/tcp_minisocks.c
index 4c1c94f..81c633d 100644
--- a/net/ipv4/tcp_minisocks.c
+++ b/net/ipv4/tcp_minisocks.c
@@ -495,7 +495,6 @@ struct sock *tcp_create_openreq_child(const struct sock *sk,
newtp->snd_cwnd_cnt = 0;
tcp_init_xmit_timers(newsk);
- __skb_queue_head_init(&newtp->out_of_order_queue);
newtp->write_seq = newtp->pushed_seq = treq->snt_isn + 1;
newtp->rx_opt.saw_tstamp = 0;
--
1.8.3.1
^ permalink raw reply related
* [PATCH stable 4.4 8/9] tcp: call tcp_drop() from tcp_data_queue_ofo()
From: Mao Wenan @ 2018-08-16 2:50 UTC (permalink / raw)
To: dwmw2, gregkh, netdev, eric.dumazet, edumazet, davem, ycheng, jdw; +Cc: stable
In-Reply-To: <1534387810-121428-1-git-send-email-maowenan@huawei.com>
From: Eric Dumazet <edumazet@google.com>
[ Upstream commit 8541b21e781a22dce52a74fef0b9bed00404a1cd ]
In order to be able to give better diagnostics and detect
malicious traffic, we need to have better sk->sk_drops tracking.
Fixes: 9f5afeae5152 ("tcp: use an RB tree for ooo receive queue")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
Acked-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Mao Wenan <maowenan@huawei.com>
---
net/ipv4/tcp_input.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index c48924f..96a1e0d 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -4445,7 +4445,7 @@ coalesce_done:
/* All the bits are present. Drop. */
NET_INC_STATS(sock_net(sk),
LINUX_MIB_TCPOFOMERGE);
- __kfree_skb(skb);
+ tcp_drop(sk, skb);
skb = NULL;
tcp_dsack_set(sk, seq, end_seq);
goto add_sack;
@@ -4464,7 +4464,7 @@ coalesce_done:
TCP_SKB_CB(skb1)->end_seq);
NET_INC_STATS(sock_net(sk),
LINUX_MIB_TCPOFOMERGE);
- __kfree_skb(skb1);
+ tcp_drop(sk, skb1);
goto add_sack;
}
} else if (tcp_try_coalesce(sk, skb1, skb, &fragstolen)) {
--
1.8.3.1
^ permalink raw reply related
* [PATCH stable 4.4 7/9] tcp: detect malicious patterns in tcp_collapse_ofo_queue()
From: Mao Wenan @ 2018-08-16 2:50 UTC (permalink / raw)
To: dwmw2, gregkh, netdev, eric.dumazet, edumazet, davem, ycheng, jdw; +Cc: stable
In-Reply-To: <1534387810-121428-1-git-send-email-maowenan@huawei.com>
From: Eric Dumazet <edumazet@google.com>
[ Upstream commit 3d4bf93ac12003f9b8e1e2de37fe27983deebdcf ]
In case an attacker feeds tiny packets completely out of order,
tcp_collapse_ofo_queue() might scan the whole rb-tree, performing
expensive copies, but not changing socket memory usage at all.
1) Do not attempt to collapse tiny skbs.
2) Add logic to exit early when too many tiny skbs are detected.
We prefer not doing aggressive collapsing (which copies packets)
for pathological flows, and revert to tcp_prune_ofo_queue() which
will be less expensive.
In the future, we might add the possibility of terminating flows
that are proven to be malicious.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Mao Wenan <maowenan@huawei.com>
---
net/ipv4/tcp_input.c | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 77130ae..c48924f 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -4845,6 +4845,7 @@ end:
static void tcp_collapse_ofo_queue(struct sock *sk)
{
struct tcp_sock *tp = tcp_sk(sk);
+ u32 range_truesize, sum_tiny = 0;
struct sk_buff *skb, *head;
struct rb_node *p;
u32 start, end;
@@ -4863,6 +4864,7 @@ new_range:
}
start = TCP_SKB_CB(skb)->seq;
end = TCP_SKB_CB(skb)->end_seq;
+ range_truesize = skb->truesize;
for (head = skb;;) {
skb = tcp_skb_next(skb, NULL);
@@ -4873,11 +4875,21 @@ new_range:
if (!skb ||
after(TCP_SKB_CB(skb)->seq, end) ||
before(TCP_SKB_CB(skb)->end_seq, start)) {
- tcp_collapse(sk, NULL, &tp->out_of_order_queue,
- head, skb, start, end);
+ /* Do not attempt collapsing tiny skbs */
+ if (range_truesize != head->truesize ||
+ end - start >= SKB_WITH_OVERHEAD(SK_MEM_QUANTUM)) {
+ tcp_collapse(sk, NULL, &tp->out_of_order_queue,
+ head, skb, start, end);
+ } else {
+ sum_tiny += range_truesize;
+ if (sum_tiny > sk->sk_rcvbuf >> 3)
+ return;
+ }
+
goto new_range;
}
+ range_truesize += skb->truesize;
if (unlikely(before(TCP_SKB_CB(skb)->seq, start)))
start = TCP_SKB_CB(skb)->seq;
if (after(TCP_SKB_CB(skb)->end_seq, end))
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH stable 4.4 0/9] fix SegmentSmack in stable branch (CVE-2018-5390)
From: Michal Kubecek @ 2018-08-16 6:16 UTC (permalink / raw)
To: Mao Wenan
Cc: dwmw2, gregkh, netdev, eric.dumazet, edumazet, davem, ycheng, jdw,
stable, Takashi Iwai
In-Reply-To: <1534387810-121428-1-git-send-email-maowenan@huawei.com>
On Thu, Aug 16, 2018 at 10:50:01AM +0800, Mao Wenan wrote:
> There are five patches to fix CVE-2018-5390 in latest mainline
> branch, but only two patches exist in stable 4.4 and 3.18:
> dc6ae4d tcp: detect malicious patterns in tcp_collapse_ofo_queue()
> 5fbec48 tcp: avoid collapses in tcp_prune_queue() if possible
> I have tested with stable 4.4 kernel, and found the cpu usage was very high.
> So I think only two patches can't fix the CVE-2018-5390.
> test results:
> with fix patch： 78.2% ksoftirqd
> withoutfix patch： 90% ksoftirqd
>
> Then I try to imitate 72cd43ba(tcp: free batches of packets in tcp_prune_ofo_queue())
> to drop at least 12.5 % of sk_rcvbuf to avoid malicious attacks with simple queue
> instead of RB tree. The result is not very well.
>
> After analysing the codes of stable 4.4, and debuging the
> system, shows that search of ofo_queue(tcp ofo using a simple queue) cost more cycles.
>
> So I try to backport "tcp: use an RB tree for ooo receive queue" using RB tree
> instead of simple queue, then backport Eric Dumazet 5 fixed patches in mainline,
> good news is that ksoftirqd is turn to about 20%, which is the same with mainline now.
>
> Stable 4.4 have already back port two patches,
> f4a3313d(tcp: avoid collapses in tcp_prune_queue() if possible)
> 3d4bf93a(tcp: detect malicious patterns in tcp_collapse_ofo_queue())
> If we want to change simple queue to RB tree to finally resolve, we should apply previous
> patch 9f5afeae(tcp: use an RB tree for ooo receive queue.) firstly, but 9f5afeae have many
> conflicts with 3d4bf93a and f4a3313d, which are part of patch series from Eric in
> mainline to fix CVE-2018-5390, so I need revert part of patches in stable 4.4 firstly,
> then apply 9f5afeae, and reapply five patches from Eric.
There seems to be an obvious mistake in one of the backports. Could you
check the results with Takashi's follow-up fix submitted at
http://lkml.kernel.org/r/20180815095846.7734-1-tiwai@suse.de
(I would try myself but you don't mention what test you ran.)
Michal Kubecek
^ permalink raw reply
* Re: [PATCH stable 4.4 0/9] fix SegmentSmack in stable branch (CVE-2018-5390)
From: maowenan @ 2018-08-16 6:42 UTC (permalink / raw)
To: Michal Kubecek
Cc: dwmw2, gregkh, netdev, eric.dumazet, edumazet, davem, ycheng, jdw,
stable, Takashi Iwai
In-Reply-To: <20180816061621.imodnhlytllvnlkj@unicorn.suse.cz>
On 2018/8/16 14:16, Michal Kubecek wrote:
> On Thu, Aug 16, 2018 at 10:50:01AM +0800, Mao Wenan wrote:
>> There are five patches to fix CVE-2018-5390 in latest mainline
>> branch, but only two patches exist in stable 4.4 and 3.18:
>> dc6ae4d tcp: detect malicious patterns in tcp_collapse_ofo_queue()
>> 5fbec48 tcp: avoid collapses in tcp_prune_queue() if possible
>> I have tested with stable 4.4 kernel, and found the cpu usage was very high.
>> So I think only two patches can't fix the CVE-2018-5390.
>> test results:
>> with fix patch： 78.2% ksoftirqd
>> withoutfix patch： 90% ksoftirqd
>>
>> Then I try to imitate 72cd43ba(tcp: free batches of packets in tcp_prune_ofo_queue())
>> to drop at least 12.5 % of sk_rcvbuf to avoid malicious attacks with simple queue
>> instead of RB tree. The result is not very well.
>>
>> After analysing the codes of stable 4.4, and debuging the
>> system, shows that search of ofo_queue(tcp ofo using a simple queue) cost more cycles.
>>
>> So I try to backport "tcp: use an RB tree for ooo receive queue" using RB tree
>> instead of simple queue, then backport Eric Dumazet 5 fixed patches in mainline,
>> good news is that ksoftirqd is turn to about 20%, which is the same with mainline now.
>>
>> Stable 4.4 have already back port two patches,
>> f4a3313d(tcp: avoid collapses in tcp_prune_queue() if possible)
>> 3d4bf93a(tcp: detect malicious patterns in tcp_collapse_ofo_queue())
>> If we want to change simple queue to RB tree to finally resolve, we should apply previous
>> patch 9f5afeae(tcp: use an RB tree for ooo receive queue.) firstly, but 9f5afeae have many
>> conflicts with 3d4bf93a and f4a3313d, which are part of patch series from Eric in
>> mainline to fix CVE-2018-5390, so I need revert part of patches in stable 4.4 firstly,
>> then apply 9f5afeae, and reapply five patches from Eric.
>
> There seems to be an obvious mistake in one of the backports. Could you
> check the results with Takashi's follow-up fix submitted at
>
> http://lkml.kernel.org/r/20180815095846.7734-1-tiwai@suse.de
>
> (I would try myself but you don't mention what test you ran.)
I have backport RB tree in stable 4.4, function tcp_collapse_ofo_queue() has been refined, which keep the
same with mainline, so it seems no problem when apply Eric's patch 3d4bf93a(tcp: detect malicious patterns in tcp_collapse_ofo_queue()).
I also noticed that range_truesize != head->truesize will be always false which mentioned in your URL, but this only based on stable 4.4's codes,
If I applied RB tree's patch 9f5afeae(tcp: use an RB tree for ooo receive queue), and after apply 3d4bf93a,the codes should be
range_truesize += skb->truesize, and range_truesize != head->truesize can be true.
One POC programm(named smack-for-ficora) is to send large out of order packets to existed tcp link, and check the cpu usage of the system with top command.
>
> Michal Kubecek
>
> .
>
^ permalink raw reply
* Re: [PATCH stable 4.4 0/9] fix SegmentSmack in stable branch (CVE-2018-5390)
From: Michal Kubecek @ 2018-08-16 6:52 UTC (permalink / raw)
To: maowenan
Cc: dwmw2, gregkh, netdev, eric.dumazet, edumazet, davem, ycheng, jdw,
stable, Takashi Iwai
In-Reply-To: <bcc20776-c8aa-f202-380f-979941d2d453@huawei.com>
On Thu, Aug 16, 2018 at 02:42:32PM +0800, maowenan wrote:
> On 2018/8/16 14:16, Michal Kubecek wrote:
> > On Thu, Aug 16, 2018 at 10:50:01AM +0800, Mao Wenan wrote:
> >> There are five patches to fix CVE-2018-5390 in latest mainline
> >> branch, but only two patches exist in stable 4.4 and 3.18:
> >> dc6ae4d tcp: detect malicious patterns in tcp_collapse_ofo_queue()
> >> 5fbec48 tcp: avoid collapses in tcp_prune_queue() if possible
> >> I have tested with stable 4.4 kernel, and found the cpu usage was very high.
> >> So I think only two patches can't fix the CVE-2018-5390.
> >> test results:
> >> with fix patch： 78.2% ksoftirqd
> >> withoutfix patch： 90% ksoftirqd
> >>
> >> Then I try to imitate 72cd43ba(tcp: free batches of packets in tcp_prune_ofo_queue())
> >> to drop at least 12.5 % of sk_rcvbuf to avoid malicious attacks with simple queue
> >> instead of RB tree. The result is not very well.
> >>
> >> After analysing the codes of stable 4.4, and debuging the
> >> system, shows that search of ofo_queue(tcp ofo using a simple queue) cost more cycles.
> >>
> >> So I try to backport "tcp: use an RB tree for ooo receive queue" using RB tree
> >> instead of simple queue, then backport Eric Dumazet 5 fixed patches in mainline,
> >> good news is that ksoftirqd is turn to about 20%, which is the same with mainline now.
> >>
> >> Stable 4.4 have already back port two patches,
> >> f4a3313d(tcp: avoid collapses in tcp_prune_queue() if possible)
> >> 3d4bf93a(tcp: detect malicious patterns in tcp_collapse_ofo_queue())
> >> If we want to change simple queue to RB tree to finally resolve, we should apply previous
> >> patch 9f5afeae(tcp: use an RB tree for ooo receive queue.) firstly, but 9f5afeae have many
> >> conflicts with 3d4bf93a and f4a3313d, which are part of patch series from Eric in
> >> mainline to fix CVE-2018-5390, so I need revert part of patches in stable 4.4 firstly,
> >> then apply 9f5afeae, and reapply five patches from Eric.
> >
> > There seems to be an obvious mistake in one of the backports. Could you
> > check the results with Takashi's follow-up fix submitted at
> >
> > http://lkml.kernel.org/r/20180815095846.7734-1-tiwai@suse.de
> >
> > (I would try myself but you don't mention what test you ran.)
>
> I have backport RB tree in stable 4.4, function
> tcp_collapse_ofo_queue() has been refined, which keep the same with
> mainline, so it seems no problem when apply Eric's patch 3d4bf93a(tcp:
> detect malicious patterns in tcp_collapse_ofo_queue()).
>
> I also noticed that range_truesize != head->truesize will be always
> false which mentioned in your URL, but this only based on stable 4.4's
> codes, If I applied RB tree's patch 9f5afeae(tcp: use an RB tree for
> ooo receive queue), and after apply 3d4bf93a,the codes should be
> range_truesize += skb->truesize, and range_truesize != head->truesize
> can be true.
My point is that backporting all this into stable 4.4 is quite intrusive
so that if we can achieve similar results with a simple fix of an
obvious omission, it would be preferrable.
Michal Kubecek
^ permalink raw reply
* Re: [PATCH] net: macb: Fix regression breaking non-MDIO fixed-link PHYs
From: Ahmad Fatoum @ 2018-08-16 6:54 UTC (permalink / raw)
To: Andrew Lunn, Uwe Kleine-König
Cc: David S. Miller, Nicolas Ferre, netdev, mdf, stable, kernel,
Brad Mouring, Florian Fainelli
In-Reply-To: <20180815023233.GD11610@lunn.ch>
On 08/15/2018 04:32 AM, Andrew Lunn wrote:
> Ahmed, where is the device tree for the EVB-KSZ9477?
I've attached it [1]. It's still work-in-progress (DSA doesn't work yet for example), but Ethernet is usable with Linux v4.18 and my patch applied.
Cheers
Ahmad
[1]
=======================================
diff --git a/arch/arm/boot/dts/at91-sama5d3_xplained_ung8087.dts b/arch/arm/boot/dts/at91-sama5d3_xplained_ung8087.dts
new file mode 100644
index 000000000000..164b6a47d0bf
--- /dev/null
+++ b/arch/arm/boot/dts/at91-sama5d3_xplained_ung8087.dts
@@ -0,0 +1,393 @@
+/*
+ * at91-sama5d3_xplained_ung8087.dts - Device Tree file for the EVB-KSZ9477 board
+ *
+ * Copyright (C) 2014 Atmel,
+ * 2014 Nicolas Ferre <nicolas.ferre@atmel.com>
+ * 2018 Ahmad Fatoum <a.fatoum@pengutronix.de>
+ *
+ * Licensed under GPLv2 or later.
+ */
+/dts-v1/;
+#include "sama5d36.dtsi"
+
+/ {
+ model = "SAMA5D3 Xplained";
+ compatible = "atmel,sama5d3-xplained", "atmel,sama5d3", "atmel,sama5";
+
+ chosen {
+ bootargs = "console=ttyS0,115200";
+ };
+
+ memory {
+ reg = <0x20000000 0x10000000>;
+ };
+
+ clocks {
+ slow_xtal {
+ clock-frequency = <32768>;
+ };
+
+ main_xtal {
+ clock-frequency = <12000000>;
+ };
+ };
+
+ ahb {
+ apb {
+ mmc0: mmc@f0000000 {
+ pinctrl-0 = <&pinctrl_mmc0_clk_cmd_dat0 &pinctrl_mmc0_dat1_3 &pinctrl_mmc0_dat4_7 &pinctrl_mmc0_cd>;
+ status = "okay";
+ slot@0 {
+ reg = <0>;
+ bus-width = <8>;
+ cd-gpios = <&pioE 0 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ spi0: spi@f0004000 {
+ cs-gpios = <&pioD 13 0>, <0>, <0>, <&pioD 16 0>;
+ id = <0>;
+ status = "okay";
+ };
+
+ can0: can@f000c000 {
+ status = "okay";
+ };
+
+ i2c0: i2c@f0014000 {
+ pinctrl-0 = <&pinctrl_i2c0_pu>;
+ status = "okay";
+ };
+
+ i2c1: i2c@f0018000 {
+ status = "okay";
+
+ pmic: act8865@5b {
+ compatible = "active-semi,act8865";
+ reg = <0x5b>;
+ status = "okay";
+
+ regulators {
+ vcc_1v8_reg: DCDC_REG1 {
+ regulator-name = "VCC_1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ };
+
+ vcc_1v2_reg: DCDC_REG2 {
+ regulator-name = "VCC_1V2";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-always-on;
+ };
+
+ vcc_3v3_reg: DCDC_REG3 {
+ regulator-name = "VCC_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ vddfuse_reg: LDO_REG1 {
+ regulator-name = "FUSE_2V5";
+ regulator-min-microvolt = <2500000>;
+ regulator-max-microvolt = <2500000>;
+ };
+
+ vddana_reg: LDO_REG2 {
+ regulator-name = "VDDANA";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+ };
+ };
+ };
+
+ macb0: ethernet@f0028000 {
+ phy-mode = "rgmii";
+ gpios = <&pioB 28 GPIO_ACTIVE_LOW>;
+ reset-gpios = <&pioC 31 GPIO_ACTIVE_LOW>;
+ status = "okay";
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+ };
+
+ pwm0: pwm@f002c000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm0_pwmh0_0 &pinctrl_pwm0_pwmh1_0>;
+ status = "okay";
+ };
+
+ usart0: serial@f001c000 {
+ status = "okay";
+ };
+
+ usart1: serial@f0020000 {
+ pinctrl-0 = <&pinctrl_usart1 &pinctrl_usart1_rts_cts>;
+ status = "okay";
+ };
+
+ uart0: serial@f0024000 {
+ status = "okay";
+ };
+
+ mmc1: mmc@f8000000 {
+ pinctrl-0 = <&pinctrl_mmc1_clk_cmd_dat0 &pinctrl_mmc1_dat1_3 &pinctrl_mmc1_cd>;
+ status = "okay";
+ slot@0 {
+ reg = <0>;
+ bus-width = <4>;
+ cd-gpios = <&pioE 1 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ spi1: spi@f8008000 {
+ pinctrl-0 = <&pinctrl_spi_ksz>;
+ cs-gpios = <&pioC 25 0>;
+ id = <1>;
+ status = "okay";
+
+ ksz9477: ksz9477@0 {
+ compatible = "microchip,ksz9477", "microchip,ksz9893";
+ reg = <0>;
+
+ /* Bus clock is 132 MHz. */
+ spi-max-frequency = <44000000>;
+ spi-cpha;
+ spi-cpol;
+ gpios = <&pioB 28 GPIO_ACTIVE_LOW>;
+ status = "okay";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ label = "lan0";
+ };
+
+ port@1 {
+ reg = <1>;
+ label = "lan1";
+ };
+
+ port@2 {
+ reg = <2>;
+ label = "lan2";
+ };
+
+ port@3 {
+ reg = <3>;
+ label = "lan3";
+ };
+
+ port@4 {
+ reg = <4>;
+ label = "lan4";
+ };
+
+ port@5 {
+ reg = <5>;
+ label = "cpu";
+ ethernet = <&macb0>;
+ phy-mode = "rgmii-id";
+
+ fixed-link {
+ speed = <0x3e8>;
+ full-duplex;
+ };
+ };
+
+ /* port 6 is connected to eth0 */
+ };
+ };
+ };
+
+ adc0: adc@f8018000 {
+ pinctrl-0 = <
+ &pinctrl_adc0_adtrg
+ &pinctrl_adc0_ad0
+ &pinctrl_adc0_ad1
+ &pinctrl_adc0_ad2
+ &pinctrl_adc0_ad3
+ &pinctrl_adc0_ad4
+ &pinctrl_adc0_ad5
+ &pinctrl_adc0_ad6
+ &pinctrl_adc0_ad7
+ &pinctrl_adc0_ad8
+ &pinctrl_adc0_ad9
+ >;
+ status = "okay";
+ };
+
+ i2c2: i2c@f801c000 {
+ dmas = <0>, <0>; /* Do not use DMA for i2c2 */
+ pinctrl-0 = <&pinctrl_i2c2_pu>;
+ status = "okay";
+ };
+
+ macb1: ethernet@f802c000 {
+ phy-mode = "rmii";
+ status = "disabled";
+ };
+
+ dbgu: serial@ffffee00 {
+ status = "okay";
+ };
+
+ pinctrl@fffff200 {
+ board {
+ pinctrl_i2c0_pu: i2c0_pu {
+ atmel,pins =
+ <AT91_PIOA 30 AT91_PERIPH_A AT91_PINCTRL_PULL_UP>,
+ <AT91_PIOA 31 AT91_PERIPH_A AT91_PINCTRL_PULL_UP>;
+ };
+
+ pinctrl_i2c2_pu: i2c2_pu {
+ atmel,pins =
+ <AT91_PIOA 18 AT91_PERIPH_B AT91_PINCTRL_PULL_UP>,
+ <AT91_PIOA 19 AT91_PERIPH_B AT91_PINCTRL_PULL_UP>;
+ };
+
+ pinctrl_mmc0_cd: mmc0_cd {
+ atmel,pins =
+ <AT91_PIOE 0 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP_DEGLITCH>;
+ };
+
+ pinctrl_mmc1_cd: mmc1_cd {
+ atmel,pins =
+ <AT91_PIOE 1 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP_DEGLITCH>;
+ };
+
+ pinctrl_usba_vbus: usba_vbus {
+ atmel,pins =
+ <AT91_PIOE 9 AT91_PERIPH_GPIO AT91_PINCTRL_DEGLITCH>; /* PE9, conflicts with A9 */
+ };
+
+ pinctrl_spi_ksz: spi_ksz {
+ atmel,pins =
+ <
+ AT91_PIOB 28 AT91_PERIPH_GPIO AT91_PINCTRL_DEGLITCH
+ AT91_PIOC 31 AT91_PERIPH_GPIO AT91_PINCTRL_DEGLITCH
+ >;
+ };
+ };
+ };
+
+ pmc: pmc@fffffc00 {
+ main: mainck {
+ clock-frequency = <12000000>;
+ };
+ };
+ };
+
+ ebi: ebi@10000000 {
+ pinctrl-0 = <&pinctrl_ebi_nand_addr>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ nand_controller: nand-controller {
+ status = "okay";
+
+ nand@3 {
+ reg = <0x3 0x0 0x2>;
+ atmel,rb = <0>;
+ nand-bus-width = <8>;
+ nand-ecc-mode = "hw";
+ nand-ecc-strength = <4>;
+ nand-ecc-step-size = <512>;
+ nand-on-flash-bbt;
+ label = "atmel_nand";
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ at91bootstrap@0 {
+ label = "at91bootstrap";
+ reg = <0x0 0x40000>;
+ };
+
+ bootloader@40000 {
+ label = "bootloader";
+ reg = <0x40000 0x80000>;
+ };
+
+ bootloaderenv@c0000 {
+ label = "bootloader env";
+ reg = <0xc0000 0xc0000>;
+ };
+
+ dtb@180000 {
+ label = "device tree";
+ reg = <0x180000 0x80000>;
+ };
+
+ kernel@200000 {
+ label = "kernel";
+ reg = <0x200000 0x600000>;
+ };
+
+ rootfs@800000 {
+ label = "rootfs";
+ reg = <0x800000 0x0f800000>;
+ };
+ };
+ };
+ };
+ };
+
+ usb0: gadget@500000 {
+ atmel,vbus-gpio = <&pioE 9 GPIO_ACTIVE_HIGH>; /* PE9, conflicts with A9 */
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usba_vbus>;
+ status = "okay";
+ };
+
+ usb1: ohci@600000 {
+ num-ports = <3>;
+ atmel,vbus-gpio = <0
+ &pioE 3 GPIO_ACTIVE_LOW
+ &pioE 4 GPIO_ACTIVE_LOW
+ >;
+ status = "okay";
+ };
+
+ usb2: ehci@700000 {
+ status = "okay";
+ };
+ };
+
+ gpio_keys {
+ compatible = "gpio-keys";
+
+ bp3 {
+ label = "PB_USER";
+ gpios = <&pioE 29 GPIO_ACTIVE_LOW>;
+ linux,code = <0x104>;
+ gpio-key,wakeup;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ d2 {
+ label = "d2";
+ gpios = <&pioE 23 GPIO_ACTIVE_LOW>; /* PE23, conflicts with A23, CTS2 */
+ linux,default-trigger = "heartbeat";
+ };
+
+ d3 {
+ label = "d3";
+ gpios = <&pioE 24 GPIO_ACTIVE_HIGH>;
+ };
+ };
+};
--
2.18.0
^ permalink raw reply related
* Re: [PATCH v3] Add BPF_SYNCHRONIZE_MAP_TO_MAP_REFERENCES bpf(2) command
From: Alexei Starovoitov @ 2018-08-16 4:01 UTC (permalink / raw)
To: Daniel Colascione
Cc: Daniel Borkmann, Jakub Kicinski, Joel Fernandes, linux-kernel,
Tim Murray, netdev, Lorenzo Colitti, Chenbo Feng,
Mathieu Desnoyers, Alexei Starovoitov
In-Reply-To: <CAKOZueuACjK0W4byW7omPvEJ-H-8MK1OU3ORrAfNtsEi8NxoPQ@mail.gmail.com>
On Tue, Aug 14, 2018 at 01:37:12PM -0700, Daniel Colascione wrote:
>
> > If we agree on that, should bpf_map_update handle it then?
> > Wouldn't it be much easier to understand and use from user pov?
> > No new commands to learn. map_update syscall replaced the map
> > and old map is no longer accessed by the program via this given map-in-map.
>
> Maybe with a new BPF_SYNCHRONIZE flag for BPF_MAP_UPDATE_ELEM and
> BPF_MAP_DELETE_ELEM. Otherwise, it seems wrong to make every user of
> these commands pay for synchronization that only a few will need.
I don't think extra flag is needed. Extra sync_rcu() for map-in-map
is useful for all users. I would consider it a bugfix,
since users that examine deleted map have this race today
and removing the race is always a good thing especially since the cost
is small.
^ permalink raw reply
* Re: [RFC PATCH net-next V2 0/6] XDP rx handler
From: Jason Wang @ 2018-08-16 4:21 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: David Ahern, Jesper Dangaard Brouer, netdev, linux-kernel, ast,
daniel, mst, Toshiaki Makita
In-Reply-To: <20180816024913.57ykirt7eqrjntfy@ast-mbp.dhcp.thefacebook.com>
On 2018年08月16日 10:49, Alexei Starovoitov wrote:
> On Wed, Aug 15, 2018 at 03:04:35PM +0800, Jason Wang wrote:
>>>> 3 Deliver XDP buff to userspace through macvtap.
>>> I think I'm getting what you're trying to achieve.
>>> You actually don't want any bpf programs in there at all.
>>> You want macvlan builtin logic to act on raw packet frames.
>> The built-in logic is just used to find the destination macvlan device. It
>> could be done by through another bpf program. Instead of inventing lots of
>> generic infrastructure on kernel with specific userspace API, built-in logic
>> has its own advantages:
>>
>> - support hundreds or even thousands of macvlans
> are you saying xdp bpf program cannot handle thousands macvlans?
Correct me if I was wrong. It works well when the macvlan requires
similar logic. But let's consider the case when each macvlan wants its
own specific logic. Is this possible to have thousands of different
policies and actions in a single BPF program? With XDP rx hanlder,
there's no need to root device to care about them. Each macvlan can only
care about itself. This is similar to the case that qdisc could be
attached to each stacked device.
>
>> - using exist tools to configure network
>> - immunity to topology changes
> what do you mean specifically?
Still the above example, if some macvlans is deleted or created. We need
notify and update the policies in the root device, this requires
userspace control program to monitor those changes and notify BPF
program through maps. Unless the BPF program is designed for some
specific configurations and setups, it would not be an easy task.
>
>> Besides the usage for containers, we can implement macvtap RX handler which
>> allows a fast packet forwarding to userspace.
> and try to reinvent af_xdp? the motivation for the patchset still escapes me.
Nope, macvtap was used for forwarding packets to VM. This is just try to
deliver the XDP buff to VM instead of skb. Similar idea was used by
TUN/TAP which shows amazing improvements.
>
>> Actually, the idea is not limited to macvlan but for all device that is
>> based on rx handler. Consider the case of bonding, this allows to set a very
>> simple XDP program on slaves and keep a single main logic XDP program on the
>> bond instead of duplicating it in all slaves.
> I think such mixed environment of hardcoded in-kernel things like bond
> mixed together with xdp programs will be difficult to manage and debug.
> How admin suppose to debug it?
Well, we've already had in-kernel XDP_TX routine. It should be not
harder than that.
> Say something in the chain of
> nic -> native xdp -> bond with your xdp rx -> veth -> xdp prog -> consumer
> is dropping a packet. If all forwarding decisions are done by bpf progs
> the progs will have packet tracing facility (like cilium does) to
> show packet flow end-to-end. It works briliantly like traceroute within a host.
Does this work well for veth pair as well? If yes, it should work for rx
handler or maybe it has some hard code logic like "ok, the packet goes
to veth, I'm sure it will be delivered to its peer"? The idea of this
series is not forbidding the forwarding decisions done by bpf progs, if
the code did this by accident, we can introduce flag to disable/enable
XDP rx handler.
And I believe redirection is part of XDP usage, we may still want things
like XDP_TX.
> But when you have things like macvlan, bond, bridge in the middle
> that can also act on packet, the admin will have a hard time.
I admit it may require admin help, but it gives us more flexibility.
>
> Essentially what you're proposing is to make all kernel builtin packet
> steering/forwarding facilities to understand raw xdp frames.
Probably not, at least for this series it just focus on rx handler. We
only have less than 10 devices use that.
> That's a lot of code
> and at the end of the chain you'd need fast xdp frame consumer otherwise
> perf benefits are lost.
The performance are lost but still the same as skb. And except for
redirection, we do have other consumer like XDP_TX.
> If that consumer is xdp bpf program
> why bother with xdp-fied macvlan or bond?
For macvlan, we may want to have different polices for different
devices. For bond, we don't want to duplicate XDP logic in each slaves,
and only bond know which slave could be used for XDP_TX.
> If that consumer is tcp stack
> than forwarding via xdp-fied bond is no faster than via skb-based bond.
>
Yes.
Thanks
^ permalink raw reply
* Re: [PATCH stable 4.4 0/9] fix SegmentSmack in stable branch (CVE-2018-5390)
From: maowenan @ 2018-08-16 7:19 UTC (permalink / raw)
To: Michal Kubecek
Cc: dwmw2, gregkh, netdev, eric.dumazet, edumazet, davem, ycheng, jdw,
stable, Takashi Iwai
In-Reply-To: <20180816065210.iq7jyscajjoiw7k4@unicorn.suse.cz>
On 2018/8/16 14:52, Michal Kubecek wrote:
> On Thu, Aug 16, 2018 at 02:42:32PM +0800, maowenan wrote:
>> On 2018/8/16 14:16, Michal Kubecek wrote:
>>> On Thu, Aug 16, 2018 at 10:50:01AM +0800, Mao Wenan wrote:
>>>> There are five patches to fix CVE-2018-5390 in latest mainline
>>>> branch, but only two patches exist in stable 4.4 and 3.18:
>>>> dc6ae4d tcp: detect malicious patterns in tcp_collapse_ofo_queue()
>>>> 5fbec48 tcp: avoid collapses in tcp_prune_queue() if possible
>>>> I have tested with stable 4.4 kernel, and found the cpu usage was very high.
>>>> So I think only two patches can't fix the CVE-2018-5390.
>>>> test results:
>>>> with fix patch： 78.2% ksoftirqd
>>>> withoutfix patch： 90% ksoftirqd
>>>>
>>>> Then I try to imitate 72cd43ba(tcp: free batches of packets in tcp_prune_ofo_queue())
>>>> to drop at least 12.5 % of sk_rcvbuf to avoid malicious attacks with simple queue
>>>> instead of RB tree. The result is not very well.
>>>>
>>>> After analysing the codes of stable 4.4, and debuging the
>>>> system, shows that search of ofo_queue(tcp ofo using a simple queue) cost more cycles.
>>>>
>>>> So I try to backport "tcp: use an RB tree for ooo receive queue" using RB tree
>>>> instead of simple queue, then backport Eric Dumazet 5 fixed patches in mainline,
>>>> good news is that ksoftirqd is turn to about 20%, which is the same with mainline now.
>>>>
>>>> Stable 4.4 have already back port two patches,
>>>> f4a3313d(tcp: avoid collapses in tcp_prune_queue() if possible)
>>>> 3d4bf93a(tcp: detect malicious patterns in tcp_collapse_ofo_queue())
>>>> If we want to change simple queue to RB tree to finally resolve, we should apply previous
>>>> patch 9f5afeae(tcp: use an RB tree for ooo receive queue.) firstly, but 9f5afeae have many
>>>> conflicts with 3d4bf93a and f4a3313d, which are part of patch series from Eric in
>>>> mainline to fix CVE-2018-5390, so I need revert part of patches in stable 4.4 firstly,
>>>> then apply 9f5afeae, and reapply five patches from Eric.
>>>
>>> There seems to be an obvious mistake in one of the backports. Could you
>>> check the results with Takashi's follow-up fix submitted at
>>>
>>> http://lkml.kernel.org/r/20180815095846.7734-1-tiwai@suse.de
>>>
>>> (I would try myself but you don't mention what test you ran.)
>>
>> I have backport RB tree in stable 4.4, function
>> tcp_collapse_ofo_queue() has been refined, which keep the same with
>> mainline, so it seems no problem when apply Eric's patch 3d4bf93a(tcp:
>> detect malicious patterns in tcp_collapse_ofo_queue()).
>>
>> I also noticed that range_truesize != head->truesize will be always
>> false which mentioned in your URL, but this only based on stable 4.4's
>> codes, If I applied RB tree's patch 9f5afeae(tcp: use an RB tree for
>> ooo receive queue), and after apply 3d4bf93a,the codes should be
>> range_truesize += skb->truesize, and range_truesize != head->truesize
>> can be true.
>
> My point is that backporting all this into stable 4.4 is quite intrusive
> so that if we can achieve similar results with a simple fix of an
> obvious omission, it would be preferrable.
There are five patches in mainline to fix this CVE, only two patches have no effect on stable 4.4,
the important reason is 4.4 use simple queue but mainline use RB tree.
I have tried my best to use easy way to fix this with dropping packets 12.5%(or other value) based on simple queue,
but the result is not very well, so the RB tree is needed and tested result is my desire.
If we only back port two patches but they don't fix the issue, I think they don't make any sense.
>
> Michal Kubecek
>
> .
>
^ permalink raw reply
* Re: [PATCH v1 2/3] zinc: Introduce minimal cryptography library
From: D. J. Bernstein @ 2018-08-16 4:24 UTC (permalink / raw)
To: Eric Biggers, Jason A. Donenfeld, Eric Biggers,
Linux Crypto Mailing List, LKML, Netdev, David Miller,
Andrew Lutomirski, Greg Kroah-Hartman, Samuel Neves, Tanja Lange,
Jean-Philippe Aumasson, Karthikeyan Bhargavan
In-Reply-To: <20180815195732.GA79500@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 7172 bytes --]
Eric Biggers writes:
> You'd probably attract more contributors if you followed established
> open source conventions.
SUPERCOP already has thousands of implementations from hundreds of
contributors. New speed records are more likely to appear in SUPERCOP
than in any other cryptographic software collection. The API is shared
by state-of-the-art benchmarks, state-of-the-art tests, three ongoing
competitions, and increasingly popular production libraries.
Am I correctly gathering from this thread that someone adding a new
implementation of a crypto primitive to the kernel has to worry about
checking the architecture and CPU features to figure out whether the
implementation will run? Wouldn't it make more sense to take this
error-prone work away from the implementor and have a robust automated
central testing mechanism, as in SUPERCOP?
Am I also correctly gathering that adding an extra implementation to the
kernel can hurt performance, unless the implementor goes to extra effort
to check for the CPUs where the previous implementation is faster---or
to build some ad-hoc timing mechanism ("raid6: using algorithm avx2x4
gen() 31737 MB/s")? Wouldn't it make more sense to take this error-prone
work away from the implementor and have a robust automated central
timing mechanism, as in SUPERCOP?
I also didn't notice anyone disputing Jason's comment about the "general
clunkiness" of the kernel's internal crypto API---but is there really no
consensus as to what the replacement API is supposed to be? Someone who
simply wants to implement some primitives has to decide on function-call
details, argue about the software location, add configuration options,
etc.? Wouldn't it make more sense to do this centrally, as in SUPERCOP?
And then there's the bigger question of how the community is organizing
ongoing work on accelerating---and auditing, and fixing, and hopefully
verifying---implementations of cryptographic primitives. Does it really
make sense that people looking for what's already been done have to go
poking around a bunch of separate libraries? Wouldn't it make more sense
to have one central collection of code, as in SUPERCOP? Is there any
fundamental obstacle to having libraries share code for primitives?
> there doesn't appear to be an official git repository for SUPERCOP,
> nor is there any mention of how to send patches, nor is there any
> COPYING or LICENSE file, nor even a README file.
https://bench.cr.yp.to/call-stream.html explains the API and submission
procedure for stream ciphers. There are similar pages for other types of
cryptographic primitives. https://bench.cr.yp.to/tips.html explains the
develop-test cycle and various useful options.
Licenses vary across implementations. There's a minimum requirement of
public distribution for verifiability of benchmark results, but it's up
to individual implementors to decide what they'll allow beyond that.
Patent status also varies; constant-time status varies; verification
status varies; code quality varies; cryptographic security varies; etc.
As I mentioned, SUPERCOP includes MD5 and Speck and RSA-512.
For comparison, where can I find an explanation of how to test kernel
crypto patches, and how fast is the develop-test cycle? Okay, I don't
have a kernel crypto patch, but I did write a kernel patch recently that
(I think) fixes some recent Lenovo ACPI stupidity:
https://marc.info/?l=qubes-users&m=153308905514481
I'd propose this for review and upstream adoption _if_ it survives
enough tests---but what's the right test procedure? I see superficial
documentation of where to submit a patch for review, but am I really
supposed to do this before serious testing? The patch works on my
laptop, and several other people say it works, but obviously this is
missing the big question of whether the patch breaks _other_ laptops.
I see an online framework for testing, but using it looks awfully
complicated, and the level of coverage is unclear to me. Has anyone
tried to virtualize kernel testing---to capture hardware data from many
machines and then centrally simulate kernels running on those machines,
for example to check that those machines don't take certain code paths?
I suppose that people who work with the kernel all the time would know
what to do, but for me the lack of information was enough of a deterrent
that I switched to doing something else.
> Another issue is that the ChaCha code in SUPERCOP is duplicated for
> each number of rounds: 8, 12, and 20.
These are auto-generated, of course.
To understand this API detail, consider some of the possibilities for
the round counts supported by compiled code:
* 20
* 12
* 8
* caller selection from among 20 and 12 and 8
* caller selection of any multiple of 4
* caller selection of any multiple of 2
* caller selection of anything
I hope that in the long term everyone is simply using 20, and then the
pure 20 is the simplest and smallest and most easily verified code, but
obviously there are other implementations today. An API with a separate
function for each round count allows any of these implementations to be
trivially benchmarked and used, whereas an API that insists on passing
the round count as an argument prohibits at least the first three and
maybe more.
> crypto_stream/chacha20/dolbeau/arm-neon/, which uses a method similar to the
> Linux implementation but it uses GCC intrinsics, so its performance will heavily
> depend on how the compiler assigns and spills registers, which can vary greatly
> depending on the compiler version and options.
Sure. The damage done by incompetent compilers is particularly clear for
in-order CPUs such as the Cortex-A7.
> I understand that Salsa20 is similar to ChaCha, and that ideas from Salsa20
> implementations often apply to ChaCha too. But it's not always obvious what
> carries over and what doesn't; the rotation amounts can matter a lot, for
> example, as different rotations can be implemented in different ways.
This sounds backwards to me. ChaCha20 supports essentially all the
Salsa20 implementation techniques plus some extra streamlining: often a
bit less register pressure, often less data reorganization, and often
some rotation speedups.
> Nor is it always obvious which ideas from SSE2 or AVX2 implementations
> (for example) carry over to NEON implementations, as these instruction
> sets are different enough that each has its own unique quirks and
> optimizations.
Of course.
> Previously I also found that OpenSSL's ARM NEON implementation of Poly1305 is
> much faster than the implementations in SUPERCOP, as well as more
> understandable. (I don't know the 'qhasm' language, for example.) So from my
> perspective, I've had more luck with OpenSSL than SUPERCOP when looking for fast
> implementations of crypto algorithms. Have you considered adding the OpenSSL
> implementations to SUPERCOP?
Almost all of the implementations in SUPERCOP were submitted by the
implementors, with a few exceptions for wrappers. Realistically, the
implementors are in the best position to check that they're getting the
expected results and to be in control of any necessary updates.
---Dan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH stable 4.4 0/9] fix SegmentSmack in stable branch (CVE-2018-5390)
From: maowenan @ 2018-08-16 7:39 UTC (permalink / raw)
To: Michal Kubecek
Cc: dwmw2, gregkh, netdev, eric.dumazet, edumazet, davem, ycheng, jdw,
stable, Takashi Iwai
In-Reply-To: <20180816072349.2ldy75jia3ubqg3u@unicorn.suse.cz>
On 2018/8/16 15:23, Michal Kubecek wrote:
> On Thu, Aug 16, 2018 at 03:19:12PM +0800, maowenan wrote:
>> On 2018/8/16 14:52, Michal Kubecek wrote:
>>>
>>> My point is that backporting all this into stable 4.4 is quite intrusive
>>> so that if we can achieve similar results with a simple fix of an
>>> obvious omission, it would be preferrable.
>>
>> There are five patches in mainline to fix this CVE, only two patches
>> have no effect on stable 4.4, the important reason is 4.4 use simple
>> queue but mainline use RB tree.
>>
>> I have tried my best to use easy way to fix this with dropping packets
>> 12.5%(or other value) based on simple queue, but the result is not
>> very well, so the RB tree is needed and tested result is my desire.
>>
>> If we only back port two patches but they don't fix the issue, I think
>> they don't make any sense.
>
> There is an obvious omission in one of the two patches and Takashi's
> patch fixes it. If his follow-up fix (applied on top of what is in
> stable 4.4 now) addresses the problem, I would certainly prefer using it
> over backporting the whole series.
Do you mean below codes from Takashi can fix this CVE?
But I have already tested like this two days ago, it is not good effect.
Could you try to test with POC programme mentioned previous mail in case I made mistake?
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 4a261e078082..9c4c6cd0316e 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -4835,6 +4835,7 @@ static void tcp_collapse_ofo_queue(struct sock *sk)
end = TCP_SKB_CB(skb)->end_seq;
range_truesize = skb->truesize;
} else {
+ range_truesize += skb->truesize;
if (before(TCP_SKB_CB(skb)->seq, start))
start = TCP_SKB_CB(skb)->seq;
if (after(TCP_SKB_CB(skb)->end_seq, end))
--
>
> Michal Kubecek
>
>
> .
>
^ permalink raw reply related
* Re: [PATCH stable 4.4 0/9] fix SegmentSmack in stable branch (CVE-2018-5390)
From: maowenan @ 2018-08-16 7:55 UTC (permalink / raw)
To: Michal Kubecek
Cc: dwmw2, gregkh, netdev, eric.dumazet, edumazet, davem, ycheng, jdw,
stable, Takashi Iwai
In-Reply-To: <20180816074457.bjxbrthhvfazuzmd@unicorn.suse.cz>
On 2018/8/16 15:44, Michal Kubecek wrote:
> On Thu, Aug 16, 2018 at 03:39:14PM +0800, maowenan wrote:
>>
>>
>> On 2018/8/16 15:23, Michal Kubecek wrote:
>>> On Thu, Aug 16, 2018 at 03:19:12PM +0800, maowenan wrote:
>>>> On 2018/8/16 14:52, Michal Kubecek wrote:
>>>>>
>>>>> My point is that backporting all this into stable 4.4 is quite intrusive
>>>>> so that if we can achieve similar results with a simple fix of an
>>>>> obvious omission, it would be preferrable.
>>>>
>>>> There are five patches in mainline to fix this CVE, only two patches
>>>> have no effect on stable 4.4, the important reason is 4.4 use simple
>>>> queue but mainline use RB tree.
>>>>
>>>> I have tried my best to use easy way to fix this with dropping packets
>>>> 12.5%(or other value) based on simple queue, but the result is not
>>>> very well, so the RB tree is needed and tested result is my desire.
>>>>
>>>> If we only back port two patches but they don't fix the issue, I think
>>>> they don't make any sense.
>>>
>>> There is an obvious omission in one of the two patches and Takashi's
>>> patch fixes it. If his follow-up fix (applied on top of what is in
>>> stable 4.4 now) addresses the problem, I would certainly prefer using it
>>> over backporting the whole series.
>>
>> Do you mean below codes from Takashi can fix this CVE?
>> But I have already tested like this two days ago, it is not good effect.
>
> IIRC what you proposed was different, you proposed to replace the "=" in
> the other branch by "+=".
No, I think you don't get what I mean, I have already tested stable 4.4,
based on commit dc6ae4d, and change the codes like Takashi, which didn't
contain any codes I have sent in this patch series.
I suggest someone to test again based on Takashi.
dc6ae4d tcp: detect malicious patterns in tcp_collapse_ofo_queue()
5fbec48 tcp: avoid collapses in tcp_prune_queue() if possible
255924e tcp: do not delay ACK in DCTCP upon CE status change
0b1d40e tcp: do not cancel delay-AcK on DCTCP special ACK
17fea38e7 tcp: helpers to send special DCTCP ack
500e03f tcp: fix dctcp delayed ACK schedule
b04c9a0 rtnetlink: add rtnl_link_state check in rtnl_configure_link
73dad08 net/mlx4_core: Save the qpn from the input modifier in RST2INIT wrapper
48f41c0 ip: hash fragments consistently
54a634c MIPS: ath79: fix register address in ath79_ddr_wb_flush()
762b585 Linux 4.4.144
>
> Michal Kubecek
>
>
>>
>> Could you try to test with POC programme mentioned previous mail in case I made mistake?
>>
>> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
>> index 4a261e078082..9c4c6cd0316e 100644
>> --- a/net/ipv4/tcp_input.c
>> +++ b/net/ipv4/tcp_input.c
>> @@ -4835,6 +4835,7 @@ static void tcp_collapse_ofo_queue(struct sock *sk)
>> end = TCP_SKB_CB(skb)->end_seq;
>> range_truesize = skb->truesize;
>> } else {
>> + range_truesize += skb->truesize;
>> if (before(TCP_SKB_CB(skb)->seq, start))
>> start = TCP_SKB_CB(skb)->seq;
>> if (after(TCP_SKB_CB(skb)->end_seq, end))
>> --
>>
>>
>>>
>>> Michal Kubecek
>>>
>>>
>>> .
>>>
>>
>
> .
>
^ permalink raw reply
* bnxt: card intermittently hanging and dropping link
From: Daniel Axtens @ 2018-08-16 5:29 UTC (permalink / raw)
To: netdev, jay.vosburgh, michael.chan
Hi Michael,
I have some user reports of issues with a Broadcom 57412 card with the
card intermittently hanging and dropping the link.
The problem has been observed on a Dell server with an Ubuntu 4.13
kernel (bnxt_en version 1.7.0) and with an Ubuntu 4.15 kernel (bnxt_en
version 1.8.0). It seems to occur while mounting an XFS volume over
iSCSI, although running blkid on the partition succeeds, and it seems to
be a different volume each time.
I've included an excerpt from the kernel log below.
It seems that other people have reported this with a RHEL7 kernel - I
have no idea what driver version that would be running, or what workload
they were operating, but the warnings and messages look the same:
https://www.dell.com/community/PowerEdge-Hardware-General/Critical-network-bnxt-en-module-crashes-on-14G-servers/td-p/6031769/highlight/true
The forum poster reported that disconnecting the card from power for 5
minutes was sufficient to get things working again and I have asked our
user to test that.
Is this a known issue?
Regards,
Daniel
[ 2662.526151] scsi host14: iSCSI Initiator over TCP/IP
[ 2662.538110] scsi host15: iSCSI Initiator over TCP/IP
[ 2662.547350] scsi host16: iSCSI Initiator over TCP/IP
[ 2662.554660] scsi host17: iSCSI Initiator over TCP/IP
[ 2662.813860] scsi 15:0:0:1: Direct-Access PURE FlashArray 8888 PQ: 0 ANSI: 6
[ 2662.813888] scsi 14:0:0:1: Direct-Access PURE FlashArray 8888 PQ: 0 ANSI: 6
[ 2662.813972] scsi 16:0:0:1: Direct-Access PURE FlashArray 8888 PQ: 0 ANSI: 6
[ 2662.814322] sd 15:0:0:1: Attached scsi generic sg1 type 0
[ 2662.814553] sd 14:0:0:1: Attached scsi generic sg2 type 0
[ 2662.814554] scsi 17:0:0:1: Direct-Access PURE FlashArray 8888 PQ: 0 ANSI: 6
[ 2662.814612] sd 16:0:0:1: Attached scsi generic sg3 type 0
[ 2662.815081] sd 15:0:0:1: [sdb] 10737418240 512-byte logical blocks: (5.50 TB/5.00 TiB)
[ 2662.815195] sd 15:0:0:1: [sdb] Write Protect is off
[ 2662.815197] sd 15:0:0:1: [sdb] Mode Sense: 43 00 00 08
[ 2662.815229] sd 14:0:0:1: [sdc] 10737418240 512-byte logical blocks: (5.50 TB/5.00 TiB)
[ 2662.815292] sd 17:0:0:1: Attached scsi generic sg4 type 0
[ 2662.815342] sd 14:0:0:1: [sdc] Write Protect is off
[ 2662.815343] sd 14:0:0:1: [sdc] Mode Sense: 43 00 00 08
[ 2662.815419] sd 15:0:0:1: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 2662.815447] sd 16:0:0:1: [sdd] 10737418240 512-byte logical blocks: (5.50 TB/5.00 TiB)
[ 2662.815544] sd 14:0:0:1: [sdc] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 2662.815614] sd 16:0:0:1: [sdd] Write Protect is off
[ 2662.815615] sd 16:0:0:1: [sdd] Mode Sense: 43 00 00 08
[ 2662.815882] sd 16:0:0:1: [sdd] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 2662.816188] sd 17:0:0:1: [sde] 10737418240 512-byte logical blocks: (5.50 TB/5.00 TiB)
[ 2662.816298] sd 17:0:0:1: [sde] Write Protect is off
[ 2662.816300] sd 17:0:0:1: [sde] Mode Sense: 43 00 00 08
[ 2662.816502] sd 17:0:0:1: [sde] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 2662.820080] sd 15:0:0:1: [sdb] Attached SCSI disk
[ 2662.820594] sd 14:0:0:1: [sdc] Attached SCSI disk
[ 2662.820995] sd 17:0:0:1: [sde] Attached SCSI disk
[ 2662.821176] sd 16:0:0:1: [sdd] Attached SCSI disk
[ 2662.913642] device-mapper: multipath round-robin: version 1.2.0 loaded
[ 2663.954001] XFS (dm-2): Mounting V5 Filesystem
[ 2673.186083] connection3:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4295558209, last ping 4295559460, now 4295560768
[ 2673.186135] connection3:0: detected conn error (1022)
[ 2673.186137] connection2:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4295558209, last ping 4295559460, now 4295560768
[ 2673.186168] connection2:0: detected conn error (1022)
[ 2673.186170] connection1:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4295558209, last ping 4295559460, now 4295560768
[ 2673.186211] connection1:0: detected conn error (1022)
[ 2674.209870] connection4:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4295558463, last ping 4295559720, now 4295561024
[ 2674.209924] connection4:0: detected conn error (1022)
[ 2678.560630] session1: session recovery timed out after 5 secs
[ 2678.560641] session2: session recovery timed out after 5 secs
[ 2678.560647] session3: session recovery timed out after 5 secs
[ 2678.951453] device-mapper: multipath: Failing path 8:32.
[ 2678.951509] device-mapper: multipath: Failing path 8:48.
[ 2678.951548] device-mapper: multipath: Failing path 8:16.
[ 2679.584302] session4: session recovery timed out after 5 secs
[ 2679.584313] sd 17:0:0:1: rejecting I/O to offline device
[ 2679.584356] sd 17:0:0:1: [sde] killing request
[ 2679.584362] sd 17:0:0:1: rejecting I/O to offline device
[ 2679.584392] sd 17:0:0:1: [sde] killing request
[ 2679.584401] sd 17:0:0:1: [sde] FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
[ 2679.584402] sd 17:0:0:1: [sde] CDB: Read(16) 88 00 00 00 00 00 00 00 00 00 00 00 00 08 00 00
[ 2679.584404] print_req_error: I/O error, dev sde, sector 0
[ 2679.584436] sd 17:0:0:1: [sde] FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
[ 2679.584438] sd 17:0:0:1: [sde] CDB: Write(16) 8a 00 00 00 00 00 80 10 7f 1e 00 00 10 00 00 00
[ 2679.584439] print_req_error: I/O error, dev sde, sector 2148564766
[ 2679.584464] device-mapper: multipath: Failing path 8:64.
[ 2679.584472] print_req_error: I/O error, dev dm-2, sector 2148564766
[ 2679.584562] XFS (dm-2): xfs_do_force_shutdown(0x1) called from line 1217 of file /build/linux-hwe-eGX82t/linux-hwe-4.15.0/fs/xfs/xfs_buf.c. Return address = 0x00000000d95bdaac
[ 2679.584576] XFS (dm-2): I/O Error Detected. Shutting down filesystem
[ 2679.584595] XFS (dm-2): Please umount the filesystem and rectify the problem(s)
[ 2679.584613] XFS (dm-2): metadata I/O error: block 0x80107f1e ("xlog_bwrite") error 5 numblks 8192
[ 2679.584796] XFS (dm-2): failed to locate log tail
[ 2679.584798] XFS (dm-2): log mount/recovery failed: error -5
[ 2679.584910] XFS (dm-2): log mount failed
[ 2680.589182] print_req_error: I/O error, dev dm-2, sector 10737418112
[ 2680.589232] print_req_error: I/O error, dev dm-2, sector 10737418112
[ 2680.589250] Buffer I/O error on dev dm-2, logical block 1342177264, async page read
[ 2680.589584] print_req_error: I/O error, dev dm-2, sector 2
[ 2680.589611] EXT4-fs (dm-2): unable to read superblock
[ 2680.589781] print_req_error: I/O error, dev dm-2, sector 2
[ 2680.589804] EXT4-fs (dm-2): unable to read superblock
[ 2680.590019] print_req_error: I/O error, dev dm-2, sector 2
[ 2680.590078] EXT4-fs (dm-2): unable to read superblock
[ 2680.590298] print_req_error: I/O error, dev dm-2, sector 0
[ 2680.590358] SQUASHFS error: squashfs_read_data failed to read block 0x0
[ 2680.590390] squashfs: SQUASHFS error: unable to read squashfs_super_block
[ 2681.592134] print_req_error: I/O error, dev dm-2, sector 10737418112
[ 2681.592217] Buffer I/O error on dev dm-2, logical block 1342177264, async page read
[ 2681.592437] EXT4-fs (dm-2): unable to read superblock
[ 2681.592576] EXT4-fs (dm-2): unable to read superblock
[ 2681.592707] EXT4-fs (dm-2): unable to read superblock
[ 2681.592839] SQUASHFS error: squashfs_read_data failed to read block 0x0
[ 2681.592858] squashfs: SQUASHFS error: unable to read squashfs_super_block
[ 2682.661952] Buffer I/O error on dev dm-2, logical block 1342177264, async page read
[ 2682.667509] Buffer I/O error on dev dm-2, logical block 10737418112, async page read
[ 2682.667533] Buffer I/O error on dev dm-2, logical block 10737418113, async page read
[ 2682.667552] Buffer I/O error on dev dm-2, logical block 10737418114, async page read
[ 2682.667571] Buffer I/O error on dev dm-2, logical block 10737418115, async page read
[ 2682.667612] Buffer I/O error on dev dm-2, logical block 10737418116, async page read
[ 2682.667632] Buffer I/O error on dev dm-2, logical block 10737418117, async page read
[ 2682.667653] Buffer I/O error on dev dm-2, logical block 10737418118, async page read
[ 2682.911295] ------------[ cut here ]------------
[ 2682.911319] NETDEV WATCHDOG: eth4 (bnxt_en): transmit queue 0 timed out
[ 2682.911350] WARNING: CPU: 23 PID: 0 at /build/linux-hwe-eGX82t/linux-hwe-4.15.0/net/sched/sch_generic.c:323 dev_watchdog+0x222/0x230
[ 2682.911352] Modules linked in: dm_round_robin binfmt_misc cfg80211 xt_set xt_multiport iptable_raw iptable_mangle ip_set_hash_ip ip_set_hash_net ip_set ipip tunnel4 ip_tunnel veth xt_statistic xt_nat xt_recent ipt_REJECT nf_reject_ipv4 xt_tcpudp xt_addrtype ip_vs ipt_MASQUERADE nf_nat_masquerade_ipv4 xt_comment ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6_tables xt_mark iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 iptable_filter ip_tables xt_conntrack x_tables nf_nat nf_conntrack_netlink nfnetlink nf_conntrack xfrm_user xfrm_algo aufs bonding intel_rapl skx_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel ipmi_ssif kvm dcdbas irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel aes_x86_64 crypto_simd glue_helper cryptd in
tel_cstate
[ 2682.911430] intel_rapl_perf mei_me lpc_ich shpchp mei ipmi_si ipmi_devintf ipmi_msghandler acpi_power_meter mac_hid ib_iser rdma_cm iw_cm ib_cm ib_core iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi br_netfilter bridge stp llc dm_multipath autofs4 xfs bnx2x ptp mgag200 i2c_algo_bit ttm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops pps_core bnxt_en mdio drm devlink libcrc32c ahci libahci
[ 2682.911482] CPU: 23 PID: 0 Comm: swapper/23 Not tainted 4.15.0-24-generic #26~16.04.1-Ubuntu
[ 2682.911483] Hardware name: Dell Inc. PowerEdge R640/0W23H8, BIOS 1.3.7 02/08/2018
[ 2682.911487] RIP: 0010:dev_watchdog+0x222/0x230
[ 2682.911489] RSP: 0018:ffff91eaeeec3e68 EFLAGS: 00010282
[ 2682.911492] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
[ 2682.911493] RDX: 0000000000040400 RSI: 00000000000000f6 RDI: 0000000000000300
[ 2682.911495] RBP: ffff91eaeeec3e98 R08: 0000000000000001 R09: 000000000000071b
[ 2682.911497] R10: 0000000000000000 R11: 000000000000071b R12: 000000000000004a
[ 2682.911499] R13: ffff91aae1522000 R14: ffff91aae1522478 R15: ffff91aae066dbc0
[ 2682.911505] FS: 0000000000000000(0000) GS:ffff91eaeeec0000(0000) knlGS:0000000000000000
[ 2682.911507] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 2682.911509] CR2: 00007f86f4058384 CR3: 00000033bd20a005 CR4: 00000000007606e0
[ 2682.911511] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 2682.911513] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 2682.911514] PKRU: 55555554
[ 2682.911515] Call Trace:
[ 2682.911518] <IRQ>
[ 2682.911524] ? dev_deactivate_queue.constprop.33+0x60/0x60
[ 2682.911534] call_timer_fn+0x32/0x140
[ 2682.911539] run_timer_softirq+0x1ed/0x440
[ 2682.911543] ? ktime_get+0x3e/0xa0
[ 2682.911550] ? lapic_next_deadline+0x26/0x30
[ 2682.911559] __do_softirq+0xf2/0x288
[ 2682.911565] irq_exit+0xb6/0xc0
[ 2682.911569] smp_apic_timer_interrupt+0x71/0x140
[ 2682.911574] apic_timer_interrupt+0x84/0x90
[ 2682.911575] </IRQ>
[ 2682.911583] RIP: 0010:cpuidle_enter_state+0xa7/0x300
[ 2682.911585] RSP: 0018:ffffbac30c6efe60 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff11
[ 2682.911587] RAX: ffff91eaeeee2880 RBX: 0000000000000003 RCX: 000000000000001f
[ 2682.911589] RDX: 0000000000000000 RSI: 000000002f84dd9f RDI: 0000000000000000
[ 2682.911591] RBP: ffffbac30c6efe98 R08: ffff91eaeeee16a4 R09: 0000000000000018
[ 2682.911592] R10: ffffbac30c6efe30 R11: 000000000000266e R12: 0000000000000003
[ 2682.911594] R13: ffffdac2ff6c3138 R14: ffffffff85171d58 R15: 00000270a5abd299
[ 2682.911599] cpuidle_enter+0x17/0x20
[ 2682.911606] call_cpuidle+0x23/0x40
[ 2682.911610] do_idle+0x197/0x200
[ 2682.911614] cpu_startup_entry+0x73/0x80
[ 2682.911618] start_secondary+0x1ab/0x200
[ 2682.911623] secondary_startup_64+0xa5/0xb0
[ 2682.911626] Code: 38 00 49 63 4e e8 eb 92 4c 89 ef c6 05 76 f3 d8 00 01 e8 42 37 fd ff 89 d9 48 89 c2 4c 89 ee 48 c7 c7 78 9c d9 84 e8 1e b3 80 ff <0f> 0b eb c0 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48
[ 2682.911687] ---[ end trace a09e66b1b45bbbba ]---
[ 2682.911693] bnxt_en 0000:3b:00.0 eth4: TX timeout detected, starting reset task!
[ 2683.782496] bnxt_en 0000:3b:00.0 eth4: Resp cmpl intr err msg: 0x51
[ 2683.783061] bnxt_en 0000:3b:00.0 eth4: hwrm_ring_free tx failed. rc:-1
[ 2684.634557] bnxt_en 0000:3b:00.0 eth4: Resp cmpl intr err msg: 0x51
[ 2684.635120] bnxt_en 0000:3b:00.0 eth4: hwrm_ring_free tx failed. rc:-1
[ 2685.474679] bnxt_en 0000:3b:00.0 eth4: Resp cmpl intr err msg: 0x51
[ 2685.475188] bnxt_en 0000:3b:00.0 eth4: hwrm_ring_free tx failed. rc:-1
[ 2686.323579] bnxt_en 0000:3b:00.0 eth4: Resp cmpl intr err msg: 0x51
[ 2686.324072] bnxt_en 0000:3b:00.0 eth4: hwrm_ring_free tx failed. rc:-1
[ 2686.691126] print_req_error: 27 callbacks suppressed
[ 2686.691127] print_req_error: I/O error, dev dm-2, sector 10737418112
[ 2686.691604] print_req_error: I/O error, dev dm-2, sector 10737418112
[ 2686.692001] buffer_io_error: 10 callbacks suppressed
[ 2686.692002] Buffer I/O error on dev dm-2, logical block 1342177264, async page read
[ 2686.693881] print_req_error: I/O error, dev dm-2, sector 10737418112
[ 2686.694399] print_req_error: I/O error, dev dm-2, sector 10737418112
[ 2686.694856] Buffer I/O error on dev dm-2, logical block 10737418112, async page read
[ 2686.695298] print_req_error: I/O error, dev dm-2, sector 10737418113
[ 2686.695720] Buffer I/O error on dev dm-2, logical block 10737418113, async page read
[ 2686.696135] print_req_error: I/O error, dev dm-2, sector 10737418114
[ 2686.696545] Buffer I/O error on dev dm-2, logical block 10737418114, async page read
[ 2686.696962] print_req_error: I/O error, dev dm-2, sector 10737418115
[ 2686.697379] Buffer I/O error on dev dm-2, logical block 10737418115, async page read
[ 2686.697795] print_req_error: I/O error, dev dm-2, sector 10737418116
[ 2686.698223] Buffer I/O error on dev dm-2, logical block 10737418116, async page read
[ 2686.698637] print_req_error: I/O error, dev dm-2, sector 10737418117
[ 2686.699044] Buffer I/O error on dev dm-2, logical block 10737418117, async page read
[ 2686.699456] print_req_error: I/O error, dev dm-2, sector 10737418118
[ 2686.699869] Buffer I/O error on dev dm-2, logical block 10737418118, async page read
[ 2686.700291] Buffer I/O error on dev dm-2, logical block 10737418119, async page read
[ 2687.162049] bnxt_en 0000:3b:00.0 eth4: Resp cmpl intr err msg: 0x51
[ 2687.162552] bnxt_en 0000:3b:00.0 eth4: hwrm_ring_free tx failed. rc:-1
[ 2688.001911] bnxt_en 0000:3b:00.0 eth4: Resp cmpl intr err msg: 0x51
[ 2688.002335] bnxt_en 0000:3b:00.0 eth4: hwrm_ring_free rx failed. rc:-1
[ 2688.836936] bnxt_en 0000:3b:00.0 eth4: Resp cmpl intr err msg: 0x51
[ 2688.837357] bnxt_en 0000:3b:00.0 eth4: hwrm_ring_free rx failed. rc:-1
[ 2689.670237] bnxt_en 0000:3b:00.0 eth4: Resp cmpl intr err msg: 0x51
[ 2689.670617] bnxt_en 0000:3b:00.0 eth4: hwrm_ring_free rx failed. rc:-1
[ 2690.519733] bnxt_en 0000:3b:00.0 eth4: Resp cmpl intr err msg: 0x51
[ 2690.520109] bnxt_en 0000:3b:00.0 eth4: hwrm_ring_free rx failed. rc:-1
[ 2691.142178] Buffer I/O error on dev dm-2, logical block 1342177264, async page read
[ 2691.358094] bnxt_en 0000:3b:00.0 eth4: Resp cmpl intr err msg: 0x51
[ 2691.358503] bnxt_en 0000:3b:00.0 eth4: hwrm_ring_free rx failed. rc:-1
[ 2692.210710] bnxt_en 0000:3b:00.0 eth4: Resp cmpl intr err msg: 0x51
[ 2692.211091] bnxt_en 0000:3b:00.0 eth4: hwrm_ring_free rx failed. rc:-1
[ 2693.052607] bnxt_en 0000:3b:00.0 eth4: Resp cmpl intr err msg: 0x51
[ 2693.053029] bnxt_en 0000:3b:00.0 eth4: hwrm_ring_free rx failed. rc:-1
[ 2693.907808] bnxt_en 0000:3b:00.0 eth4: Resp cmpl intr err msg: 0x51
[ 2693.908233] bnxt_en 0000:3b:00.0 eth4: hwrm_ring_free rx failed. rc:-1
[ 2694.761187] bnxt_en 0000:3b:00.0 eth4: Resp cmpl intr err msg: 0x51
[ 2694.761626] bnxt_en 0000:3b:00.0 eth4: hwrm_ring_free rx failed. rc:-1
[ 2695.609620] bnxt_en 0000:3b:00.0 eth4: Resp cmpl intr err msg: 0x51
[ 2695.610055] bnxt_en 0000:3b:00.0 eth4: hwrm_ring_free rx failed. rc:-1
[ 2696.450508] bnxt_en 0000:3b:00.0 eth4: Resp cmpl intr err msg: 0x51
[ 2696.450939] bnxt_en 0000:3b:00.0 eth4: hwrm_ring_free rx failed. rc:-1
[ 2697.293569] bnxt_en 0000:3b:00.0 eth4: Resp cmpl intr err msg: 0x51
[ 2697.294007] bnxt_en 0000:3b:00.0 eth4: hwrm_ring_free rx failed. rc:-1
[ 2698.138408] bnxt_en 0000:3b:00.0 eth4: Resp cmpl intr err msg: 0x51
[ 2698.138854] bnxt_en 0000:3b:00.0 eth4: hwrm_ring_free rx failed. rc:-1
[ 2698.992525] bnxt_en 0000:3b:00.0 eth4: Resp cmpl intr err msg: 0x51
[ 2698.992979] bnxt_en 0000:3b:00.0 eth4: hwrm_ring_free rx failed. rc:-1
[ 2699.605100] print_req_error: 12 callbacks suppressed
[ 2699.605111] print_req_error: I/O error, dev dm-2, sector 10737418112
[ 2699.605680] print_req_error: I/O error, dev dm-2, sector 10737418112
[ 2699.606212] buffer_io_error: 8 callbacks suppressed
[ 2699.606213] Buffer I/O error on dev dm-2, logical block 1342177264, async page read
[ 2699.608144] print_req_error: I/O error, dev dm-2, sector 10737418112
[ 2699.608722] print_req_error: I/O error, dev dm-2, sector 10737418112
[ 2699.609168] Buffer I/O error on dev dm-2, logical block 10737418112, async page read
[ 2699.609581] print_req_error: I/O error, dev dm-2, sector 10737418113
[ 2699.609987] Buffer I/O error on dev dm-2, logical block 10737418113, async page read
[ 2699.610422] print_req_error: I/O error, dev dm-2, sector 10737418114
[ 2699.610855] Buffer I/O error on dev dm-2, logical block 10737418114, async page read
[ 2699.611294] print_req_error: I/O error, dev dm-2, sector 10737418115
[ 2699.611727] Buffer I/O error on dev dm-2, logical block 10737418115, async page read
[ 2699.612133] print_req_error: I/O error, dev dm-2, sector 10737418116
[ 2699.612572] Buffer I/O error on dev dm-2, logical block 10737418116, async page read
[ 2699.612991] print_req_error: I/O error, dev dm-2, sector 10737418117
[ 2699.613407] Buffer I/O error on dev dm-2, logical block 10737418117, async page read
[ 2699.613836] print_req_error: I/O error, dev dm-2, sector 10737418118
[ 2699.614261] Buffer I/O error on dev dm-2, logical block 10737418118, async page read
[ 2699.614803] Buffer I/O error on dev dm-2, logical block 10737418119, async page read
[ 2699.845546] bnxt_en 0000:3b:00.0 eth4: Resp cmpl intr err msg: 0x51
[ 2699.846018] bnxt_en 0000:3b:00.0 eth4: hwrm_ring_free rx failed. rc:-1
[ 2700.688086] bnxt_en 0000:3b:00.0 eth4: Resp cmpl intr err msg: 0x51
[ 2700.688563] bnxt_en 0000:3b:00.0 eth4: hwrm_ring_free rx failed. rc:-1
[ 2701.523722] bnxt_en 0000:3b:00.0 eth4: Error (timeout: 500) msg {0x51 0xb6b} len:0
[ 2701.524174] bnxt_en 0000:3b:00.0 eth4: hwrm_ring_free cp failed. rc:-1
[ 2702.368502] bnxt_en 0000:3b:00.0 eth4: Error (timeout: 500) msg {0x51 0xb6c} len:0
[ 2702.368952] bnxt_en 0000:3b:00.0 eth4: hwrm_ring_free cp failed. rc:-1
[ 2703.222505] bnxt_en 0000:3b:00.0 eth4: Error (timeout: 500) msg {0x51 0xb6d} len:0
[ 2703.222945] bnxt_en 0000:3b:00.0 eth4: hwrm_ring_free cp failed. rc:-1
[ 2704.078981] bnxt_en 0000:3b:00.0 eth4: Error (timeout: 500) msg {0x51 0xb6e} len:0
[ 2704.079748] bnxt_en 0000:3b:00.0 eth4: hwrm_ring_free cp failed. rc:-1
[ 2704.913958] bnxt_en 0000:3b:00.0 eth4: Error (timeout: 500) msg {0x51 0xb6f} len:0
[ 2704.914393] bnxt_en 0000:3b:00.0 eth4: hwrm_ring_free cp failed. rc:-1
[ 2705.764961] bnxt_en 0000:3b:00.0 eth4: Error (timeout: 500) msg {0x51 0xb70} len:0
[ 2705.765400] bnxt_en 0000:3b:00.0 eth4: hwrm_ring_free cp failed. rc:-1
[ 2706.613411] bnxt_en 0000:3b:00.0 eth4: Error (timeout: 500) msg {0x51 0xb71} len:0
[ 2706.613839] bnxt_en 0000:3b:00.0 eth4: hwrm_ring_free cp failed. rc:-1
[ 2707.454748] bnxt_en 0000:3b:00.0 eth4: Error (timeout: 500) msg {0x51 0xb72} len:0
[ 2707.455187] bnxt_en 0000:3b:00.0 eth4: hwrm_ring_free cp failed. rc:-1
[ 2708.306362] bnxt_en 0000:3b:00.0 eth4: Error (timeout: 500) msg {0x61 0xb73} len:0
[ 2709.150419] bnxt_en 0000:3b:00.0 eth4: Error (timeout: 500) msg {0x50 0xb74} len:0
[ 2709.150880] bnxt_en 0000:3b:00.0 eth4: Invalid ring
[ 2709.151318] bnxt_en 0000:3b:00.0 eth4: hwrm ring alloc failure rc: ffffffff
[ 2709.989131] bnxt_en 0000:3b:00.0 eth4: Error (timeout: 500) msg {0x44 0xb75} len:0
[ 2709.989635] bnxt_en 0000:3b:00.0 eth4: hwrm vnic set tpa failure rc for vnic 0: ffffffff
[ 2710.826136] bnxt_en 0000:3b:00.0 eth4: Error (timeout: 500) msg {0xb1 0xb76} len:0
[ 2710.826671] bnxt_en 0000:3b:00.0 eth4: bnxt_init_nic err: ffffffff
[ 2710.831139] bnxt_en 0000:3b:00.0 eth4: nic open fail (rc: ffffffff)
[ 2711.680497] bnxt_en 0000:3b:00.0 eth4: Error (timeout: 500) msg {0x20 0xb77} len:0
[ 2711.694743] bond1: link status definitely down for interface eth4, disabling it
[ 2711.694745] bond1: making interface eth5 the new active one
[ 2712.521953] bnxt_en 0000:3b:00.1 eth5: Error (timeout: 500) msg {0x23 0xaa2} len:0
[ 2713.363445] bnxt_en 0000:3b:00.1 eth5: Error (timeout: 500) msg {0x93 0xaa3} len:0
[ 2713.364096] bnxt_en 0000:3b:00.1 eth5: HWRM cfa l2 rx mask failure rc: ffffffff
[ 2714.213610] bnxt_en 0000:3b:00.1 eth5: Error (timeout: 500) msg {0x23 0xaa4} len:0
[ 2714.946281] device-mapper: multipath: Reinstating path 8:32.
[ 2714.946353] device-mapper: multipath: Reinstating path 8:48.
[ 2714.946409] device-mapper: multipath: Reinstating path 8:16.
[ 2715.052045] bnxt_en 0000:3b:00.1 eth5: Error (timeout: 500) msg {0x23 0xaa5} len:0
[ 2715.892140] bnxt_en 0000:3b:00.1 eth5: Error (timeout: 500) msg {0x23 0xaa6} len:0
[ 2715.987424] XFS (dm-2): Mounting V5 Filesystem
[ 2716.003187] XFS (dm-2): Starting recovery (logdev: internal)
[ 2716.018293] XFS (dm-2): Ending recovery (logdev: internal)
[ 2716.735471] bnxt_en 0000:3b:00.1 eth5: Error (timeout: 500) msg {0x23 0xaa7} len:0
[ 2717.575403] bnxt_en 0000:3b:00.1 eth5: Error (timeout: 500) msg {0x23 0xaa8} len:0
[ 2718.459295] bnxt_en 0000:3b:00.1 eth5: Error (timeout: 500) msg {0x23 0xaa9} len:0
[ 2719.487382] bnxt_en 0000:3b:00.1 eth5: Error (timeout: 500) msg {0x23 0xaaa} len:0
[ 2720.517072] bnxt_en 0000:3b:00.1 eth5: Error (timeout: 500) msg {0x23 0xaab} len:0
[ 2721.525248] bnxt_en 0000:3b:00.1 eth5: Error (timeout: 500) msg {0x23 0xaac} len:0
[ 2722.548765] bnxt_en 0000:3b:00.1 eth5: Error (timeout: 500) msg {0x23 0xaad} len:0
[ 2723.572190] bnxt_en 0000:3b:00.1 eth5: Error (timeout: 500) msg {0x23 0xaae} len:0
[ 2724.609428] bnxt_en 0000:3b:00.1 eth5: Error (timeout: 500) msg {0x23 0xaaf} len:0
[ 2724.882745] connection4:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4295571130, last ping 4295572416, now 4295573696
[ 2724.883488] connection4:0: detected conn error (1022)
[ 2725.629310] bnxt_en 0000:3b:00.1 eth5: Error (timeout: 500) msg {0x23 0xab0} len:0
[ 2726.657752] bnxt_en 0000:3b:00.1 eth5: Error (timeout: 500) msg {0x23 0xab1} len:0
[ 2727.680069] bnxt_en 0000:3b:00.1 eth5: Error (timeout: 500) msg {0x23 0xab2} len:0
[ 2728.705973] bnxt_en 0000:3b:00.1 eth5: Error (timeout: 500) msg {0x23 0xab3} len:0
[ 2729.489387] bnxt_en 0000:3b:00.1 eth5: TX timeout detected, starting reset task!
[ 2729.726626] bnxt_en 0000:3b:00.1 eth5: Error (timeout: 500) msg {0x23 0xab4} len:0
...
[ 2744.875420] bnxt_en 0000:3b:00.1 eth5: Resp cmpl intr err msg: 0x51
[ 2744.875775] bnxt_en 0000:3b:00.1 eth5: hwrm_ring_free tx failed. rc:-1
[ 2745.726024] bnxt_en 0000:3b:00.1 eth5: Resp cmpl intr err msg: 0x51
[ 2745.726346] bnxt_en 0000:3b:00.1 eth5: hwrm_ring_free tx failed. rc:-1
[ 2746.579434] bnxt_en 0000:3b:00.1 eth5: Resp cmpl intr err msg: 0x51
[ 2746.579709] bnxt_en 0000:3b:00.1 eth5: hwrm_ring_free tx failed. rc:-1
[ 2747.430915] bnxt_en 0000:3b:00.1 eth5: Resp cmpl intr err msg: 0x51
[ 2747.431197] bnxt_en 0000:3b:00.1 eth5: hwrm_ring_free tx failed. rc:-1
[ 2748.285855] bnxt_en 0000:3b:00.1 eth5: Resp cmpl intr err msg: 0x51
[ 2748.286132] bnxt_en 0000:3b:00.1 eth5: hwrm_ring_free rx failed. rc:-1
[ 2749.141919] bnxt_en 0000:3b:00.1 eth5: Resp cmpl intr err msg: 0x51
[ 2749.142170] bnxt_en 0000:3b:00.1 eth5: hwrm_ring_free rx failed. rc:-1
[ 2749.986850] bnxt_en 0000:3b:00.1 eth5: Resp cmpl intr err msg: 0x51
[ 2749.987190] bnxt_en 0000:3b:00.1 eth5: hwrm_ring_free rx failed. rc:-1
[ 2750.821519] bnxt_en 0000:3b:00.1 eth5: Resp cmpl intr err msg: 0x51
[ 2750.821848] bnxt_en 0000:3b:00.1 eth5: hwrm_ring_free rx failed. rc:-1
[ 2751.657391] bnxt_en 0000:3b:00.1 eth5: Resp cmpl intr err msg: 0x51
[ 2751.657709] bnxt_en 0000:3b:00.1 eth5: hwrm_ring_free rx failed. rc:-1
[ 2752.512205] bnxt_en 0000:3b:00.1 eth5: Resp cmpl intr err msg: 0x51
[ 2752.512543] bnxt_en 0000:3b:00.1 eth5: hwrm_ring_free rx failed. rc:-1
[ 2753.352293] bnxt_en 0000:3b:00.1 eth5: Resp cmpl intr err msg: 0x51
[ 2753.352613] bnxt_en 0000:3b:00.1 eth5: hwrm_ring_free rx failed. rc:-1
[ 2754.187621] bnxt_en 0000:3b:00.1 eth5: Resp cmpl intr err msg: 0x51
[ 2754.187946] bnxt_en 0000:3b:00.1 eth5: hwrm_ring_free rx failed. rc:-1
[ 2755.022193] bnxt_en 0000:3b:00.1 eth5: Resp cmpl intr err msg: 0x51
[ 2755.022524] bnxt_en 0000:3b:00.1 eth5: hwrm_ring_free rx failed. rc:-1
[ 2755.856013] bnxt_en 0000:3b:00.1 eth5: Resp cmpl intr err msg: 0x51
[ 2755.856329] bnxt_en 0000:3b:00.1 eth5: hwrm_ring_free rx failed. rc:-1
[ 2756.694497] bnxt_en 0000:3b:00.1 eth5: Resp cmpl intr err msg: 0x51
[ 2756.694840] bnxt_en 0000:3b:00.1 eth5: hwrm_ring_free rx failed. rc:-1
[ 2757.527374] bnxt_en 0000:3b:00.1 eth5: Resp cmpl intr err msg: 0x51
[ 2757.527732] bnxt_en 0000:3b:00.1 eth5: hwrm_ring_free rx failed. rc:-1
[ 2758.363738] bnxt_en 0000:3b:00.1 eth5: Resp cmpl intr err msg: 0x51
[ 2758.364115] bnxt_en 0000:3b:00.1 eth5: hwrm_ring_free rx failed. rc:-1
[ 2759.215324] bnxt_en 0000:3b:00.1 eth5: Resp cmpl intr err msg: 0x51
[ 2759.215701] bnxt_en 0000:3b:00.1 eth5: hwrm_ring_free rx failed. rc:-1
[ 2760.061181] bnxt_en 0000:3b:00.1 eth5: Resp cmpl intr err msg: 0x51
[ 2760.061552] bnxt_en 0000:3b:00.1 eth5: hwrm_ring_free rx failed. rc:-1
[ 2760.898309] bnxt_en 0000:3b:00.1 eth5: Resp cmpl intr err msg: 0x51
[ 2760.898673] bnxt_en 0000:3b:00.1 eth5: hwrm_ring_free rx failed. rc:-1
[ 2761.732935] bnxt_en 0000:3b:00.1 eth5: Error (timeout: 500) msg {0x51 0xada} len:0
[ 2761.733303] bnxt_en 0000:3b:00.1 eth5: hwrm_ring_free cp failed. rc:-1
[ 2762.573293] bnxt_en 0000:3b:00.1 eth5: Error (timeout: 500) msg {0x51 0xadb} len:0
[ 2762.573700] bnxt_en 0000:3b:00.1 eth5: hwrm_ring_free cp failed. rc:-1
[ 2763.407002] bnxt_en 0000:3b:00.1 eth5: Error (timeout: 500) msg {0x51 0xadc} len:0
[ 2763.407411] bnxt_en 0000:3b:00.1 eth5: hwrm_ring_free cp failed. rc:-1
[ 2764.255762] bnxt_en 0000:3b:00.1 eth5: Error (timeout: 500) msg {0x51 0xadd} len:0
[ 2764.256162] bnxt_en 0000:3b:00.1 eth5: hwrm_ring_free cp failed. rc:-1
[ 2765.100554] bnxt_en 0000:3b:00.1 eth5: Error (timeout: 500) msg {0x51 0xade} len:0
[ 2765.100947] bnxt_en 0000:3b:00.1 eth5: hwrm_ring_free cp failed. rc:-1
[ 2765.941308] bnxt_en 0000:3b:00.1 eth5: Error (timeout: 500) msg {0x51 0xadf} len:0
[ 2765.941712] bnxt_en 0000:3b:00.1 eth5: hwrm_ring_free cp failed. rc:-1
[ 2766.793534] bnxt_en 0000:3b:00.1 eth5: Error (timeout: 500) msg {0x51 0xae0} len:0
[ 2766.794015] bnxt_en 0000:3b:00.1 eth5: hwrm_ring_free cp failed. rc:-1
[ 2767.642247] bnxt_en 0000:3b:00.1 eth5: Error (timeout: 500) msg {0x51 0xae1} len:0
[ 2767.642630] bnxt_en 0000:3b:00.1 eth5: hwrm_ring_free cp failed. rc:-1
[ 2768.496229] bnxt_en 0000:3b:00.1 eth5: Error (timeout: 500) msg {0x61 0xae2} len:0
[ 2769.356587] bnxt_en 0000:3b:00.1 eth5: Error (timeout: 500) msg {0x50 0xae3} len:0
[ 2769.356939] bnxt_en 0000:3b:00.1 eth5: Invalid ring
[ 2769.357277] bnxt_en 0000:3b:00.1 eth5: hwrm ring alloc failure rc: ffffffff
[ 2770.215233] bnxt_en 0000:3b:00.1 eth5: Error (timeout: 500) msg {0x44 0xae4} len:0
[ 2770.215619] bnxt_en 0000:3b:00.1 eth5: hwrm vnic set tpa failure rc for vnic 0: ffffffff
[ 2771.073430] bnxt_en 0000:3b:00.1 eth5: Error (timeout: 500) msg {0xb1 0xae5} len:0
[ 2771.073803] bnxt_en 0000:3b:00.1 eth5: bnxt_init_nic err: ffffffff
[ 2771.076758] bnxt_en 0000:3b:00.1 eth5: nic open fail (rc: ffffffff)
[ 2771.925191] bnxt_en 0000:3b:00.1 eth5: Error (timeout: 500) msg {0x20 0xae6} len:0
[ 2771.936019] bond1: link status definitely down for interface eth5, disabling it
[ 2771.936023] bond1: now running without any active interface!
^ permalink raw reply
* Re: [PATCH stable 4.4 1/9] Revert "tcp: detect malicious patterns in tcp_collapse_ofo_queue()"
From: Greg KH @ 2018-08-16 6:04 UTC (permalink / raw)
To: maowenan; +Cc: dwmw2, netdev, eric.dumazet, edumazet, davem, ycheng, jdw
In-Reply-To: <865f3aa5-e763-a5fe-9ab0-eab42e0fc310@huawei.com>
On Thu, Aug 16, 2018 at 09:55:42AM +0800, maowenan wrote:
>
>
> On 2018/8/15 21:18, Greg KH wrote:
> > On Wed, Aug 15, 2018 at 09:21:00PM +0800, Mao Wenan wrote:
> >> This reverts commit dc6ae4dffd656811dee7151b19545e4cd839d378.
> >
> > I need a reason why, and a signed-off-by line :(
>
> stable 4.4 only back port two patches to fix CVE-2018-5390, I have tested they can't
> fix fully because of simple queue used in lower version, so we need change simple queue
> to RB tree to finally resolve. But 9f5afeae have many conflicts with tcp: detect malicious patterns in tcp_collapse_ofo_queue()
> and tcp: avoid collapses in tcp_prune_queue() if possible, and there are patch series from Eric in mainline to fix CVE-2018-5390,
> so I need revert part of patches in stable 4.4 firstly, then apply 9f5afeae, and reapply five patches from Eric.
> 9f5afeae tcp: use an RB tree for ooo receive queue
Then please put this information in the changelog text, that's what we
need to see here.
thanks,
greg k-h
^ permalink raw reply
* Re: bnxt: card intermittently hanging and dropping link
From: Michael Chan @ 2018-08-16 6:29 UTC (permalink / raw)
To: Daniel Axtens; +Cc: Netdev, jay.vosburgh
In-Reply-To: <87o9e26fqj.fsf@linkitivity.dja.id.au>
On Wed, Aug 15, 2018 at 10:29 PM, Daniel Axtens <dja@axtens.net> wrote:
> [ 2682.911295] ------------[ cut here ]------------
> [ 2682.911319] NETDEV WATCHDOG: eth4 (bnxt_en): transmit queue 0 timed out
The main issue is the TX timeout.
.....
> [ 2682.911693] bnxt_en 0000:3b:00.0 eth4: TX timeout detected, starting reset task!
> [ 2683.782496] bnxt_en 0000:3b:00.0 eth4: Resp cmpl intr err msg: 0x51
> [ 2683.783061] bnxt_en 0000:3b:00.0 eth4: hwrm_ring_free tx failed. rc:-1
> [ 2684.634557] bnxt_en 0000:3b:00.0 eth4: Resp cmpl intr err msg: 0x51
> [ 2684.635120] bnxt_en 0000:3b:00.0 eth4: hwrm_ring_free tx failed. rc:-1
and it is not recovering.
Please provide ethtool -i eth4 which will show the firmware version on
the NIC. Let's see if the firmware is too old.
Thanks.
^ permalink raw reply
* Re: [PATCH v1 2/3] zinc: Introduce minimal cryptography library
From: Jason A. Donenfeld @ 2018-08-16 6:31 UTC (permalink / raw)
To: Eric Biggers
Cc: Eric Biggers, Linux Crypto Mailing List, LKML, Netdev,
David Miller, Andrew Lutomirski, Greg Kroah-Hartman, Samuel Neves,
Daniel J . Bernstein, Tanja Lange, Jean-Philippe Aumasson,
Karthikeyan Bhargavan
In-Reply-To: <20180814211229.GB24575@gmail.com>
Hi Eric,
On Tue, Aug 14, 2018 at 2:12 PM Eric Biggers <ebiggers@kernel.org> wrote:
> On ARM Cortex-A7, OpenSSL's ChaCha20 implementation is 13.9 cpb (cycles per
> byte), whereas Linux's is faster: 11.9 cpb.
>
> The reason Linux's ChaCha20 NEON implementation is faster than OpenSSL's
>
> I understand there are tradeoffs, and different implementations can be faster on
> different CPUs.
>
> So if your proposal goes in, I'd likely need to write a patch
> to get the old performance back, at least on Cortex-A7...
Yes, absolutely. Different CPUs behave differently indeed, but if you
have improvements for hardware that matters to you, we should
certainly incorporate these, and also loop Andy Polyakov in (I've
added him to the CC for the WIP v2). ChaCha is generally pretty
obvious, but for big integer algorithms -- like Poly1305 and
Curve25519 -- I think it's all the more important to involve Andy and
the rest of the world in general, so that Linux benefits from bug
research and fuzzing in places that are typically and classically
prone to nasty issues. In other words, let's definitely incorporate
your improvements after the patchset goes in, and at the same time
we'll try to bring Andy and others into the fold, where our
improvements can generally track each others.
> Also, I don't know whether Andy P. considered the 4xNEON implementation
> technique. It could even be fastest on other ARM CPUs too, I don't know.
After v2, when he's CC'd in, let's plan to start discussing this with him.
Jason
^ permalink raw reply
* [PATCH] net: phy: add tracepoints
From: Tobias Waldekranz @ 2018-08-16 9:30 UTC (permalink / raw)
To: Tobias Waldekranz
Cc: Andrew Lunn, Florian Fainelli, David S. Miller, Steven Rostedt,
Ingo Molnar, open list, open list:ETHERNET PHY LIBRARY
Two tracepoints for now:
* `phy_interrupt` Pretty self-explanatory.
* `phy_state_change` Whenever the PHY's state machine is run, trace
the old and the new state.
Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
---
drivers/net/phy/phy.c | 4 +++
include/trace/events/phy.h | 68 ++++++++++++++++++++++++++++++++++++++
2 files changed, 72 insertions(+)
create mode 100644 include/trace/events/phy.h
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index 9aabfa1a455a..8d22926f3962 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -38,6 +38,9 @@
#include <asm/irq.h>
+#define CREATE_TRACE_POINTS
+#include <trace/events/phy.h>
+
#define PHY_STATE_STR(_state) \
case PHY_##_state: \
return __stringify(_state); \
@@ -1039,6 +1042,7 @@ void phy_state_machine(struct work_struct *work)
if (err < 0)
phy_error(phydev);
+ trace_phy_state_change(phydev, old_state);
if (old_state != phydev->state)
phydev_dbg(phydev, "PHY state change %s -> %s\n",
phy_state_to_str(old_state),
diff --git a/include/trace/events/phy.h b/include/trace/events/phy.h
new file mode 100644
index 000000000000..7ba6c0dda47e
--- /dev/null
+++ b/include/trace/events/phy.h
@@ -0,0 +1,68 @@
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM phy
+
+#if !defined(_TRACE_PHY_H) || defined(TRACE_HEADER_MULTI_READ)
+#define _TRACE_PHY_H
+
+#include <linux/tracepoint.h>
+
+TRACE_EVENT(phy_interrupt,
+ TP_PROTO(int irq, struct phy_device *phydev),
+ TP_ARGS(irq, phydev),
+ TP_STRUCT__entry(
+ __field(int, irq)
+ __field(int, addr)
+ __field(int, state)
+ __array(char, ifname, IFNAMSIZ)
+ ),
+ TP_fast_assign(
+ __entry->irq = irq;
+ __entry->addr = phydev->mdio.addr;
+ __entry->state = phydev->state;
+ if (phydev->attached_dev)
+ memcpy(__entry->ifname,
+ netdev_name(phydev->attached_dev),
+ IFNAMSIZ);
+ else
+ memset(__entry->ifname, 0, IFNAMSIZ);
+ ),
+ TP_printk("phy-%d-irq irq=%d ifname=%16s state=%d",
+ __entry->addr,
+ __entry->irq,
+ __entry->ifname,
+ __entry->state
+ )
+ );
+
+TRACE_EVENT(phy_state_change,
+ TP_PROTO(struct phy_device *phydev, enum phy_state old_state),
+ TP_ARGS(phydev, old_state),
+ TP_STRUCT__entry(
+ __field(int, addr)
+ __field(int, state)
+ __field(int, old_state)
+ __array(char, ifname, IFNAMSIZ)
+ ),
+ TP_fast_assign(
+ __entry->addr = phydev->mdio.addr;
+ __entry->state = phydev->state;
+ __entry->old_state = old_state;
+ if (phydev->attached_dev)
+ memcpy(__entry->ifname,
+ netdev_name(phydev->attached_dev),
+ IFNAMSIZ);
+ else
+ memset(__entry->ifname, 0, IFNAMSIZ);
+ ),
+ TP_printk("phy-%d-change ifname=%16s old_state=%d state=%d",
+ __entry->addr,
+ __entry->ifname,
+ __entry->old_state,
+ __entry->state
+ )
+ );
+
+#endif /* _TRACE_PHY_H */
+
+/* This part must be outside protection */
+#include <trace/define_trace.h>
--
2.17.1
^ permalink raw reply related
* [PATCH] net: phy: add tracepoints
From: Tobias Waldekranz @ 2018-08-16 9:34 UTC (permalink / raw)
To: tobias
Cc: Andrew Lunn, Florian Fainelli, David S. Miller, Steven Rostedt,
Ingo Molnar, open list, open list:ETHERNET PHY LIBRARY
Two tracepoints for now:
* `phy_interrupt` Pretty self-explanatory.
* `phy_state_change` Whenever the PHY's state machine is run, trace
the old and the new state.
Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
---
drivers/net/phy/phy.c | 4 +++
include/trace/events/phy.h | 68 ++++++++++++++++++++++++++++++++++++++
2 files changed, 72 insertions(+)
create mode 100644 include/trace/events/phy.h
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index 9aabfa1a455a..8d22926f3962 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -38,6 +38,9 @@
#include <asm/irq.h>
+#define CREATE_TRACE_POINTS
+#include <trace/events/phy.h>
+
#define PHY_STATE_STR(_state) \
case PHY_##_state: \
return __stringify(_state); \
@@ -1039,6 +1042,7 @@ void phy_state_machine(struct work_struct *work)
if (err < 0)
phy_error(phydev);
+ trace_phy_state_change(phydev, old_state);
if (old_state != phydev->state)
phydev_dbg(phydev, "PHY state change %s -> %s\n",
phy_state_to_str(old_state),
diff --git a/include/trace/events/phy.h b/include/trace/events/phy.h
new file mode 100644
index 000000000000..7ba6c0dda47e
--- /dev/null
+++ b/include/trace/events/phy.h
@@ -0,0 +1,68 @@
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM phy
+
+#if !defined(_TRACE_PHY_H) || defined(TRACE_HEADER_MULTI_READ)
+#define _TRACE_PHY_H
+
+#include <linux/tracepoint.h>
+
+TRACE_EVENT(phy_interrupt,
+ TP_PROTO(int irq, struct phy_device *phydev),
+ TP_ARGS(irq, phydev),
+ TP_STRUCT__entry(
+ __field(int, irq)
+ __field(int, addr)
+ __field(int, state)
+ __array(char, ifname, IFNAMSIZ)
+ ),
+ TP_fast_assign(
+ __entry->irq = irq;
+ __entry->addr = phydev->mdio.addr;
+ __entry->state = phydev->state;
+ if (phydev->attached_dev)
+ memcpy(__entry->ifname,
+ netdev_name(phydev->attached_dev),
+ IFNAMSIZ);
+ else
+ memset(__entry->ifname, 0, IFNAMSIZ);
+ ),
+ TP_printk("phy-%d-irq irq=%d ifname=%16s state=%d",
+ __entry->addr,
+ __entry->irq,
+ __entry->ifname,
+ __entry->state
+ )
+ );
+
+TRACE_EVENT(phy_state_change,
+ TP_PROTO(struct phy_device *phydev, enum phy_state old_state),
+ TP_ARGS(phydev, old_state),
+ TP_STRUCT__entry(
+ __field(int, addr)
+ __field(int, state)
+ __field(int, old_state)
+ __array(char, ifname, IFNAMSIZ)
+ ),
+ TP_fast_assign(
+ __entry->addr = phydev->mdio.addr;
+ __entry->state = phydev->state;
+ __entry->old_state = old_state;
+ if (phydev->attached_dev)
+ memcpy(__entry->ifname,
+ netdev_name(phydev->attached_dev),
+ IFNAMSIZ);
+ else
+ memset(__entry->ifname, 0, IFNAMSIZ);
+ ),
+ TP_printk("phy-%d-change ifname=%16s old_state=%d state=%d",
+ __entry->addr,
+ __entry->ifname,
+ __entry->old_state,
+ __entry->state
+ )
+ );
+
+#endif /* _TRACE_PHY_H */
+
+/* This part must be outside protection */
+#include <trace/define_trace.h>
--
2.17.1
^ permalink raw reply related
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