* Re: [PATCHv2 1/2] drivers: net: davinci_mdio: remove busy loop on wait user access
From: Grygorii Strashko @ 2017-08-10 16:24 UTC (permalink / raw)
To: Max Uvarov, netdev; +Cc: linux-omap
In-Reply-To: <1502351267-23841-1-git-send-email-muvarov@gmail.com>
On 08/10/2017 02:47 AM, Max Uvarov wrote:
> Polling 14 mdio devices on single mdio bus eats 30% of 1Ghz cpu time
> due to busy loop in wait(). Add small delay to relax cpu.
>
> Signed-off-by: Max Uvarov <muvarov@gmail.com>
yep. cover letter is good to have.
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
> ---
> v2: fix spelling in commit description.
>
> drivers/net/ethernet/ti/davinci_mdio.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/ti/davinci_mdio.c b/drivers/net/ethernet/ti/davinci_mdio.c
> index 33df340..611e7cc 100644
> --- a/drivers/net/ethernet/ti/davinci_mdio.c
> +++ b/drivers/net/ethernet/ti/davinci_mdio.c
> @@ -198,8 +198,10 @@ static inline int wait_for_user_access(struct davinci_mdio_data *data)
> return 0;
>
> reg = __raw_readl(®s->control);
> - if ((reg & CONTROL_IDLE) == 0)
> + if ((reg & CONTROL_IDLE) == 0) {
> + usleep_range(100, 200);
> continue;
> + }
>
> /*
> * An emac soft_reset may have clobbered the mdio controller's
>
--
regards,
-grygorii
^ permalink raw reply
* Re: [PATCH 4/8] tty/bcm63xx_uart: allow naming clock in device tree
From: Rob Herring @ 2017-08-10 16:25 UTC (permalink / raw)
To: Jonas Gorski
Cc: linux-mips, linux-arm-kernel, linux-serial, devicetree, netdev,
Greg Kroah-Hartman, Mark Rutland, Ralf Baechle, Florian Fainelli,
bcm-kernel-feedback-list, Kevin Cernekee, Jiri Slaby,
David S. Miller, Russell King
In-Reply-To: <20170802093429.12572-5-jonas.gorski@gmail.com>
On Wed, Aug 02, 2017 at 11:34:25AM +0200, Jonas Gorski wrote:
> Codify using a named clock for the refclk of the uart. This makes it
> easier if we might need to add a gating clock (like present on the
> BCM6345).
>
> Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
> ---
> Documentation/devicetree/bindings/serial/brcm,bcm6345-uart.txt | 6 ++++++
> drivers/tty/serial/bcm63xx_uart.c | 6 ++++--
> 2 files changed, 10 insertions(+), 2 deletions(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH RFC net-next] net: Allow name change of IFF_UP interfaces
From: Andrew Lunn @ 2017-08-10 16:27 UTC (permalink / raw)
To: Vitaly Kuznetsov
Cc: Eric Dumazet, network dev, David S. Miller, Eric Dumazet,
Stephen Hemminger
In-Reply-To: <87lgmrsawo.fsf@vitty.brq.redhat.com>
On Thu, Aug 10, 2017 at 05:24:55PM +0200, Vitaly Kuznetsov wrote:
> Andrew Lunn <andrew@lunn.ch> writes:
>
> >> We are - rtnetlink_event() does the job. We, however, don't have a
> >> special IFLA_EVENT_* for name change and end up with IFLA_EVENT_NONE.
> >
> > What is in this event? Old and new name? Just the new name?
>
> Basically, it's everything we know about the interface - type, index,
> name, mtu, qdisc, ... - see rtnl_fill_ifinfo(). Back to your question -
> it's only the new name.
So the program needs to keep track of ifindex to know which interface
has changed name. Doable.
I still expect this has the potential to break something. You probably
should be asking on linux-api for the API experts opinion.
Andrew
^ permalink raw reply
* [PATCH net] udp: consistently apply ufo or fragmentation
From: Willem de Bruijn @ 2017-08-10 16:29 UTC (permalink / raw)
To: netdev; +Cc: davem, andreyknvl, Willem de Bruijn
From: Willem de Bruijn <willemb@google.com>
When iteratively building a UDP datagram with MSG_MORE and that
datagram exceeds MTU, consistently choose UFO or fragmentation.
Once skb_is_gso, always apply ufo. Conversely, once a datagram is
split across multiple skbs, do not consider ufo.
Sendpage already maintains the first invariant, only add the second.
IPv6 does not have a sendpage implementation to modify.
A gso skb must have a partial checksum, do not follow sk_no_check_tx
in udp_send_skb.
Found by syzkaller.
Fixes: e89e9cf539a2 ("[IPv4/IPv6]: UFO Scatter-gather approach")
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Willem de Bruijn <willemb@google.com>
---
net/ipv4/ip_output.c | 8 +++++---
net/ipv4/udp.c | 2 +-
net/ipv6/ip6_output.c | 7 ++++---
3 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
index 50c74cd890bc..e153c40c2436 100644
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -965,11 +965,12 @@ static int __ip_append_data(struct sock *sk,
csummode = CHECKSUM_PARTIAL;
cork->length += length;
- if ((((length + (skb ? skb->len : fragheaderlen)) > mtu) ||
- (skb && skb_is_gso(skb))) &&
+ if ((skb && skb_is_gso(skb)) ||
+ (((length + (skb ? skb->len : fragheaderlen)) > mtu) &&
+ (skb_queue_len(queue) <= 1) &&
(sk->sk_protocol == IPPROTO_UDP) &&
(rt->dst.dev->features & NETIF_F_UFO) && !dst_xfrm(&rt->dst) &&
- (sk->sk_type == SOCK_DGRAM) && !sk->sk_no_check_tx) {
+ (sk->sk_type == SOCK_DGRAM) && !sk->sk_no_check_tx)) {
err = ip_ufo_append_data(sk, queue, getfrag, from, length,
hh_len, fragheaderlen, transhdrlen,
maxfraglen, flags);
@@ -1288,6 +1289,7 @@ ssize_t ip_append_page(struct sock *sk, struct flowi4 *fl4, struct page *page,
return -EINVAL;
if ((size + skb->len > mtu) &&
+ (skb_queue_len(&sk->sk_write_queue) == 1) &&
(sk->sk_protocol == IPPROTO_UDP) &&
(rt->dst.dev->features & NETIF_F_UFO)) {
if (skb->ip_summed != CHECKSUM_PARTIAL)
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index e6276fa3750b..a7c804f73990 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -802,7 +802,7 @@ static int udp_send_skb(struct sk_buff *skb, struct flowi4 *fl4)
if (is_udplite) /* UDP-Lite */
csum = udplite_csum(skb);
- else if (sk->sk_no_check_tx) { /* UDP csum disabled */
+ else if (sk->sk_no_check_tx && !skb_is_gso(skb)) { /* UDP csum off */
skb->ip_summed = CHECKSUM_NONE;
goto send;
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 162efba0d0cd..2dfe50d8d609 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -1381,11 +1381,12 @@ static int __ip6_append_data(struct sock *sk,
*/
cork->length += length;
- if ((((length + (skb ? skb->len : headersize)) > mtu) ||
- (skb && skb_is_gso(skb))) &&
+ if ((skb && skb_is_gso(skb)) ||
+ (((length + (skb ? skb->len : headersize)) > mtu) &&
+ (skb_queue_len(queue) <= 1) &&
(sk->sk_protocol == IPPROTO_UDP) &&
(rt->dst.dev->features & NETIF_F_UFO) && !dst_xfrm(&rt->dst) &&
- (sk->sk_type == SOCK_DGRAM) && !udp_get_no_check6_tx(sk)) {
+ (sk->sk_type == SOCK_DGRAM) && !udp_get_no_check6_tx(sk))) {
err = ip6_ufo_append_data(sk, queue, getfrag, from, length,
hh_len, fragheaderlen, exthdrlen,
transhdrlen, mtu, flags, fl6);
--
2.14.0.434.g98096fd7a8-goog
^ permalink raw reply related
* Re: [PATCH V4 net 0/2] ipv6: fix flowlabel issue for reset packet
From: Shaohua Li @ 2017-08-10 16:30 UTC (permalink / raw)
To: Tom Herbert; +Cc: Linux Kernel Network Developers, David S. Miller, Shaohua Li
In-Reply-To: <CALx6S36DcpqqqhosdN4qNqTNYZkxZ=0Qy-=uKXHVM_yQoE4XbQ@mail.gmail.com>
On Wed, Aug 09, 2017 at 09:40:08AM -0700, Tom Herbert wrote:
> On Mon, Jul 31, 2017 at 3:19 PM, Shaohua Li <shli@kernel.org> wrote:
> > From: Shaohua Li <shli@fb.com>
> >
> > Please see below tcpdump output:
> > 21:00:48.109122 IP6 (flowlabel 0x43304, hlim 64, next-header TCP (6) payload length: 40) fec0::5054:ff:fe12:3456.55804 > fec0::5054:ff:fe12:3456.5555: Flags [S], cksum 0x0529 (incorrect -> 0xf56c), seq 3282214508, win 43690, options [mss 65476,sackOK,TS val 2500903437 ecr 0,nop,wscale 7], length 0
> > 21:00:48.109381 IP6 (flowlabel 0xd827f, hlim 64, next-header TCP (6) payload length: 40) fec0::5054:ff:fe12:3456.5555 > fec0::5054:ff:fe12:3456.55804: Flags [S.], cksum 0x0529 (incorrect -> 0x49ad), seq 1923801573, ack 3282214509, win 43690, options [mss 65476,sackOK,TS val 2500903437 ecr 2500903437,nop,wscale 7], length 0
> > 21:00:48.109548 IP6 (flowlabel 0x43304, hlim 64, next-header TCP (6) payload length: 32) fec0::5054:ff:fe12:3456.55804 > fec0::5054:ff:fe12:3456.5555: Flags [.], cksum 0x0521 (incorrect -> 0x1bdf), seq 1, ack 1, win 342, options [nop,nop,TS val 2500903437 ecr 2500903437], length 0
> > 21:00:48.109823 IP6 (flowlabel 0x43304, hlim 64, next-header TCP (6) payload length: 62) fec0::5054:ff:fe12:3456.55804 > fec0::5054:ff:fe12:3456.5555: Flags [P.], cksum 0x053f (incorrect -> 0xb8b1), seq 1:31, ack 1, win 342, options [nop,nop,TS val 2500903437 ecr 2500903437], length 30
> > 21:00:48.109910 IP6 (flowlabel 0xd827f, hlim 64, next-header TCP (6) payload length: 32) fec0::5054:ff:fe12:3456.5555 > fec0::5054:ff:fe12:3456.55804: Flags [.], cksum 0x0521 (incorrect -> 0x1bc1), seq 1, ack 31, win 342, options [nop,nop,TS val 2500903437 ecr 2500903437], length 0
> > 21:00:48.110043 IP6 (flowlabel 0xd827f, hlim 64, next-header TCP (6) payload length: 56) fec0::5054:ff:fe12:3456.5555 > fec0::5054:ff:fe12:3456.55804: Flags [P.], cksum 0x0539 (incorrect -> 0xb726), seq 1:25, ack 31, win 342, options [nop,nop,TS val 2500903438 ecr 2500903437], length 24
> > 21:00:48.110173 IP6 (flowlabel 0x43304, hlim 64, next-header TCP (6) payload length: 32) fec0::5054:ff:fe12:3456.55804 > fec0::5054:ff:fe12:3456.5555: Flags [.], cksum 0x0521 (incorrect -> 0x1ba7), seq 31, ack 25, win 342, options [nop,nop,TS val 2500903438 ecr 2500903438], length 0
> > 21:00:48.110211 IP6 (flowlabel 0xd827f, hlim 64, next-header TCP (6) payload length: 32) fec0::5054:ff:fe12:3456.5555 > fec0::5054:ff:fe12:3456.55804: Flags [F.], cksum 0x0521 (incorrect -> 0x1ba7), seq 25, ack 31, win 342, options [nop,nop,TS val 2500903438 ecr 2500903437], length 0
> > 21:00:48.151099 IP6 (flowlabel 0x43304, hlim 64, next-header TCP (6) payload length: 32) fec0::5054:ff:fe12:3456.55804 > fec0::5054:ff:fe12:3456.5555: Flags [.], cksum 0x0521 (incorrect -> 0x1ba6), seq 31, ack 26, win 342, options [nop,nop,TS val 2500903438 ecr 2500903438], length 0
> > 21:00:49.110524 IP6 (flowlabel 0x43304, hlim 64, next-header TCP (6) payload length: 56) fec0::5054:ff:fe12:3456.55804 > fec0::5054:ff:fe12:3456.5555: Flags [P.], cksum 0x0539 (incorrect -> 0xb324), seq 31:55, ack 26, win 342, options [nop,nop,TS val 2500904438 ecr 2500903438], length 24
> > 21:00:49.110637 IP6 (flowlabel 0xb34d5, hlim 64, next-header TCP (6) payload length: 20) fec0::5054:ff:fe12:3456.5555 > fec0::5054:ff:fe12:3456.55804: Flags [R], cksum 0x0515 (incorrect -> 0x668c), seq 1923801599, win 0, length 0
> >
> > The flowlabel of reset packet (0xb34d5) and flowlabel of normal packet
> > (0xd827f) are different. This causes our router doesn't correctly close tcp
> > connection. The patches try to fix the issue.
> >
> Shaohua,
>
> Can you give some more detail about what the router doesn't close the
> TCP connection means? I'm guessing the problem is either: 1) the
> router is maintaining connection state that includes the flow label in
> a connection tuple. 2) some router in the path is maintaining
> connection state, but when the flow label changes the flow's packet
> are routed through a different router that doesn't have a state for
> the flow it drops the packet. #1 should be easily fix in the router,
> flow labels cannot be used as state. #2 is the known problem that
> stateful firewalls have killed our ability to use multihoming.
The #2 is exactly the problem we saw.
> Another consideration is that sk_txhash is also used in routing
> decisions by the local host (flow label is normally derived from
> txhash). If you want to ensure that connections are routed
> consistently for timewait state you might need sk_txhash saved also.
As far as I understood, we don't use sk_txhash for routing selection. The code
does routing selection with flowlabel user configured, at that time we don't
derive fl6.flowlabel from skb->hash (which is from sk_txhash). The code always
does routing selection first and then uses ip6_make_flowlabel to build packet
data where we derive flowlabel from skb->hash.
Thanks,
Shaohua
^ permalink raw reply
* Re: [PATCH RFC net-next] net: Allow name change of IFF_UP interfaces
From: Vitaly Kuznetsov @ 2017-08-10 16:33 UTC (permalink / raw)
To: Andrew Lunn
Cc: Eric Dumazet, network dev, David S. Miller, Eric Dumazet,
Stephen Hemminger
In-Reply-To: <20170810162722.GH24790@lunn.ch>
Andrew Lunn <andrew@lunn.ch> writes:
> On Thu, Aug 10, 2017 at 05:24:55PM +0200, Vitaly Kuznetsov wrote:
>> Andrew Lunn <andrew@lunn.ch> writes:
>>
>> >> We are - rtnetlink_event() does the job. We, however, don't have a
>> >> special IFLA_EVENT_* for name change and end up with IFLA_EVENT_NONE.
>> >
>> > What is in this event? Old and new name? Just the new name?
>>
>> Basically, it's everything we know about the interface - type, index,
>> name, mtu, qdisc, ... - see rtnl_fill_ifinfo(). Back to your question -
>> it's only the new name.
>
> So the program needs to keep track of ifindex to know which interface
> has changed name. Doable.
>
Yes, and I'd expect that's what these daemons do nowdays to track name
changes for down interfaces (if/when they care).
> I still expect this has the potential to break something. You probably
> should be asking on linux-api for the API experts opinion.
>
Good idea, I'll do RFCv2 submission.
--
Vitaly
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: net: c_can: Update binding for clock and power-domains property
From: Rob Herring @ 2017-08-10 16:35 UTC (permalink / raw)
To: Franklin S Cooper Jr
Cc: devicetree, linux-kernel, netdev, linux, linux-can, mkl,
linux-arm-kernel, ssantosh, wg
In-Reply-To: <20170802201822.11532-2-fcooper@ti.com>
On Wed, Aug 02, 2017 at 03:18:20PM -0500, Franklin S Cooper Jr wrote:
> CAN driver uses the clk_get_rate call to determine the frequency of the
> functional clock. OMAP based SoCs do not require the clock property since
> hwmod already handles creating a "fck" clock thats accessible to drivers.
that's
> However, this isn't the case for 66AK2G which makes the clocks property
> require for that SoC.
required
>
> 66AK2G requires a new property. Therefore, update the binding to also make
> this property requirement clear. Also clarify that for OMAP based SoCs
> ti,hwmod is a required property.
>
> Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
> ---
> Documentation/devicetree/bindings/net/can/c_can.txt | 13 ++++++++++++-
> 1 file changed, 12 insertions(+), 1 deletion(-)
Otherwise,
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH net] packet: fix tp_reserve race in packet_set_ring
From: Willem de Bruijn @ 2017-08-10 16:41 UTC (permalink / raw)
To: netdev; +Cc: davem, andreyknvl, Willem de Bruijn
From: Willem de Bruijn <willemb@google.com>
Updates to tp_reserve can race with reads of the field in
packet_set_ring. Avoid this by holding the socket lock during
updates in setsockopt PACKET_RESERVE.
This bug was discovered by syzkaller.
Fixes: 8913336a7e8d ("packet: add PACKET_RESERVE sockopt")
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Willem de Bruijn <willemb@google.com>
---
net/packet/af_packet.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 0615c2a950fa..008a45ca3112 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -3700,14 +3700,19 @@ packet_setsockopt(struct socket *sock, int level, int optname, char __user *optv
if (optlen != sizeof(val))
return -EINVAL;
- if (po->rx_ring.pg_vec || po->tx_ring.pg_vec)
- return -EBUSY;
if (copy_from_user(&val, optval, sizeof(val)))
return -EFAULT;
if (val > INT_MAX)
return -EINVAL;
- po->tp_reserve = val;
- return 0;
+ lock_sock(sk);
+ if (po->rx_ring.pg_vec || po->tx_ring.pg_vec) {
+ ret = -EBUSY;
+ } else {
+ po->tp_reserve = val;
+ ret = 0;
+ }
+ release_sock(sk);
+ return ret;
}
case PACKET_LOSS:
{
--
2.14.0.434.g98096fd7a8-goog
^ permalink raw reply related
* Re: [PATCH RFC net-next] net: Allow name change of IFF_UP interfaces
From: David Miller @ 2017-08-10 16:48 UTC (permalink / raw)
To: andrew; +Cc: vkuznets, eric.dumazet, netdev, edumazet, stephen
In-Reply-To: <20170810162722.GH24790@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch>
Date: Thu, 10 Aug 2017 18:27:22 +0200
> On Thu, Aug 10, 2017 at 05:24:55PM +0200, Vitaly Kuznetsov wrote:
>> Andrew Lunn <andrew@lunn.ch> writes:
>>
>> >> We are - rtnetlink_event() does the job. We, however, don't have a
>> >> special IFLA_EVENT_* for name change and end up with IFLA_EVENT_NONE.
>> >
>> > What is in this event? Old and new name? Just the new name?
>>
>> Basically, it's everything we know about the interface - type, index,
>> name, mtu, qdisc, ... - see rtnl_fill_ifinfo(). Back to your question -
>> it's only the new name.
>
> So the program needs to keep track of ifindex to know which interface
> has changed name. Doable.
>
> I still expect this has the potential to break something. You probably
> should be asking on linux-api for the API experts opinion.
But a greater point is that nobody is monitoring device renames
explicitly right now.
It's hard to legitimize imposing new requirements like this on daemons
which didn't exist before.
If they could assume the name didn't change, they probably are doing
so.
You can't expect that just because they might already be listening to
this event for device up and down tracking that they are handling
device renames.
^ permalink raw reply
* Re: [PATCH net-next 0/6] rtnetlink: fix initial rtnl pushdown fallout
From: David Miller @ 2017-08-10 16:50 UTC (permalink / raw)
To: fw; +Cc: netdev
In-Reply-To: <20170810145302.30391-1-fw@strlen.de>
From: Florian Westphal <fw@strlen.de>
Date: Thu, 10 Aug 2017 16:52:56 +0200
> This series fixes various bugs and splats reported since the
> allow-handler-to-run-with-no-rtnl series went in.
>
> Last patch adds a script that can be used to add further
> tests in case more bugs are reported.
> In case you prefer reverting the original series instead of
> fixing fallout I can resend this patch on its own.
Series applied, thanks Florian.
^ permalink raw reply
* Re: [PATCH 0/3] ARM: dts: keystone-k2g: Add DCAN instances to 66AK2G
From: santosh.shilimkar @ 2017-08-10 16:51 UTC (permalink / raw)
To: Franklin S Cooper Jr, wg, mkl, robh+dt, ssantosh, linux,
linux-can, netdev, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <8930852b-6995-3d41-440e-86f440b313ad@ti.com>
On 8/7/17 2:31 PM, Franklin S Cooper Jr wrote:
>
> Hi Santosh,
> On 08/04/2017 12:07 PM, Santosh Shilimkar wrote:
>> Hi Franklin,
>>
>> On 8/2/2017 1:18 PM, Franklin S Cooper Jr wrote:
>>> Add D CAN nodes to 66AK2G based SoC dtsi.
>>>
>>> Franklin S Cooper Jr (2):
>>> dt-bindings: net: c_can: Update binding for clock and power-domains
>>> property
>>> ARM: configs: keystone: Enable D_CAN driver
>>>
>>> Lokesh Vutla (1):
>>> ARM: dts: k2g: Add DCAN nodes
>>>
>> Any DCAN driver dependency with these patchset ? If not, I can
>> queue this up so do let me know.
>
> There aren't any dependencies.
Applied. Thanks !!
Regards,
Santosh
^ permalink raw reply
* Re: [PATCH net] udp: consistently apply ufo or fragmentation
From: David Miller @ 2017-08-10 16:52 UTC (permalink / raw)
To: willemdebruijn.kernel; +Cc: netdev, andreyknvl, willemb
In-Reply-To: <20170810162919.50577-1-willemdebruijn.kernel@gmail.com>
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Date: Thu, 10 Aug 2017 12:29:19 -0400
> From: Willem de Bruijn <willemb@google.com>
>
> When iteratively building a UDP datagram with MSG_MORE and that
> datagram exceeds MTU, consistently choose UFO or fragmentation.
>
> Once skb_is_gso, always apply ufo. Conversely, once a datagram is
> split across multiple skbs, do not consider ufo.
>
> Sendpage already maintains the first invariant, only add the second.
> IPv6 does not have a sendpage implementation to modify.
>
> A gso skb must have a partial checksum, do not follow sk_no_check_tx
> in udp_send_skb.
>
> Found by syzkaller.
>
> Fixes: e89e9cf539a2 ("[IPv4/IPv6]: UFO Scatter-gather approach")
> Reported-by: Andrey Konovalov <andreyknvl@google.com>
> Signed-off-by: Willem de Bruijn <willemb@google.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net] packet: fix tp_reserve race in packet_set_ring
From: David Miller @ 2017-08-10 16:52 UTC (permalink / raw)
To: willemdebruijn.kernel; +Cc: netdev, andreyknvl, willemb
In-Reply-To: <20170810164158.52213-1-willemdebruijn.kernel@gmail.com>
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Date: Thu, 10 Aug 2017 12:41:58 -0400
> From: Willem de Bruijn <willemb@google.com>
>
> Updates to tp_reserve can race with reads of the field in
> packet_set_ring. Avoid this by holding the socket lock during
> updates in setsockopt PACKET_RESERVE.
>
> This bug was discovered by syzkaller.
>
> Fixes: 8913336a7e8d ("packet: add PACKET_RESERVE sockopt")
> Reported-by: Andrey Konovalov <andreyknvl@google.com>
> Signed-off-by: Willem de Bruijn <willemb@google.com>
Also applied and queued up for -stable, thanks Willem.
^ permalink raw reply
* Re: [PATCH RFC net-next] net: Allow name change of IFF_UP interfaces
From: David Ahern @ 2017-08-10 16:55 UTC (permalink / raw)
To: David Miller, andrew; +Cc: vkuznets, eric.dumazet, netdev, edumazet, stephen
In-Reply-To: <20170810.094803.1621536453262110983.davem@davemloft.net>
On 8/10/17 10:48 AM, David Miller wrote:
> From: Andrew Lunn <andrew@lunn.ch>
> Date: Thu, 10 Aug 2017 18:27:22 +0200
>
>> On Thu, Aug 10, 2017 at 05:24:55PM +0200, Vitaly Kuznetsov wrote:
>>> Andrew Lunn <andrew@lunn.ch> writes:
>>>
>>>>> We are - rtnetlink_event() does the job. We, however, don't have a
>>>>> special IFLA_EVENT_* for name change and end up with IFLA_EVENT_NONE.
>>>>
>>>> What is in this event? Old and new name? Just the new name?
>>>
>>> Basically, it's everything we know about the interface - type, index,
>>> name, mtu, qdisc, ... - see rtnl_fill_ifinfo(). Back to your question -
>>> it's only the new name.
>>
>> So the program needs to keep track of ifindex to know which interface
>> has changed name. Doable.
>>
>> I still expect this has the potential to break something. You probably
>> should be asking on linux-api for the API experts opinion.
>
> But a greater point is that nobody is monitoring device renames
> explicitly right now.
Just to throw in an example:
https://github.com/kobolabs/dhcpcd/blob/kobo/if-linux.c#L761
Learned of its use from a recent regression:
https://bugzilla.kernel.org/show_bug.cgi?id=196355
^ permalink raw reply
* Re: [PATCH net-next] net: skb_needs_check() removes CHECKSUM_NONE check for tx.
From: Willem de Bruijn @ 2017-08-10 17:03 UTC (permalink / raw)
To: Tonghao Zhang; +Cc: Network Development, Eric Dumazet, Willem de Bruijn
In-Reply-To: <CAMDZJNUMdKvKLJGtwg-3dMf_CPiX56x5b17A8H3oW2m=fkWAUw@mail.gmail.com>
On Wed, Aug 9, 2017 at 6:02 PM, Tonghao Zhang <xiangxia.m.yue@gmail.com> wrote:
> Thanks for your work.
You, too.
> On Thu, Aug 10, 2017 at 2:30 AM, Willem de Bruijn
> <willemdebruijn.kernel@gmail.com> wrote:
>> On Wed, Aug 9, 2017 at 5:04 AM, Tonghao Zhang <xiangxia.m.yue@gmail.com> wrote:
>>> This patch reverts the commit 6e7bc478c9a0
>>> ("net: skb_needs_check() accepts CHECKSUM_NONE for tx"),
>>> because we removed the UFO support.
>>>
>>> Cc: Eric Dumazet <edumazet@google.com>
>>> Cc: Willem de Bruijn <willemb@google.com>
>>> Signed-off-by: Tonghao Zhang <xiangxia.m.yue@gmail.com>
>>
>>
>> I would wait until net is merged into net-next. This will cause a conflict.
>>
>> Also, while logically equivalent, it is not a real revert (as in `git
>> revert $SHA1`) of that patch.
>>
>> Aside from those concerns, I agree that the original patch is no
>> longer needed now that UFO is reverted.
Please do resubmit the revert patch once net has been merged into net-next.
^ permalink raw reply
* Re: [PATCH V5 1/2] firmware: add more flexible request_firmware_async function
From: Luis R. Rodriguez @ 2017-08-10 17:05 UTC (permalink / raw)
To: Kalle Valo
Cc: Luis R. Rodriguez, Rafał Miłecki, Greg Kroah-Hartman,
Bjorn Andersson, Daniel Wagner, David Woodhouse, Arend van Spriel,
Rafael J . Wysocki, yi1.li, atull, Moritz Fischer, pmladek,
Johannes Berg, emmanuel.grumbach, luciano.coelho, luto,
Linus Torvalds, Kees Cook, AKASHI Takahiro, David Howells, pjones
In-Reply-To: <878tj1ql6z.fsf@kamboji.qca.qualcomm.com>
On Thu, Aug 03, 2017 at 08:23:00AM +0300, Kalle Valo wrote:
> "Luis R. Rodriguez" <mcgrof@kernel.org> writes:
>
> >> +int request_firmware_nowait(struct module *module, bool uevent,
> >> + const char *name, struct device *device, gfp_t gfp,
> >> + void *context,
> >> + void (*cont)(const struct firmware *fw, void *context))
> >> +{
> >> + unsigned int opt_flags = FW_OPT_FALLBACK |
> >> + (uevent ? FW_OPT_UEVENT : FW_OPT_USERHELPER);
> >> +
> >> + return __request_firmware_nowait(module, opt_flags, name, device, gfp,
> >> + context, cont);
> >> +}
> >> EXPORT_SYMBOL(request_firmware_nowait);
> >>
> >> +int __request_firmware_async(struct module *module, const char *name,
> >> + struct firmware_opts *fw_opts, struct device *dev,
> >> + void *context,
> >> + void (*cont)(const struct firmware *fw, void *context))
> >> +{
> >> + unsigned int opt_flags = FW_OPT_UEVENT;
> >
> > This exposes a long issue. Think -- why do we want this enabled by default? Its
> > actually because even though the fallback stuff is optional and can be, the uevent
> > internal flag *also* provides caching support as a side consequence only. We
> > don't want to add a new API without first cleaning up that mess.
> >
> > This is a slipery slope and best to clean that up before adding any new API.
> >
> > That and also Greg recently stated he would like to see at least 3 users of
> > a feature before adding it. Although I think that's pretty arbitrary, and
> > considering that request_firmware_into_buf() only has *one* user -- its what
> > he wishes.
>
> ath10k at least needs a way to silence the warning for missing firmware
> and I think iwlwifi also.
It would seem ath10k actually does not need an async version of the no-warn
thing proposed here.
Below an analysis of how ath10k uses the firmware API. Note that I think
that iwlwifi may be on the same boat but the case and issue is slightly
different: both drivers use an API revision scheme, intermediate files
which are not found are not fatal as revisions go from min..max and only
one file is needed. A warning may be needed only if *no* file is found
at all.
I had proposed a new API call to handle this in the driver API series but
had only converted iwlwifi. It would seem ath10k can also be converted to
it and also they could end up sharing the same revision loop scheme so
less code on both drivers.
Below my analysis of how ath10k uses the firmware API:
You noted in private that ath10k long ago addressed the warning issue by
switching to request_firmware_direct() entirely:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9f5bcfe93315d75da4cc46bd30b536966559359a
Below is a list of the file name schemes used for all the different firmwares
types used in ath10k:
1)
/* pre-cal-<bus>-<id>.bin */
scnprintf(filename, sizeof(filename), "pre-cal-%s-%s.bin",
2)
/* cal-<bus>-<id>.bin */
scnprintf(filename, sizeof(filename), "cal-%s-%s.bin",
ath10k_bus_str(ar->hif.bus), dev_name(ar->dev));
This seems fine as-is if indeed they are optional.
3) ath10k_core_fetch_board_data_api_1():
ar->hw_params.fw.dir/ar->hw_params.fw.board
This seems fine if indeed its optional.
3) Then you have a board file on ath10k_core_fetch_board_data_api_n():
boardname/ATH10K_BOARD_API2_FILE
This seems fine if indeed its optional.
4) Finally you have the actual firmware files which use a revision scheme
in ath10k_core_fetch_firmware_api_n():
for (i = ATH10K_FW_API_MAX; i >= ATH10K_FW_API_MIN; i--) {
ar->fw_api = i;
ath10k_dbg(ar, ATH10K_DBG_BOOT, "trying fw api %d\n",
ar->fw_api);
ath10k_core_get_fw_name(ar, fw_name, sizeof(fw_name), ar->fw_api);
ret = ath10k_core_fetch_firmware_api_n(ar, fw_name,
&ar->normal_mode_fw.fw_file);
if (!ret)
goto success;
}
This ends up using the ar->hw_params.fw.dir/fw_name but fw_name is constructed
above using a API revision scheme. The fw_name can be of two types as per
ath10k_core_get_fw_name():
For SDIO:
scnprintf(fw_name, fw_name_len, "%s-%s-%d.bin",
ATH10K_FW_FILE_BASE, ath10k_bus_str(ar->hif.bus),
fw_api);
For PCI/AHB:
scnprintf(fw_name, fw_name_len, "%s-%d.bin",
ATH10K_FW_FILE_BASE, fw_api);
For this the problem is at least one firmware is required so no complaint is
issued using request_firmware_direct() at all so you have to do that yourself
on ath10k_core_fetch_firmware_files():
/* we end up here if we couldn't fetch any firmware */
ath10k_err(ar, "Failed to find firmware-N.bin (N between %d and %d) from %s: %d",
ATH10K_FW_API_MIN, ATH10K_FW_API_MAX, ar->hw_params.fw.dir,
ret);
This is *fine* as per the API but it just means you are troubled to keep this
error warning. Correct me if I'm wrong but this does not seem to me like a big
issue and your issue is not in any way related to the patch proposed.
*But* the whole API revision scheme is something I figured could be generalized
and have code which lets us specify a name template, and let the driver
specific a series of API revision numbers and then the firmware API will do the
hunting for us. Then at least one API versioned file is hunted for. Since you
got from ATH10K_FW_API_MAX (6) down to ATH10K_FW_API_MIN (2) and I had used u8
for it then we have a match in terms of compatibility.
Turns out Intel uses a similar scheme, this is what it would look like for
iwlwifi to change to it, your driver similarly could cope:
https://lkml.kernel.org/r/20170605213937.26215-6-mcgrof@kernel.org
If this seems appealing I could do the conversion for you later once
I add this upstream. I'd need one more driver which has a similar API
revision scheme.
Luis
^ permalink raw reply
* Re: [PATCH V5 1/2] firmware: add more flexible request_firmware_async function
From: Luis R. Rodriguez @ 2017-08-10 17:07 UTC (permalink / raw)
To: Coelho, Luciano
Cc: kvalo@codeaurora.org, mcgrof@kernel.org,
pieter-paul.giesberts@broadcom.com, bjorn.andersson@linaro.org,
arend.vanspriel@broadcom.com, hante.meuleman@broadcom.com,
gregkh@linuxfoundation.org, keescook@chromium.org,
linux-wireless@vger.kernel.org, alan@linux.intel.com,
moritz.fischer@ettus.com, pjones@redhat.com, wagi@monom.org,
pmladek@suse.com, atull@kernel.org
In-Reply-To: <1501739717.15969.26.camel@intel.com>
On Thu, Aug 03, 2017 at 05:55:18AM +0000, Coelho, Luciano wrote:
> On Thu, 2017-08-03 at 08:23 +0300, Kalle Valo wrote:
> > "Luis R. Rodriguez" <mcgrof@kernel.org> writes:
> >
> > > > +int request_firmware_nowait(struct module *module, bool uevent,
> > > > + const char *name, struct device *device, gfp_t gfp,
> > > > + void *context,
> > > > + void (*cont)(const struct firmware *fw, void *context))
> > > > +{
> > > > + unsigned int opt_flags = FW_OPT_FALLBACK |
> > > > + (uevent ? FW_OPT_UEVENT : FW_OPT_USERHELPER);
> > > > +
> > > > + return __request_firmware_nowait(module, opt_flags, name, device, gfp,
> > > > + context, cont);
> > > > +}
> > > > EXPORT_SYMBOL(request_firmware_nowait);
> > > >
> > > > +int __request_firmware_async(struct module *module, const char *name,
> > > > + struct firmware_opts *fw_opts, struct device *dev,
> > > > + void *context,
> > > > + void (*cont)(const struct firmware *fw, void *context))
> > > > +{
> > > > + unsigned int opt_flags = FW_OPT_UEVENT;
> > >
> > > This exposes a long issue. Think -- why do we want this enabled by default? Its
> > > actually because even though the fallback stuff is optional and can be, the uevent
> > > internal flag *also* provides caching support as a side consequence only. We
> > > don't want to add a new API without first cleaning up that mess.
> > >
> > > This is a slipery slope and best to clean that up before adding any new API.
> > >
> > > That and also Greg recently stated he would like to see at least 3 users of
> > > a feature before adding it. Although I think that's pretty arbitrary, and
> > > considering that request_firmware_into_buf() only has *one* user -- its what
> > > he wishes.
> >
> > ath10k at least needs a way to silence the warning for missing firmware
> > and I think iwlwifi also.
>
> Yes, iwlwifi needs to silence the warning. It the feature (only one,
> really) that I've been waiting for.
Luca,
can you confirm? The API revision thing is one thing but as I noted to
Kalle that can be done using a different API scheme as I had proposed on
the driver data API.
Other than that are there specific firmware requests which are async which
are not API revision style (min...max) for which an async request is optional?
Luis
^ permalink raw reply
* [PATCH ipsec-next] net: xfrm: support setting an output mark.
From: Lorenzo Colitti @ 2017-08-10 17:11 UTC (permalink / raw)
To: netdev; +Cc: davem, jhs, steffen.klassert, herbert, Lorenzo Colitti
On systems that use mark-based routing it may be necessary for
routing lookups to use marks in order for packets to be routed
correctly. An example of such a system is Android, which uses
socket marks to route packets via different networks.
Currently, routing lookups in tunnel mode always use a mark of
zero, making routing incorrect on such systems.
This patch adds a new output_mark element to the xfrm state and
a corresponding XFRMA_OUTPUT_MARK netlink attribute. The output
mark differs from the existing xfrm mark in two ways:
1. The xfrm mark is used to match xfrm policies and states, while
the xfrm output mark is used to set the mark (and influence
the routing) of the packets emitted by those states.
2. The existing mark is constrained to be a subset of the bits of
the originating socket or transformed packet, but the output
mark is arbitrary and depends only on the state.
The use of a separate mark provides additional flexibility. For
example:
- A packet subject to two transforms (e.g., transport mode inside
tunnel mode) can have two different output marks applied to it,
one for the transport mode SA and one for the tunnel mode SA.
- On a system where socket marks determine routing, the packets
emitted by an IPsec tunnel can be routed based on a mark that
is determined by the tunnel, not by the marks of the
unencrypted packets.
- Support for setting the output marks can be introduced without
breaking any existing setups that employ both mark-based
routing and xfrm tunnel mode. Simply changing the code to use
the xfrm mark for routing output packets could xfrm mark could
change behaviour in a way that breaks these setups.
If the output mark is unspecified or set to zero, the mark is not
set or changed.
Tested: make allyesconfig; make -j64
Tested: https://android-review.googlesource.com/452776
Signed-off-by: Lorenzo Colitti <lorenzo@google.com>
---
include/net/xfrm.h | 9 ++++++---
include/uapi/linux/xfrm.h | 1 +
net/ipv4/xfrm4_policy.c | 14 +++++++++-----
net/ipv6/xfrm6_policy.c | 9 ++++++---
net/xfrm/xfrm_device.c | 3 ++-
net/xfrm/xfrm_output.c | 3 +++
net/xfrm/xfrm_policy.c | 17 +++++++++--------
net/xfrm/xfrm_user.c | 11 +++++++++++
8 files changed, 47 insertions(+), 20 deletions(-)
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index 18d7de34a5..9c7b70cce6 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -165,6 +165,7 @@ struct xfrm_state {
int header_len;
int trailer_len;
u32 extra_flags;
+ u32 output_mark;
} props;
struct xfrm_lifetime_cfg lft;
@@ -298,10 +299,12 @@ struct xfrm_policy_afinfo {
struct dst_entry *(*dst_lookup)(struct net *net,
int tos, int oif,
const xfrm_address_t *saddr,
- const xfrm_address_t *daddr);
+ const xfrm_address_t *daddr,
+ u32 mark);
int (*get_saddr)(struct net *net, int oif,
xfrm_address_t *saddr,
- xfrm_address_t *daddr);
+ xfrm_address_t *daddr,
+ u32 mark);
void (*decode_session)(struct sk_buff *skb,
struct flowi *fl,
int reverse);
@@ -1640,7 +1643,7 @@ static inline int xfrm4_udp_encap_rcv(struct sock *sk, struct sk_buff *skb)
struct dst_entry *__xfrm_dst_lookup(struct net *net, int tos, int oif,
const xfrm_address_t *saddr,
const xfrm_address_t *daddr,
- int family);
+ int family, u32 mark);
struct xfrm_policy *xfrm_policy_alloc(struct net *net, gfp_t gfp);
diff --git a/include/uapi/linux/xfrm.h b/include/uapi/linux/xfrm.h
index 2b384ff09f..5fe7370a2b 100644
--- a/include/uapi/linux/xfrm.h
+++ b/include/uapi/linux/xfrm.h
@@ -304,6 +304,7 @@ enum xfrm_attr_type_t {
XFRMA_ADDRESS_FILTER, /* struct xfrm_address_filter */
XFRMA_PAD,
XFRMA_OFFLOAD_DEV, /* struct xfrm_state_offload */
+ XFRMA_OUTPUT_MARK, /* __u32 */
__XFRMA_MAX
#define XFRMA_MAX (__XFRMA_MAX - 1)
diff --git a/net/ipv4/xfrm4_policy.c b/net/ipv4/xfrm4_policy.c
index 4aefb149fe..d7bf0b0418 100644
--- a/net/ipv4/xfrm4_policy.c
+++ b/net/ipv4/xfrm4_policy.c
@@ -20,7 +20,8 @@
static struct dst_entry *__xfrm4_dst_lookup(struct net *net, struct flowi4 *fl4,
int tos, int oif,
const xfrm_address_t *saddr,
- const xfrm_address_t *daddr)
+ const xfrm_address_t *daddr,
+ u32 mark)
{
struct rtable *rt;
@@ -28,6 +29,7 @@ static struct dst_entry *__xfrm4_dst_lookup(struct net *net, struct flowi4 *fl4,
fl4->daddr = daddr->a4;
fl4->flowi4_tos = tos;
fl4->flowi4_oif = l3mdev_master_ifindex_by_index(net, oif);
+ fl4->flowi4_mark = mark;
if (saddr)
fl4->saddr = saddr->a4;
@@ -42,20 +44,22 @@ static struct dst_entry *__xfrm4_dst_lookup(struct net *net, struct flowi4 *fl4,
static struct dst_entry *xfrm4_dst_lookup(struct net *net, int tos, int oif,
const xfrm_address_t *saddr,
- const xfrm_address_t *daddr)
+ const xfrm_address_t *daddr,
+ u32 mark)
{
struct flowi4 fl4;
- return __xfrm4_dst_lookup(net, &fl4, tos, oif, saddr, daddr);
+ return __xfrm4_dst_lookup(net, &fl4, tos, oif, saddr, daddr, mark);
}
static int xfrm4_get_saddr(struct net *net, int oif,
- xfrm_address_t *saddr, xfrm_address_t *daddr)
+ xfrm_address_t *saddr, xfrm_address_t *daddr,
+ u32 mark)
{
struct dst_entry *dst;
struct flowi4 fl4;
- dst = __xfrm4_dst_lookup(net, &fl4, 0, oif, NULL, daddr);
+ dst = __xfrm4_dst_lookup(net, &fl4, 0, oif, NULL, daddr, mark);
if (IS_ERR(dst))
return -EHOSTUNREACH;
diff --git a/net/ipv6/xfrm6_policy.c b/net/ipv6/xfrm6_policy.c
index f44b25a484..11d1314ab6 100644
--- a/net/ipv6/xfrm6_policy.c
+++ b/net/ipv6/xfrm6_policy.c
@@ -27,7 +27,8 @@
static struct dst_entry *xfrm6_dst_lookup(struct net *net, int tos, int oif,
const xfrm_address_t *saddr,
- const xfrm_address_t *daddr)
+ const xfrm_address_t *daddr,
+ u32 mark)
{
struct flowi6 fl6;
struct dst_entry *dst;
@@ -36,6 +37,7 @@ static struct dst_entry *xfrm6_dst_lookup(struct net *net, int tos, int oif,
memset(&fl6, 0, sizeof(fl6));
fl6.flowi6_oif = l3mdev_master_ifindex_by_index(net, oif);
fl6.flowi6_flags = FLOWI_FLAG_SKIP_NH_OIF;
+ fl6.flowi6_mark = mark;
memcpy(&fl6.daddr, daddr, sizeof(fl6.daddr));
if (saddr)
memcpy(&fl6.saddr, saddr, sizeof(fl6.saddr));
@@ -52,12 +54,13 @@ static struct dst_entry *xfrm6_dst_lookup(struct net *net, int tos, int oif,
}
static int xfrm6_get_saddr(struct net *net, int oif,
- xfrm_address_t *saddr, xfrm_address_t *daddr)
+ xfrm_address_t *saddr, xfrm_address_t *daddr,
+ u32 mark)
{
struct dst_entry *dst;
struct net_device *dev;
- dst = xfrm6_dst_lookup(net, 0, oif, NULL, daddr);
+ dst = xfrm6_dst_lookup(net, 0, oif, NULL, daddr, mark);
if (IS_ERR(dst))
return -EHOSTUNREACH;
diff --git a/net/xfrm/xfrm_device.c b/net/xfrm/xfrm_device.c
index 1904127f5f..acf00104ef 100644
--- a/net/xfrm/xfrm_device.c
+++ b/net/xfrm/xfrm_device.c
@@ -79,7 +79,8 @@ int xfrm_dev_state_add(struct net *net, struct xfrm_state *x,
daddr = &x->props.saddr;
}
- dst = __xfrm_dst_lookup(net, 0, 0, saddr, daddr, x->props.family);
+ dst = __xfrm_dst_lookup(net, 0, 0, saddr, daddr,
+ x->props.family, x->props.output_mark);
if (IS_ERR(dst))
return 0;
diff --git a/net/xfrm/xfrm_output.c b/net/xfrm/xfrm_output.c
index 8c0b6722aa..31a2e6d34d 100644
--- a/net/xfrm/xfrm_output.c
+++ b/net/xfrm/xfrm_output.c
@@ -66,6 +66,9 @@ static int xfrm_output_one(struct sk_buff *skb, int err)
goto error_nolock;
}
+ if (x->props.output_mark)
+ skb->mark = x->props.output_mark;
+
err = x->outer_mode->output(x, skb);
if (err) {
XFRM_INC_STATS(net, LINUX_MIB_XFRMOUTSTATEMODEERROR);
diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
index 06c3bf7ab8..1de52f36ca 100644
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -122,7 +122,7 @@ static const struct xfrm_policy_afinfo *xfrm_policy_get_afinfo(unsigned short fa
struct dst_entry *__xfrm_dst_lookup(struct net *net, int tos, int oif,
const xfrm_address_t *saddr,
const xfrm_address_t *daddr,
- int family)
+ int family, u32 mark)
{
const struct xfrm_policy_afinfo *afinfo;
struct dst_entry *dst;
@@ -131,7 +131,7 @@ struct dst_entry *__xfrm_dst_lookup(struct net *net, int tos, int oif,
if (unlikely(afinfo == NULL))
return ERR_PTR(-EAFNOSUPPORT);
- dst = afinfo->dst_lookup(net, tos, oif, saddr, daddr);
+ dst = afinfo->dst_lookup(net, tos, oif, saddr, daddr, mark);
rcu_read_unlock();
@@ -143,7 +143,7 @@ static inline struct dst_entry *xfrm_dst_lookup(struct xfrm_state *x,
int tos, int oif,
xfrm_address_t *prev_saddr,
xfrm_address_t *prev_daddr,
- int family)
+ int family, u32 mark)
{
struct net *net = xs_net(x);
xfrm_address_t *saddr = &x->props.saddr;
@@ -159,7 +159,7 @@ static inline struct dst_entry *xfrm_dst_lookup(struct xfrm_state *x,
daddr = x->coaddr;
}
- dst = __xfrm_dst_lookup(net, tos, oif, saddr, daddr, family);
+ dst = __xfrm_dst_lookup(net, tos, oif, saddr, daddr, family, mark);
if (!IS_ERR(dst)) {
if (prev_saddr != saddr)
@@ -1340,14 +1340,14 @@ int __xfrm_sk_clone_policy(struct sock *sk, const struct sock *osk)
static int
xfrm_get_saddr(struct net *net, int oif, xfrm_address_t *local,
- xfrm_address_t *remote, unsigned short family)
+ xfrm_address_t *remote, unsigned short family, u32 mark)
{
int err;
const struct xfrm_policy_afinfo *afinfo = xfrm_policy_get_afinfo(family);
if (unlikely(afinfo == NULL))
return -EINVAL;
- err = afinfo->get_saddr(net, oif, local, remote);
+ err = afinfo->get_saddr(net, oif, local, remote, mark);
rcu_read_unlock();
return err;
}
@@ -1378,7 +1378,7 @@ xfrm_tmpl_resolve_one(struct xfrm_policy *policy, const struct flowi *fl,
if (xfrm_addr_any(local, tmpl->encap_family)) {
error = xfrm_get_saddr(net, fl->flowi_oif,
&tmp, remote,
- tmpl->encap_family);
+ tmpl->encap_family, 0);
if (error)
goto fail;
local = &tmp;
@@ -1598,7 +1598,8 @@ static struct dst_entry *xfrm_bundle_create(struct xfrm_policy *policy,
if (xfrm[i]->props.mode != XFRM_MODE_TRANSPORT) {
family = xfrm[i]->props.family;
dst = xfrm_dst_lookup(xfrm[i], tos, fl->flowi_oif,
- &saddr, &daddr, family);
+ &saddr, &daddr, family,
+ xfrm[i]->props.output_mark);
err = PTR_ERR(dst);
if (IS_ERR(dst))
goto put_states;
diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
index ffe8d5ef09..cc3268d814 100644
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -584,6 +584,9 @@ static struct xfrm_state *xfrm_state_construct(struct net *net,
xfrm_mark_get(attrs, &x->mark);
+ if (attrs[XFRMA_OUTPUT_MARK])
+ x->props.output_mark = nla_get_u32(attrs[XFRMA_OUTPUT_MARK]);
+
err = __xfrm_init_state(x, false, attrs[XFRMA_OFFLOAD_DEV]);
if (err)
goto error;
@@ -899,6 +902,11 @@ static int copy_to_user_state_extra(struct xfrm_state *x,
goto out;
if (x->security)
ret = copy_sec_ctx(x->security, skb);
+ if (x->props.output_mark) {
+ ret = nla_put_u32(skb, XFRMA_OUTPUT_MARK, x->props.output_mark);
+ if (ret)
+ goto out;
+ }
out:
return ret;
}
@@ -2454,6 +2462,7 @@ static const struct nla_policy xfrma_policy[XFRMA_MAX+1] = {
[XFRMA_PROTO] = { .type = NLA_U8 },
[XFRMA_ADDRESS_FILTER] = { .len = sizeof(struct xfrm_address_filter) },
[XFRMA_OFFLOAD_DEV] = { .len = sizeof(struct xfrm_user_offload) },
+ [XFRMA_OUTPUT_MARK] = { .len = NLA_U32 },
};
static const struct nla_policy xfrma_spd_policy[XFRMA_SPD_MAX+1] = {
@@ -2673,6 +2682,8 @@ static inline size_t xfrm_sa_len(struct xfrm_state *x)
l += nla_total_size(sizeof(x->props.extra_flags));
if (x->xso.dev)
l += nla_total_size(sizeof(x->xso));
+ if (x->props.output_mark)
+ l += nla_total_size(sizeof(x->props.output_mark));
/* Must count x->lastused as it may become non-zero behind our back. */
l += nla_total_size_64bit(sizeof(u64));
--
2.14.0.434.g98096fd7a8-goog
^ permalink raw reply related
* Re: [PATCH RFC net-next] net: Allow name change of IFF_UP interfaces
From: Stephen Hemminger @ 2017-08-10 17:16 UTC (permalink / raw)
To: David Ahern
Cc: David Miller, andrew, vkuznets, eric.dumazet, netdev, edumazet
In-Reply-To: <88b507b7-1b60-5100-3e31-b68263f0f631@gmail.com>
On Thu, 10 Aug 2017 10:55:01 -0600
David Ahern <dsahern@gmail.com> wrote:
> On 8/10/17 10:48 AM, David Miller wrote:
> > From: Andrew Lunn <andrew@lunn.ch>
> > Date: Thu, 10 Aug 2017 18:27:22 +0200
> >
> >> On Thu, Aug 10, 2017 at 05:24:55PM +0200, Vitaly Kuznetsov wrote:
> >>> Andrew Lunn <andrew@lunn.ch> writes:
> >>>
> >>>>> We are - rtnetlink_event() does the job. We, however, don't have a
> >>>>> special IFLA_EVENT_* for name change and end up with IFLA_EVENT_NONE.
> >>>>
> >>>> What is in this event? Old and new name? Just the new name?
> >>>
> >>> Basically, it's everything we know about the interface - type, index,
> >>> name, mtu, qdisc, ... - see rtnl_fill_ifinfo(). Back to your question -
> >>> it's only the new name.
> >>
> >> So the program needs to keep track of ifindex to know which interface
> >> has changed name. Doable.
> >>
> >> I still expect this has the potential to break something. You probably
> >> should be asking on linux-api for the API experts opinion.
> >
> > But a greater point is that nobody is monitoring device renames
> > explicitly right now.
>
> Just to throw in an example:
> https://github.com/kobolabs/dhcpcd/blob/kobo/if-linux.c#L761
>
> Learned of its use from a recent regression:
> https://bugzilla.kernel.org/show_bug.cgi?id=196355
Quagga is another example of what might break. Especially with all the new
forks..
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2017-08-10 17:21 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
1) Fix handling of initial STATE message in TIPC, from Jon Paul
Maloy.
2) Fix stats handling in bcm_sysport_get_stats(), from Florian
Fainelli.
3) Reject 16777215 VNI value in geneve_validate(), from Girish
Moodalbail.
4) Fix initial IGMP sysctl setting regression, from Nikolay Borisov.
5) Once a UFO fragmented frame is treated as UFO, we should continue
doing so. Likewise once a frame has been segmented, we should
continue doing that and not try to convert it to a UFO frame.
From Willem de Bruijn.
6) Test the AF_PACKET RX/TX ring pg_vec state under the socket lock
to prevent races. From Willem de Bruijn.
Please pull, thanks a lot!
The following changes since commit 48fb6f4db940e92cfb16cd878cddd59ea6120d06:
futex: Remove unnecessary warning from get_futex_key (2017-08-09 14:00:54 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
for you to fetch changes up to c27927e372f0785f3303e8fad94b85945e2c97b7:
packet: fix tp_reserve race in packet_set_ring (2017-08-10 09:52:12 -0700)
----------------------------------------------------------------
Florian Fainelli (1):
net: systemport: Fix software statistics for SYSTEMPORT Lite
Girish Moodalbail (1):
geneve: maximum value of VNI cannot be used
Jon Paul Maloy (1):
tipc: remove premature ESTABLISH FSM event at link synchronization
Nikolay Borisov (1):
igmp: Fix regression caused by igmp sysctl namespace code.
Willem de Bruijn (2):
udp: consistently apply ufo or fragmentation
packet: fix tp_reserve race in packet_set_ring
Xin Long (1):
net: sched: set xt_tgchk_param par.nft_compat as 0 in ipt_init_target
drivers/net/ethernet/broadcom/bcmsysport.c | 4 ++++
drivers/net/geneve.c | 2 +-
net/ipv4/af_inet.c | 7 +++++++
net/ipv4/igmp.c | 6 ------
net/ipv4/ip_output.c | 8 +++++---
net/ipv4/udp.c | 2 +-
net/ipv6/ip6_output.c | 7 ++++---
net/packet/af_packet.c | 13 +++++++++----
net/sched/act_ipt.c | 2 +-
net/tipc/node.c | 4 +---
10 files changed, 33 insertions(+), 22 deletions(-)
^ permalink raw reply
* Re: Regression: Bug 196547 - Since 4.12 - bonding module not working with wireless drivers
From: Andreas Born @ 2017-08-10 17:52 UTC (permalink / raw)
To: Arend van Spriel
Cc: Kalle Valo, Mahesh Bandewar, Andy Gospodarek, David Miller,
netdev, linux-wireless, James Feeney
In-Reply-To: <8845e49b-3165-e6df-5935-c86278d220d9@broadcom.com>
Hi everyone,
2017-08-10 14:43 GMT+02:00 Arend van Spriel <arend.vanspriel@broadcom.com>:
>
>
> On 10-08-17 07:39, Kalle Valo wrote:
>>
>> Hi Mahesh and Andy,
>>
>> James Feeney reported that there's a serious regression in bonding
>> module since v4.12, it doesn't work with wireless drivers anymore as
>> wireless drivers don't report the link speed via ethtool:
>>
>> https://bugzilla.kernel.org/show_bug.cgi?id=196547
>>
>> In the bug report it's said that this commit is the culprit:
>>
>> 3f3c278c94dd bonding: fix active-backup transition
>
>
> This commit references another one. ie. commit c4adfc822bf5 ("bonding: make speed, duplex setting consistent with link state"). Before this commit the result of __ethtool_get_link_ksettings() was simply ignored.
Actually it was not simply ignored in any case: Further down in
bond_miimon_commit() there's a conditional call to
bond_3ad_handle_link_change() which triggers an update using
__get_link_speed() to actually access the result. A similar handler is
also called for lb modes.
>
> Commit 3f3c278c94dd ("bonding: fix active-backup transition") moves setting the link state to the call sites of bond_update_speed_duplex(), just not all call sites.
>
>> Is there a fix for this or should that commit be reverted? This seems to
>> be a serious regression as there are multiple reports already and we
>> should get it fixed for v4.13, and the fix backported to v4.12 stable
>> release.
>
>
> The ethtool callbacks really seem optional. At least in brcmfmac, the wireless driver I maintain, I only provide get_drvinfo callback and there is no warning triggered upon registering the netdev. The changes above now require each netdev to implement the get_link_ksettings callback (get_settings is deprecated) or the link is marked as DOWN ruling it out to be used as active bond slave. To the end-users who were using bonding this is simply a regression. So to fix that both changes should be reverted in my opinion.
Yes, also to me as user of a wireless slave in an active-backup bond
it's clearly a regression. But only partially for some modes like
active-backup since the bonding documentation [1] clearly lists as a
prerequisite
1) for 802.3ad: "Ethtool support in the base drivers for retrieving
the speed and duplex of each slave."
2) for tlb/alb: "Ethtool support in the base drivers for retrieving
the speed of each slave."
This was previously not directly enforced in the bonding code and thus
probably occasionally caused unexpected behavior. At least such
behavior is what to my understanding commit c4adfc822bf5 ("bonding:
make speed, duplex setting consistent with link state") and
3f3c278c94dd ("bonding: fix active-backup transition") intend to fix
with an apparent focus on 802.3ad. However those commits went too far
by requiring a get_link_ksettings implementation by every slave driver
REGARDLESS of the bond mode.
Earlier today I submitted the patch (bonding: require speed/duplex
only for 802.3ad, alb and tlb) [2] that only partially reverts what is
a regression following my aforementioned logic. This seems to me like
the best solution in the short term since it should satisfy both
usergroups represented by Mahesh and James and restores consistence
with the bonding documentation. James already commented approvingly on
that patch in the bug report. [3]
Regards
Andreas
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/networking/bonding.txt
[2] https://www.spinics.net/lists/netdev/msg448662.html
[3] https://bugzilla.kernel.org/show_bug.cgi?id=196547#c10
^ permalink raw reply
* Re: [net-next 03/12] e1000e: add check on e1e_wphy() return value
From: Joe Perches @ 2017-08-10 17:56 UTC (permalink / raw)
To: Jeff Kirsher, davem
Cc: Gustavo A R Silva, netdev, nhorman, sassmann, jogreene
In-Reply-To: <20170809214746.28139-4-jeffrey.t.kirsher@intel.com>
On Wed, 2017-08-09 at 14:47 -0700, Jeff Kirsher wrote:
> From: Gustavo A R Silva <garsilva@embeddedor.com>
>
> Check return value from call to e1e_wphy(). This value is being
> checked during previous calls to function e1e_wphy() and it seems
> a check was missing here.
The use of "it seems" here is less than compelling.
Perhaps the write of 0x3140 to MII_BMCR takes too long for
the return value used.
Many other uses of e1e_wphy.*MII_BMCR are also not checked.
For instance: the e100e/ethtool uses.
> diff --git a/drivers/net/ethernet/intel/e1000e/ich8lan.c b/drivers/net/ethernet/intel/e1000e/ich8lan.c
[]
> @@ -2437,6 +2437,8 @@ static s32 e1000_hv_phy_workarounds_ich8lan(struct e1000_hw *hw)
> if (hw->phy.revision < 2) {
> e1000e_phy_sw_reset(hw);
> ret_val = e1e_wphy(hw, MII_BMCR, 0x3140);
> + if (ret_val)
> + return ret_val;
> }
> }
>
^ permalink raw reply
* Re: unregister_netdevice: waiting for eth0 to become free. Usage count = 1
From: John Stultz @ 2017-08-10 18:12 UTC (permalink / raw)
To: Wei Wang
Cc: Cong Wang, lkml, Network Development, Linux USB List,
David S. Miller, Felipe Balbi
In-Reply-To: <CAEA6p_AOcNkAWPc7NFBnr8QWi3eHdJiQ2=8D_DB_XthwSDL2+Q@mail.gmail.com>
On Wed, Aug 9, 2017 at 10:41 PM, Wei Wang <weiwan@google.com> wrote:
> Hi John,
>
> Is it possible to try the attached patch?
Thanks so much for the quick turn around!
So I dropped all the reverts you suggested, and applied this one
against 4.13-rc4, but I'm still seeing the problematic behavior.
> I am not sure if it actually fixes the issue. But I think it is worth a try.
> Also, could you get me all the ipv6 routes when you plug in the usb
> using "ip -6 route show"? (If you have multiple routing tables
> configured, could you dump them all?)
# ip -6 route show
2601:1c2:1002:83f0::/64 dev eth0 proto kernel metric 256 expires
345599sec pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
default via fe80::200:caff:fe11:2233 dev eth0 proto ra metric 1024
expires 1799sec hoplimit 64 pref medium
After unplugging the device (and getting the unregister_netdevice errors):
# ip -6 route show
#
thanks
-john
^ permalink raw reply
* Re: [PATCH V4 net 0/2] ipv6: fix flowlabel issue for reset packet
From: Tom Herbert @ 2017-08-10 18:30 UTC (permalink / raw)
To: Shaohua Li; +Cc: Linux Kernel Network Developers, David S. Miller, Shaohua Li
In-Reply-To: <20170810163033.kriwd2pivmuuzfnb@kernel.org>
On Thu, Aug 10, 2017 at 9:30 AM, Shaohua Li <shli@kernel.org> wrote:
> On Wed, Aug 09, 2017 at 09:40:08AM -0700, Tom Herbert wrote:
>> On Mon, Jul 31, 2017 at 3:19 PM, Shaohua Li <shli@kernel.org> wrote:
>> > From: Shaohua Li <shli@fb.com>
>> >
>> > Please see below tcpdump output:
>> > 21:00:48.109122 IP6 (flowlabel 0x43304, hlim 64, next-header TCP (6) payload length: 40) fec0::5054:ff:fe12:3456.55804 > fec0::5054:ff:fe12:3456.5555: Flags [S], cksum 0x0529 (incorrect -> 0xf56c), seq 3282214508, win 43690, options [mss 65476,sackOK,TS val 2500903437 ecr 0,nop,wscale 7], length 0
>> > 21:00:48.109381 IP6 (flowlabel 0xd827f, hlim 64, next-header TCP (6) payload length: 40) fec0::5054:ff:fe12:3456.5555 > fec0::5054:ff:fe12:3456.55804: Flags [S.], cksum 0x0529 (incorrect -> 0x49ad), seq 1923801573, ack 3282214509, win 43690, options [mss 65476,sackOK,TS val 2500903437 ecr 2500903437,nop,wscale 7], length 0
>> > 21:00:48.109548 IP6 (flowlabel 0x43304, hlim 64, next-header TCP (6) payload length: 32) fec0::5054:ff:fe12:3456.55804 > fec0::5054:ff:fe12:3456.5555: Flags [.], cksum 0x0521 (incorrect -> 0x1bdf), seq 1, ack 1, win 342, options [nop,nop,TS val 2500903437 ecr 2500903437], length 0
>> > 21:00:48.109823 IP6 (flowlabel 0x43304, hlim 64, next-header TCP (6) payload length: 62) fec0::5054:ff:fe12:3456.55804 > fec0::5054:ff:fe12:3456.5555: Flags [P.], cksum 0x053f (incorrect -> 0xb8b1), seq 1:31, ack 1, win 342, options [nop,nop,TS val 2500903437 ecr 2500903437], length 30
>> > 21:00:48.109910 IP6 (flowlabel 0xd827f, hlim 64, next-header TCP (6) payload length: 32) fec0::5054:ff:fe12:3456.5555 > fec0::5054:ff:fe12:3456.55804: Flags [.], cksum 0x0521 (incorrect -> 0x1bc1), seq 1, ack 31, win 342, options [nop,nop,TS val 2500903437 ecr 2500903437], length 0
>> > 21:00:48.110043 IP6 (flowlabel 0xd827f, hlim 64, next-header TCP (6) payload length: 56) fec0::5054:ff:fe12:3456.5555 > fec0::5054:ff:fe12:3456.55804: Flags [P.], cksum 0x0539 (incorrect -> 0xb726), seq 1:25, ack 31, win 342, options [nop,nop,TS val 2500903438 ecr 2500903437], length 24
>> > 21:00:48.110173 IP6 (flowlabel 0x43304, hlim 64, next-header TCP (6) payload length: 32) fec0::5054:ff:fe12:3456.55804 > fec0::5054:ff:fe12:3456.5555: Flags [.], cksum 0x0521 (incorrect -> 0x1ba7), seq 31, ack 25, win 342, options [nop,nop,TS val 2500903438 ecr 2500903438], length 0
>> > 21:00:48.110211 IP6 (flowlabel 0xd827f, hlim 64, next-header TCP (6) payload length: 32) fec0::5054:ff:fe12:3456.5555 > fec0::5054:ff:fe12:3456.55804: Flags [F.], cksum 0x0521 (incorrect -> 0x1ba7), seq 25, ack 31, win 342, options [nop,nop,TS val 2500903438 ecr 2500903437], length 0
>> > 21:00:48.151099 IP6 (flowlabel 0x43304, hlim 64, next-header TCP (6) payload length: 32) fec0::5054:ff:fe12:3456.55804 > fec0::5054:ff:fe12:3456.5555: Flags [.], cksum 0x0521 (incorrect -> 0x1ba6), seq 31, ack 26, win 342, options [nop,nop,TS val 2500903438 ecr 2500903438], length 0
>> > 21:00:49.110524 IP6 (flowlabel 0x43304, hlim 64, next-header TCP (6) payload length: 56) fec0::5054:ff:fe12:3456.55804 > fec0::5054:ff:fe12:3456.5555: Flags [P.], cksum 0x0539 (incorrect -> 0xb324), seq 31:55, ack 26, win 342, options [nop,nop,TS val 2500904438 ecr 2500903438], length 24
>> > 21:00:49.110637 IP6 (flowlabel 0xb34d5, hlim 64, next-header TCP (6) payload length: 20) fec0::5054:ff:fe12:3456.5555 > fec0::5054:ff:fe12:3456.55804: Flags [R], cksum 0x0515 (incorrect -> 0x668c), seq 1923801599, win 0, length 0
>> >
>> > The flowlabel of reset packet (0xb34d5) and flowlabel of normal packet
>> > (0xd827f) are different. This causes our router doesn't correctly close tcp
>> > connection. The patches try to fix the issue.
>> >
>> Shaohua,
>>
>> Can you give some more detail about what the router doesn't close the
>> TCP connection means? I'm guessing the problem is either: 1) the
>> router is maintaining connection state that includes the flow label in
>> a connection tuple. 2) some router in the path is maintaining
>> connection state, but when the flow label changes the flow's packet
>> are routed through a different router that doesn't have a state for
>> the flow it drops the packet. #1 should be easily fix in the router,
>> flow labels cannot be used as state. #2 is the known problem that
>> stateful firewalls have killed our ability to use multihoming.
>
> The #2 is exactly the problem we saw.
>
>> Another consideration is that sk_txhash is also used in routing
>> decisions by the local host (flow label is normally derived from
>> txhash). If you want to ensure that connections are routed
>> consistently for timewait state you might need sk_txhash saved also.
>
> As far as I understood, we don't use sk_txhash for routing selection. The code
> does routing selection with flowlabel user configured, at that time we don't
> derive fl6.flowlabel from skb->hash (which is from sk_txhash). The code always
> does routing selection first and then uses ip6_make_flowlabel to build packet
> data where we derive flowlabel from skb->hash.
>
That is assuming one particular use case. Generally, if you want to
ensure all packets for a flow take the same path you'll need tx_hash
and make it persistent (disable flow bender). For instance, if you
were doing UDP encapsulation like in VXLAN the UDP source port
selection is unaffected by saved flow label for the lifetime of the
flow. So we would still hit #2 in that case and the stateful device
doesn't see whole flow. It might be just as easy to move tx_hash in
skc_common so that it's available in TW state for this purpose. Then
when moving to TW state just copy the tx_hash.
Tom
> Thanks,
> Shaohua
^ permalink raw reply
* Re: [PATCH] bonding: require speed/duplex only for 802.3ad, alb and tlb
From: Mahesh Bandewar (महेश बंडेवार) @ 2017-08-10 19:04 UTC (permalink / raw)
To: Andreas Born; +Cc: linux-netdev
In-Reply-To: <20170810044144.17398-1-futur.andy@googlemail.com>
On Wed, Aug 9, 2017 at 9:41 PM, Andreas Born <futur.andy@googlemail.com> wrote:
> The patch c4adfc822bf5 ("bonding: make speed, duplex setting consistent
> with link state") puts the link state to down if
> bond_update_speed_duplex() cannot retrieve speed and duplex settings.
> Assumably the patch was written with 802.3ad mode in mind which relies
> on link speed/duplex settings. For other modes like active-backup these
> settings are not required.
> Thus, only for these other modes, this patch
> reintroduces support for slaves that do not support reporting speed or
> duplex such as wireless devices. This fixes the regression reported in
> bug 196547 (https://bugzilla.kernel.org/show_bug.cgi?id=196547).
>
> Fixes: c4adfc822bf5 ("bonding: make speed, duplex setting consistent
> with link state")
> Signed-off-by: Andreas Born <futur.andy@googlemail.com>
Acked-by: Mahesh Bandewar <maheshb@google.com>
> ---
> drivers/net/bonding/bond_main.c | 6 ++++--
> include/net/bonding.h | 5 +++++
> 2 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
> index 9bee6c1c70cc..85bb272d2a34 100644
> --- a/drivers/net/bonding/bond_main.c
> +++ b/drivers/net/bonding/bond_main.c
> @@ -1569,7 +1569,8 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev)
> new_slave->delay = 0;
> new_slave->link_failure_count = 0;
>
> - if (bond_update_speed_duplex(new_slave))
> + if (bond_update_speed_duplex(new_slave) &&
> + bond_needs_speed_duplex(bond))
> new_slave->link = BOND_LINK_DOWN;
>
> new_slave->last_rx = jiffies -
> @@ -2140,7 +2141,8 @@ static void bond_miimon_commit(struct bonding *bond)
> continue;
>
> case BOND_LINK_UP:
> - if (bond_update_speed_duplex(slave)) {
> + if (bond_update_speed_duplex(slave) &&
> + bond_needs_speed_duplex(bond)) {
> slave->link = BOND_LINK_DOWN;
> netdev_warn(bond->dev,
> "failed to get link speed/duplex for %s\n",
> diff --git a/include/net/bonding.h b/include/net/bonding.h
> index b00508d22e0a..b2e68657a216 100644
> --- a/include/net/bonding.h
> +++ b/include/net/bonding.h
> @@ -277,6 +277,11 @@ static inline bool bond_is_lb(const struct bonding *bond)
> BOND_MODE(bond) == BOND_MODE_ALB;
> }
>
> +static inline bool bond_needs_speed_duplex(const struct bonding *bond)
> +{
> + return BOND_MODE(bond) == BOND_MODE_8023AD || bond_is_lb(bond);
> +}
> +
> static inline bool bond_is_nondyn_tlb(const struct bonding *bond)
> {
> return (BOND_MODE(bond) == BOND_MODE_TLB) &&
> --
> 2.14.0
>
^ 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