* [ROSE] Bug : waiting for rose module to become free
From: f6bvp @ 2019-02-16 18:44 UTC (permalink / raw)
To: netdev, linux-hams; +Cc: dvyukov, richard, thomas, f6bvp
Hi,
A nastly bug is still pending in ROSE module that prevents it to be removed.
When trying to remove rose module we enter into an endless loop with displayed message :
"waiting for rose module to become free"
A patch from Richard Stern had been committed a while ago but it did not get a chance to be applied.
https://marc.info/?l=linux-hams&m=150870350516064&w=2
Since then, there have been some changes in af_rose.c and net code architecture that prevents simply adding missing dev_put(dev) in present kernel.
From time to time we can observe a negative count (-1 for integer value is displayed as 65535 in /proc/net/rose_neigh) that probably means there is a bug in rose module refcount (??).
/proc/net/rose_neigh
00015 SV1HCC-9 ax0 2 1 DCE yes 0 0
00013 PE1OWG-11 ax0 2 65535 DCE yes 0 0
00011 F5KTR-11 ax0 1 1 DCE yes 0 0
00007 F3KT-11 ax0 2 1 DCE yes 0 0
00003 SK7ES-9 ax0 2 1 DTE yes 0 0
00002 K4GBB-9 ax0 4 0 DCE yes 0 0
00001 RSLOOP-0 ??? 1 2 DCE yes 0 0
Help is kindly requested to get a valid patch.
Bernard,
f6bvp
^ permalink raw reply
* Re: [PATCH RFC] net: bridge: don't flood known multicast traffic when snooping is enabled
From: Ido Schimmel @ 2019-02-16 18:43 UTC (permalink / raw)
To: Nikolay Aleksandrov
Cc: Linus Lüssing, netdev, roopa, wkok, anuradhak, bridge, davem,
stephen
In-Reply-To: <479a1acf-c7f3-4e6f-4246-e1583e98d356@cumulusnetworks.com>
On Sat, Feb 16, 2019 at 10:05:40AM +0200, Nikolay Aleksandrov wrote:
> On 15/02/2019 19:13, Linus Lüssing wrote:
> > On Fri, Feb 15, 2019 at 03:04:27PM +0200, Nikolay Aleksandrov wrote:
> >> Every user would expect to have traffic forwarded only to the configured
> >> mdb destination when snooping is enabled, instead now to get that one
> >> needs to enable both snooping and querier. Enabling querier on all
> >> switches could be problematic and is not a good solution,
> >
> > There is no need to set the querier on all snooping switches.
> > br_multicast_querier_exists() checks if a querier exists on the
> > link in general, not if this particular host/bridge is a querier.
> >
>
> We need a generic solution for the case of existing mdst and no querier.
> More below.
>
> >
> >> for example as summarized by our multicast experts:
> >> "every switch would send an IGMP query
> >
> > What? RFC3810, section 7.1 says:
> >
> > "If it is the case, a querier election mechanism (described in
> > section 7.6.2) is used to elect a single multicast router to be
> > in Querier state. [...] Nevertheless, it is only the [elected] Querier
> > that sends periodical or triggered query messages on the subnet."
> > >> for any random multicast traffic it
> >> received across the entire domain and it would send it forever as long as a
> >> host exists wanting that stream even if it has no downstream/directly
> >> connected receivers"
> >
>
> This was taken out of context and it's my bad, I think everyone is aware
> of the election process, please nevermind the above statement.
>
> [snip]>
> >
> > Have you done some tests with this change yet, Nikolay?
> >
>
> You've raised good questions, IPv6 indeed needs more work - we'll have to flood
> link-local packets etc. but I wanted to have a discussion about no querier/existing mdst.
> To simplify we can modify the patch and have traffic forwarded to the proper ports when an
> mdst exists and there is no querier for both unsolicited report and user-added entry.
> We can keep the current behaviour for unknown traffic with and without querier.
> This would align it closer to what other vendors currently do as well IIRC.
> What do you think ?
The no querier condition is not currently reflected via switchdev, so
the behavior you're proposing in your patch is what actually happens in
the data plane.
We already hit the problem Linus mentioned in commit b00589af3b04
("bridge: disable snooping if there is no querier"). Namely, IPv6 ND
broke because a port joined before the bridge was created.
I introduced a workaround in commit 9d45deb04c59 ("mlxsw: spectrum:
Treat IPv6 unregistered multicast as broadcast"). I'm interested to know
what other vendors are doing. Can you elaborate?
We can trap IPv6 ND packets at L2 (we'll eventually need to do for ND
suppression) and let the bridge take care of flooding them correctly.
I'm not sure it's good enough.
^ permalink raw reply
* Re: [RFC PATCH] bonding: use mutex lock in bond_get_stats()
From: Eric Dumazet @ 2019-02-16 18:18 UTC (permalink / raw)
To: Kefeng Wang
Cc: netdev, Willem de Bruijn, David S . Miller, Jay Vosburgh,
Veaceslav Falico, weiyongjun1
In-Reply-To: <09569f86-2a12-ccdf-3ae7-00a228d1f957@huawei.com>
On Fri, Feb 15, 2019 at 9:36 PM Kefeng Wang <wangkefeng.wang@huawei.com> wrote:
>
>
>
> On 2019/2/15 21:57, Eric Dumazet wrote:
> > On Fri, Feb 15, 2019 at 5:37 AM Kefeng Wang <wangkefeng.wang@huawei.com> wrote:
> >>
> >> With CONFIG_DEBUG_SPINLOCK=y, we find following stack,
> >>
> >> BUG: spinlock wrong CPU on CPU#0, ip/16047
> >> lock: 0xffff803f5febc998, .magic: dead4ead, .owner: ip/16047, .owner_cpu: 0
> >> CPU: 1 PID: 16047 Comm: ip Kdump: loaded Tainted: G E 4.19.12.aarch64 #1
> >> Hardware name: Huawei TaiShan 2280 V2/BC82AMDA, BIOS TA BIOS TaiShan 2280 V2 - B900 01/29/2019
> >> Call trace:
> >> dump_backtrace+0x0/0x1c0
> >> show_stack+0x24/0x30
> >> dump_stack+0x90/0xbc
> >> spin_dump+0x84/0xa8
> >> do_raw_spin_unlock+0xf8/0x100
> >> _raw_spin_unlock+0x20/0x30
> >> bond_get_stats+0x110/0x140 [bonding]
> >> rtnl_fill_stats+0x50/0x150
> >> rtnl_fill_ifinfo+0x4d4/0xd18
> >> rtnl_dump_ifinfo+0x200/0x3a8
> >> netlink_dump+0x100/0x2b0
> >> netlink_recvmsg+0x310/0x3e8
> >> sock_recvmsg+0x58/0x68
> >> ___sys_recvmsg+0xd0/0x278
> >> __sys_recvmsg+0x74/0xd0
> >> __arm64_sys_recvmsg+0x2c/0x38
> >> el0_svc_common+0x7c/0x118
> >> el0_svc_handler+0x30/0x40
> >> el0_svc+0x8/0xc
> >>
> >> and then lead to softlockup issue, fix this by using mutex lock instead
> >> of spin lock.
> >>
> >> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
> >> ---
> >>
> >> Not sure if this is right fix, please correct me if I'm wrong.
> >>
> >
> > Make sure to also try :
> >
> > cat /proc/net/dev
>
> Yes, no regression with this patch in our test or 'cat /proc/net/dev'
>
You really should have a warning showing up.
Make sure you have : DEBUG_ATOMIC_SLEEP=y (I thought this was
automatically selected with LOCKDEP on, maybe not...)
Please take a look at net/core/net-procfs.c , functions
dev_seq_start(), dev_seq_printf_stats(), dev_seq_show()
We can not use a mutex in a section protected by rcu_read_lock()
^ permalink raw reply
* Re: [PATCH net-next 1/3] net: stmmac: Fix NAPI poll in TX path when in multi-queue
From: Lendacky, Thomas @ 2019-02-16 17:21 UTC (permalink / raw)
To: Florian Fainelli, Jose Abreu, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Cc: Joao Pinto, David S . Miller, Giuseppe Cavallaro,
Alexandre Torgue
In-Reply-To: <c6a38836-a0d7-608d-39cf-ea770db78c95@gmail.com>
On 2/15/19 6:35 PM, Florian Fainelli wrote:
> On 2/15/19 5:42 AM, Jose Abreu wrote:
>> Commit 8fce33317023 introduced the concept of NAPI per-channel and
>> independent cleaning of TX path.
>>
>> This is currently breaking performance in some cases. The scenario
>> happens when all packets are being received in Queue 0 but the TX is
>> performed in Queue != 0.
>>
>> Fix this by using different NAPI instances per each TX and RX queue, as
>> suggested by Florian.
>>
>> Signed-off-by: Jose Abreu <joabreu@synopsys.com>
>> Cc: Florian Fainelli <f.fainelli@gmail.com>
>> Cc: Joao Pinto <jpinto@synopsys.com>
>> Cc: David S. Miller <davem@davemloft.net>
>> Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
>> Cc: Alexandre Torgue <alexandre.torgue@st.com>
>> ---
>
> [snip]
>
>> - if (work_done < budget && napi_complete_done(napi, work_done)) {
>> - int stat;
>> + priv->xstats.napi_poll++;
>>
>> + work_done = stmmac_tx_clean(priv, budget, chan);
>> + if (work_done < budget && napi_complete_done(napi, work_done))
>
> You should not be bounding your TX queue against the NAPI budge, it
> should run unbound and clean as much as it can, which could be the
> entire ring size if that is how many packets you pushed between
> interrupts. That could be the cause of poor performance as well.
Won't returning the budget value cause this napi_poll routine to be called
again, where the driver can continue to clean TX packets? I thought this
just gives other drivers the opportunity to run their napi_poll routines
in between so as not to be starved.
Thanks,
Tom
>
^ permalink raw reply
* Re: [PATCH net-next] ip_tunnel: Fix DST_METADATA dst_entry handle in tnl_update_pmtu
From: Alexei Starovoitov @ 2019-02-16 16:34 UTC (permalink / raw)
To: wenxu
Cc: David S. Miller, rong.a.chen, Network Development,
Stephen Rothwell, LKP
In-Reply-To: <1550278683-17239-1-git-send-email-wenxu@ucloud.cn>
On Sat, Feb 16, 2019 at 2:11 AM <wenxu@ucloud.cn> wrote:
>
> From: wenxu <wenxu@ucloud.cn>
>
> BUG report in selftests: bpf: test_tunnel.sh
>
> Testing IPIP tunnel...
> BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
> PGD 0 P4D 0
> Oops: 0010 [#1] SMP PTI
> CPU: 0 PID: 16822 Comm: ping Not tainted 5.0.0-rc3-00352-gc8b34e6 #1
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
> RIP: 0010: (null)
> Code: Bad RIP value.
> RSP: 0018:ffffc9000104f9c8 EFLAGS: 00010286
> RAX: 0000000000000000 RBX: ffffe8ffffc071a8 RCX: 0000000000000000
> RDX: ffff888054e33000 RSI: ffff88807796f500 RDI: ffffe8ffffc07130
> RBP: ffff88807796f500 R08: ffff88806da4f0a0 R09: 0000000000000000
> R10: 0000000000000004 R11: ffff888054e33000 R12: 0000000000000054
> R13: ffff88805e714000 R14: ffff88806da4f0a0 R15: 0000000000000000
> FS: 00007f4c00431500(0000) GS:ffff88813fc00000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: ffffffffffffffd6 CR3: 000000008276e000 CR4: 00000000000406f0
> Call Trace:
> ? tnl_update_pmtu+0x21b/0x250 [ip_tunnel]
> ? ip_md_tunnel_xmit+0x1b7/0xdc0 [ip_tunnel]
> ? ipip_tunnel_xmit+0x90/0xc0 [ipip]
> ? dev_hard_start_xmit+0x98/0x210
> ? __dev_queue_xmit+0x6a9/0x8e0
>
> The bpf program set tunnel_key through bpf_skb_set_tunnel_key which will
> drop the old dst_entry and create a DST_METADATA dst_entry. It will lead
> the tunnel_update_pmtu operator the dst_entry incorrect. So It should be
> check the dst_entry is valid.
>
> Fixes: c8b34e680a09 ("ip_tunnel: Add tnl_update_pmtu in ip_md_tunnel_xmit")
> Signed-off-by: wenxu <wenxu@ucloud.cn>
different fix for this issue was sent earlier:
https://patchwork.ozlabs.org/patch/1042687/
I think it's more complete than this one.
^ permalink raw reply
* [PATCH v2 net-next 2/2] net: sock: undefine SOCK_DEBUGGING
From: Yafang Shao @ 2019-02-16 16:28 UTC (permalink / raw)
To: davem
Cc: daniel, edumazet, joe, xiyou.wangcong, netdev, shaoyafang,
Yafang Shao
In-Reply-To: <1550334537-380-1-git-send-email-laoar.shao@gmail.com>
SOCK_DEBUG() is a old facility for debugging.
If the user want to use it for debugging, the user must modify the
application first, that doesn't seem like a good way.
Now we have more powerful facilities, i.e. bpf or tracepoint, for this kind
of debugging purpose.
So we'd better disable it by default.
The reason why I don't remove it comepletely is that someone may still
would like to use it for debugging.
Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
Suggested-by: Joe Perches <joe@perches.com>
---
include/net/sock.h | 13 ++++++++-----
net/core/sock.c | 3 +++
2 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/include/net/sock.h b/include/net/sock.h
index 6679f3c..d41e8f4 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -81,14 +81,17 @@
*/
/* Define this to get the SOCK_DBG debugging facility. */
-#define SOCK_DEBUGGING
+/* #define SOCK_DEBUGGING */
#ifdef SOCK_DEBUGGING
-#define SOCK_DEBUG(sk, msg...) do { if ((sk) && sock_flag((sk), SOCK_DBG)) \
- printk(KERN_DEBUG msg); } while (0)
+#define SOCK_DEBUG(sk, fmt, ...) \
+do { \
+ if ((sk) && sock_flag((sk), SOCK_DBG)) \
+ pr_debug(fmt, ##__VA_ARGS__); \
+} while (0)
#else
/* Validate arguments and do nothing */
-static inline __printf(2, 3)
-void SOCK_DEBUG(const struct sock *sk, const char *msg, ...)
+__printf(2, 3)
+static inline void SOCK_DEBUG(const struct sock *sk, const char *fmt, ...)
{
}
#endif
diff --git a/net/core/sock.c b/net/core/sock.c
index 71ded4d..7c15835 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -753,6 +753,9 @@ int sock_setsockopt(struct socket *sock, int level, int optname,
switch (optname) {
case SO_DEBUG:
+ /* This option takes effect only when SOCK_DEBUGGING
+ * is defined.
+ */
if (val && !capable(CAP_NET_ADMIN))
ret = -EACCES;
else
--
1.8.3.1
^ permalink raw reply related
* [PATCH v2 net-next 1/2] tcp: clean up SOCK_DEBUG()
From: Yafang Shao @ 2019-02-16 16:28 UTC (permalink / raw)
To: davem
Cc: daniel, edumazet, joe, xiyou.wangcong, netdev, shaoyafang,
Yafang Shao
In-Reply-To: <1550334537-380-1-git-send-email-laoar.shao@gmail.com>
Per discussion with Daniel[1] and Eric[2], these SOCK_DEBUG() calles in
TCP are not needed now.
We'd better clean up it.
[1] https://patchwork.ozlabs.org/patch/1035573/
[2] https://patchwork.ozlabs.org/patch/1040533/
Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
---
net/ipv4/tcp_input.c | 19 +------------------
net/ipv6/tcp_ipv6.c | 2 --
2 files changed, 1 insertion(+), 20 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 7a027dec..6d2750e 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -3595,7 +3595,7 @@ static int tcp_ack(struct sock *sk, const struct sk_buff *skb, int flag)
* this segment (RFC793 Section 3.9).
*/
if (after(ack, tp->snd_nxt))
- goto invalid_ack;
+ return -1;
if (after(ack, prior_snd_una)) {
flag |= FLAG_SND_UNA_ADVANCED;
@@ -3714,10 +3714,6 @@ static int tcp_ack(struct sock *sk, const struct sk_buff *skb, int flag)
tcp_process_tlp_ack(sk, ack, flag);
return 1;
-invalid_ack:
- SOCK_DEBUG(sk, "Ack %u after %u:%u\n", ack, tp->snd_una, tp->snd_nxt);
- return -1;
-
old_ack:
/* If data was SACKed, tag it and see if we should send more data.
* If data was DSACKed, see if we can undo a cwnd reduction.
@@ -3731,7 +3727,6 @@ static int tcp_ack(struct sock *sk, const struct sk_buff *skb, int flag)
tcp_xmit_recovery(sk, rexmit);
}
- SOCK_DEBUG(sk, "Ack %u before %u:%u\n", ack, tp->snd_una, tp->snd_nxt);
return 0;
}
@@ -4432,13 +4427,9 @@ static void tcp_ofo_queue(struct sock *sk)
rb_erase(&skb->rbnode, &tp->out_of_order_queue);
if (unlikely(!after(TCP_SKB_CB(skb)->end_seq, tp->rcv_nxt))) {
- SOCK_DEBUG(sk, "ofo packet was already received\n");
tcp_drop(sk, skb);
continue;
}
- SOCK_DEBUG(sk, "ofo requeuing : rcv_next %X seq %X - %X\n",
- tp->rcv_nxt, TCP_SKB_CB(skb)->seq,
- TCP_SKB_CB(skb)->end_seq);
tail = skb_peek_tail(&sk->sk_receive_queue);
eaten = tail && tcp_try_coalesce(sk, tail, skb, &fragstolen);
@@ -4502,8 +4493,6 @@ static void tcp_data_queue_ofo(struct sock *sk, struct sk_buff *skb)
NET_INC_STATS(sock_net(sk), LINUX_MIB_TCPOFOQUEUE);
seq = TCP_SKB_CB(skb)->seq;
end_seq = TCP_SKB_CB(skb)->end_seq;
- SOCK_DEBUG(sk, "out of order segment: rcv_next %X seq %X - %X\n",
- tp->rcv_nxt, seq, end_seq);
p = &tp->out_of_order_queue.rb_node;
if (RB_EMPTY_ROOT(&tp->out_of_order_queue)) {
@@ -4779,10 +4768,6 @@ static void tcp_data_queue(struct sock *sk, struct sk_buff *skb)
if (before(TCP_SKB_CB(skb)->seq, tp->rcv_nxt)) {
/* Partial packet, seq < rcv_next < end_seq */
- SOCK_DEBUG(sk, "partial packet: rcv_next %X seq %X - %X\n",
- tp->rcv_nxt, TCP_SKB_CB(skb)->seq,
- TCP_SKB_CB(skb)->end_seq);
-
tcp_dsack_set(sk, TCP_SKB_CB(skb)->seq, tp->rcv_nxt);
/* If window is closed, drop tail of packet. But after
@@ -5061,8 +5046,6 @@ static int tcp_prune_queue(struct sock *sk)
{
struct tcp_sock *tp = tcp_sk(sk);
- SOCK_DEBUG(sk, "prune_queue: c=%x\n", tp->copied_seq);
-
NET_INC_STATS(sock_net(sk), LINUX_MIB_PRUNECALLED);
if (atomic_read(&sk->sk_rmem_alloc) >= sk->sk_rcvbuf)
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index e51cda7..57ef69a1 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -220,8 +220,6 @@ static int tcp_v6_connect(struct sock *sk, struct sockaddr *uaddr,
u32 exthdrlen = icsk->icsk_ext_hdr_len;
struct sockaddr_in sin;
- SOCK_DEBUG(sk, "connect: ipv4 mapped\n");
-
if (__ipv6_only_sock(sk))
return -ENETUNREACH;
--
1.8.3.1
^ permalink raw reply related
* [PATCH v2 net-next 0/2] clean up SOCK_DEBUG()
From: Yafang Shao @ 2019-02-16 16:28 UTC (permalink / raw)
To: davem
Cc: daniel, edumazet, joe, xiyou.wangcong, netdev, shaoyafang,
Yafang Shao
Per discussion with Daniel[1] and Eric[2], these SOCK_DEBUG() calles in
TCP are not needed now.
We'd better clean up it.
Plus undefine SOCK_DEBUGGING by default.
[1] https://patchwork.ozlabs.org/patch/1035573/
[2] https://patchwork.ozlabs.org/patch/1040533/
Yafang Shao (2):
tcp: clean up SOCK_DEBUG()
net: sock: undefine SOCK_DEBUGGING
include/net/sock.h | 13 ++++++++-----
net/core/sock.c | 3 +++
net/ipv4/tcp_input.c | 19 +------------------
net/ipv6/tcp_ipv6.c | 2 --
4 files changed, 12 insertions(+), 25 deletions(-)
--
1.8.3.1
^ permalink raw reply
* [PATCH net-next v2 2/2] net: phy: use mii_10gbt_stat_mod_linkmode_lpa_t in genphy_c45_read_lpa
From: Heiner Kallweit @ 2019-02-16 16:26 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <c6be00e5-d4e5-69a1-cb9c-31cd446556be@gmail.com>
Use mii_10gbt_stat_mod_linkmode_lpa_t() in genphy_c45_read_lpa() to
simplify the code.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/phy/phy-c45.c | 10 +---------
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/drivers/net/phy/phy-c45.c b/drivers/net/phy/phy-c45.c
index 7af5fa81d..bef126344 100644
--- a/drivers/net/phy/phy-c45.c
+++ b/drivers/net/phy/phy-c45.c
@@ -204,15 +204,7 @@ int genphy_c45_read_lpa(struct phy_device *phydev)
if (val < 0)
return val;
- if (val & MDIO_AN_10GBT_STAT_LP2_5G)
- linkmode_set_bit(ETHTOOL_LINK_MODE_2500baseT_Full_BIT,
- phydev->lp_advertising);
- if (val & MDIO_AN_10GBT_STAT_LP5G)
- linkmode_set_bit(ETHTOOL_LINK_MODE_5000baseT_Full_BIT,
- phydev->lp_advertising);
- if (val & MDIO_AN_10GBT_STAT_LP10G)
- linkmode_set_bit(ETHTOOL_LINK_MODE_10000baseT_Full_BIT,
- phydev->lp_advertising);
+ mii_10gbt_stat_mod_linkmode_lpa_t(phydev->lp_advertising, val);
return 0;
}
--
2.20.1
^ permalink raw reply related
* [PATCH net-next v2 1/2] net: phy: add helper mii_10gbt_stat_mod_linkmode_lpa_t
From: Heiner Kallweit @ 2019-02-16 16:26 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <c6be00e5-d4e5-69a1-cb9c-31cd446556be@gmail.com>
Similar to the existing helpers for the Clause 22 registers add helper
mii_10gbt_stat_mod_linkmode_lpa_t.
Note that this helper is defined in linux/mdio.h, not like the
Clause 22 helpers in linux/mii.h. Reason is that the Clause 45 register
constants are defined in uapi/linux/mdio.h. And uapi/linux/mdio.h
includes linux/mii.h before defining the C45 register constants.
v2:
- remove helpers that don't have users in this series
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
include/linux/mdio.h | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/include/linux/mdio.h b/include/linux/mdio.h
index bfa711416..5b872c45f 100644
--- a/include/linux/mdio.h
+++ b/include/linux/mdio.h
@@ -261,6 +261,25 @@ static inline u16 ethtool_adv_to_mmd_eee_adv_t(u32 adv)
return reg;
}
+/**
+ * mii_10gbt_stat_mod_linkmode_lpa_t
+ * @advertising: target the linkmode advertisement settings
+ * @adv: value of the C45 10GBASE-T AN STATUS register
+ *
+ * A small helper function that translates C45 10GBASE-T AN STATUS register bits
+ * to linkmode advertisement settings. Other bits in advertising aren't changed.
+ */
+static inline void mii_10gbt_stat_mod_linkmode_lpa_t(unsigned long *advertising,
+ u32 lpa)
+{
+ linkmode_mod_bit(ETHTOOL_LINK_MODE_2500baseT_Full_BIT,
+ advertising, lpa & MDIO_AN_10GBT_STAT_LP2_5G);
+ linkmode_mod_bit(ETHTOOL_LINK_MODE_5000baseT_Full_BIT,
+ advertising, lpa & MDIO_AN_10GBT_STAT_LP5G);
+ linkmode_mod_bit(ETHTOOL_LINK_MODE_10000baseT_Full_BIT,
+ advertising, lpa & MDIO_AN_10GBT_STAT_LP10G);
+}
+
int __mdiobus_read(struct mii_bus *bus, int addr, u32 regnum);
int __mdiobus_write(struct mii_bus *bus, int addr, u32 regnum, u16 val);
--
2.20.1
^ permalink raw reply related
* [PATCH net-next v2 0/2] net: phy: add helpers for handling C45 10GBT AN register values
From: Heiner Kallweit @ 2019-02-16 16:24 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller; +Cc: netdev@vger.kernel.org
Similar to the existing helpers for the Clause 22 registers add helpers
to deal with converting Clause 45 advertisement registers to / from
link mode bitmaps.
Note that these helpers are defined in linux/mdio.h, not like the
Clause 22 helpers in linux/mii.h. Reason is that the Clause 45 register
constants are defined in uapi/linux/mdio.h. And uapi/linux/mdio.h
includes linux/mii.h before defining the C45 register constants.
v2:
- Remove few helpers which aren't used by this series. They will
follow together with the users.
Heiner Kallweit (2):
net: phy: add helper mii_10gbt_stat_mod_linkmode_lpa_t
net: phy: use mii_10gbt_stat_mod_linkmode_lpa_t in genphy_c45_read_lpa
drivers/net/phy/phy-c45.c | 10 +---------
include/linux/mdio.h | 19 +++++++++++++++++++
2 files changed, 20 insertions(+), 9 deletions(-)
--
2.20.1
^ permalink raw reply
* [BUG] [FIX] net: dsa: oops in br_vlan_enabled
From: Frank Wunderlich @ 2019-02-16 16:22 UTC (permalink / raw)
To: netdev
Hi,
i've found an oops in 4.19.23/10, seems to be fixed anyhow in 5.0 (also works in 4.14.101)
root@bpi-r2:~# ip link add link lan0 name lan0.5 type vlan id 5
root@bpi-r2:~# ip addr add 192.168.5.200/24 brd 192.168.5.255 dev lan0.5
root@bpi-r2:~# ip link set dev lan0 up
root@bpi-r2:~# ip link set dev lan0.5 up
12: lan0.5@lan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state LOWERLAYERDOWN group default qlen 1000
link/ether 02:02:02:02:02:02 brd ff:ff:ff:ff:ff:ff
inet 192.168.5.200/24 brd 192.168.5.255 scope global lan0.5
valid_lft forever preferred_lft forever
root@bpi-r2:~# brctl addbr bridge_name
root@bpi-r2:~# brctl addif bridge_name lan0.5
[ 352.057128] bridge_name: port 1(lan0.5) entered blocking state
[ 352.063065] bridge_name: port 1(lan0.5) entered disabled state
[ 352.069181] device lan0.5 entered promiscuous mode
[ 352.074018] device lan0 entered promiscuous mode
[ 352.078906] Unable to handle kernel NULL pointer dereference at virtual address 00000558
...
[ 352.493085] [<bf0fde88>] (br_vlan_enabled [bridge]) from [<bf12c234>] (dsa_port_vlan_add+0x60/0xbc [dsa_core])
[ 352.503050] [<bf12c234>] (dsa_port_vlan_add [dsa_core]) from [<bf12cb64>] (dsa_slave_port_obj_add+0x4c/0x50 [dsa_core])
[ 352.513776] [<bf12cb64>] (dsa_slave_port_obj_add [dsa_core]) from [<c0b4e2d4>] (__switchdev_port_obj_add+0x50/0xc4)
[ 352.524138] [<c0b4e2d4>] (__switchdev_port_obj_add) from [<c0b4e324>] (__switchdev_port_obj_add+0xa0/0xc4)
[ 352.533721] [<c0b4e324>] (__switchdev_port_obj_add) from [<c0b4e3a8>] (switchdev_port_obj_add_now+0x60/0x130)
[ 352.543562] [<c0b4e3a8>] (switchdev_port_obj_add_now) from [<c0b4e7e4>] (switchdev_port_obj_add+0x44/0x190)
[ 352.553284] [<c0b4e7e4>] (switchdev_port_obj_add) from [<bf1013d0>] (br_switchdev_port_vlan_add+0x60/0x7c [bridge])
[ 352.563733] [<bf1013d0>] (br_switchdev_port_vlan_add [bridge]) from [<bf0ff250>] (__vlan_add+0xb0/0x620 [bridge])
[ 352.574007] [<bf0ff250>] (__vlan_add [bridge]) from [<bf0ffd04>] (nbp_vlan_add+0xc4/0x150 [bridge])
[ 352.583073] [<bf0ffd04>] (nbp_vlan_add [bridge]) from [<bf0ffec4>] (nbp_vlan_init+0x134/0x164 [bridge])
[ 352.592482] [<bf0ffec4>] (nbp_vlan_init [bridge]) from [<bf0edd4c>] (br_add_if+0x40c/0x5fc [bridge])
[ 352.601632] [<bf0edd4c>] (br_add_if [bridge]) from [<bf0eeb14>] (add_del_if+0x6c/0x80 [bridge])
[ 352.610351] [<bf0eeb14>] (add_del_if [bridge]) from [<bf0ef5b0>] (br_dev_ioctl+0x7c/0x9c [bridge])
[ 352.619290] [<bf0ef5b0>] (br_dev_ioctl [bridge]) from [<c09583d4>] (dev_ifsioc+0x184/0x324)
[ 352.627582] [<c09583d4>] (dev_ifsioc) from [<c09589e8>] (dev_ioctl+0x32c/0x5cc)
[ 352.634837] [<c09589e8>] (dev_ioctl) from [<c090913c>] (sock_ioctl+0x3bc/0x580)
since my 4.19.23 kernel is modified a bit i tried with 4.19.10 without my net modifications and it is still reproducable with steps above (create a vlan on dsa-user-port and then use it in a bridge)
i fixed it with these changes:
diff --git a/net/dsa/port.c b/net/dsa/port.c
index ed0595459df1..962887752ae8 100644
--- a/net/dsa/port.c
+++ b/net/dsa/port.c
@@ -255,8 +255,9 @@ int dsa_port_vlan_add(struct dsa_port *dp,
if (netif_is_bridge_master(vlan->obj.orig_dev))
return -EOPNOTSUPP;
- if (br_vlan_enabled(dp->bridge_dev))
- return dsa_port_notify(dp, DSA_NOTIFIER_VLAN_ADD, &info);
+ printk(KERN_ALERT "DEBUG: Passed %s %d 0x%x \n",__FUNCTION__,__LINE__,(unsigned int)dp->bridge_dev);
+ if (!dp->bridge_dev || br_vlan_enabled(dp->bridge_dev))
+ return dsa_port_notify(dp, DSA_NOTIFIER_VLAN_DEL, &info);
return 0;
}
@@ -273,7 +274,7 @@ int dsa_port_vlan_del(struct dsa_port *dp,
if (netif_is_bridge_master(vlan->obj.orig_dev))
return -EOPNOTSUPP;
- if (br_vlan_enabled(dp->bridge_dev))
+ if (!dp->bridge_dev || br_vlan_enabled(dp->bridge_dev))
return dsa_port_notify(dp, DSA_NOTIFIER_VLAN_DEL, &info);
return 0;
i've found in a Patch from florian/vivien: https://www.mail-archive.com/netdev@vger.kernel.org/msg281415.html
Strange that 5.0-rc1 does not crash,because these 2 code-sections are unchanged: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/dsa/port.c#n255 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/bridge/br_vlan.c#n788
maybe you know why only 4.19 is affected...
regards Frank
^ permalink raw reply related
* Re: [PATCH net-next 1/2] net: phy: add helpers for handling C45 10GBT AN register values
From: Heiner Kallweit @ 2019-02-16 16:07 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Florian Fainelli, David Miller, netdev@vger.kernel.org
In-Reply-To: <20190216160053.GP5699@lunn.ch>
On 16.02.2019 17:00, Andrew Lunn wrote:
> On Fri, Feb 15, 2019 at 09:57:49PM +0100, Heiner Kallweit wrote:
>> Similar to the existing helpers for the Clause 22 registers add helpers
>> to deal with converting Clause 45 advertisement registers to / from
>> link mode bitmaps.
>>
>> Note that these helpers are defined in linux/mdio.h, not like the
>> Clause 22 helpers in linux/mii.h. Reason is that the Clause 45 register
>> constants are defined in uapi/linux/mdio.h. And uapi/linux/mdio.h
>> includes linux/mii.h before defining the C45 register constants.
>
> Hi Heiner
>
> You add three helpers, but the followup patch only uses one of them.
> Maybe you should wait until you have real uses of the other two?
> Or just add the one helper.
>
Ah, right. I created all helpers but at least one user isn't ready yet.
I'll resend the series with just the helper being used now.
> Andrew
>
Heiner
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: phy: add helpers for handling C45 10GBT AN register values
From: Andrew Lunn @ 2019-02-16 16:00 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: Florian Fainelli, David Miller, netdev@vger.kernel.org
In-Reply-To: <5c217a09-dac8-d8db-3a38-c9a621ae55a6@gmail.com>
On Fri, Feb 15, 2019 at 09:57:49PM +0100, Heiner Kallweit wrote:
> Similar to the existing helpers for the Clause 22 registers add helpers
> to deal with converting Clause 45 advertisement registers to / from
> link mode bitmaps.
>
> Note that these helpers are defined in linux/mdio.h, not like the
> Clause 22 helpers in linux/mii.h. Reason is that the Clause 45 register
> constants are defined in uapi/linux/mdio.h. And uapi/linux/mdio.h
> includes linux/mii.h before defining the C45 register constants.
Hi Heiner
You add three helpers, but the followup patch only uses one of them.
Maybe you should wait until you have real uses of the other two?
Or just add the one helper.
Andrew
^ permalink raw reply
* Re: [PATCH v2] net: dsa: Implement flow_dissect callback for tag_dsa.
From: Andrew Lunn @ 2019-02-16 15:42 UTC (permalink / raw)
To: Rundong Ge; +Cc: vivien.didelot, f.fainelli, davem, netdev, linux-kernel
In-Reply-To: <20190216083524.860-1-rdong.ge@gmail.com>
On Sat, Feb 16, 2019 at 08:35:24AM +0000, Rundong Ge wrote:
> RPS not work for DSA devices since the 'skb_get_hash'
> will always get the invalid hash for dsa tagged packets.
>
> "[PATCH] tag_mtk: add flow_dissect callback to the ops struct"
> introduced the flow_dissect callback to get the right hash for
> MTK tagged packet. Tag_dsa and tag_edsa also need to implement
> the callback.
>
> Signed-off-by: Rundong Ge <rdong.ge@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH v2] net: dsa: Implement flow_dissect callback for tag_dsa.
From: Andrew Lunn @ 2019-02-16 15:35 UTC (permalink / raw)
To: Rundong Ge; +Cc: vivien.didelot, Florian Fainelli, davem, netdev, linux-kernel
In-Reply-To: <CAN1Lvyqo4K3OJEO-RAnp03tM5SgBr3ZK=NTCtKOc+YTymjw8CA@mail.gmail.com>
On Sat, Feb 16, 2019 at 04:38:25PM +0800, Rundong Ge wrote:
> Hi Andrew
>
> I have tested the L3 forwarding throughput performance of my box (with
> an intel 4-core processor and each core’s frequency is 2.20GHz).
> In my test scenario, I generated 200 UDP flows (frame size is 64
> bytes) with different src/dst pairs from eth1 to eth0. Eth1 is a slave
> DSA device from mv88e6190x, eth0 is an intel NIC. Then get the max fps
> with no frame losing.
>
> The max fps with RPS working is 400235fps, frames are hashed to four
> cores’ backlog.
> And the max fps without RPS is 199686fps.
Nice numbers, thanks.
Andrew
^ permalink raw reply
* phy speed setting issue: e1000: Add support for the CE4100 reference platform
From: Colin Ian King @ 2019-02-16 14:26 UTC (permalink / raw)
To: Dirk Brandewie, Jeff Pieper, Jeff Kirsher
Cc: David S. Miller, netdev, linux-kernel@vger.kernel.org
Hi,
Static analysis from CoverityScan has detected an issue with the speed
setup with the control setting in the e1000 driver.
Function e1000_config_mac_to_phy in
/drivers/net/ethernet/intel/e1000/e1000_hw.c, CoverityScan reports:
CID 140032 (#1 of 1): Operands don't affect result
(CONSTANT_EXPRESSION_RESULT)
result_independent_of_operands: phy_data & 0x200000 is always 0
regardless of the values of its operands. This occurs as the logical
operand of if.
1936 if (phy_data & RTL_PHY_CTRL_SPD_100)
1937 ctrl |= E1000_CTRL_SPD_100;
1938 else
1939 ctrl |= E1000_CTRL_SPD_10;
phy_data is a u16 however the 100 mbit speed bitmask is 0x200000, hence
the bitwise with phy_data will always result in zero, and so the ctrl is
never set to E1000_CTRL_SPD_100.
I'm not familiar with this hardware, so I'm not sure what appropriate
mask should be.
Issue was introduced with commit: 5377a4160bb6 ("e1000: Add support for
the CE4100 reference platform")
Colin
^ permalink raw reply
* -Wimplicit-fallthrough not working with ccache
From: Kalle Valo @ 2019-02-16 11:21 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: netdev, linux-wireless, linux-kernel, ath10k, David S. Miller,
linux-kbuild
In-Reply-To: <20180613114059.DAC95601D2@smtp.codeaurora.org>
(replying to an old thread but renaming it)
Kalle Valo <kvalo@codeaurora.org> writes:
> "Gustavo A. R. Silva" <gustavo@embeddedor.com> wrote:
>
>> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
>> where we are expecting to fall through.
>>
>> Notice that in this particular case, I replaced "pass through" with
>> a proper "fall through" comment, which is what GCC is expecting
>> to find.
>>
>> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
>> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
>
> Patch applied to ath-next branch of ath.git, thanks.
>
> f1d270ae10ff ath10k: htt_tx: mark expected switch fall-throughs
Gustavo, I enabled W=1 on my ath10k build checks and it took me a while
to figure out why GCC was warning about fall through annotations missing
even I knew you had fixed them. Finally I figured out that the reason
was ccache, which I need because I work with different branches and need
to recompile the kernel quite often.
If the plan is to enable -Wimplicit-fallthrough by default in the kernel
IMHO this might become an issue, as otherwise people using ccache start
seeing lots of invalid warnings. Apparently CCACHE_COMMENTS=1 will fix
that but my version of ccache doesn't support it, and how would everyone
learn that trick anyway? Or maybe CCACHE_COMMENTS can enabled through
kernel Makefile?
--
Kalle Valo
^ permalink raw reply
* INFO: task hung in addrconf_dad_work
From: syzbot @ 2019-02-16 10:20 UTC (permalink / raw)
To: ast, christian, daniel, davem, dsahern, hawk, idosch,
jakub.kicinski, john.fastabend, kafai, ktkhai, linux-kernel,
netdev, petrm, roopa, songliubraving, syzkaller-bugs, xdp-newbies,
yhs
Hello,
syzbot found the following crash on:
HEAD commit: 5ded5871030e Merge tag 'scsi-fixes' of git://git.kernel.or..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1577228f400000
kernel config: https://syzkaller.appspot.com/x/.config?x=ee434566c893c7b1
dashboard link: https://syzkaller.appspot.com/bug?extid=f4290c15a8ab6dee87c9
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10ee52d4c00000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1073879cc00000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+f4290c15a8ab6dee87c9@syzkaller.appspotmail.com
INFO: task kworker/0:1:12 blocked for more than 140 seconds.
Not tainted 5.0.0-rc6+ #73
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
kworker/0:1 D26560 12 2 0x80000000
Workqueue: ipv6_addrconf addrconf_dad_work
Call Trace:
context_switch kernel/sched/core.c:2844 [inline]
__schedule+0x817/0x1cc0 kernel/sched/core.c:3485
schedule+0x92/0x180 kernel/sched/core.c:3529
schedule_preempt_disabled+0x13/0x20 kernel/sched/core.c:3587
__mutex_lock_common kernel/locking/mutex.c:1002 [inline]
__mutex_lock+0x726/0x1310 kernel/locking/mutex.c:1072
mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1087
rtnl_lock+0x17/0x20 net/core/rtnetlink.c:77
addrconf_dad_work+0xad/0x1150 net/ipv6/addrconf.c:3995
process_one_work+0x98e/0x1790 kernel/workqueue.c:2173
worker_thread+0x98/0xe40 kernel/workqueue.c:2319
kthread+0x357/0x430 kernel/kthread.c:246
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
INFO: task kworker/1:1:22 blocked for more than 140 seconds.
Not tainted 5.0.0-rc6+ #73
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
kworker/1:1 D26848 22 2 0x80000000
Workqueue: ipv6_addrconf addrconf_dad_work
Call Trace:
context_switch kernel/sched/core.c:2844 [inline]
__schedule+0x817/0x1cc0 kernel/sched/core.c:3485
schedule+0x92/0x180 kernel/sched/core.c:3529
schedule_preempt_disabled+0x13/0x20 kernel/sched/core.c:3587
__mutex_lock_common kernel/locking/mutex.c:1002 [inline]
__mutex_lock+0x726/0x1310 kernel/locking/mutex.c:1072
mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1087
rtnl_lock+0x17/0x20 net/core/rtnetlink.c:77
addrconf_dad_work+0xad/0x1150 net/ipv6/addrconf.c:3995
process_one_work+0x98e/0x1790 kernel/workqueue.c:2173
worker_thread+0x98/0xe40 kernel/workqueue.c:2319
kthread+0x357/0x430 kernel/kthread.c:246
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
Showing all locks held in the system:
3 locks held by kworker/0:1/12:
#0: 00000000c092f744 ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at:
__write_once_size include/linux/compiler.h:220 [inline]
#0: 00000000c092f744 ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at:
arch_atomic64_set arch/x86/include/asm/atomic64_64.h:34 [inline]
#0: 00000000c092f744 ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at:
atomic64_set include/asm-generic/atomic-instrumented.h:40 [inline]
#0: 00000000c092f744 ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at:
atomic_long_set include/asm-generic/atomic-long.h:59 [inline]
#0: 00000000c092f744 ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at:
set_work_data kernel/workqueue.c:617 [inline]
#0: 00000000c092f744 ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at:
set_work_pool_and_clear_pending kernel/workqueue.c:644 [inline]
#0: 00000000c092f744 ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at:
process_one_work+0x87e/0x1790 kernel/workqueue.c:2144
#1: 00000000ba501015 ((work_completion)(&(&ifa->dad_work)->work)){+.+.},
at: process_one_work+0x8b4/0x1790 kernel/workqueue.c:2148
#2: 000000000a023ce4 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:77
3 locks held by kworker/1:1/22:
#0: 00000000c092f744 ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at:
__write_once_size include/linux/compiler.h:220 [inline]
#0: 00000000c092f744 ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at:
arch_atomic64_set arch/x86/include/asm/atomic64_64.h:34 [inline]
#0: 00000000c092f744 ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at:
atomic64_set include/asm-generic/atomic-instrumented.h:40 [inline]
#0: 00000000c092f744 ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at:
atomic_long_set include/asm-generic/atomic-long.h:59 [inline]
#0: 00000000c092f744 ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at:
set_work_data kernel/workqueue.c:617 [inline]
#0: 00000000c092f744 ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at:
set_work_pool_and_clear_pending kernel/workqueue.c:644 [inline]
#0: 00000000c092f744 ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at:
process_one_work+0x87e/0x1790 kernel/workqueue.c:2144
#1: 00000000609e3f2e ((work_completion)(&(&ifa->dad_work)->work)){+.+.},
at: process_one_work+0x8b4/0x1790 kernel/workqueue.c:2148
#2: 000000000a023ce4 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:77
1 lock held by khungtaskd/1039:
#0: 000000009a681c98 (rcu_read_lock){....}, at:
debug_show_all_locks+0x5f/0x27e kernel/locking/lockdep.c:4389
1 lock held by rsyslogd/7932:
#0: 000000000ae60368 (&f->f_pos_lock){+.+.}, at: __fdget_pos+0xee/0x110
fs/file.c:795
2 locks held by getty/8054:
#0: 00000000330eb6bd (&tty->ldisc_sem){++++}, at:
ldsem_down_read+0x33/0x40 drivers/tty/tty_ldsem.c:341
#1: 00000000115a4ff9 (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x232/0x1b70 drivers/tty/n_tty.c:2154
2 locks held by getty/8055:
#0: 000000001f90753f (&tty->ldisc_sem){++++}, at:
ldsem_down_read+0x33/0x40 drivers/tty/tty_ldsem.c:341
#1: 000000001e27037e (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x232/0x1b70 drivers/tty/n_tty.c:2154
2 locks held by getty/8056:
#0: 0000000027f8ba41 (&tty->ldisc_sem){++++}, at:
ldsem_down_read+0x33/0x40 drivers/tty/tty_ldsem.c:341
#1: 00000000a0356b01 (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x232/0x1b70 drivers/tty/n_tty.c:2154
2 locks held by getty/8057:
#0: 000000009cf2ea94 (&tty->ldisc_sem){++++}, at:
ldsem_down_read+0x33/0x40 drivers/tty/tty_ldsem.c:341
#1: 0000000097e38bce (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x232/0x1b70 drivers/tty/n_tty.c:2154
2 locks held by getty/8058:
#0: 000000006dd48e75 (&tty->ldisc_sem){++++}, at:
ldsem_down_read+0x33/0x40 drivers/tty/tty_ldsem.c:341
#1: 00000000a75b841a (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x232/0x1b70 drivers/tty/n_tty.c:2154
2 locks held by getty/8059:
#0: 0000000020112132 (&tty->ldisc_sem){++++}, at:
ldsem_down_read+0x33/0x40 drivers/tty/tty_ldsem.c:341
#1: 00000000c3504044 (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x232/0x1b70 drivers/tty/n_tty.c:2154
2 locks held by getty/8060:
#0: 000000001510234f (&tty->ldisc_sem){++++}, at:
ldsem_down_read+0x33/0x40 drivers/tty/tty_ldsem.c:341
#1: 00000000e70220db (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x232/0x1b70 drivers/tty/n_tty.c:2154
1 lock held by syz-executor112/8443:
=============================================
NMI backtrace for cpu 1
CPU: 1 PID: 1039 Comm: khungtaskd Not tainted 5.0.0-rc6+ #73
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x172/0x1f0 lib/dump_stack.c:113
nmi_cpu_backtrace.cold+0x63/0xa4 lib/nmi_backtrace.c:101
nmi_trigger_cpumask_backtrace+0x1be/0x236 lib/nmi_backtrace.c:62
arch_trigger_cpumask_backtrace+0x14/0x20 arch/x86/kernel/apic/hw_nmi.c:38
trigger_all_cpu_backtrace include/linux/nmi.h:146 [inline]
check_hung_uninterruptible_tasks kernel/hung_task.c:203 [inline]
watchdog+0x9df/0xee0 kernel/hung_task.c:287
kthread+0x357/0x430 kernel/kthread.c:246
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
Sending NMI from CPU 1 to CPUs 0:
INFO: NMI handler (nmi_cpu_backtrace_handler) took too long to run: 1.262
msecs
NMI backtrace for cpu 0
CPU: 0 PID: 8443 Comm: syz-executor112 Not tainted 5.0.0-rc6+ #73
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:preempt_count_add+0xf8/0x1b0 kernel/sched/core.c:3210
Code: 11 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02
00 0f 85 ab 00 00 00 49 89 9c 24 b0 11 00 00 5b 41 5c 5d <c3> 48 8b 45 00
48 8b 58 08 48 89 df e8 27 e7 09 00 85 c0 74 b3 48
RSP: 0018:ffff88809e13f190 EFLAGS: 00000046
RAX: dffffc0000000000 RBX: 0000000000000286 RCX: 0000000000000000
RDX: 1ffff1100f1efe66 RSI: 0000000000000000 RDI: ffff888078f7f330
RBP: ffff88809e13f1a8 R08: ffff888078f7e180 R09: ffffed1015d05bd0
R10: ffffed1015d05bcf R11: ffff8880ae82de7b R12: ffffffff8a648b08
R13: 0000000000000086 R14: ffffffff8a648b08 R15: 00000000004012c0
FS: 00000000019f3940(0000) GS:ffff8880ae800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffffff600400 CR3: 00000000a1211000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
__debug_check_no_obj_freed lib/debugobjects.c:776 [inline]
debug_check_no_obj_freed+0xbe/0x464 lib/debugobjects.c:817
kfree+0xbd/0x230 mm/slab.c:3805
skb_free_head+0x93/0xb0 net/core/skbuff.c:553
pskb_expand_head+0x2ba/0xdd0 net/core/skbuff.c:1498
netlink_trim+0x215/0x270 net/netlink/af_netlink.c:1292
netlink_unicast+0xbf/0x720 net/netlink/af_netlink.c:1326
rtnetlink_send+0xf0/0x110 net/core/rtnetlink.c:721
tcf_add_notify net/sched/act_api.c:1325 [inline]
tcf_action_add+0x243/0x370 net/sched/act_api.c:1344
tc_ctl_action+0x3b6/0x4bd net/sched/act_api.c:1392
rtnetlink_rcv_msg+0x465/0xb00 net/core/rtnetlink.c:5130
netlink_rcv_skb+0x17a/0x460 net/netlink/af_netlink.c:2477
rtnetlink_rcv+0x1d/0x30 net/core/rtnetlink.c:5148
netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline]
netlink_unicast+0x536/0x720 net/netlink/af_netlink.c:1336
netlink_sendmsg+0x8ae/0xd70 net/netlink/af_netlink.c:1917
sock_sendmsg_nosec net/socket.c:621 [inline]
sock_sendmsg+0xdd/0x130 net/socket.c:631
___sys_sendmsg+0x806/0x930 net/socket.c:2114
__sys_sendmsg+0x105/0x1d0 net/socket.c:2152
__do_sys_sendmsg net/socket.c:2161 [inline]
__se_sys_sendmsg net/socket.c:2159 [inline]
__x64_sys_sendmsg+0x78/0xb0 net/socket.c:2159
do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x45b129
Code: e8 3c 0a 03 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 5b 07 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007ffc05c7adc8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 000000000045b129
RDX: 00000000000000c4 RSI: 0000000020000300 RDI: 0000000000000003
RBP: 0000000000000000 R08: 00000000000003e8 R09: 00000000000003e8
R10: 0000000000000004 R11: 0000000000000246 R12: 0000000000000162
R13: 000000000041bda0 R14: 0000000000000000 R15: 0000000000000000
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* [PATCH net-next] liquidio: using NULL instead of plain integer
From: YueHaibing @ 2019-02-16 9:53 UTC (permalink / raw)
To: davem, dchickles, sburla, fmanlunas; +Cc: linux-kernel, netdev, YueHaibing
Fix following warning:
drivers/net/ethernet/cavium/liquidio/cn23xx_pf_device.c:1453:35: warning: Using plain integer as NULL pointer
drivers/net/ethernet/cavium/liquidio/lio_main.c:2910:23: warning: Using plain integer as NULL pointer
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/ethernet/cavium/liquidio/cn23xx_pf_device.c | 2 +-
drivers/net/ethernet/cavium/liquidio/lio_main.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/cavium/liquidio/cn23xx_pf_device.c b/drivers/net/ethernet/cavium/liquidio/cn23xx_pf_device.c
index 9f4f3c1d..43d11c3 100644
--- a/drivers/net/ethernet/cavium/liquidio/cn23xx_pf_device.c
+++ b/drivers/net/ethernet/cavium/liquidio/cn23xx_pf_device.c
@@ -1450,7 +1450,7 @@ void cn23xx_tell_vf_its_macaddr_changed(struct octeon_device *oct, int vfidx,
mbox_cmd.recv_len = 0;
mbox_cmd.recv_status = 0;
mbox_cmd.fn = NULL;
- mbox_cmd.fn_arg = 0;
+ mbox_cmd.fn_arg = NULL;
ether_addr_copy(mbox_cmd.msg.s.params, mac);
mbox_cmd.q_no = vfidx * oct->sriov_info.rings_per_vf;
octeon_mbox_write(oct, &mbox_cmd);
diff --git a/drivers/net/ethernet/cavium/liquidio/lio_main.c b/drivers/net/ethernet/cavium/liquidio/lio_main.c
index e97e675..9b7819f 100644
--- a/drivers/net/ethernet/cavium/liquidio/lio_main.c
+++ b/drivers/net/ethernet/cavium/liquidio/lio_main.c
@@ -2907,7 +2907,7 @@ static int liquidio_set_vf_spoofchk(struct net_device *netdev, int vfidx,
nctrl.ncmd.s.param2 = enable;
nctrl.ncmd.s.more = 0;
nctrl.iq_no = lio->linfo.txpciq[0].s.q_no;
- nctrl.cb_fn = 0;
+ nctrl.cb_fn = NULL;
retval = octnet_send_nic_ctrl_pkt(oct, &nctrl);
--
2.7.0
^ permalink raw reply related
* Re: [PATCH net-next] netfilter: ipt_CLUSTERIP: make symbol 'cip_netdev_notifier' static
From: Pablo Neira Ayuso @ 2019-02-16 9:44 UTC (permalink / raw)
To: Wei Yongjun
Cc: Jozsef Kadlecsik, Florian Westphal, Alexey Kuznetsov,
Hideaki YOSHIFUJI, Taehee Yoo, netfilter-devel, coreteam, netdev,
kernel-janitors
In-Reply-To: <20190216081606.91596-1-weiyongjun1@huawei.com>
On Sat, Feb 16, 2019 at 08:16:06AM +0000, Wei Yongjun wrote:
> Fixes the following sparse warnings:
>
> net/ipv4/netfilter/ipt_CLUSTERIP.c:867:23: warning:
> symbol 'cip_netdev_notifier' was not declared. Should it be static?
Applied, thanks.
^ permalink raw reply
* [PATCH net-next] cfg80211: pmsr: use eth_broadcast_addr() to assign broadcast address
From: Mao Wenan @ 2019-02-16 9:47 UTC (permalink / raw)
To: johannes, linux-wireless, kernel-janitors, netdev
This patch is to use eth_broadcast_addr() to assign broadcast address
insetad of memset().
Signed-off-by: Mao Wenan <maowenan@huawei.com>
---
net/wireless/pmsr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/wireless/pmsr.c b/net/wireless/pmsr.c
index de9286703280..21139b82749f 100644
--- a/net/wireless/pmsr.c
+++ b/net/wireless/pmsr.c
@@ -258,7 +258,7 @@ int nl80211_pmsr_start(struct sk_buff *skb, struct genl_info *info)
} else {
memcpy(req->mac_addr, nla_data(info->attrs[NL80211_ATTR_MAC]),
ETH_ALEN);
- memset(req->mac_addr_mask, 0xff, ETH_ALEN);
+ eth_broadcast_addr(req->mac_addr_mask);
}
idx = 0;
--
2.20.1
^ permalink raw reply related
* [PATCH net-next] r8169: remove unneeded mmiowb barriers
From: Heiner Kallweit @ 2019-02-16 9:20 UTC (permalink / raw)
To: Realtek linux nic maintainers, David Miller; +Cc: netdev@vger.kernel.org
writex() has implicit barriers, that's what makes it different from
writex_relaxed(). Therefore these calls to mmiowb() can be removed.
This patch was recently reverted due to a dependency with another
problematic patch. But because it didn't contribute to the problem
it was rebased and can be resubmitted.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/ethernet/realtek/r8169.c | 6 ------
1 file changed, 6 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 548fe260b..3cca2ffb2 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -1288,13 +1288,11 @@ static u8 rtl8168d_efuse_read(struct rtl8169_private *tp, int reg_addr)
static void rtl_ack_events(struct rtl8169_private *tp, u16 bits)
{
RTL_W16(tp, IntrStatus, bits);
- mmiowb();
}
static void rtl_irq_disable(struct rtl8169_private *tp)
{
RTL_W16(tp, IntrMask, 0);
- mmiowb();
}
#define RTL_EVENT_NAPI_RX (RxOK | RxErr)
@@ -6251,8 +6249,6 @@ static netdev_tx_t rtl8169_start_xmit(struct sk_buff *skb,
RTL_W8(tp, TxPoll, NPQ);
- mmiowb();
-
if (!rtl_tx_slots_avail(tp, MAX_SKB_FRAGS)) {
/* Avoid wrongly optimistic queue wake-up: rtl_tx thread must
* not miss a ring update when it notices a stopped queue.
@@ -6597,9 +6593,7 @@ static int rtl8169_poll(struct napi_struct *napi, int budget)
if (work_done < budget) {
napi_complete_done(napi, work_done);
-
rtl_irq_enable(tp);
- mmiowb();
}
return work_done;
--
2.20.1
^ permalink raw reply related
* [PATCH] r8152: Add support for MAC address pass through on RTL8153-BD
From: David Chen @ 2019-02-16 9:16 UTC (permalink / raw)
To: linux-usb, netdev, linux-kernel
Cc: davem, hayeswang, mario.limonciello, bigeasy, edumazet, jslaby,
f.fainelli, david.chen7, kai.heng.feng, zhongjiang
From: David Chen <david.chen7@dell.com>
RTL8153-BD is used in Dell DA300 type-C dongle.
It should be added to the whitelist of devices to activate MAC address
pass through.
Per confirming with Realtek all devices containing RTL8153-BD should
activate MAC pass through and there won't use pass through bit on efuse
like in RTL8153-AD.
Signed-off-by: David Chen <david.chen7@dell.com>
---
drivers/net/usb/r8152.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 60dd1ec1665f..ada6baf8847a 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -557,6 +557,7 @@ enum spd_duplex {
/* MAC PASSTHRU */
#define AD_MASK 0xfee0
#define BND_MASK 0x0004
+#define BD_MASK 0x0001
#define EFUSE 0xcfdb
#define PASS_THRU_MASK 0x1
@@ -1176,9 +1177,9 @@ static int vendor_mac_passthru_addr_read(struct r8152 *tp, struct sockaddr *sa)
return -ENODEV;
}
} else {
- /* test for RTL8153-BND */
+ /* test for RTL8153-BND and RTL8153-BD */
ocp_data = ocp_read_byte(tp, MCU_TYPE_USB, USB_MISC_1);
- if ((ocp_data & BND_MASK) == 0) {
+ if ((ocp_data & BND_MASK) == 0 && (ocp_data & BD_MASK)) {
netif_dbg(tp, probe, tp->netdev,
"Invalid variant for MAC pass through\n");
return -ENODEV;
--
2.19.1
^ permalink raw reply related
* Re: [PATCH v2] net: dsa: Implement flow_dissect callback for tag_dsa.
From: Rundong Ge @ 2019-02-16 8:38 UTC (permalink / raw)
To: Andrew Lunn; +Cc: vivien.didelot, Florian Fainelli, davem, netdev, linux-kernel
In-Reply-To: <20190216083524.860-1-rdong.ge@gmail.com>
Hi Andrew
I have tested the L3 forwarding throughput performance of my box (with
an intel 4-core processor and each core’s frequency is 2.20GHz).
In my test scenario, I generated 200 UDP flows (frame size is 64
bytes) with different src/dst pairs from eth1 to eth0. Eth1 is a slave
DSA device from mv88e6190x, eth0 is an intel NIC. Then get the max fps
with no frame losing.
The max fps with RPS working is 400235fps, frames are hashed to four
cores’ backlog.
And the max fps without RPS is 199686fps.
Rundong
Rundong Ge <rdong.ge@gmail.com> 于2019年2月16日周六 下午4:35写道：
>
> RPS not work for DSA devices since the 'skb_get_hash'
> will always get the invalid hash for dsa tagged packets.
>
> "[PATCH] tag_mtk: add flow_dissect callback to the ops struct"
> introduced the flow_dissect callback to get the right hash for
> MTK tagged packet. Tag_dsa and tag_edsa also need to implement
> the callback.
>
> Signed-off-by: Rundong Ge <rdong.ge@gmail.com>
> ---
> net/dsa/tag_dsa.c | 9 +++++++++
> net/dsa/tag_edsa.c | 9 +++++++++
> 2 files changed, 18 insertions(+)
>
> diff --git a/net/dsa/tag_dsa.c b/net/dsa/tag_dsa.c
> index 8b2f92e..67ff3fa 100644
> --- a/net/dsa/tag_dsa.c
> +++ b/net/dsa/tag_dsa.c
> @@ -146,8 +146,17 @@ static struct sk_buff *dsa_rcv(struct sk_buff *skb, struct net_device *dev,
> return skb;
> }
>
> +static int dsa_tag_flow_dissect(const struct sk_buff *skb, __be16 *proto,
> + int *offset)
> +{
> + *offset = 4;
> + *proto = ((__be16 *)skb->data)[1];
> + return 0;
> +}
> +
> const struct dsa_device_ops dsa_netdev_ops = {
> .xmit = dsa_xmit,
> .rcv = dsa_rcv,
> + .flow_dissect = dsa_tag_flow_dissect,
> .overhead = DSA_HLEN,
> };
> diff --git a/net/dsa/tag_edsa.c b/net/dsa/tag_edsa.c
> index f5b87ee..234585e 100644
> --- a/net/dsa/tag_edsa.c
> +++ b/net/dsa/tag_edsa.c
> @@ -165,8 +165,17 @@ static struct sk_buff *edsa_rcv(struct sk_buff *skb, struct net_device *dev,
> return skb;
> }
>
> +static int edsa_tag_flow_dissect(const struct sk_buff *skb, __be16 *proto,
> + int *offset)
> +{
> + *offset = 8;
> + *proto = ((__be16 *)skb->data)[3];
> + return 0;
> +}
> +
> const struct dsa_device_ops edsa_netdev_ops = {
> .xmit = edsa_xmit,
> .rcv = edsa_rcv,
> + .flow_dissect = edsa_tag_flow_dissect,
> .overhead = EDSA_HLEN,
> };
> --
> 1.8.3.1
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox