* [PATCH v2 2/2] ARM: dts: Add the ethernet and ethernet PHY to the cygnus core DT.
From: Eric Anholt @ 2017-04-25 23:53 UTC (permalink / raw)
To: Florian Fainelli, Vivien Didelot, Andrew Lunn, netdev,
Rob Herring, Mark Rutland, devicetree
Cc: linux-arm-kernel, linux-kernel, bcm-kernel-feedback-list, Ray Jui,
Scott Branden, Jon Mason, Eric Anholt
In-Reply-To: <20170425235357.7690-1-eric@anholt.net>
Cygnus has a single AMAC controller connected to the B53 switch with 2
PHYs. On the BCM911360_EP platform, those two PHYs are connected to
the external ethernet jacks.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
---
v2: Call the node "switch", just call the ports "port" (suggestions by
Florian), drop max-speed on the phys (suggestion by Andrew Lunn),
call the other nodes "ethernet" and "ethernet-phy" (suggestions by
Sergei Shtylyov)
arch/arm/boot/dts/bcm-cygnus.dtsi | 58 ++++++++++++++++++++++++++++++++++
arch/arm/boot/dts/bcm911360_entphn.dts | 8 +++++
2 files changed, 66 insertions(+)
diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi b/arch/arm/boot/dts/bcm-cygnus.dtsi
index 009f1346b817..9fd89be0f5e0 100644
--- a/arch/arm/boot/dts/bcm-cygnus.dtsi
+++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
@@ -142,6 +142,54 @@
interrupts = <0>;
};
+ mdio: mdio@18002000 {
+ compatible = "brcm,iproc-mdio";
+ reg = <0x18002000 0x8>;
+ #size-cells = <1>;
+ #address-cells = <0>;
+
+ gphy0: ethernet-phy@0 {
+ reg = <0>;
+ };
+
+ gphy1: ethernet-phy@1 {
+ reg = <1>;
+ };
+ };
+
+ switch: switch@18007000 {
+ compatible = "brcm,bcm11360-srab", "brcm,cygnus-srab";
+ reg = <0x18007000 0x1000>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ phy-handle = <&gphy0>;
+ phy-mode = "rgmii";
+ };
+
+ port@1 {
+ reg = <1>;
+ phy-handle = <&gphy1>;
+ phy-mode = "rgmii";
+ };
+
+ port@8 {
+ reg = <8>;
+ label = "cpu";
+ ethernet = <ð0>;
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+ };
+ };
+ };
+
i2c0: i2c@18008000 {
compatible = "brcm,cygnus-iproc-i2c", "brcm,iproc-i2c";
reg = <0x18008000 0x100>;
@@ -295,6 +343,16 @@
status = "disabled";
};
+ eth0: ethernet@18042000 {
+ compatible = "brcm,amac";
+ reg = <0x18042000 0x1000>,
+ <0x18110000 0x1000>;
+ reg-names = "amac_base", "idm_base";
+ interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>;
+ max-speed = <1000>;
+ status = "disabled";
+ };
+
nand: nand@18046000 {
compatible = "brcm,nand-iproc", "brcm,brcmnand-v6.1";
reg = <0x18046000 0x600>, <0xf8105408 0x600>,
diff --git a/arch/arm/boot/dts/bcm911360_entphn.dts b/arch/arm/boot/dts/bcm911360_entphn.dts
index 8b3800f46288..e037dea63f4a 100644
--- a/arch/arm/boot/dts/bcm911360_entphn.dts
+++ b/arch/arm/boot/dts/bcm911360_entphn.dts
@@ -57,6 +57,14 @@
};
};
+ð0 {
+ status = "okay";
+};
+
+&switch {
+ status = "okay";
+};
+
&uart3 {
status = "okay";
};
--
2.11.0
^ permalink raw reply related
* [PATCH v2 1/2] net: dsa: b53: Add compatible strings for the Cygnus-family BCM11360.
From: Eric Anholt @ 2017-04-25 23:53 UTC (permalink / raw)
To: Florian Fainelli, Vivien Didelot, Andrew Lunn, netdev,
Rob Herring, Mark Rutland, devicetree
Cc: Scott Branden, Jon Mason, Ray Jui, linux-kernel, Eric Anholt,
bcm-kernel-feedback-list, linux-arm-kernel
Cygnus is a small family of SoCs, of which we currently have
devicetree for BCM11360 and BCM58300. The 11360's B53 is mostly the
same as 58xx, just requiring a tiny bit of setup that was previously
missing.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
---
v2: Reorder the entry in the docs (suggestion by Scott Branden), add
missing '"'
Documentation/devicetree/bindings/net/dsa/b53.txt | 3 +++
drivers/net/dsa/b53/b53_srab.c | 2 ++
2 files changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/dsa/b53.txt b/Documentation/devicetree/bindings/net/dsa/b53.txt
index d6c6e41648d4..eb679e92d525 100644
--- a/Documentation/devicetree/bindings/net/dsa/b53.txt
+++ b/Documentation/devicetree/bindings/net/dsa/b53.txt
@@ -13,6 +13,9 @@ Required properties:
"brcm,bcm5397"
"brcm,bcm5398"
+ For the BCM11360 SoC, must be:
+ "brcm,bcm11360-srab" and the mandatory "brcm,cygnus-srab" string
+
For the BCM5310x SoCs with an integrated switch, must be one of:
"brcm,bcm53010-srab"
"brcm,bcm53011-srab"
diff --git a/drivers/net/dsa/b53/b53_srab.c b/drivers/net/dsa/b53/b53_srab.c
index 8a62b6a69703..c37ffd1b6833 100644
--- a/drivers/net/dsa/b53/b53_srab.c
+++ b/drivers/net/dsa/b53/b53_srab.c
@@ -364,6 +364,7 @@ static const struct of_device_id b53_srab_of_match[] = {
{ .compatible = "brcm,bcm53018-srab" },
{ .compatible = "brcm,bcm53019-srab" },
{ .compatible = "brcm,bcm5301x-srab" },
+ { .compatible = "brcm,bcm11360-srab", .data = (void *)BCM58XX_DEVICE_ID },
{ .compatible = "brcm,bcm58522-srab", .data = (void *)BCM58XX_DEVICE_ID },
{ .compatible = "brcm,bcm58525-srab", .data = (void *)BCM58XX_DEVICE_ID },
{ .compatible = "brcm,bcm58535-srab", .data = (void *)BCM58XX_DEVICE_ID },
@@ -371,6 +372,7 @@ static const struct of_device_id b53_srab_of_match[] = {
{ .compatible = "brcm,bcm58623-srab", .data = (void *)BCM58XX_DEVICE_ID },
{ .compatible = "brcm,bcm58625-srab", .data = (void *)BCM58XX_DEVICE_ID },
{ .compatible = "brcm,bcm88312-srab", .data = (void *)BCM58XX_DEVICE_ID },
+ { .compatible = "brcm,cygnus-srab", .data = (void *)BCM58XX_DEVICE_ID },
{ .compatible = "brcm,nsp-srab", .data = (void *)BCM58XX_DEVICE_ID },
{ /* sentinel */ },
};
--
2.11.0
^ permalink raw reply related
* Re: [PATCH] IB/IPoIB: Check the headroom size
From: Or Gerlitz @ 2017-04-25 21:50 UTC (permalink / raw)
To: Doug Ledford
Cc: Erez Shitrit, Paolo Abeni, Honggang LI, Erez Shitrit,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Linux Netdev List, David Miller
In-Reply-To: <1493134815.3041.72.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On Tue, Apr 25, 2017 at 6:40 PM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> On Tue, 2017-04-25 at 17:39 +0300, Or Gerlitz wrote:
>> If got you right, Paolo's commit introduced a regression, so we (I
>> guess you and Paolo) need to either solve it or we (community)
>> should consider a revert, please suggest.
> [...] So, this issue should be
> reproducible either after Paolo's commit or with any kernel prior to
> your commit to use the skb->cb area to store the DGID, but it probably
> requires the specific series of actions in this bug to trigger it.
mmm
> A normal, clean shutdown of the interface doesn't demonstrate the issue.
so maybe @ least for the time being, we should be picking Hong's patch
with proper change log and without the giant stack dump till we have
something better. If you agree, can you do the re-write of the change
log?
Or.
>> The bug is now in stable and distro kernels, so please act.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [Patch net] ipv6: check skb->protocol before lookup for nexthop
From: Cong Wang @ 2017-04-25 21:37 UTC (permalink / raw)
To: netdev; +Cc: andreyknvl, Cong Wang, Steffen Klassert
Andrey reported a out-of-bound access in ip6_tnl_xmit(), this
is because we use an ipv4 dst in ip6_tnl_xmit() and cast an IPv4
neigh key as an IPv6 address:
neigh = dst_neigh_lookup(skb_dst(skb),
&ipv6_hdr(skb)->daddr);
if (!neigh)
goto tx_err_link_failure;
addr6 = (struct in6_addr *)&neigh->primary_key; // <=== HERE
addr_type = ipv6_addr_type(addr6);
if (addr_type == IPV6_ADDR_ANY)
addr6 = &ipv6_hdr(skb)->daddr;
memcpy(&fl6->daddr, addr6, sizeof(fl6->daddr));
Also the network header of the skb at this point should be still IPv4
for 4in6 tunnels, we shold not just use it as IPv6 header.
This patch fixes it by checking if skb->protocol is ETH_P_IPV6: if it
is, we are safe to do the nexthop lookup using skb_dst() and
ipv6_hdr(skb)->daddr; if not (aka IPv4), we have no clue about which
dest address we can pick here, we have to rely on callers to fill it
from tunnel config, so just fall to ip6_route_output() to make the
decision.
Fixes: ea3dc9601bda ("ip6_tunnel: Add support for wildcard tunnel endpoints.")
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Tested-by: Andrey Konovalov <andreyknvl@google.com>
Cc: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
---
net/ipv6/ip6_tunnel.c | 34 ++++++++++++++++++----------------
1 file changed, 18 insertions(+), 16 deletions(-)
diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index 75fac93..a9692ec 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -1037,7 +1037,7 @@ int ip6_tnl_xmit(struct sk_buff *skb, struct net_device *dev, __u8 dsfield,
struct ip6_tnl *t = netdev_priv(dev);
struct net *net = t->net;
struct net_device_stats *stats = &t->dev->stats;
- struct ipv6hdr *ipv6h = ipv6_hdr(skb);
+ struct ipv6hdr *ipv6h;
struct ipv6_tel_txoption opt;
struct dst_entry *dst = NULL, *ndst = NULL;
struct net_device *tdev;
@@ -1057,26 +1057,28 @@ int ip6_tnl_xmit(struct sk_buff *skb, struct net_device *dev, __u8 dsfield,
/* NBMA tunnel */
if (ipv6_addr_any(&t->parms.raddr)) {
- struct in6_addr *addr6;
- struct neighbour *neigh;
- int addr_type;
+ if (skb->protocol == htons(ETH_P_IPV6)) {
+ struct in6_addr *addr6;
+ struct neighbour *neigh;
+ int addr_type;
- if (!skb_dst(skb))
- goto tx_err_link_failure;
+ if (!skb_dst(skb))
+ goto tx_err_link_failure;
- neigh = dst_neigh_lookup(skb_dst(skb),
- &ipv6_hdr(skb)->daddr);
- if (!neigh)
- goto tx_err_link_failure;
+ neigh = dst_neigh_lookup(skb_dst(skb),
+ &ipv6_hdr(skb)->daddr);
+ if (!neigh)
+ goto tx_err_link_failure;
- addr6 = (struct in6_addr *)&neigh->primary_key;
- addr_type = ipv6_addr_type(addr6);
+ addr6 = (struct in6_addr *)&neigh->primary_key;
+ addr_type = ipv6_addr_type(addr6);
- if (addr_type == IPV6_ADDR_ANY)
- addr6 = &ipv6_hdr(skb)->daddr;
+ if (addr_type == IPV6_ADDR_ANY)
+ addr6 = &ipv6_hdr(skb)->daddr;
- memcpy(&fl6->daddr, addr6, sizeof(fl6->daddr));
- neigh_release(neigh);
+ memcpy(&fl6->daddr, addr6, sizeof(fl6->daddr));
+ neigh_release(neigh);
+ }
} else if (!(t->parms.flags &
(IP6_TNL_F_USE_ORIG_TCLASS | IP6_TNL_F_USE_ORIG_FWMARK))) {
/* enable the cache only only if the routing decision does
--
2.5.5
^ permalink raw reply related
* Re: [PATCH net-next 01/10] tcp: add tp->tcp_mstamp field
From: Eric Dumazet @ 2017-04-25 21:33 UTC (permalink / raw)
To: Yuchung Cheng
Cc: David S . Miller, netdev, Soheil Hassas Yeganeh, Eric Dumazet
In-Reply-To: <CAK6E8=fhzzLKiUnB73upZdUUUSZ4t6HABmM17YGyEj93jLBkMQ@mail.gmail.com>
On Tue, Apr 25, 2017 at 2:27 PM, Yuchung Cheng <ycheng@google.com> wrote:
>> + struct skb_mstamp tcp_mstamp; /* most recent packet received/sent */
> Eric: would this new stamp cover outgoing packet as well in the
> future? in the patch series seem to cover only the incoming packets.
This is the plan yes : tp->lsndtime will also be replaced for a better
TSO autodefer.
When it happens, tp->tcp_mstamp will be updated once per write episode.
And we'll remove a lot of skb_mstamp_get(&skb->skb_mstamp) calls all
over the places.
^ permalink raw reply
* Re: [PATCH net-next 01/10] tcp: add tp->tcp_mstamp field
From: Yuchung Cheng @ 2017-04-25 21:27 UTC (permalink / raw)
To: Eric Dumazet
Cc: David S . Miller, netdev, Soheil Hassas Yeganeh, Eric Dumazet
In-Reply-To: <20170425171541.3417-2-edumazet@google.com>
On Tue, Apr 25, 2017 at 10:15 AM, Eric Dumazet <edumazet@google.com> wrote:
> We want to use precise timestamps in TCP stack, but we do not
> want to call possibly expensive kernel time services too often.
>
> tp->tcp_mstamp is guaranteed to be updated once per incoming packet.
>
> We will use it in the following patches, removing specific
> skb_mstamp_get() calls, and removing ack_time from
> struct tcp_sacktag_state.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> ---
> include/linux/tcp.h | 1 +
> net/ipv4/tcp_input.c | 3 +++
> 2 files changed, 4 insertions(+)
>
> diff --git a/include/linux/tcp.h b/include/linux/tcp.h
> index cbe5b602a2d349fdeb1e878305f37b4da1e6cc86..99a22f44c32e1587a6bf4835b65c7a4314807aa8 100644
> --- a/include/linux/tcp.h
> +++ b/include/linux/tcp.h
> @@ -240,6 +240,7 @@ struct tcp_sock {
> u32 tlp_high_seq; /* snd_nxt at the time of TLP retransmit. */
>
> /* RTT measurement */
> + struct skb_mstamp tcp_mstamp; /* most recent packet received/sent */
Eric: would this new stamp cover outgoing packet as well in the
future? in the patch series seem to cover only the incoming packets.
> u32 srtt_us; /* smoothed round trip time << 3 in usecs */
> u32 mdev_us; /* medium deviation */
> u32 mdev_max_us; /* maximal mdev for the last rtt period */
> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
> index 5af2f04f885914491a7116c20056b3d2188d2d7d..bd18c65df4a9d9c2b66d8005f2cc4ff468140a73 100644
> --- a/net/ipv4/tcp_input.c
> +++ b/net/ipv4/tcp_input.c
> @@ -5362,6 +5362,7 @@ void tcp_rcv_established(struct sock *sk, struct sk_buff *skb,
> {
> struct tcp_sock *tp = tcp_sk(sk);
>
> + skb_mstamp_get(&tp->tcp_mstamp);
> if (unlikely(!sk->sk_rx_dst))
> inet_csk(sk)->icsk_af_ops->sk_rx_dst_set(sk, skb);
> /*
> @@ -5922,6 +5923,7 @@ int tcp_rcv_state_process(struct sock *sk, struct sk_buff *skb)
>
> case TCP_SYN_SENT:
> tp->rx_opt.saw_tstamp = 0;
> + skb_mstamp_get(&tp->tcp_mstamp);
> queued = tcp_rcv_synsent_state_process(sk, skb, th);
> if (queued >= 0)
> return queued;
> @@ -5933,6 +5935,7 @@ int tcp_rcv_state_process(struct sock *sk, struct sk_buff *skb)
> return 0;
> }
>
> + skb_mstamp_get(&tp->tcp_mstamp);
> tp->rx_opt.saw_tstamp = 0;
> req = tp->fastopen_rsk;
> if (req) {
> --
> 2.13.0.rc0.306.g87b477812d-goog
>
^ permalink raw reply
* Re: [PATCH v1] net: phy: fix auto-negotiation stall due to unavailable interrupt
From: Florian Fainelli @ 2017-04-25 21:07 UTC (permalink / raw)
To: David Miller, alexandre.belloni
Cc: al.kochet, netdev, linux-kernel, sergei.shtylyov, rogerq,
madalin.bucur
In-Reply-To: <20170425.162625.941066354018174414.davem@davemloft.net>
On 04/25/2017 01:26 PM, David Miller wrote:
> From: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> Date: Tue, 25 Apr 2017 22:09:11 +0200
>
>> Hi,
>>
>> On 25/04/2017 at 18:25:30 +0300, Alexander Kochetkov wrote:
>>> Hello David!
>>>
>>>> 25 апр. 2017 г., в 17:36, David Miller <davem@davemloft.net> написал(а):
>>>>
>>>> So... what are we doing here?
>>>>
>>>> My understanding is that this should fix the same problem that commit
>>>> 99f81afc139c6edd14d77a91ee91685a414a1c66 ("phy: micrel: Disable auto
>>>> negotiation on startup") fixed and that this micrel commit should thus
>>>> be reverted to improve MAC startup times which regressed.
>>>>
>>>> Florian, any guidance?
>>>
>>> Yes, this should be done.
>>>
>>> I aksed Alexandre to check if 99f81afc139c6edd14d77a91ee91685a414a1c66 ("phy: micrel: Disable auto
>>> negotiation on startup») can be reverted, and he answered what it may do that
>>> sometime this/next week.
>>>
>>
>> Yes, it can be safely reverted after Alexander's patch. I had to test on
>> v4.7 because we are not using interrupts on those boards since v4.8
>> (another issue to be fixed).
>>
>> As Florian pointed out, at the time I sent my patch, I didn't have time
>> to investigate whether this was affecting other phys, see
>> https://lkml.org/lkml/2016/2/26/766
>>
>> I can send the revert or you can do it.
>
> I can take care of it, thanks for testing.
Thanks! Can you add the following Fixes tag:
Fixes: 321beec5047a (net: phy: Use interrupts when available in NOLINK
state)
BTW, can you have the netdev patchwork instance automatically accepted
Fixes: tag sent as replies to patches? (just like Acked-by, Reviewed-by
and so on are already accepted)?
--
Florian
^ permalink raw reply
* Re: [RFC 0/4] xdp: use netlink extended ACK reporting
From: Jakub Kicinski @ 2017-04-25 21:05 UTC (permalink / raw)
To: David Ahern
Cc: netdev, davem, johannes, daniel, alexei.starovoitov, bblanco,
john.fastabend, oss-drivers
In-Reply-To: <2fbd12c0-dfed-c8df-8c74-1686565168ab@cumulusnetworks.com>
On Tue, 25 Apr 2017 08:53:35 -0600, David Ahern wrote:
> On 4/25/17 2:06 AM, Jakub Kicinski wrote:
>
> > Also - is anyone working on adding proper extack support to iproute2?
> > The code I have right now is a bit of a hack...
>
> This is what I have done:
> https://github.com/dsahern/iproute2/commits/ext-ack
>
> Basically, added the parsing code and then a new rtnl_talk_extack
> function that takes a callback to invoke with the extack data. The last
> patch (of 3) purposely breaks ip set link mtu -- sending the mtu as a
> u16 rather than a u32 just to work on the plumbing for parsing the
> returned message:
>
> $ ip li set dummy1 mtu 1490
> Error with rtnetlink attribute IFLA_MTU
>
> If an errmsg is returned it is printed as well.
Great, that's much better than what I have. It will make the XDP patch
for iproute2 pretty trivial :)
^ permalink raw reply
* Re: TCP fast open using experimental TCP option?
From: Yuchung Cheng @ 2017-04-25 21:00 UTC (permalink / raw)
To: Tom Herbert; +Cc: Linux Kernel Network Developers, Jerry Chu
In-Reply-To: <CALx6S36L4BbdcASbGNvn6mRMJDhJJ6n8y-uRTgVqteM=f6On6A@mail.gmail.com>
On Tue, Apr 25, 2017 at 12:08 PM, Tom Herbert <tom@herbertland.com> wrote:
> Looks like TCP fast open was using experimental TCP option at some. Is
> this still needed? Technically this violates usage requirements of
> experimental options. Can this be removed now since there is now an
> assigned option number for TFO?
Given that many clients (e.g. android) have not migrated to 4.0
kernels that support TFO opt 34, I would keep it for backward
compatibility for now.
>
> case TCPOPT_EXP:
> /* Fast Open option shares code 254 using a
> * 16 bits magic number.
> */
> if (opsize >= TCPOLEN_EXP_FASTOPEN_BASE &&
> get_unaligned_be16(ptr) ==
> TCPOPT_FASTOPEN_MAGIC)
> tcp_parse_fastopen_option(opsize -
> TCPOLEN_EXP_FASTOPEN_BASE,
> ptr + 2, th->syn, foc, true);
> break;
^ permalink raw reply
* Re: [RFC 0/4] xdp: use netlink extended ACK reporting
From: Jakub Kicinski @ 2017-04-25 21:00 UTC (permalink / raw)
To: Daniel Borkmann
Cc: netdev, davem, johannes, dsa, alexei.starovoitov, bblanco,
john.fastabend, kubakici, oss-drivers
In-Reply-To: <58FF1157.8030309@iogearbox.net>
On Tue, 25 Apr 2017 11:05:27 +0200, Daniel Borkmann wrote:
> > adding #defines for the most common configuration conflicts?
> > Sharing the messages verbatim between drivers could make them easier
> > to google.
>
> Makes sense, once more drivers adapt to this reporting, these
> messages could be consolidated.
There seem to be concerns about standardizing/turning the strings into
ABI. I will leave it out for now, but we can revisit later :)
^ permalink raw reply
* Re: [RFC 1/4] netlink: make extended ACK setting NULL-friendly
From: Jakub Kicinski @ 2017-04-25 20:53 UTC (permalink / raw)
To: Johannes Berg, daniel
Cc: netdev, davem, dsa, alexei.starovoitov, bblanco, john.fastabend,
kubakici, oss-drivers
In-Reply-To: <1493108014.2592.1.camel@sipsolutions.net>
On Tue, 25 Apr 2017 10:13:34 +0200, Johannes Berg wrote:
> On Tue, 2017-04-25 at 01:06 -0700, Jakub Kicinski wrote:
>
> > +#define NL_SET_ERR_MSG(extack, msg) do { \
> > + struct netlink_ext_ack *_extack = (extack); \
> > + static const char _msg[] = (msg); \
> > + \
> > + if (_extack) \
> > + _extack->_msg = _msg; \
> > + else \
> > + pr_info("%s\n", _msg); \
> > } while (0)
>
> That's a good point, I used it only for genetlink so far where it was
> guaranteed non-NULL.
>
> I'm not really sure about the printing though - I'd rather not people
> start relying on that and then we convert to have non-NULL and the
> message disappears as a result ...
Yes, agreed. I don't really know what to do about that one though :|
One could argue people may already be depending on the messages which
I'm converting in this series... On the other hand, that would
be considering logs as part of the ABI which we don't want to do.
I'm leaning towards dropping the else clause and never printing, that
will add an incentive for people to convert more paths to provide the
ext ack. Any thoughts on that?
^ permalink raw reply
* Re: more test_progs...
From: Daniel Borkmann @ 2017-04-25 20:49 UTC (permalink / raw)
To: David Miller, ast; +Cc: netdev
In-Reply-To: <20170425.125217.1962662516948420246.davem@davemloft.net>
On 04/25/2017 06:52 PM, David Miller wrote:
[...]
> Load eth->h_proto
>
> 10: (15) if r3 == 0xdd86 goto pc+9
> R0=imm2,min_value=2,max_value=2 R1=pkt(id=0,off=0,r=14) R2=pkt_end R3=inv R4=pkt(id=0,off=14,r=14) R5=inv56 R10=fp
>
> Hmmm, endianness looks wrong here. "-target bpf" defaults to the
> endianness of whatever cpu that llvm was built for, right?
Hmm, would it show the right endianess when you compile
with "-target bpfeb"?
My understanding is that "-target bpf" defaults to host
cpu's endianess, and since you likely built clang/llvm
directly on sparc, it should also all run on target
endianness anyway (so no potential mixup when compiling
f.e. bpfeb on x86_64).
^ permalink raw reply
* Re: [PATCH net-next] virtio-net: on tx, only call napi_disable if tx napi is on
From: Michael S. Tsirkin @ 2017-04-25 20:44 UTC (permalink / raw)
To: Willem de Bruijn; +Cc: Willem de Bruijn, netdev, davem, virtualization
In-Reply-To: <20170425195917.54209-1-willemdebruijn.kernel@gmail.com>
On Tue, Apr 25, 2017 at 03:59:17PM -0400, Willem de Bruijn wrote:
> From: Willem de Bruijn <willemb@google.com>
>
> As of tx napi, device down (`ip link set dev $dev down`) hangs unless
> tx napi is enabled. Else napi_enable is not called, so napi_disable
> will spin on test_and_set_bit NAPI_STATE_SCHED.
>
> Only call napi_disable if tx napi is enabled.
>
> Fixes: 5a719c2552ca ("virtio-net: transmit napi")
> Reported-by: Jason Wang <jasowang@redhat.com>
> Signed-off-by: Willem de Bruijn <willemb@google.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> drivers/net/virtio_net.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 003143835766..82f1c3a73345 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -997,6 +997,12 @@ static void virtnet_napi_tx_enable(struct virtnet_info *vi,
> return virtnet_napi_enable(vq, napi);
> }
>
> +static void virtnet_napi_tx_disable(struct napi_struct *napi)
> +{
> + if (napi->weight)
> + napi_disable(napi);
> +}
> +
> static void refill_work(struct work_struct *work)
> {
> struct virtnet_info *vi =
> @@ -1445,7 +1451,7 @@ static int virtnet_close(struct net_device *dev)
>
> for (i = 0; i < vi->max_queue_pairs; i++) {
> napi_disable(&vi->rq[i].napi);
> - napi_disable(&vi->sq[i].napi);
> + virtnet_napi_tx_disable(&vi->sq[i].napi);
> }
>
> return 0;
> @@ -1803,7 +1809,7 @@ static void virtnet_freeze_down(struct virtio_device *vdev)
> if (netif_running(vi->dev)) {
> for (i = 0; i < vi->max_queue_pairs; i++) {
> napi_disable(&vi->rq[i].napi);
> - napi_disable(&vi->sq[i].napi);
> + virtnet_napi_tx_disable(&vi->sq[i].napi);
> }
> }
> }
> --
> 2.13.0.rc0.306.g87b477812d-goog
^ permalink raw reply
* Re: [PATCH v2] macsec: dynamically allocate space for sglist
From: Sabrina Dubroca @ 2017-04-25 20:35 UTC (permalink / raw)
To: Jason A. Donenfeld; +Cc: Netdev, LKML, David Miller, stable, security
In-Reply-To: <20170425170818.32661-1-Jason@zx2c4.com>
2017-04-25, 19:08:18 +0200, Jason A. Donenfeld wrote:
> We call skb_cow_data, which is good anyway to ensure we can actually
> modify the skb as such (another error from prior). Now that we have the
> number of fragments required, we can safely allocate exactly that amount
> of memory.
>
> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
> Cc: Sabrina Dubroca <sd@queasysnail.net>
> Cc: security@kernel.org
> Cc: stable@vger.kernel.org
Acked-by: Sabrina Dubroca <sd@queasysnail.net>
Fixes: c09440f7dcb3 ("macsec: introduce IEEE 802.1AE driver")
Fixes: CVE-2017-7477
David, this fix is essentially equivalent to my patch "macsec: avoid
heap overflow in skb_to_sgvec on receive". Feel free to pick my patch
if you prefer (it's smaller), but this looks ok to me.
Thanks,
--
Sabrina
^ permalink raw reply
* Re: [PATCH net-next v8 2/3] net sched actions: dump more than TCA_ACT_MAX_PRIO actions per batch
From: Jamal Hadi Salim @ 2017-04-25 20:29 UTC (permalink / raw)
To: Jiri Pirko; +Cc: davem, xiyou.wangcong, eric.dumazet, netdev
In-Reply-To: <20170425160445.GD1867@nanopsycho.orion>
On 17-04-25 12:04 PM, Jiri Pirko wrote:
> Tue, Apr 25, 2017 at 03:01:22PM CEST, jhs@mojatatu.com wrote:
>> On 17-04-25 08:13 AM, Jiri Pirko wrote:
>>> Tue, Apr 25, 2017 at 01:54:06PM CEST, jhs@mojatatu.com wrote:
>>>>
>>>> +static inline bool tca_flags_valid(u32 act_flags)
>>>> +{
>>>> + u32 invalid_flags_mask = ~VALID_TCA_FLAGS;
>>>> +
>>>> + if (act_flags & invalid_flags_mask)
>>>> + return false;
>>>
>>> I don't see how this resolves anything. VALID_TCA_FLAGS is set in stone
>>> not going to change anytime in future, right?
>>
>> Every time a new bit gets added VALID_TCA_FLAGS changes.
>
> You mean flag that user can set? If that is the case, you are breaking
> UAPI for newer app running on older kernel.
>
Ok, let me try to explain with more clarity. The rules Iam
trying to follow are:
if i see any bit set that i dont understand I will reject.
So lets in first kernel I have support for bit 0.
My validation check is to make sure only bit 0 is set.
The valid_flags currently then only constitutes bit 0.
i.e
If you set bit 2 or 3, the function above will reject and i return
the error to the user.
That is expected behavior correct?
3 months down the road:
I add two flags - bit 1 and 2.
So now my valid_flags changes to bits 1, 2 and 0.
The function above will now return true for bits 0-2 but
will reject if you set bit 3.
That is expected behavior, correct?
On u32/16/8:
I am choosing u32 so it allows me to add more upto 32 bit flags.
Not all 32 are needed today but it is better insurance.
If I used u8 then the 24 of those 32 bits i dont use will be used
as pads in the TLV. So it doesnt make sense for me to use a u8/16.
Does that make more sense?
cheers,
jamal
^ permalink raw reply
* Re: [PATCH v1] net: phy: fix auto-negotiation stall due to unavailable interrupt
From: David Miller @ 2017-04-25 20:26 UTC (permalink / raw)
To: alexandre.belloni
Cc: al.kochet, f.fainelli, netdev, linux-kernel, sergei.shtylyov,
rogerq, madalin.bucur
In-Reply-To: <20170425200911.d7zfakqs5k5zwisg@piout.net>
From: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Date: Tue, 25 Apr 2017 22:09:11 +0200
> Hi,
>
> On 25/04/2017 at 18:25:30 +0300, Alexander Kochetkov wrote:
>> Hello David!
>>
>> > 25 апр. 2017 г., в 17:36, David Miller <davem@davemloft.net> написал(а):
>> >
>> > So... what are we doing here?
>> >
>> > My understanding is that this should fix the same problem that commit
>> > 99f81afc139c6edd14d77a91ee91685a414a1c66 ("phy: micrel: Disable auto
>> > negotiation on startup") fixed and that this micrel commit should thus
>> > be reverted to improve MAC startup times which regressed.
>> >
>> > Florian, any guidance?
>>
>> Yes, this should be done.
>>
>> I aksed Alexandre to check if 99f81afc139c6edd14d77a91ee91685a414a1c66 ("phy: micrel: Disable auto
>> negotiation on startup») can be reverted, and he answered what it may do that
>> sometime this/next week.
>>
>
> Yes, it can be safely reverted after Alexander's patch. I had to test on
> v4.7 because we are not using interrupts on those boards since v4.8
> (another issue to be fixed).
>
> As Florian pointed out, at the time I sent my patch, I didn't have time
> to investigate whether this was affecting other phys, see
> https://lkml.org/lkml/2016/2/26/766
>
> I can send the revert or you can do it.
I can take care of it, thanks for testing.
^ permalink raw reply
* Re: [PATCH net-next] net: move xdp_prog field in RX cache lines
From: David Miller @ 2017-04-25 20:25 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1493145412.6453.45.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 25 Apr 2017 11:36:52 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> (struct net_device, xdp_prog) field should be moved in RX cache lines,
> reducing latencies when a single packet is received on idle host,
> since netif_elide_gro() needs it.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Sure, applied, thanks Eric!
^ permalink raw reply
* Re: [PATCH v1] net: phy: fix auto-negotiation stall due to unavailable interrupt
From: Alexandre Belloni @ 2017-04-25 20:09 UTC (permalink / raw)
To: Alexander Kochetkov
Cc: David Miller, Florian Fainelli, netdev, LKML, Sergei Shtylyov,
Roger Quadros, Madalin Bucur
In-Reply-To: <B99ADC0E-A793-4334-A086-9F2CE045AB7E@gmail.com>
Hi,
On 25/04/2017 at 18:25:30 +0300, Alexander Kochetkov wrote:
> Hello David!
>
> > 25 апр. 2017 г., в 17:36, David Miller <davem@davemloft.net> написал(а):
> >
> > So... what are we doing here?
> >
> > My understanding is that this should fix the same problem that commit
> > 99f81afc139c6edd14d77a91ee91685a414a1c66 ("phy: micrel: Disable auto
> > negotiation on startup") fixed and that this micrel commit should thus
> > be reverted to improve MAC startup times which regressed.
> >
> > Florian, any guidance?
>
> Yes, this should be done.
>
> I aksed Alexandre to check if 99f81afc139c6edd14d77a91ee91685a414a1c66 ("phy: micrel: Disable auto
> negotiation on startup») can be reverted, and he answered what it may do that
> sometime this/next week.
>
Yes, it can be safely reverted after Alexander's patch. I had to test on
v4.7 because we are not using interrupts on those boards since v4.8
(another issue to be fixed).
As Florian pointed out, at the time I sent my patch, I didn't have time
to investigate whether this was affecting other phys, see
https://lkml.org/lkml/2016/2/26/766
I can send the revert or you can do it.
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH net-next] virtio-net: on tx, only call napi_disable if tx napi is on
From: Willem de Bruijn @ 2017-04-25 19:59 UTC (permalink / raw)
To: netdev; +Cc: Willem de Bruijn, virtualization, davem, mst
From: Willem de Bruijn <willemb@google.com>
As of tx napi, device down (`ip link set dev $dev down`) hangs unless
tx napi is enabled. Else napi_enable is not called, so napi_disable
will spin on test_and_set_bit NAPI_STATE_SCHED.
Only call napi_disable if tx napi is enabled.
Fixes: 5a719c2552ca ("virtio-net: transmit napi")
Reported-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: Willem de Bruijn <willemb@google.com>
---
drivers/net/virtio_net.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 003143835766..82f1c3a73345 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -997,6 +997,12 @@ static void virtnet_napi_tx_enable(struct virtnet_info *vi,
return virtnet_napi_enable(vq, napi);
}
+static void virtnet_napi_tx_disable(struct napi_struct *napi)
+{
+ if (napi->weight)
+ napi_disable(napi);
+}
+
static void refill_work(struct work_struct *work)
{
struct virtnet_info *vi =
@@ -1445,7 +1451,7 @@ static int virtnet_close(struct net_device *dev)
for (i = 0; i < vi->max_queue_pairs; i++) {
napi_disable(&vi->rq[i].napi);
- napi_disable(&vi->sq[i].napi);
+ virtnet_napi_tx_disable(&vi->sq[i].napi);
}
return 0;
@@ -1803,7 +1809,7 @@ static void virtnet_freeze_down(struct virtio_device *vdev)
if (netif_running(vi->dev)) {
for (i = 0; i < vi->max_queue_pairs; i++) {
napi_disable(&vi->rq[i].napi);
- napi_disable(&vi->sq[i].napi);
+ virtnet_napi_tx_disable(&vi->sq[i].napi);
}
}
}
--
2.13.0.rc0.306.g87b477812d-goog
^ permalink raw reply related
* [PATCH -stable 3.10,backport] net: ipv6: drop non loopback packets claiming to originate from ::1
From: Donatas Abraitis @ 2017-04-25 19:56 UTC (permalink / raw)
To: netdev
commit 0aa8c13eb512823bc4d60397d666a6b6260bb965 upstream.
We lack a saddr check for ::1. This causes security issues e.g. with acls
permitting connections from ::1 because of assumption that these originate
from local machine.
Assuming a source address of ::1 is local seems reasonable.
RFC4291 doesn't allow such a source address either, so drop such packets.
As IPv6 is getting faster pace, this patch should be included in older
kernels, for instance, 3.10 (RHEL7 family). It could be solved with
netfilter, but why do not apply this trivial patch to work as
expected?
--
Donatas
^ permalink raw reply
* Re: [PATCH 5/7] IB/hfi1: use pcie_flr instead of duplicating it
From: Bjorn Helgaas @ 2017-04-25 19:39 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Byczkowski, Jakub, Bjorn Helgaas, Cabiddu, Giovanni,
Benedetto, Salvatore, Marciniszyn, Mike, Dalessandro, Dennis,
Derek Chickles, Satanand Burla, Felix Manlunas, Raghu Vatsavayi,
Kirsher, Jeffrey T,
linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, qat-linux,
linux-crypto-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, "net
In-Reply-To: <20170424143507.GA28812-jcswGhMUV9g@public.gmane.org>
On Mon, Apr 24, 2017 at 04:35:07PM +0200, Christoph Hellwig wrote:
> On Mon, Apr 24, 2017 at 02:16:31PM +0000, Byczkowski, Jakub wrote:
> > Tested-by: Jakub Byczkowski <jakub.byczkowski-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>
> Are you (and Doug) ok with queueing this up in the PCI tree?
Applied this with Jakub's tested-by and Doug's ack to pci/virtualization
for v4.12.
This still leaves these:
[PATCH 4/7] ixgbe: use pcie_flr instead of duplicating it
[PATCH 6/7] crypto: qat: use pcie_flr instead of duplicating it
[PATCH 7/7] liquidio: use pcie_flr instead of duplicating it
I haven't seen any response to 4 and 6. Felix reported an unused
variable in 7. Let me know if you'd like me to do anything with
these.
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RESEND PATCH 3/3] infiniband: hns: avoid gcc-7.0.1 warning for uninitialized data
From: Doug Ledford @ 2017-04-25 19:19 UTC (permalink / raw)
To: Arnd Bergmann, David S . Miller
Cc: Lijun Ou, Wei Hu(Xavier), Daode Huang, Kejian Yan, Qianqian Xie,
Wei Yongjun, Yisen Zhuang, Salil Mehta, Sean Hefty,
Hal Rosenstock, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170324220250.2193128-2-arnd-r2nGTMty4D4@public.gmane.org>
On Fri, 2017-03-24 at 23:02 +0100, Arnd Bergmann wrote:
> hns_roce_v1_cq_set_ci() calls roce_set_bit() on an uninitialized
> field,
> which will then change only a few of its bits, causing a warning with
> the latest gcc:
>
> infiniband/hw/hns/hns_roce_hw_v1.c: In function
> 'hns_roce_v1_cq_set_ci':
> infiniband/hw/hns/hns_roce_hw_v1.c:1854:23: error: 'doorbell[1]' is
> used uninitialized in this function [-Werror=uninitialized]
> roce_set_bit(doorbell[1], ROCEE_DB_OTHERS_H_ROCEE_DB_OTH_HW_SYNS_S,
> 1);
>
> The code is actually correct since we always set all bits of the
> port_vlan field, but gcc correctly points out that the first
> access does contain uninitialized data.
>
> This initializes the field to zero first before setting the
> individual bits.
>
> Fixes: 9a4435375cd1 ("IB/hns: Add driver files for hns RoCE driver")
> Signed-off-by: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
Thanks, applied.
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* TCP fast open using experimental TCP option?
From: Tom Herbert @ 2017-04-25 19:08 UTC (permalink / raw)
To: Linux Kernel Network Developers, Jerry Chu
Looks like TCP fast open was using experimental TCP option at some. Is
this still needed? Technically this violates usage requirements of
experimental options. Can this be removed now since there is now an
assigned option number for TFO?
case TCPOPT_EXP:
/* Fast Open option shares code 254 using a
* 16 bits magic number.
*/
if (opsize >= TCPOLEN_EXP_FASTOPEN_BASE &&
get_unaligned_be16(ptr) ==
TCPOPT_FASTOPEN_MAGIC)
tcp_parse_fastopen_option(opsize -
TCPOLEN_EXP_FASTOPEN_BASE,
ptr + 2, th->syn, foc, true);
break;
^ permalink raw reply
* [PATCH v3] net: core: Prevent from dereferencing null pointer when releasing SKB
From: Myungho Jung @ 2017-04-25 18:58 UTC (permalink / raw)
To: davem; +Cc: netdev
Added NULL check to make __dev_kfree_skb_irq consistent with kfree
family of functions.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=195289
Signed-off-by: Myungho Jung <mhjungk@gmail.com>
---
Changes in v2:
- Correct category in subject
Changes in v3:
- Fix typo in subject
net/core/dev.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/core/dev.c b/net/core/dev.c
index 7869ae3..22be2a6 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2450,6 +2450,9 @@ void __dev_kfree_skb_irq(struct sk_buff *skb, enum skb_free_reason reason)
{
unsigned long flags;
+ if (unlikely(!skb))
+ return;
+
if (likely(atomic_read(&skb->users) == 1)) {
smp_rmb();
atomic_set(&skb->users, 0);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] net: ipv6: check route protocol when deleting routes
From: David Ahern @ 2017-04-25 18:54 UTC (permalink / raw)
To: Lorenzo Colitti, Mantas Mikulėnas
Cc: netdev@vger.kernel.org, lkml, David Miller, Joel Scherpelz,
Hannes Frederic Sowa, YOSHIFUJI Hideaki, Greg KH
In-Reply-To: <CAKD1Yr3cv+zZgZdjLMt7oac9kKAjFcht+j+JskFD_RsR61LRtA@mail.gmail.com>
On 4/24/17 3:48 AM, Lorenzo Colitti wrote:
> For non-stable kernels, it seems that the proper fix would be:
>
> 1. Ensure that when an RA creates a route, it properly sets
> rtm_protocol at time of route creation.
> 2. When we dump routes to userspace, we don't overwrite the rtm_protocol.
+1
^ 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