* [PATCH net-next 3/6] net/bpf_jit: MIPS: split VLAN_PRESENT bit handling from VLAN_TCI
From: Michał Mirosław @ 2018-11-10 18:58 UTC (permalink / raw)
To: netdev
Cc: Ralf Baechle, Paul Burton, James Hogan, linux-mips,
Alexei Starovoitov, Benjamin Herrenschmidt, Daniel Borkmann,
David S. Miller, linuxppc-dev, Michael Ellerman, Paul Mackerras,
sparclinux
In-Reply-To: <cover.1541876179.git.mirq-linux@rere.qmqm.pl>
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
---
arch/mips/net/bpf_jit.c | 21 ++++++++++++---------
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/arch/mips/net/bpf_jit.c b/arch/mips/net/bpf_jit.c
index 4d8cb9bb8365..de4c6372ad9a 100644
--- a/arch/mips/net/bpf_jit.c
+++ b/arch/mips/net/bpf_jit.c
@@ -1159,19 +1159,22 @@ static int build_body(struct jit_ctx *ctx)
emit_load(r_A, r_skb, off, ctx);
break;
case BPF_ANC | SKF_AD_VLAN_TAG:
- case BPF_ANC | SKF_AD_VLAN_TAG_PRESENT:
ctx->flags |= SEEN_SKB | SEEN_A;
BUILD_BUG_ON(FIELD_SIZEOF(struct sk_buff,
vlan_tci) != 2);
off = offsetof(struct sk_buff, vlan_tci);
- emit_half_load_unsigned(r_s0, r_skb, off, ctx);
- if (code == (BPF_ANC | SKF_AD_VLAN_TAG)) {
- emit_andi(r_A, r_s0, (u16)~VLAN_TAG_PRESENT, ctx);
- } else {
- emit_andi(r_A, r_s0, VLAN_TAG_PRESENT, ctx);
- /* return 1 if present */
- emit_sltu(r_A, r_zero, r_A, ctx);
- }
+ emit_half_load_unsigned(r_A, r_skb, off, ctx);
+#ifdef VLAN_TAG_PRESENT
+ emit_andi(r_A, r_A, (u16)~VLAN_TAG_PRESENT, ctx);
+#endif
+ break;
+ case BPF_ANC | SKF_AD_VLAN_TAG_PRESENT:
+ ctx->flags |= SEEN_SKB | SEEN_A;
+ emit_load_byte(r_A, r_skb, PKT_VLAN_PRESENT_OFFSET(), ctx);
+ if (PKT_VLAN_PRESENT_BIT)
+ emit_srl(r_A, r_A, PKT_VLAN_PRESENT_BIT, ctx);
+ if (PKT_VLAN_PRESENT_BIT < 7)
+ emit_andi(r_A, r_A, 1, ctx);
break;
case BPF_ANC | SKF_AD_PKTTYPE:
ctx->flags |= SEEN_SKB;
--
2.19.1
^ permalink raw reply related
* [PATCH net-next 4/6] net/bpf_jit: PPC: split VLAN_PRESENT bit handling from VLAN_TCI
From: Michał Mirosław @ 2018-11-10 18:58 UTC (permalink / raw)
To: netdev
Cc: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
linuxppc-dev, Alexei Starovoitov, Daniel Borkmann,
David S. Miller, James Hogan, linux-mips, Paul Burton,
Ralf Baechle, sparclinux
In-Reply-To: <cover.1541876179.git.mirq-linux@rere.qmqm.pl>
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
---
arch/powerpc/net/bpf_jit_comp.c | 18 ++++++++++--------
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/net/bpf_jit_comp.c b/arch/powerpc/net/bpf_jit_comp.c
index d5bfe24bb3b5..dc4a2f54e829 100644
--- a/arch/powerpc/net/bpf_jit_comp.c
+++ b/arch/powerpc/net/bpf_jit_comp.c
@@ -379,18 +379,20 @@ static int bpf_jit_build_body(struct bpf_prog *fp, u32 *image,
hash));
break;
case BPF_ANC | SKF_AD_VLAN_TAG:
- case BPF_ANC | SKF_AD_VLAN_TAG_PRESENT:
BUILD_BUG_ON(FIELD_SIZEOF(struct sk_buff, vlan_tci) != 2);
- BUILD_BUG_ON(VLAN_TAG_PRESENT != 0x1000);
PPC_LHZ_OFFS(r_A, r_skb, offsetof(struct sk_buff,
vlan_tci));
- if (code == (BPF_ANC | SKF_AD_VLAN_TAG)) {
- PPC_ANDI(r_A, r_A, ~VLAN_TAG_PRESENT);
- } else {
- PPC_ANDI(r_A, r_A, VLAN_TAG_PRESENT);
- PPC_SRWI(r_A, r_A, 12);
- }
+#ifdef VLAN_TAG_PRESENT
+ PPC_ANDI(r_A, r_A, ~VLAN_TAG_PRESENT);
+#endif
+ break;
+ case BPF_ANC | SKF_AD_VLAN_TAG_PRESENT:
+ PPC_LBZ_OFFS(r_A, r_skb, PKT_VLAN_PRESENT_OFFSET());
+ if (PKT_VLAN_PRESENT_BIT)
+ PPC_SRWI(r_A, r_A, PKT_VLAN_PRESENT_BIT);
+ if (PKT_VLAN_PRESENT_BIT < 7)
+ PPC_ANDI(r_A, r_A, 1);
break;
case BPF_ANC | SKF_AD_QUEUE:
BUILD_BUG_ON(FIELD_SIZEOF(struct sk_buff,
--
2.19.1
^ permalink raw reply related
* [PATCH net-next 2/6] net/bpf: split VLAN_PRESENT bit handling from VLAN_TCI
From: Michał Mirosław @ 2018-11-10 18:58 UTC (permalink / raw)
To: netdev
Cc: Alexei Starovoitov, Daniel Borkmann, Benjamin Herrenschmidt,
David S. Miller, James Hogan, linux-mips, linuxppc-dev,
Michael Ellerman, Paul Burton, Paul Mackerras, Ralf Baechle,
sparclinux
In-Reply-To: <cover.1541876179.git.mirq-linux@rere.qmqm.pl>
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
---
net/core/filter.c | 40 +++++++++++++++++++++-------------------
1 file changed, 21 insertions(+), 19 deletions(-)
diff --git a/net/core/filter.c b/net/core/filter.c
index e521c5ebc7d1..c151b906df53 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -296,22 +296,21 @@ static u32 convert_skb_access(int skb_field, int dst_reg, int src_reg,
break;
case SKF_AD_VLAN_TAG:
- case SKF_AD_VLAN_TAG_PRESENT:
BUILD_BUG_ON(FIELD_SIZEOF(struct sk_buff, vlan_tci) != 2);
- BUILD_BUG_ON(VLAN_TAG_PRESENT != 0x1000);
/* dst_reg = *(u16 *) (src_reg + offsetof(vlan_tci)) */
*insn++ = BPF_LDX_MEM(BPF_H, dst_reg, src_reg,
offsetof(struct sk_buff, vlan_tci));
- if (skb_field == SKF_AD_VLAN_TAG) {
- *insn++ = BPF_ALU32_IMM(BPF_AND, dst_reg,
- ~VLAN_TAG_PRESENT);
- } else {
- /* dst_reg >>= 12 */
- *insn++ = BPF_ALU32_IMM(BPF_RSH, dst_reg, 12);
- /* dst_reg &= 1 */
+#ifdef VLAN_TAG_PRESENT
+ *insn++ = BPF_ALU32_IMM(BPF_AND, dst_reg, ~VLAN_TAG_PRESENT);
+#endif
+ break;
+ case SKF_AD_VLAN_TAG_PRESENT:
+ *insn++ = BPF_LDX_MEM(BPF_B, dst_reg, src_reg, PKT_VLAN_PRESENT_OFFSET());
+ if (PKT_VLAN_PRESENT_BIT)
+ *insn++ = BPF_ALU32_IMM(BPF_RSH, dst_reg, PKT_VLAN_PRESENT_BIT);
+ if (PKT_VLAN_PRESENT_BIT < 7)
*insn++ = BPF_ALU32_IMM(BPF_AND, dst_reg, 1);
- }
break;
}
@@ -6140,19 +6139,22 @@ static u32 bpf_convert_ctx_access(enum bpf_access_type type,
break;
case offsetof(struct __sk_buff, vlan_present):
+ *target_size = 1;
+ *insn++ = BPF_LDX_MEM(BPF_B, si->dst_reg, si->src_reg,
+ PKT_VLAN_PRESENT_OFFSET());
+ if (PKT_VLAN_PRESENT_BIT)
+ *insn++ = BPF_ALU32_IMM(BPF_RSH, si->dst_reg, PKT_VLAN_PRESENT_BIT);
+ if (PKT_VLAN_PRESENT_BIT < 7)
+ *insn++ = BPF_ALU32_IMM(BPF_AND, si->dst_reg, 1);
+ break;
+
case offsetof(struct __sk_buff, vlan_tci):
- BUILD_BUG_ON(VLAN_TAG_PRESENT != 0x1000);
-
*insn++ = BPF_LDX_MEM(BPF_H, si->dst_reg, si->src_reg,
bpf_target_off(struct sk_buff, vlan_tci, 2,
target_size));
- if (si->off == offsetof(struct __sk_buff, vlan_tci)) {
- *insn++ = BPF_ALU32_IMM(BPF_AND, si->dst_reg,
- ~VLAN_TAG_PRESENT);
- } else {
- *insn++ = BPF_ALU32_IMM(BPF_RSH, si->dst_reg, 12);
- *insn++ = BPF_ALU32_IMM(BPF_AND, si->dst_reg, 1);
- }
+#ifdef VLAN_TAG_PRESENT
+ *insn++ = BPF_ALU32_IMM(BPF_AND, si->dst_reg, ~VLAN_TAG_PRESENT);
+#endif
break;
case offsetof(struct __sk_buff, cb[0]) ...
--
2.19.1
^ permalink raw reply related
* [PATCH net-next 0/6] Remove VLAN.CFI overload
From: Michał Mirosław @ 2018-11-10 18:58 UTC (permalink / raw)
To: netdev
Cc: Alexei Starovoitov, Benjamin Herrenschmidt, Daniel Borkmann,
David S. Miller, James Hogan, linux-mips, linuxppc-dev,
Michael Ellerman, Paul Burton, Paul Mackerras, Ralf Baechle,
sparclinux
Fix BPF code/JITs to allow for separate VLAN_PRESENT flag
storage and finally move the flag to separate storage in skbuff.
This is final step to make CLAN.CFI transparent to core Linux
networking stack.
An #ifdef is introduced temporarily to mark fragments masking
VLAN_TAG_PRESENT. This is removed altogether in the final patch.
---
Michał Mirosław (6):
net/skbuff: add macros for VLAN_PRESENT bit
net/bpf: split VLAN_PRESENT bit handling from VLAN_TCI
net/bpf_jit: MIPS: split VLAN_PRESENT bit handling from VLAN_TCI
net/bpf_jit: PPC: split VLAN_PRESENT bit handling from VLAN_TCI
net/bpf_jit: SPARC: split VLAN_PRESENT bit handling from VLAN_TCI
net: remove VLAN_TAG_PRESENT
arch/mips/net/bpf_jit.c | 18 ++++++++---------
arch/powerpc/net/bpf_jit_comp.c | 15 +++++++-------
arch/sparc/net/bpf_jit_comp_32.c | 13 ++++++------
include/linux/if_vlan.h | 11 ++++++-----
include/linux/skbuff.h | 10 +++++++++-
lib/test_bpf.c | 14 +++++++------
net/core/filter.c | 34 ++++++++++++++------------------
7 files changed, 60 insertions(+), 55 deletions(-)
--
2.19.1
^ permalink raw reply
* [PATCH net-next 1/6] net/skbuff: add macros for VLAN_PRESENT bit
From: Michał Mirosław @ 2018-11-10 18:58 UTC (permalink / raw)
To: netdev
Cc: David S. Miller, Alexei Starovoitov, Benjamin Herrenschmidt,
Daniel Borkmann, James Hogan, linux-mips, linuxppc-dev,
Michael Ellerman, Paul Burton, Paul Mackerras, Ralf Baechle,
sparclinux
In-Reply-To: <cover.1541876179.git.mirq-linux@rere.qmqm.pl>
Wrap VLAN_PRESENT bit using macro like PKT_TYPE_* and CLONED_*,
as used by BPF code.
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
---
include/linux/skbuff.h | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 7dcfb5591dc3..99f38779332c 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -816,6 +816,12 @@ struct sk_buff {
__u32 priority;
int skb_iif;
__u32 hash;
+#define PKT_VLAN_PRESENT_BIT 4 // CFI (12-th bit) in TCI
+#ifdef __BIG_ENDIAN
+#define PKT_VLAN_PRESENT_OFFSET() offsetof(struct sk_buff, vlan_tci)
+#else
+#define PKT_VLAN_PRESENT_OFFSET() (offsetof(struct sk_buff, vlan_tci) + 1)
+#endif
__be16 vlan_proto;
__u16 vlan_tci;
#if defined(CONFIG_NET_RX_BUSY_POLL) || defined(CONFIG_XPS)
--
2.19.1
^ permalink raw reply related
* [PATCH net-next] OVS: remove VLAN_TAG_PRESENT - fixup
From: Michał Mirosław @ 2018-11-10 18:55 UTC (permalink / raw)
To: netdev; +Cc: Pravin B Shelar, dev
It turns out I missed one VLAN_TAG_PRESENT in OVS code while rebasing.
This fixes it.
Fixes: 9df46aefafa6 ("OVS: remove use of VLAN_TAG_PRESENT")
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
---
net/openvswitch/flow.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/openvswitch/flow.c b/net/openvswitch/flow.c
index fa393815991e..57e07768c9d1 100644
--- a/net/openvswitch/flow.c
+++ b/net/openvswitch/flow.c
@@ -597,7 +597,7 @@ static int key_extract(struct sk_buff *skb, struct sw_flow_key *key)
* skb_vlan_pop(), which will later shift the ethertype into
* skb->protocol.
*/
- if (key->eth.cvlan.tci & htons(VLAN_TAG_PRESENT))
+ if (key->eth.cvlan.tci & htons(VLAN_CFI_MASK))
skb->protocol = key->eth.cvlan.tpid;
else
skb->protocol = key->eth.type;
--
2.19.1
^ permalink raw reply related
* Re: [PATCH net v2] net: sched: cls_flower: validate nested enc_opts_policy to avoid warning
From: David Miller @ 2018-11-10 17:56 UTC (permalink / raw)
To: jakub.kicinski; +Cc: oss-drivers, netdev
In-Reply-To: <20181110050626.6659-1-jakub.kicinski@netronome.com>
From: Jakub Kicinski <jakub.kicinski@netronome.com>
Date: Fri, 9 Nov 2018 21:06:26 -0800
> TCA_FLOWER_KEY_ENC_OPTS and TCA_FLOWER_KEY_ENC_OPTS_MASK can only
> currently contain further nested attributes, which are parsed by
> hand, so the policy is never actually used resulting in a W=1
> build warning:
>
> net/sched/cls_flower.c:492:1: warning: ‘enc_opts_policy’ defined but not used [-Wunused-const-variable=]
> enc_opts_policy[TCA_FLOWER_KEY_ENC_OPTS_MAX + 1] = {
>
> Add the validation anyway to avoid potential bugs when other
> attributes are added and to make the attribute structure slightly
> more clear. Validation will also set extact to point to bad
> attribute on error.
>
> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> Acked-by: Simon Horman <simon.horman@netronome.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH] add an initial version of snmp_counter.rst
From: Randy Dunlap @ 2018-11-10 16:56 UTC (permalink / raw)
To: yupeng, netdev, xiyou.wangcong
In-Reply-To: <20181109181309.5541-1-yupeng0921@gmail.com>
On 11/9/18 10:13 AM, yupeng wrote:
> The snmp_counter.rst run a set of simple experiments, explains the
> meaning of snmp counters depend on the experiments' results. This is
> an initial version, only covers a small part of the snmp counters.
>
> Signed-off-by: yupeng <yupeng0921@gmail.com>
> ---
> Documentation/networking/index.rst | 1 +
> Documentation/networking/snmp_counter.rst | 963 ++++++++++++++++++++++
> 2 files changed, 964 insertions(+)
> create mode 100644 Documentation/networking/snmp_counter.rst
Hi,
> diff --git a/Documentation/networking/snmp_counter.rst b/Documentation/networking/snmp_counter.rst
> new file mode 100644
> index 000000000000..2939c5acf675
> --- /dev/null
> +++ b/Documentation/networking/snmp_counter.rst
> @@ -0,0 +1,963 @@
> +====================
> +snmp counter tutorial
> +====================
First, I would change (almost) all occurrences of "snmp" to "SNMP", unless
it refers to a variable or struct or function etc. (something in C language)
or to the name of this file (document).
> +
> +This document explains the meaning of snmp counters. For understanding
> +their meanings better, this document doesn't explain the counters one
> +by one, but creates a set of experiments, and explains the counters
> +depend on the experiments' results. The experiments are on one or two
depending on
> +virtual machines. Except for the test commands we use in the experiments,
> +the virtual machines have no other network traffic. We use the 'nstat'
> +command to get the values of snmp counters, before every test, we run
counters;
> +'nstat -n' to update the history, so the 'nstat' output would only
> +show the changes of the snmp counters. For more information about
> +nstat, please refer:
> +
> +http://man7.org/linux/man-pages/man8/nstat.8.html
> +
> +icmp ping
> +========
s/icmp/ICMP/
> +
> +Run the ping command against the public dns server 8.8.8.8::
> +
> + nstatuser@nstat-a:~$ ping 8.8.8.8 -c 1
> + PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
> + 64 bytes from 8.8.8.8: icmp_seq=1 ttl=119 time=17.8 ms
> +
> + --- 8.8.8.8 ping statistics ---
> + 1 packets transmitted, 1 received, 0% packet loss, time 0ms
> + rtt min/avg/max/mdev = 17.875/17.875/17.875/0.000 ms
> +
> +The nstayt result::
nstat
> +
> + nstatuser@nstat-a:~$ nstat
> + #kernel
> + IpInReceives 1 0.0
> + IpInDelivers 1 0.0
> + IpOutRequests 1 0.0
> + IcmpInMsgs 1 0.0
> + IcmpInEchoReps 1 0.0
> + IcmpOutMsgs 1 0.0
> + IcmpOutEchos 1 0.0
> + IcmpMsgInType0 1 0.0
> + IcmpMsgOutType8 1 0.0
> + IpExtInOctets 84 0.0
> + IpExtOutOctets 84 0.0
> + IpExtInNoECTPkts 1 0.0
> +
> +The nstat output could be divided into two part: one with the 'Ext'
> +keyword, another without the 'Ext' keyword. If the counter name
> +doesn't have 'Ext', it is defined by one of snmp rfc, if it has 'Ext',
by one of the SNMP RFCs; it is has
> +it is a kernel extent counter. Below we explain them one by one.
> +
> +The rfc defined counters
> +----------------------
s/rfc/RFC/
> +
> +* IpInReceives
> +The total number of input datagrams received from interfaces,
> +including those received in error.
> +
> +https://tools.ietf.org/html/rfc1213#page-26
> +
> +* IpInDelivers
> +The total number of input datagrams successfully delivered to IP
> +user-protocols (including ICMP).
> +
> +https://tools.ietf.org/html/rfc1213#page-28
> +
> +* IpOutRequests
> +The total number of IP datagrams which local IP user-protocols
> +(including ICMP) supplied to IP in requests for transmission. Note
> +that this counter does not include any datagrams counted in
> +ipForwDatagrams.
> +
> +https://tools.ietf.org/html/rfc1213#page-28
> +
> +* IcmpInMsgs
> +The total number of ICMP messages which the entity received. Note
> +that this counter includes all those counted by icmpInErrors.
> +
> +https://tools.ietf.org/html/rfc1213#page-41
> +
> +* IcmpInEchoReps
> +The number of ICMP Echo Reply messages received.
> +
> +https://tools.ietf.org/html/rfc1213#page-42
> +
> +* IcmpOutMsgs
> +The total number of ICMP messages which this entity attempted to send.
> +Note that this counter includes all those counted by icmpOutErrors.
> +
> +https://tools.ietf.org/html/rfc1213#page-43
> +
> +* IcmpOutEchos
> +The number of ICMP Echo (request) messages sent.
> +
> +https://tools.ietf.org/html/rfc1213#page-45
> +
> +IcmpMsgInType0 and IcmpMsgOutType8 are not defined by any snmp related
SNMP-related
> +RFCs, but their meaning are quite straightforward, they count the
meanings straightforward: they count the
> +packet number of specific icmp packet types. We could find the icmp
s/could/can/
s/icmp/ICMP/ 2 times
> +types here:
> +
> +https://www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtml
> +
> +Type 8 is echo, type 0 is echo reply.
> +
> +Until now, we can easily explain these items of the nstat: We sent an
> +icmp echo request, so IpOutRequests, IcmpOutMsgs, IcmpOutEchos and
ICMP
> +IcmpMsgOutType8 were increased 1. We got icmp echo reply from 8.8.8.8,
ICMP
> +so IpInReceives, IcmpInMsgs, IcmpInEchoReps, IcmpMsgInType0 were
> +increased 1. The icmp echo reply was passed to icmp layer via ip
s/icmp/ICMP/ 2 times
s/ip/IP/
> +layer, so IpInDelivers was increased 1.
> +
> +Please note, these metrics don't aware LRO/GRO, e.g., IpOutRequests
aren't aware of
> +might count 1 packet, but hardware splits it to 2, and sends them
> +separately.
> +
> +IpExtInOctets and IpExtOutOctets
> +------------------------------
> +They are linux kernel extensions, no rfc definitions. Please note,
s/linux/Linux/
s/no rfc/not RFC/
> +rfc1213 indeed defines ifInOctets and ifOutOctets, but they
> +are different things. The ifInOctets and ifOutOctets are packets
s/packets/packet/
> +size which includes the mac layer. But IpExtInOctets and IpExtOutOctets
s/size/sizes/
s/mac/MAC/
> +are only ip layer sizes.
s/ip/IP/
> +
> +In our example, an ICMP echo request has four parts:
> +* 14 bytes mac header
MAC
> +* 20 bytes ip header
IP
> +* 16 bytes icmp header
ICMP
> +* 48 bytes data (default value of the ping command)
> +
> +So IpExtInOctets value is 20+16+48=84. The IpExtOutOctets is similar.
value is similar.
> +
> +IpExtInNoECTPkts
> +---------------
> +We could find IpExtInNoECTPkts in the nstat output, but kernel provide
We can find provides
> +four similar counters, we explain them together, they are:
counters. We explain them togther; they are:
> +* IpExtInNoECTPkts
> +* IpExtInECT1Pkts
> +* IpExtInECT0Pkts
> +* IpExtInCEPkts
> +
> +They indicate four kinds of ECN IP packets, they are defined here:
packets;
> +
> +https://tools.ietf.org/html/rfc3168#page-6
> +
> +These 4 counters calculate how many packets received per ECN
> +status. They count the real frame number regardless the LRO/GRO. So
numbers regardless of LRO/GRO. So
> +for the same packet, you might find that IpInReceives count 1, but
that the IpInReceives count is 1, but
> +IpExtInNoECTPkts counts 2 or more.
the IpExtInNoECTPkts count is 2 or more.
> +
> +additional explain
> +-----------------
additional explanation
----------------------
(note: the "---" line must be the same length as the "heading" line above it.
> +The ip layer counters are recorded by the ip layer code in the kernel. I mean, if you send a packet to a lower layer directly, Linux
s/ip/IP/ 2 times
Also split that line so that it is < 80 columns wide.
Then:
This means that
if you send a packet to a lower layer directly, Linux
> +kernel won't record it. For example, tcpreplay will open an
> +AF_PACKET socket, and send the packet to layer 2, although it could send
layer 2, and although it could send
> +an IP packet, you can't find it from the nstat output. Here is an
> +example:
> +
> +We capture the ping packet by tcpdump::
> +
> + nstatuser@nstat-a:~$ sudo tcpdump -w /tmp/ping.pcap dst 8.8.8.8
> +
> +Then run ping command::
> +
> + nstatuser@nstat-a:~$ ping 8.8.8.8 -c 1
> +
> +Terminate tcpdump by Ctrl-C, and run 'nstat -n' to update the nstat
> +history. Then run tcpreplay::
> +
> + nstatuser@nstat-a:~$ sudo tcpreplay --intf1=ens3 /tmp/ping.pcap
> + Actual: 1 packets (98 bytes) sent in 0.000278 seconds
> + Rated: 352517.9 Bps, 2.82 Mbps, 3597.12 pps
> + Flows: 1 flows, 3597.12 fps, 1 flow packets, 0 non-flow
> + Statistics for network device: ens3
> + Successful packets: 1
> + Failed packets: 0
> + Truncated packets: 0
> + Retried packets (ENOBUFS): 0
> + Retried packets (EAGAIN): 0
> +
> +Check the nstat output::
> +
> + nstatuser@nstat-a:~$ nstat
> + #kernel
> + IpInReceives 1 0.0
> + IpInDelivers 1 0.0
> + IcmpInMsgs 1 0.0
> + IcmpInEchoReps 1 0.0
> + IcmpMsgInType0 1 0.0
> + IpExtInOctets 84 0.0
> + IpExtInNoECTPkts 1 0.0
> +
> +We can see, nstat only show the received packet, because the IP layer
We can see that nstat only shows the received packet, because the IP layer
> +of kernel only know the reply of 8.8.8.8, it doesn't know what
of the kernel only knows about the reply of 8.8.8.8; it doesn't know what
> +tcpreplay sent.
> +
> +At the same time, when you use AF_INET socket, even you use the
even if you use the
> +SOCK_RAW option, the IP layer will still try to verify whether the
> +packet is an ICMP packet, if it is, kernel will still count it to its
packet is an ICMP packet. If it is, the kernel will
> +counters and you can find it in the output of nstat.
^^^ interesting.
> +
> +tcp 3 way handshake
> +==================
TCP 3-way handshake
===================
> +
> +On server side, we run::
On the server side,
> +
> + nstatuser@nstat-b:~$ nc -lknv 0.0.0.0 9000
> + Listening on [0.0.0.0] (family 0, port 9000)
> +
> +On client side, we run::
On the client side,
> +
> + nstatuser@nstat-a:~$ nc -nv 192.168.122.251 9000
> + Connection to 192.168.122.251 9000 port [tcp/*] succeeded!
> +
> +The server listened on tcp 9000 port, the client connected to it, they
> +completed the 3-way handshake.
> +
> +On server side, we can find below nstat output::
On the server side, we can see the following nstat output::
> +
> + nstatuser@nstat-b:~$ nstat | grep -i tcp
> + TcpPassiveOpens 1 0.0
> + TcpInSegs 2 0.0
> + TcpOutSegs 1 0.0
> + TcpExtTCPPureAcks 1 0.0
> +
> +On client side, we can find below nstat output::
On the client side, we can see the following nstat output::
> +
> + nstatuser@nstat-a:~$ nstat | grep -i tcp
> + TcpActiveOpens 1 0.0
> + TcpInSegs 1 0.0
> + TcpOutSegs 2 0.0
> +
> +Except for TcpExtTCPPureAcks, all other counters are defined by rfc1213
by rfc1213.
and that's just part of a file name; I would really prefer to see:
by RFC 1213.
> +
> +* TcpActiveOpens
> +The number of times TCP connections have made a direct transition to
> +the SYN-SENT state from the CLOSED state.
> +
> +https://tools.ietf.org/html/rfc1213#page-47
> +
> +* TcpPassiveOpens
> +The number of times TCP connections have made a direct transition to
> +the SYN-RCVD state from the LISTEN state.
> +
> +https://tools.ietf.org/html/rfc1213#page-47
> +
> +* TcpInSegs
> +The total number of segments received, including those received in
> +error. This count includes segments received on currently established
> +connections.
> +
> +https://tools.ietf.org/html/rfc1213#page-48
> +
> +* TcpOutSegs
> +The total number of segments sent, including those on current
> +connections but excluding those containing only retransmitted octets.
> +
> +https://tools.ietf.org/html/rfc1213#page-48
> +
> +
> +The TcpExtTCPPureAcks is an extension in linux kernel. When kernel
in the Linux kernel. When the kernel
> +receives a TCP packet which set ACK flag and with no data, either
sets the ACK flag and with no data, either
> +TcpExtTCPPureAcks or TcpExtTCPHPAcks will increase 1. We will discuss
> +it in a later section.
s/it/this/
> +
> +Now we can easily explain the nstat outputs on the server side and client
> +side.
> +
> +When the server received the first syn, it replied a syn+ack, and came into
it replied with a syn+ack,
> +SYN-RCVD state, so TcpPassiveOpens increased 1. The server received
> +syn, sent syn+ack, received ack, so server sent 1 packet, received 2
> +packets, TcpInSegs increased 2, TcpOutSegs increased 1. The last ack
> +of the 3-way handshake is a pure ack without data, so
> +TcpExtTCPPureAcks increased 1.
> +
> +When the client sent syn, the client came into the SYN-SENT state, so
> +TcpActiveOpens increased 1, client sent syn, received syn+ack, sent
> +ack, so client sent 2 packets, received 1 packet, TcpInSegs increased
> +1, TcpOutSegs increased 2.
> +
> +Note: about TcpInSegs and TcpOutSegs, rfc1213 doesn't define the
> +behaviors when gso/gro/tso are enabled on the NIC (network interface
GSO/GRO/TSO
> +card). On current linux implementation, TcpOutSegs awares gso/tso, but
Linux is aware of GSO/TSO, but
> +TcpInSegs doesn't aware gro. So TcpOutSegs will count the actual
isn't aware of GRO.
> +packet number even only 1 packet is sent via tcp layer. If multiple
even if only 1 packet is sent via the TCP later.
> +packets arrived at a NIC, and they are merged into 1 packet, TcpInSegs
> +will only count 1.
> +
> +tcp disconnect
> +=============
TCP disconnect
==============
> +
> +Continue our previous example, on the server side, we have run::
Continuing
> +
> + nstatuser@nstat-b:~$ nc -lknv 0.0.0.0 9000
> + Listening on [0.0.0.0] (family 0, port 9000)
> +
> +On client side, we have run::
> +
> + nstatuser@nstat-a:~$ nc -nv 192.168.122.251 9000
> + Connection to 192.168.122.251 9000 port [tcp/*] succeeded!
> +
> +Now we type Ctrl-C on the client side, stop the tcp connection between the
stopping the TCP
> +two nc command. Then we check the nstat output.
commands.
> +
> +On server side::
> +
> + nstatuser@nstat-b:~$ nstat | grep -i tcp
> + TcpInSegs 2 0.0
> + TcpOutSegs 1 0.0
> + TcpExtTCPPureAcks 1 0.0
> + TcpExtTCPOrigDataSent 1 0.0
> +
> +On client side::
> +
> + nstatuser@nstat-b:~$ nstat | grep -i tcp
> + TcpInSegs 2 0.0
> + TcpOutSegs 1 0.0
> + TcpExtTCPPureAcks 1 0.0
> + TcpExtTCPOrigDataSent 1 0.0
> +
> +Wait for more than 1 minute, run nstat on client again::
> +
> + nstatuser@nstat-a:~$ nstat | grep -i tcp
> + TcpExtTW 1 0.0
> +
> +Most of the counters are explained in the previous section except
> +two: TcpExtTCPOrigDataSent and TcpExtTW. Both of them are linux kernel
s/linux/Linux/
> +extensions.
> +
> +TcpExtTW means a tcp connection is closed normally via
s/tcp/TCP/
> +time wait stage, not via tcp reuse process.
s/tcp/TCP/
> +
> +About TcpExtTCPOrigDataSent, Below kernel patch has a good explanation:
the below kernel patch has
> +
> +https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f19c29e3e391a66a273e9afebaf01917245148cd
> +
> +I pasted it here::
> +
> + TCPOrigDataSent: number of outgoing packets with original data
> + (excluding retransmission but including data-in-SYN). This counter is
> + different from TcpOutSegs because TcpOutSegs also tracks pure
> + ACKs. TCPOrigDataSent is more useful to track the TCP retransmission rate.
> +
> +the effect of gso and gro
> +=======================
the effect of GSO and GRO
=========================
> +
> +The Generic Segmentation Offload (GSO) and Generic Receive Offload
Offload (GRO)
> +would affect the metrics of the packet in/out on both ip and tcp
on both IP and TCP
> +layer. Here is an iperf example. Before the test, run below command to
layers. run the command below to
> +make sure both gso and gro are enabled on the NIC::
GSO and GRO
> +
> + $ sudo ethtool -k ens3 | egrep '(generic-segmentation-offload|generic-receive-offload)'
> + generic-segmentation-offload: on
> + generic-receive-offload: on
> +
> +On server side, run::
On the server side,
> +
> + iperf3 -s -p 9000
> +
> +On client side, run::
On the client side,
> +
> + iperf3 -c 192.168.122.251 -p 9000 -t 5 -P 10
> +
> +The server listened on tcp port 9000, the client connected to the server,
TCP
> +created 10 threads parallel, run 5 seconds. After the pierf3 stopped, we
After iperf3 stopped, we
> +run nstat on both the server and client.
> +
> +On server side::
On the server side::
> +
> + nstatuser@nstat-b:~$ nstat
> + #kernel
> + IpInReceives 36346 0.0
> + IpInDelivers 36346 0.0
> + IpOutRequests 33836 0.0
> + TcpPassiveOpens 11 0.0
> + TcpEstabResets 2 0.0
> + TcpInSegs 36346 0.0
> + TcpOutSegs 33836 0.0
> + TcpOutRsts 20 0.0
> + TcpExtDelayedACKs 26 0.0
> + TcpExtTCPHPHits 32120 0.0
> + TcpExtTCPPureAcks 16 0.0
> + TcpExtTCPHPAcks 5 0.0
> + TcpExtTCPAbortOnData 5 0.0
> + TcpExtTCPAbortOnClose 2 0.0
> + TcpExtTCPRcvCoalesce 7306 0.0
> + TcpExtTCPOFOQueue 1354 0.0
> + TcpExtTCPOrigDataSent 15 0.0
> + IpExtInOctets 311732432 0.0
> + IpExtOutOctets 1785119 0.0
> + IpExtInNoECTPkts 214032 0.0
> +
> +Client side::
On the client side::
> +
> + nstatuser@nstat-a:~$ nstat
> + #kernel
> + IpInReceives 33836 0.0
> + IpInDelivers 33836 0.0
> + IpOutRequests 43786 0.0
> + TcpActiveOpens 11 0.0
> + TcpEstabResets 10 0.0
> + TcpInSegs 33836 0.0
> + TcpOutSegs 214072 0.0
> + TcpRetransSegs 3876 0.0
> + TcpExtDelayedACKs 7 0.0
> + TcpExtTCPHPHits 5 0.0
> + TcpExtTCPPureAcks 2719 0.0
> + TcpExtTCPHPAcks 31071 0.0
> + TcpExtTCPSackRecovery 607 0.0
> + TcpExtTCPSACKReorder 61 0.0
> + TcpExtTCPLostRetransmit 90 0.0
> + TcpExtTCPFastRetrans 3806 0.0
> + TcpExtTCPSlowStartRetrans 62 0.0
> + TcpExtTCPLossProbes 38 0.0
> + TcpExtTCPSackRecoveryFail 8 0.0
> + TcpExtTCPSackShifted 203 0.0
> + TcpExtTCPSackMerged 778 0.0
> + TcpExtTCPSackShiftFallback 700 0.0
> + TcpExtTCPSpuriousRtxHostQueues 4 0.0
> + TcpExtTCPAutoCorking 14 0.0
> + TcpExtTCPOrigDataSent 214038 0.0
> + TcpExtTCPHystartTrainDetect 8 0.0
> + TcpExtTCPHystartTrainCwnd 172 0.0
> + IpExtInOctets 1785227 0.0
> + IpExtOutOctets 317789680 0.0
> + IpExtInNoECTPkts 33836 0.0
> +
> +The TcpOutSegs and IpOutRequests on the server are 33836, exactly the
> +same as IpExtInNoECTPkts, IpInReceives, IpInDelivers and TcpInSegs on
> +the client side. During iperf3 test, the server only reply very short
replies with very short
> +packets, so gso and gro has no effect on the server's reply.
so GSO and GRO have no effect
> +
> +On the client side, TcpOutSegs is 214072, IpOutRequests is 43786, the
> +tcp layer packet out is larger than ip layer packet out, because
TCP layer packet size out is larger than the IP layer packet size out, because
> +TcpOutSegs count the packet number after gso, but IpOutRequests
counts GSO,
> +doesn't. On the server side, IpExtInNoECTPkts is 214032, this number
is 214032; this number
> +is smaller a little than the TcpOutSegs on the client side (214072), it
; it
> +might cause by the packet loss. The IpInReceives, IpInDelivers and
might be caused by packet loss.
> +TcpInSegs are obviously smaller than the TcpOutSegs on the client side,
> +because these counters calculate the packet after gro.
packet counts after GRO.
> +
> +tcp counters in established state
> +================================
TCP counters in established state
=================================
> +
> +Run nc on server::
> +
> + nstatuser@nstat-b:~$ nc -lkv 0.0.0.0 9000
> + Listening on [0.0.0.0] (family 0, port 9000)
> +
> +Run nc on client:
> +
> + nstatuser@nstat-a:~$ nc -v nstat-b 9000
> + Connection to nstat-b 9000 port [tcp/*] succeeded!
> +
> +Input a string in the nc client ('hello' in our example):
> +
> + nstatuser@nstat-a:~$ nc -v nstat-b 9000
> + Connection to nstat-b 9000 port [tcp/*] succeeded!
> + hello
> +
> +The client side nstat output:
> +
> + nstatuser@nstat-a:~$ nstat
> + #kernel
> + IpInReceives 1 0.0
> + IpInDelivers 1 0.0
> + IpOutRequests 1 0.0
> + TcpInSegs 1 0.0
> + TcpOutSegs 1 0.0
> + TcpExtTCPPureAcks 1 0.0
> + TcpExtTCPOrigDataSent 1 0.0
> + IpExtInOctets 52 0.0
> + IpExtOutOctets 58 0.0
> + IpExtInNoECTPkts 1 0.0
> +
> +The server side nstat output:
> +
> + nstatuser@nstat-b:~$ nstat
> + #kernel
> + IpInReceives 1 0.0
> + IpInDelivers 1 0.0
> + IpOutRequests 1 0.0
> + TcpInSegs 1 0.0
> + TcpOutSegs 1 0.0
> + IpExtInOctets 58 0.0
> + IpExtOutOctets 52 0.0
> + IpExtInNoECTPkts 1 0.0
> +
> +Input a string in nc client side again ('world' in our exmaple):
> +
> + nstatuser@nstat-a:~$ nc -v nstat-b 9000
> + Connection to nstat-b 9000 port [tcp/*] succeeded!
> + hello
> + world
> +
> +Client side nstat output:
> +
> + nstatuser@nstat-a:~$ nstat
> + #kernel
> + IpInReceives 1 0.0
> + IpInDelivers 1 0.0
> + IpOutRequests 1 0.0
> + TcpInSegs 1 0.0
> + TcpOutSegs 1 0.0
> + TcpExtTCPHPAcks 1 0.0
> + TcpExtTCPOrigDataSent 1 0.0
> + IpExtInOctets 52 0.0
> + IpExtOutOctets 58 0.0
> + IpExtInNoECTPkts 1 0.0
> +
> +
> +Server side nstat output:
> +
> + nstatuser@nstat-b:~$ nstat
> + #kernel
> + IpInReceives 1 0.0
> + IpInDelivers 1 0.0
> + IpOutRequests 1 0.0
> + TcpInSegs 1 0.0
> + TcpOutSegs 1 0.0
> + TcpExtTCPHPHits 1 0.0
> + IpExtInOctets 58 0.0
> + IpExtOutOctets 52 0.0
> + IpExtInNoECTPkts 1 0.0
> +
> +Compare the first client side output and the second client side
Comparing
> +output, we could find one difference: the first one had a
> +'TcpExtTCPPureAcks', but the second one had a
> +'TcpExtTCPHPAcks'. The first server side output and the second server
> +side output had a difference too: the second server side output had a
> +TcpExtTCPHPHits, but the first server side output didn't have it. The
Next line is too long -- split it into < 80 columns.
> +network traffic patterns were exactly the same: the client sent a packet to the server, the server replied an ack. But kernel handled them in different
But the kernel handled them in different
> +ways. When kernel receives a tpc packet in the established status,
When the kernel receives a TCP packet
> +kernel has two paths to handle the packet, one is fast path, another
the kernel has two paths to handle the packet: one is the fast path and the other
> +is slow path. The comment in kernel code provides a good explanation of
is the slow path.
> +them, I paste them below:
> +
> + It is split into a fast path and a slow path. The fast path is
> + disabled when:
> + - A zero window was announced from us - zero window probing
> + is only handled properly on the slow path.
> + - Out of order segments arrived.
> + - Urgent data is expected.
> + - There is no buffer space left
> + - Unexpected TCP flags/window values/header lengths are received
> + (detected by checking the TCP header against pred_flags)
> + - Data is sent in both directions. The fast path only supports pure senders
> + or pure receivers (this means either the sequence number or the ack
> + value must stay constant)
> + - Unexpected TCP option.
> +
> +Kernel will try to use fast path unless any of the above conditions
The kernel will try to use the fast path
> +are satisfied. If the packets are out of order, kernel will handle
is satisfied. order, the kernel will handle
> +them in slow path, which means the performance might be not very
in the slow path,
> +good. Kernel would also come into slow path if the "Delayed ack" is
The kernel into the slow path
> +used, because when using "Delayed ack", the data is sent in both
> +directions. When the tcp window scale option is not used, kernel will
TCP not used, the kernel will
> +try to enable fast path immediately when the connection comes into the established
> +state, but if the tcp window scale option is used, kernel will disable
TCP used, the kernel will
> +the fast path at first, and try to enable it after kerenl receives
after the kernel receives
> +packets. We could use the 'ss' command to verify whether the window
> +scale option is used. e.g. run below command on either server or
E.g., run the command below on either the server or the
> +client:
> +
> + nstatuser@nstat-a:~$ ss -o state established -i '( dport = :9000 or sport = :9000 )
> + Netid Recv-Q Send-Q Local Address:Port Peer Address:Port
> + tcp 0 0 192.168.122.250:40654 192.168.122.251:9000
> + ts sack cubic wscale:7,7 rto:204 rtt:0.98/0.49 mss:1448 pmtu:1500 rcvmss:536 advmss:1448 cwnd:10 bytes_acked:1 segs_out:2 segs_in:1 send 118.2Mbps lastsnd:46572 lastrcv:46572 lastack:46572 pacing_rate 236.4Mbps rcv_space:29200 rcv_ssthresh:29200 minrtt:0.98
> +
> +The 'wscale:7,7' means both server and client set the window scale
> +option to 7. Now we could explain the nstat output in our test:
> +
> +In the first nstat output of client side, the client sent a packet, server
of the client side, the server
> +reply an ack, when kernel handled this ack, the fast path was not
replied with an ack; when the kernel handled this ack,
> +enabled, so the ack was counted into 'TcpExtTCPPureAcks'.
> +In the second nstat output of client side, the client sent a packet again,
the client side,
> +and received another ack from the server, this time, the fast path is
from the server; this time,
> +enabled, and the ack was qualified for fast path, so it was handled by
> +the fast path, so this ack was counted into TcpExtTCPHPAcks.
> +In the first nstat output of server side, the fast path was not enabled,
of the server side,
> +so there was no 'TcpExtTCPHPHits'.
> +In the second nstat output of server side, the fast path was enabled,
of the server side,
> +and the packet received from client qualified for fast path, so it
from the client qualified for the fast path,
> +was counted into 'TcpExtTCPHPHits'.
> +
> +tcp abort
> +========
TCP abort
=========
> +
> +Some counters indicate the reaons why tcp layer want to send a rst,
why the TCP layer may want to send a RST.
What is "rst"? or "RST" in RFCs?
> +they are:
The are:
> +* TcpExtTCPAbortOnData
> +* TcpExtTCPAbortOnClose
> +* TcpExtTCPAbortOnMemory
> +* TcpExtTCPAbortOnTimeout
> +* TcpExtTCPAbortOnLinger
> +* TcpExtTCPAbortFailed
> +
> +TcpExtTCPAbortOnData
> +-------------------
--------------------
(same length as text above it)
> +
> +It means tcp layer has data in flight, but need to close the
means the TCP layer needs
> +connection. So tcp layer sends a rst to the other side, indicate the
the TCP layer indicating
> +connection is not closed very graceful. An easy way to increase this
is not closed gracefully.
> +counter is using the SO_LINGER option. Please refer to the SO_LINGER
> +section of the socket man page:
> +
> +http://man7.org/linux/man-pages/man7/socket.7.html).
> +
> +By default, when an application closes a connection, the close function
> +will return immediately and kernel will try to send the in-flight data
and the kernel
> +async. If you use the SO_LINGER option, set l_onoff to 1, and l_linger
> +to a positive number, the close function won't return immediately, but
> +wait for the in-flight data are acked by the other side, the max wait
data to be acked by the other side;
> +time is l_linger seconds. If set l_onoff to 1 and set l_linger to 0,
> +when the application closes a connection, kernel will send an rst
the kernel will send an RST
> +immediately, and increase the TcpExtTCPAbortOnData counter.
> +
> +We run nc on the server side::
> +
> + nstatuser@nstat-b:~$ nc -lkv 0.0.0.0 9000
> + Listening on [0.0.0.0] (family 0, port 9000)
> +
> +Run below python code on the client side::
Run the below
> +
> + import socket
> + import struct
> +
> + server = 'nstat-b' # server address
> + port = 9000
> +
> + s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
> + s.setsockopt(socket.SOL_SOCKET, socket.SO_LINGER, struct.pack('ii', 1, 0))
> + s.connect((server, port))
> + s.close()
> +
> +On client side, we could see TcpExtTCPAbortOnData increased::
On the client side,
> +
> + nstatuser@nstat-a:~$ nstat | grep -i abort
> + TcpExtTCPAbortOnData 1 0.0
> +
> +If we capture packet by tcpdump, we could see the client send rst
packets RST
> +instead of fin.
FIN.
> +
> +
> +TcpExtTCPAbortOnClose
> +--------------------
---------------------
> +
> +This counter means the tcp layer has unread data when an application
TCP
> +want to close a connection.
wants
> +
> +On the server side, we run below python script:
run the below
> +
> + import socket
> + import time
> +
> + port = 9000
> +
> + s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
> + s.bind(('0.0.0.0', port))
> + s.listen(1)
> + sock, addr = s.accept()
> + while True:
> + time.sleep(9999999)
> +
> +This python script listen on 9000 port, but doesn't read anything from
listens on port 9000,
> +the connection.
> +
> +On the client side, we send the string "hello" by nc:
> +
> + nstatuser@nstat-a:~$ echo "hello" | nc nstat-b 9000
> +
> +Then, we come back to the server side, the server has received the "hello"
side;
> +packet, and tcp layer has acked this packet, but the application didn't
and the TCP layer
> +read it yet. We type Ctrl-C to terminate the server script. Then we
> +could find TcpExtTCPAbortOnClose increased 1 on the server side:
> +
> + nstatuser@nstat-b:~$ nstat | grep -i abort
> + TcpExtTCPAbortOnClose 1 0.0
> +
> +If we run tcpdump on the server side, we could find the server sent a
> +rst after we type Ctrl-C.
RST
> +
> +TcpExtTCPAbortOnMemory
> +--------------------
----------------------
> +
> +When an application closes a tcp connection, kernel still need to track
TCP the kernel still needs
> +the connection, let it complete the tcp disconnect process. E.g. an
TCP
> +app calls the close method of a socket, kernel sends fin to the other
the kernel sends FIN
> +side of the connection, then the app has no relationship with the
> +socket any more, but kernel need to keep the socket, this socket
but the kernel needs
> +becomes an orphan socket, kernel waits for the reply of the other side,
the kernel
> +and would come to the TIME_WAIT state finally. When kernel has no
the kernel does not have
> +enough memory to keep the orphan socket, kernel would send an rst to
the kernel sends an RST to
> +the other side, and delete the socket, in such situation, kernel will
deletes the socket. In such situation, the kernel will
> +increase 1 to the TcpExtTCPAbortOnMemory. Two conditions would trigger
> +TcpExtTCPAbortOnMemory:
> +
> +* the memory used by tcp protocol is higher than the third value of
by the TCP
> +the tcp_mem. Please refer the tcp_mem section in the tcp man page:
> +
> +http://man7.org/linux/man-pages/man7/tcp.7.html
> +
> +* the orphan socket count is higher than net.ipv4.tcp_max_orphans
> +
> +Below is an example which let the orphan socket count be higher than
lets
> +net.ipv4.tcp_max_orphans.
> +
> +Change tcp_max_orphans to a smaller value on client::
on the client::
> +
> + sudo bash -c "echo 10 > /proc/sys/net/ipv4/tcp_max_orphans"
> +
> +Client code (create 64 connection to server)::
64 connections to the server)::
> +
> + nstatuser@nstat-a:~$ cat client_orphan.py
> + import socket
> + import time
> +
> + server = 'nstat-b' # server address
> + port = 9000
> +
> + count = 64
> +
> + connection_list = []
> +
> + for i in range(64):
> + s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
> + s.connect((server, port))
> + connection_list.append(s)
> + print("connection_count: %d" % len(connection_list))
> +
> + while True:
> + time.sleep(99999)
> +
> +Server code (accept 64 connection from client)::
64 connections from the client)::
> +
> + nstatuser@nstat-b:~$ cat server_orphan.py
> + import socket
> + import time
> +
> + port = 9000
> + count = 64
> +
> + s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
> + s.bind(('0.0.0.0', port))
> + s.listen(count)
> + connection_list = []
> + while True:
> + sock, addr = s.accept()
> + connection_list.append((sock, addr))
> + print("connection_count: %d" % len(connection_list))
> +
> +Run the python scripts on server and client.
> +
> +On server::
> +
> + python3 server_orphan.py
> +
> +On client::
> +
> + python3 client_orphan.py
> +
> +Run iptables on server::
> +
> + sudo iptables -A INPUT -i ens3 -p tcp --destination-port 9000 -j DROP
> +
> +Type Ctrl-C on client, stop client_orphan.py.
stopping
> +
> +Check TcpExtTCPAbortOnMemory on client::
on the client::
> +
> + nstatuser@nstat-a:~$ nstat | grep -i abort
> + TcpExtTCPAbortOnMemory 54 0.0
> +
> +Check orphane socket count on client::
orphaned socket count on the client::
> +
> + nstatuser@nstat-a:~$ ss -s
> + Total: 131 (kernel 0)
> + TCP: 14 (estab 1, closed 0, orphaned 10, synrecv 0, timewait 0/0), ports 0
> +
> + Transport Total IP IPv6
> + * 0 - -
> + RAW 1 0 1
> + UDP 1 1 0
> + TCP 14 13 1
> + INET 16 14 2
> + FRAG 0 0 0
> +
> +The explanation of the test: after run server_orphan.py and
running
> +client_orphan.py, we set up 64 connections between server and
> +client. Run the iptables command, the server will drop all packets from
command. The server
> +the client, type Ctrl-C on client_orphan.py, the system of the client
client. Type
> +would try to close these connections, and before they are closed
> +gracefully, these connections became orphan sockets. As the iptables
> +of the server blocked packets from the client, the server won't receive fin
FIN
> +from the client, so all connection on clients would be stuck on FIN_WAIT_1
> +stage, so they will keep as orphan sockets until timeout. We have echo
will be kept as We have echo-ed
> +10 to /proc/sys/net/ipv4/tcp_max_orphans, so the client system would
> +only keep 10 orphan sockets, for all other orphan sockets, the client
sockets;
> +system sent rst for them and delete them. We have 64 connections, so
RST and deleted them.
> +the 'ss -s' command shows the system has 10 orphan sockets, and the
> +value of TcpExtTCPAbortOnMemory was 54.
> +
> +An additional explanation about orphan socket count: You could find the
> +exactly orphan socket count by the 'ss -s' command, but when kernel
exact but when the kernel
> +decide whither increases TcpExtTCPAbortOnMemory and sends rst, kernel
decides whether to increase RST, the kernel
> +doesn't always check the exactly orphan socket count. For increasing
exact
> +performance, kernel checks an approximate count firstly, if the
the kernel first; if the
> +approximate count is more than tcp_max_orphans, kernel checks the
the kernel checks the
> +exact count again. So if the approximate count is less than
> +tcp_max_orphans, but exactly count is more than tcp_max_orphans, you
but the exact count
> +would find TcpExtTCPAbortOnMemory is not increased at all. If
> +tcp_max_orphans is large enough, it won't occur, but if you decrease
> +tcp_max_orphans to a small value like our test, you might find this
> +issue. So in our test, the client set up 64 connections although the
although [drop "the"]
> +tcp_max_orphans is 10. If the client only set up 11 connections, we
> +can't find the change of TcpExtTCPAbortOnMemory.
> +
> +TcpExtTCPAbortOnTimeout
> +----------------------
-----------------------
> +This counter will increase when any of the tcp timers expire. In this
TCP
> +situation, kernel won't send rst, just give up the connection.
the kernel RST; it just gives up the connection.
> +Continue the previous test, we wait for several minutes, because the
Continuing
> +iptables on the server blocked the traffic, the server wouldn't receive
> +fin, and all the client's orphan sockets would timeout on the
FIN,
> +FIN_WAIT_1 state finally. So we wait for a few minutes, we could find
So if we wait for a few minutes, we can find
> +10 timeout on the client::
10 timeouts
> +
> + nstatuser@nstat-a:~$ nstat | grep -i abort
> + TcpExtTCPAbortOnTimeout 10 0.0
> +
> +TcpExtTCPAbortOnLinger
> +---------------------
----------------------
> +When a tcp connection comes into FIN_WAIT_2 state, instead of waiting
TCP
> +for the fin packet from the other side, kernel could send a rst and
FIN the kernel an RST
> +delete the socket immediately. This is not the default behavior of
> +linux kernel tcp stack, but after configuring socket option, you could
the Linux kernel TCP stack,
> +let kernel follow this behavior. Below is an example.
find the kernel following this behavior.
> +
> +The server side code::
> +
> + nstatuser@nstat-b:~$ cat server_linger.py
> + import socket
> + import time
> +
> + port = 9000
> +
> + s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
> + s.bind(('0.0.0.0', port))
> + s.listen(1)
> + sock, addr = s.accept()
> + while True:
> + time.sleep(9999999)
> +
> +The client side code::
> +
> + nstatuser@nstat-a:~$ cat client_linger.py
> + import socket
> + import struct
> +
> + server = 'nstat-b' # server address
> + port = 9000
> +
> + s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
> + s.setsockopt(socket.SOL_SOCKET, socket.SO_LINGER, struct.pack('ii', 1, 10))
> + s.setsockopt(socket.SOL_TCP, socket.TCP_LINGER2, struct.pack('i', -1))
> + s.connect((server, port))
> + s.close()
> +
> +Run server_linger.py on server::
> +
> + nstatuser@nstat-b:~$ python3 server_linger.py
> +
> +Run client_linger.py on client::
> +
> + nstatuser@nstat-a:~$ python3 client_linger.py
> +
> +After run client_linger.py, check the output of nstat::
running
> +
> + nstatuser@nstat-a:~$ nstat | grep -i abort
> + TcpExtTCPAbortOnLinger 1 0.0
> +
> +TcpExtTCPAbortFailed
> +-------------------
--------------------
> +The kernel tcp layer will send rst if the RFC 2525 2.17 section is satisfied:
TCP RST
> +
> +https://tools.ietf.org/html/rfc2525#page-50
> +
> +If an internal error occurs during this process, TcpExtTCPAbortFailed
> +will be increased.
> +
> +TcpExtListenOverflows and TcpExtListenDrops
> +========================================
===========================================
> +When kernel receive a syn from a client, and if the tcp accept queue
the kernel receives a SYN TCP
> +is full, kernel will drop the syn and add 1 to TcpExtListenOverflows.
the kernel SYN
> +At the same time kernel will also add 1 to TcpExtListenDrops. When
the kernel
> +a tcp socket is in LISTEN state, and kernel need to drop a packet,
TCP the kernel needs
> +kernel would always add 1 to TcpExtListenDrops. So increase
the kernel
> +TcpExtListenOverflows would let TcpExtListenDrops increasing at the
increase at
> +same time, but TcpExtListenDrops would also increase without
> +TcpExtListenOverflows increasing, e.g. a memory allocation fail would
failure would
> +also let TcpExtListenDrops increase.
> +
> +Note: The above explain bases on kernel 4.15 or above version, on an
explanation is based on kernel version 4.15 or above; on an
> +old kernel, the tcp stack has different behavior when tcp accept queue
older TCP when the TCP
> +is full. On the old kernel, tcp stack won't drop the syn, it would
older the TCP stack SYN; it would
> +complete the 3-way handshake, but as the accept queue is full, tcp
the TCP
> +stack will keep the socket in the tcp half-open queue. As it is in the
TCP
> +half open queue, tcp stack will send syn+ack on an exponential backoff
the TCP SYN+ACK
> +timer, after client replies ack, tcp stack checks whether the accept
timer. After the client replies with ACK, the TCP stack
> +queue is still full, if it is not full, move the socket to accept
full. If it socket to the accept
> +queue, if it is full, keeps the socket in the half-open queue, at next
queue. If it is full, keep the socket queue. The next
> +time client replies ack, this socket will get another chance to move
time the client replies with ACK,
> +to the accept queue.
> +
> +Here is an example:
> +
> +On server, run the nc command, listen on port 9000::
> +
> + nstatuser@nstat-b:~$ nc -lkv 0.0.0.0 9000
> + Listening on [0.0.0.0] (family 0, port 9000)
> +
> +On client, run 3 nc commands in different terminals::
> +
> + nstatuser@nstat-a:~$ nc -v nstat-b 9000
> + Connection to nstat-b 9000 port [tcp/*] succeeded!
> +
> +The nc command only accepts 1 connection, and the accept queue length
> +is 1. On current linux implementation, set queue length to n means the
the current Linux
> +actual queue length is n+1. Now we create 3 connections, 1 is accepted
> +by nc, 2 in accepted queue, so the accept queue is full.
> +
> +Before running the 4th nc, we clean the nstat history on the server:
> +
> + nstatuser@nstat-b:~$ nstat -n
> +
> +Run the 4th nc on the client:
> +
> + nstatuser@nstat-a:~$ nc -v nstat-b 9000
> +
> +If the nc server is running on kernel 4.15 or higher version, you
> +won't see the "Connection to ... succeeded!" string, because kernel
the kernel
> +will drop the syn if the accept queue is full. If the nc client is running
SYN
> +on an old kernel, you could see that the connection is succeeded,
older that the connection succeeded,
> +because kernel would complete the 3-way handshake and keep the socket
the kernel
> +on the half-open queue.
> +
> +Our test is on kernel 4.15, run nstat on the server:
4.15. Run nstat on the server:
> +
> + nstatuser@nstat-b:~$ nstat
> + #kernel
> + IpInReceives 4 0.0
> + IpInDelivers 4 0.0
> + TcpInSegs 4 0.0
> + TcpExtListenOverflows 4 0.0
> + TcpExtListenDrops 4 0.0
> + IpExtInOctets 240 0.0
> + IpExtInNoECTPkts 4 0.0
> +
> +We can see both TcpExtListenOverflows and TcpExtListenDrops are 4. If
> +the time between the 4th nc and the nstat is longer, the value of
> +TcpExtListenOverflows and TcpExtListenDrops will be larger, because
> +the syn of the 4th nc is dropped, it keeps retrying.
SYN
That last sentence needs to be split up some to be more clear.
Use one or more periods ('.') and not so many commas.
--
~Randy
^ permalink raw reply
* Re: KASAN: slab-out-of-bounds Write in __xfrm_policy_unlink
From: Dmitry Vyukov @ 2018-11-11 1:57 UTC (permalink / raw)
To: syzbot
Cc: David Miller, Herbert Xu, LKML, netdev, Steffen Klassert,
syzkaller-bugs
In-Reply-To: <CACT4Y+YO6i-rEAydWQPadtGw7w_ZDT58Mt6XYybnBdUQMcxh-Q@mail.gmail.com>
On Sat, Nov 10, 2018 at 5:55 PM, Dmitry Vyukov <dvyukov@google.com> wrote:
> On Sat, Nov 10, 2018 at 5:54 PM, syzbot
> <syzbot+1a5442803e5354a25766@syzkaller.appspotmail.com> wrote:
>> Hello,
>>
>> syzbot found the following crash on:
>>
>> HEAD commit: 29e12207174a sfc: use the new __netdev_tx_sent_queue BQL o..
>> git tree: net-next
>> console output: https://syzkaller.appspot.com/x/log.txt?x=133c2c5d400000
>> kernel config: https://syzkaller.appspot.com/x/.config?x=8f559fee2fc3375a
>> dashboard link: https://syzkaller.appspot.com/bug?extid=1a5442803e5354a25766
>> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>>
>> Unfortunately, I don't have any reproducer for this crash yet.
>>
>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> Reported-by: syzbot+1a5442803e5354a25766@syzkaller.appspotmail.com
>
> May be related to "KASAN: slab-out-of-bounds Write in __xfrm_policy_unlink"
> https://syzkaller.appspot.com/bug?extid=aa77660edbf949365033
Obviously related to itself :)
I meant "KASAN: use-after-free Write in __xfrm_policy_unlink"
https://syzkaller.appspot.com/bug?id=ebeba334a8a886e3d5dc25641e201e894d4d9657
>> ==================================================================
>> BUG: KASAN: slab-out-of-bounds in __write_once_size
>> include/linux/compiler.h:209 [inline]
>> BUG: KASAN: slab-out-of-bounds in __hlist_del include/linux/list.h:702
>> [inline]
>> BUG: KASAN: slab-out-of-bounds in hlist_del_rcu include/linux/rculist.h:455
>> [inline]
>> BUG: KASAN: slab-out-of-bounds in __xfrm_policy_unlink+0x75f/0x810
>> net/xfrm/xfrm_policy.c:1241
>> Write of size 8 at addr ffff8801b979db48 by task blkid/15614
>>
>> CPU: 1 PID: 15614 Comm: blkid Not tainted 4.20.0-rc1+ #287
>> kernel msg: ebtables bug: please report to author: Nentries wrong
>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>> Google 01/01/2011
>> Call Trace:
>> <IRQ>
>> __dump_stack lib/dump_stack.c:77 [inline]
>> dump_stack+0x244/0x39d lib/dump_stack.c:113
>> print_address_description.cold.7+0x9/0x1ff mm/kasan/report.c:256
>> kasan_report_error mm/kasan/report.c:354 [inline]
>> kasan_report.cold.8+0x242/0x309 mm/kasan/report.c:412
>> __asan_report_store8_noabort+0x17/0x20 mm/kasan/report.c:438
>> __write_once_size include/linux/compiler.h:209 [inline]
>> __hlist_del include/linux/list.h:702 [inline]
>> hlist_del_rcu include/linux/rculist.h:455 [inline]
>> __xfrm_policy_unlink+0x75f/0x810 net/xfrm/xfrm_policy.c:1241
>> xfrm_policy_delete+0x49/0x90 net/xfrm/xfrm_policy.c:1266
>> xfrm_policy_timer+0x46f/0x660 net/xfrm/xfrm_policy.c:254
>> call_timer_fn+0x272/0x920 kernel/time/timer.c:1326
>> expire_timers kernel/time/timer.c:1363 [inline]
>> __run_timers+0x7e5/0xc70 kernel/time/timer.c:1682
>> run_timer_softirq+0x52/0xb0 kernel/time/timer.c:1695
>> __do_softirq+0x308/0xb7e kernel/softirq.c:292
>> invoke_softirq kernel/softirq.c:373 [inline]
>> irq_exit+0x17f/0x1c0 kernel/softirq.c:413
>> exiting_irq arch/x86/include/asm/apic.h:536 [inline]
>> smp_apic_timer_interrupt+0x1cb/0x760 arch/x86/kernel/apic/apic.c:1061
>> apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:804
>> </IRQ>
>> RIP: 0010:arch_local_irq_restore arch/x86/include/asm/paravirt.h:761
>> [inline]
>> RIP: 0010:count_memcg_events include/linux/memcontrol.h:742 [inline]
>> RIP: 0010:count_memcg_event_mm include/linux/memcontrol.h:763 [inline]
>> RIP: 0010:handle_mm_fault+0x9a8/0xc70 mm/memory.c:3906
>> Code: df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 4e 02 00 00 48 83 3d 78 5b
>> 9e 07 00 0f 84 70 01 00 00 e8 7d ea cb ff 4c 89 ff 57 9d <0f> 1f 44 00 00 e9
>> 22 fa ff ff e8 69 ea cb ff 49 8d bd 20 04 00 00
>> RSP: 0000:ffff8801bbcffcc8 EFLAGS: 00000293 ORIG_RAX: ffffffffffffff13
>> RAX: ffff8801bc1ae540 RBX: ffff8801c6f5dca0 RCX: 1ffff10037835dbc
>> RDX: 0000000000000000 RSI: ffffffff81b3a043 RDI: 0000000000000293
>> RBP: ffff8801bbcffd68 R08: ffff8801bc1aede0 R09: 0000000000000007
>> R10: 0000000000000000 R11: ffff8801bc1ae540 R12: 1ffff1003779ff9c
>> R13: 0000000000000200 R14: 0000000000000054 R15: 0000000000000293
>> do_user_addr_fault arch/x86/mm/fault.c:1423 [inline]
>> __do_page_fault+0x5e8/0xe60 arch/x86/mm/fault.c:1489
>> do_page_fault+0xf2/0x7e0 arch/x86/mm/fault.c:1520
>> page_fault+0x1e/0x30 arch/x86/entry/entry_64.S:1139
>> RIP: 0033:0x7f05c5e50d61
>> Code: 00 c3 f7 05 9d c4 30 00 04 00 00 00 74 07 48 8d 05 84 95 0b 00 c3 0f
>> 1f 00 48 31 c0 89 f9 83 e1 3f 66 0f ef c0 83 f9 30 77 19 <f3> 0f 6f 0f 66 0f
>> 74 c1 66 0f d7 d0 85 d2 75 7a 48 89 f8 48 83 e0
>> RSP: 002b:00007ffc5d3e2558 EFLAGS: 00010287
>> RAX: 0000000000000000 RBX: 00007f05c638487c RCX: 0000000000000020
>> RDX: 0000000000000005 RSI: 00007ffc5d3e2d48 RDI: 00007f05c6179a20
>> RBP: 00007ffc5d3e2f2b R08: 0000000000000008 R09: 0101010101010101
>> R10: 0000000000000000 R11: 00007f05c5e07060 R12: 0000000000403738
>> R13: 0000000000000001 R14: 0000000000000000 R15: 00007f05c6179a20
>>
>> Allocated by task 7136:
>> save_stack+0x43/0xd0 mm/kasan/kasan.c:448
>> set_track mm/kasan/kasan.c:460 [inline]
>> kasan_kmalloc+0xc7/0xe0 mm/kasan/kasan.c:553
>> kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:490
>> kmem_cache_alloc+0x12e/0x730 mm/slab.c:3554
>> mempool_alloc_slab+0x44/0x60 mm/mempool.c:505
>> mempool_alloc+0x193/0x4a0 mm/mempool.c:385
>> bvec_alloc+0x12a/0x2d0 block/bio.c:218
>> bio_alloc_bioset+0x47a/0x700 block/bio.c:509
>> bio_alloc include/linux/bio.h:393 [inline]
>> io_submit_init_bio fs/ext4/page-io.c:374 [inline]
>> io_submit_add_bh fs/ext4/page-io.c:399 [inline]
>> ext4_bio_write_page+0x1304/0x1bd1 fs/ext4/page-io.c:506
>> mpage_submit_page+0x15e/0x270 fs/ext4/inode.c:2237
>> mpage_process_page_bufs+0x50a/0x600 fs/ext4/inode.c:2348
>> mpage_prepare_extent_to_map+0xea5/0x19c0 fs/ext4/inode.c:2710
>> ext4_writepages+0x140c/0x41a0 fs/ext4/inode.c:2837
>> do_writepages+0x9a/0x1a0 mm/page-writeback.c:2328
>> __writeback_single_inode+0x20a/0x1660 fs/fs-writeback.c:1316
>> writeback_sb_inodes+0x71f/0x1210 fs/fs-writeback.c:1580
>> __writeback_inodes_wb+0x1b9/0x340 fs/fs-writeback.c:1649
>> wb_writeback+0xa73/0xfc0 fs/fs-writeback.c:1758
>> wb_check_start_all fs/fs-writeback.c:1882 [inline]
>> wb_do_writeback fs/fs-writeback.c:1908 [inline]
>> wb_workfn+0xee9/0x1790 fs/fs-writeback.c:1942
>> process_one_work+0xc90/0x1c40 kernel/workqueue.c:2153
>> worker_thread+0x17f/0x1390 kernel/workqueue.c:2296
>> kthread+0x35a/0x440 kernel/kthread.c:246
>> ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
>>
>> Freed by task 5729:
>> save_stack+0x43/0xd0 mm/kasan/kasan.c:448
>> set_track mm/kasan/kasan.c:460 [inline]
>> __kasan_slab_free+0x102/0x150 mm/kasan/kasan.c:521
>> kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
>> __cache_free mm/slab.c:3498 [inline]
>> kmem_cache_free+0x83/0x290 mm/slab.c:3760
>> mempool_free_slab+0x1d/0x30 mm/mempool.c:512
>> mempool_free+0xed/0x370 mm/mempool.c:494
>> bvec_free+0xa8/0xd0 block/bio.c:173
>> bio_free+0xc1/0x150 block/bio.c:259
>> bio_put+0x187/0x200 block/bio.c:561
>> ext4_end_bio+0x197/0x6e0 fs/ext4/page-io.c:343
>> bio_endio+0x5d2/0xb80 block/bio.c:1773
>> req_bio_endio block/blk-core.c:278 [inline]
>> blk_update_request+0x585/0xd20 block/blk-core.c:3076
>> scsi_end_request+0xde/0x860 drivers/scsi/scsi_lib.c:673
>> scsi_io_completion+0x2ce/0x1ca0 drivers/scsi/scsi_lib.c:1093
>> scsi_finish_command+0x579/0x970 drivers/scsi/scsi.c:248
>> scsi_softirq_done+0x465/0x520 drivers/scsi/scsi_lib.c:1737
>> blk_done_softirq+0x4c2/0x760 block/blk-softirq.c:37
>> __do_softirq+0x308/0xb7e kernel/softirq.c:292
>>
>> The buggy address belongs to the object at ffff8801b979ddc0
>> which belongs to the cache biovec-max of size 8192
>> The buggy address is located 632 bytes to the left of
>> 8192-byte region [ffff8801b979ddc0, ffff8801b979fdc0)
>> The buggy address belongs to the page:
>> page:ffffea0006e5e700 count:1 mapcount:0 mapping:ffff8801d79b6980 index:0x0
>> compound_mapcount: 0
>> flags: 0x2fffc0000010200(slab|head)
>> raw: 02fffc0000010200 ffffea000730ee08 ffffea000652d508 ffff8801d79b6980
>> raw: 0000000000000000 ffff8801b979ddc0 0000000100000001 0000000000000000
>> page dumped because: kasan: bad access detected
>>
>> Memory state around the buggy address:
>> ffff8801b979da00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>> ffff8801b979da80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>>>
>>> ffff8801b979db00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>>
>> ^
>> ffff8801b979db80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>> ffff8801b979dc00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>> ==================================================================
>>
>>
>> ---
>> This bug is generated by a bot. It may contain errors.
>> See https://goo.gl/tpsmEJ for more information about syzbot.
>> syzbot engineers can be reached at syzkaller@googlegroups.com.
>>
>> syzbot will keep track of this bug report. See:
>> https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
>> syzbot.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "syzkaller-bugs" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to syzkaller-bugs+unsubscribe@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/syzkaller-bugs/000000000000e5a3e1057a59db17%40google.com.
>> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: KASAN: slab-out-of-bounds Write in __xfrm_policy_unlink
From: Dmitry Vyukov @ 2018-11-11 1:55 UTC (permalink / raw)
To: syzbot
Cc: David Miller, Herbert Xu, LKML, netdev, Steffen Klassert,
syzkaller-bugs
In-Reply-To: <000000000000e5a3e1057a59db17@google.com>
On Sat, Nov 10, 2018 at 5:54 PM, syzbot
<syzbot+1a5442803e5354a25766@syzkaller.appspotmail.com> wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 29e12207174a sfc: use the new __netdev_tx_sent_queue BQL o..
> git tree: net-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=133c2c5d400000
> kernel config: https://syzkaller.appspot.com/x/.config?x=8f559fee2fc3375a
> dashboard link: https://syzkaller.appspot.com/bug?extid=1a5442803e5354a25766
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>
> Unfortunately, I don't have any reproducer for this crash yet.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+1a5442803e5354a25766@syzkaller.appspotmail.com
May be related to "KASAN: slab-out-of-bounds Write in __xfrm_policy_unlink"
https://syzkaller.appspot.com/bug?extid=aa77660edbf949365033
> ==================================================================
> BUG: KASAN: slab-out-of-bounds in __write_once_size
> include/linux/compiler.h:209 [inline]
> BUG: KASAN: slab-out-of-bounds in __hlist_del include/linux/list.h:702
> [inline]
> BUG: KASAN: slab-out-of-bounds in hlist_del_rcu include/linux/rculist.h:455
> [inline]
> BUG: KASAN: slab-out-of-bounds in __xfrm_policy_unlink+0x75f/0x810
> net/xfrm/xfrm_policy.c:1241
> Write of size 8 at addr ffff8801b979db48 by task blkid/15614
>
> CPU: 1 PID: 15614 Comm: blkid Not tainted 4.20.0-rc1+ #287
> kernel msg: ebtables bug: please report to author: Nentries wrong
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> <IRQ>
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x244/0x39d lib/dump_stack.c:113
> print_address_description.cold.7+0x9/0x1ff mm/kasan/report.c:256
> kasan_report_error mm/kasan/report.c:354 [inline]
> kasan_report.cold.8+0x242/0x309 mm/kasan/report.c:412
> __asan_report_store8_noabort+0x17/0x20 mm/kasan/report.c:438
> __write_once_size include/linux/compiler.h:209 [inline]
> __hlist_del include/linux/list.h:702 [inline]
> hlist_del_rcu include/linux/rculist.h:455 [inline]
> __xfrm_policy_unlink+0x75f/0x810 net/xfrm/xfrm_policy.c:1241
> xfrm_policy_delete+0x49/0x90 net/xfrm/xfrm_policy.c:1266
> xfrm_policy_timer+0x46f/0x660 net/xfrm/xfrm_policy.c:254
> call_timer_fn+0x272/0x920 kernel/time/timer.c:1326
> expire_timers kernel/time/timer.c:1363 [inline]
> __run_timers+0x7e5/0xc70 kernel/time/timer.c:1682
> run_timer_softirq+0x52/0xb0 kernel/time/timer.c:1695
> __do_softirq+0x308/0xb7e kernel/softirq.c:292
> invoke_softirq kernel/softirq.c:373 [inline]
> irq_exit+0x17f/0x1c0 kernel/softirq.c:413
> exiting_irq arch/x86/include/asm/apic.h:536 [inline]
> smp_apic_timer_interrupt+0x1cb/0x760 arch/x86/kernel/apic/apic.c:1061
> apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:804
> </IRQ>
> RIP: 0010:arch_local_irq_restore arch/x86/include/asm/paravirt.h:761
> [inline]
> RIP: 0010:count_memcg_events include/linux/memcontrol.h:742 [inline]
> RIP: 0010:count_memcg_event_mm include/linux/memcontrol.h:763 [inline]
> RIP: 0010:handle_mm_fault+0x9a8/0xc70 mm/memory.c:3906
> Code: df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 4e 02 00 00 48 83 3d 78 5b
> 9e 07 00 0f 84 70 01 00 00 e8 7d ea cb ff 4c 89 ff 57 9d <0f> 1f 44 00 00 e9
> 22 fa ff ff e8 69 ea cb ff 49 8d bd 20 04 00 00
> RSP: 0000:ffff8801bbcffcc8 EFLAGS: 00000293 ORIG_RAX: ffffffffffffff13
> RAX: ffff8801bc1ae540 RBX: ffff8801c6f5dca0 RCX: 1ffff10037835dbc
> RDX: 0000000000000000 RSI: ffffffff81b3a043 RDI: 0000000000000293
> RBP: ffff8801bbcffd68 R08: ffff8801bc1aede0 R09: 0000000000000007
> R10: 0000000000000000 R11: ffff8801bc1ae540 R12: 1ffff1003779ff9c
> R13: 0000000000000200 R14: 0000000000000054 R15: 0000000000000293
> do_user_addr_fault arch/x86/mm/fault.c:1423 [inline]
> __do_page_fault+0x5e8/0xe60 arch/x86/mm/fault.c:1489
> do_page_fault+0xf2/0x7e0 arch/x86/mm/fault.c:1520
> page_fault+0x1e/0x30 arch/x86/entry/entry_64.S:1139
> RIP: 0033:0x7f05c5e50d61
> Code: 00 c3 f7 05 9d c4 30 00 04 00 00 00 74 07 48 8d 05 84 95 0b 00 c3 0f
> 1f 00 48 31 c0 89 f9 83 e1 3f 66 0f ef c0 83 f9 30 77 19 <f3> 0f 6f 0f 66 0f
> 74 c1 66 0f d7 d0 85 d2 75 7a 48 89 f8 48 83 e0
> RSP: 002b:00007ffc5d3e2558 EFLAGS: 00010287
> RAX: 0000000000000000 RBX: 00007f05c638487c RCX: 0000000000000020
> RDX: 0000000000000005 RSI: 00007ffc5d3e2d48 RDI: 00007f05c6179a20
> RBP: 00007ffc5d3e2f2b R08: 0000000000000008 R09: 0101010101010101
> R10: 0000000000000000 R11: 00007f05c5e07060 R12: 0000000000403738
> R13: 0000000000000001 R14: 0000000000000000 R15: 00007f05c6179a20
>
> Allocated by task 7136:
> save_stack+0x43/0xd0 mm/kasan/kasan.c:448
> set_track mm/kasan/kasan.c:460 [inline]
> kasan_kmalloc+0xc7/0xe0 mm/kasan/kasan.c:553
> kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:490
> kmem_cache_alloc+0x12e/0x730 mm/slab.c:3554
> mempool_alloc_slab+0x44/0x60 mm/mempool.c:505
> mempool_alloc+0x193/0x4a0 mm/mempool.c:385
> bvec_alloc+0x12a/0x2d0 block/bio.c:218
> bio_alloc_bioset+0x47a/0x700 block/bio.c:509
> bio_alloc include/linux/bio.h:393 [inline]
> io_submit_init_bio fs/ext4/page-io.c:374 [inline]
> io_submit_add_bh fs/ext4/page-io.c:399 [inline]
> ext4_bio_write_page+0x1304/0x1bd1 fs/ext4/page-io.c:506
> mpage_submit_page+0x15e/0x270 fs/ext4/inode.c:2237
> mpage_process_page_bufs+0x50a/0x600 fs/ext4/inode.c:2348
> mpage_prepare_extent_to_map+0xea5/0x19c0 fs/ext4/inode.c:2710
> ext4_writepages+0x140c/0x41a0 fs/ext4/inode.c:2837
> do_writepages+0x9a/0x1a0 mm/page-writeback.c:2328
> __writeback_single_inode+0x20a/0x1660 fs/fs-writeback.c:1316
> writeback_sb_inodes+0x71f/0x1210 fs/fs-writeback.c:1580
> __writeback_inodes_wb+0x1b9/0x340 fs/fs-writeback.c:1649
> wb_writeback+0xa73/0xfc0 fs/fs-writeback.c:1758
> wb_check_start_all fs/fs-writeback.c:1882 [inline]
> wb_do_writeback fs/fs-writeback.c:1908 [inline]
> wb_workfn+0xee9/0x1790 fs/fs-writeback.c:1942
> process_one_work+0xc90/0x1c40 kernel/workqueue.c:2153
> worker_thread+0x17f/0x1390 kernel/workqueue.c:2296
> kthread+0x35a/0x440 kernel/kthread.c:246
> ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
>
> Freed by task 5729:
> save_stack+0x43/0xd0 mm/kasan/kasan.c:448
> set_track mm/kasan/kasan.c:460 [inline]
> __kasan_slab_free+0x102/0x150 mm/kasan/kasan.c:521
> kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
> __cache_free mm/slab.c:3498 [inline]
> kmem_cache_free+0x83/0x290 mm/slab.c:3760
> mempool_free_slab+0x1d/0x30 mm/mempool.c:512
> mempool_free+0xed/0x370 mm/mempool.c:494
> bvec_free+0xa8/0xd0 block/bio.c:173
> bio_free+0xc1/0x150 block/bio.c:259
> bio_put+0x187/0x200 block/bio.c:561
> ext4_end_bio+0x197/0x6e0 fs/ext4/page-io.c:343
> bio_endio+0x5d2/0xb80 block/bio.c:1773
> req_bio_endio block/blk-core.c:278 [inline]
> blk_update_request+0x585/0xd20 block/blk-core.c:3076
> scsi_end_request+0xde/0x860 drivers/scsi/scsi_lib.c:673
> scsi_io_completion+0x2ce/0x1ca0 drivers/scsi/scsi_lib.c:1093
> scsi_finish_command+0x579/0x970 drivers/scsi/scsi.c:248
> scsi_softirq_done+0x465/0x520 drivers/scsi/scsi_lib.c:1737
> blk_done_softirq+0x4c2/0x760 block/blk-softirq.c:37
> __do_softirq+0x308/0xb7e kernel/softirq.c:292
>
> The buggy address belongs to the object at ffff8801b979ddc0
> which belongs to the cache biovec-max of size 8192
> The buggy address is located 632 bytes to the left of
> 8192-byte region [ffff8801b979ddc0, ffff8801b979fdc0)
> The buggy address belongs to the page:
> page:ffffea0006e5e700 count:1 mapcount:0 mapping:ffff8801d79b6980 index:0x0
> compound_mapcount: 0
> flags: 0x2fffc0000010200(slab|head)
> raw: 02fffc0000010200 ffffea000730ee08 ffffea000652d508 ffff8801d79b6980
> raw: 0000000000000000 ffff8801b979ddc0 0000000100000001 0000000000000000
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
> ffff8801b979da00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ffff8801b979da80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>>
>> ffff8801b979db00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>
> ^
> ffff8801b979db80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ffff8801b979dc00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ==================================================================
>
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
>
> syzbot will keep track of this bug report. See:
> https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
> syzbot.
>
> --
> You received this message because you are subscribed to the Google Groups
> "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to syzkaller-bugs+unsubscribe@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/syzkaller-bugs/000000000000e5a3e1057a59db17%40google.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* KASAN: slab-out-of-bounds Write in __xfrm_policy_unlink
From: syzbot @ 2018-11-11 1:54 UTC (permalink / raw)
To: davem, herbert, linux-kernel, netdev, steffen.klassert,
syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 29e12207174a sfc: use the new __netdev_tx_sent_queue BQL o..
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=133c2c5d400000
kernel config: https://syzkaller.appspot.com/x/.config?x=8f559fee2fc3375a
dashboard link: https://syzkaller.appspot.com/bug?extid=1a5442803e5354a25766
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+1a5442803e5354a25766@syzkaller.appspotmail.com
==================================================================
BUG: KASAN: slab-out-of-bounds in __write_once_size
include/linux/compiler.h:209 [inline]
BUG: KASAN: slab-out-of-bounds in __hlist_del include/linux/list.h:702
[inline]
BUG: KASAN: slab-out-of-bounds in hlist_del_rcu include/linux/rculist.h:455
[inline]
BUG: KASAN: slab-out-of-bounds in __xfrm_policy_unlink+0x75f/0x810
net/xfrm/xfrm_policy.c:1241
Write of size 8 at addr ffff8801b979db48 by task blkid/15614
CPU: 1 PID: 15614 Comm: blkid Not tainted 4.20.0-rc1+ #287
kernel msg: ebtables bug: please report to author: Nentries wrong
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x244/0x39d lib/dump_stack.c:113
print_address_description.cold.7+0x9/0x1ff mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report.cold.8+0x242/0x309 mm/kasan/report.c:412
__asan_report_store8_noabort+0x17/0x20 mm/kasan/report.c:438
__write_once_size include/linux/compiler.h:209 [inline]
__hlist_del include/linux/list.h:702 [inline]
hlist_del_rcu include/linux/rculist.h:455 [inline]
__xfrm_policy_unlink+0x75f/0x810 net/xfrm/xfrm_policy.c:1241
xfrm_policy_delete+0x49/0x90 net/xfrm/xfrm_policy.c:1266
xfrm_policy_timer+0x46f/0x660 net/xfrm/xfrm_policy.c:254
call_timer_fn+0x272/0x920 kernel/time/timer.c:1326
expire_timers kernel/time/timer.c:1363 [inline]
__run_timers+0x7e5/0xc70 kernel/time/timer.c:1682
run_timer_softirq+0x52/0xb0 kernel/time/timer.c:1695
__do_softirq+0x308/0xb7e kernel/softirq.c:292
invoke_softirq kernel/softirq.c:373 [inline]
irq_exit+0x17f/0x1c0 kernel/softirq.c:413
exiting_irq arch/x86/include/asm/apic.h:536 [inline]
smp_apic_timer_interrupt+0x1cb/0x760 arch/x86/kernel/apic/apic.c:1061
apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:804
</IRQ>
RIP: 0010:arch_local_irq_restore arch/x86/include/asm/paravirt.h:761
[inline]
RIP: 0010:count_memcg_events include/linux/memcontrol.h:742 [inline]
RIP: 0010:count_memcg_event_mm include/linux/memcontrol.h:763 [inline]
RIP: 0010:handle_mm_fault+0x9a8/0xc70 mm/memory.c:3906
Code: df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 4e 02 00 00 48 83 3d 78 5b
9e 07 00 0f 84 70 01 00 00 e8 7d ea cb ff 4c 89 ff 57 9d <0f> 1f 44 00 00
e9 22 fa ff ff e8 69 ea cb ff 49 8d bd 20 04 00 00
RSP: 0000:ffff8801bbcffcc8 EFLAGS: 00000293 ORIG_RAX: ffffffffffffff13
RAX: ffff8801bc1ae540 RBX: ffff8801c6f5dca0 RCX: 1ffff10037835dbc
RDX: 0000000000000000 RSI: ffffffff81b3a043 RDI: 0000000000000293
RBP: ffff8801bbcffd68 R08: ffff8801bc1aede0 R09: 0000000000000007
R10: 0000000000000000 R11: ffff8801bc1ae540 R12: 1ffff1003779ff9c
R13: 0000000000000200 R14: 0000000000000054 R15: 0000000000000293
do_user_addr_fault arch/x86/mm/fault.c:1423 [inline]
__do_page_fault+0x5e8/0xe60 arch/x86/mm/fault.c:1489
do_page_fault+0xf2/0x7e0 arch/x86/mm/fault.c:1520
page_fault+0x1e/0x30 arch/x86/entry/entry_64.S:1139
RIP: 0033:0x7f05c5e50d61
Code: 00 c3 f7 05 9d c4 30 00 04 00 00 00 74 07 48 8d 05 84 95 0b 00 c3 0f
1f 00 48 31 c0 89 f9 83 e1 3f 66 0f ef c0 83 f9 30 77 19 <f3> 0f 6f 0f 66
0f 74 c1 66 0f d7 d0 85 d2 75 7a 48 89 f8 48 83 e0
RSP: 002b:00007ffc5d3e2558 EFLAGS: 00010287
RAX: 0000000000000000 RBX: 00007f05c638487c RCX: 0000000000000020
RDX: 0000000000000005 RSI: 00007ffc5d3e2d48 RDI: 00007f05c6179a20
RBP: 00007ffc5d3e2f2b R08: 0000000000000008 R09: 0101010101010101
R10: 0000000000000000 R11: 00007f05c5e07060 R12: 0000000000403738
R13: 0000000000000001 R14: 0000000000000000 R15: 00007f05c6179a20
Allocated by task 7136:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
kasan_kmalloc+0xc7/0xe0 mm/kasan/kasan.c:553
kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:490
kmem_cache_alloc+0x12e/0x730 mm/slab.c:3554
mempool_alloc_slab+0x44/0x60 mm/mempool.c:505
mempool_alloc+0x193/0x4a0 mm/mempool.c:385
bvec_alloc+0x12a/0x2d0 block/bio.c:218
bio_alloc_bioset+0x47a/0x700 block/bio.c:509
bio_alloc include/linux/bio.h:393 [inline]
io_submit_init_bio fs/ext4/page-io.c:374 [inline]
io_submit_add_bh fs/ext4/page-io.c:399 [inline]
ext4_bio_write_page+0x1304/0x1bd1 fs/ext4/page-io.c:506
mpage_submit_page+0x15e/0x270 fs/ext4/inode.c:2237
mpage_process_page_bufs+0x50a/0x600 fs/ext4/inode.c:2348
mpage_prepare_extent_to_map+0xea5/0x19c0 fs/ext4/inode.c:2710
ext4_writepages+0x140c/0x41a0 fs/ext4/inode.c:2837
do_writepages+0x9a/0x1a0 mm/page-writeback.c:2328
__writeback_single_inode+0x20a/0x1660 fs/fs-writeback.c:1316
writeback_sb_inodes+0x71f/0x1210 fs/fs-writeback.c:1580
__writeback_inodes_wb+0x1b9/0x340 fs/fs-writeback.c:1649
wb_writeback+0xa73/0xfc0 fs/fs-writeback.c:1758
wb_check_start_all fs/fs-writeback.c:1882 [inline]
wb_do_writeback fs/fs-writeback.c:1908 [inline]
wb_workfn+0xee9/0x1790 fs/fs-writeback.c:1942
process_one_work+0xc90/0x1c40 kernel/workqueue.c:2153
worker_thread+0x17f/0x1390 kernel/workqueue.c:2296
kthread+0x35a/0x440 kernel/kthread.c:246
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
Freed by task 5729:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
__kasan_slab_free+0x102/0x150 mm/kasan/kasan.c:521
kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
__cache_free mm/slab.c:3498 [inline]
kmem_cache_free+0x83/0x290 mm/slab.c:3760
mempool_free_slab+0x1d/0x30 mm/mempool.c:512
mempool_free+0xed/0x370 mm/mempool.c:494
bvec_free+0xa8/0xd0 block/bio.c:173
bio_free+0xc1/0x150 block/bio.c:259
bio_put+0x187/0x200 block/bio.c:561
ext4_end_bio+0x197/0x6e0 fs/ext4/page-io.c:343
bio_endio+0x5d2/0xb80 block/bio.c:1773
req_bio_endio block/blk-core.c:278 [inline]
blk_update_request+0x585/0xd20 block/blk-core.c:3076
scsi_end_request+0xde/0x860 drivers/scsi/scsi_lib.c:673
scsi_io_completion+0x2ce/0x1ca0 drivers/scsi/scsi_lib.c:1093
scsi_finish_command+0x579/0x970 drivers/scsi/scsi.c:248
scsi_softirq_done+0x465/0x520 drivers/scsi/scsi_lib.c:1737
blk_done_softirq+0x4c2/0x760 block/blk-softirq.c:37
__do_softirq+0x308/0xb7e kernel/softirq.c:292
The buggy address belongs to the object at ffff8801b979ddc0
which belongs to the cache biovec-max of size 8192
The buggy address is located 632 bytes to the left of
8192-byte region [ffff8801b979ddc0, ffff8801b979fdc0)
The buggy address belongs to the page:
page:ffffea0006e5e700 count:1 mapcount:0 mapping:ffff8801d79b6980 index:0x0
compound_mapcount: 0
flags: 0x2fffc0000010200(slab|head)
raw: 02fffc0000010200 ffffea000730ee08 ffffea000652d508 ffff8801d79b6980
raw: 0000000000000000 ffff8801b979ddc0 0000000100000001 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8801b979da00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff8801b979da80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ffff8801b979db00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
^
ffff8801b979db80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff8801b979dc00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
^ permalink raw reply
* Re: [RFC PATCH 01/12] dt-bindings: soc: qcom: add IPA bindings
From: Rob Herring @ 2018-11-11 1:40 UTC (permalink / raw)
To: Alex Elder
Cc: Mark Rutland, David Miller, Arnd Bergmann, Bjorn Andersson,
ilias.apalodimas, netdev, devicetree, linux-arm-msm,
open list:ARM/QUALCOMM SUPPORT,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
linux-kernel@vger.kernel.org, syadagir, mjavid
In-Reply-To: <a4c9f0f8-d7c7-2756-cfdf-b67ce9f1ca3b@linaro.org>
On Fri, Nov 9, 2018 at 4:38 PM Alex Elder <elder@linaro.org> wrote:
>
> On 11/7/18 8:59 AM, Rob Herring wrote:
> > On Tue, Nov 6, 2018 at 6:33 PM Alex Elder <elder@linaro.org> wrote:
> >>
> >> Add the binding definitions for the "qcom,ipa" and "qcom,rmnet-ipa"
> >> device tree nodes.
> >>
> >> Signed-off-by: Alex Elder <elder@linaro.org>
> >> ---
> >> .../devicetree/bindings/soc/qcom/qcom,ipa.txt | 136 ++++++++++++++++++
> >> .../bindings/soc/qcom/qcom,rmnet-ipa.txt | 15 ++
> >> 2 files changed, 151 insertions(+)
> >> create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,ipa.txt
> >> create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,rmnet-ipa.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,ipa.txt b/Documentation/devicetree/bindings/soc/qcom/qcom,ipa.txt
> >> new file mode 100644
> >> index 000000000000..d4d3d37df029
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,ipa.txt
> >> @@ -0,0 +1,136 @@
> >> +Qualcomm IPA (IP Accelerator) Driver
> >
> > Bindings are for h/w not drivers.
>
> OK. I'll drop " Driver".
>
> >> +
> >> +This binding describes the Qualcomm IPA. The IPA is capable of offloading
> >> +certain network processing tasks (e.g. filtering, routing, and NAT) from
> >> +the main processor. The IPA currently serves only as a network interface,
> >> +providing access to an LTE network available via a modem.
> >> +
> >> +The IPA sits between multiple independent "execution environments,"
> >> +including the AP subsystem (APSS) and the modem. The IPA presents
> >> +a Generic Software Interface (GSI) to each execution environment.
> >> +The GSI is an integral part of the IPA, but it is logically isolated
> >> +and has a distinct interrupt and a separately-defined address space.
> >> +
> >> + ---------- ------------- ---------
> >> + | | |G| |G| | |
> >> + | APSS |===|S| IPA |S|===| Modem |
> >> + | | |I| |I| | |
> >> + ---------- ------------- ---------
> >> +
> >> +See also:
> >> + bindings/interrupt-controller/interrupts.txt
> >> + bindings/interconnect/interconnect.txt
> >> + bindings/soc/qcom/qcom,smp2p.txt
> >> + bindings/reserved-memory/reserved-memory.txt
> >> + bindings/clock/clock-bindings.txt
> >> +
> >> +All properties defined below are required.
> >> +
> >> +- compatible:
> >> + Must be one of the following compatible strings:
> >> + "qcom,ipa-sdm845-modem_init"
> >> + "qcom,ipa-sdm845-tz_init"
> >
> > Normal order is <vendor>,<soc>-<ipblock>."
>
> I'll use "qcom,sdm845-ipa-modem-init" and "qcom,sdm845-ipa-tz-init".
> (Or just "qcom,sdm845-ipa", depending on the outcome of the discussion
> below.)
>
> > Don't use '_'.
>
> OK.
>
> > What's the difference between these 2? It can't be detected somehow?
>
> There is some early initialization, including loading some firmware,
> that must be done by trusted code. That can be done by either Trust
> Zone or the modem. If it's done by the modem, there is an additional
> step required during initialization so the modem can tell the AP
> that it has done its part, and the AP can finish IPA initialization.
>
> There is no way of detecting (e.g. by probing hardware) which is
> in effect so we use DT. I discussed this with Bjorn, who said that
> this was a situation seen elsewhere and that using compatible strings
> was the way he suggested to address it.
Okay. However, if this is common for QCom blocks maybe we should
reconsider. I think compatible makes sense if the programming model
changes.
> > This might be better expressed as a property. Then if Trustzone
> > initializes things, it can just add a property.
>
> A Boolean property to distinguish them would be fine as well, but
> I would like to address this "common" problem consistently.
>
> Bjorn, would you please weigh in?
>
> >> +
> >> +-reg:
> >> + Resources specyfing the physical address spaces of the IPA and GSI.
> >
> > typo
> >
> >> +
> >> +-reg-names:
> >> + The names of the address space ranges defined by the "reg" property.
> >> + Must be "ipa" and "gsi".
> >> +
> >> +- interrupts-extended:
> >
> > Use 'interrupts' here and describe what they are and the order. What
> > they are connected to (and the need for interrupts-extended) is
> > outside the scope of this binding.
>
> I used interrupts-extended because there were two interrupt parents
> (a "normal" interrupt controller and the interrupt controller implemented
> for SMP2P input). A paragraph here:
> bindings/interrupt-controller/interrupts.txt
> recommends "interrupts-extended" in that case.
>
> I have no objection to using just "interrupts" but can you tell me what
> I misunderstood? It seems like I need to do "interrupts-extended".
Yes, in the dts you should use interrupts-extended. However, for
documentation purposes that aspect is not important. So we just use
interrupts most everywhere.
Rob
^ permalink raw reply
* Re: [PATCH mlx5-next 08/10] IB/mlx5: Call PAGE_FAULT_RESUME command asynchronously
From: Leon Romanovsky @ 2018-11-10 15:47 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Doug Ledford, RDMA mailing list, Artemy Kovalyov, Majd Dibbiny,
Moni Shoua, Saeed Mahameed, linux-netdev
In-Reply-To: <20181109165953.GC22987@ziepe.ca>
[-- Attachment #1: Type: text/plain, Size: 3602 bytes --]
On Fri, Nov 09, 2018 at 09:59:53AM -0700, Jason Gunthorpe wrote:
> On Fri, Nov 09, 2018 at 06:26:22PM +0200, Leon Romanovsky wrote:
> > On Thu, Nov 08, 2018 at 07:49:03PM +0000, Jason Gunthorpe wrote:
> > > On Thu, Nov 08, 2018 at 09:10:15PM +0200, Leon Romanovsky wrote:
> > > > From: Moni Shoua <monis@mellanox.com>
> > > >
> > > > Telling the HCA that page fault handling is done and QP can resume
> > > > its flow is done in the context of the page fault handler. This blocks
> > > > the handling of the next work in queue without a need.
> > > > Call the PAGE_FAULT_RESUME command in an asynchronous manner and free
> > > > the workqueue to pick the next work item for handling. All tasks that
> > > > were executed after PAGE_FAULT_RESUME need to be done now
> > > > in the callback of the asynchronous command mechanism.
> > > >
> > > > Signed-off-by: Moni Shoua <monis@mellanox.com>
> > > > Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
> > > > drivers/infiniband/hw/mlx5/odp.c | 110 +++++++++++++++++++++++++------
> > > > include/linux/mlx5/driver.h | 3 +
> > > > 2 files changed, 94 insertions(+), 19 deletions(-)
> > > >
> > > > diff --git a/drivers/infiniband/hw/mlx5/odp.c b/drivers/infiniband/hw/mlx5/odp.c
> > > > index abce55b8b9ba..0c4f469cdd5b 100644
> > > > +++ b/drivers/infiniband/hw/mlx5/odp.c
> > > > @@ -298,20 +298,78 @@ void mlx5_ib_internal_fill_odp_caps(struct mlx5_ib_dev *dev)
> > > > return;
> > > > }
> > > >
> > > > +struct pfault_resume_cb_ctx {
> > > > + struct mlx5_ib_dev *dev;
> > > > + struct mlx5_core_rsc_common *res;
> > > > + struct mlx5_pagefault *pfault;
> > > > +};
> > > > +
> > > > +static void page_fault_resume_callback(int status, void *context)
> > > > +{
> > > > + struct pfault_resume_cb_ctx *ctx = context;
> > > > + struct mlx5_pagefault *pfault = ctx->pfault;
> > > > +
> > > > + if (status)
> > > > + mlx5_ib_err(ctx->dev, "Resolve the page fault failed with status %d\n",
> > > > + status);
> > > > +
> > > > + if (ctx->res)
> > > > + mlx5_core_res_put(ctx->res);
> > > > + kfree(pfault);
> > > > + kfree(ctx);
> > > > +}
> > > > +
> > > > static void mlx5_ib_page_fault_resume(struct mlx5_ib_dev *dev,
> > > > + struct mlx5_core_rsc_common *res,
> > > > struct mlx5_pagefault *pfault,
> > > > - int error)
> > > > + int error,
> > > > + bool async)
> > > > {
> > > > + int ret = 0;
> > > > + u32 *out = pfault->out_pf_resume;
> > > > + u32 *in = pfault->in_pf_resume;
> > > > + u32 token = pfault->token;
> > > > int wq_num = pfault->event_subtype == MLX5_PFAULT_SUBTYPE_WQE ?
> > > > - pfault->wqe.wq_num : pfault->token;
> > > > - int ret = mlx5_core_page_fault_resume(dev->mdev,
> > > > - pfault->token,
> > > > - wq_num,
> > > > - pfault->type,
> > > > - error);
> > > > - if (ret)
> > > > - mlx5_ib_err(dev, "Failed to resolve the page fault on WQ 0x%x\n",
> > > > - wq_num);
> > > > + pfault->wqe.wq_num : pfault->token;
> > > > + u8 type = pfault->type;
> > > > + struct pfault_resume_cb_ctx *ctx = NULL;
> > > > +
> > > > + if (async)
> > > > + ctx = kmalloc(sizeof(*ctx), GFP_KERNEL);
> > >
> > > Why not allocate this ctx ast part of the mlx5_pagefault and avoid
> > > this allocation failure strategy?
> >
> > It is another way to implement it, both of them are correct.
>
> .. I think it is alot better to move this allocation, it gets rid of
> this ugly duplicated code
>
> > Can I assume that we can progress with patches except patch #2?
>
> Lets drop this one too..
Sure, thanks
>
> Jason
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: Kernel 4.19 network performance - forwarding/routing normal users traffic
From: David Ahern @ 2018-11-10 14:56 UTC (permalink / raw)
To: Paweł Staszewski, Jesper Dangaard Brouer; +Cc: netdev, Yoel Caspersen
In-Reply-To: <602b9904-b374-c9a7-abf6-2444d02d1bc0@itcare.pl>
On 11/10/18 6:18 AM, Paweł Staszewski wrote:
>
> ./xdp_fwd enp175s0f0 enp175s0f1
> libbpf: failed to create map (name: 'stats_map'): Operation not permitted
> libbpf: failed to load object './xdp_fwd_kern.o'
Forgot I had increased locked memory:
ulimit -l unlimited
./xdp_fwd enp175s0f0 enp175s0f1
^ permalink raw reply
* Re: Kernel 4.19 network performance - forwarding/routing normal users traffic
From: Paweł Staszewski @ 2018-11-10 13:18 UTC (permalink / raw)
To: David Ahern, Jesper Dangaard Brouer; +Cc: netdev, Yoel Caspersen
In-Reply-To: <d3631119-a5fc-b11d-fbad-9a57eeb80f7f@gmail.com>
W dniu 10.11.2018 o 01:06, David Ahern pisze:
> On 11/9/18 9:21 AM, David Ahern wrote:
>>> Is there possible to add only counters from xdp for vlans ?
>>> This will help me in testing.
>> I will take a look today at adding counters that you can dump using
>> bpftool. It will be a temporary solution for this xdp program only.
>>
> Same tree, kernel-tables-wip-02 branch. Compile kernel and install.
> Compile samples as before.
>
> If you give the userspace program a -t arg, it loop showing stats.
> Ctrl-C to break. The xdp programs are not detached on exit.
>
> Example:
>
> ./xdp_fwd -t 5 eth1 eth2 eth3 eth4
>
> 15:59:32: rx tx dropped skipped l3_dev fib_dev
> index 3: 901158 901158 0 18 0 0
> index 4: 901159 901158 0 20 0 901139
> index 10: 0 0 0 0 19 19
> index 11: 0 0 0 0 901139 901139
> index 15: 0 0 0 0 19 19
> index 16: 0 0 0 0 901139 0
>
> Rx and Tx counters are for the physical port.
>
> VLANs show up as l3_dev (ingress) and fib_dev (egress).
>
> dropped is anytime the xdp program returns XDP_DROP (e.g., invalid packet)
>
> skipped is anytime the program returns XDP_PASS (e.g., not ipv4 or ipv6,
> local traffic, or needs full stack assist).
>
recompiled new version but:
./xdp_fwd enp175s0f0 enp175s0f1
libbpf: failed to create map (name: 'stats_map'): Operation not permitted
libbpf: failed to load object './xdp_fwd_kern.o'
^ permalink raw reply
* [PATCH iproute2] testsuite: ss: Fix spacing in expected output for ssfilter.t
From: Stefano Brivio @ 2018-11-10 9:21 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Phil Sutter, Yoann P., netdev
Since commit 00240899ec0b ("ss: Actually print left delimiter for
columns") changes spacing in ss output, we also need to adjust for that in
the ss filter test.
Fixes: 00240899ec0b ("ss: Actually print left delimiter for columns")
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
---
testsuite/tests/ss/ssfilter.t | 24 ++++++++++++------------
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/testsuite/tests/ss/ssfilter.t b/testsuite/tests/ss/ssfilter.t
index e74f1765cb72..3091054f2892 100755
--- a/testsuite/tests/ss/ssfilter.t
+++ b/testsuite/tests/ss/ssfilter.t
@@ -12,37 +12,37 @@ export TCPDIAG_FILE="$(dirname $0)/ss1.dump"
ts_log "[Testing ssfilter]"
ts_ss "$0" "Match dport = 22" -Htna dport = 22
-test_on "ESTAB 0 0 10.0.0.1:36266 10.0.0.1:22"
+test_on "ESTAB 0 0 10.0.0.1:36266 10.0.0.1:22"
ts_ss "$0" "Match dport 22" -Htna dport 22
-test_on "ESTAB 0 0 10.0.0.1:36266 10.0.0.1:22"
+test_on "ESTAB 0 0 10.0.0.1:36266 10.0.0.1:22"
ts_ss "$0" "Match (dport)" -Htna '( dport = 22 )'
-test_on "ESTAB 0 0 10.0.0.1:36266 10.0.0.1:22"
+test_on "ESTAB 0 0 10.0.0.1:36266 10.0.0.1:22"
ts_ss "$0" "Match src = 0.0.0.0" -Htna src = 0.0.0.0
-test_on "LISTEN 0 128 0.0.0.0:22 0.0.0.0:*"
+test_on "LISTEN 0 128 0.0.0.0:22 0.0.0.0:*"
ts_ss "$0" "Match src 0.0.0.0" -Htna src 0.0.0.0
-test_on "LISTEN 0 128 0.0.0.0:22 0.0.0.0:*"
+test_on "LISTEN 0 128 0.0.0.0:22 0.0.0.0:*"
ts_ss "$0" "Match src sport" -Htna src 0.0.0.0 sport = 22
-test_on "LISTEN 0 128 0.0.0.0:22 0.0.0.0:*"
+test_on "LISTEN 0 128 0.0.0.0:22 0.0.0.0:*"
ts_ss "$0" "Match src and sport" -Htna src 0.0.0.0 and sport = 22
-test_on "LISTEN 0 128 0.0.0.0:22 0.0.0.0:*"
+test_on "LISTEN 0 128 0.0.0.0:22 0.0.0.0:*"
ts_ss "$0" "Match src and sport and dport" -Htna src 10.0.0.1 and sport = 22 and dport = 50312
-test_on "ESTAB 0 0 10.0.0.1:22 10.0.0.2:50312"
+test_on "ESTAB 0 0 10.0.0.1:22 10.0.0.2:50312"
ts_ss "$0" "Match src and sport and (dport)" -Htna 'src 10.0.0.1 and sport = 22 and ( dport = 50312 )'
-test_on "ESTAB 0 0 10.0.0.1:22 10.0.0.2:50312"
+test_on "ESTAB 0 0 10.0.0.1:22 10.0.0.2:50312"
ts_ss "$0" "Match src and (sport and dport)" -Htna 'src 10.0.0.1 and ( sport = 22 and dport = 50312 )'
-test_on "ESTAB 0 0 10.0.0.1:22 10.0.0.2:50312"
+test_on "ESTAB 0 0 10.0.0.1:22 10.0.0.2:50312"
ts_ss "$0" "Match (src and sport) and dport" -Htna '( src 10.0.0.1 and sport = 22 ) and dport = 50312'
-test_on "ESTAB 0 0 10.0.0.1:22 10.0.0.2:50312"
+test_on "ESTAB 0 0 10.0.0.1:22 10.0.0.2:50312"
ts_ss "$0" "Match (src or src) and dst" -Htna '( src 0.0.0.0 or src 10.0.0.1 ) and dst 10.0.0.2'
-test_on "ESTAB 0 0 10.0.0.1:22 10.0.0.2:50312"
+test_on "ESTAB 0 0 10.0.0.1:22 10.0.0.2:50312"
--
2.19.1
^ permalink raw reply related
* Re: [PATCH v4] Wait for running BPF programs when updating map-in-map
From: Chenbo Feng @ 2018-11-10 18:58 UTC (permalink / raw)
To: gregkh
Cc: joel, Alexei Starovoitov, Daniel Colascione, Joel Fernandes,
linux-kernel, Tim Murray, netdev, Lorenzo Colitti,
Mathieu Desnoyers, Alexei Starovoitov, Daniel Borkmann, stable
In-Reply-To: <20181110152232.GA24724@kroah.com>
The Linus's tree commit SHA is 1ae80cf31938c8f77c37a29bbe29e7f1cd492be8.
I can send the patch to stable directly if needed.
Thanks
Chenbo Feng
On Sat, Nov 10, 2018 at 7:22 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Fri, Nov 09, 2018 at 06:01:54PM -0800, Chenbo Feng wrote:
> > Hi netdev,
> >
> > Could we queue up this patch to stable 4.14 and stable 4.19? I can
> > provide a backport patch if needed. I checked it is a clean
> > cherry-pick for 4.19 but have some minor conflict for 4.14.
>
> What is the git commit id of the patch in Linus's tree?
>
> thanks
>
> greg k-h
^ permalink raw reply
* Re: [RFC PATCH 0/3] acpi: Add acpi mdio support code
From: Wang, Dongsheng @ 2018-11-10 9:10 UTC (permalink / raw)
To: Andrew Lunn
Cc: timur@kernel.org, Zheng, Joey, f.fainelli@gmail.com,
rjw@rjwysocki.net, linux-acpi@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <20181108232353.GL5259@lunn.ch>
Hi Andrew,
On 2018/11/9 7:23, Andrew Lunn wrote:
> On Thu, Nov 08, 2018 at 03:21:29PM +0800, Wang Dongsheng wrote:
>> Originally I just push "phy-handle" support for ACPI on the QCOM QDF2400
>> platform. After some discussion and following Andrew's advice, I send
>> out with a generic version of ACPI.
>>
>> Current there is no clear documentation about MDIO/PHY for ACPI, so when
>> I reading some documents about ACPI [1], I think we just need to reuse the
>> DT binding in the ACPI.[2]. However, this series of patches are not
>> fully compatible with all contents specified in DT binding.
>>
>> The most important thing about this iseries is link the phy device and
>> fwnode of acpi. Besides, we need to carry out bus scan at the mdio
>> register. Therefore, I am not compatible with more DT binding properties
>> in this series of patches. More support will be in the follow-up patches
>> support, or some people do the support.
>>
>> Example:
>> Based on ACPI doc:
>> Documentation/acpi/dsd/data-node-references.txt
>> Documentation/acpi/dsd/graph.txt
>> With _DSD device properties we can finally do this:
>> Device (MDIO) {
>> Name (_DSD, Package () {
>> ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
>> Package () { Package () { "ethernet-phy@0", PHY0 }, }
>> })
>> Name (PHY0, Package() {
>> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
>> Package () { Package () { "reg", 0x0 }, }
>> })
> I don't know much about ACPI. I do know DT. MDIO busses can have
> multiple PHYs on them. Is the following valid to list two PHYs?
>
> Device (MDIO) {
> Name (_DSD, Package () {
> ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
> Package () { Package () { "ethernet-phy@0", PHY0 }, }
> })
> Name (PHY0, Package() {
> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> Package () { Package () { "reg", 0x0 }, }
> })
> Name (_DSD, Package () {
> ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
> Package () { Package () { "ethernet-phy@10", PHY1 }, }
> })
> Name (PHY1, Package() {
> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> Package () { Package () { "reg", 0x10 }, }
> })
> }
Multiple PHYs example:
Device (MDIO)
{
Name (_DSD, Package () {
ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
Package () {
Package () { "ethernet-phy@0", PHY0 },
Package () { "ethernet-phy@1", PHY1 },
...
...
}
})
Name (PHY0, Package() {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () { "reg", 0x0 },
}
})
Name (PHY1, Package() {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () { "reg", 0x1 },
}
})
}
Device (MAC0)
{
// _DSD: Device-Specific Data
Name (_DSD, Package (0x02) {
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301") /* Device
Properties for _DSD */,
Package () {
Package () { "phy-handle", Package () { \_SB.MDIO,
"ethernet-phy@0" } },
...
...
}
})
}
Device (MAC1)
{
// _DSD: Device-Specific Data
Name (_DSD, Package (0x02) {
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301") /* Device
Properties for _DSD */,
Package () {
Package () { "phy-handle", Package () { \_SB.MDIO,
"ethernet-phy@1" } },
...
...
}
})
}
>
> An MDIO bus can also have more than PHYs on them. There can be
> Ethernet switches. Broadcom also have some with generic PHY devices on
> them, and other odd things. That means whatever is on an MDIO bus is a
> device in the Linux device model. How does that work? Do we need some
> form Device (PHY) {}?
ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b") describes a ACPI data node.
The data node can contain property or pointer.
Let's look at the table I'm using:
Device (MAC1)
{
// _DSD: Device-Specific Data
Name (_DSD, Package (0x02) {
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301") /* Device
Properties for _DSD */,
Package (0x07) {
Package () { "phy-handle", Package () { \_SB.MAC1.MDIO,
"ethernet-phy@1" } },
Package () { "dev-refs", \_SB.MAC0 },
Package () { "refs0-dev", Package () { \_SB.MAC1.MDIO,
"refs@0" } },
Package () { "refs1-dev", Package () { \_SB.MAC1.MDIO,
"refs@1" } },
...
...
}
})
Device (MDIO)
{
Name (_DSD, Package () {
ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
Package () {
Package () { "ethernet-phy@1", PHY1 },
Package () { "refs@0", REF0},
Package () { "refs@1", REF1},
}
})
//Contain a property
Name (PHY1, Package() {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () { "reg", 0x1 },
}
})
//Point to a device
Name (REF0, Package() {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () { "child-refs-dev", \_SB.MAC0 },
}
})
//Contain a property and a pointer that point to a device
Name (REF1, Package() {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () { "property", 0x5 },
Package () { "child-refs-dev", \_SB.MAC0 },
}
})
}
}
> Device (MDIO) {
> Device (PHY) {
> Name (_DSD, Package () {
> ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
> Package () { Package () { "ethernet-phy@0", PHY0 }, }
> })
> Name (PHY0, Package() {
> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> Package () { Package () { "reg", 0x0 }, }
> })
> }
> Device (PHY) {
> Name (_DSD, Package () {
> ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
> Package () { Package () { "ethernet-phy@10", PHY1 }, }
> })
> Name (PHY1, Package() {
> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> Package () { Package () { "reg", 0x10 }, }
> })
> Device (SWITCH) {
> Name (_DSD, Package () {
> ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
> Package () { Package () { "switch@11", SWITCH0 }, }
> })
> Name (SWITCH0, Package() {
> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> Package () { Package () { "reg", 0x11 }, }
> })
> }
Device (MDIO)
{
Name (_DSD, Package () {
ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
Package () {
Package () { "ethernet-phy@1", PHY1 },
Package () { "switch@0", SW00 },
Package () { "switch@1", SW01 },
}
})
//Contain a property
Name (PHY1, Package() {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () { "reg", 0x1 },
}
})
Name (SW00, Package() {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () { "reg", 0x0 },
}
})
Name (SW01, Package() {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () { "property", 0x5 },
}
})
}
> }
>
> I'm just trying to ensure whatever is defined is flexible enough that
> we really can later support everything which DT does. We have PHYs on
> MDIO busses, inside switches, which are on MDIO busses, which are
> inside Ethernet interfaces, etc.
I think it can be satisfied. See the table I'm using above.
> An MDIO bus is very similar to an i2c bus. How is that described in
> ACPI? Anything we can learn from that?
About the data node, I just read the Kernel Documentation/acpi/dsd/
And others learn from ACPI spec.
Cheers,
Dongsheng
^ permalink raw reply
* Re: WARNING in format_decode (2)
From: syzbot @ 2018-11-10 8:42 UTC (permalink / raw)
To: alexei.starovoitov, daniel, linux-kernel, mingo, netdev, rostedt,
syzkaller-bugs
In-Reply-To: <000000000000e12d4105746dcb0d@google.com>
syzbot has found a reproducer for the following crash on:
HEAD commit: da85d8bfd151 kselftests/bpf: use ping6 as the default ipv6..
git tree: bpf
console output: https://syzkaller.appspot.com/x/log.txt?x=116bf533400000
kernel config: https://syzkaller.appspot.com/x/.config?x=8f559fee2fc3375a
dashboard link: https://syzkaller.appspot.com/bug?extid=1ec5c5ec949c4adaa0c4
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16d03247400000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=104f5533400000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+1ec5c5ec949c4adaa0c4@syzkaller.appspotmail.com
** **
** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE **
**********************************************************
------------[ cut here ]------------
Please remove unsupported %\0 in format string
WARNING: CPU: 0 PID: 5654 at lib/vsprintf.c:2152 format_decode+0x8fc/0xaf0
lib/vsprintf.c:2152
Kernel panic - not syncing: panic_on_warn set ...
CPU: 0 PID: 5654 Comm: syz-executor818 Not tainted 4.20.0-rc1+ #80
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+0x244/0x39d lib/dump_stack.c:113
panic+0x2ad/0x55c kernel/panic.c:188
__warn.cold.8+0x20/0x45 kernel/panic.c:540
report_bug+0x254/0x2d0 lib/bug.c:186
fixup_bug arch/x86/kernel/traps.c:178 [inline]
do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:271
do_invalid_op+0x36/0x40 arch/x86/kernel/traps.c:290
invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:969
RIP: 0010:format_decode+0x8fc/0xaf0 lib/vsprintf.c:2152
Code: e8 c9 37 b5 f9 41 c6 45 00 12 e9 9b fd ff ff e8 ba 37 b5 f9 0f be f3
48 c7 c7 c0 f1 d5 88 c6 05 d2 08 47 02 01 e8 74 99 7e f9 <0f> 0b 4d 8b 66
c0 e9 59 fe ff ff 48 8b bd 70 ff ff ff e8 6d 84 f8
RSP: 0018:ffff8801ba76f670 EFLAGS: 00010286
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffffffff8165e9b5 RDI: 0000000000000005
RBP: ffff8801ba76f718 R08: ffff8801b6cfc0c0 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffff8801ba76faec
R13: ffff8801ba76f790 R14: ffff8801ba76f6f0 R15: 0000000000000000
vsnprintf+0x185/0x1b60 lib/vsprintf.c:2248
vscnprintf+0x2d/0x80 lib/vsprintf.c:2399
__trace_array_vprintk.part.59+0x5b/0x2f0 kernel/trace/trace.c:2992
__trace_array_vprintk kernel/trace/trace.c:3023 [inline]
trace_array_vprintk kernel/trace/trace.c:3023 [inline]
trace_vprintk+0x71/0x90 kernel/trace/trace.c:3061
__trace_printk+0xce/0x120 kernel/trace/trace_printk.c:238
____bpf_trace_printk kernel/trace/bpf_trace.c:271 [inline]
bpf_trace_printk+0xb30/0xc50 kernel/trace/bpf_trace.c:163
bpf_prog_12183cdb1cd51dab+0x3e7/0x1000
Kernel Offset: disabled
Rebooting in 86400 seconds..
^ permalink raw reply
* Re: [PATCH net v2] net: sched: cls_flower: validate nested enc_opts_policy to avoid warning
From: Jiri Pirko @ 2018-11-10 7:18 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: davem, oss-drivers, netdev
In-Reply-To: <20181110050626.6659-1-jakub.kicinski@netronome.com>
Sat, Nov 10, 2018 at 06:06:26AM CET, jakub.kicinski@netronome.com wrote:
>TCA_FLOWER_KEY_ENC_OPTS and TCA_FLOWER_KEY_ENC_OPTS_MASK can only
>currently contain further nested attributes, which are parsed by
>hand, so the policy is never actually used resulting in a W=1
>build warning:
>
>net/sched/cls_flower.c:492:1: warning: ‘enc_opts_policy’ defined but not used [-Wunused-const-variable=]
> enc_opts_policy[TCA_FLOWER_KEY_ENC_OPTS_MAX + 1] = {
>
>Add the validation anyway to avoid potential bugs when other
>attributes are added and to make the attribute structure slightly
>more clear. Validation will also set extact to point to bad
>attribute on error.
>
>Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
>Acked-by: Simon Horman <simon.horman@netronome.com>
Fixes: 0a6e77784f49 ("net/sched: allow flower to match tunnel options")
Acked-by: Jiri Pirko <jiri@mellanox.com>
^ permalink raw reply
* Re: [net-next PATCH v3] net: sched: cls_flower: Classify packets using port ranges
From: Jiri Pirko @ 2018-11-10 7:14 UTC (permalink / raw)
To: Amritha Nambiar
Cc: netdev, davem, jakub.kicinski, sridhar.samudrala, jhs,
xiyou.wangcong
In-Reply-To: <154180867008.52041.3062211283036334314.stgit@anamhost.jf.intel.com>
Sat, Nov 10, 2018 at 01:11:10AM CET, amritha.nambiar@intel.com wrote:
[...]
>@@ -1026,8 +1122,7 @@ static void fl_init_dissector(struct flow_dissector *dissector,
> FLOW_DISSECTOR_KEY_IPV4_ADDRS, ipv4);
> FL_KEY_SET_IF_MASKED(mask, keys, cnt,
> FLOW_DISSECTOR_KEY_IPV6_ADDRS, ipv6);
>- FL_KEY_SET_IF_MASKED(mask, keys, cnt,
>- FLOW_DISSECTOR_KEY_PORTS, tp);
>+ FL_KEY_SET(keys, cnt, FLOW_DISSECTOR_KEY_PORTS, tp);
You still need to set the key under a condition. Something like:
if (FL_KEY_IS_MASKED(mask, tp) ||
FL_KEY_IS_MASKED(mask, tp_min) ||
FL_KEY_IS_MASKED(mask, tp_max)
FL_KEY_SET(keys, cnt, FLOW_DISSECTOR_KEY_PORTS, tp);
> FL_KEY_SET_IF_MASKED(mask, keys, cnt,
> FLOW_DISSECTOR_KEY_IP, ip);
> FL_KEY_SET_IF_MASKED(mask, keys, cnt,
[...]
^ permalink raw reply
* Re: [PATCH net-next] udp6: cleanup stats accounting in recvmsg()
From: David Miller @ 2018-11-10 4:07 UTC (permalink / raw)
To: pabeni; +Cc: netdev
In-Reply-To: <650a43db4aa1039a9cefe66aeecf226da9efd115.1541775141.git.pabeni@redhat.com>
From: Paolo Abeni <pabeni@redhat.com>
Date: Fri, 9 Nov 2018 15:52:45 +0100
> In the udp6 code path, we needed multiple tests to select the correct
> mib to be updated. Since we touch at least a counter at each iteration,
> it's convenient to use the recently introduced __UDPX_MIB() helper once
> and remove some code duplication.
>
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next v2 0/2] dpaa2-eth: defer probe on object allocate
From: David Miller @ 2018-11-10 4:09 UTC (permalink / raw)
To: ioana.ciornei; +Cc: netdev, andrew, ruxandra.radulescu
In-Reply-To: <1541777182-9135-1-git-send-email-ioana.ciornei@nxp.com>
From: Ioana Ciornei <ioana.ciornei@nxp.com>
Date: Fri, 9 Nov 2018 15:26:45 +0000
> Allocatable objects on the fsl-mc bus may be probed by the fsl_mc_allocator
> after the first attempts of other drivers to use them. Defer the probe when
> this situation happens.
>
> Changes in v2:
> - proper handling of IS_ERR_OR_NULL
Series applied.
^ permalink raw reply
* Re: [PATCH net] flow_dissector: do not dissect l4 ports for fragments
From: David Miller @ 2018-11-10 4:02 UTC (permalink / raw)
To: edumazet; +Cc: netdev, eric.dumazet, soukjin.bae
In-Reply-To: <20181110005306.8102-1-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Fri, 9 Nov 2018 16:53:06 -0800
> From: 배석진 <soukjin.bae@samsung.com>
>
> Only first fragment has the sport/dport information,
> not the following ones.
>
> If we want consistent hash for all fragments, we need to
> ignore ports even for first fragment.
>
> This bug is visible for IPv6 traffic, if incoming fragments
> do not have a flow label, since skb_get_hash() will give
> different results for first fragment and following ones.
>
> It is also visible if any routing rule wants dissection
> and sport or dport.
>
> See commit 5e5d6fed3741 ("ipv6: route: dissect flow
> in input path if fib rules need it") for details.
>
> [edumazet] rewrote the changelog completely.
>
> Fixes: 06635a35d13d ("flow_dissect: use programable dissector in skb_flow_dissect and friends")
> Signed-off-by: 배석진 <soukjin.bae@samsung.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [net-next PATCH v2] net: sched: cls_flower: Classify packets using port ranges
From: Nambiar, Amritha @ 2018-11-10 4:56 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, jakub.kicinski, sridhar.samudrala, jhs,
xiyou.wangcong
In-Reply-To: <20181109121016.GA4745@nanopsycho>
On 11/9/2018 4:10 AM, Jiri Pirko wrote:
> Wed, Nov 07, 2018 at 10:22:42PM CET, amritha.nambiar@intel.com wrote:
>> Added support in tc flower for filtering based on port ranges.
>>
>> Example:
>> 1. Match on a port range:
>> -------------------------
>> $ tc filter add dev enp4s0 protocol ip parent ffff:\
>> prio 1 flower ip_proto tcp dst_port range 20-30 skip_hw\
>> action drop
>>
>> $ tc -s filter show dev enp4s0 parent ffff:
>> filter protocol ip pref 1 flower chain 0
>> filter protocol ip pref 1 flower chain 0 handle 0x1
>> eth_type ipv4
>> ip_proto tcp
>> dst_port range 20-30
>> skip_hw
>> not_in_hw
>> action order 1: gact action drop
>> random type none pass val 0
>> index 1 ref 1 bind 1 installed 85 sec used 3 sec
>> Action statistics:
>> Sent 460 bytes 10 pkt (dropped 10, overlimits 0 requeues 0)
>> backlog 0b 0p requeues 0
>>
>> 2. Match on IP address and port range:
>> --------------------------------------
>> $ tc filter add dev enp4s0 protocol ip parent ffff:\
>> prio 1 flower dst_ip 192.168.1.1 ip_proto tcp dst_port range 100-200\
>> skip_hw action drop
>>
>> $ tc -s filter show dev enp4s0 parent ffff:
>> filter protocol ip pref 1 flower chain 0 handle 0x2
>> eth_type ipv4
>> ip_proto tcp
>> dst_ip 192.168.1.1
>> dst_port range 100-200
>> skip_hw
>> not_in_hw
>> action order 1: gact action drop
>> random type none pass val 0
>> index 2 ref 1 bind 1 installed 58 sec used 2 sec
>> Action statistics:
>> Sent 920 bytes 20 pkt (dropped 20, overlimits 0 requeues 0)
>> backlog 0b 0p requeues 0
>>
>> v2:
>> Addressed Jiri's comments:
>> 1. Added separate functions for dst and src comparisons.
>> 2. Removed endpoint enum.
>> 3. Added new bit TCA_FLOWER_FLAGS_RANGE to decide normal/range
>> lookup.
>> 4. Cleaned up fl_lookup function.
>>
>> Signed-off-by: Amritha Nambiar <amritha.nambiar@intel.com>
>> ---
>> include/uapi/linux/pkt_cls.h | 7 ++
>> net/sched/cls_flower.c | 133 ++++++++++++++++++++++++++++++++++++++++--
>> 2 files changed, 134 insertions(+), 6 deletions(-)
>>
>> diff --git a/include/uapi/linux/pkt_cls.h b/include/uapi/linux/pkt_cls.h
>> index 401d0c1..b63c3cf 100644
>> --- a/include/uapi/linux/pkt_cls.h
>> +++ b/include/uapi/linux/pkt_cls.h
>> @@ -405,6 +405,11 @@ enum {
>> TCA_FLOWER_KEY_UDP_SRC, /* be16 */
>> TCA_FLOWER_KEY_UDP_DST, /* be16 */
>>
>> + TCA_FLOWER_KEY_PORT_SRC_MIN, /* be16 */
>> + TCA_FLOWER_KEY_PORT_SRC_MAX, /* be16 */
>> + TCA_FLOWER_KEY_PORT_DST_MIN, /* be16 */
>> + TCA_FLOWER_KEY_PORT_DST_MAX, /* be16 */
>> +
>
> Please put it at the end of the enum, as David mentioned.
Will fix in v3.
>
>
>> TCA_FLOWER_FLAGS,
>> TCA_FLOWER_KEY_VLAN_ID, /* be16 */
>> TCA_FLOWER_KEY_VLAN_PRIO, /* u8 */
>> @@ -518,6 +523,8 @@ enum {
>> TCA_FLOWER_KEY_FLAGS_FRAG_IS_FIRST = (1 << 1),
>> };
>>
>> +#define TCA_FLOWER_MASK_FLAGS_RANGE (1 << 0) /* Range-based match */
>> +
>> /* Match-all classifier */
>>
>> enum {
>> diff --git a/net/sched/cls_flower.c b/net/sched/cls_flower.c
>> index 9aada2d..9d2582d 100644
>> --- a/net/sched/cls_flower.c
>> +++ b/net/sched/cls_flower.c
>> @@ -55,6 +55,9 @@ struct fl_flow_key {
>> struct flow_dissector_key_ip ip;
>> struct flow_dissector_key_ip enc_ip;
>> struct flow_dissector_key_enc_opts enc_opts;
>> +
>
> No need for an empty line.
Will fix in v3.
>
>
>> + struct flow_dissector_key_ports tp_min;
>> + struct flow_dissector_key_ports tp_max;
>> } __aligned(BITS_PER_LONG / 8); /* Ensure that we can do comparisons as longs. */
>>
>> struct fl_flow_mask_range {
>> @@ -65,6 +68,7 @@ struct fl_flow_mask_range {
>> struct fl_flow_mask {
>> struct fl_flow_key key;
>> struct fl_flow_mask_range range;
>> + u32 flags;
>> struct rhash_head ht_node;
>> struct rhashtable ht;
>> struct rhashtable_params filter_ht_params;
>> @@ -179,13 +183,89 @@ static void fl_clear_masked_range(struct fl_flow_key *key,
>> memset(fl_key_get_start(key, mask), 0, fl_mask_range(mask));
>> }
>>
>> -static struct cls_fl_filter *fl_lookup(struct fl_flow_mask *mask,
>> - struct fl_flow_key *mkey)
>> +static bool fl_range_port_dst_cmp(struct cls_fl_filter *filter,
>> + struct fl_flow_key *key,
>> + struct fl_flow_key *mkey)
>> +{
>> + __be16 min_mask, max_mask, min_val, max_val;
>> +
>> + min_mask = htons(filter->mask->key.tp_min.dst);
>> + max_mask = htons(filter->mask->key.tp_max.dst);
>> + min_val = htons(filter->key.tp_min.dst);
>> + max_val = htons(filter->key.tp_max.dst);
>> +
>> + if (min_mask && max_mask) {
>> + if (htons(key->tp.dst) < min_val ||
>> + htons(key->tp.dst) > max_val)
>> + return false;
>> +
>> + /* skb does not have min and max values */
>> + mkey->tp_min.dst = filter->mkey.tp_min.dst;
>> + mkey->tp_max.dst = filter->mkey.tp_max.dst;
>> + }
>> + return true;
>> +}
>> +
>> +static bool fl_range_port_src_cmp(struct cls_fl_filter *filter,
>> + struct fl_flow_key *key,
>> + struct fl_flow_key *mkey)
>> +{
>> + __be16 min_mask, max_mask, min_val, max_val;
>> +
>> + min_mask = htons(filter->mask->key.tp_min.src);
>> + max_mask = htons(filter->mask->key.tp_max.src);
>> + min_val = htons(filter->key.tp_min.src);
>> + max_val = htons(filter->key.tp_max.src);
>> +
>> + if (min_mask && max_mask) {
>> + if (htons(key->tp.src) < min_val ||
>> + htons(key->tp.src) > max_val)
>> + return false;
>> +
>> + /* skb does not have min and max values */
>> + mkey->tp_min.src = filter->mkey.tp_min.src;
>> + mkey->tp_max.src = filter->mkey.tp_max.src;
>> + }
>> + return true;
>> +}
>> +
>> +static struct cls_fl_filter *__fl_lookup(struct fl_flow_mask *mask,
>> + struct fl_flow_key *mkey)
>> {
>> return rhashtable_lookup_fast(&mask->ht, fl_key_get_start(mkey, mask),
>> mask->filter_ht_params);
>> }
>>
>> +static struct cls_fl_filter *fl_lookup_range(struct fl_flow_mask *mask,
>> + struct fl_flow_key *mkey,
>> + struct fl_flow_key *key)
>> +{
>> + struct cls_fl_filter *filter, *f;
>> +
>> + list_for_each_entry_rcu(filter, &mask->filters, list) {
>> + if (!fl_range_port_dst_cmp(filter, key, mkey))
>> + continue;
>> +
>> + if (!fl_range_port_src_cmp(filter, key, mkey))
>> + continue;
>> +
>> + f = __fl_lookup(mask, mkey);
>> + if (f)
>> + return f;
>> + }
>> + return NULL;
>> +}
>> +
>> +static struct cls_fl_filter *fl_lookup(struct fl_flow_mask *mask,
>> + struct fl_flow_key *mkey,
>> + struct fl_flow_key *key)
>> +{
>> + if ((mask->flags & TCA_FLOWER_MASK_FLAGS_RANGE))
>> + return fl_lookup_range(mask, mkey, key);
>> +
>> + return __fl_lookup(mask, mkey);
>> +}
>> +
>> static int fl_classify(struct sk_buff *skb, const struct tcf_proto *tp,
>> struct tcf_result *res)
>> {
>> @@ -207,8 +287,8 @@ static int fl_classify(struct sk_buff *skb, const struct tcf_proto *tp,
>> skb_flow_dissect(skb, &mask->dissector, &skb_key, 0);
>>
>> fl_set_masked_key(&skb_mkey, &skb_key, mask);
>> + f = fl_lookup(mask, &skb_mkey, &skb_key);
>>
>> - f = fl_lookup(mask, &skb_mkey);
>
> Please leave the original ordering (empty line, fl_lookup call).
Will fix in v3.
>
>
>> if (f && !tc_skip_sw(f->flags)) {
>> *res = f->res;
>> return tcf_exts_exec(skb, &f->exts, res);
>> @@ -909,6 +989,23 @@ static int fl_set_key(struct net *net, struct nlattr **tb,
>> sizeof(key->arp.tha));
>> }
>>
>> + if (key->basic.ip_proto == IPPROTO_TCP ||
>> + key->basic.ip_proto == IPPROTO_UDP ||
>> + key->basic.ip_proto == IPPROTO_SCTP) {
>> + fl_set_key_val(tb, &key->tp_min.dst,
>> + TCA_FLOWER_KEY_PORT_DST_MIN, &mask->tp_min.dst,
>> + TCA_FLOWER_UNSPEC, sizeof(key->tp_min.dst));
>> + fl_set_key_val(tb, &key->tp_max.dst,
>> + TCA_FLOWER_KEY_PORT_DST_MAX, &mask->tp_max.dst,
>> + TCA_FLOWER_UNSPEC, sizeof(key->tp_max.dst));
>> + fl_set_key_val(tb, &key->tp_min.src,
>> + TCA_FLOWER_KEY_PORT_SRC_MIN, &mask->tp_min.src,
>> + TCA_FLOWER_UNSPEC, sizeof(key->tp_min.src));
>> + fl_set_key_val(tb, &key->tp_max.src,
>> + TCA_FLOWER_KEY_PORT_SRC_MAX, &mask->tp_max.src,
>> + TCA_FLOWER_UNSPEC, sizeof(key->tp_max.src));
>> + }
>> +
>> if (tb[TCA_FLOWER_KEY_ENC_IPV4_SRC] ||
>> tb[TCA_FLOWER_KEY_ENC_IPV4_DST]) {
>> key->enc_control.addr_type = FLOW_DISSECTOR_KEY_IPV4_ADDRS;
>> @@ -1026,8 +1123,7 @@ static void fl_init_dissector(struct flow_dissector *dissector,
>> FLOW_DISSECTOR_KEY_IPV4_ADDRS, ipv4);
>> FL_KEY_SET_IF_MASKED(mask, keys, cnt,
>> FLOW_DISSECTOR_KEY_IPV6_ADDRS, ipv6);
>> - FL_KEY_SET_IF_MASKED(mask, keys, cnt,
>> - FLOW_DISSECTOR_KEY_PORTS, tp);
>> + FL_KEY_SET(keys, cnt, FLOW_DISSECTOR_KEY_PORTS, tp);
>> FL_KEY_SET_IF_MASKED(mask, keys, cnt,
>> FLOW_DISSECTOR_KEY_IP, ip);
>> FL_KEY_SET_IF_MASKED(mask, keys, cnt,
>> @@ -1074,6 +1170,10 @@ static struct fl_flow_mask *fl_create_new_mask(struct cls_fl_head *head,
>>
>> fl_mask_copy(newmask, mask);
>>
>> + if ((newmask->key.tp_min.dst && newmask->key.tp_max.dst) ||
>> + (newmask->key.tp_min.src && newmask->key.tp_max.src))
>> + newmask->flags |= TCA_FLOWER_MASK_FLAGS_RANGE;
>> +
>> err = fl_init_mask_hashtable(newmask);
>> if (err)
>> goto errout_free;
>> @@ -1227,7 +1327,7 @@ static int fl_change(struct net *net, struct sk_buff *in_skb,
>> goto errout_idr;
>>
>> if (!tc_skip_sw(fnew->flags)) {
>> - if (!fold && fl_lookup(fnew->mask, &fnew->mkey)) {
>> + if (!fold && __fl_lookup(fnew->mask, &fnew->mkey)) {
>> err = -EEXIST;
>> goto errout_mask;
>> }
>> @@ -1800,6 +1900,27 @@ static int fl_dump_key(struct sk_buff *skb, struct net *net,
>> sizeof(key->arp.tha))))
>> goto nla_put_failure;
>>
>> + if ((key->basic.ip_proto == IPPROTO_TCP ||
>> + key->basic.ip_proto == IPPROTO_UDP ||
>> + key->basic.ip_proto == IPPROTO_SCTP) &&
>> + (fl_dump_key_val(skb, &key->tp_min.dst,
>> + TCA_FLOWER_KEY_PORT_DST_MIN,
>> + &mask->tp_min.dst, TCA_FLOWER_UNSPEC,
>> + sizeof(key->tp_min.dst)) ||
>> + fl_dump_key_val(skb, &key->tp_max.dst,
>> + TCA_FLOWER_KEY_PORT_DST_MAX,
>> + &mask->tp_max.dst, TCA_FLOWER_UNSPEC,
>> + sizeof(key->tp_max.dst)) ||
>> + fl_dump_key_val(skb, &key->tp_min.src,
>> + TCA_FLOWER_KEY_PORT_SRC_MIN,
>> + &mask->tp_min.src, TCA_FLOWER_UNSPEC,
>> + sizeof(key->tp_min.src)) ||
>> + fl_dump_key_val(skb, &key->tp_max.src,
>> + TCA_FLOWER_KEY_PORT_SRC_MAX,
>> + &mask->tp_max.src, TCA_FLOWER_UNSPEC,
>> + sizeof(key->tp_max.src))))
>> + goto nla_put_failure;
>> +
>> if (key->enc_control.addr_type == FLOW_DISSECTOR_KEY_IPV4_ADDRS &&
>> (fl_dump_key_val(skb, &key->enc_ipv4.src,
>> TCA_FLOWER_KEY_ENC_IPV4_SRC, &mask->enc_ipv4.src,
>>
^ 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