* Re: [RFC PATCH net-next 4/5] bpf/verifier: track signed and unsigned min/max values
From: Alexei Starovoitov @ 2017-06-08 16:47 UTC (permalink / raw)
To: Edward Cree
Cc: davem, Alexei Starovoitov, Daniel Borkmann, netdev, iovisor-dev,
LKML
In-Reply-To: <abee6b82-316b-58cb-fa85-0584866f8d29@solarflare.com>
On Thu, Jun 08, 2017 at 04:23:24PM +0100, Edward Cree wrote:
> On 08/06/17 03:40, Alexei Starovoitov wrote:
> > On Wed, Jun 07, 2017 at 03:59:25PM +0100, Edward Cree wrote:
> >> Allows us to, sometimes, combine information from a signed check of one
> >> bound and an unsigned check of the other.
> >> We now track the full range of possible values, rather than restricting
> >> ourselves to [0, 1<<30) and considering anything beyond that as
> >> unknown. While this is probably not necessary, it makes the code more
> >> straightforward and symmetrical between signed and unsigned bounds.
> >>
> >> Signed-off-by: Edward Cree <ecree@solarflare.com>
> >> ---
> >> include/linux/bpf_verifier.h | 22 +-
> >> kernel/bpf/verifier.c | 661 +++++++++++++++++++++++++------------------
> >> 2 files changed, 395 insertions(+), 288 deletions(-)
> >>
> >> diff --git a/include/linux/bpf_verifier.h b/include/linux/bpf_verifier.h
> >> index e341469..10a5944 100644
> >> --- a/include/linux/bpf_verifier.h
> >> +++ b/include/linux/bpf_verifier.h
> >> @@ -11,11 +11,15 @@
> >> #include <linux/filter.h> /* for MAX_BPF_STACK */
> >> #include <linux/tnum.h>
> >>
> >> - /* Just some arbitrary values so we can safely do math without overflowing and
> >> - * are obviously wrong for any sort of memory access.
> >> - */
> >> -#define BPF_REGISTER_MAX_RANGE (1024 * 1024 * 1024)
> >> -#define BPF_REGISTER_MIN_RANGE -1
> >> +/* Maximum variable offset umax_value permitted when resolving memory accesses.
> >> + * In practice this is far bigger than any realistic pointer offset; this limit
> >> + * ensures that umax_value + (int)off + (int)size cannot overflow a u64.
> >> + */
> >> +#define BPF_MAX_VAR_OFF (1ULL << 31)
> >> +/* Maximum variable size permitted for ARG_CONST_SIZE[_OR_ZERO]. This ensures
> >> + * that converting umax_value to int cannot overflow.
> >> + */
> >> +#define BPF_MAX_VAR_SIZ INT_MAX
> >>
> >> struct bpf_reg_state {
> >> enum bpf_reg_type type;
> >> @@ -38,7 +42,7 @@ struct bpf_reg_state {
> >> * PTR_TO_MAP_VALUE_OR_NULL, we have to NULL-check it _first_.
> >> */
> >> u32 id;
> >> - /* These three fields must be last. See states_equal() */
> >> + /* These five fields must be last. See states_equal() */
> >> /* For scalar types (SCALAR_VALUE), this represents our knowledge of
> >> * the actual value.
> >> * For pointer types, this represents the variable part of the offset
> >> @@ -51,8 +55,10 @@ struct bpf_reg_state {
> >> * These refer to the same value as align, not necessarily the actual
> >> * contents of the register.
> >> */
> >> - s64 min_value; /* minimum possible (s64)value */
> >> - u64 max_value; /* maximum possible (u64)value */
> >> + s64 smin_value; /* minimum possible (s64)value */
> >> + s64 smax_value; /* maximum possible (s64)value */
> >> + u64 umin_value; /* minimum possible (u64)value */
> >> + u64 umax_value; /* maximum possible (u64)value */
> > have uneasy feeling about this one.
> > It's 16 extra bytes to be stored in every reg_state and memcmp later
> > while we didn't have cases where people wanted negative values
> > in ptr+var cases. Why bother than?
> It was the only way I could see to both pass my new test (correctly reject
> an uninformative combination of JGT and JSGT), and still pass one of the
> other tests where we have to accept an informative combination of JGT and
> JSGT. This isn't so much about supporting negative numbers as it is about
> deducing the right bounds from signed checks, or a mixture of signed and
> unsigned checks on the same value.
> For instance, if you check a register is s< 5, you know nothing yet about
> its unsigned maximum (it could be -1). But if you then check it's u< 10,
> or even if you check it's s>= 0, you've now learned its sign bit so you
> can conclude from the previous check that it's u< 5. But to conclude
> that, you have to have stored the bound from the previous check.
> I'm not too worried about the extra 16 bytes, because this is a control-
> plane operation, and I'd be surprised if its performance really turned out
> to be a problem. But if there's a better way to handle these checks, I'm
> all ears.
> >> unknown. While this is probably not necessary, it makes the code more
> >> straightforward and symmetrical between signed and unsigned bounds.
> > it's hard for me to see the 'straightforward' part yet.
> Well, the new reg_set_min_max[_inv]() are simpler, as they just update the
> relevant bound then call __reg_deduce_bounds() to propagate that knowledge
> into the others, rather than having confusing (and, as we've seen, buggy)
> logic in each case about "if we did this kind of check we've learned that
> thing in this branch".
> Also, all the care to check "did we exceed BPF_REGISTER_MAX_RANGE?" goes
> away, as does special handling of negatives to turn them into
> BPF_REGISTER_MIN_RANGE (again, this has bugs in the current code). Instead
> we just have to check "does our operation on the bounds overflow?", and if
> so, mark our bounds as unknown.
> I think a lot of the arithmetic ops become a more mechanical "does this
> overflow? No? Then let's compute new bounds". But then, that's partly
> because the semantics of the old min_value and max_value weren't documented
> anywhere (do they refer to the signed or the unsigned value in the
> register?) and so it's unclear to me why some of the code does what it does.
got it. that all makes sense.
^ permalink raw reply
* Re: [PATCH net 2/3] bonding: fix 802.3ad support for 14G speed
From: Andrew Lunn @ 2017-06-08 16:48 UTC (permalink / raw)
To: Nicolas Dichtel
Cc: davem, netdev, j.vosburgh, vfalico, andy, thibaut.collet,
linville
In-Reply-To: <1496913493-23293-2-git-send-email-nicolas.dichtel@6wind.com>
On Thu, Jun 08, 2017 at 11:18:12AM +0200, Nicolas Dichtel wrote:
> This patch adds 14 Gbps enum definition, and fixes
> aggregated bandwidth calculation based on above slave links.
>
> Fixes: 0d7e2d2166f6 ("IB/ipoib: add get_link_ksettings in ethtool")
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> ---
> drivers/net/bonding/bond_3ad.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/net/bonding/bond_3ad.c b/drivers/net/bonding/bond_3ad.c
> index d1b09be63ba4..e5386ab706ec 100644
> --- a/drivers/net/bonding/bond_3ad.c
> +++ b/drivers/net/bonding/bond_3ad.c
> @@ -92,6 +92,7 @@ enum ad_link_speed_type {
> AD_LINK_SPEED_2500MBPS,
> AD_LINK_SPEED_5000MBPS,
> AD_LINK_SPEED_10000MBPS,
> + AD_LINK_SPEED_14000MBPS,
> AD_LINK_SPEED_20000MBPS,
> AD_LINK_SPEED_25000MBPS,
> AD_LINK_SPEED_40000MBPS,
> @@ -263,6 +264,7 @@ static inline int __check_agg_selection_timer(struct port *port)
> * %AD_LINK_SPEED_2500MBPS,
> * %AD_LINK_SPEED_5000MBPS,
> * %AD_LINK_SPEED_10000MBPS
> + * %AD_LINK_SPEED_14000MBPS,
> * %AD_LINK_SPEED_20000MBPS
> * %AD_LINK_SPEED_25000MBPS
> * %AD_LINK_SPEED_40000MBPS
> @@ -308,6 +310,10 @@ static u16 __get_link_speed(struct port *port)
> speed = AD_LINK_SPEED_10000MBPS;
> break;
>
> + case SPEED_14000:
> + speed = AD_LINK_SPEED_14000MBPS;
> + break;
> +
> case SPEED_20000:
> speed = AD_LINK_SPEED_20000MBPS;
> break;
> @@ -725,6 +731,9 @@ static u32 __get_agg_bandwidth(struct aggregator *aggregator)
> case AD_LINK_SPEED_10000MBPS:
> bandwidth = nports * 10000;
> break;
> + case AD_LINK_SPEED_14000MBPS:
> + bandwidth = nports * 14000;
> + break;
> case AD_LINK_SPEED_20000MBPS:
> bandwidth = nports * 20000;
> break;
How about adding a pr_warn() to the default clause?
Andrew
^ permalink raw reply
* Re: [RFC PATCH net-next 3/5] bpf/verifier: feed pointer-to-unknown-scalar casts into scalar ALU path
From: Alexei Starovoitov @ 2017-06-08 16:50 UTC (permalink / raw)
To: Edward Cree
Cc: davem, Alexei Starovoitov, Daniel Borkmann, netdev, iovisor-dev,
LKML
In-Reply-To: <2363ab5f-c344-900b-78ee-41e2eb0dd40f@solarflare.com>
On Thu, Jun 08, 2017 at 04:25:39PM +0100, Edward Cree wrote:
> On 08/06/17 03:35, Alexei Starovoitov wrote:
> > such large back and forth move doesn't help reviewing.
> > may be just merge it into previous patch?
> > Or keep that function in the right place in patch 2 already?
> I think 'diff' got a bit confused, and maybe with different options I could
> have got it to produce something more readable. But I think I will just
> merge this into patch 2; it's only separate because it started out as an
> experiment.
after sleeping on it I'm not sure we should be allowing such pointer
arithmetic. In normal C code people do fancy tricks with lower 3 bits
of the pointer, but in bpf code I cannot see such use case.
What kind of realistic code will be doing ptr & 0x40 ?
^ permalink raw reply
* Re: [PATCH v2 7/8] net: mvmdio: add xmdio support
From: Andrew Lunn @ 2017-06-08 16:55 UTC (permalink / raw)
To: Florian Fainelli
Cc: Antoine Tenart, davem, jason, gregory.clement,
sebastian.hesselbarth, thomas.petazzoni, netdev, mw, linux,
linux-arm-kernel
In-Reply-To: <a60a0b26-62b1-7c9e-e846-215747dddb1f@gmail.com>
On Thu, Jun 08, 2017 at 09:42:21AM -0700, Florian Fainelli wrote:
> On 06/08/2017 02:26 AM, Antoine Tenart wrote:
> > This patch adds the xMDIO interface support in the mvmdio driver. This
> > interface is used in Ethernet controllers on Marvell 370, 7k and 8k (as
> > of now). The xSMI interface supported by this driver complies with the
> > IEEE 802.3 clause 45 (while the SMI interface complies with the clause
> > 22). The xSMI interface is used by 10GbE devices.
>
> In the previous version you were properly defining a new compatibles
> strings for xmdio, but now you don't and instead you runtime select the
> operations based on whether MII_ADDR_C45 is set in the register which is
> fine from a functional perspective.
>
> If I get this right, the xMDIO controller is actually a superset of the
> MDIO controller and has an extra MVMDIO_XSMI_ADDR_REG register to
> preform C45 accesses?
>
> If that is the case (and looking at patch 8 that seems to be the case),
> you probably still need to define a new compatible string for that
> block, because it has a different register layout than its predecessor.
Yes, i think you need the compatible string to return -EOPNOSUP when
somebody tries to do a C45 access on the older IP which only has C22.
Andrew
^ permalink raw reply
* ATENCIÓN;
From: Sistemas administrador @ 2017-06-08 17:01 UTC (permalink / raw)
To: Recipients
ATENCIÓN;
Su buzón ha superado el límite de almacenamiento, que es de 5 GB definidos por el administrador, quien actualmente está ejecutando en 10.9GB, no puede ser capaz de enviar o recibir correo nuevo hasta que vuelva a validar su buzón de correo electrónico. Para revalidar su buzón de correo, envíe la
siguiente información a continuación:
nombre:
Nombre de usuario:
contraseña:
Confirmar contraseña:
E-mail:
teléfono
Si usted no puede revalidar su buzón, el buzón se deshabilitará!
Disculpa las molestias.
Código de verificación:Ar Correo.AR...AR005615273849598
Correo Soporte Técnico © 2017
¡gracias
Sistemas administrador
^ permalink raw reply
* [PATCH net] bpf, tests: fix endianness selection
From: Daniel Borkmann @ 2017-06-08 17:06 UTC (permalink / raw)
To: davem; +Cc: ast, netdev, Daniel Borkmann
I noticed that test_l4lb was failing in selftests:
# ./test_progs
test_pkt_access:PASS:ipv4 77 nsec
test_pkt_access:PASS:ipv6 44 nsec
test_xdp:PASS:ipv4 2933 nsec
test_xdp:PASS:ipv6 1500 nsec
test_l4lb:PASS:ipv4 377 nsec
test_l4lb:PASS:ipv6 544 nsec
test_l4lb:FAIL:stats 6297600000 200000
test_tcp_estats:PASS: 0 nsec
Summary: 7 PASSED, 1 FAILED
Tracking down the issue actually revealed that endianness selection
in bpf_endian.h is broken when compiled with clang with bpf target.
test_pkt_access.c, test_l4lb.c is compiled with __BYTE_ORDER as
__BIG_ENDIAN, test_xdp.c as __LITTLE_ENDIAN! test_l4lb noticeably
fails, because the test accounts bytes via bpf_ntohs(ip6h->payload_len)
and bpf_ntohs(iph->tot_len), and compares them against a defined
value and given a wrong endianness, the test outcome is different,
of course.
Turns out that there are actually two bugs: i) when we do __BYTE_ORDER
comparison with __LITTLE_ENDIAN/__BIG_ENDIAN, then depending on the
include order we see different outcomes. Reason is that __BYTE_ORDER
is undefined due to missing endian.h include. Before we include the
asm/byteorder.h (e.g. through linux/in.h), then __BYTE_ORDER equals
__LITTLE_ENDIAN since both are undefined, after the include which
correctly pulls in linux/byteorder/little_endian.h, __LITTLE_ENDIAN
is defined, but given __BYTE_ORDER is still undefined, we match on
__BYTE_ORDER equals to __BIG_ENDIAN since __BIG_ENDIAN is also
undefined at that point, sigh. ii) But even that would be wrong,
since when compiling the test cases with clang, one can select between
bpfeb and bpfel targets for cross compilation. Hence, we can also not
rely on what the system's endian.h provides, but we need to look at
the compiler's defined endianness. The compiler defines __BYTE_ORDER__,
and we can match __ORDER_LITTLE_ENDIAN__ and __ORDER_BIG_ENDIAN__,
which also reflects targets bpf (native), bpfel, bpfeb correctly,
thus really only rely on that. After patch:
# ./test_progs
test_pkt_access:PASS:ipv4 74 nsec
test_pkt_access:PASS:ipv6 42 nsec
test_xdp:PASS:ipv4 2340 nsec
test_xdp:PASS:ipv6 1461 nsec
test_l4lb:PASS:ipv4 400 nsec
test_l4lb:PASS:ipv6 530 nsec
test_tcp_estats:PASS: 0 nsec
Summary: 7 PASSED, 0 FAILED
Fixes: 43bcf707ccdc ("bpf: fix _htons occurences in test_progs")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
---
tools/testing/selftests/bpf/bpf_endian.h | 41 +++++++++++++++++++++++---------
1 file changed, 30 insertions(+), 11 deletions(-)
diff --git a/tools/testing/selftests/bpf/bpf_endian.h b/tools/testing/selftests/bpf/bpf_endian.h
index 19d0604..487cbfb 100644
--- a/tools/testing/selftests/bpf/bpf_endian.h
+++ b/tools/testing/selftests/bpf/bpf_endian.h
@@ -1,23 +1,42 @@
#ifndef __BPF_ENDIAN__
#define __BPF_ENDIAN__
-#include <asm/byteorder.h>
+#include <linux/swab.h>
-#if __BYTE_ORDER == __LITTLE_ENDIAN
-# define __bpf_ntohs(x) __builtin_bswap16(x)
-# define __bpf_htons(x) __builtin_bswap16(x)
-#elif __BYTE_ORDER == __BIG_ENDIAN
-# define __bpf_ntohs(x) (x)
-# define __bpf_htons(x) (x)
+/* LLVM's BPF target selects the endianness of the CPU
+ * it compiles on, or the user specifies (bpfel/bpfeb),
+ * respectively. The used __BYTE_ORDER__ is defined by
+ * the compiler, we cannot rely on __BYTE_ORDER from
+ * libc headers, since it doesn't reflect the actual
+ * requested byte order.
+ *
+ * Note, LLVM's BPF target has different __builtin_bswapX()
+ * semantics. It does map to BPF_ALU | BPF_END | BPF_TO_BE
+ * in bpfel and bpfeb case, which means below, that we map
+ * to cpu_to_be16(). We could use it unconditionally in BPF
+ * case, but better not rely on it, so that this header here
+ * can be used from application and BPF program side, which
+ * use different targets.
+ */
+#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
+# define __bpf_ntohs(x) __builtin_bswap16(x)
+# define __bpf_htons(x) __builtin_bswap16(x)
+# define __bpf_constant_ntohs(x) ___constant_swab16(x)
+# define __bpf_constant_htons(x) ___constant_swab16(x)
+#elif __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
+# define __bpf_ntohs(x) (x)
+# define __bpf_htons(x) (x)
+# define __bpf_constant_ntohs(x) (x)
+# define __bpf_constant_htons(x) (x)
#else
-# error "Fix your __BYTE_ORDER?!"
+# error "Fix your compiler's __BYTE_ORDER__?!"
#endif
#define bpf_htons(x) \
(__builtin_constant_p(x) ? \
- __constant_htons(x) : __bpf_htons(x))
+ __bpf_constant_htons(x) : __bpf_htons(x))
#define bpf_ntohs(x) \
(__builtin_constant_p(x) ? \
- __constant_ntohs(x) : __bpf_ntohs(x))
+ __bpf_constant_ntohs(x) : __bpf_ntohs(x))
-#endif
+#endif /* __BPF_ENDIAN__ */
--
1.9.3
^ permalink raw reply related
* Re: [RFC PATCH net-next 3/5] bpf/verifier: feed pointer-to-unknown-scalar casts into scalar ALU path
From: Edward Cree via iovisor-dev @ 2017-06-08 17:12 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Alexei Starovoitov, netdev-u79uwXL29TY76Z2rM5mHXA, iovisor-dev,
LKML, davem-fT/PcQaiUtIeIZ0/mPfg9Q
In-Reply-To: <20170608165004.n5jc33pocxlytuvf-+o4/htvd0TCa6kscz5V53/3mLCh9rsb+VpNB7YpNyf8@public.gmane.org>
On 08/06/17 17:50, Alexei Starovoitov wrote:
> On Thu, Jun 08, 2017 at 04:25:39PM +0100, Edward Cree wrote:
>> On 08/06/17 03:35, Alexei Starovoitov wrote:
>>> such large back and forth move doesn't help reviewing.
>>> may be just merge it into previous patch?
>>> Or keep that function in the right place in patch 2 already?
>> I think 'diff' got a bit confused, and maybe with different options I could
>> have got it to produce something more readable. But I think I will just
>> merge this into patch 2; it's only separate because it started out as an
>> experiment.
> after sleeping on it I'm not sure we should be allowing such pointer
> arithmetic. In normal C code people do fancy tricks with lower 3 bits
> of the pointer, but in bpf code I cannot see such use case.
> What kind of realistic code will be doing ptr & 0x40 ?
Well, I didn't support it because I saw a use case. I supported it because
it seemed easy to do and the code came out reasonably elegant-looking.
Since this is guarded by env->allow_ptr_leaks, I can't see any reason _not_
to let people try fancy tricks with the low bits of pointers.
I agree ptr & 0x40 is a crazy thing with no imaginable use case, but...
"Unix was not designed to stop its users from doing stupid things, as that
would also stop them from doing clever things." ;-)
-Ed
^ permalink raw reply
* Using HTB and FQ on the same interface
From: Alexandre Ferrieux @ 2017-06-08 17:22 UTC (permalink / raw)
To: netdev
Hello, I need to use simultaneously on the same interface the classful
qdisc HTB and the classless qdisc FQ. The rationale is:
- I need to send properly shaped UDP streams to a few remote IP
addresses. For this I'm using htb classes and u32 filters.
- for a few other remote peers I need FQ to be available since I
activated BBR congestion control (ip route change ... congctl bbr)
Questions:
(1) can this be done at all ?
(2) if yes, what are the recommended hierarchy and parameters so
that things go smoothly in the limit of low traffic (neither qdisc
needing a significant fraction of the 1Gbps line rate) ?
I was thinking about
# HTB as root
root@foo:~# tc qdisc add dev eth1 handle 1: root htb
# FQ in a line-rate class
root@foo:~# tc class add dev eth1 parent 1: classid 1:42 htb rate 1gbit
root@foo:~# tc qdisc add dev eth1 parent 1:42 fq
# "n" HTB classes with appropriate rates and individual u32 filters
root@foo:~# tc class add dev eth1 parent 1: classid $id htb rate $rate
root@foo:~# tc filter add dev eth1 parent 1: protocol ip prio
$prio u32 match ip protocol 17 0xff match ip dst $IP/32 flowid $id
Thanks for amending.
(3) In detail, how do the models interact (the token buckets on one
side, and the regular interval timers on the other) ? What happens to
subsequent packets in a paced FQ flow if some get delayed due to
contention: does FQ "catch up" or do packets get offset in the future
?
Thanks in advance,
-Alex
^ permalink raw reply
* Re: [patch iproute2/net-next] tc: add support for TRAP action
From: Jiri Benc @ 2017-06-08 17:26 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, jhs, xiyou.wangcong, edumazet, alexander.h.duyck,
stephen, daniel, mlxsw
In-Reply-To: <20170605143945.7094-1-jiri@resnulli.us>
On Mon, 5 Jun 2017 16:39:45 +0200, Jiri Pirko wrote:
> From: Jiri Pirko <jiri@mellanox.com>
>
> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
> ---
> include/linux/pkt_cls.h | 5 +++++
> tc/tc_util.c | 3 +++
> 2 files changed, 8 insertions(+)
No documentation again. Please add the description of the new action to
a man page.
Jiri
^ permalink raw reply
* ARM GLX Khadas VIM Pro - Ethernet detected as only 10Mbps and stalled after some traffic
From: crow @ 2017-06-08 17:30 UTC (permalink / raw)
To: netdev, linux-amlogic
Hi,
I have here two problems with Khadas VIM Pro device and Ethernet.
1) sometimes with the Kernel Linux 4.12-rc4 the Ethernet link is Up
but only 10Mbps.
Don't work (either SSH to device nor over serial console to ping out)
meson8b-dwmac c9410000.ethernet eth0: Link is Up - 10Mbps/Half - flow
control off
Works (if I do ifconfig eth0 down / up):
meson8b-dwmac c9410000.ethernet eth0: Link is Down
meson8b-dwmac c9410000.ethernet eth0: Link is Up - 100Mbps/Full - flow
control off
Whole log could be found in [0].
2) if downloading an amount of data while connected to device over
SSH, connection will stall and after some minutes SSH session would be
disconnected. Nothing is written in dmesg and ethtool shows me same
values before when Ethernet was working, and after when connection
stall. Whole log can be found in [1]
SSH to device (OK)
-> Cloning linux git repo...
Cloning into bare repository '/opt/mmcblk1/linux-aarch64-git/linux'...
remote: Counting objects: 5399033, done.
remote: Compressing objects: 100% (1495/1495), done.
Receiving objects: 3% (161971/5399033), 73.20 MiB | 6.19 MiB/s
here the download stalled and SSH connection also stalled but not disconnected
# ethtool eth0
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Link partner advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Link partner advertised pause frame use: No
Link partner advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: MII
PHYAD: 8
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: ug
Wake-on: d
Current message level: 0x0000003f (63)
drv probe link timer ifdown ifup
Link detected: yes
#
after 2 min SSH connection disconnected
over serial console:
# ping -c3 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
>From 10.8.8.6 icmp_seq=1 Destination Host Unreachable
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 0 received, +1 errors, 100% packet loss, time 2060ms
pipe 3
#
nothing in dmesg or in journalctl
also here is helps only to take port down and again up. restarting
networking services fails "timed out".
Regards,
[0] https://defuse.ca/b/jqXqW9Ip
[1] https://defuse.ca/b/bJLOAuX6
^ permalink raw reply
* [PATCH] net: vrf: Make add_fib_rules per network namespace flag
From: David Ahern @ 2017-06-08 17:31 UTC (permalink / raw)
To: netdev; +Cc: petrm, David Ahern
Commit 1aa6c4f6b8cd8 ("net: vrf: Add l3mdev rules on first device create")
adds the l3mdev FIB rule the first time a VRF device is created. However,
it only creates the rule once and only in the namespace the first device
is created - which may not be init_net. Fix by using the net_generic
capability to make the add_fib_rules flag per network namespace.
Fixes: 1aa6c4f6b8cd8 ("net: vrf: Add l3mdev rules on first device create")
Reported-by: Petr Machata <petrm@mellanox.com>
Signed-off-by: David Ahern <dsahern@gmail.com>
---
drivers/net/vrf.c | 36 ++++++++++++++++++++++++++++++++----
1 file changed, 32 insertions(+), 4 deletions(-)
diff --git a/drivers/net/vrf.c b/drivers/net/vrf.c
index db882493875c..73b36f579867 100644
--- a/drivers/net/vrf.c
+++ b/drivers/net/vrf.c
@@ -36,12 +36,14 @@
#include <net/addrconf.h>
#include <net/l3mdev.h>
#include <net/fib_rules.h>
+#include <net/netns/generic.h>
#define DRV_NAME "vrf"
#define DRV_VERSION "1.0"
#define FIB_RULE_PREF 1000 /* default preference for FIB rules */
-static bool add_fib_rules = true;
+
+static unsigned int vrf_net_id;
struct net_vrf {
struct rtable __rcu *rth;
@@ -1394,6 +1396,8 @@ static int vrf_newlink(struct net *src_net, struct net_device *dev,
struct nlattr *tb[], struct nlattr *data[])
{
struct net_vrf *vrf = netdev_priv(dev);
+ bool *add_fib_rules;
+ struct net *net;
int err;
if (!data || !data[IFLA_VRF_TABLE])
@@ -1409,13 +1413,15 @@ static int vrf_newlink(struct net *src_net, struct net_device *dev,
if (err)
goto out;
- if (add_fib_rules) {
+ net = dev_net(dev);
+ add_fib_rules = net_generic(net, vrf_net_id);
+ if (*add_fib_rules) {
err = vrf_add_fib_rules(dev);
if (err) {
unregister_netdevice(dev);
goto out;
}
- add_fib_rules = false;
+ *add_fib_rules = false;
}
out:
@@ -1498,16 +1504,38 @@ static struct notifier_block vrf_notifier_block __read_mostly = {
.notifier_call = vrf_device_event,
};
+/* Initialize per network namespace state */
+static int __net_init vrf_netns_init(struct net *net)
+{
+ bool *add_fib_rules = net_generic(net, vrf_net_id);
+
+ *add_fib_rules = true;
+
+ return 0;
+}
+
+static struct pernet_operations vrf_net_ops __net_initdata = {
+ .init = vrf_netns_init,
+ .id = &vrf_net_id,
+ .size = sizeof(bool),
+};
+
static int __init vrf_init_module(void)
{
int rc;
register_netdevice_notifier(&vrf_notifier_block);
- rc = rtnl_link_register(&vrf_link_ops);
+ rc = register_pernet_subsys(&vrf_net_ops);
if (rc < 0)
goto error;
+ rc = rtnl_link_register(&vrf_link_ops);
+ if (rc < 0) {
+ unregister_pernet_subsys(&vrf_net_ops);
+ goto error;
+ }
+
return 0;
error:
--
2.11.0 (Apple Git-81)
^ permalink raw reply related
* (unknown),
From: kirola @ 2017-06-08 17:59 UTC (permalink / raw)
To: netdev
[-- Attachment #1: 87350019.zip --]
[-- Type: application/zip, Size: 3183 bytes --]
^ permalink raw reply
* Re: [PATCH iproute] tc: flower: add support for matching on ip tos and ttl
From: Stephen Hemminger @ 2017-06-08 18:01 UTC (permalink / raw)
To: Or Gerlitz; +Cc: netdev, Roi Dayan, Paul Blakey
In-Reply-To: <1496837874-9284-1-git-send-email-ogerlitz@mellanox.com>
On Wed, 7 Jun 2017 15:17:54 +0300
Or Gerlitz <ogerlitz@mellanox.com> wrote:
> Allow users to set flower classifier filter rules which
> include matches for ip tos and ttl.
>
> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
> Reviewed-by: Jiri Pirko <jiri@mellanox.com>
Applied to net-next
^ permalink raw reply
* [PATCH 1/2 net-next] net: stmmac: fix RX routing function name
From: Joao Pinto @ 2017-06-08 18:02 UTC (permalink / raw)
To: davem; +Cc: netdev, peppe.cavallaro, alexandre.torgue, Joao Pinto
This patch fixes the RX packet routing function name in dwmac4_core.
It also calls the correct dwmac4_core callback for the routing
configuration purpose.
Signed-off-by: Joao Pinto <jpinto@synopsys.com>
---
drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 6 +++---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
index f233bf8..0df038f 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
@@ -111,7 +111,7 @@ static void dwmac4_tx_queue_priority(struct mac_device_info *hw,
writel(value, ioaddr + base_register);
}
-static void dwmac4_tx_queue_routing(struct mac_device_info *hw,
+static void dwmac4_rx_queue_routing(struct mac_device_info *hw,
u8 packet, u32 queue)
{
void __iomem *ioaddr = hw->pcsr;
@@ -676,7 +676,7 @@ static const struct stmmac_ops dwmac4_ops = {
.rx_queue_enable = dwmac4_rx_queue_enable,
.rx_queue_prio = dwmac4_rx_queue_priority,
.tx_queue_prio = dwmac4_tx_queue_priority,
- .rx_queue_routing = dwmac4_tx_queue_routing,
+ .rx_queue_routing = dwmac4_rx_queue_routing,
.prog_mtl_rx_algorithms = dwmac4_prog_mtl_rx_algorithms,
.prog_mtl_tx_algorithms = dwmac4_prog_mtl_tx_algorithms,
.set_mtl_tx_queue_weight = dwmac4_set_mtl_tx_queue_weight,
@@ -707,7 +707,7 @@ static const struct stmmac_ops dwmac410_ops = {
.rx_queue_enable = dwmac4_rx_queue_enable,
.rx_queue_prio = dwmac4_rx_queue_priority,
.tx_queue_prio = dwmac4_tx_queue_priority,
- .rx_queue_routing = dwmac4_tx_queue_routing,
+ .rx_queue_routing = dwmac4_rx_queue_routing,
.prog_mtl_rx_algorithms = dwmac4_prog_mtl_rx_algorithms,
.prog_mtl_tx_algorithms = dwmac4_prog_mtl_tx_algorithms,
.set_mtl_tx_queue_weight = dwmac4_set_mtl_tx_queue_weight,
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index f446f36..9ca3a2d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -2353,7 +2353,7 @@ static void stmmac_mac_config_rx_queues_routing(struct stmmac_priv *priv)
continue;
packet = priv->plat->rx_queues_cfg[queue].pkt_route;
- priv->hw->mac->rx_queue_prio(priv->hw, packet, queue);
+ priv->hw->mac->rx_queue_routing(priv->hw, packet, queue);
}
}
--
2.9.3
^ permalink raw reply related
* [PATCH 2/2 net-next] net: stmmac: Improve documentation on AVB parameters
From: Joao Pinto @ 2017-06-08 18:02 UTC (permalink / raw)
To: davem; +Cc: netdev, peppe.cavallaro, alexandre.torgue, Joao Pinto
In-Reply-To: <014297b3b5a1654eda19f099082d04b79a98b16a.1496944749.git.jpinto@synopsys.com>
This patch fixes the description of the DT AVB parameters and gives
an accurate example. It was also included the base values that were
used to get the example' CBS paremeter values.
Signed-off-by: Joao Pinto <jpinto@synopsys.com>
---
Documentation/devicetree/bindings/net/stmmac.txt | 24 ++++++++++++++++--------
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/stmmac.txt b/Documentation/devicetree/bindings/net/stmmac.txt
index c3a7be6..707426d 100644
--- a/Documentation/devicetree/bindings/net/stmmac.txt
+++ b/Documentation/devicetree/bindings/net/stmmac.txt
@@ -109,10 +109,10 @@ Optional properties:
[Attention] Queue 0 is reserved for legacy traffic
and so no AVB is available in this queue.
- Configure Credit Base Shaper (if AVB Mode selected):
- - snps,send_slope: enable Low Power Interface
- - snps,idle_slope: unlock on WoL
- - snps,high_credit: max write outstanding req. limit
- - snps,low_credit: max read outstanding req. limit
+ - snps,send_slope: Send Slope Credit value
+ - snps,idle_slope: Idle Slope Credit value
+ - snps,high_credit: High Credit value
+ - snps,low_credit: Low Credit value
- snps,priority: TX queue priority (Range: 0x0 to 0xF)
Examples:
@@ -143,10 +143,18 @@ Examples:
queue1 {
snps,avb-algorithm;
- snps,send_slope = <0x1000>;
- snps,idle_slope = <0x1000>;
- snps,high_credit = <0x3E800>;
- snps,low_credit = <0xFFC18000>;
+ /*
+ * Example AVB parameters based on:
+ * Allocated Bandwidth: 40%
+ * Maximum Frame size: 1000 bytes
+ * Maximum Interference size: 1500 bytes
+ * Port Transmit Rate: 8
+ * Scaling Factor: 1024
+ */
+ snps,idle_slope = <0xCCC>;
+ snps,send_slope = <0x1333>;
+ snps,high_credit = <0x4B0000>;
+ snps,low_credit = <0xFFB50000>;
snps,priority = <0x1>;
};
};
--
2.9.3
^ permalink raw reply related
* Re: [patch iproute2/net-next] tc: add support for TRAP action
From: Stephen Hemminger @ 2017-06-08 18:03 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, jhs, xiyou.wangcong, edumazet, alexander.h.duyck,
daniel, mlxsw
In-Reply-To: <20170605143945.7094-1-jiri@resnulli.us>
On Mon, 5 Jun 2017 16:39:45 +0200
Jiri Pirko <jiri@resnulli.us> wrote:
> From: Jiri Pirko <jiri@mellanox.com>
>
> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Applied to net-next
^ permalink raw reply
* Re: [PATCH net-next v2 6/6] vxlan: allow multiple VXLANs with same VNI for IPv6 link-local addresses
From: Matthias Schiffer @ 2017-06-08 18:05 UTC (permalink / raw)
To: Stephen Hemminger
Cc: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA,
roopa-qUQiAmfTcIp+XZJcv9eMoEEOCMrvLtNR,
jbenc-H+wXaHxf7aLQT0dZR+AlfA, aduyck-nYU0QVwCCFFWk0Htik3J/w,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <3c054ae3-ec68-ab20-0928-81e313a53cde-Nyw9WiXk/RKXhJHkyCwd5uTW4wlIGRCZ@public.gmane.org>
[-- Attachment #1.1.1: Type: text/plain, Size: 2725 bytes --]
On 04/16/2017 05:15 PM, Matthias Schiffer wrote:
> On 04/14/2017 07:38 PM, Stephen Hemminger wrote:
>> On Fri, 14 Apr 2017 18:44:46 +0200
>> Matthias Schiffer <mschiffer-Nyw9WiXk/RKXhJHkyCwd5uTW4wlIGRCZ@public.gmane.org> wrote:
>>
>>> As link-local addresses are only valid for a single interface, we can allow
>>> to use the same VNI for multiple independent VXLANs, as long as the used
>>> interfaces are distinct. This way, VXLANs can always be used as a drop-in
>>> replacement for VLANs with greater ID space.
>>>
>>> This also extends VNI lookup to respect the ifindex when link-local IPv6
>>> addresses are used, so using the same VNI on multiple interfaces can
>>> actually work.
>>>
>>> Signed-off-by: Matthias Schiffer <mschiffer-Nyw9WiXk/RKXhJHkyCwd5uTW4wlIGRCZ@public.gmane.org>
>>
>> Why does this have to be IPv6 specific?
>
> I'm not familar with IPv4 link-local addresses and how route lookup works
> for them. vxlan_get_route() sets flowi4_oif to the outgoing interface; does
> __ip_route_output_key_hash() do the right thing for link-local addresses
> when such addresses are used on multiple interfaces? I see some special
> casing for multicast destinations, but none for link-local ones.
>
Getting back to this (sorry for the delay, I got caught up in other
projects), I'm seeing the following pros and cons regarding the support of
VXLAN over IPv4 link-local addresses:
+ There should be no technical reason not to support it; as everything is
in the kernel, the usual problems with IPv4 LL (userspace APIs not
supporting passing a scope ID as part of the IP address) don't apply here
+ The code needed to support IPv4 LL should be easy to add
- IPv4 LL semantics aren't as well-defined as for IPv6. While IPv4 LL
addresses are usually in the 169.254.x.y range, the Linux kernel allows
setting the address scope independently of the range for IPv4. In contrast
to this, we need to judge the validity of the configuration based on
syntactic properties of the IP addresses (at least if we don't want to add
a lot of more compexity to the validation, and probably other parts of the
code.) Generally, code that checks for the 169.254.x.y range is uncommon in
the kernel (I think I only found a single instance, somewhere in the SCTP
implementation.)
- IPv4 LL addresses are mostly used for zeroconf; I don't really see a
usecase for zeroconf addresses + VXLANs
- Personally, I have no interest in IPv4
I probably forgot a few more arguments... All in all, I'd like the VXLAN
maintainers to decide if we do want IPv4 LL support or not, and if the
verdict is to support it, I'll implement it in the next revision of my
patchset.
Matthias
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [PATCH] cpsw: cpts: enable HWTSTAMP_FILTER_PTP_V1_L4_EVENT filter
From: David Miller @ 2017-06-08 18:10 UTC (permalink / raw)
To: grygorii.strashko; +Cc: netdev, nsekhar, linux-kernel, linux-omap
In-Reply-To: <ea451242-46f4-5d61-a157-2dfb6b86f684@ti.com>
From: Grygorii Strashko <grygorii.strashko@ti.com>
Date: Thu, 8 Jun 2017 11:40:44 -0500
> Hi David,
>
> On 06/08/2017 08:52 AM, David Miller wrote:
>> These two patches do not apply cleanly to my net GIT tree, please
>> respin.
>>
>
> I did it on top of net-next as there some conflicts,
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
>
> I've just re-checked and both can be applied with no issues on top of
> net-next.
>
> Sorry for inconvenience.
You should mention explicitly the tree your patches are targetting
in your Subject line in order to avoid this problem, like
Subject: [PATCH net-next] ...
Please resubmit your patches with proper Subject lines.
Thank you.
^ permalink raw reply
* Re: [patch net-next v2 00/19] Remove support from bridge bypass for mlxsw/rocker drivers
From: David Miller @ 2017-06-08 18:17 UTC (permalink / raw)
To: jiri; +Cc: netdev, idosch, arkadis, mlxsw, roopa, stephen, ivecera, nikolay
In-Reply-To: <20170608064428.4785-1-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Thu, 8 Jun 2017 08:44:09 +0200
> Currently setting bridge port attributes and adding FDBs are done via
> setting the SELF flag which implies unconsistent offloading model. This
> patch-set fixes this behavior by making the bridge and drivers which are
> using it to be totally in sync.
>
> This implies several changes:
> - Offloading bridge flags from the bridge code.
> - Sending notification about FDB add/del to the software bridge in a
> similiar way it is done for the hardware externally learned FDBs.
>
> By making the offloading model more consistent a cleanup is done in
> the drivers supporting it. This is done in order to remove un-needed
> logic related to dump operation which is redundant.
>
> First add missing functionality to bridge, then clean up the mlxsw/rocker
> drivers.
> ---
> v1->v2
> - Move bridge-switchdev related stuff to br_switchdev.c as suggested by Nik
Series applied.
I really appreciate how you split these changes up to make them easier
to review.
Thanks.
^ permalink raw reply
* Re: [PATCH net] ipv4: igmp: fix a use after free
From: Xin Long @ 2017-06-08 18:22 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Andrey Konovalov, David S. Miller, netdev
In-Reply-To: <1496929425.736.73.camel@edumazet-glaptop3.roam.corp.google.com>
On Thu, Jun 8, 2017 at 9:43 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> Andrey reported a use-after-free in add_grec(), courtesy of syzkaller.
>
> Problem here is that igmp_stop_timer() uses a del_timer(), so we can not
> guarantee that another cpu is not servicing the timer.
>
> Therefore, if igmp_group_dropped() call from ip_mc_dec_group() is
> immediately followed by ip_mc_clear_src(), ip_mc_clear_src() might free
> memory that could be used by the other cpu servicing the timer.
>
> To fix this issue, we should defer the memory freeing
> (ip_mc_clear_src()) to the point all references to (struct
> ip_mc_list)->refcnt have been released.
> This happens in ip_ma_put()
>
>
> ==================================================================
> BUG: KASAN: use-after-free in add_grec+0x101e/0x1090 net/ipv4/igmp.c:473
> Read of size 8 at addr ffff88003053c1a0 by task swapper/0/0
>
> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.12.0-rc3+ #370
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> Call Trace:
> <IRQ>
> __dump_stack lib/dump_stack.c:16 [inline]
> dump_stack+0x292/0x395 lib/dump_stack.c:52
> print_address_description+0x73/0x280 mm/kasan/report.c:252
> kasan_report_error mm/kasan/report.c:351 [inline]
> kasan_report+0x22b/0x340 mm/kasan/report.c:408
> __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:429
> add_grec+0x101e/0x1090 net/ipv4/igmp.c:473
> igmpv3_send_cr net/ipv4/igmp.c:663 [inline]
> igmp_ifc_timer_expire+0x46d/0xa80 net/ipv4/igmp.c:768
the call trace is igmp_ifc_timer_expire -> igmpv3_send_cr -> add_grec
and the timer should be in_dev->mr_ifc_timer.
but igmp_stop_timer you mentioned is used to stop im->timer
It's possible that ip_mc_clear_src is done in ip_ma_put()
while igmp_ifc_timer_expire is still using ip_mc_list under
rcu_read_lock(). no ?
> IPVS: length: 51 != 8
> call_timer_fn+0x23f/0x800 kernel/time/timer.c:1268
> expire_timers kernel/time/timer.c:1307 [inline]
> __run_timers+0x94e/0xcd0 kernel/time/timer.c:1601
> run_timer_softirq+0x21/0x80 kernel/time/timer.c:1614
> __do_softirq+0x2fb/0xb99 kernel/softirq.c:284
> invoke_softirq kernel/softirq.c:364 [inline]
> irq_exit+0x19e/0x1d0 kernel/softirq.c:405
> exiting_irq arch/x86/include/asm/apic.h:652 [inline]
> smp_apic_timer_interrupt+0x76/0xa0 arch/x86/kernel/apic/apic.c:966
> apic_timer_interrupt+0x93/0xa0 arch/x86/entry/entry_64.S:481
> RIP: 0010:native_safe_halt+0x6/0x10 arch/x86/include/asm/irqflags.h:53
> RSP: 0018:ffffffff85a079a8 EFLAGS: 00000282 ORIG_RAX: ffffffffffffff10
> RAX: dffffc0000000020 RBX: 1ffffffff0b40f38 RCX: 0000000000000000
> RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffffff85a2a9e4
> RBP: ffffffff85a079a8 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000000 R12: dffffc0000000000
> R13: ffffffff85a07a60 R14: ffffffff86171338 R15: 1ffffffff0b40f5b
> </IRQ>
> arch_safe_halt arch/x86/include/asm/paravirt.h:98 [inline]
> default_idle+0x8f/0x440 arch/x86/kernel/process.c:341
> arch_cpu_idle+0xa/0x10 arch/x86/kernel/process.c:332
> default_idle_call+0x36/0x60 kernel/sched/idle.c:98
> cpuidle_idle_call kernel/sched/idle.c:156 [inline]
> do_idle+0x348/0x420 kernel/sched/idle.c:245
> cpu_startup_entry+0x18/0x20 kernel/sched/idle.c:350
> rest_init+0x18d/0x1a0 init/main.c:415
> start_kernel+0x747/0x779 init/main.c:679
> x86_64_start_reservations+0x2a/0x2c arch/x86/kernel/head64.c:196
> x86_64_start_kernel+0x132/0x141 arch/x86/kernel/head64.c:177
> secondary_startup_64+0x9f/0x9f arch/x86/kernel/head_64.S:304
>
> Allocated by task 30543:
> save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
> save_stack+0x43/0xd0 mm/kasan/kasan.c:513
> set_track mm/kasan/kasan.c:525 [inline]
> kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:617
> kmem_cache_alloc_trace+0x82/0x270 mm/slub.c:2745
> kmalloc include/linux/slab.h:492 [inline]
> kzalloc include/linux/slab.h:665 [inline]
> ip_mc_add1_src net/ipv4/igmp.c:1909 [inline]
> ip_mc_add_src+0x6cd/0x1020 net/ipv4/igmp.c:2033
> ip_mc_msfilter+0x5e5/0xcf0 net/ipv4/igmp.c:2403
> do_ip_setsockopt.isra.12+0x2d47/0x38c0 net/ipv4/ip_sockglue.c:959
> ip_setsockopt+0x3a/0xb0 net/ipv4/ip_sockglue.c:1256
> tcp_setsockopt+0x82/0xd0 net/ipv4/tcp.c:2740
> sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2844
> SYSC_setsockopt net/socket.c:1798 [inline]
> SyS_setsockopt+0x270/0x3a0 net/socket.c:1777
> entry_SYSCALL_64_fastpath+0x1f/0xbe
>
> Freed by task 30543:
> save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
> save_stack+0x43/0xd0 mm/kasan/kasan.c:513
> set_track mm/kasan/kasan.c:525 [inline]
> kasan_slab_free+0x72/0xc0 mm/kasan/kasan.c:590
> slab_free_hook mm/slub.c:1357 [inline]
> slab_free_freelist_hook mm/slub.c:1379 [inline]
> slab_free mm/slub.c:2961 [inline]
> kfree+0xe8/0x2b0 mm/slub.c:3882
> ip_mc_clear_src+0x69/0x1c0 net/ipv4/igmp.c:2078
> ip_mc_dec_group+0x19a/0x470 net/ipv4/igmp.c:1618
> ip_mc_drop_socket+0x145/0x230 net/ipv4/igmp.c:2609
> inet_release+0x4e/0x1c0 net/ipv4/af_inet.c:411
> sock_release+0x8d/0x1e0 net/socket.c:597
> sock_close+0x16/0x20 net/socket.c:1072
> __fput+0x332/0x7f0 fs/file_table.c:209
> ____fput+0x15/0x20 fs/file_table.c:245
> task_work_run+0x19b/0x270 kernel/task_work.c:116
> exit_task_work include/linux/task_work.h:21 [inline]
> do_exit+0x18a3/0x2820 kernel/exit.c:878
> do_group_exit+0x149/0x420 kernel/exit.c:982
> get_signal+0x76d/0x1790 kernel/signal.c:2318
> do_signal+0xd2/0x2130 arch/x86/kernel/signal.c:808
> exit_to_usermode_loop+0x17a/0x210 arch/x86/entry/common.c:157
> prepare_exit_to_usermode arch/x86/entry/common.c:194 [inline]
> syscall_return_slowpath+0x3ba/0x410 arch/x86/entry/common.c:263
> entry_SYSCALL_64_fastpath+0xbc/0xbe
>
> The buggy address belongs to the object at ffff88003053c1a0
> which belongs to the cache kmalloc-64 of size 64
> The buggy address is located 0 bytes inside of
> 64-byte region [ffff88003053c1a0, ffff88003053c1e0)
> The buggy address belongs to the page:
> page:ffffea0000c14f00 count:1 mapcount:0 mapping: (null)
> index:0x0 compound_mapcount: 0
> flags: 0x100000000008100(slab|head)
> raw: 0100000000008100 0000000000000000 0000000000000000 0000000100140014
> raw: ffffea0000c2f520 ffffea0000e20aa0 ffff88003e80f740 0000000000000000
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
> ffff88003053c080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ffff88003053c100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>>ffff88003053c180: fc fc fc fc fb fb fb fb fb fb fb fb fc fc fc fc
> ^
> ffff88003053c200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ffff88003053c280: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ==================================================================
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: Andrey Konovalov <andreyknvl@google.com>
> ---
> net/ipv4/igmp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
> index 44fd86de2823dd17de16276a8ec01b190e69b8b4..f172d251c5f2cda8fc8bedd65fa16cdfe33a4d40 100644
> --- a/net/ipv4/igmp.c
> +++ b/net/ipv4/igmp.c
> @@ -174,6 +174,7 @@ static int ip_mc_add_src(struct in_device *in_dev, __be32 *pmca, int sfmode,
> static void ip_ma_put(struct ip_mc_list *im)
> {
> if (atomic_dec_and_test(&im->refcnt)) {
> + ip_mc_clear_src(im);
> in_dev_put(im->interface);
> kfree_rcu(im, rcu);
> }
> @@ -1615,7 +1616,6 @@ void ip_mc_dec_group(struct in_device *in_dev, __be32 addr)
> *ip = i->next_rcu;
> in_dev->mc_count--;
> igmp_group_dropped(i);
> - ip_mc_clear_src(i);
>
> if (!in_dev->dead)
> ip_rt_multicast_event(in_dev);
>
>
>
^ permalink raw reply
* Re: [patch net-next 0/3] mlxsw: Remove compatibility with old firmware
From: David Miller @ 2017-06-08 18:34 UTC (permalink / raw)
To: jiri; +Cc: netdev, idosch, mlxsw
In-Reply-To: <20170608064745.4900-1-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Thu, 8 Jun 2017 08:47:42 +0200
> Up until recently we couldn't enforce a minimal firmware version, which
> forced us to be compatible with old firmware versions. This patchset
> removes this code and simplifies the driver.
Series applied, thanks Jiri.
^ permalink raw reply
* Re: [PATCH net-next v2] net: ipmr: add getlink support
From: David Miller @ 2017-06-08 18:39 UTC (permalink / raw)
To: nikolay; +Cc: netdev, roopa, sharpd
In-Reply-To: <1496847752-6935-1-git-send-email-nikolay@cumulusnetworks.com>
From: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Date: Wed, 7 Jun 2017 18:02:32 +0300
> Currently there's no way to dump the VIF table for an ipmr table other
> than the default (via proc). This is a major issue when debugging ipmr
> issues and in general it is good to know which interfaces are
> configured. This patch adds support for RTM_GETLINK for the ipmr family
> so we can dump the VIF table and the ipmr table's current config for
> each table. We're protected by rtnl so no need to acquire RCU or
> mrt_lock.
>
> Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
> ---
> v2: use netlink attributes for all mrtable and vif fields, and set message
> type to RTM_NEWLINK
>
> The plan is to add full netlink control to ipmr via new/set/dellink later.
> Also this would allow us to dump any number of VIFs in the future when we
> remove the VIF device limit.
Applied, thanks Nikolay.
^ permalink raw reply
* Re: [RFC PATCH net-next 3/5] bpf/verifier: feed pointer-to-unknown-scalar casts into scalar ALU path
From: Alexei Starovoitov via iovisor-dev @ 2017-06-08 18:41 UTC (permalink / raw)
To: Edward Cree
Cc: Alexei Starovoitov, netdev-u79uwXL29TY76Z2rM5mHXA, iovisor-dev,
LKML, davem-fT/PcQaiUtIeIZ0/mPfg9Q
In-Reply-To: <3cca425f-5794-dddd-18a8-af5e36bb3597-s/n/eUQHGBpZroRs9YW3xA@public.gmane.org>
On Thu, Jun 08, 2017 at 06:12:39PM +0100, Edward Cree wrote:
> On 08/06/17 17:50, Alexei Starovoitov wrote:
> > On Thu, Jun 08, 2017 at 04:25:39PM +0100, Edward Cree wrote:
> >> On 08/06/17 03:35, Alexei Starovoitov wrote:
> >>> such large back and forth move doesn't help reviewing.
> >>> may be just merge it into previous patch?
> >>> Or keep that function in the right place in patch 2 already?
> >> I think 'diff' got a bit confused, and maybe with different options I could
> >> have got it to produce something more readable. But I think I will just
> >> merge this into patch 2; it's only separate because it started out as an
> >> experiment.
> > after sleeping on it I'm not sure we should be allowing such pointer
> > arithmetic. In normal C code people do fancy tricks with lower 3 bits
> > of the pointer, but in bpf code I cannot see such use case.
> > What kind of realistic code will be doing ptr & 0x40 ?
> Well, I didn't support it because I saw a use case. I supported it because
> it seemed easy to do and the code came out reasonably elegant-looking.
> Since this is guarded by env->allow_ptr_leaks, I can't see any reason _not_
> to let people try fancy tricks with the low bits of pointers.
> I agree ptr & 0x40 is a crazy thing with no imaginable use case, but...
> "Unix was not designed to stop its users from doing stupid things, as that
> would also stop them from doing clever things." ;-)
well, I agree with the philosophy :) but I also see few reasons not to allow it:
1. it immediately becomes uapi and if later we find out that it's preventing us
to do something we actually really need we'll be stuck looking for workaround
2. it's the same pruning concern. probably doesn't fully apply here, but
the reason we don't track 'if (reg == 1) ...' is if we mark that
register as known const_imm in the true branch, it will screw up
pruning quite badly. It's trivial to track and may seem useful,
but hurts instead.
^ permalink raw reply
* Re: [patch iproute2/net-next] tc: add support for TRAP action
From: Jiri Pirko @ 2017-06-08 18:41 UTC (permalink / raw)
To: Jiri Benc
Cc: netdev, davem, jhs, xiyou.wangcong, edumazet, alexander.h.duyck,
stephen, daniel, mlxsw
In-Reply-To: <20170608192612.6a9c175a@griffin>
Thu, Jun 08, 2017 at 07:26:12PM CEST, jbenc@redhat.com wrote:
>On Mon, 5 Jun 2017 16:39:45 +0200, Jiri Pirko wrote:
>> From: Jiri Pirko <jiri@mellanox.com>
>>
>> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
>> ---
>> include/linux/pkt_cls.h | 5 +++++
>> tc/tc_util.c | 3 +++
>> 2 files changed, 8 insertions(+)
>
>No documentation again. Please add the description of the new action to
>a man page.
Will do. It's on my todo list.
^ permalink raw reply
* Re: [net-next 0/2][pull request] 1GbE Intel Wired LAN Driver Updates 2017-06-07
From: David Miller @ 2017-06-08 18:41 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann, jogreene
In-Reply-To: <20170608053237.73040-1-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 7 Jun 2017 22:32:35 -0700
> This series contains a fix for e1000e and igb.
>
> Colin Ian King fixes sparse warnings in igb by making functions static.
>
> Chris Wilson provides a fix for a previous commit which is causing an
> issue during suspend "e1000e_pm_suspend()", where we need to run
> e1000e_pm_thaw() if __e1000_shutdown() is unsuccessful.
Series applied, thanks Jeff.
^ 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