* Re: [PATCH] net: dsa: Remove documentation for port_fdb_prepare
From: David Miller @ 2019-02-24 2:38 UTC (permalink / raw)
To: hauke; +Cc: arkadis, netdev, linux-doc
In-Reply-To: <20190222190745.28020-1-hauke@hauke-m.de>
From: Hauke Mehrtens <hauke@hauke-m.de>
Date: Fri, 22 Feb 2019 20:07:45 +0100
> This callback was removed some time ago, also remove the documentation.
>
> Fixes: 1b6dd556c304 ("net: dsa: Remove prepare phase for FDB")
> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Applied.
^ permalink raw reply
* Re: [PATCH net] Revert "bridge: do not add port to router list when receives query with source 0.0.0.0"
From: David Miller @ 2019-02-24 2:36 UTC (permalink / raw)
To: liuhangbin
Cc: netdev, nikolay, roopa, bridge, yinxu, gregkh, stable,
s.gottschall, linus.luessing
In-Reply-To: <20190222132232.24123-1-liuhangbin@gmail.com>
From: Hangbin Liu <liuhangbin@gmail.com>
Date: Fri, 22 Feb 2019 21:22:32 +0800
> This reverts commit 5a2de63fd1a5 ("bridge: do not add port to router list
> when receives query with source 0.0.0.0") and commit 0fe5119e267f ("net:
> bridge: remove ipv6 zero address check in mcast queries")
>
> The reason is RFC 4541 is not a standard but suggestive. Currently we
> will elect 0.0.0.0 as Querier if there is no ip address configured on
> bridge. If we do not add the port which recives query with source
> 0.0.0.0 to router list, the IGMP reports will not be about to forward
> to Querier, IGMP data will also not be able to forward to dest.
>
> As Nikolay suggested, revert this change first and add a boolopt api
> to disable none-zero election in future if needed.
>
> Reported-by: Linus Lüssing <linus.luessing@c0d3.blue>
> Reported-by: Sebastian Gottschall <s.gottschall@newmedia-net.de>
> Fixes: 5a2de63fd1a5 ("bridge: do not add port to router list when receives query with source 0.0.0.0")
> Fixes: 0fe5119e267f ("net: bridge: remove ipv6 zero address check in mcast queries")
> Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH] selftests: fib_tests: sleep after changing carrier. again.
From: David Miller @ 2019-02-24 2:34 UTC (permalink / raw)
To: cascardo; +Cc: netdev, linux-kselftest, dsahern
In-Reply-To: <20190222102741.31173-1-cascardo@canonical.com>
From: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Date: Fri, 22 Feb 2019 07:27:41 -0300
> Just like commit e2ba732a1681 ("selftests: fib_tests: sleep after
> changing carrier"), wait one second to allow linkwatch to propagate the
> carrier change to the stack.
>
> There are two sets of carrier tests. The first slept after the carrier
> was set to off, and when the second set ran, it was likely that the
> linkwatch would be able to run again without much delay, reducing the
> likelihood of a race. However, if you run 'fib_tests.sh -t carrier' on a
> loop, you will quickly notice the failures.
>
> Sleeping on the second set of tests make the failures go away.
>
> Cc: David Ahern <dsahern@gmail.com>
> Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v3 net-next 2/2] net: sock: undefine SOCK_DEBUGGING
From: David Miller @ 2019-02-24 2:30 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: laoar.shao, daniel, edumazet, joe, netdev, shaoyafang
In-Reply-To: <CAM_iQpXLBR3gnheLTxeu_wkELs5jOS1+SaeiLZknA6sbC19NmA@mail.gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Sat, 23 Feb 2019 17:11:08 -0800
> On Sat, Feb 23, 2019 at 1:21 PM David Miller <davem@davemloft.net> wrote:
>>
>> You are forcing everyone who wants to use this to add a curstom local
>> source code change into their build.
>
> What's wrong with this? People carry custom changes in anyway,
> do we really need to care about all the downstream changes?
No way am I allowing this, sorry.
Either it's something in the tree that people can use or it's
a crap hack.
When we see stuff like this in a driver we ask the driver author to
remove it.
^ permalink raw reply
* [PATCH net-next] net: fix double-free in bpf_lwt_xmit_reroute
From: Peter Oskolkov @ 2019-02-24 2:25 UTC (permalink / raw)
To: David Miller, netdev; +Cc: Peter Oskolkov, Peter Oskolkov
dst_output() frees skb when it fails (see, for example,
ip_finish_output2), so it must not be freed in this case.
Fixes: 3bd0b15281af ("bpf: add handling of BPF_LWT_REROUTE to lwt_bpf.c")
Signed-off-by: Peter Oskolkov <posk@google.com>
---
net/core/lwt_bpf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/lwt_bpf.c b/net/core/lwt_bpf.c
index a5c8c79d468a..cf2f8897ca19 100644
--- a/net/core/lwt_bpf.c
+++ b/net/core/lwt_bpf.c
@@ -260,7 +260,7 @@ static int bpf_lwt_xmit_reroute(struct sk_buff *skb)
err = dst_output(dev_net(skb_dst(skb)->dev), skb->sk, skb);
if (unlikely(err))
- goto err;
+ return err;
/* ip[6]_finish_output2 understand LWTUNNEL_XMIT_DONE */
return LWTUNNEL_XMIT_DONE;
--
2.21.0.rc0.258.g878e2cd30e-goog
^ permalink raw reply related
* RE: kTLS getsockopt TLS_RX support
From: Vakul Garg @ 2019-02-24 1:50 UTC (permalink / raw)
To: Hayakawa Yutaro, netdev@vger.kernel.org
In-Reply-To: <7889DA1D-7671-4012-81E4-FB626F06B20F@gmail.com>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org <netdev-owner@vger.kernel.org> On
> Behalf Of Hayakawa Yutaro
> Sent: Saturday, February 23, 2019 10:59 PM
> To: netdev@vger.kernel.org
> Subject: kTLS getsockopt TLS_RX support
>
> Hello,
>
> While trying the kTLS, I found out that currently, there is no support for kTLS
> getsockopt TLS_RX which extracts receive side crypto information from kTLS
> socket. Since setting crypto information for RX side is supported, I felt
> wonder why it is not supported.
>
> Is there any particular reason for it?
What use case do you have in mind?
Why give back state of record layer which also contains (record sequence number) to user space?
>
> Regards,
> Yutaro
^ permalink raw reply
* Re: [PATCH v2 bpf-next 2/9] bpf: Add bpf helper bpf_tcp_enter_cwr
From: Eric Dumazet @ 2019-02-24 1:32 UTC (permalink / raw)
To: brakmo, netdev
Cc: Martin Lau, Alexei Starovoitov, Daniel Borkmann, Eric Dumazet,
Kernel Team
In-Reply-To: <20190223010703.678070-3-brakmo@fb.com>
On 02/22/2019 05:06 PM, brakmo wrote:
> From: Martin KaFai Lau <kafai@fb.com>
>
> This patch adds a new bpf helper BPF_FUNC_tcp_enter_cwr
> "int bpf_tcp_enter_cwr(struct bpf_tcp_sock *tp)".
> It is added to BPF_PROG_TYPE_CGROUP_SKB which can be attached
> to the egress path where the bpf prog is called by
> ip_finish_output() or ip6_finish_output(). The verifier
> ensures that the parameter must be a tcp_sock.
>
> This helper makes a tcp_sock enter CWR state. It can be used
> by a bpf_prog to manage egress network bandwidth limit per
> cgroupv2. A later patch will have a sample program to
> show how it can be used to limit bandwidth usage per cgroupv2.
>
> To ensure it is only called from BPF_CGROUP_INET_EGRESS, the
> attr->expected_attach_type must be specified as BPF_CGROUP_INET_EGRESS
> during load time if the prog uses this new helper.
> The newly added prog->enforce_expected_attach_type bit will also be set
> if this new helper is used. This bit is for backward compatibility reason
> because currently prog->expected_attach_type has been ignored in
> BPF_PROG_TYPE_CGROUP_SKB. During attach time,
> prog->expected_attach_type is only enforced if the
> prog->enforce_expected_attach_type bit is set.
> i.e. prog->expected_attach_type is only enforced if this new helper
> is used by the prog.
>
BTW, it seems to me that BPF_CGROUP_INET_EGRESS can be used while the socket lock is not held.
Maybe we should fix :/
^ permalink raw reply
* Re: [PATCH v3 net-next 2/2] net: sock: undefine SOCK_DEBUGGING
From: Cong Wang @ 2019-02-24 1:26 UTC (permalink / raw)
To: David Miller
Cc: Yafang Shao, Daniel Borkmann, Eric Dumazet, Joe Perches,
Linux Kernel Network Developers, shaoyafang
In-Reply-To: <20190223.132117.343025457687449183.davem@davemloft.net>
On Sat, Feb 23, 2019 at 1:21 PM David Miller <davem@davemloft.net> wrote:
>
> From: Yafang Shao <laoar.shao@gmail.com>
> Date: Sun, 17 Feb 2019 22:26:32 +0800
> > The reason why I don't remove it comepletely is that someone may still
> > would like to use it for debugging.
Please remove it completely.
The rule here is we upstream only care about in-tree users, any out-of-tree
user is beyond what we care. They either need to push their code that uses
this to upstream, or have to carry a revert downstream.
People carry downstream changes all the time, this one isn't an exception.
Let's respect rules.
Thanks.
^ permalink raw reply
* Re: [PATCH net] tcp: repaired skbs must init their tso_segs
From: Neal Cardwell @ 2019-02-24 1:17 UTC (permalink / raw)
To: Eric Dumazet
Cc: David S . Miller, netdev, Eric Dumazet, Soheil Hassas Yeganeh,
Yuchung Cheng, syzbot, Andrey Vagin
In-Reply-To: <20190223235151.168283-1-edumazet@google.com>
On Sat, Feb 23, 2019 at 6:51 PM Eric Dumazet <edumazet@google.com> wrote:
>
> syzbot reported a WARN_ON(!tcp_skb_pcount(skb))
> in tcp_send_loss_probe() [1]
>
> This was caused by TCP_REPAIR sent skbs that inadvertenly
> were missing a call to tcp_init_tso_segs()
>
Acked-by: Neal Cardwell <ncardwell@google.com>
Thanks, Eric!
neal
^ permalink raw reply
* Re: [PATCH v3 net-next 2/2] net: sock: undefine SOCK_DEBUGGING
From: Cong Wang @ 2019-02-24 1:11 UTC (permalink / raw)
To: David Miller
Cc: Yafang Shao, Daniel Borkmann, Eric Dumazet, Joe Perches,
Linux Kernel Network Developers, shaoyafang
In-Reply-To: <20190223.132117.343025457687449183.davem@davemloft.net>
On Sat, Feb 23, 2019 at 1:21 PM David Miller <davem@davemloft.net> wrote:
>
> You are forcing everyone who wants to use this to add a curstom local
> source code change into their build.
What's wrong with this? People carry custom changes in anyway,
do we really need to care about all the downstream changes?
If yes, can I just add some debugging prink's that no one is going
to use except me? My argument would be you can't force me
to add a custom local source code change.
Can we just play this fairly instead of just for any special people?
Thanks!
^ permalink raw reply
* Re: [PATCH v2] net: phy: realtek: Dummy IRQ calls for RTL8366RB
From: Andrew Lunn @ 2019-02-24 1:00 UTC (permalink / raw)
To: Linus Walleij; +Cc: Florian Fainelli, netdev, Heiner Kallweit
In-Reply-To: <20190224001115.17497-1-linus.walleij@linaro.org>
On Sun, Feb 24, 2019 at 01:11:15AM +0100, Linus Walleij wrote:
> This fixes a regression introduced by
> commit 0d2e778e38e0ddffab4bb2b0e9ed2ad5165c4bf7
> "net: phy: replace PHY_HAS_INTERRUPT with a check for
> config_intr and ack_interrupt".
>
> This assumes that a PHY cannot trigger interrupt unless
> it has .config_intr() or .ack_interrupt() implemented.
> A later patch makes the code assume both need to be
> implemented for interrupts to be present.
>
> But this PHY (which is inside a DSA) will happily
> fire interrupts without either callback.
>
> Implement dummy callbacks for .config_intr() and
> .ack_interrupt() in the phy header to fix this.
>
> Tested on the RTL8366RB on D-Link DIR-685.
>
> Fixes: 0d2e778e38e0 ("net: phy: replace PHY_HAS_INTERRUPT with a check for config_intr and ack_interrupt")
> Cc: Heiner Kallweit <hkallweit1@gmail.com>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* [PATCH net-next v3] ip_tunnel: Add ip tunnel tun_info type dst_cache in ip_tunnel_xmit
From: wenxu @ 2019-02-24 0:24 UTC (permalink / raw)
To: davem; +Cc: netdev
From: wenxu <wenxu@ucloud.cn>
ip l add dev tun type gretap key 1000
Non-tunnel-dst ip tunnel device can send packet through lwtunnel
This patch provide the tun_inf dst cache support for this mode.
Signed-off-by: wenxu <wenxu@ucloud.cn>
---
net/ipv4/ip_tunnel.c | 38 +++++++++++++++++++++++++++-----------
1 file changed, 27 insertions(+), 11 deletions(-)
diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
index 893f013..2973067 100644
--- a/net/ipv4/ip_tunnel.c
+++ b/net/ipv4/ip_tunnel.c
@@ -654,14 +654,17 @@ void ip_tunnel_xmit(struct sk_buff *skb, struct net_device *dev,
const struct iphdr *tnl_params, u8 protocol)
{
struct ip_tunnel *tunnel = netdev_priv(dev);
+ struct ip_tunnel_info *tun_info = NULL;
const struct iphdr *inner_iph;
- struct flowi4 fl4;
- u8 tos, ttl;
- __be16 df;
- struct rtable *rt; /* Route to the other host */
unsigned int max_headroom; /* The extra header space needed */
- __be32 dst;
+ struct rtable *rt = NULL; /* Route to the other host */
+ bool use_cache = false;
+ struct flowi4 fl4;
+ bool md = false;
bool connected;
+ u8 tos, ttl;
+ __be32 dst;
+ __be16 df;
inner_iph = (const struct iphdr *)skb_inner_network_header(skb);
connected = (tunnel->parms.iph.daddr != 0);
@@ -671,7 +674,6 @@ void ip_tunnel_xmit(struct sk_buff *skb, struct net_device *dev,
dst = tnl_params->daddr;
if (dst == 0) {
/* NBMA tunnel */
- struct ip_tunnel_info *tun_info;
if (!skb_dst(skb)) {
dev->stats.tx_fifo_errors++;
@@ -681,8 +683,11 @@ void ip_tunnel_xmit(struct sk_buff *skb, struct net_device *dev,
tun_info = skb_tunnel_info(skb);
if (tun_info && (tun_info->mode & IP_TUNNEL_INFO_TX) &&
ip_tunnel_info_af(tun_info) == AF_INET &&
- tun_info->key.u.ipv4.dst)
+ tun_info->key.u.ipv4.dst) {
dst = tun_info->key.u.ipv4.dst;
+ md = true;
+ connected = true;
+ }
else if (skb->protocol == htons(ETH_P_IP)) {
rt = skb_rtable(skb);
dst = rt_nexthop(rt, inner_iph->daddr);
@@ -721,7 +726,8 @@ void ip_tunnel_xmit(struct sk_buff *skb, struct net_device *dev,
else
goto tx_error;
- connected = false;
+ if (!md)
+ connected = false;
}
tos = tnl_params->tos;
@@ -743,8 +749,15 @@ void ip_tunnel_xmit(struct sk_buff *skb, struct net_device *dev,
if (ip_tunnel_encap(skb, tunnel, &protocol, &fl4) < 0)
goto tx_error;
- rt = connected ? dst_cache_get_ip4(&tunnel->dst_cache, &fl4.saddr) :
- NULL;
+ if (connected && md) {
+ use_cache = ip_tunnel_dst_cache_usable(skb, tun_info);
+ if (use_cache)
+ rt = dst_cache_get_ip4(&tun_info->dst_cache,
+ &fl4.saddr);
+ } else {
+ rt = connected ? dst_cache_get_ip4(&tunnel->dst_cache,
+ &fl4.saddr) : NULL;
+ }
if (!rt) {
rt = ip_route_output_key(tunnel->net, &fl4);
@@ -753,7 +766,10 @@ void ip_tunnel_xmit(struct sk_buff *skb, struct net_device *dev,
dev->stats.tx_carrier_errors++;
goto tx_error;
}
- if (connected)
+ if (use_cache)
+ dst_cache_set_ip4(&tun_info->dst_cache, &rt->dst,
+ fl4.saddr);
+ else if (!md && connected)
dst_cache_set_ip4(&tunnel->dst_cache, &rt->dst,
fl4.saddr);
}
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH] net: phy: realtek: Dummy IRQ calls for RTL8366RB
From: Linus Walleij @ 2019-02-24 0:14 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Florian Fainelli, netdev, Heiner Kallweit
In-Reply-To: <20190224000727.GB26626@lunn.ch>
On Sun, Feb 24, 2019 at 1:07 AM Andrew Lunn <andrew@lunn.ch> wrote:
> > They are handled by the irqchip mask/unmask inside
> > the RTL8366RB, see:
> > drivers/net/dsa/rtl8366rb.c
> >
> > So as soon as the phy core request the threaded IRQ
> > the irqchip will deal with this business on its own.
> >
> > How exactly the RTL8366RB IRQ machine looks inside
> > I doubt even Realtek knows themselves, but from
> > my experiements, they seem all edge triggered,
> > and the irq will be raised every time an edge occurse
> > (such as inserting or removing the cable). The "ACK"
> > happens in hardware when we read the status register
> > in the nested interrupt handler in rtl8366rb_irq() so no
> > further registers need to be accessed.
>
> Hi Linus
>
> Thanks for the explanation. So dummy functions are fine in this case.
>
> However, in general, i don't think dummy functions will work for a PHY
> driver, and may lead to interrupt storms. So it might be better to
> have them in the driver, not the core, with comments about why they
> are safe.
OK shall I just send a v3 moving them back to the driver so we avoid
confusion on which version should be applied?
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2] net: phy: realtek: Dummy IRQ calls for RTL8366RB
From: Linus Walleij @ 2019-02-24 0:11 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli; +Cc: netdev, Linus Walleij, Heiner Kallweit
This fixes a regression introduced by
commit 0d2e778e38e0ddffab4bb2b0e9ed2ad5165c4bf7
"net: phy: replace PHY_HAS_INTERRUPT with a check for
config_intr and ack_interrupt".
This assumes that a PHY cannot trigger interrupt unless
it has .config_intr() or .ack_interrupt() implemented.
A later patch makes the code assume both need to be
implemented for interrupts to be present.
But this PHY (which is inside a DSA) will happily
fire interrupts without either callback.
Implement dummy callbacks for .config_intr() and
.ack_interrupt() in the phy header to fix this.
Tested on the RTL8366RB on D-Link DIR-685.
Fixes: 0d2e778e38e0 ("net: phy: replace PHY_HAS_INTERRUPT with a check for config_intr and ack_interrupt")
Cc: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v1->v2:
- Define generic inline helpers for
genphy_no_ack_interrupt and genphy_no_config_intr
- Add a comment block explaining how interrupts are
unmasked and ACKed in the RTL8366RB internal irqchip
so it is clear what is going on.
---
drivers/net/phy/realtek.c | 7 +++++++
include/linux/phy.h | 8 ++++++++
2 files changed, 15 insertions(+)
diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
index c6010fb1aa0f..cb4a23041a94 100644
--- a/drivers/net/phy/realtek.c
+++ b/drivers/net/phy/realtek.c
@@ -282,6 +282,13 @@ static struct phy_driver realtek_drvs[] = {
.name = "RTL8366RB Gigabit Ethernet",
.features = PHY_GBIT_FEATURES,
.config_init = &rtl8366rb_config_init,
+ /* These interrupts are handled by the irq controller
+ * embedded inside the RTL8366RB, they get unmasked when the
+ * irq is requested and ACKed by reading the status register,
+ * which is done by the irqchip code.
+ */
+ .ack_interrupt = genphy_no_ack_interrupt,
+ .config_intr = genphy_no_config_intr,
.suspend = genphy_suspend,
.resume = genphy_resume,
},
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 127fcc9c3778..333b56d8f746 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -992,6 +992,14 @@ static inline int genphy_no_soft_reset(struct phy_device *phydev)
{
return 0;
}
+static inline int genphy_no_ack_interrupt(struct phy_device *phydev)
+{
+ return 0;
+}
+static inline int genphy_no_config_intr(struct phy_device *phydev)
+{
+ return 0;
+}
int genphy_read_mmd_unsupported(struct phy_device *phdev, int devad,
u16 regnum);
int genphy_write_mmd_unsupported(struct phy_device *phdev, int devnum,
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] net: phy: realtek: Dummy IRQ calls for RTL8366RB
From: Andrew Lunn @ 2019-02-24 0:07 UTC (permalink / raw)
To: Linus Walleij; +Cc: Florian Fainelli, netdev, Heiner Kallweit
In-Reply-To: <CACRpkdaisrc1h-9Pa70bswV0K8PPj=+YGNRBZXq5cqvRNirATw@mail.gmail.com>
> They are handled by the irqchip mask/unmask inside
> the RTL8366RB, see:
> drivers/net/dsa/rtl8366rb.c
>
> So as soon as the phy core request the threaded IRQ
> the irqchip will deal with this business on its own.
>
> How exactly the RTL8366RB IRQ machine looks inside
> I doubt even Realtek knows themselves, but from
> my experiements, they seem all edge triggered,
> and the irq will be raised every time an edge occurse
> (such as inserting or removing the cable). The "ACK"
> happens in hardware when we read the status register
> in the nested interrupt handler in rtl8366rb_irq() so no
> further registers need to be accessed.
Hi Linus
Thanks for the explanation. So dummy functions are fine in this case.
However, in general, i don't think dummy functions will work for a PHY
driver, and may lead to interrupt storms. So it might be better to
have them in the driver, not the core, with comments about why they
are safe.
Andrew
^ permalink raw reply
* Re: [PATCH net] tcp: repaired skbs must init their tso_segs
From: Soheil Hassas Yeganeh @ 2019-02-24 0:01 UTC (permalink / raw)
To: Eric Dumazet
Cc: David S . Miller, netdev, Eric Dumazet, Neal Cardwell,
Yuchung Cheng, syzbot, Andrey Vagin
In-Reply-To: <20190223235151.168283-1-edumazet@google.com>
On Sat, Feb 23, 2019 at 6:51 PM Eric Dumazet <edumazet@google.com> wrote:
>
> syzbot reported a WARN_ON(!tcp_skb_pcount(skb))
> in tcp_send_loss_probe() [1]
>
> This was caused by TCP_REPAIR sent skbs that inadvertenly
> were missing a call to tcp_init_tso_segs()
>
> [1]
> WARNING: CPU: 1 PID: 0 at net/ipv4/tcp_output.c:2534 tcp_send_loss_probe+0x771/0x8a0 net/ipv4/tcp_output.c:2534
> Kernel panic - not syncing: panic_on_warn set ...
> CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.0.0-rc7+ #77
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> Call Trace:
> <IRQ>
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x172/0x1f0 lib/dump_stack.c:113
> panic+0x2cb/0x65c kernel/panic.c:214
> __warn.cold+0x20/0x45 kernel/panic.c:571
> report_bug+0x263/0x2b0 lib/bug.c:186
> fixup_bug arch/x86/kernel/traps.c:178 [inline]
> fixup_bug arch/x86/kernel/traps.c:173 [inline]
> do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:271
> do_invalid_op+0x37/0x50 arch/x86/kernel/traps.c:290
> invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:973
> RIP: 0010:tcp_send_loss_probe+0x771/0x8a0 net/ipv4/tcp_output.c:2534
> Code: 88 fc ff ff 4c 89 ef e8 ed 75 c8 fb e9 c8 fc ff ff e8 43 76 c8 fb e9 63 fd ff ff e8 d9 75 c8 fb e9 94 f9 ff ff e8 bf 03 91 fb <0f> 0b e9 7d fa ff ff e8 b3 03 91 fb 0f b6 1d 37 43 7a 03 31 ff 89
> RSP: 0018:ffff8880ae907c60 EFLAGS: 00010206
> RAX: ffff8880a989c340 RBX: 0000000000000000 RCX: ffffffff85dedbdb
> RDX: 0000000000000100 RSI: ffffffff85dee0b1 RDI: 0000000000000005
> RBP: ffff8880ae907c90 R08: ffff8880a989c340 R09: ffffed10147d1ae1
> R10: ffffed10147d1ae0 R11: ffff8880a3e8d703 R12: ffff888091b90040
> R13: ffff8880a3e8d540 R14: 0000000000008000 R15: ffff888091b90860
> tcp_write_timer_handler+0x5c0/0x8a0 net/ipv4/tcp_timer.c:583
> tcp_write_timer+0x10e/0x1d0 net/ipv4/tcp_timer.c:607
> call_timer_fn+0x190/0x720 kernel/time/timer.c:1325
> expire_timers kernel/time/timer.c:1362 [inline]
> __run_timers kernel/time/timer.c:1681 [inline]
> __run_timers kernel/time/timer.c:1649 [inline]
> run_timer_softirq+0x652/0x1700 kernel/time/timer.c:1694
> __do_softirq+0x266/0x95a kernel/softirq.c:292
> invoke_softirq kernel/softirq.c:373 [inline]
> irq_exit+0x180/0x1d0 kernel/softirq.c:413
> exiting_irq arch/x86/include/asm/apic.h:536 [inline]
> smp_apic_timer_interrupt+0x14a/0x570 arch/x86/kernel/apic/apic.c:1062
> apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:807
> </IRQ>
> RIP: 0010:native_safe_halt+0x2/0x10 arch/x86/include/asm/irqflags.h:58
> Code: ff ff ff 48 89 c7 48 89 45 d8 e8 59 0c a1 fa 48 8b 45 d8 e9 ce fe ff ff 48 89 df e8 48 0c a1 fa eb 82 90 90 90 90 90 90 fb f4 <c3> 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 00 f4 c3 90 90 90 90 90 90
> RSP: 0018:ffff8880a98afd78 EFLAGS: 00000286 ORIG_RAX: ffffffffffffff13
> RAX: 1ffffffff1125061 RBX: ffff8880a989c340 RCX: 0000000000000000
> RDX: dffffc0000000000 RSI: 0000000000000001 RDI: ffff8880a989cbbc
> RBP: ffff8880a98afda8 R08: ffff8880a989c340 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001
> R13: ffffffff889282f8 R14: 0000000000000001 R15: 0000000000000000
> arch_cpu_idle+0x10/0x20 arch/x86/kernel/process.c:555
> default_idle_call+0x36/0x90 kernel/sched/idle.c:93
> cpuidle_idle_call kernel/sched/idle.c:153 [inline]
> do_idle+0x386/0x570 kernel/sched/idle.c:262
> cpu_startup_entry+0x1b/0x20 kernel/sched/idle.c:353
> start_secondary+0x404/0x5c0 arch/x86/kernel/smpboot.c:271
> secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:243
> Kernel Offset: disabled
> Rebooting in 86400 seconds..
>
> Fixes: 79861919b889 ("tcp: fix TCP_REPAIR xmit queue setup")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: syzbot <syzkaller@googlegroups.com>
> Cc: Andrey Vagin <avagin@openvz.org>
> Cc: Soheil Hassas Yeganeh <soheil@google.com>
> Cc: Neal Cardwell <ncardwell@google.com>
Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
Very nice catch and fix! This was a really cryptic failure. Thank you Eric!
> ---
> net/ipv4/tcp_output.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
> index 730bc44dbad9363814705b28c2f91a2253d91207..ccc78f3a4b60d3012430488bdfbcfc5122ff8627 100644
> --- a/net/ipv4/tcp_output.c
> +++ b/net/ipv4/tcp_output.c
> @@ -2347,6 +2347,7 @@ static bool tcp_write_xmit(struct sock *sk, unsigned int mss_now, int nonagle,
> /* "skb_mstamp_ns" is used as a start point for the retransmit timer */
> skb->skb_mstamp_ns = tp->tcp_wstamp_ns = tp->tcp_clock_cache;
> list_move_tail(&skb->tcp_tsorted_anchor, &tp->tsorted_sent_queue);
> + tcp_init_tso_segs(skb, mss_now);
> goto repair; /* Skip network transmission */
> }
>
> --
> 2.21.0.rc0.258.g878e2cd30e-goog
>
^ permalink raw reply
* Re: [PATCH] net: phy: realtek: Dummy IRQ calls for RTL8366RB
From: Linus Walleij @ 2019-02-23 23:57 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Florian Fainelli, netdev, Heiner Kallweit
In-Reply-To: <20190223151723.GC10693@lunn.ch>
On Sat, Feb 23, 2019 at 4:17 PM Andrew Lunn <andrew@lunn.ch> wrote:
> On Sat, Feb 23, 2019 at 03:36:39AM +0100, Linus Walleij wrote:
> > This fixes a regression introduced by
> > commit 0d2e778e38e0ddffab4bb2b0e9ed2ad5165c4bf7
> > "net: phy: replace PHY_HAS_INTERRUPT with a check for
> > config_intr and ack_interrupt".
> >
> > This assumes that a PHY cannot trigger interrupt unless
> > it has .config_intr() or .ack_interrupt() implemented.
> > A later patch makes the code assume both need to be
> > implemented for interrupts to be present.
> >
> > But this PHY (which is inside a DSA) will happily
> > fire interrupts without either callback.
>
> Hi Linus
>
> Can you disable these interrupts?
>
> If you have dummy implementations, what is clearing the interrupt?
They are handled by the irqchip mask/unmask inside
the RTL8366RB, see:
drivers/net/dsa/rtl8366rb.c
So as soon as the phy core request the threaded IRQ
the irqchip will deal with this business on its own.
How exactly the RTL8366RB IRQ machine looks inside
I doubt even Realtek knows themselves, but from
my experiements, they seem all edge triggered,
and the irq will be raised every time an edge occurse
(such as inserting or removing the cable). The "ACK"
happens in hardware when we read the status register
in the nested interrupt handler in rtl8366rb_irq() so no
further registers need to be accessed.
Yours,
Linus Walleij
^ permalink raw reply
* Re: No traffic with Marvell switch and latest linux-next
From: Florian Fainelli @ 2019-02-23 23:55 UTC (permalink / raw)
To: Heiner Kallweit, Andrew Lunn
Cc: Russell King - ARM Linux admin, netdev@vger.kernel.org
In-Reply-To: <188fcef7-81fe-cffc-af71-1f37725b8611@gmail.com>
Le 2/23/19 à 1:48 PM, Heiner Kallweit a écrit :
> On 18.02.2019 19:21, Andrew Lunn wrote:
>>>> Hi Heiner
>>>>
>>>> Watch out for boot vs reboot, and when rebooting if port 8 had link or
>>>> not before you reboot.
>>>>
>>> Will do. Is there some known issue or bug?
>>
>> Hi Heiner
>>
>> No, but it is a variable which can make a difference. The fix i made
>> for the Freescale GPIO controller was not an issue for cold boot, but
>> reboot with link up did cause interrupt problems, etc.
>>
> Hi Andrew,
>
> it took me quite some time to debug this issue ..
>
> At first a bisect pointed to one of my commits:
> 5502b218e001 ("net: phy: use phy_resolve_aneg_linkmode in genphy_read_status")
This is the same issue that Michal reported here:
https://www.spinics.net/lists/netdev/msg552955.html
>
> Further digging lead me to some suspicious dsa code:
> In dsa_port_fixed_link_register_of() there's a call to genphy_read_status().
> At the time of the call phydev->advertising is empty, therefore the fixed phy
> settings are overwritten with defaults (10/half) what breaks the system.
>
> Worth to be mentioned is that for the PHY these two flags are set:
> - is_pseudo_fixed_link (that's ok)
> - autoneg -> I'm not sure this is correct.
>
> It seems that you once added the code in question:
> 39b0c705195e ("net: dsa: Allow configuration of CPU & DSA port speeds/duplex")
>
> I did what I like to do most and removed some code.
> W/o the calls to genphy_config_init() and genphy_read_status() it works again.
> Do these calls have some purpose here with a fixed link?
>
> My commit exposed the issue because before it genphy_read_status() read the
> advertisement from chip registers instead of using phydev->advertising.
>
> Very close to this function is dsa_port_setup_phy_of() which uses genphy_resume()
> and genphy_read_status() and also looks somewhat suspicious. This code makes
> quite some assumptions:
> - PHY is a C22 PHY
> - PHY is compatible with the generic PHY driver
>
>> Andrew
>>
> Heiner
>
--
Florian
^ permalink raw reply
* [PATCH net] tcp: repaired skbs must init their tso_segs
From: Eric Dumazet @ 2019-02-23 23:51 UTC (permalink / raw)
To: David S . Miller
Cc: netdev, Eric Dumazet, Eric Dumazet, Soheil Hassas Yeganeh,
Neal Cardwell, Yuchung Cheng, syzbot, Andrey Vagin
syzbot reported a WARN_ON(!tcp_skb_pcount(skb))
in tcp_send_loss_probe() [1]
This was caused by TCP_REPAIR sent skbs that inadvertenly
were missing a call to tcp_init_tso_segs()
[1]
WARNING: CPU: 1 PID: 0 at net/ipv4/tcp_output.c:2534 tcp_send_loss_probe+0x771/0x8a0 net/ipv4/tcp_output.c:2534
Kernel panic - not syncing: panic_on_warn set ...
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.0.0-rc7+ #77
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x172/0x1f0 lib/dump_stack.c:113
panic+0x2cb/0x65c kernel/panic.c:214
__warn.cold+0x20/0x45 kernel/panic.c:571
report_bug+0x263/0x2b0 lib/bug.c:186
fixup_bug arch/x86/kernel/traps.c:178 [inline]
fixup_bug arch/x86/kernel/traps.c:173 [inline]
do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:271
do_invalid_op+0x37/0x50 arch/x86/kernel/traps.c:290
invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:973
RIP: 0010:tcp_send_loss_probe+0x771/0x8a0 net/ipv4/tcp_output.c:2534
Code: 88 fc ff ff 4c 89 ef e8 ed 75 c8 fb e9 c8 fc ff ff e8 43 76 c8 fb e9 63 fd ff ff e8 d9 75 c8 fb e9 94 f9 ff ff e8 bf 03 91 fb <0f> 0b e9 7d fa ff ff e8 b3 03 91 fb 0f b6 1d 37 43 7a 03 31 ff 89
RSP: 0018:ffff8880ae907c60 EFLAGS: 00010206
RAX: ffff8880a989c340 RBX: 0000000000000000 RCX: ffffffff85dedbdb
RDX: 0000000000000100 RSI: ffffffff85dee0b1 RDI: 0000000000000005
RBP: ffff8880ae907c90 R08: ffff8880a989c340 R09: ffffed10147d1ae1
R10: ffffed10147d1ae0 R11: ffff8880a3e8d703 R12: ffff888091b90040
R13: ffff8880a3e8d540 R14: 0000000000008000 R15: ffff888091b90860
tcp_write_timer_handler+0x5c0/0x8a0 net/ipv4/tcp_timer.c:583
tcp_write_timer+0x10e/0x1d0 net/ipv4/tcp_timer.c:607
call_timer_fn+0x190/0x720 kernel/time/timer.c:1325
expire_timers kernel/time/timer.c:1362 [inline]
__run_timers kernel/time/timer.c:1681 [inline]
__run_timers kernel/time/timer.c:1649 [inline]
run_timer_softirq+0x652/0x1700 kernel/time/timer.c:1694
__do_softirq+0x266/0x95a kernel/softirq.c:292
invoke_softirq kernel/softirq.c:373 [inline]
irq_exit+0x180/0x1d0 kernel/softirq.c:413
exiting_irq arch/x86/include/asm/apic.h:536 [inline]
smp_apic_timer_interrupt+0x14a/0x570 arch/x86/kernel/apic/apic.c:1062
apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:807
</IRQ>
RIP: 0010:native_safe_halt+0x2/0x10 arch/x86/include/asm/irqflags.h:58
Code: ff ff ff 48 89 c7 48 89 45 d8 e8 59 0c a1 fa 48 8b 45 d8 e9 ce fe ff ff 48 89 df e8 48 0c a1 fa eb 82 90 90 90 90 90 90 fb f4 <c3> 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 00 f4 c3 90 90 90 90 90 90
RSP: 0018:ffff8880a98afd78 EFLAGS: 00000286 ORIG_RAX: ffffffffffffff13
RAX: 1ffffffff1125061 RBX: ffff8880a989c340 RCX: 0000000000000000
RDX: dffffc0000000000 RSI: 0000000000000001 RDI: ffff8880a989cbbc
RBP: ffff8880a98afda8 R08: ffff8880a989c340 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001
R13: ffffffff889282f8 R14: 0000000000000001 R15: 0000000000000000
arch_cpu_idle+0x10/0x20 arch/x86/kernel/process.c:555
default_idle_call+0x36/0x90 kernel/sched/idle.c:93
cpuidle_idle_call kernel/sched/idle.c:153 [inline]
do_idle+0x386/0x570 kernel/sched/idle.c:262
cpu_startup_entry+0x1b/0x20 kernel/sched/idle.c:353
start_secondary+0x404/0x5c0 arch/x86/kernel/smpboot.c:271
secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:243
Kernel Offset: disabled
Rebooting in 86400 seconds..
Fixes: 79861919b889 ("tcp: fix TCP_REPAIR xmit queue setup")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
Cc: Andrey Vagin <avagin@openvz.org>
Cc: Soheil Hassas Yeganeh <soheil@google.com>
Cc: Neal Cardwell <ncardwell@google.com>
---
net/ipv4/tcp_output.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 730bc44dbad9363814705b28c2f91a2253d91207..ccc78f3a4b60d3012430488bdfbcfc5122ff8627 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -2347,6 +2347,7 @@ static bool tcp_write_xmit(struct sock *sk, unsigned int mss_now, int nonagle,
/* "skb_mstamp_ns" is used as a start point for the retransmit timer */
skb->skb_mstamp_ns = tp->tcp_wstamp_ns = tp->tcp_clock_cache;
list_move_tail(&skb->tcp_tsorted_anchor, &tp->tsorted_sent_queue);
+ tcp_init_tso_segs(skb, mss_now);
goto repair; /* Skip network transmission */
}
--
2.21.0.rc0.258.g878e2cd30e-goog
^ permalink raw reply related
* Re: No traffic with Marvell switch and latest linux-next
From: Andrew Lunn @ 2019-02-23 23:42 UTC (permalink / raw)
To: Heiner Kallweit
Cc: Russell King - ARM Linux admin, Florian Fainelli,
netdev@vger.kernel.org
In-Reply-To: <188fcef7-81fe-cffc-af71-1f37725b8611@gmail.com>
> it took me quite some time to debug this issue ..
>
> At first a bisect pointed to one of my commits:
> 5502b218e001 ("net: phy: use phy_resolve_aneg_linkmode in genphy_read_status")
>
> Further digging lead me to some suspicious dsa code:
> In dsa_port_fixed_link_register_of() there's a call to genphy_read_status().
> At the time of the call phydev->advertising is empty, therefore the fixed phy
> settings are overwritten with defaults (10/half) what breaks the system.
>
> Worth to be mentioned is that for the PHY these two flags are set:
> - is_pseudo_fixed_link (that's ok)
> - autoneg -> I'm not sure this is correct.
>
> It seems that you once added the code in question:
> 39b0c705195e ("net: dsa: Allow configuration of CPU & DSA port speeds/duplex")
Hi Heiner
For Ethernet switches, you can have device trees like this:
switch0: switch@0 {
compatible = "marvell,mv88e6085";
pinctrl-0 = <&pinctrl_gpio_switch0>;
pinctrl-names = "default";
reg = <0>;
dsa,member = <0 0>;
interrupt-parent = <&gpio0>;
interrupts = <27 IRQ_TYPE_LEVEL_LOW>;
interrupt-controller;
#interrupt-cells = <2>;
eeprom-length = <512>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
label = "lan0";
phy-handle = <&switch0phy0>;
};
...
switch0port5: port@5 {
reg = <5>;
label = "dsa";
phy-mode = "rgmii-txid";
link = <&switch1port6
&switch2port9>;
fixed-link {
speed = <1000>;
full-duplex;
};
};
This is a DSA port. It is used to connect two Ethernet switches
together. In this case, the MACs are connected back to back. There are
no PHYs involved. These ports don't have a netdev associated with
them, since they are just pipes between switches, not user interfaces.
If i remember correctly, the code you are looking at was to deal with
the "rgmii-txid". Without the TXID, i could not get frames to pass
between the ports.
There is a second use case as well. The Vybrid FEC ethernet controller
is a Fast Ethernet port. The switch ports are 1G. DSA drivers set the
port connecting to the SoC to its highest speed. Again, there is no
netdev associated to the switch port, and generally the MAC ports are
connected back to back. This 100 vs 1000 does not work for the
Vybrid. So we add a fixed PHY to the CPU port.
port@6 {
reg = <6>;
label = "cpu";
ethernet = <&fec1>;
fixed-link {
speed = <100>;
full-duplex;
};
};
And there is a third use case:
port@4 {
reg = <4>;
label = "optical4";
fixed-link {
speed = <1000>;
full-duplex;
link-gpios = <&gpio6 3
GPIO_ACTIVE_HIGH>;
};
};
We have a GPIO which tells us if the link it up, because there is not
a PHY here, but an optical module. The GPIO tells us about loss of
signal. Unfortunately we cannot use the SFP driver here, because of a
hardware issue.
In all cases end up in the same code. We want to tell the MAC to
configure RGMII delays, or to configure the port speed, or to have the
correct initial link state. The adjust_link() call can do this, if
passed a phydev. And we have a phydev for the fixed-link PHY. However,
since it has never been attached to a netdev, phy_start() called, etc,
the state information is maybe not correct. So we call config_init()
and read_status(), so phydev should reflect the state of the
fixed-link PHY. And a fixed-link PHY is always c22, and it can be
driven by genphy. Take a look at drivers/net/phy/swphy.c which is the
core of the simulation, and fixed_phy.c
> I did what I like to do most and removed some code.
> W/o the calls to genphy_config_init() and genphy_read_status() it works again.
> Do these calls have some purpose here with a fixed link?
Maybe with all the core changes, these calls are no longer needed? We
just need to ensure the state in phydev reflects the state of the
fixed link, i.e. in this case 100 Full.
Looking forward, at some point we are going to have to make fixed-link
support higher speeds. That probably means we need a swphy-c45 which
emulates the standard registers for 2.5G, 5G and 10G. At that point
genphy will not work...
Andrew
^ permalink raw reply
* r8169 Kernel bug in 4.20.11
From: Ron Murray @ 2019-02-23 23:33 UTC (permalink / raw)
To: netdev
[-- Attachment #1.1.1: Type: text/plain, Size: 309 bytes --]
Hi.
I've encountered this bug in the last couple of kernel versions now
(since, say 4.20.8 +/- 0.0.2).
I don't see a mention in this mailing list/ Apologies if you've
already seen it.
--
Ron Murray <rjmx@rjmx.net>
PGP Fingerprint: 4D99 70E3 2317 334B 141E 7B63 12F7 E865 B5E2 E761
[-- Attachment #1.1.2: r8196-crash.txt --]
[-- Type: text/plain, Size: 4966 bytes --]
Feb 21 15:54:04 khufu kernel: ------------[ cut here ]------------
Feb 21 15:54:04 khufu kernel: NETDEV WATCHDOG: enp5s0 (r8169): transmit queue 0 timed out
Feb 21 15:54:04 khufu kernel: WARNING: CPU: 5 PID: 0 at net/sched/sch_generic.c:461 dev_watchdog+0x211/0x220
Feb 21 15:54:04 khufu kernel: Modules linked in: fuse rfcomm hidp pci_stub vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) cpufreq_userspace cpufreq_powersave cpufreq_conservative nf_tables cmac bnep nfnetlink_log nfnetlink binfmt_misc nls_iso8859_1 nls_cp437 vfat fat uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev btusb btrtl btbcm btintel media snd_usb_audio bluetooth snd_usbmidi_lib snd_hwdep snd_rawmidi snd_seq_device joydev ecdh_generic nvidia_drm(PO) nvidia_modeset(PO) nvidia(PO) arc4 snd_hda_codec_realtek drm_kms_helper snd_hda_codec_hdmi syscopyarea iwlmvm snd_hda_codec_generic sysfillrect sysimgblt fb_sys_fops mac80211 drm agpgart snd_hda_intel snd_hda_codec snd_hda_core pktcdvd iwlwifi snd_pcm_oss ipmi_devintf ipmi_msghandler cfg80211 snd_mixer_oss snd_pcm snd_timer evdev mxm_wmi rfkill snd kvm_amd soundcore k10temp fam15h_power pcspkr wmi button acpi_cpufreq kvm irqbypass efi_pstore efivars nct6775 hwmon_vid loop nfsd auth_rpcgss lockd grace sunrpc efivarfs
Feb 21 15:54:04 khufu kernel: ip_tables x_tables ipv6 autofs4 overlay btrfs xor raid6_pq algif_skcipher af_alg dm_crypt dm_mod dax hid_logitech_hidpp hid_logitech_dj usbhid crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel pata_acpi aes_x86_64 crypto_simd cryptd glue_helper r8169 realtek libphy pata_atiixp i2c_piix4
Feb 21 15:54:04 khufu kernel: CPU: 5 PID: 0 Comm: swapper/5 Tainted: P O 4.20.11.khufu #0
Feb 21 15:54:04 khufu kernel: Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./970A-G/3.1, BIOS P1.20 01/12/2016
Feb 21 15:54:04 khufu kernel: RIP: 0010:dev_watchdog+0x211/0x220
Feb 21 15:54:04 khufu kernel: Code: 49 63 4c 24 e0 eb 8d 4c 89 ef c6 05 58 5d a1 00 01 e8 73 32 fd ff 89 d9 48 89 c2 4c 89 ee 48 c7 c7 b8 15 dc bc e8 40 be 9d ff <0f> 0b eb be 66 66 2e 0f 1f 84 00 00 00 00 00 48 c7 47 08 00 00 00
Feb 21 15:54:04 khufu kernel: RSP: 0018:ffffa3154fb43ea0 EFLAGS: 00010286
Feb 21 15:54:04 khufu kernel: RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000006
Feb 21 15:54:04 khufu kernel: RDX: 0000000000000007 RSI: 0000000000000096 RDI: ffffa3154fb552c0
Feb 21 15:54:04 khufu kernel: RBP: ffffa3154d45e41c R08: ffffffffbc4bc310 R09: 00000000000003d8
Feb 21 15:54:04 khufu kernel: R10: 0000000000000007 R11: 0000000000000000 R12: ffffa3154d45e440
Feb 21 15:54:04 khufu kernel: R13: ffffa3154d45e000 R14: 0000000000000001 R15: ffffa31548f2a880
Feb 21 15:54:04 khufu kernel: FS: 0000000000000000(0000) GS:ffffa3154fb40000(0000) knlGS:0000000000000000
Feb 21 15:54:04 khufu kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Feb 21 15:54:04 khufu kernel: CR2: 0000557d6fc1e880 CR3: 00000003c8944000 CR4: 00000000000406e0
Feb 21 15:54:04 khufu kernel: Call Trace:
Feb 21 15:54:04 khufu kernel: <IRQ>
Feb 21 15:54:04 khufu kernel: ? qdisc_put_unlocked+0x30/0x30
Feb 21 15:54:04 khufu kernel: ? qdisc_put_unlocked+0x30/0x30
Feb 21 15:54:04 khufu kernel: call_timer_fn+0x17/0x80
Feb 21 15:54:04 khufu kernel: run_timer_softirq+0x14a/0x190
Feb 21 15:54:04 khufu kernel: ? tick_sched_timer+0x71/0x170
Feb 21 15:54:04 khufu kernel: ? timerqueue_add+0x52/0x80
Feb 21 15:54:04 khufu kernel: ? __hrtimer_run_queues+0x126/0x190
Feb 21 15:54:04 khufu kernel: ? ktime_get+0x31/0x90
Feb 21 15:54:04 khufu kernel: __do_softirq+0xbf/0x235
Feb 21 15:54:04 khufu kernel: irq_exit+0x59/0x80
Feb 21 15:54:04 khufu kernel: smp_apic_timer_interrupt+0x61/0xa0
Feb 21 15:54:04 khufu kernel: apic_timer_interrupt+0xf/0x20
Feb 21 15:54:04 khufu kernel: </IRQ>
Feb 21 15:54:04 khufu kernel: RIP: 0010:cpuidle_enter_state+0x135/0x1e0
Feb 21 15:54:04 khufu kernel: Code: e8 a0 f3 a7 ff 31 ff 48 89 c3 e8 c6 fd a7 ff 45 84 ff 74 12 9c 58 f6 c4 02 0f 85 9c 00 00 00 31 ff e8 ff 34 ac ff fb 45 85 ed <0f> 88 80 00 00 00 48 89 d9 48 b8 ff ff ff ff f3 01 00 00 48 29 e9
Feb 21 15:54:04 khufu kernel: RSP: 0018:ffffb20981927eb0 EFLAGS: 00000202 ORIG_RAX: ffffffffffffff13
Feb 21 15:54:04 khufu kernel: RAX: ffffa3154fb5e200 RBX: 0000362b0e1ab0d5 RCX: 000000000000001f
Feb 21 15:54:04 khufu kernel: RDX: 0000362b0e1ab0d5 RSI: 000000001fffc19c RDI: 0000000000000000
Feb 21 15:54:04 khufu kernel: RBP: 0000362b0e0b8b3a R08: 0000000000000002 R09: 000000000001dac0
Feb 21 15:54:04 khufu kernel: R10: 0000d8c2c0ebe281 R11: 0000000000002000 R12: ffffa3154d0cd600
Feb 21 15:54:04 khufu kernel: R13: 0000000000000002 R14: 0000000000000002 R15: 0000000000000000
Feb 21 15:54:04 khufu kernel: do_idle+0x149/0x1c0
Feb 21 15:54:04 khufu kernel: cpu_startup_entry+0x1b/0x20
Feb 21 15:54:04 khufu kernel: start_secondary+0x18a/0x1c0
Feb 21 15:54:04 khufu kernel: secondary_startup_64+0xa4/0xb0
Feb 21 15:54:04 khufu kernel: ---[ end trace faeefde2824c9f3f ]---
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply
* Re: [PATCH] ip_tunnel: Add ip tunnel tunnel_info dst_cache in ip_tunnel_xmit
From: kbuild test robot @ 2019-02-23 23:28 UTC (permalink / raw)
To: wenxu; +Cc: kbuild-all, netdev, davem
In-Reply-To: <1550750930-27138-1-git-send-email-wenxu@ucloud.cn>
[-- Attachment #1: Type: text/plain, Size: 3301 bytes --]
Hi wenxu,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on net/master]
[also build test WARNING on v5.0-rc4 next-20190222]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/wenxu-ucloud-cn/ip_tunnel-Add-ip-tunnel-tunnel_info-dst_cache-in-ip_tunnel_xmit/20190224-065214
config: x86_64-randconfig-x016-201908 (attached as .config)
compiler: gcc-8 (Debian 8.2.0-20) 8.2.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings
All warnings (new ones prefixed by >>):
In file included from net/ipv4/ip_tunnel.c:48:
net/ipv4/ip_tunnel.c: In function 'ip_tunnel_xmit':
>> include/net/ip_tunnels.h:207:15: warning: 'tun_info' may be used uninitialized in this function [-Wmaybe-uninitialized]
if (info->key.tun_flags & TUNNEL_NOCACHE)
~~~~~~~~~^~~~~~~~~~
net/ipv4/ip_tunnel.c:640:25: note: 'tun_info' was declared here
struct ip_tunnel_info *tun_info;
^~~~~~~~
net/ipv4/ip_tunnel.c:734:5: warning: 'rt' may be used uninitialized in this function [-Wmaybe-uninitialized]
if (!rt) {
^
--
In file included from net//ipv4/ip_tunnel.c:48:
net//ipv4/ip_tunnel.c: In function 'ip_tunnel_xmit':
>> include/net/ip_tunnels.h:207:15: warning: 'tun_info' may be used uninitialized in this function [-Wmaybe-uninitialized]
if (info->key.tun_flags & TUNNEL_NOCACHE)
~~~~~~~~~^~~~~~~~~~
net//ipv4/ip_tunnel.c:640:25: note: 'tun_info' was declared here
struct ip_tunnel_info *tun_info;
^~~~~~~~
net//ipv4/ip_tunnel.c:734:5: warning: 'rt' may be used uninitialized in this function [-Wmaybe-uninitialized]
if (!rt) {
^
vim +/tun_info +207 include/net/ip_tunnels.h
1d8fff90 Thomas Graf 2015-07-21 198
db3c6139 Daniel Borkmann 2016-03-04 199 static inline bool
db3c6139 Daniel Borkmann 2016-03-04 200 ip_tunnel_dst_cache_usable(const struct sk_buff *skb,
db3c6139 Daniel Borkmann 2016-03-04 201 const struct ip_tunnel_info *info)
db3c6139 Daniel Borkmann 2016-03-04 202 {
db3c6139 Daniel Borkmann 2016-03-04 203 if (skb->mark)
db3c6139 Daniel Borkmann 2016-03-04 204 return false;
db3c6139 Daniel Borkmann 2016-03-04 205 if (!info)
db3c6139 Daniel Borkmann 2016-03-04 206 return true;
db3c6139 Daniel Borkmann 2016-03-04 @207 if (info->key.tun_flags & TUNNEL_NOCACHE)
db3c6139 Daniel Borkmann 2016-03-04 208 return false;
db3c6139 Daniel Borkmann 2016-03-04 209
db3c6139 Daniel Borkmann 2016-03-04 210 return true;
db3c6139 Daniel Borkmann 2016-03-04 211 }
db3c6139 Daniel Borkmann 2016-03-04 212
:::::: The code at line 207 was first introduced by commit
:::::: db3c6139e6ead91b42e7c2ad044ed8beaee884e6 bpf, vxlan, geneve, gre: fix usage of dst_cache on xmit
:::::: TO: Daniel Borkmann <daniel@iogearbox.net>
:::::: CC: David S. Miller <davem@davemloft.net>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 28325 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 2/2] xdp: Add devmap_idx map type for looking up devices by ifindex
From: kbuild test robot @ 2019-02-23 23:28 UTC (permalink / raw)
To: Toke Høiland-Jørgensen
Cc: kbuild-all, David Miller, netdev, Jesper Dangaard Brouer,
Daniel Borkmann, Alexei Starovoitov
In-Reply-To: <155075021407.13610.6656977312753058829.stgit@alrua-x1>
[-- Attachment #1: Type: text/plain, Size: 2691 bytes --]
Hi Toke,
I love your patch! Yet something to improve:
[auto build test ERROR on net-next/master]
url: https://github.com/0day-ci/linux/commits/Toke-H-iland-J-rgensen/xdp-Always-use-a-devmap-for-XDP_REDIRECT-to-a-device/20190224-054907
config: i386-randconfig-l1-02240344 (attached as .config)
compiler: gcc-5 (Debian 5.5.0-3) 5.4.1 20171010
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
net//core/filter.c: In function '__bpf_tx_xdp_map':
>> net//core/filter.c:3355:29: error: passing argument 2 of '__dev_map_insert_ctx' from incompatible pointer type [-Werror=incompatible-pointer-types]
__dev_map_insert_ctx(map, dst);
^
In file included from include/linux/bpf-cgroup.h:5:0,
from include/linux/cgroup-defs.h:22,
from include/linux/cgroup.h:28,
from include/net/netprio_cgroup.h:17,
from include/linux/netdevice.h:46,
from include/net/sock.h:51,
from include/linux/sock_diag.h:8,
from net//core/filter.c:29:
include/linux/bpf.h:715:20: note: expected 'struct net_device *' but argument is of type 'struct bpf_dtab_netdev *'
static inline void __dev_map_insert_ctx(struct bpf_map *map,
^
cc1: some warnings being treated as errors
vim +/__dev_map_insert_ctx +3355 net//core/filter.c
3339
3340 static int __bpf_tx_xdp_map(struct net_device *dev_rx, void *fwd,
3341 struct bpf_map *map,
3342 struct xdp_buff *xdp,
3343 u32 index)
3344 {
3345 int err;
3346
3347 switch (map->map_type) {
3348 case BPF_MAP_TYPE_DEVMAP:
3349 case BPF_MAP_TYPE_DEVMAP_IDX: {
3350 struct bpf_dtab_netdev *dst = fwd;
3351
3352 err = dev_map_enqueue(dst, xdp, dev_rx);
3353 if (unlikely(err))
3354 return err;
> 3355 __dev_map_insert_ctx(map, dst);
3356 break;
3357 }
3358 case BPF_MAP_TYPE_CPUMAP: {
3359 struct bpf_cpu_map_entry *rcpu = fwd;
3360
3361 err = cpu_map_enqueue(rcpu, xdp, dev_rx);
3362 if (unlikely(err))
3363 return err;
3364 __cpu_map_insert_ctx(map, index);
3365 break;
3366 }
3367 case BPF_MAP_TYPE_XSKMAP: {
3368 struct xdp_sock *xs = fwd;
3369
3370 err = __xsk_map_redirect(map, xdp, xs);
3371 return err;
3372 }
3373 default:
3374 break;
3375 }
3376 return 0;
3377 }
3378
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 29026 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 2/2] xdp: Add devmap_idx map type for looking up devices by ifindex
From: kbuild test robot @ 2019-02-23 23:19 UTC (permalink / raw)
To: Toke Høiland-Jørgensen
Cc: kbuild-all, David Miller, netdev, Jesper Dangaard Brouer,
Daniel Borkmann, Alexei Starovoitov
In-Reply-To: <155075021407.13610.6656977312753058829.stgit@alrua-x1>
[-- Attachment #1: Type: text/plain, Size: 2605 bytes --]
Hi Toke,
I love your patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
url: https://github.com/0day-ci/linux/commits/Toke-H-iland-J-rgensen/xdp-Always-use-a-devmap-for-XDP_REDIRECT-to-a-device/20190224-054907
config: i386-randconfig-a1-201907 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
net/core/filter.c: In function '__bpf_tx_xdp_map':
>> net/core/filter.c:3355:29: warning: passing argument 2 of '__dev_map_insert_ctx' from incompatible pointer type
__dev_map_insert_ctx(map, dst);
^
In file included from include/linux/bpf-cgroup.h:5:0,
from include/linux/cgroup-defs.h:22,
from include/linux/cgroup.h:28,
from include/net/netprio_cgroup.h:17,
from include/linux/netdevice.h:46,
from include/net/sock.h:51,
from include/linux/sock_diag.h:8,
from net/core/filter.c:29:
include/linux/bpf.h:715:20: note: expected 'struct net_device *' but argument is of type 'struct bpf_dtab_netdev *'
static inline void __dev_map_insert_ctx(struct bpf_map *map,
^
vim +/__dev_map_insert_ctx +3355 net/core/filter.c
3339
3340 static int __bpf_tx_xdp_map(struct net_device *dev_rx, void *fwd,
3341 struct bpf_map *map,
3342 struct xdp_buff *xdp,
3343 u32 index)
3344 {
3345 int err;
3346
3347 switch (map->map_type) {
3348 case BPF_MAP_TYPE_DEVMAP:
3349 case BPF_MAP_TYPE_DEVMAP_IDX: {
3350 struct bpf_dtab_netdev *dst = fwd;
3351
3352 err = dev_map_enqueue(dst, xdp, dev_rx);
3353 if (unlikely(err))
3354 return err;
> 3355 __dev_map_insert_ctx(map, dst);
3356 break;
3357 }
3358 case BPF_MAP_TYPE_CPUMAP: {
3359 struct bpf_cpu_map_entry *rcpu = fwd;
3360
3361 err = cpu_map_enqueue(rcpu, xdp, dev_rx);
3362 if (unlikely(err))
3363 return err;
3364 __cpu_map_insert_ctx(map, index);
3365 break;
3366 }
3367 case BPF_MAP_TYPE_XSKMAP: {
3368 struct xdp_sock *xs = fwd;
3369
3370 err = __xsk_map_redirect(map, xdp, xs);
3371 return err;
3372 }
3373 default:
3374 break;
3375 }
3376 return 0;
3377 }
3378
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 27631 bytes --]
^ permalink raw reply
* Re: [PATCH v2 bpf-next 0/9] bpf: Network Resource Manager (NRM)
From: Alexei Starovoitov @ 2019-02-23 23:25 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Ahern, brakmo, netdev, Martin Lau, Alexei Starovoitov,
Daniel Borkmann, Kernel Team
In-Reply-To: <49fbc4c9-6e8d-5115-0860-e418427a2ce5@gmail.com>
On Sat, Feb 23, 2019 at 12:43:51PM -0800, Eric Dumazet wrote:
>
>
> On 02/23/2019 12:40 PM, Alexei Starovoitov wrote:
> > On Sat, Feb 23, 2019 at 10:39:53AM -0800, Eric Dumazet wrote:
> >>
> >>
> >> On 02/22/2019 07:03 PM, David Ahern wrote:
> >>> On 2/22/19 8:06 PM, brakmo wrote:
> >>>> Network Resource Manager is a framework for limiting the bandwidth used
> >>>> by v2 cgroups. It consists of 4 BPF helpers and a sample BPF program to
> >>>> limit egress bandwdith as well as a sample user program and script to
> >>>> simplify NRM testing.
> >>>
> >>> 'resource manager' is a really generic name. Since you are referring to
> >>> bandwidth, how about renaming to Network Bandwidth Manager?
> >>>
> >>
> >> Or just use the normal word for a policer ...
> >>
> >> Really this is beyond me that TCP experts can still push policers out there,
> >> they are really a huge pain.
> >
> > hmm. please see our NRM presentation at LPC.
> > It is a networking _resource_ management for cgroups.
> > Bandwidth enforcement is a particular example.
> > It's not a policer either.
> >
>
> Well, this definitely looks a policer to me, sorry if we disagree, this is fine.
this particular example certainly does look like it. we both agree.
It's overall direction of this work that is aiming to do
network resource management. For example bpf prog may choose
to react on SLA violations in one cgroup by throttling flows
in the other cgroup. Aggregated per-cgroup bandwidth doesn't
need to cross a threshold for bpf prog to take action.
It could do 'work conserving' 'policer'.
I think this set of patches represent a revolutionary approach and existing
networking nomenclature doesn't have precise words to describe it :)
'NRM' describes our goals the best.
Other folks may choose to use it differently, of course.
Note that NRM abbreviation doesn't leak anywhere in uapi.
It's only used in examples. So not sure what we're arguing about.
^ 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