* [PATCH net-next 3/8] tcp: simpler NewReno implementation
From: Yuchung Cheng @ 2018-05-16 23:40 UTC (permalink / raw)
To: davem; +Cc: netdev, edumazet, ncardwell, soheil, priyarjha, Yuchung Cheng
In-Reply-To: <20180516234017.172775-1-ycheng@google.com>
This is a rewrite of NewReno loss recovery implementation that is
simpler and standalone for readability and better performance by
using less states.
Note that NewReno refers to RFC6582 as a modification to the fast
recovery algorithm. It is used only if the connection does not
support SACK in Linux. It should not to be confused with the Reno
(AIMD) congestion control.
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Soheil Hassas Yeganeh <soheil@google.com>
Reviewed-by: Priyaranjan Jha <priyarjha@google.com>
---
include/net/tcp.h | 1 +
net/ipv4/tcp_input.c | 19 +++++++++++--------
net/ipv4/tcp_recovery.c | 27 +++++++++++++++++++++++++++
3 files changed, 39 insertions(+), 8 deletions(-)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 85000c85ddcd..d7f81325bee5 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -1878,6 +1878,7 @@ void tcp_v4_init(void);
void tcp_init(void);
/* tcp_recovery.c */
+void tcp_newreno_mark_lost(struct sock *sk, bool snd_una_advanced);
extern void tcp_rack_mark_lost(struct sock *sk);
extern void tcp_rack_advance(struct tcp_sock *tp, u8 sacked, u32 end_seq,
u64 xmit_time);
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index ccbe04f80040..076206873e3e 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -2223,9 +2223,7 @@ static void tcp_update_scoreboard(struct sock *sk, int fast_rexmit)
{
struct tcp_sock *tp = tcp_sk(sk);
- if (tcp_is_reno(tp)) {
- tcp_mark_head_lost(sk, 1, 1);
- } else {
+ if (tcp_is_sack(tp)) {
int sacked_upto = tp->sacked_out - tp->reordering;
if (sacked_upto >= 0)
tcp_mark_head_lost(sk, sacked_upto, 0);
@@ -2723,11 +2721,16 @@ static bool tcp_try_undo_partial(struct sock *sk, u32 prior_snd_una)
return false;
}
-static void tcp_rack_identify_loss(struct sock *sk, int *ack_flag)
+static void tcp_identify_packet_loss(struct sock *sk, int *ack_flag)
{
struct tcp_sock *tp = tcp_sk(sk);
- if (tcp_is_rack(sk)) {
+ if (tcp_rtx_queue_empty(sk))
+ return;
+
+ if (unlikely(tcp_is_reno(tp))) {
+ tcp_newreno_mark_lost(sk, *ack_flag & FLAG_SND_UNA_ADVANCED);
+ } else if (tcp_is_rack(sk)) {
u32 prior_retrans = tp->retrans_out;
tcp_rack_mark_lost(sk);
@@ -2823,11 +2826,11 @@ static void tcp_fastretrans_alert(struct sock *sk, const u32 prior_snd_una,
tcp_try_keep_open(sk);
return;
}
- tcp_rack_identify_loss(sk, ack_flag);
+ tcp_identify_packet_loss(sk, ack_flag);
break;
case TCP_CA_Loss:
tcp_process_loss(sk, flag, is_dupack, rexmit);
- tcp_rack_identify_loss(sk, ack_flag);
+ tcp_identify_packet_loss(sk, ack_flag);
if (!(icsk->icsk_ca_state == TCP_CA_Open ||
(*ack_flag & FLAG_LOST_RETRANS)))
return;
@@ -2844,7 +2847,7 @@ static void tcp_fastretrans_alert(struct sock *sk, const u32 prior_snd_una,
if (icsk->icsk_ca_state <= TCP_CA_Disorder)
tcp_try_undo_dsack(sk);
- tcp_rack_identify_loss(sk, ack_flag);
+ tcp_identify_packet_loss(sk, ack_flag);
if (!tcp_time_to_recover(sk, flag)) {
tcp_try_to_open(sk, flag);
return;
diff --git a/net/ipv4/tcp_recovery.c b/net/ipv4/tcp_recovery.c
index 1c1bdf12a96f..299b0e38aa9a 100644
--- a/net/ipv4/tcp_recovery.c
+++ b/net/ipv4/tcp_recovery.c
@@ -216,3 +216,30 @@ void tcp_rack_update_reo_wnd(struct sock *sk, struct rate_sample *rs)
tp->rack.reo_wnd_steps = 1;
}
}
+
+/* RFC6582 NewReno recovery for non-SACK connection. It simply retransmits
+ * the next unacked packet upon receiving
+ * a) three or more DUPACKs to start the fast recovery
+ * b) an ACK acknowledging new data during the fast recovery.
+ */
+void tcp_newreno_mark_lost(struct sock *sk, bool snd_una_advanced)
+{
+ const u8 state = inet_csk(sk)->icsk_ca_state;
+ struct tcp_sock *tp = tcp_sk(sk);
+
+ if ((state < TCP_CA_Recovery && tp->sacked_out >= tp->reordering) ||
+ (state == TCP_CA_Recovery && snd_una_advanced)) {
+ struct sk_buff *skb = tcp_rtx_queue_head(sk);
+ u32 mss;
+
+ if (TCP_SKB_CB(skb)->sacked & TCPCB_LOST)
+ return;
+
+ mss = tcp_skb_mss(skb);
+ if (tcp_skb_pcount(skb) > 1 && skb->len > mss)
+ tcp_fragment(sk, TCP_FRAG_IN_RTX_QUEUE, skb,
+ mss, mss, GFP_ATOMIC);
+
+ tcp_skb_mark_lost_uncond_verify(tp, skb);
+ }
+}
--
2.17.0.441.gb46fe60e1d-goog
^ permalink raw reply related
* [PATCH net-next 2/8] tcp: disable RFC6675 loss detection
From: Yuchung Cheng @ 2018-05-16 23:40 UTC (permalink / raw)
To: davem; +Cc: netdev, edumazet, ncardwell, soheil, priyarjha, Yuchung Cheng
In-Reply-To: <20180516234017.172775-1-ycheng@google.com>
This patch disables RFC6675 loss detection and make sysctl
net.ipv4.tcp_recovery = 1 controls a binary choice between RACK
(1) or RFC6675 (0).
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Soheil Hassas Yeganeh <soheil@google.com>
Reviewed-by: Priyaranjan Jha <priyarjha@google.com>
---
Documentation/networking/ip-sysctl.txt | 3 ++-
net/ipv4/tcp_input.c | 12 ++++++++----
2 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index 13bbac50dc8b..ea304a23c8d7 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -449,7 +449,8 @@ tcp_recovery - INTEGER
features.
RACK: 0x1 enables the RACK loss detection for fast detection of lost
- retransmissions and tail drops.
+ retransmissions and tail drops. It also subsumes and disables
+ RFC6675 recovery for SACK connections.
RACK: 0x2 makes RACK's reordering window static (min_rtt/4).
RACK: 0x4 disables RACK's DUPACK threshold heuristic
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index b188e0d75edd..ccbe04f80040 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -2035,6 +2035,11 @@ static inline int tcp_dupack_heuristics(const struct tcp_sock *tp)
return tp->sacked_out + 1;
}
+static bool tcp_is_rack(const struct sock *sk)
+{
+ return sock_net(sk)->ipv4.sysctl_tcp_recovery & TCP_RACK_LOSS_DETECTION;
+}
+
/* Linux NewReno/SACK/ECN state machine.
* --------------------------------------
*
@@ -2141,7 +2146,7 @@ static bool tcp_time_to_recover(struct sock *sk, int flag)
return true;
/* Not-A-Trick#2 : Classic rule... */
- if (tcp_dupack_heuristics(tp) > tp->reordering)
+ if (!tcp_is_rack(sk) && tcp_dupack_heuristics(tp) > tp->reordering)
return true;
return false;
@@ -2722,8 +2727,7 @@ static void tcp_rack_identify_loss(struct sock *sk, int *ack_flag)
{
struct tcp_sock *tp = tcp_sk(sk);
- /* Use RACK to detect loss */
- if (sock_net(sk)->ipv4.sysctl_tcp_recovery & TCP_RACK_LOSS_DETECTION) {
+ if (tcp_is_rack(sk)) {
u32 prior_retrans = tp->retrans_out;
tcp_rack_mark_lost(sk);
@@ -2862,7 +2866,7 @@ static void tcp_fastretrans_alert(struct sock *sk, const u32 prior_snd_una,
fast_rexmit = 1;
}
- if (do_lost)
+ if (!tcp_is_rack(sk) && do_lost)
tcp_update_scoreboard(sk, fast_rexmit);
*rexmit = REXMIT_LOST;
}
--
2.17.0.441.gb46fe60e1d-goog
^ permalink raw reply related
* [PATCH net-next 1/8] tcp: support DUPACK threshold in RACK
From: Yuchung Cheng @ 2018-05-16 23:40 UTC (permalink / raw)
To: davem; +Cc: netdev, edumazet, ncardwell, soheil, priyarjha, Yuchung Cheng
In-Reply-To: <20180516234017.172775-1-ycheng@google.com>
This patch adds support for the classic DUPACK threshold rule
(#DupThresh) in RACK.
When the number of packets SACKed is greater or equal to the
threshold, RACK sets the reordering window to zero which would
immediately mark all the unsacked packets below the highest SACKed
sequence lost. Since this approach is known to not work well with
reordering, RACK only uses it if no reordering has been observed.
The DUPACK threshold rule is a particularly useful extension to the
fast recoveries triggered by RACK reordering timer. For example
data-center transfers where the RTT is much smaller than a timer
tick, or high RTT path where the default RTT/4 may take too long.
Note that this patch differs slightly from RFC6675. RFC6675
considers a packet lost when at least #DupThresh higher-sequence
packets are SACKed.
With RACK, for connections that have seen reordering, RACK
continues to use a dynamically-adaptive time-based reordering
window to detect losses. But for connections on which we have not
yet seen reordering, this patch considers a packet lost when at
least one higher sequence packet is SACKed and the total number
of SACKed packets is at least DupThresh. For example, suppose a
connection has not seen reordering, and sends 10 packets, and
packets 3, 5, 7 are SACKed. RFC6675 considers packets 1 and 2
lost. RACK considers packets 1, 2, 4, 6 lost.
There is some small risk of spurious retransmits here due to
reordering. However, this is mostly limited to the first flight of
a connection on which the sender receives SACKs from reordering.
And RFC 6675 and FACK loss detection have a similar risk on the
first flight with reordering (it's just that the risk of spurious
retransmits from reordering was slightly narrower for those older
algorithms due to the margin of 3*MSS).
Also the minimum reordering window is reduced from 1 msec to 0
to recover quicker on short RTT transfers. Therefore RACK is more
aggressive in marking packets lost during recovery to reduce the
reordering window timeouts.
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Soheil Hassas Yeganeh <soheil@google.com>
Reviewed-by: Priyaranjan Jha <priyarjha@google.com>
---
Documentation/networking/ip-sysctl.txt | 1 +
include/net/tcp.h | 1 +
net/ipv4/tcp_recovery.c | 40 +++++++++++++++++---------
3 files changed, 29 insertions(+), 13 deletions(-)
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index 59afc9a10b4f..13bbac50dc8b 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -451,6 +451,7 @@ tcp_recovery - INTEGER
RACK: 0x1 enables the RACK loss detection for fast detection of lost
retransmissions and tail drops.
RACK: 0x2 makes RACK's reordering window static (min_rtt/4).
+ RACK: 0x4 disables RACK's DUPACK threshold heuristic
Default: 0x1
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 3b1d617b0110..85000c85ddcd 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -245,6 +245,7 @@ extern long sysctl_tcp_mem[3];
#define TCP_RACK_LOSS_DETECTION 0x1 /* Use RACK to detect losses */
#define TCP_RACK_STATIC_REO_WND 0x2 /* Use static RACK reo wnd */
+#define TCP_RACK_NO_DUPTHRESH 0x4 /* Do not use DUPACK threshold in RACK */
extern atomic_long_t tcp_memory_allocated;
extern struct percpu_counter tcp_sockets_allocated;
diff --git a/net/ipv4/tcp_recovery.c b/net/ipv4/tcp_recovery.c
index 3a81720ac0c4..1c1bdf12a96f 100644
--- a/net/ipv4/tcp_recovery.c
+++ b/net/ipv4/tcp_recovery.c
@@ -21,6 +21,32 @@ static bool tcp_rack_sent_after(u64 t1, u64 t2, u32 seq1, u32 seq2)
return t1 > t2 || (t1 == t2 && after(seq1, seq2));
}
+u32 tcp_rack_reo_wnd(const struct sock *sk)
+{
+ struct tcp_sock *tp = tcp_sk(sk);
+
+ if (!tp->rack.reord) {
+ /* If reordering has not been observed, be aggressive during
+ * the recovery or starting the recovery by DUPACK threshold.
+ */
+ if (inet_csk(sk)->icsk_ca_state >= TCP_CA_Recovery)
+ return 0;
+
+ if (tp->sacked_out >= tp->reordering &&
+ !(sock_net(sk)->ipv4.sysctl_tcp_recovery & TCP_RACK_NO_DUPTHRESH))
+ return 0;
+ }
+
+ /* To be more reordering resilient, allow min_rtt/4 settling delay.
+ * Use min_rtt instead of the smoothed RTT because reordering is
+ * often a path property and less related to queuing or delayed ACKs.
+ * Upon receiving DSACKs, linearly increase the window up to the
+ * smoothed RTT.
+ */
+ return min((tcp_min_rtt(tp) >> 2) * tp->rack.reo_wnd_steps,
+ tp->srtt_us >> 3);
+}
+
/* RACK loss detection (IETF draft draft-ietf-tcpm-rack-01):
*
* Marks a packet lost, if some packet sent later has been (s)acked.
@@ -44,23 +70,11 @@ static bool tcp_rack_sent_after(u64 t1, u64 t2, u32 seq1, u32 seq2)
static void tcp_rack_detect_loss(struct sock *sk, u32 *reo_timeout)
{
struct tcp_sock *tp = tcp_sk(sk);
- u32 min_rtt = tcp_min_rtt(tp);
struct sk_buff *skb, *n;
u32 reo_wnd;
*reo_timeout = 0;
- /* To be more reordering resilient, allow min_rtt/4 settling delay
- * (lower-bounded to 1000uS). We use min_rtt instead of the smoothed
- * RTT because reordering is often a path property and less related
- * to queuing or delayed ACKs.
- */
- reo_wnd = 1000;
- if ((tp->rack.reord || inet_csk(sk)->icsk_ca_state < TCP_CA_Recovery) &&
- min_rtt != ~0U) {
- reo_wnd = max((min_rtt >> 2) * tp->rack.reo_wnd_steps, reo_wnd);
- reo_wnd = min(reo_wnd, tp->srtt_us >> 3);
- }
-
+ reo_wnd = tcp_rack_reo_wnd(sk);
list_for_each_entry_safe(skb, n, &tp->tsorted_sent_queue,
tcp_tsorted_anchor) {
struct tcp_skb_cb *scb = TCP_SKB_CB(skb);
--
2.17.0.441.gb46fe60e1d-goog
^ permalink raw reply related
* [PATCH net-next 0/8] tcp: default RACK loss recovery
From: Yuchung Cheng @ 2018-05-16 23:40 UTC (permalink / raw)
To: davem; +Cc: netdev, edumazet, ncardwell, soheil, priyarjha, Yuchung Cheng
This patch set implements the features correspond to the
draft-ietf-tcpm-rack-03 version of the RACK draft.
https://datatracker.ietf.org/meeting/101/materials/slides-101-tcpm-update-on-tcp-rack-00
1. SACK: implement equivalent DUPACK threshold heuristic in RACK to
replace existing RFC6675 recovery (tcp_mark_head_lost).
2. Non-SACK: simplify RFC6582 NewReno implementation
3. RTO: apply RACK's time-based approach to avoid spuriouly
marking very recently sent packets lost.
4. with (1)(2)(3), make RACK the exclusive fast recovery mechanism to
mark losses based on time on S/ACK. Tail loss probe and F-RTO remain
enabled by default as complementary mechanisms to send probes in
CA_Open and CA_Loss states. The probes would solicit S/ACKs to trigger
RACK time-based loss detection.
All Google web and internal servers have been running RACK-only mode
(4) for a while now. a/b experiments indicate RACK/TLP on average
reduces recovery latency by 10% compared to RFC6675. RFC6675
is default-off now but can be enabled by disabling RACK (sysctl
net.ipv4.tcp_recovery=0) for unseen issues.
Yuchung Cheng (8):
tcp: support DUPACK threshold in RACK
tcp: disable RFC6675 loss detection
tcp: simpler NewReno implementation
tcp: account lost retransmit after timeout
tcp: new helper tcp_timeout_mark_lost
tcp: separate loss marking and state update on RTO
tcp: new helper tcp_rack_skb_timeout
tcp: don't mark recently sent packets lost on RTO
Documentation/networking/ip-sysctl.txt | 4 +-
include/net/tcp.h | 5 ++
net/ipv4/tcp_input.c | 99 ++++++++++++++------------
net/ipv4/tcp_recovery.c | 80 ++++++++++++++++-----
4 files changed, 124 insertions(+), 64 deletions(-)
--
2.17.0.441.gb46fe60e1d-goog
^ permalink raw reply
* Proposal
From: Miss Zeliha Omer Faruk @ 2018-05-16 23:26 UTC (permalink / raw)
Hello
Greetings to you please i have a business proposal for you contact me
for more detailes asap thanks.
Best Regards,
Miss.Zeliha ömer faruk
Esentepe Mahallesi Büyükdere
Caddesi Kristal Kule Binasi
No:215
Sisli - Istanbul, Turkey
^ permalink raw reply
* Re: [PATCH] bpf: add __printf verification to bpf_verifier_vlog
From: Daniel Borkmann @ 2018-05-16 22:59 UTC (permalink / raw)
To: Mathieu Malaterre, Alexei Starovoitov; +Cc: netdev, linux-kernel
In-Reply-To: <20180516202741.20861-1-malat@debian.org>
On 05/16/2018 10:27 PM, Mathieu Malaterre wrote:
> __printf is useful to verify format and arguments. ‘bpf_verifier_vlog’
> function is used twice in verifier.c in both cases the caller function
> already uses the __printf gcc attribute.
>
> Remove the following warning, triggered with W=1:
>
> kernel/bpf/verifier.c:176:2: warning: function might be possible candidate for ‘gnu_printf’ format attribute [-Wsuggest-attribute=format]
>
> Signed-off-by: Mathieu Malaterre <malat@debian.org>
Looks good, applied to bpf-next, thanks Mathieu!
^ permalink raw reply
* Re: [PATCH bpf-next] libbpf: add ifindex to enable offload support
From: Daniel Borkmann @ 2018-05-16 22:59 UTC (permalink / raw)
To: Jakub Kicinski, alexei.starovoitov; +Cc: oss-drivers, netdev, David Beckett
In-Reply-To: <20180516210249.6486-1-jakub.kicinski@netronome.com>
On 05/16/2018 11:02 PM, Jakub Kicinski wrote:
> From: David Beckett <david.beckett@netronome.com>
>
> BPF programs currently can only be offloaded using iproute2. This
> patch will allow programs to be offloaded using libbpf calls.
>
> Signed-off-by: David Beckett <david.beckett@netronome.com>
> Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Applied to bpf-next, thanks guys!
^ permalink raw reply
* Re: [PATCH bpf-next] bpf: fix sock hashmap kmalloc warning
From: Daniel Borkmann @ 2018-05-16 22:58 UTC (permalink / raw)
To: Yonghong Song, ast, netdev; +Cc: kernel-team
In-Reply-To: <20180516210626.776403-1-yhs@fb.com>
On 05/16/2018 11:06 PM, Yonghong Song wrote:
> syzbot reported a kernel warning below:
> WARNING: CPU: 0 PID: 4499 at mm/slab_common.c:996 kmalloc_slab+0x56/0x70 mm/slab_common.c:996
> Kernel panic - not syncing: panic_on_warn set ...
>
> CPU: 0 PID: 4499 Comm: syz-executor050 Not tainted 4.17.0-rc3+ #9
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x1b9/0x294 lib/dump_stack.c:113
> panic+0x22f/0x4de kernel/panic.c:184
> __warn.cold.8+0x163/0x1b3 kernel/panic.c:536
> report_bug+0x252/0x2d0 lib/bug.c:186
> fixup_bug arch/x86/kernel/traps.c:178 [inline]
> do_error_trap+0x1de/0x490 arch/x86/kernel/traps.c:296
> do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315
> invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:992
> RIP: 0010:kmalloc_slab+0x56/0x70 mm/slab_common.c:996
> RSP: 0018:ffff8801d907fc58 EFLAGS: 00010246
> RAX: 0000000000000000 RBX: ffff8801aeecb280 RCX: ffffffff8185ebd7
> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00000000ffffffe1
> RBP: ffff8801d907fc58 R08: ffff8801adb5e1c0 R09: ffffed0035a84700
> R10: ffffed0035a84700 R11: ffff8801ad423803 R12: ffff8801aeecb280
> R13: 00000000fffffff4 R14: ffff8801ad891a00 R15: 00000000014200c0
> __do_kmalloc mm/slab.c:3713 [inline]
> __kmalloc+0x25/0x760 mm/slab.c:3727
> kmalloc include/linux/slab.h:517 [inline]
> map_get_next_key+0x24a/0x640 kernel/bpf/syscall.c:858
> __do_sys_bpf kernel/bpf/syscall.c:2131 [inline]
> __se_sys_bpf kernel/bpf/syscall.c:2096 [inline]
> __x64_sys_bpf+0x354/0x4f0 kernel/bpf/syscall.c:2096
> do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> The test case is against sock hashmap with a key size 0xffffffe1.
> Such a large key size will cause the below code in function
> sock_hash_alloc() overflowing and produces a smaller elem_size,
> hence map creation will be successful.
> htab->elem_size = sizeof(struct htab_elem) +
> round_up(htab->map.key_size, 8);
>
> Later, when map_get_next_key is called and kernel tries
> to allocate the key unsuccessfully, it will issue
> the above warning.
>
> Similar to hashtab, ensure the key size is at most
> MAX_BPF_STACK for a successful map creation.
>
> Fixes: 81110384441a ("bpf: sockmap, add hash map support")
> Reported-by: syzbot+e4566d29080e7f3460ff@syzkaller.appspotmail.com
> Signed-off-by: Yonghong Song <yhs@fb.com>
Applied to bpf-next, thanks Yonghong!
^ permalink raw reply
* Re: kernel BUG at lib/string.c:LINE! (4)
From: Julian Anastasov @ 2018-05-16 22:43 UTC (permalink / raw)
To: syzbot
Cc: coreteam, davem, fw, horms, kadlec, linux-kernel, lvs-devel,
netdev, netfilter-devel, pablo, syzkaller-bugs, wensong
In-Reply-To: <0000000000006764b4056c5476d9@google.com>
Hello,
On Wed, 16 May 2018, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 0b7d9978406f Merge branch 'Microsemi-Ocelot-Ethernet-switc..
> git tree: net-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=16e91017800000
> kernel config: https://syzkaller.appspot.com/x/.config?x=b632d8e2c2ab2c1
> dashboard link: https://syzkaller.appspot.com/bug?extid=aac887f77319868646df
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=1665d637800000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=10517107800000
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+aac887f77319868646df@syzkaller.appspotmail.com
>
> IPVS: Unknown mcast interface: veth1_to???a????????????
> IPVS: Unknown mcast interface: veth1_to???a????????????
> IPVS: Unknown mcast interface: veth1_to???a????????????
> detected buffer overflow in strlen
> ------------[ cut here ]------------
> kernel BUG at lib/string.c:1052!
> invalid opcode: 0000 [#1] SMP KASAN
> Dumping ftrace buffer:
> (ftrace buffer empty)
> Modules linked in:
> CPU: 1 PID: 373 Comm: syz-executor936 Not tainted 4.17.0-rc4+ #45
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
> 01/01/2011
> RIP: 0010:fortify_panic+0x13/0x20 lib/string.c:1051
> RSP: 0018:ffff8801c976f800 EFLAGS: 00010282
> RAX: 0000000000000022 RBX: 0000000000000040 RCX: 0000000000000000
> RDX: 0000000000000022 RSI: ffffffff8160f6f1 RDI: ffffed00392edef6
> RBP: ffff8801c976f800 R08: ffff8801cf4c62c0 R09: ffffed003b5e4fb0
> R10: ffffed003b5e4fb0 R11: ffff8801daf27d87 R12: ffff8801c976fa20
> R13: ffff8801c976fae4 R14: ffff8801c976fae0 R15: 000000000000048b
> FS: 00007fd99f75e700(0000) GS:ffff8801daf00000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00000000200001c0 CR3: 00000001d6843000 CR4: 00000000001406e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
> strlen include/linux/string.h:270 [inline]
> strlcpy include/linux/string.h:293 [inline]
> do_ip_vs_set_ctl+0x31c/0x1d00 net/netfilter/ipvs/ip_vs_ctl.c:2388
> nf_sockopt net/netfilter/nf_sockopt.c:106 [inline]
> nf_setsockopt+0x7d/0xd0 net/netfilter/nf_sockopt.c:115
> ip_setsockopt+0xd8/0xf0 net/ipv4/ip_sockglue.c:1253
> udp_setsockopt+0x62/0xa0 net/ipv4/udp.c:2487
> ipv6_setsockopt+0x149/0x170 net/ipv6/ipv6_sockglue.c:917
> tcp_setsockopt+0x93/0xe0 net/ipv4/tcp.c:3057
> sock_common_setsockopt+0x9a/0xe0 net/core/sock.c:3046
> __sys_setsockopt+0x1bd/0x390 net/socket.c:1903
> __do_sys_setsockopt net/socket.c:1914 [inline]
> __se_sys_setsockopt net/socket.c:1911 [inline]
> __x64_sys_setsockopt+0xbe/0x150 net/socket.c:1911
> do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x447369
> RSP: 002b:00007fd99f75dda8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036
> RAX: ffffffffffffffda RBX: 00000000006e39e4 RCX: 0000000000447369
> RDX: 000000000000048b RSI: 0000000000000000 RDI: 0000000000000003
> RBP: 0000000000000000 R08: 0000000000000018 R09: 0000000000000000
> R10: 00000000200001c0 R11: 0000000000000246 R12: 00000000006e39e0
> R13: 75a1ff93f0896195 R14: 6f745f3168746576 R15: 0000000000000001
> Code: 08 5b 41 5c 41 5d 41 5e 41 5f 5d c3 0f 0b 48 89 df e8 d2 8f 48 fa eb de
> 55 48 89 fe 48 c7 c7 60 65 64 88 48 89 e5 e8 91 dd f3 f9 <0f> 0b 90 90 90 90
> 90 90 90 90 90 90 90 55 48 89 e5 41 57 41 56
> RIP: fortify_panic+0x13/0x20 lib/string.c:1051 RSP: ffff8801c976f800
> ---[ end trace 624046f2d9af7702 ]---
Just to let you know that I tested a patch with
the syzbot, will do more tests before submitting...
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: [PATCH net-next] erspan: set bso bit based on mirrored packet's len
From: Tobin C. Harding @ 2018-05-16 22:24 UTC (permalink / raw)
To: William Tu; +Cc: Linux Kernel Network Developers
In-Reply-To: <CALDO+SaDVJtagChiQdvue6tY-N8G=jAT40GcD7U9kpa9qcVvQA@mail.gmail.com>
On Wed, May 16, 2018 at 07:05:34AM -0700, William Tu wrote:
> On Mon, May 14, 2018 at 10:33 PM, Tobin C. Harding <tobin@apporbit.com> wrote:
> > On Mon, May 14, 2018 at 04:54:36PM -0700, William Tu wrote:
> >> Before the patch, the erspan BSO bit (Bad/Short/Oversized) is not
> >> handled. BSO has 4 possible values:
> >> 00 --> Good frame with no error, or unknown integrity
> >> 11 --> Payload is a Bad Frame with CRC or Alignment Error
> >> 01 --> Payload is a Short Frame
> >> 10 --> Payload is an Oversized Frame
> >>
> >> Based the short/oversized definitions in RFC1757, the patch sets
> >> the bso bit based on the mirrored packet's size.
> >>
> >> Reported-by: Xiaoyan Jin <xiaoyanj@vmware.com>
> >> Signed-off-by: William Tu <u9012063@gmail.com>
> >> ---
> >> include/net/erspan.h | 25 +++++++++++++++++++++++++
> >> 1 file changed, 25 insertions(+)
> >>
> >> diff --git a/include/net/erspan.h b/include/net/erspan.h
> >> index d044aa60cc76..5eb95f78ad45 100644
> >> --- a/include/net/erspan.h
> >> +++ b/include/net/erspan.h
> >> @@ -219,6 +219,30 @@ static inline __be32 erspan_get_timestamp(void)
> >> return htonl((u32)h_usecs);
> >> }
> >>
> >> +/* ERSPAN BSO (Bad/Short/Oversized)
> >> + * 00b --> Good frame with no error, or unknown integrity
> >> + * 01b --> Payload is a Short Frame
> >> + * 10b --> Payload is an Oversized Frame
> >> + * 11b --> Payload is a Bad Frame with CRC or Alignment Error
> >> + */
> >> +enum erspan_bso {
> >> + BSO_NOERROR,
> >> + BSO_SHORT,
> >> + BSO_OVERSIZED,
> >> + BSO_BAD,
> >> +};
> >
> > If we are relying on the values perhaps this would be clearer
> >
> > BSO_NOERROR = 0x00,
> > BSO_SHORT = 0x01,
> > BSO_OVERSIZED = 0x02,
> > BSO_BAD = 0x03,
> >
>
> Yes, thanks. I will change in v2.
>
> >> +
> >> +static inline u8 erspan_detect_bso(struct sk_buff *skb)
> >> +{
> >> + if (skb->len < ETH_ZLEN)
> >> + return BSO_SHORT;
> >> +
> >> + if (skb->len > ETH_FRAME_LEN)
> >> + return BSO_OVERSIZED;
> >> +
> >> + return BSO_NOERROR;
> >> +}
> >
> > Without having much contextual knowledge around this patch; should we be
> > doing some check on CRC or alignment (at some stage)? Having BSO_BAD
> > seems to imply so?
> >
>
> The definition of BSO_BAD:
> etherStatsCRCAlignErrors OBJECT-TYPE
> SYNTAX Counter
> ACCESS read-only
> STATUS mandatory
> DESCRIPTION
> "The total number of packets received that
> had a length (excluding framing bits, but
> including FCS octets) of between 64 and 1518
> octets, inclusive, but but had either a bad
> Frame Check Sequence (FCS) with an integral
> number of octets (FCS Error) or a bad FCS with
> a non-integral number of octets (Alignment Error)."
>
> But I don't know how to check CRC error at this code point.
> Isn't it done by the NIC hardware?
I'll just start with; I don't know anything about ERSPAN
"ERSPAN is a Cisco proprietary feature and is available only to
Catalyst 6500, 7600, Nexus, and ASR 1000 platforms to date. The
ASR 1000 supports ERSPAN source (monitoring) only on Fast
Ethernet, Gigabit Ethernet, and port-channel interfaces."
https://supportforums.cisco.com/t5/network-infrastructure-documents/understanding-span-rspan-and-erspan/ta-p/3144951
I dug around a bit and none of the files that currently import erspan.h
actually use the 'bso' field
$ grep bso $(git grep -l 'erspan\.h')
include/net/erspan.h: u8 bso = 0; /* Bad/Short/Oversized */
include/net/erspan.h: ershdr->en = bso;
net/ipv4/ip_gre.c: ICMP in the real Internet is absolutely infeasible.
net/ipv4/ip_gre.c: * ICMP in the real Internet is absolutely infeasible.
Normally, AFAICT, the FCS does not get passed to the operating system
since its a link layer mechanism. If ERSPAN is passing the FCS when it
mirrors frames (does it mirror frames or packets, I don't know?) then
surely ERSPAN should provide a function to return the BSO value.
So IMHO this patch seems like a just pretense and not really doing
anything.
Hope this helps,
Tobin.
^ permalink raw reply
* [PATCH] net: ethernet: ti: cpsw: disable mq feature for "AM33xx ES1.0" devices
From: Ivan Khoronzhuk @ 2018-05-16 22:21 UTC (permalink / raw)
To: grygorii.strashko, davem
Cc: netdev, linux-kernel, linux-omap, Ivan Khoronzhuk
The early versions of am33xx devices, related to ES1.0 SoC revision
have errata limiting mq support. That's the same errata as
commit 7da1160002f1 ("drivers: net: cpsw: add am335x errata workarround for
interrutps")
AM33xx Errata [1] Advisory 1.0.9
http://www.ti.com/lit/er/sprz360f/sprz360f.pdf
After additional investigation were found that drivers w/a is
propagated on all AM33xx SoCs and on DM814x. But the errata exists
only for ES1.0 of AM33xx family, limiting mq support for revisions
after ES1.0. So, disable mq support only for related SoCs and use
separate polls for revisions allowing mq.
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
---
Based on net-next/master
drivers/net/ethernet/ti/cpsw.c | 109 ++++++++++++++++++---------------
1 file changed, 60 insertions(+), 49 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 28d893b93d30..a7285dddfd29 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -36,6 +36,7 @@
#include <linux/of_device.h>
#include <linux/if_vlan.h>
#include <linux/kmemleak.h>
+#include <linux/sys_soc.h>
#include <linux/pinctrl/consumer.h>
@@ -957,7 +958,7 @@ static irqreturn_t cpsw_rx_interrupt(int irq, void *dev_id)
return IRQ_HANDLED;
}
-static int cpsw_tx_poll(struct napi_struct *napi_tx, int budget)
+static int cpsw_tx_mq_poll(struct napi_struct *napi_tx, int budget)
{
u32 ch_map;
int num_tx, cur_budget, ch;
@@ -984,7 +985,21 @@ static int cpsw_tx_poll(struct napi_struct *napi_tx, int budget)
if (num_tx < budget) {
napi_complete(napi_tx);
writel(0xff, &cpsw->wr_regs->tx_en);
- if (cpsw->quirk_irq && cpsw->tx_irq_disabled) {
+ }
+
+ return num_tx;
+}
+
+static int cpsw_tx_poll(struct napi_struct *napi_tx, int budget)
+{
+ struct cpsw_common *cpsw = napi_to_cpsw(napi_tx);
+ int num_tx;
+
+ num_tx = cpdma_chan_process(cpsw->txv[0].ch, budget);
+ if (num_tx < budget) {
+ napi_complete(napi_tx);
+ writel(0xff, &cpsw->wr_regs->tx_en);
+ if (cpsw->tx_irq_disabled) {
cpsw->tx_irq_disabled = false;
enable_irq(cpsw->irqs_table[1]);
}
@@ -993,7 +1008,7 @@ static int cpsw_tx_poll(struct napi_struct *napi_tx, int budget)
return num_tx;
}
-static int cpsw_rx_poll(struct napi_struct *napi_rx, int budget)
+static int cpsw_rx_mq_poll(struct napi_struct *napi_rx, int budget)
{
u32 ch_map;
int num_rx, cur_budget, ch;
@@ -1020,7 +1035,21 @@ static int cpsw_rx_poll(struct napi_struct *napi_rx, int budget)
if (num_rx < budget) {
napi_complete_done(napi_rx, num_rx);
writel(0xff, &cpsw->wr_regs->rx_en);
- if (cpsw->quirk_irq && cpsw->rx_irq_disabled) {
+ }
+
+ return num_rx;
+}
+
+static int cpsw_rx_poll(struct napi_struct *napi_rx, int budget)
+{
+ struct cpsw_common *cpsw = napi_to_cpsw(napi_rx);
+ int num_rx;
+
+ num_rx = cpdma_chan_process(cpsw->rxv[0].ch, budget);
+ if (num_rx < budget) {
+ napi_complete_done(napi_rx, num_rx);
+ writel(0xff, &cpsw->wr_regs->rx_en);
+ if (cpsw->rx_irq_disabled) {
cpsw->rx_irq_disabled = false;
enable_irq(cpsw->irqs_table[0]);
}
@@ -2364,9 +2393,9 @@ static void cpsw_get_channels(struct net_device *ndev,
{
struct cpsw_common *cpsw = ndev_to_cpsw(ndev);
+ ch->max_rx = cpsw->quirk_irq ? 1 : CPSW_MAX_QUEUES;
+ ch->max_tx = cpsw->quirk_irq ? 1 : CPSW_MAX_QUEUES;
ch->max_combined = 0;
- ch->max_rx = CPSW_MAX_QUEUES;
- ch->max_tx = CPSW_MAX_QUEUES;
ch->max_other = 0;
ch->other_count = 0;
ch->rx_count = cpsw->rx_ch_num;
@@ -2377,6 +2406,11 @@ static void cpsw_get_channels(struct net_device *ndev,
static int cpsw_check_ch_settings(struct cpsw_common *cpsw,
struct ethtool_channels *ch)
{
+ if (cpsw->quirk_irq) {
+ dev_err(cpsw->dev, "Maximum one tx/rx queue is allowed");
+ return -EOPNOTSUPP;
+ }
+
if (ch->combined_count)
return -EINVAL;
@@ -2917,44 +2951,20 @@ static int cpsw_probe_dual_emac(struct cpsw_priv *priv)
return ret;
}
-#define CPSW_QUIRK_IRQ BIT(0)
-
-static const struct platform_device_id cpsw_devtype[] = {
- {
- /* keep it for existing comaptibles */
- .name = "cpsw",
- .driver_data = CPSW_QUIRK_IRQ,
- }, {
- .name = "am335x-cpsw",
- .driver_data = CPSW_QUIRK_IRQ,
- }, {
- .name = "am4372-cpsw",
- .driver_data = 0,
- }, {
- .name = "dra7-cpsw",
- .driver_data = 0,
- }, {
- /* sentinel */
- }
-};
-MODULE_DEVICE_TABLE(platform, cpsw_devtype);
-
-enum ti_cpsw_type {
- CPSW = 0,
- AM335X_CPSW,
- AM4372_CPSW,
- DRA7_CPSW,
-};
-
static const struct of_device_id cpsw_of_mtable[] = {
- { .compatible = "ti,cpsw", .data = &cpsw_devtype[CPSW], },
- { .compatible = "ti,am335x-cpsw", .data = &cpsw_devtype[AM335X_CPSW], },
- { .compatible = "ti,am4372-cpsw", .data = &cpsw_devtype[AM4372_CPSW], },
- { .compatible = "ti,dra7-cpsw", .data = &cpsw_devtype[DRA7_CPSW], },
+ { .compatible = "ti,cpsw"},
+ { .compatible = "ti,am335x-cpsw"},
+ { .compatible = "ti,am4372-cpsw"},
+ { .compatible = "ti,dra7-cpsw"},
{ /* sentinel */ },
};
MODULE_DEVICE_TABLE(of, cpsw_of_mtable);
+static const struct soc_device_attribute cpsw_soc_devices[] = {
+ { .family = "AM33xx", .revision = "ES1.0"},
+ { /* sentinel */ }
+};
+
static int cpsw_probe(struct platform_device *pdev)
{
struct clk *clk;
@@ -2966,9 +2976,9 @@ static int cpsw_probe(struct platform_device *pdev)
void __iomem *ss_regs;
void __iomem *cpts_regs;
struct resource *res, *ss_res;
- const struct of_device_id *of_id;
struct gpio_descs *mode;
u32 slave_offset, sliver_offset, slave_size;
+ const struct soc_device_attribute *soc;
struct cpsw_common *cpsw;
int ret = 0, i;
int irq;
@@ -3141,6 +3151,10 @@ static int cpsw_probe(struct platform_device *pdev)
goto clean_dt_ret;
}
+ soc = soc_device_match(cpsw_soc_devices);
+ if (soc)
+ cpsw->quirk_irq = 1;
+
cpsw->txv[0].ch = cpdma_chan_create(cpsw->dma, 0, cpsw_tx_handler, 0);
if (IS_ERR(cpsw->txv[0].ch)) {
dev_err(priv->dev, "error initializing tx dma channel\n");
@@ -3180,19 +3194,16 @@ static int cpsw_probe(struct platform_device *pdev)
goto clean_dma_ret;
}
- of_id = of_match_device(cpsw_of_mtable, &pdev->dev);
- if (of_id) {
- pdev->id_entry = of_id->data;
- if (pdev->id_entry->driver_data)
- cpsw->quirk_irq = true;
- }
-
ndev->features |= NETIF_F_HW_VLAN_CTAG_FILTER | NETIF_F_HW_VLAN_CTAG_RX;
ndev->netdev_ops = &cpsw_netdev_ops;
ndev->ethtool_ops = &cpsw_ethtool_ops;
- netif_napi_add(ndev, &cpsw->napi_rx, cpsw_rx_poll, CPSW_POLL_WEIGHT);
- netif_tx_napi_add(ndev, &cpsw->napi_tx, cpsw_tx_poll, CPSW_POLL_WEIGHT);
+ netif_napi_add(ndev, &cpsw->napi_rx,
+ cpsw->quirk_irq ? cpsw_rx_poll : cpsw_rx_mq_poll,
+ CPSW_POLL_WEIGHT);
+ netif_tx_napi_add(ndev, &cpsw->napi_tx,
+ cpsw->quirk_irq ? cpsw_tx_poll : cpsw_tx_mq_poll,
+ CPSW_POLL_WEIGHT);
cpsw_split_res(ndev);
/* register the network device */
--
2.17.0
^ permalink raw reply related
* Re: [PATCH bpf-next 2/7] bpf: introduce bpf subcommand BPF_PERF_EVENT_QUERY
From: Yonghong Song @ 2018-05-16 21:59 UTC (permalink / raw)
To: Peter Zijlstra; +Cc: ast, daniel, netdev, kernel-team
In-Reply-To: <20180516112734.GE12217@hirez.programming.kicks-ass.net>
On 5/16/18 4:27 AM, Peter Zijlstra wrote:
> On Tue, May 15, 2018 at 04:45:16PM -0700, Yonghong Song wrote:
>> Currently, suppose a userspace application has loaded a bpf program
>> and attached it to a tracepoint/kprobe/uprobe, and a bpf
>> introspection tool, e.g., bpftool, wants to show which bpf program
>> is attached to which tracepoint/kprobe/uprobe. Such attachment
>> information will be really useful to understand the overall bpf
>> deployment in the system.
>>
>> There is a name field (16 bytes) for each program, which could
>> be used to encode the attachment point. There are some drawbacks
>> for this approaches. First, bpftool user (e.g., an admin) may not
>> really understand the association between the name and the
>> attachment point. Second, if one program is attached to multiple
>> places, encoding a proper name which can imply all these
>> attachments becomes difficult.
>>
>> This patch introduces a new bpf subcommand BPF_PERF_EVENT_QUERY.
>> Given a pid and fd, if the <pid, fd> is associated with a
>> tracepoint/kprobe/uprobea perf event, BPF_PERF_EVENT_QUERY will return
>> . prog_id
>> . tracepoint name, or
>> . k[ret]probe funcname + offset or kernel addr, or
>> . u[ret]probe filename + offset
>> to the userspace.
>> The user can use "bpftool prog" to find more information about
>> bpf program itself with prog_id.
>>
>> Signed-off-by: Yonghong Song <yhs@fb.com>
>> ---
>> include/linux/trace_events.h | 15 ++++++
>> include/uapi/linux/bpf.h | 25 ++++++++++
>> kernel/bpf/syscall.c | 113 +++++++++++++++++++++++++++++++++++++++++++
>> kernel/trace/bpf_trace.c | 53 ++++++++++++++++++++
>> kernel/trace/trace_kprobe.c | 29 +++++++++++
>> kernel/trace/trace_uprobe.c | 22 +++++++++
>> 6 files changed, 257 insertions(+)
>
> Why is the command called *_PERF_EVENT_* ? Are there not a lot of !perf
> places to attach BPF proglets?
Just gave a complete picture, the below are major places to attach
BPF programs:
. perf based (through perf ioctl)
. raw tracepoint based (through bpf interface)
. netlink interface for tc, xdp, tunneling
. setsockopt for socket filters
. cgroup based (bpf attachment subcommand)
mostly networking and io devices
. some other networking socket related (sk_skb stream/parser/verdict,
sk_msg verdict) through bpf attachment subcommand.
Currently, for cgroup based attachment, we have BPF_PROG_QUERY with
input cgroup file descriptor. For other networking based queries, we
may need to enumerate tc filters, networking devices, open sockets, etc.
to get the attachment information.
So to have one BPF_QUERY command line may be too complex to
cover all cases.
But you are right that BPF_PERF_EVENT_QUERY name is too narrow since
it should be used for other (pid, fd) based queries as well (e.g.,
socket, or other potential uses in the future).
How about the subcommand name BPF_TASK_FD_QUERY and make
bpf_attr.task_fd_query extensible?
Thanks!
^ permalink raw reply
* Re: [PATCH bpf-next v5 3/6] bpf: Add IPv6 Segment Routing helpers
From: Mathieu Xhonneux @ 2018-05-16 21:59 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: netdev, David Lebrun, Alexei Starovoitov
In-Reply-To: <ae7d9849-1124-2d96-1304-4693a1827729@iogearbox.net>
2018-05-14 23:40 GMT+01:00 Daniel Borkmann <daniel@iogearbox.net>:
> On 05/12/2018 07:25 PM, Mathieu Xhonneux wrote:
> [...]
>> +BPF_CALL_4(bpf_lwt_seg6_store_bytes, struct sk_buff *, skb, u32, offset,
>> + const void *, from, u32, len)
>> +{
>> +#if IS_ENABLED(CONFIG_IPV6_SEG6_BPF)
>> + struct seg6_bpf_srh_state *srh_state =
>> + this_cpu_ptr(&seg6_bpf_srh_states);
>> + void *srh_tlvs, *srh_end, *ptr;
>> + struct ipv6_sr_hdr *srh;
>> + int srhoff = 0;
>> +
>> + if (ipv6_find_hdr(skb, &srhoff, IPPROTO_ROUTING, NULL, NULL) < 0)
>> + return -EINVAL;
>> +
>> + srh = (struct ipv6_sr_hdr *)(skb->data + srhoff);
>> + srh_tlvs = (void *)((char *)srh + ((srh->first_segment + 1) << 4));
>> + srh_end = (void *)((char *)srh + sizeof(*srh) + srh_state->hdrlen);
>
> Do we need to check that this cannot go out of bounds wrt skb data?
input_action_bpf_end (which calls the BPF program) already verifies
using get_srh() that the whole SRH is accessible and is not out of
bounds.
The seg6 helpers (e.g. bpf_lwt_seg6_adjust_srh) then modify
srh_state->hdrlen following the evolution of the SRH in size. I don't
think that a check on srh_end is needed here as the SRH is already
verified once, and srh_state->hdrlen is then updated to keep this
bound correct.
>> + ptr = skb->data + offset;
>> + if (ptr >= srh_tlvs && ptr + len <= srh_end)
>> + srh_state->valid = 0;
>> + else if (ptr < (void *)&srh->flags ||
>> + ptr + len > (void *)&srh->segments)
>> + return -EFAULT;
>> +
>> + if (unlikely(bpf_try_make_writable(skb, offset + len)))
>> + return -EFAULT;
>> +
>> + memcpy(ptr, from, len);
>
> You have a use after free here. bpf_try_make_writable() is potentially changing
> underlying skb->data (e.g. see pskb_expand_head()). Therefore memcpy()'ing into
> cached ptr is invalid.
>
OK.
>> + if (len > 0) {
>> + ret = skb_cow_head(skb, len);
>> + if (unlikely(ret < 0))
>> + return ret;
>> +
>> + ret = bpf_skb_net_hdr_push(skb, offset, len);
>> + } else {
>> + ret = bpf_skb_net_hdr_pop(skb, offset, -1 * len);
>> + }
>> + if (unlikely(ret < 0))
>> + return ret;
>
> And here as well. You changed underlying pointers via skb_cow_head(), but in
> the error path you leave the cached pointers that now point to already freed
> buffer. Thus, you'd now be able to access the new skb data out of bounds since
> cb->data_end is still the old one due to missing bpf_compute_data_pointers(skb).
> Please fix and audit your whole series carefully against these types of subtle
> bugs.
Right.
I went through the whole series again. I found a similar mistake in
bpf_push_seg6_encap, and added also a bpf_compute_data_pointers(skb)
there. I didn't find anything else, so I hope that we're covered here
(bpf_lwt_seg6_store_bytes, bpf_lwt_seg6_adjust_srh and
bpf_push_seg6_encap are the only functions modifying the packet in
this series).
Thanks. I'll submit a v6 ASAP.
^ permalink raw reply
* Re: [PATCH 00/14] Modify action API for implementing lockless actions
From: Jiri Pirko @ 2018-05-16 21:51 UTC (permalink / raw)
To: Vlad Buslov
Cc: Roman Mashak, Jamal Hadi Salim, Linux Kernel Network Developers,
David Miller, Cong Wang, pablo, kadlec, fw, ast, Daniel Borkmann,
Eric Dumazet, kliteyn
In-Reply-To: <vbfpo1vpa5e.fsf@reg-r-vrt-018-180.mtr.labs.mlnx>
Wed, May 16, 2018 at 11:23:41PM CEST, vladbu@mellanox.com wrote:
>
>On Wed 16 May 2018 at 17:36, Roman Mashak <mrv@mojatatu.com> wrote:
>> Vlad Buslov <vladbu@mellanox.com> writes:
>>
>>> On Wed 16 May 2018 at 14:38, Roman Mashak <mrv@mojatatu.com> wrote:
>>>> On Wed, May 16, 2018 at 2:43 AM, Vlad Buslov <vladbu@mellanox.com> wrote:
>>>>>>>>> I'm trying to run tdc, but keep getting following error even on clean
>>>>>>>>> branch without my patches:
>>>>>>>>
>>>>>>>> Vlad, not sure if you saw my email:
>>>>>>>> Apply Roman's patch and try again
>>>>>>>>
>>>>>>>> https://marc.info/?l=linux-netdev&m=152639369112020&w=2
>>>>>>>>
>>>>>>>> cheers,
>>>>>>>> jamal
>>>>>>>
>>>>>>> With patch applied I get following error:
>>>>>>>
>>>>>>> Test 7d50: Add skbmod action to set destination mac
>>>>>>> exit: 255 0
>>>>>>> dst MAC address <11:22:33:44:55:66>
>>>>>>> RTNETLINK answers: No such file or directory
>>>>>>> We have an error talking to the kernel
>>>>>>>
>>>>>>
>>>>>> You may actually have broken something with your patches in this case.
>>>>>
>>>>> Results is for net-next without my patches.
>>>>
>>>> Do you have skbmod compiled in kernel or as a module?
>>>
>>> Thanks, already figured out that default config has some actions
>>> disabled.
>>> Have more errors now. Everything related to ife:
>>>
>>> Test 7682: Create valid ife encode action with mark and pass control
>>> exit: 255 0
>>> IFE type 0xED3E
>>> RTNETLINK answers: No such file or directory
>>> We have an error talking to the kernel
>>>
>>> Test ef47: Create valid ife encode action with mark and pipe control
>>> exit: 255 0
>>> IFE type 0xED3E
>>> RTNETLINK answers: No space left on device
>>> We have an error talking to the kernel
>>>
>>> Test df43: Create valid ife encode action with mark and continue control
>>> exit: 255 0
>>> IFE type 0xED3E
>>> RTNETLINK answers: No space left on device
>>> We have an error talking to the kernel
>>>
>>> Test e4cf: Create valid ife encode action with mark and drop control
>>> exit: 255 0
>>> IFE type 0xED3E
>>> RTNETLINK answers: No space left on device
>>> We have an error talking to the kernel
>>>
>>> Test ccba: Create valid ife encode action with mark and reclassify control
>>> exit: 255 0
>>> IFE type 0xED3E
>>> RTNETLINK answers: No space left on device
>>> We have an error talking to the kernel
>>>
>>> Test a1cf: Create valid ife encode action with mark and jump control
>>> exit: 255 0
>>> IFE type 0xED3E
>>> RTNETLINK answers: No space left on device
>>> We have an error talking to the kernel
>>>
>>> ...
>>>
>>>
>>
>> Please make sure you have these in your kernel config:
>>
>> CONFIG_NET_ACT_IFE=y
>> CONFIG_NET_IFE_SKBMARK=m
>> CONFIG_NET_IFE_SKBPRIO=m
>> CONFIG_NET_IFE_SKBTCINDEX=m
Roman, could you please add this to some file? Something similar to:
tools/testing/selftests/net/forwarding/config
Thanks!
>>
>> For tdc to run all the tests, it is assumed that all the supported tc
>> actions/filters are enabled and compiled.
>
>Enabling these options allowed all ife tests to pass. Thanks!
>
>Error in u32 test still appears however:
>
>Test e9a3: Add u32 with source match
>
>-----> prepare stage *** Could not execute: "$TC qdisc add dev $DEV1 ingress"
>
>-----> prepare stage *** Error message: "Cannot find device "v0p1"
^ permalink raw reply
* [bpf PATCH 2/2] bpf: parse and verdict prog attach may race with bpf map update
From: John Fastabend @ 2018-05-16 21:46 UTC (permalink / raw)
To: ast, daniel; +Cc: netdev
In-Reply-To: <20180516214651.6664.62408.stgit@john-Precision-Tower-5810>
In the sockmap design BPF programs (SK_SKB_STREAM_PARSER and
SK_SKB_STREAM_VERDICT) are attached to the sockmap map type and when
a sock is added to the map the programs are used by the socket.
However, sockmap updates from both userspace and BPF programs can
happen concurrently with the attach and detach of these programs.
To resolve this we use the bpf_prog_inc_not_zero and a READ_ONCE()
primitive to ensure the program pointer is not refeched and
possibly NULL'd before the refcnt increment. This happens inside
a RCU critical section so although the pointer reference in the map
object may be NULL (by a concurrent detach operation) the reference
from READ_ONCE will not be free'd until after grace period. This
ensures the object returned by READ_ONCE() is valid through the
RCU criticl section and safe to use as long as we "know" it may
be free'd shortly.
Daniel spotted a case in the sock update API where instead of using
the READ_ONCE() program reference we used the pointer from the
original map, stab->bpf_{verdict|parse}. The problem with this is
the logic checks the object returned from the READ_ONCE() is not
NULL and then tries to reference the object again but using the
above map pointer, which may have already been NULL'd by a parallel
detach operation. If this happened bpf_porg_inc_not_zero could
dereference a NULL pointer.
Fix this by using variable returned by READ_ONCE() that is checked
for NULL.
Fixes: 2f857d04601a ("bpf: sockmap, remove STRPARSER map_flags and add multi-map support")
Reported-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
---
kernel/bpf/sockmap.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/bpf/sockmap.c b/kernel/bpf/sockmap.c
index f03aaa8..583c1eb 100644
--- a/kernel/bpf/sockmap.c
+++ b/kernel/bpf/sockmap.c
@@ -1703,11 +1703,11 @@ static int sock_map_ctx_update_elem(struct bpf_sock_ops_kern *skops,
* we increment the refcnt. If this is the case abort with an
* error.
*/
- verdict = bpf_prog_inc_not_zero(stab->bpf_verdict);
+ verdict = bpf_prog_inc_not_zero(verdict);
if (IS_ERR(verdict))
return PTR_ERR(verdict);
- parse = bpf_prog_inc_not_zero(stab->bpf_parse);
+ parse = bpf_prog_inc_not_zero(parse);
if (IS_ERR(parse)) {
bpf_prog_put(verdict);
return PTR_ERR(parse);
^ permalink raw reply related
* [bpf PATCH 1/2] bpf: sockmap update rollback on error can incorrectly dec prog refcnt
From: John Fastabend @ 2018-05-16 21:46 UTC (permalink / raw)
To: ast, daniel; +Cc: netdev
If the user were to only attach one of the parse or verdict programs
then it is possible a subsequent sockmap update could incorrectly
decrement the refcnt on the program. This happens because in the
rollback logic, after an error, we have to decrement the program
reference count when its been incremented. However, we only increment
the program reference count if the user has both a verdict and a
parse program. The reason for this is because, at least at the
moment, both are required for any one to be meaningful. The problem
fixed here is in the rollback path we decrement the program refcnt
even if only one existing. But we never incremented the refcnt in
the first place creating an imbalance.
This patch fixes the error path to handle this case.
Fixes: 2f857d04601a ("bpf: sockmap, remove STRPARSER map_flags and add multi-map support")
Reported-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
---
kernel/bpf/sockmap.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/kernel/bpf/sockmap.c b/kernel/bpf/sockmap.c
index 098eca5..f03aaa8 100644
--- a/kernel/bpf/sockmap.c
+++ b/kernel/bpf/sockmap.c
@@ -1717,10 +1717,10 @@ static int sock_map_ctx_update_elem(struct bpf_sock_ops_kern *skops,
if (tx_msg) {
tx_msg = bpf_prog_inc_not_zero(stab->bpf_tx_msg);
if (IS_ERR(tx_msg)) {
- if (verdict)
- bpf_prog_put(verdict);
- if (parse)
+ if (parse && verdict) {
bpf_prog_put(parse);
+ bpf_prog_put(verdict);
+ }
return PTR_ERR(tx_msg);
}
}
@@ -1805,10 +1805,10 @@ static int sock_map_ctx_update_elem(struct bpf_sock_ops_kern *skops,
out_free:
smap_release_sock(psock, sock);
out_progs:
- if (verdict)
- bpf_prog_put(verdict);
- if (parse)
+ if (parse && verdict) {
bpf_prog_put(parse);
+ bpf_prog_put(verdict);
+ }
if (tx_msg)
bpf_prog_put(tx_msg);
write_unlock_bh(&sock->sk_callback_lock);
^ permalink raw reply related
* Re: [PATCH bpf-next v6 1/4] bpf: sockmap, refactor sockmap routines to work with hashmap
From: John Fastabend @ 2018-05-16 21:46 UTC (permalink / raw)
To: Daniel Borkmann, ast; +Cc: netdev, davem
In-Reply-To: <954e3b7f-9001-e528-c6ab-f8f69c84cfd8@iogearbox.net>
On 05/15/2018 12:19 PM, Daniel Borkmann wrote:
> On 05/14/2018 07:00 PM, John Fastabend wrote:
> [...]
[...]
>
> As you say in the comment above the function wrt locking notes that the
> __sock_map_ctx_update_elem() can be called concurrently.
>
> All operations operate on sock_map using cmpxchg and xchg operations to ensure we
> do not get stale references. Any reads into the map must be done with READ_ONCE()
> because of this.
>
> You initially use the READ_ONCE() on the verdict/parse/tx_msg, but later on when
> grabbing the reference you use again progs->bpf_verdict/bpf_parse/bpf_tx_msg which
> would potentially refetch it, but if updates would happen concurrently e.g. to the
> three progs, they could be NULL in the mean-time, no? bpf_prog_inc_not_zero() would
> then crash. Why are not the ones used that you fetched previously via READ_ONCE()
> for taking the ref?
Nice catch. We should use the reference fetched by READ_ONCE in all cases.
>
> The second question I had is that verdict/parse/tx_msg are updated independently
> from each other and each could be NULL or non-NULL. What if, say, parse is NULL
> and verdict as well as tx_msg is non-NULL and the bpf_prog_inc_not_zero() on the
> tx_msg prog fails. Doesn't this cause a use-after-free since a ref on verdict wasn't
> taken earlier but the bpf_prog_put() will cause accidental misbalance/free of the
> progs?
Also good catch. I'll send patches for both now. Thanks.
>
> It would probably help to clarify the locking comment a bit more if indeed the
> above should be okay as is.
>
> Thanks,
> Daniel
>
^ permalink raw reply
* Re: [PATCH 00/14] Modify action API for implementing lockless actions
From: Vlad Buslov @ 2018-05-16 21:29 UTC (permalink / raw)
To: Davide Caratti
Cc: Roman Mashak, Jamal Hadi Salim, Linux Kernel Network Developers,
David Miller, Cong Wang, Jiri Pirko, pablo, kadlec, fw, ast,
Daniel Borkmann, Eric Dumazet, kliteyn
In-Reply-To: <bd6cf2d13402fae390e29dba8919a5a388481b5e.camel@redhat.com>
On Wed 16 May 2018 at 18:10, Davide Caratti <dcaratti@redhat.com> wrote:
> On Wed, 2018-05-16 at 13:36 -0400, Roman Mashak wrote:
>> Vlad Buslov <vladbu@mellanox.com> writes:
>>
>> > On Wed 16 May 2018 at 14:38, Roman Mashak <mrv@mojatatu.com> wrote:
>> > > On Wed, May 16, 2018 at 2:43 AM, Vlad Buslov <vladbu@mellanox.com> wrote:
>> > > > > > > > I'm trying to run tdc, but keep getting following error even on clean
>> > > > > > > > branch without my patches:
>> > > > > > >
>> > > > > > > Vlad, not sure if you saw my email:
>> > > > > > > Apply Roman's patch and try again
>> > > > > > >
>> > > > > > > https://marc.info/?l=linux-netdev&m=152639369112020&w=2
>> > > > > > >
>> > > > > > > cheers,
>> > > > > > > jamal
>> > > > > >
>> > > > > > With patch applied I get following error:
>> > > > > >
>> > > > > > Test 7d50: Add skbmod action to set destination mac
>> > > > > > exit: 255 0
>> > > > > > dst MAC address <11:22:33:44:55:66>
>> > > > > > RTNETLINK answers: No such file or directory
>> > > > > > We have an error talking to the kernel
>> > > > > >
>> > > > >
>> > > > > You may actually have broken something with your patches in this case.
>> > > >
>> > > > Results is for net-next without my patches.
>> > >
>> > > Do you have skbmod compiled in kernel or as a module?
>> >
>> > Thanks, already figured out that default config has some actions
>> > disabled.
>> > Have more errors now. Everything related to ife:
>> >
>> > Test 7682: Create valid ife encode action with mark and pass control
>> > exit: 255 0
>> > IFE type 0xED3E
>> > RTNETLINK answers: No such file or directory
>> > We have an error talking to the kernel
>> >
>> > Test ef47: Create valid ife encode action with mark and pipe control
>> > exit: 255 0
>> > IFE type 0xED3E
>> > RTNETLINK answers: No space left on device
>> > We have an error talking to the kernel
>> >
>> > Test df43: Create valid ife encode action with mark and continue control
>> > exit: 255 0
>> > IFE type 0xED3E
>> > RTNETLINK answers: No space left on device
>> > We have an error talking to the kernel
>> >
>> > Test e4cf: Create valid ife encode action with mark and drop control
>> > exit: 255 0
>> > IFE type 0xED3E
>> > RTNETLINK answers: No space left on device
>> > We have an error talking to the kernel
>> >
>> > Test ccba: Create valid ife encode action with mark and reclassify control
>> > exit: 255 0
>> > IFE type 0xED3E
>> > RTNETLINK answers: No space left on device
>> > We have an error talking to the kernel
>> >
>> > Test a1cf: Create valid ife encode action with mark and jump control
>> > exit: 255 0
>> > IFE type 0xED3E
>> > RTNETLINK answers: No space left on device
>> > We have an error talking to the kernel
>> >
>> > ...
>> >
>> >
>>
>> Please make sure you have these in your kernel config:
>>
>> CONFIG_NET_ACT_IFE=y
>> CONFIG_NET_IFE_SKBMARK=m
>> CONFIG_NET_IFE_SKBPRIO=m
>> CONFIG_NET_IFE_SKBTCINDEX=m
>>
>> For tdc to run all the tests, it is assumed that all the supported tc
>> actions/filters are enabled and compiled.
> hello,
>
> looking at ife.json, it seems that we have at least 4 typos in
> 'teardown'.
>
> It does
>
> $TC actions flush action skbedit
>
> in place of
>
> $TC actions flush action ife
>
> On my fedora28 (with fedora28 kernel), fixing them made test 7682 return
> 'ok' (and all others in ife category, except ee94, 7ee0 and 0a7d).
>
> regards,
I can confirm that on net-next kernel version that I use, there are also
multiple teardowns of actions type skbedit after actually creating ife
action in file ife.json. However, tests pass when I enabled config
options that Roman suggested:
ok 119 - 7682 # Create valid ife encode action with mark and pass control
^ permalink raw reply
* Re: [PATCH iproute2-next] tc-netem: fix limit description in man page
From: Stephen Hemminger @ 2018-05-16 21:28 UTC (permalink / raw)
To: David Ahern; +Cc: Marcelo Ricardo Leitner, netdev
In-Reply-To: <700b8303-28df-d991-6410-2f9d06f2b70d@gmail.com>
On Wed, 16 May 2018 15:17:50 -0600
David Ahern <dsahern@gmail.com> wrote:
> On 5/15/18 6:49 PM, Marcelo Ricardo Leitner wrote:
> > As the kernel code says, limit is actually the amount of packets it can
> > hold queued at a time, as per:
> >
> > static int netem_enqueue(struct sk_buff *skb, struct Qdisc *sch,
> > struct sk_buff **to_free)
> > {
> > ...
> > if (unlikely(sch->q.qlen >= sch->limit))
> > return qdisc_drop_all(skb, sch, to_free);
> >
> > So lets fix the description of the field in the man page.
> >
> > Signed-off-by: Marcelo Ricardo Leitner <mleitner@redhat.com>
> > ---
> > man/man8/tc-netem.8 | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
>
> applied to iproute2-next. Thanks,
>
Since it is an error, I will put it in master.
^ permalink raw reply
* Re: [PATCH 00/14] Modify action API for implementing lockless actions
From: Vlad Buslov @ 2018-05-16 21:23 UTC (permalink / raw)
To: Roman Mashak
Cc: Jamal Hadi Salim, Linux Kernel Network Developers, David Miller,
Cong Wang, Jiri Pirko, pablo, kadlec, fw, ast, Daniel Borkmann,
Eric Dumazet, kliteyn
In-Reply-To: <85efib33kr.fsf@mojatatu.com>
On Wed 16 May 2018 at 17:36, Roman Mashak <mrv@mojatatu.com> wrote:
> Vlad Buslov <vladbu@mellanox.com> writes:
>
>> On Wed 16 May 2018 at 14:38, Roman Mashak <mrv@mojatatu.com> wrote:
>>> On Wed, May 16, 2018 at 2:43 AM, Vlad Buslov <vladbu@mellanox.com> wrote:
>>>>>>>> I'm trying to run tdc, but keep getting following error even on clean
>>>>>>>> branch without my patches:
>>>>>>>
>>>>>>> Vlad, not sure if you saw my email:
>>>>>>> Apply Roman's patch and try again
>>>>>>>
>>>>>>> https://marc.info/?l=linux-netdev&m=152639369112020&w=2
>>>>>>>
>>>>>>> cheers,
>>>>>>> jamal
>>>>>>
>>>>>> With patch applied I get following error:
>>>>>>
>>>>>> Test 7d50: Add skbmod action to set destination mac
>>>>>> exit: 255 0
>>>>>> dst MAC address <11:22:33:44:55:66>
>>>>>> RTNETLINK answers: No such file or directory
>>>>>> We have an error talking to the kernel
>>>>>>
>>>>>
>>>>> You may actually have broken something with your patches in this case.
>>>>
>>>> Results is for net-next without my patches.
>>>
>>> Do you have skbmod compiled in kernel or as a module?
>>
>> Thanks, already figured out that default config has some actions
>> disabled.
>> Have more errors now. Everything related to ife:
>>
>> Test 7682: Create valid ife encode action with mark and pass control
>> exit: 255 0
>> IFE type 0xED3E
>> RTNETLINK answers: No such file or directory
>> We have an error talking to the kernel
>>
>> Test ef47: Create valid ife encode action with mark and pipe control
>> exit: 255 0
>> IFE type 0xED3E
>> RTNETLINK answers: No space left on device
>> We have an error talking to the kernel
>>
>> Test df43: Create valid ife encode action with mark and continue control
>> exit: 255 0
>> IFE type 0xED3E
>> RTNETLINK answers: No space left on device
>> We have an error talking to the kernel
>>
>> Test e4cf: Create valid ife encode action with mark and drop control
>> exit: 255 0
>> IFE type 0xED3E
>> RTNETLINK answers: No space left on device
>> We have an error talking to the kernel
>>
>> Test ccba: Create valid ife encode action with mark and reclassify control
>> exit: 255 0
>> IFE type 0xED3E
>> RTNETLINK answers: No space left on device
>> We have an error talking to the kernel
>>
>> Test a1cf: Create valid ife encode action with mark and jump control
>> exit: 255 0
>> IFE type 0xED3E
>> RTNETLINK answers: No space left on device
>> We have an error talking to the kernel
>>
>> ...
>>
>>
>
> Please make sure you have these in your kernel config:
>
> CONFIG_NET_ACT_IFE=y
> CONFIG_NET_IFE_SKBMARK=m
> CONFIG_NET_IFE_SKBPRIO=m
> CONFIG_NET_IFE_SKBTCINDEX=m
>
> For tdc to run all the tests, it is assumed that all the supported tc
> actions/filters are enabled and compiled.
Enabling these options allowed all ife tests to pass. Thanks!
Error in u32 test still appears however:
Test e9a3: Add u32 with source match
-----> prepare stage *** Could not execute: "$TC qdisc add dev $DEV1 ingress"
-----> prepare stage *** Error message: "Cannot find device "v0p1"
^ permalink raw reply
* Re: [PATCH iproute2-next] tc-netem: fix limit description in man page
From: David Ahern @ 2018-05-16 21:17 UTC (permalink / raw)
To: Marcelo Ricardo Leitner, netdev
In-Reply-To: <adc166a5db72cf5c658cbc68a7d733c0793e31d4.1526431697.git.mleitner@redhat.com>
On 5/15/18 6:49 PM, Marcelo Ricardo Leitner wrote:
> As the kernel code says, limit is actually the amount of packets it can
> hold queued at a time, as per:
>
> static int netem_enqueue(struct sk_buff *skb, struct Qdisc *sch,
> struct sk_buff **to_free)
> {
> ...
> if (unlikely(sch->q.qlen >= sch->limit))
> return qdisc_drop_all(skb, sch, to_free);
>
> So lets fix the description of the field in the man page.
>
> Signed-off-by: Marcelo Ricardo Leitner <mleitner@redhat.com>
> ---
> man/man8/tc-netem.8 | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
applied to iproute2-next. Thanks,
^ permalink raw reply
* Re: [PATCH net-next v12 2/7] sch_cake: Add ingress mode
From: Toke Høiland-Jørgensen @ 2018-05-16 21:16 UTC (permalink / raw)
To: Cong Wang; +Cc: Linux Kernel Network Developers, Cake List
In-Reply-To: <CAM_iQpVz9bRDkW_cqj-vo6fapXaG6zV-bWM0Sc2wmHuj-vzWqg@mail.gmail.com>
Cong Wang <xiyou.wangcong@gmail.com> writes:
> On Wed, May 16, 2018 at 1:29 PM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>> + if (tb[TCA_CAKE_AUTORATE]) {
>> + if (!!nla_get_u32(tb[TCA_CAKE_AUTORATE]))
>> + q->rate_flags |= CAKE_FLAG_AUTORATE_INGRESS;
>> + else
>> + q->rate_flags &= ~CAKE_FLAG_AUTORATE_INGRESS;
>> + }
>> +
>> + if (tb[TCA_CAKE_INGRESS]) {
>> + if (!!nla_get_u32(tb[TCA_CAKE_INGRESS]))
>> + q->rate_flags |= CAKE_FLAG_INGRESS;
>> + else
>> + q->rate_flags &= ~CAKE_FLAG_INGRESS;
>> + }
>> +
>> if (tb[TCA_CAKE_MEMORY])
>> q->buffer_config_limit = nla_get_u32(tb[TCA_CAKE_MEMORY]);
>>
>> @@ -1559,6 +1628,14 @@ static int cake_dump(struct Qdisc *sch, struct sk_buff *skb)
>> if (nla_put_u32(skb, TCA_CAKE_MEMORY, q->buffer_config_limit))
>> goto nla_put_failure;
>>
>> + if (nla_put_u32(skb, TCA_CAKE_AUTORATE,
>> + !!(q->rate_flags & CAKE_FLAG_AUTORATE_INGRESS)))
>> + goto nla_put_failure;
>> +
>> + if (nla_put_u32(skb, TCA_CAKE_INGRESS,
>> + !!(q->rate_flags & CAKE_FLAG_INGRESS)))
>> + goto nla_put_failure;
>> +
>
> Why do you want to dump each bit of the rate_flags separately rather than
> dumping the whole rate_flags as an integer?
Well, these were added one at a time, each as a new option. Isn't that
more or less congruent with how netlink attributes are supposed to be
used?
-Toke
^ permalink raw reply
* Re: [PATCH net-next v12 4/7] sch_cake: Add NAT awareness to packet classifier
From: Toke Høiland-Jørgensen @ 2018-05-16 21:14 UTC (permalink / raw)
To: Cong Wang; +Cc: Linux Kernel Network Developers, Cake List
In-Reply-To: <CAM_iQpUCB24x7d7oDYkes_ngQ==8CjiwGqCBit-BK5NxzzZODg@mail.gmail.com>
Cong Wang <xiyou.wangcong@gmail.com> writes:
> On Wed, May 16, 2018 at 1:29 PM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>> When CAKE is deployed on a gateway that also performs NAT (which is a
>> common deployment mode), the host fairness mechanism cannot distinguish
>> internal hosts from each other, and so fails to work correctly.
>>
>> To fix this, we add an optional NAT awareness mode, which will query the
>> kernel conntrack mechanism to obtain the pre-NAT addresses for each packet
>> and use that in the flow and host hashing.
>>
>> When the shaper is enabled and the host is already performing NAT, the cost
>> of this lookup is negligible. However, in unlimited mode with no NAT being
>> performed, there is a significant CPU cost at higher bandwidths. For this
>> reason, the feature is turned off by default.
>>
>> Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk>
>> ---
>> net/sched/sch_cake.c | 73 ++++++++++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 73 insertions(+)
>>
>> diff --git a/net/sched/sch_cake.c b/net/sched/sch_cake.c
>> index 65439b643c92..e1038a7b6686 100644
>> --- a/net/sched/sch_cake.c
>> +++ b/net/sched/sch_cake.c
>> @@ -71,6 +71,12 @@
>> #include <net/tcp.h>
>> #include <net/flow_dissector.h>
>>
>> +#if IS_REACHABLE(CONFIG_NF_CONNTRACK)
>> +#include <net/netfilter/nf_conntrack_core.h>
>> +#include <net/netfilter/nf_conntrack_zones.h>
>> +#include <net/netfilter/nf_conntrack.h>
>> +#endif
>> +
>> #define CAKE_SET_WAYS (8)
>> #define CAKE_MAX_TINS (8)
>> #define CAKE_QUEUES (1024)
>> @@ -514,6 +520,60 @@ static bool cobalt_should_drop(struct cobalt_vars *vars,
>> return drop;
>> }
>>
>> +#if IS_REACHABLE(CONFIG_NF_CONNTRACK)
>> +
>> +static void cake_update_flowkeys(struct flow_keys *keys,
>> + const struct sk_buff *skb)
>> +{
>> + const struct nf_conntrack_tuple *tuple;
>> + enum ip_conntrack_info ctinfo;
>> + struct nf_conn *ct;
>> + bool rev = false;
>> +
>> + if (tc_skb_protocol(skb) != htons(ETH_P_IP))
>> + return;
>> +
>> + ct = nf_ct_get(skb, &ctinfo);
>> + if (ct) {
>> + tuple = nf_ct_tuple(ct, CTINFO2DIR(ctinfo));
>> + } else {
>> + const struct nf_conntrack_tuple_hash *hash;
>> + struct nf_conntrack_tuple srctuple;
>> +
>> + if (!nf_ct_get_tuplepr(skb, skb_network_offset(skb),
>> + NFPROTO_IPV4, dev_net(skb->dev),
>> + &srctuple))
>> + return;
>> +
>> + hash = nf_conntrack_find_get(dev_net(skb->dev),
>> + &nf_ct_zone_dflt,
>> + &srctuple);
>> + if (!hash)
>> + return;
>> +
>> + rev = true;
>> + ct = nf_ct_tuplehash_to_ctrack(hash);
>> + tuple = nf_ct_tuple(ct, !hash->tuple.dst.dir);
>> + }
>> +
>> + keys->addrs.v4addrs.src = rev ? tuple->dst.u3.ip : tuple->src.u3.ip;
>> + keys->addrs.v4addrs.dst = rev ? tuple->src.u3.ip : tuple->dst.u3.ip;
>> +
>> + if (keys->ports.ports) {
>> + keys->ports.src = rev ? tuple->dst.u.all : tuple->src.u.all;
>> + keys->ports.dst = rev ? tuple->src.u.all : tuple->dst.u.all;
>> + }
>> + if (rev)
>> + nf_ct_put(ct);
>> +}
>> +#else
>> +static void cake_update_flowkeys(struct flow_keys *keys,
>> + const struct sk_buff *skb)
>> +{
>> + /* There is nothing we can do here without CONNTRACK */
>> +}
>> +#endif
>> +
>> /* Cake has several subtle multiple bit settings. In these cases you
>> * would be matching triple isolate mode as well.
>> */
>> @@ -541,6 +601,9 @@ static u32 cake_hash(struct cake_tin_data *q, const struct sk_buff *skb,
>> skb_flow_dissect_flow_keys(skb, &keys,
>> FLOW_DISSECTOR_F_STOP_AT_FLOW_LABEL);
>>
>> + if (flow_mode & CAKE_FLOW_NAT_FLAG)
>> + cake_update_flowkeys(&keys, skb);
>> +
>> /* flow_hash_from_keys() sorts the addresses by value, so we have
>> * to preserve their order in a separate data structure to treat
>> * src and dst host addresses as independently selectable.
>> @@ -1727,6 +1790,12 @@ static int cake_change(struct Qdisc *sch, struct nlattr *opt,
>> q->flow_mode = (nla_get_u32(tb[TCA_CAKE_FLOW_MODE]) &
>> CAKE_FLOW_MASK);
>>
>> + if (tb[TCA_CAKE_NAT]) {
>> + q->flow_mode &= ~CAKE_FLOW_NAT_FLAG;
>> + q->flow_mode |= CAKE_FLOW_NAT_FLAG *
>> + !!nla_get_u32(tb[TCA_CAKE_NAT]);
>> + }
>
>
> I think it's better to return -EOPNOTSUPP when CONFIG_NF_CONNTRACK
> is not enabled.
Good point, will fix :)
-Toke
^ permalink raw reply
* Re: [PATCH bpf-next] bpf: fix sock hashmap kmalloc warning
From: John Fastabend @ 2018-05-16 21:14 UTC (permalink / raw)
To: Yonghong Song, ast, daniel, netdev; +Cc: kernel-team
In-Reply-To: <20180516210626.776403-1-yhs@fb.com>
On 05/16/2018 02:06 PM, Yonghong Song wrote:
> syzbot reported a kernel warning below:
> WARNING: CPU: 0 PID: 4499 at mm/slab_common.c:996 kmalloc_slab+0x56/0x70 mm/slab_common.c:996
> Kernel panic - not syncing: panic_on_warn set ...
>
> CPU: 0 PID: 4499 Comm: syz-executor050 Not tainted 4.17.0-rc3+ #9
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x1b9/0x294 lib/dump_stack.c:113
> panic+0x22f/0x4de kernel/panic.c:184
> __warn.cold.8+0x163/0x1b3 kernel/panic.c:536
> report_bug+0x252/0x2d0 lib/bug.c:186
> fixup_bug arch/x86/kernel/traps.c:178 [inline]
> do_error_trap+0x1de/0x490 arch/x86/kernel/traps.c:296
> do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315
> invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:992
> RIP: 0010:kmalloc_slab+0x56/0x70 mm/slab_common.c:996
> RSP: 0018:ffff8801d907fc58 EFLAGS: 00010246
> RAX: 0000000000000000 RBX: ffff8801aeecb280 RCX: ffffffff8185ebd7
> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00000000ffffffe1
> RBP: ffff8801d907fc58 R08: ffff8801adb5e1c0 R09: ffffed0035a84700
> R10: ffffed0035a84700 R11: ffff8801ad423803 R12: ffff8801aeecb280
> R13: 00000000fffffff4 R14: ffff8801ad891a00 R15: 00000000014200c0
> __do_kmalloc mm/slab.c:3713 [inline]
> __kmalloc+0x25/0x760 mm/slab.c:3727
> kmalloc include/linux/slab.h:517 [inline]
> map_get_next_key+0x24a/0x640 kernel/bpf/syscall.c:858
> __do_sys_bpf kernel/bpf/syscall.c:2131 [inline]
> __se_sys_bpf kernel/bpf/syscall.c:2096 [inline]
> __x64_sys_bpf+0x354/0x4f0 kernel/bpf/syscall.c:2096
> do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> The test case is against sock hashmap with a key size 0xffffffe1.
> Such a large key size will cause the below code in function
> sock_hash_alloc() overflowing and produces a smaller elem_size,
> hence map creation will be successful.
> htab->elem_size = sizeof(struct htab_elem) +
> round_up(htab->map.key_size, 8);
>
> Later, when map_get_next_key is called and kernel tries
> to allocate the key unsuccessfully, it will issue
> the above warning.
>
> Similar to hashtab, ensure the key size is at most
> MAX_BPF_STACK for a successful map creation.
>
> Fixes: 81110384441a ("bpf: sockmap, add hash map support")
> Reported-by: syzbot+e4566d29080e7f3460ff@syzkaller.appspotmail.com
> Signed-off-by: Yonghong Song <yhs@fb.com>
> ---
> kernel/bpf/sockmap.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/kernel/bpf/sockmap.c b/kernel/bpf/sockmap.c
> index 56879c9fd3a4..79f5e8988889 100644
> --- a/kernel/bpf/sockmap.c
> +++ b/kernel/bpf/sockmap.c
> @@ -1990,6 +1990,12 @@ static struct bpf_map *sock_hash_alloc(union bpf_attr *attr)
> attr->map_flags & ~SOCK_CREATE_FLAG_MASK)
> return ERR_PTR(-EINVAL);
>
> + if (attr->key_size > MAX_BPF_STACK)
> + /* eBPF programs initialize keys on stack, so they cannot be
> + * larger than max stack size
> + */
> + return ERR_PTR(-E2BIG);
> +
> err = bpf_tcp_ulp_register();
> if (err && err != -EEXIST)
> return ERR_PTR(err);
>
Thanks!
Acked-by: John Fastabend <john.fastabend@gmail.com>
^ permalink raw reply
* Re: [PATCH net-next v12 1/7] sched: Add Common Applications Kept Enhanced (cake) qdisc
From: Toke Høiland-Jørgensen @ 2018-05-16 21:13 UTC (permalink / raw)
To: Cong Wang; +Cc: Linux Kernel Network Developers, Cake List
In-Reply-To: <CAM_iQpX0mfKJWjDE_2ofKftcr2KgaOkinm70-CdNtNSBj8_cJQ@mail.gmail.com>
Cong Wang <xiyou.wangcong@gmail.com> writes:
> On Wed, May 16, 2018 at 1:29 PM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>> +
>> +static struct Qdisc *cake_leaf(struct Qdisc *sch, unsigned long arg)
>> +{
>> + return NULL;
>> +}
>> +
>> +static unsigned long cake_find(struct Qdisc *sch, u32 classid)
>> +{
>> + return 0;
>> +}
>> +
>> +static void cake_walk(struct Qdisc *sch, struct qdisc_walker *arg)
>> +{
>> +}
>
>
> Thanks for adding the support to other TC filters, it is much better
> now!
You're welcome. Turned out not to be that hard :)
> A quick question: why class_ops->dump_stats is still NULL?
>
> It is supposed to dump the stats of each flow. Is there still any
> difficulty to map it to tc class? I thought you figured it out when
> you added the tcf_classify().
On the classify side, I solved the "multiple sets of queues" problem by
using skb->priority to select the tin (diffserv tier) and the classifier
output to select the queue within that tin. This would not work for
dumping stats; some other way of mapping queues to the linear class
space would be needed. And since we are not actually collecting any
per-flow stats that I could print, I thought it wasn't worth coming up
with a half-baked proposal for this just to add an API hook that no one
in the existing CAKE user base has ever asked for...
-Toke
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox