* Re: linux-next: Fixes tag needs some work in the net-next tree
From: tanhuazhong @ 2019-02-27 1:12 UTC (permalink / raw)
To: Stephen Rothwell, David Miller, Networking
Cc: Linux Next Mailing List, Linux Kernel Mailing List, Jian Shen,
Peng Li
In-Reply-To: <20190225190034.0cad4e3d@canb.auug.org.au>
Hi Stephen & David,
It is my mistake, so sorry about this. There is a redundant "net: hns3:
" in the fixes tag.
How could I fix it?
Thanks.
On 2019/2/25 16:00, Stephen Rothwell wrote:
> Hi all,
>
> In commit
>
> a638b1d8cc87 ("net: hns3: fix get VF RSS issue")
>
> Fixes tag
>
> Fixes: 374ad291762a ("net: hns3: net: hns3: Add RSS general configuration support for VF")
>
> has these problem(s):
>
> - Subject does not match target commit subject
> Just use
> git log -1 --format='Fixes: %h (%s)'
>
^ permalink raw reply
* Re: [PATCH net-next 1/2] vxlan: add extack support for create and changelink
From: Roopa Prabhu @ 2019-02-27 1:05 UTC (permalink / raw)
To: Petr Machata
Cc: davem@davemloft.net, netdev@vger.kernel.org,
dsa@cumulusnetworks.com, sd@queasysnail.net,
johannes@sipsolutions.net
In-Reply-To: <87h8cqfnq8.fsf@mellanox.com>
On Tue, Feb 26, 2019 at 9:45 AM Petr Machata <petrm@mellanox.com> wrote:
>
>
> Roopa Prabhu <roopa@cumulusnetworks.com> writes:
>
> > On Tue, Feb 26, 2019 at 5:51 AM Petr Machata <petrm@mellanox.com> wrote:
> >>
> >> Many of the flags for which you call this don't actually have the else
> >> branch. However I suspect there are no good reasons not to allow
> >> resetting a flag.
> >>
> >> Reviewed-by: Petr Machata <petrm@mellanox.com>
> >
> > yes, correct, that was intentional.
> > also, I am not sure what is the best way to support reseting of a NLA_FLAG.
> > Absence of the flag attribute in the request cannot be the reason for
> > resetting or clearing the flag.
>
> Yeah, I was thinking about that. It looks like this would need a new set
> of u8 attributes :-(
yes, and thats unfortunate. We should keep an eye on future NLA_FLAG
attributes during review .
^ permalink raw reply
* [PATCH net-next] net: sched: pie: fix 64-bit division
From: Leslie Monis @ 2019-02-27 1:00 UTC (permalink / raw)
To: davem; +Cc: netdev, Leslie Monis
Use div_u64() to resolve build failures on 32-bit platforms.
Fixes: 3f7ae5f3dc52 ("net: sched: pie: add more cases to auto-tune alpha and beta")
Signed-off-by: Leslie Monis <lesliemonis@gmail.com>
---
net/sched/sch_pie.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/sched/sch_pie.c b/net/sched/sch_pie.c
index 4c0670b6aec1..f93cfe034c72 100644
--- a/net/sched/sch_pie.c
+++ b/net/sched/sch_pie.c
@@ -429,7 +429,7 @@ static void calculate_probability(struct Qdisc *sch)
*/
if (qdelay == 0 && qdelay_old == 0 && update_prob)
- q->vars.prob = (q->vars.prob * 98) / 100;
+ q->vars.prob = 98 * div_u64(q->vars.prob, 100);
q->vars.qdelay = qdelay;
q->vars.qlen_old = qlen;
--
2.17.1
^ permalink raw reply related
* Re: [BUG] net/sched : qlen can not really be per cpu ?
From: Eric Dumazet @ 2019-02-27 0:56 UTC (permalink / raw)
To: Cong Wang; +Cc: John Fastabend, Networking, Jamal Hadi Salim, Jiri Pirko
In-Reply-To: <CAM_iQpVuaP9kVyvM-s2MFw+cz1tZpp0ehipo7Gm-W8+=UzxuvQ@mail.gmail.com>
On 02/26/2019 03:51 PM, Cong Wang wrote:
> On Tue, Feb 26, 2019 at 3:19 PM Eric Dumazet <eric.dumazet@gmail.com> wrote:
>>
>>
>>
>> On 02/25/2019 10:42 PM, Eric Dumazet wrote:
>>> HTB + pfifo_fast as a leaf qdisc hits badly the following warning in htb_activate() :
>>>
>>> WARN_ON(cl->level || !cl->leaf.q || !cl->leaf.q->q.qlen);
>>>
>>> This is because pfifo_fast does not update sch->q.qlen, but per cpu counters.
>>> So cl->leaf.q->q.qlen is zero.
>>>
>>> HFSC, CBQ, DRR, QFQ have the same problem.
>>>
>>> Any ideas how we can fix this ?
>>
>> What about something simple for stable ?
>> ( I yet have to boot/test this )
>
> Is merely updating qlen sufficient for fixing it?
>
> I thought it is because of the lack of qdisc_tree_reduce_backlog()
> in pfifo_fast.
It does not seem to be the qdisc_tree_reduce_backlog() thing.
HTB, HFSC, CBQ, DRR, QFQ only peek at their children 'qlen' to decide if there
is at least one packet in them.
The backlog is only reported for dumps, but the actual backlog value is not used in data path.
^ permalink raw reply
* Re: general protection fault in finish_wait
From: Eric Biggers @ 2019-02-27 0:55 UTC (permalink / raw)
To: syzbot; +Cc: davem, kuznet, linux-kernel, netdev, syzkaller-bugs, yoshfuji
In-Reply-To: <0000000000009276d205708f9910@google.com>
On Mon, Jul 09, 2018 at 04:49:02AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 6508b6781be0 tcp: cleanup copied_seq and urg_data in tcp_d..
> git tree: net
> console output: https://syzkaller.appspot.com/x/log.txt?x=1256e6dc400000
> kernel config: https://syzkaller.appspot.com/x/.config?x=2ca6c7a31d407f86
> dashboard link: https://syzkaller.appspot.com/bug?extid=3aac4a52d8e8ca0414d5
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=1310fafc400000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=10af4f48400000
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+3aac4a52d8e8ca0414d5@syzkaller.appspotmail.com
>
> random: sshd: uninitialized urandom read (32 bytes read)
> random: sshd: uninitialized urandom read (32 bytes read)
> kasan: CONFIG_KASAN_INLINE enabled
> kasan: GPF could be caused by NULL-ptr deref or user memory access
> general protection fault: 0000 [#1] SMP KASAN
> CPU: 1 PID: 19 Comm: kworker/1:0 Not tainted 4.18.0-rc3+ #4
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Workqueue: events smc_tcp_listen_work
> RIP: 0010:__lock_acquire+0x245/0x5020 kernel/locking/lockdep.c:3314
> Code: 28 00 00 00 0f 85 03 34 00 00 48 8d 65 d8 5b 41 5c 41 5d 41 5e 41 5f
> 5d c3 48 b8 00 00 00 00 00 fc ff df 4c 89 ea 48 c1 ea 03 <80> 3c 02 00 0f 85
> c6 35 00 00 49 81 7d 00 60 76 e7 89 0f 84 42 ff
> RSP: 0000:ffff8801d9b36d20 EFLAGS: 00010006
> RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
> RDX: 0000000000000003 RSI: 0000000000000000 RDI: ffffffff88f1b060
> RBP: ffff8801d9b370a8 R08: 0000000000000001 R09: 0000000000000001
> R10: ffff8801d9b2a500 R11: 0000000000000001 R12: 0000000000000001
> R13: 0000000000000018 R14: ffff8801d9b2a500 R15: 0000000000000000
> FS: 0000000000000000(0000) GS:ffff8801daf00000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000020002cc0 CR3: 00000001ae03f000 CR4: 00000000001406e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
> lock_acquire+0x1e4/0x540 kernel/locking/lockdep.c:3924
> __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
> _raw_spin_lock_irqsave+0x96/0xc0 kernel/locking/spinlock.c:152
> finish_wait+0x119/0x430 kernel/sched/wait.c:364
> inet_csk_wait_for_connect net/ipv4/inet_connection_sock.c:418 [inline]
> inet_csk_accept+0x6d0/0xe70 net/ipv4/inet_connection_sock.c:451
> inet_accept+0x138/0x9f0 net/ipv4/af_inet.c:734
> kernel_accept+0x136/0x310 net/socket.c:3251
> smc_clcsock_accept net/smc/af_smc.c:701 [inline]
> smc_tcp_listen_work+0x222/0xef0 net/smc/af_smc.c:1114
> process_one_work+0xc73/0x1ba0 kernel/workqueue.c:2153
> worker_thread+0x189/0x13c0 kernel/workqueue.c:2296
> kthread+0x345/0x410 kernel/kthread.c:240
> ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412
> Modules linked in:
> Dumping ftrace buffer:
> (ftrace buffer empty)
> ---[ end trace 472b359041f047a6 ]---
> RIP: 0010:__lock_acquire+0x245/0x5020 kernel/locking/lockdep.c:3314
> Code: 28 00 00 00 0f 85 03 34 00 00 48 8d 65 d8 5b 41 5c 41 5d 41 5e 41 5f
> 5d c3 48 b8 00 00 00 00 00 fc ff df 4c 89 ea 48 c1 ea 03 <80> 3c 02 00 0f 85
> c6 35 00 00 49 81 7d 00 60 76 e7 89 0f 84 42 ff
> RSP: 0000:ffff8801d9b36d20 EFLAGS: 00010006
> RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
> RDX: 0000000000000003 RSI: 0000000000000000 RDI: ffffffff88f1b060
> RBP: ffff8801d9b370a8 R08: 0000000000000001 R09: 0000000000000001
> R10: ffff8801d9b2a500 R11: 0000000000000001 R12: 0000000000000001
> R13: 0000000000000018 R14: ffff8801d9b2a500 R15: 0000000000000000
> FS: 0000000000000000(0000) GS:ffff8801daf00000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000020002cc0 CR3: 00000001ae03f000 CR4: 00000000001406e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
>
>
> ---
> 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
>
> --
> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/0000000000009276d205708f9910%40google.com.
> For more options, visit https://groups.google.com/d/optout.
This was fixed by:
commit 78abe3d0dfad196959b1246003366e2610775ea6 (refs/bisect/new)
Author: Myungho Jung <mhjungk@gmail.com>
Date: Tue Dec 18 09:02:25 2018 -0800
net/smc: fix TCP fallback socket release
#syz fix: net/smc: fix TCP fallback socket release
There are newer crashes with this same signature, e.g.
https://syzkaller.appspot.com/text?tag=CrashReport&x=16cb391f400000
but they are something different...
- Eric
^ permalink raw reply
* Re: [PATCH] bpf: decrease usercnt if bpf_map_new_fd() fails in bpf_map_get_fd_by_id()
From: zerons @ 2019-02-27 0:49 UTC (permalink / raw)
To: Daniel Borkmann, ast; +Cc: netdev, linux-kernel
In-Reply-To: <ba6710b8-a2c9-3557-3a03-14b74ccde5b8@iogearbox.net>
On 2/27/19 00:24, Daniel Borkmann wrote:
> On 02/26/2019 03:58 PM, zerons wrote:
>> On 2/26/19 22:44, Daniel Borkmann wrote:
>>> On 02/26/2019 03:15 PM, zerons wrote:
>>>> [ Upstream commit c91951f15978f1a0c6b65f063d30f7ea7bc6fb42 ]
>>>
>>> Thanks for the fix! What do you mean by "upstream commit" above in this context?
>>
>> This patch is based on that commit, I thought I should mention this.
>> Sorry for the confusion.
>
> Ah, no. Usually that line is placed into stable commits that are
> cherry-picked to point to the original commit sha in the mainline
> tree. In any case, I didn't find c91951f15978, hence my question.
That is v4.20.12.
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v4.20.12&id=c91951f15978f1a0c6b65f063d30f7ea7bc6fb42
> Anyway, for normal patch submissions in future, please don't add
> it into the log, we'll remove it this time.
>
Thanks for reminding me. I won't do that again.
^ permalink raw reply
* Re: [virtio-dev] Re: net_failover slave udev renaming (was Re: [RFC PATCH net-next v6 4/4] netvsc: refactor notifier/event handling code to use the bypass framework)
From: si-wei liu @ 2019-02-27 0:49 UTC (permalink / raw)
To: Michael S. Tsirkin, Stephen Hemminger
Cc: Samudrala, Sridhar, Siwei Liu, Jiri Pirko, David Miller, Netdev,
virtualization, virtio-dev, Brandeburg, Jesse, Alexander Duyck,
Jakub Kicinski, Jason Wang, liran.alon
In-Reply-To: <20190225210428-mutt-send-email-mst@kernel.org>
On 2/25/2019 6:05 PM, Michael S. Tsirkin wrote:
> On Mon, Feb 25, 2019 at 05:39:12PM -0800, Stephen Hemminger wrote:
>>>>>> Moreover, you were suggesting hiding the lower slave devices anyway. There was some discussion
>>>>>> about moving them to a hidden network namespace so that they are not visible from the default namespace.
>>>>>> I looked into this sometime back, but did not find the right kernel api to create a network namespace within
>>>>>> kernel. If so, we could use this mechanism to simulate a 1-netdev model.
>>>>> Yes, that's one possible implementation (IMHO the key is to make 1-netdev
>>>>> model as much transparent to a real NIC as possible, while a hidden netns is
>>>>> just the vehicle). However, I recall there was resistance around this
>>>>> discussion that even the concept of hiding itself is a taboo for Linux
>>>>> netdev. I would like to summon potential alternatives before concluding
>>>>> 1-netdev is the only solution too soon.
>>>>>
>>>>> Thanks,
>>>>> -Siwei
>>>> Your scripts would not work at all then, right?
>>> At this point we don't claim images with such usage as SR-IOV live
>>> migrate-able. We would flag it as live migrate-able until this ethtool
>>> config issue is fully addressed and a transparent live migration
>>> solution emerges in upstream eventually.
>> The hyper-v netvsc with 1-dev model uses a timeout to allow udev to do its rename.
>> I proposed a patch to key state change off of the udev rename, but that patch was
>> rejected.
> Of course that would mean nothing works without udev - was
> that the objection? Could you help me find that discussion pls?
Yeah, the kernel should work with and without udev rename - typically
the kernel is agnostic of upcoming rename. User may opt out for kernel
provided names (particularly on older distros) then no rename would ever
happen.
I ever thought about this approach but didn't think it would fit. But,
what is the historical reason that prevents slave from being renamed
after being opened? Could we specialize a code path for this kernel
created device, as net_failover shouldn't carry over any history burden?
Thanks,
-Siwei
^ permalink raw reply
* Re: BUG: please report to dccp@vger.kernel.org => prev = 5, last = 5 at net/dccp/ccids/lib/packet_history.c:LINE/tfrc_rx_his
From: Eric Biggers @ 2019-02-27 0:44 UTC (permalink / raw)
To: syzbot; +Cc: davem, dccp, garsilva, gerrit, linux-kernel, netdev,
syzkaller-bugs
In-Reply-To: <000000000000627205057803724d@google.com>
On Fri, Oct 12, 2018 at 12:58:02AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 771b65e89c8a Add linux-next specific files for 20181011
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=167d2376400000
> kernel config: https://syzkaller.appspot.com/x/.config?x=45f1c06c4da0a925
> dashboard link: https://syzkaller.appspot.com/bug?extid=e326127852f785c44347
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>
> Unfortunately, I don't have any reproducer for this crash yet.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+e326127852f785c44347@syzkaller.appspotmail.com
>
> BUG: please report to dccp@vger.kernel.org => prev = 5, last = 5 at
> net/dccp/ccids/lib/packet_history.c:425/tfrc_rx_hist_sample_rtt()
> CPU: 1 PID: 16 Comm: ksoftirqd/1 Not tainted 4.19.0-rc7-next-20181011+ #92
> 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+0x244/0x3ab lib/dump_stack.c:113
> tfrc_rx_hist_sample_rtt.cold.3+0x54/0x5c
> net/dccp/ccids/lib/packet_history.c:422
> ccid3_hc_rx_packet_recv+0x5c4/0xeb0 net/dccp/ccids/ccid3.c:767
> ccid_hc_rx_packet_recv net/dccp/ccid.h:185 [inline]
> dccp_deliver_input_to_ccids+0xf0/0x280 net/dccp/input.c:180
> dccp_rcv_established+0x87/0xb0 net/dccp/input.c:378
> dccp_v4_do_rcv+0x153/0x180 net/dccp/ipv4.c:656
> sk_backlog_rcv include/net/sock.h:932 [inline]
> __sk_receive_skb+0x3e0/0xeb0 net/core/sock.c:473
> binder: send failed reply for transaction 41 to 27388:27389
> dccp_v4_rcv+0x10f9/0x1f58 net/dccp/ipv4.c:877
> ip_local_deliver_finish+0x2e9/0xda0 net/ipv4/ip_input.c:215
> NF_HOOK include/linux/netfilter.h:289 [inline]
> ip_local_deliver+0x1e4/0x740 net/ipv4/ip_input.c:256
> dst_input include/net/dst.h:450 [inline]
> ip_rcv_finish+0x1f9/0x300 net/ipv4/ip_input.c:415
> NF_HOOK include/linux/netfilter.h:289 [inline]
> ip_rcv+0xe8/0x600 net/ipv4/ip_input.c:524
> __netif_receive_skb_one_core+0x14d/0x200 net/core/dev.c:4908
> __netif_receive_skb+0x27/0x1e0 net/core/dev.c:5018
> process_backlog+0x24e/0x7a0 net/core/dev.c:5822
> napi_poll net/core/dev.c:6242 [inline]
> net_rx_action+0x7fa/0x19b0 net/core/dev.c:6308
> __do_softirq+0x30d/0xb26 kernel/softirq.c:292
> run_ksoftirqd+0x5e/0x100 kernel/softirq.c:654
> smpboot_thread_fn+0x68b/0xa00 kernel/smpboot.c:164
> kthread+0x35a/0x440 kernel/kthread.c:246
> ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
> dccp_close: ABORT with 52224 bytes unread
> binder: send failed reply for transaction 43 to 27399:27404
> dccp_close: ABORT with 3584 bytes unread
> binder: send failed reply for transaction 45 to 27417:27418
> binder: send failed reply for transaction 47 to 27424:27425
> dccp_close: ABORT with 105984 bytes unread
> dccp_close: ABORT with 105984 bytes unread
> dccp_close: ABORT with 105984 bytes unread
> nf_conntrack: default automatic helper assignment has been turned off for
> security reasons and CT-based firewall rule not found. Use the iptables CT
> target to attach helpers instead.
> Dead loop on virtual device ip6_vti0, fix it urgently!
> Dead loop on virtual device ip6_vti0, fix it urgently!
> Dead loop on virtual device ip6_vti0, fix it urgently!
> Dead loop on virtual device ip6_vti0, fix it urgently!
> Dead loop on virtual device ip6_vti0, fix it urgently!
> Dead loop on virtual device ip6_vti0, fix it urgently!
> IPVS: sync thread started: state = BACKUP, mcast_ifn = team_slave_0, syncid
> = 0, id = 0
> Dead loop on virtual device ip6_vti0, fix it urgently!
> IPVS: sync thread started: state = BACKUP, mcast_ifn = team_slave_0, syncid
> = 0, id = 0
> IPVS: ftp: loaded support on port[0] = 21
> : renamed from bpq0
> IPVS: ftp: loaded support on port[0] = 21
>
>
> ---
> 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.
>
#syz dup: BUG: please report to dccp@vger.kernel.org => prev = 0, last = 0 at net/dccp/ccids/lib/packet_history.c:LINE/tfrc_rx_hist_sample_rtt()
Still occurring, see existing thread with reproducer here:
https://groups.google.com/d/msg/syzkaller-bugs/u5nq3PdPkIc/M7tbibYVCQAJ
- Eric
^ permalink raw reply
* Re: BUG: please report to dccp@vger.kernel.org => prev = 2, last = 2 at net/dccp/ccids/lib/packet_history.c:LINE/tfrc_rx_his
From: Eric Biggers @ 2019-02-27 0:42 UTC (permalink / raw)
To: syzbot; +Cc: davem, dccp, garsilva, gerrit, linux-kernel, netdev,
syzkaller-bugs
In-Reply-To: <0000000000006dc2420578e29de3@google.com>
On Tue, Oct 23, 2018 at 03:13:02AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: ca9eb48fe01f Merge tag 'regulator-v5.0' of git://git.kerne..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1482a939400000
> kernel config: https://syzkaller.appspot.com/x/.config?x=963b24abf3f7c2d8
> dashboard link: https://syzkaller.appspot.com/bug?extid=e786ba000564d103a6fe
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>
> Unfortunately, I don't have any reproducer for this crash yet.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+e786ba000564d103a6fe@syzkaller.appspotmail.com
>
> input: syz0 as /devices/virtual/input/input6
> BUG: please report to dccp@vger.kernel.org => prev = 2, last = 2 at
> net/dccp/ccids/lib/packet_history.c:425/tfrc_rx_hist_sample_rtt()
> CPU: 1 PID: 18 Comm: ksoftirqd/1 Not tainted 4.19.0+ #298
> 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+0x1c4/0x2b6 lib/dump_stack.c:113
> tfrc_rx_hist_sample_rtt.cold.3+0x54/0x5c
> net/dccp/ccids/lib/packet_history.c:422
> ccid3_hc_rx_packet_recv+0x5c4/0xeb0 net/dccp/ccids/ccid3.c:767
> ccid_hc_rx_packet_recv net/dccp/ccid.h:185 [inline]
> dccp_deliver_input_to_ccids+0xf0/0x280 net/dccp/input.c:180
> dccp_rcv_established+0x87/0xb0 net/dccp/input.c:378
> dccp_v4_do_rcv+0x153/0x180 net/dccp/ipv4.c:656
> sk_backlog_rcv include/net/sock.h:931 [inline]
> __sk_receive_skb+0x3e5/0xec0 net/core/sock.c:473
> dccp_v4_rcv+0x10f9/0x1f58 net/dccp/ipv4.c:877
> ip_local_deliver_finish+0x2e9/0xda0 net/ipv4/ip_input.c:215
> NF_HOOK include/linux/netfilter.h:289 [inline]
> ip_local_deliver+0x1e9/0x750 net/ipv4/ip_input.c:256
> dst_input include/net/dst.h:450 [inline]
> ip_rcv_finish+0x1f9/0x300 net/ipv4/ip_input.c:415
> NF_HOOK include/linux/netfilter.h:289 [inline]
> ip_rcv+0xed/0x600 net/ipv4/ip_input.c:524
> __netif_receive_skb_one_core+0x14d/0x200 net/core/dev.c:4913
> __netif_receive_skb+0x2c/0x1e0 net/core/dev.c:5023
> process_backlog+0x218/0x6f0 net/core/dev.c:5829
> napi_poll net/core/dev.c:6249 [inline]
> net_rx_action+0x7c5/0x1950 net/core/dev.c:6315
> __do_softirq+0x30c/0xb03 kernel/softirq.c:292
> run_ksoftirqd+0x94/0x100 kernel/softirq.c:653
> smpboot_thread_fn+0x68b/0xa00 kernel/smpboot.c:164
> kthread+0x35a/0x420 kernel/kthread.c:246
> ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:413
> net_ratelimit: 18 callbacks suppressed
> dccp_close: ABORT with 105978 bytes unread
> input: syz0 as /devices/virtual/input/input7
> input: syz0 as /devices/virtual/input/input8
> dccp_close: ABORT with 52730 bytes unread
> input: syz0 as /devices/virtual/input/input9
> dccp_close: ABORT with 105978 bytes unread
> dccp_close: ABORT with 105978 bytes unread
> dccp_close: ABORT with 77306 bytes unread
> dccp_close: ABORT with 89594 bytes unread
> input: syz0 as /devices/virtual/input/input10
> input: syz0 as /devices/virtual/input/input11
> input: syz0 as /devices/virtual/input/input12
> input: syz0 as /devices/virtual/input/input13
> input: syz0 as /devices/virtual/input/input14
> input: syz0 as /devices/virtual/input/input15
> input: syz0 as /devices/virtual/input/input16
> input: syz0 as /devices/virtual/input/input17
> input: syz0 as /devices/virtual/input/input18
>
>
> ---
> 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.
>
#syz dup: BUG: please report to dccp@vger.kernel.org => prev = 0, last = 0 at net/dccp/ccids/lib/packet_history.c:LINE/tfrc_rx_hist_sample_rtt()
Still occurring, see existing thread with reproducer here:
https://groups.google.com/d/msg/syzkaller-bugs/u5nq3PdPkIc/M7tbibYVCQAJ
- Eric
^ permalink raw reply
* Re: BUG: please report to dccp@vger.kernel.org => prev = 10, last = 10 at net/dccp/ccids/lib/packet_history.c:LINE/tfrc_rx_h
From: Eric Biggers @ 2019-02-27 0:42 UTC (permalink / raw)
To: syzbot; +Cc: davem, dccp, gerrit, linux-kernel, netdev, syzkaller-bugs
In-Reply-To: <0000000000007664bf057d71f6d7@google.com>
On Thu, Dec 20, 2018 at 02:55:03AM -0800, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 6531e115b7ab Merge branch 'akpm' (patches from Andrew)
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=13b0bd5d400000
> kernel config: https://syzkaller.appspot.com/x/.config?x=c8970c89a0efbb23
> dashboard link: https://syzkaller.appspot.com/bug?extid=3c8a843d9de82272915b
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>
> Unfortunately, I don't have any reproducer for this crash yet.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+3c8a843d9de82272915b@syzkaller.appspotmail.com
>
> bond0: enslaved VLAN challenged slave lo. Adding VLANs will be blocked as
> long as lo is part of bond bond0
> bond0: lo is up - this may be due to an out of date ifenslave
> A link change request failed with some changes committed already. Interface
> lo may have been left with an inconsistent configuration, please check.
> BUG: please report to dccp@vger.kernel.org => prev = 10, last = 10 at
> net/dccp/ccids/lib/packet_history.c:425/tfrc_rx_hist_sample_rtt()
> CPU: 0 PID: 9 Comm: ksoftirqd/0 Not tainted 4.20.0-rc6+ #374
> 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+0x244/0x39d lib/dump_stack.c:113
> tfrc_rx_hist_sample_rtt.cold.3+0x54/0x5c
> net/dccp/ccids/lib/packet_history.c:422
> ccid3_hc_rx_packet_recv+0x5c4/0xeb0 net/dccp/ccids/ccid3.c:767
> ccid_hc_rx_packet_recv net/dccp/ccid.h:185 [inline]
> dccp_deliver_input_to_ccids+0xf0/0x280 net/dccp/input.c:180
> dccp_rcv_established+0x87/0xb0 net/dccp/input.c:378
> dccp_v4_do_rcv+0x153/0x180 net/dccp/ipv4.c:656
> sk_backlog_rcv include/net/sock.h:932 [inline]
> __sk_receive_skb+0x3e5/0xec0 net/core/sock.c:473
> dccp_v4_rcv+0x10f9/0x1f58 net/dccp/ipv4.c:877
> ip_local_deliver_finish+0x2e9/0xda0 net/ipv4/ip_input.c:215
> NF_HOOK include/linux/netfilter.h:289 [inline]
> ip_local_deliver+0x1e9/0x750 net/ipv4/ip_input.c:256
> dst_input include/net/dst.h:450 [inline]
> ip_rcv_finish+0x1f9/0x300 net/ipv4/ip_input.c:415
> NF_HOOK include/linux/netfilter.h:289 [inline]
> ip_rcv+0xed/0x600 net/ipv4/ip_input.c:524
> __netif_receive_skb_one_core+0x14d/0x200 net/core/dev.c:4946
> __netif_receive_skb+0x2c/0x1e0 net/core/dev.c:5056
> process_backlog+0x24e/0x7a0 net/core/dev.c:5864
> napi_poll net/core/dev.c:6287 [inline]
> net_rx_action+0x7fa/0x19b0 net/core/dev.c:6353
> __do_softirq+0x308/0xb7e kernel/softirq.c:292
> run_ksoftirqd+0x5e/0x100 kernel/softirq.c:654
> smpboot_thread_fn+0x68b/0xa00 kernel/smpboot.c:164
> kthread+0x35a/0x440 kernel/kthread.c:246
> ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
> IPv6: ADDRCONF(NETDEV_CHANGE): vcan0: link becomes ready
> IPVS: ftp: loaded support on port[0] = 21
> dccp_close: ABORT with 36864 bytes unread
> bond0: enslaved VLAN challenged slave lo. Adding VLANs will be blocked as
> long as lo is part of bond bond0
> bond0: lo is up - this may be due to an out of date ifenslave
> A link change request failed with some changes committed already. Interface
> lo may have been left with an inconsistent configuration, please check.
> IPv6: ADDRCONF(NETDEV_CHANGE): vcan0: link becomes ready
> IPv6: ADDRCONF(NETDEV_CHANGE): vcan0: link becomes ready
> bond0: enslaved VLAN challenged slave lo. Adding VLANs will be blocked as
> long as lo is part of bond bond0
> bond0: lo is up - this may be due to an out of date ifenslave
> A link change request failed with some changes committed already. Interface
> lo may have been left with an inconsistent configuration, please check.
> IPVS: ftp: loaded support on port[0] = 21
> bond0: enslaved VLAN challenged slave lo. Adding VLANs will be blocked as
> long as lo is part of bond bond0
> bond0: lo is up - this may be due to an out of date ifenslave
> A link change request failed with some changes committed already. Interface
> lo may have been left with an inconsistent configuration, please check.
> IPv6: ADDRCONF(NETDEV_CHANGE): vcan0: link becomes ready
> IPVS: ftp: loaded support on port[0] = 21
> IPv6: ADDRCONF(NETDEV_CHANGE): vcan0: link becomes ready
> bond0: enslaved VLAN challenged slave lo. Adding VLANs will be blocked as
> long as lo is part of bond bond0
> bond0: lo is up - this may be due to an out of date ifenslave
> A link change request failed with some changes committed already. Interface
> lo may have been left with an inconsistent configuration, please check.
> IPv6: ADDRCONF(NETDEV_CHANGE): vcan0: link becomes ready
> bond0: enslaved VLAN challenged slave lo. Adding VLANs will be blocked as
> long as lo is part of bond bond0
> bond0: lo is up - this may be due to an out of date ifenslave
> IPVS: ftp: loaded support on port[0] = 21
> A link change request failed with some changes committed already. Interface
> lo may have been left with an inconsistent configuration, please check.
> IPv6: ADDRCONF(NETDEV_CHANGE): vcan0: link becomes ready
> bond0: enslaved VLAN challenged slave lo. Adding VLANs will be blocked as
> long as lo is part of bond bond0
> bond0: lo is up - this may be due to an out of date ifenslave
> A link change request failed with some changes committed already. Interface
> lo may have been left with an inconsistent configuration, please check.
> IPVS: ftp: loaded support on port[0] = 21
> IPv6: ADDRCONF(NETDEV_CHANGE): vcan0: link becomes ready
> bond0: enslaved VLAN challenged slave lo. Adding VLANs will be blocked as
> long as lo is part of bond bond0
> bond0: lo is up - this may be due to an out of date ifenslave
> IPVS: ftp: loaded support on port[0] = 21
> A link change request failed with some changes committed already. Interface
> lo may have been left with an inconsistent configuration, please check.
> IPv6: ADDRCONF(NETDEV_CHANGE): vcan0: link becomes ready
> IPVS: ftp: loaded support on port[0] = 21
> IPv6: ADDRCONF(NETDEV_CHANGE): vcan0: link becomes ready
> bond0: enslaved VLAN challenged slave lo. Adding VLANs will be blocked as
> long as lo is part of bond bond0
> bond0: lo is up - this may be due to an out of date ifenslave
> IPVS: ftp: loaded support on port[0] = 21
> A link change request failed with some changes committed already. Interface
> lo may have been left with an inconsistent configuration, please check.
> IPv6: ADDRCONF(NETDEV_CHANGE): vcan0: link becomes ready
> IPVS: ftp: loaded support on port[0] = 21
> IPv6: ADDRCONF(NETDEV_CHANGE): vcan0: link becomes ready
> bond0: enslaved VLAN challenged slave lo. Adding VLANs will be blocked as
> long as lo is part of bond bond0
> bond0: lo is up - this may be due to an out of date ifenslave
> A link change request failed with some changes committed already. Interface
> lo may have been left with an inconsistent configuration, please check.
> IPVS: ftp: loaded support on port[0] = 21
> IPv6: ADDRCONF(NETDEV_CHANGE): vcan0: link becomes ready
> bond0: enslaved VLAN challenged slave lo. Adding VLANs will be blocked as
> long as lo is part of bond bond0
> bond0: lo is up - this may be due to an out of date ifenslave
> A link change request failed with some changes committed already. Interface
> lo may have been left with an inconsistent configuration, please check.
> IPv6: ADDRCONF(NETDEV_CHANGE): vcan0: link becomes ready
> IPv6: ADDRCONF(NETDEV_CHANGE): vcan0: link becomes ready
> bond0: enslaved VLAN challenged slave lo. Adding VLANs will be blocked as
> long as lo is part of bond bond0
> bond0: lo is up - this may be due to an out of date ifenslave
> A link change request failed with some changes committed already. Interface
> lo may have been left with an inconsistent configuration, please check.
>
>
> ---
> 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.
>
> --
> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/0000000000007664bf057d71f6d7%40google.com.
> For more options, visit https://groups.google.com/d/optout.
#syz dup: BUG: please report to dccp@vger.kernel.org => prev = 0, last = 0 at net/dccp/ccids/lib/packet_history.c:LINE/tfrc_rx_hist_sample_rtt()
Still occurring, see existing thread with reproducer here:
https://groups.google.com/d/msg/syzkaller-bugs/u5nq3PdPkIc/M7tbibYVCQAJ
- Eric
^ permalink raw reply
* linux-next: manual merge of the net-next tree with the rdma tree
From: Stephen Rothwell @ 2019-02-27 0:25 UTC (permalink / raw)
To: David Miller, Networking, Doug Ledford, Jason Gunthorpe
Cc: Linux Next Mailing List, Linux Kernel Mailing List,
Shamir Rabinovitch, Jakub Kicinski
[-- Attachment #1: Type: text/plain, Size: 1256 bytes --]
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
drivers/infiniband/hw/mlx4/Kconfig
between commit:
6fa8f1afd337 ("IB/{core,uverbs}: Move ib_umem_xxx functions from ib_core to ib_uverbs")
from the rdma tree and commit:
f4b6bcc7002f ("net: devlink: turn devlink into a built-in")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/infiniband/hw/mlx4/Kconfig
index db4aa13ebae0,4e9936731867..000000000000
--- a/drivers/infiniband/hw/mlx4/Kconfig
+++ b/drivers/infiniband/hw/mlx4/Kconfig
@@@ -1,7 -1,7 +1,6 @@@
config MLX4_INFINIBAND
tristate "Mellanox ConnectX HCA support"
depends on NETDEVICES && ETHERNET && PCI && INET
- depends on MAY_USE_DEVLINK
- depends on INFINIBAND_USER_ACCESS || !INFINIBAND_USER_ACCESS
select NET_VENDOR_MELLANOX
select MLX4_CORE
---help---
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [virtio-dev] Re: net_failover slave udev renaming (was Re: [RFC PATCH net-next v6 4/4] netvsc: refactor notifier/event handling code to use the bypass framework)
From: si-wei liu @ 2019-02-27 0:17 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Samudrala, Sridhar, Siwei Liu, Jiri Pirko, Stephen Hemminger,
David Miller, Netdev, virtualization, virtio-dev,
Brandeburg, Jesse, Alexander Duyck, Jakub Kicinski, Jason Wang,
liran.alon
In-Reply-To: <20190225210529-mutt-send-email-mst@kernel.org>
On 2/25/2019 6:08 PM, Michael S. Tsirkin wrote:
> On Mon, Feb 25, 2019 at 04:58:07PM -0800, si-wei liu wrote:
>>
>> On 2/22/2019 7:14 AM, Michael S. Tsirkin wrote:
>>> On Thu, Feb 21, 2019 at 11:55:11PM -0800, si-wei liu wrote:
>>>> On 2/21/2019 11:00 PM, Samudrala, Sridhar wrote:
>>>>> On 2/21/2019 7:33 PM, si-wei liu wrote:
>>>>>> On 2/21/2019 5:39 PM, Michael S. Tsirkin wrote:
>>>>>>> On Thu, Feb 21, 2019 at 05:14:44PM -0800, Siwei Liu wrote:
>>>>>>>> Sorry for replying to this ancient thread. There was some remaining
>>>>>>>> issue that I don't think the initial net_failover patch got addressed
>>>>>>>> cleanly, see:
>>>>>>>>
>>>>>>>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1815268
>>>>>>>>
>>>>>>>> The renaming of 'eth0' to 'ens4' fails because the udev userspace was
>>>>>>>> not specifically writtten for such kernel automatic enslavement.
>>>>>>>> Specifically, if it is a bond or team, the slave would typically get
>>>>>>>> renamed *before* virtual device gets created, that's what udev can
>>>>>>>> control (without getting netdev opened early by the other part of
>>>>>>>> kernel) and other userspace components for e.g. initramfs,
>>>>>>>> init-scripts can coordinate well in between. The in-kernel
>>>>>>>> auto-enslavement of net_failover breaks this userspace convention,
>>>>>>>> which don't provides a solution if user care about consistent naming
>>>>>>>> on the slave netdevs specifically.
>>>>>>>>
>>>>>>>> Previously this issue had been specifically called out when IFF_HIDDEN
>>>>>>>> and the 1-netdev was proposed, but no one gives out a solution to this
>>>>>>>> problem ever since. Please share your mind how to proceed and solve
>>>>>>>> this userspace issue if netdev does not welcome a 1-netdev model.
>>>>>>> Above says:
>>>>>>>
>>>>>>> there's no motivation in the systemd/udevd community at
>>>>>>> this point to refactor the rename logic and make it work well with
>>>>>>> 3-netdev.
>>>>>>>
>>>>>>> What would the fix be? Skip slave devices?
>>>>>>>
>>>>>> There's nothing user can get if just skipping slave devices - the
>>>>>> name is still unchanged and unpredictable e.g. eth0, or eth1 the
>>>>>> next reboot, while the rest may conform to the naming scheme (ens3
>>>>>> and such). There's no way one can fix this in userspace alone - when
>>>>>> the failover is created the enslaved netdev was opened by the kernel
>>>>>> earlier than the userspace is made aware of, and there's no
>>>>>> negotiation protocol for kernel to know when userspace has done
>>>>>> initial renaming of the interface. I would expect netdev list should
>>>>>> at least provide the direction in general for how this can be
>>>>>> solved...
>>> I was just wondering what did you mean when you said
>>> "refactor the rename logic and make it work well with 3-netdev" -
>>> was there a proposal udev rejected?
>> No. I never believed this particular issue can be fixed in userspace alone.
>> Previously someone had said it could be, but I never see any work or
>> relevant discussion ever happened in various userspace communities (for e.g.
>> dracut, initramfs-tools, systemd, udev, and NetworkManager). IMHO the root
>> of the issue derives from the kernel, it makes more sense to start from
>> netdev, work out and decide on a solution: see what can be done in the
>> kernel in order to fix it, then after that engage userspace community for
>> the feasibility...
>>
>>> Anyway, can we write a time diagram for what happens in which order that
>>> leads to failure? That would help look for triggers that we can tie
>>> into, or add new ones.
>>>
>> See attached diagram.
>>
>>>
>>>
>>>
>>>>> Is there an issue if slave device names are not predictable? The user/admin scripts are expected
>>>>> to only work with the master failover device.
>>>> Where does this expectation come from?
>>>>
>>>> Admin users may have ethtool or tc configurations that need to deal with
>>>> predictable interface name. Third-party app which was built upon specifying
>>>> certain interface name can't be modified to chase dynamic names.
>>>>
>>>> Specifically, we have pre-canned image that uses ethtool to fine tune VF
>>>> offload settings post boot for specific workload. Those images won't work
>>>> well if the name is constantly changing just after couple rounds of live
>>>> migration.
>>> It should be possible to specify the ethtool configuration on the
>>> master and have it automatically propagated to the slave.
>>>
>>> BTW this is something we should look at IMHO.
>> I was elaborating a few examples that the expectation and assumption that
>> user/admin scripts only deal with master failover device is incorrect. It
>> had never been taken good care of, although I did try to emphasize it from
>> the very beginning.
>>
>> Basically what you said about propagating the ethtool configuration down to
>> the slave is the key pursuance of 1-netdev model. However, what I am seeking
>> now is any alternative that can also fix the specific udev rename problem,
>> before concluding that 1-netdev is the only solution. Generally a 1-netdev
>> scheme would take time to implement, while I'm trying to find a way out to
>> fix this particular naming problem under 3-netdev.
>>
>>>>> Moreover, you were suggesting hiding the lower slave devices anyway. There was some discussion
>>>>> about moving them to a hidden network namespace so that they are not visible from the default namespace.
>>>>> I looked into this sometime back, but did not find the right kernel api to create a network namespace within
>>>>> kernel. If so, we could use this mechanism to simulate a 1-netdev model.
>>>> Yes, that's one possible implementation (IMHO the key is to make 1-netdev
>>>> model as much transparent to a real NIC as possible, while a hidden netns is
>>>> just the vehicle). However, I recall there was resistance around this
>>>> discussion that even the concept of hiding itself is a taboo for Linux
>>>> netdev. I would like to summon potential alternatives before concluding
>>>> 1-netdev is the only solution too soon.
>>>>
>>>> Thanks,
>>>> -Siwei
>>> Your scripts would not work at all then, right?
>> At this point we don't claim images with such usage as SR-IOV live
>> migrate-able. We would flag it as live migrate-able until this ethtool
>> config issue is fully addressed and a transparent live migration solution
>> emerges in upstream eventually.
>>
>>
>> Thanks,
>> -Siwei
>>>
>>>>>> -Siwei
>>>>>>
>>>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
>>> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
>>>
>> net_failover(kernel) | network.service (user) | systemd-udevd (user)
>> --------------------------------------------------+------------------------------+--------------------------------------------
>> (standby virtio-net and net_failover | |
>> devices created and initialized, | |
>> i.e. virtnet_probe()-> | |
>> net_failover_create() | |
>> was done.) | |
>> | |
>> | runs `ifup ens3' -> |
>> | ip link set dev ens3 up |
>> net_failover_open() | |
>> dev_open(virtnet_dev) | |
>> virtnet_open(virtnet_dev) | |
>> netif_carrier_on(failover_dev) | |
>> ... | |
>> | |
>> (VF hot plugged in) | |
>> ixgbevf_probe() | |
>> register_netdev(ixgbevf_netdev) | |
>> netdev_register_kobject(ixgbevf_netdev) | |
>> kobject_add(ixgbevf_dev) | |
>> device_add(ixgbevf_dev) | |
>> kobject_uevent(&ixgbevf_dev->kobj, KOBJ_ADD) | |
>> netlink_broadcast() | |
>> ... | |
>> call_netdevice_notifiers(NETDEV_REGISTER) | |
>> failover_event(..., NETDEV_REGISTER, ...) | |
>> failover_slave_register(ixgbevf_netdev) | |
>> net_failover_slave_register(ixgbevf_netdev) | |
>> dev_open(ixgbevf_netdev) | |
>> | |
>> | |
>> | | received ADD uevent from netlink fd
>> | | ...
>> | | udev-builtin-net_id.c:dev_pci_slot()
>> | | (decided to renamed 'eth0' )
>> | | ip link set dev eth0 name ens4
>> (dev_change_name() returns -EBUSY as | |
>> ixgbevf_netdev->flags has IFF_UP) | |
>> | |
>>
> Given renaming slaves does not work anyway:
I was actually thinking what if we relieve the rename restriction just
for the failover slave? What the impact would be? I think users don't
care about slave being renamed when it's in use, especially the initial
rename. Thoughts?
> would it work if we just
> hard-coded slave names instead?
>
> E.g.
> 1. fail slave renames
> 2. rename of failover to XX automatically renames standby to XXnsby
> and primary to XXnpry
That wouldn't help. The time when the failover master gets renamed, the
VF may not be present. I don't like the idea to delay exposing failover
master until VF is hot plugged in (probably subject to various failures)
later.
Thanks,
-Siwei
>
>
^ permalink raw reply
* Zdravstvujte Vas interesuyut bazy dannyh dlya prodazhi Vashih tovarov i uslug?
From: netdev @ 2019-02-26 4:48 UTC (permalink / raw)
To: netdev
Zdravstvujte Vas interesuyut bazy dannyh dlya prodazhi Vashih tovarov i uslug?
^ permalink raw reply
* Re: [RFC] nasty corner case in unix_dgram_sendmsg()
From: Al Viro @ 2019-02-26 23:59 UTC (permalink / raw)
To: Jason Baron; +Cc: Rainer Weikusat, netdev
In-Reply-To: <552b3d67-2f43-5831-e4ea-666827de54fe@akamai.com>
On Tue, Feb 26, 2019 at 03:35:39PM -0500, Jason Baron wrote:
> > I understand what the unix_dgram_peer_wake_me() is doing; I understand
> > what unix_dgram_poll() is using it for. What I do not understand is
> > what's the point of doing that in unix_dgram_sendmsg()...
> >
>
> Hi,
>
> So the unix_dgram_peer_wake_me() in unix_dgram_sendmsg() is there for
> epoll in edge-triggered mode. In that case, we want to ensure that if
> -EAGAIN is returned a subsequent epoll_wait() is not stuck indefinitely.
> Probably could use a comment...
*owwww*
Let me see if I've got it straight - you want the forwarding rearmed,
so that it would match the behaviour of ep_poll_callback() (i.e.
removing only when POLLFREE is passed)? Looks like an odd way to
do it, if that's what's happening...
While we are at it, why disarm a forwarder upon noticing that peer
is dead? Wouldn't it be simpler to move that
wake_up_interruptible_all(&u->peer_wait);
in unix_release_sock() to just before
unix_state_unlock(sk);
a line prior? Then anyone seeing SOCK_DEAD on (locked) peer
would be guaranteed that all forwarders are gone...
Another fun question about the same dgram sendmsg:
if (unix_peer(sk) == other) {
unix_peer(sk) = NULL;
unix_dgram_peer_wake_disconnect_wakeup(sk, other);
unix_state_unlock(sk);
unix_dgram_disconnected(sk, other);
... and we are holding any locks at the last line. What happens
if we have thread A doing
decide which address to talk to
connect(fd, that address)
send request over fd (with send(2) or write(2))
read reply from fd (recv(2) or read(2))
in a loop, with thread B doing explicit sendto(2) over the same
socket?
Suppose B happens to send to the last server thread A was talking
to and finds it just closed (e.g. because the last request from
A had been "shut down", which server has honoured). B gets ECONNREFUSED,
as it ought to, but it can also ends up disrupting the next exchange
of A.
Shouldn't we rather extract the skbs from that queue *before*
dropping sk->lock? E.g. move them to a temporary queue, and flush
that queue after we'd unlocked sk...
^ permalink raw reply
* Re: [BUG] net/sched : qlen can not really be per cpu ?
From: Cong Wang @ 2019-02-26 23:51 UTC (permalink / raw)
To: Eric Dumazet; +Cc: John Fastabend, Networking, Jamal Hadi Salim, Jiri Pirko
In-Reply-To: <b9f45c9e-8e4e-36d6-8de1-15a759346344@gmail.com>
On Tue, Feb 26, 2019 at 3:19 PM Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>
>
> On 02/25/2019 10:42 PM, Eric Dumazet wrote:
> > HTB + pfifo_fast as a leaf qdisc hits badly the following warning in htb_activate() :
> >
> > WARN_ON(cl->level || !cl->leaf.q || !cl->leaf.q->q.qlen);
> >
> > This is because pfifo_fast does not update sch->q.qlen, but per cpu counters.
> > So cl->leaf.q->q.qlen is zero.
> >
> > HFSC, CBQ, DRR, QFQ have the same problem.
> >
> > Any ideas how we can fix this ?
>
> What about something simple for stable ?
> ( I yet have to boot/test this )
Is merely updating qlen sufficient for fixing it?
I thought it is because of the lack of qdisc_tree_reduce_backlog()
in pfifo_fast.
^ permalink raw reply
* Re: [PATCH 0/4] mwifiex PCI/wake-up interrupt fixes
From: Brian Norris @ 2019-02-26 23:44 UTC (permalink / raw)
To: Marc Zyngier
Cc: Ard Biesheuvel, Amitkumar Karwar, Enric Balletbo i Serra,
Ganapathi Bhat, Heiko Stuebner, Kalle Valo, Nishant Sarmukadam,
Rob Herring, Xinming Hu, Devicetree List,
<netdev@vger.kernel.org>,
<linux-wireless@vger.kernel.org>, Linux Kernel Mailing List,
linux-rockchip, David S. Miller, linux-arm-kernel, linux-pci,
linux-pm, Jeffy Chen
In-Reply-To: <0c433a70-27f6-76ad-c46c-6015de1ffaa4@arm.com>
Hi,
On Tue, Feb 26, 2019 at 05:14:00PM +0000, Marc Zyngier wrote:
> On 26/02/2019 16:21, Ard Biesheuvel wrote:
> > On Mon, 25 Feb 2019 at 15:53, Marc Zyngier <marc.zyngier@arm.com> wrote:
> >> It outlines one thing: If you have to interpret per-device PCI
> >> properties from DT, you're in for serious trouble. I should get some
> >> better HW.
> >>
> >
> > Yeah, it obviously makes no sense at all for the interrupt parent of a
> > PCI device to deviate from the host bridge's interrupt parent, and
> > it's quite unfortunate that we can't simply ban it now that the cat is
> > out of the bag already.
> >
> > Arguably, the wake up widget is not part of the PCI device, but I have
> > no opinion as to whether it is better modeling it as a sub device as
> > you are proposing or as an entirely separate device referenced via a
> > phandle.
>
> It is not that clear. The widget seems to be an integral part of the
> device, as it is the same basic IP that is used for SDIO and USB.
It's not really a widget specific to this IP. It's just a GPIO. It so
happens that both SDIO and PCIe designs have wanted to use a GPIO for
wakeup, as many other devices do. (Note: it's not just cheap ARM
devices; pulling up some Intel Chromebook designs, I see the exact same
WAKE# GPIO on their PCIe WiFi as well.)
> It looks like the good old pre-PCI-2.2 days, where you had to have a
> separate cable between your network card and the base-board for the
> wake-up interrupt to be delivered. Starting with PCI-2.2, the bus can
> carry the signal just fine. With PCIe, it should just be an interrupt
> TLP sent to the RC, but that's obviously not within the capabilities of
> the HW.
You should search the PCI Express specification for WAKE#. There is a
clearly-documented "side-band wake" feature that is part of the
standard, as an alternative to in-band TLP wakeup. While you claim this
is an ancient thing, it in fact still in use on many systems -- it's
just usually abstracted better by ACPI firmware, whereas the dirty
laundry is aired a bit more on a Device Tree system. And we got it
wrong.
> Anyway, it'd be good if the Marvell people could chime in and let us
> know how they'd prefer to handle this.
I'm not sure this is really a Marvell-specific problem. (Well, except
for the marvell,wakeup-pin silliness, which is somewhat orthogonal.) In
fact, if we cared a little more about Wake-on-WiFi, we'd be trying to
support the same (out-of-band WAKE#) with other WiFi drivers.
Brian
^ permalink raw reply
* Re: [PATCH 0/3] soc: fsl: dpio: enable and configure cache stashing
From: Li Yang @ 2019-02-26 23:42 UTC (permalink / raw)
To: Ioana Ciornei
Cc: Roy Pledge, Ioana Ciocoi Radulescu, Laurentiu Tudor, Horia Geanta,
brouer@redhat.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20190223084816.28985-1-ioana.ciornei@nxp.com>
On Sat, Feb 23, 2019 at 2:49 AM Ioana Ciornei <ioana.ciornei@nxp.com> wrote:
>
> The first two patches enable cache stashing and configure the core cluster
> destination per software portal while the third patch is the one
> configuring the amount of stashing on a queue.
Series applied for next. Thanks.
Regards,
Leo
>
> Ioana Ciornei (3):
> soc: fsl: dpio: enable frame data cache stashing per software portal
> soc: fsl: dpio: configure cache stashing destination
> dpaa2-eth: configure the cache stashing amount on a queue
>
> drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c | 7 +++-
> drivers/soc/fsl/Kconfig | 1 +
> drivers/soc/fsl/dpio/dpio-cmd.h | 5 +++
> drivers/soc/fsl/dpio/dpio-driver.c | 52 ++++++++++++++++++++++++
> drivers/soc/fsl/dpio/dpio.c | 16 ++++++++
> drivers/soc/fsl/dpio/dpio.h | 5 +++
> drivers/soc/fsl/dpio/qbman-portal.c | 4 +-
> 7 files changed, 87 insertions(+), 3 deletions(-)
>
> --
> 1.9.1
>
^ permalink raw reply
* [PATCH net-next 3/3] net: dsa: microchip: add other KSZ9477 switch variants
From: Tristram.Ha @ 2019-02-26 23:37 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, Pavel Machek
Cc: Tristram Ha, UNGLinuxDriver, netdev
In-Reply-To: <1551224265-9304-1-git-send-email-Tristram.Ha@microchip.com>
From: Tristram Ha <Tristram.Ha@microchip.com>
Add other switches in KSZ9477 family.
KSZ9896 is a switch with 6 ports; the last one is typically used to
connect to MAC.
KSZ9567 is same as KSZ9897 but with 1588 PTP capability.
KSZ8567 is same as KSZ9567 but without gigabit capability.
KSZ9563 is same as KSZ9893 but with 1588 PTP capability.
KSZ8563 is same as KSZ9563 but without gigabit capability.
KSZ8565 is a switch with 5 ports; however, port 7 has to be used to
connect to MAC. This chip can only be set through device tree.
Signed-off-by: Tristram Ha <Tristram.Ha@microchip.com>
---
drivers/net/dsa/microchip/ksz9477.c | 93 ++++++++++++++++++++++++++++++++-
drivers/net/dsa/microchip/ksz9477_spi.c | 3 ++
drivers/net/dsa/microchip/ksz_common.c | 4 ++
3 files changed, 98 insertions(+), 2 deletions(-)
diff --git a/drivers/net/dsa/microchip/ksz9477.c b/drivers/net/dsa/microchip/ksz9477.c
index 3bb548a..81e7c2f 100644
--- a/drivers/net/dsa/microchip/ksz9477.c
+++ b/drivers/net/dsa/microchip/ksz9477.c
@@ -1264,6 +1264,32 @@ static void ksz9477_port_setup(struct ksz_device *dev, int port, bool cpu_port)
ksz_pread16(dev, port, REG_PORT_PHY_INT_ENABLE, &data16);
}
+#define KSZ_CHIP_NAME_SIZE 18
+
+static char *ksz9477_chip_names[KSZ_CHIP_NAME_SIZE] = {
+ "Microchip KSZ9477",
+ "Microchip KSZ9897",
+ "Microchip KSZ9896",
+ "Microchip KSZ9567",
+ "Microchip KSZ8567",
+ "Microchip KSZ8565",
+ "Microchip KSZ9893",
+ "Microchip KSZ9563",
+ "Microchip KSZ8563",
+};
+
+enum {
+ KSZ9477_SW_CHIP,
+ KSZ9897_SW_CHIP,
+ KSZ9896_SW_CHIP,
+ KSZ9567_SW_CHIP,
+ KSZ8567_SW_CHIP,
+ KSZ8565_SW_CHIP,
+ KSZ9893_SW_CHIP,
+ KSZ9563_SW_CHIP,
+ KSZ8563_SW_CHIP,
+};
+
static void ksz9477_config_cpu_port(struct dsa_switch *ds)
{
struct ksz_device *dev = ds->priv;
@@ -1314,7 +1340,8 @@ static void ksz9477_config_cpu_port(struct dsa_switch *ds)
p->vid_member = (1 << i);
p->member = dev->port_mask;
ksz9477_port_stp_state_set(ds, i, BR_STATE_DISABLED);
- p->on = 1;
+ if (!dsa_is_unused_port(ds, i))
+ p->on = 1;
if (i < dev->phy_port_cnt)
p->phy = 1;
if (dev->chip_id == 0x00947700 && i == 6) {
@@ -1406,6 +1433,7 @@ static u32 ksz9477_get_port_addr(int port, int offset)
static int ksz9477_switch_detect(struct ksz_device *dev)
{
+ int chip = -1;
u8 data8;
u8 id_hi;
u8 id_lo;
@@ -1448,6 +1476,12 @@ static int ksz9477_switch_detect(struct ksz_device *dev)
dev->features &= ~GBIT_SUPPORT;
dev->mib_port_cnt = 3;
dev->phy_port_cnt = 2;
+ if (!(data8 & SW_AVB_ABLE))
+ chip = KSZ9893_SW_CHIP;
+ else if (data8 & SW_QW_ABLE)
+ chip = KSZ8563_SW_CHIP;
+ else
+ chip = KSZ9563_SW_CHIP;
} else {
/* Chip uses new XMII register definitions. */
dev->features |= NEW_XMII;
@@ -1455,6 +1489,37 @@ static int ksz9477_switch_detect(struct ksz_device *dev)
/* Chip does not support gigabit. */
if (!(data8 & SW_GIGABIT_ABLE))
dev->features &= ~GBIT_SUPPORT;
+ if ((id_lo & 0xf) == 6)
+ dev->mib_port_cnt = 6;
+ if (id_hi == FAMILY_ID_94)
+ chip = KSZ9477_SW_CHIP;
+ else if (id_hi == FAMILY_ID_98 && id_lo == CHIP_ID_97)
+ chip = KSZ9897_SW_CHIP;
+ else if (id_hi == FAMILY_ID_98 && id_lo == CHIP_ID_96)
+ chip = KSZ9896_SW_CHIP;
+ else if (id_hi == FAMILY_ID_95 && id_lo == CHIP_ID_67)
+ chip = KSZ9567_SW_CHIP;
+ else if (id_hi == FAMILY_ID_85 && id_lo == CHIP_ID_67)
+ chip = KSZ8567_SW_CHIP;
+ if (id_lo == CHIP_ID_67) {
+ id_hi = FAMILY_ID_98;
+ id_lo = CHIP_ID_97;
+ } else if (id_lo == CHIP_ID_66) {
+ id_hi = FAMILY_ID_98;
+ id_lo = CHIP_ID_96;
+ }
+ }
+ if (dev->dev->of_node) {
+ char name[80];
+
+ /* KSZ8565 chip can only be set through device tree. */
+ if (!of_modalias_node(dev->dev->of_node, name, sizeof(name))) {
+ if (!strcmp(name, "ksz8565")) {
+ chip = KSZ8565_SW_CHIP;
+ id_hi = FAMILY_ID_98;
+ id_lo = 0x95;
+ }
+ }
}
/* Change chip id to known ones so it can be matched against them. */
@@ -1462,6 +1527,10 @@ static int ksz9477_switch_detect(struct ksz_device *dev)
dev->chip_id = id32;
+ /* Update switch device name to matched chip. */
+ if (chip >= 0)
+ dev->name = ksz9477_chip_names[chip];
+
return 0;
}
@@ -1495,6 +1564,15 @@ struct ksz_chip_data {
.port_cnt = 7, /* total physical port count */
},
{
+ .chip_id = 0x00989600,
+ .dev_name = "KSZ9896",
+ .num_vlans = 4096,
+ .num_alus = 4096,
+ .num_statics = 16,
+ .cpu_ports = 0x3F, /* can be configured as cpu port */
+ .port_cnt = 6, /* total port count */
+ },
+ {
.chip_id = 0x00989300,
.dev_name = "KSZ9893",
.num_vlans = 4096,
@@ -1503,6 +1581,15 @@ struct ksz_chip_data {
.cpu_ports = 0x07, /* can be configured as cpu port */
.port_cnt = 3, /* total port count */
},
+ {
+ .chip_id = 0x00989500,
+ .dev_name = "KSZ8565",
+ .num_vlans = 4096,
+ .num_alus = 4096,
+ .num_statics = 16,
+ .cpu_ports = 0x4F, /* can be configured as cpu port */
+ .port_cnt = 7, /* total port count */
+ },
};
static int ksz9477_switch_init(struct ksz_device *dev)
@@ -1515,7 +1602,8 @@ static int ksz9477_switch_init(struct ksz_device *dev)
const struct ksz_chip_data *chip = &ksz9477_switch_chips[i];
if (dev->chip_id == chip->chip_id) {
- dev->name = chip->dev_name;
+ if (!dev->name)
+ dev->name = chip->dev_name;
dev->num_vlans = chip->num_vlans;
dev->num_alus = chip->num_alus;
dev->num_statics = chip->num_statics;
@@ -1531,6 +1619,7 @@ static int ksz9477_switch_init(struct ksz_device *dev)
return -ENODEV;
dev->port_mask = (1 << dev->port_cnt) - 1;
+ dev->port_mask &= dev->cpu_ports;
dev->reg_mib_cnt = SWITCH_COUNTER_NUM;
dev->mib_cnt = TOTAL_SWITCH_COUNTER_NUM;
diff --git a/drivers/net/dsa/microchip/ksz9477_spi.c b/drivers/net/dsa/microchip/ksz9477_spi.c
index 7517862..878dd64 100644
--- a/drivers/net/dsa/microchip/ksz9477_spi.c
+++ b/drivers/net/dsa/microchip/ksz9477_spi.c
@@ -155,6 +155,9 @@ static void ksz9477_spi_shutdown(struct spi_device *spi)
static const struct of_device_id ksz9477_dt_ids[] = {
{ .compatible = "microchip,ksz9477" },
{ .compatible = "microchip,ksz9897" },
+ { .compatible = "microchip,ksz9896" },
+ { .compatible = "microchip,ksz9567" },
+ { .compatible = "microchip,ksz8565" },
{ .compatible = "microchip,ksz9893" },
{ .compatible = "microchip,ksz9563" },
{},
diff --git a/drivers/net/dsa/microchip/ksz_common.c b/drivers/net/dsa/microchip/ksz_common.c
index 39dace8..826e046 100644
--- a/drivers/net/dsa/microchip/ksz_common.c
+++ b/drivers/net/dsa/microchip/ksz_common.c
@@ -84,6 +84,10 @@ static void ksz_mib_read_work(struct work_struct *work)
for (i = 0; i < dev->mib_port_cnt; i++) {
p = &dev->ports[i];
+
+ /* Port is not being used. */
+ if (!p->on)
+ continue;
mib = &p->mib;
mutex_lock(&mib->cnt_mutex);
--
1.9.1
^ permalink raw reply related
* [PATCH net-next 2/3] net: dsa: microchip: add KSZ9893 switch support
From: Tristram.Ha @ 2019-02-26 23:37 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, Pavel Machek
Cc: Tristram Ha, UNGLinuxDriver, netdev
In-Reply-To: <1551224265-9304-1-git-send-email-Tristram.Ha@microchip.com>
From: Tristram Ha <Tristram.Ha@microchip.com>
Add KSZ9893 switch support in KSZ9477 driver. This switch is similar to
KSZ9477 except the ingress tail tag has 1 byte instead of 2 bytes. The
XMII register that governs how the host port communicates with the MAC
also has different register definitions.
Signed-off-by: Tristram Ha <Tristram.Ha@microchip.com>
---
drivers/net/dsa/microchip/ksz9477.c | 244 ++++++++++++++++++++++++++++++--
drivers/net/dsa/microchip/ksz9477_spi.c | 4 +-
drivers/net/dsa/microchip/ksz_common.c | 4 +-
include/net/dsa.h | 1 +
net/dsa/dsa.c | 2 +
net/dsa/dsa_priv.h | 1 +
net/dsa/tag_ksz.c | 34 +++++
7 files changed, 274 insertions(+), 16 deletions(-)
diff --git a/drivers/net/dsa/microchip/ksz9477.c b/drivers/net/dsa/microchip/ksz9477.c
index 03de50e..3bb548a 100644
--- a/drivers/net/dsa/microchip/ksz9477.c
+++ b/drivers/net/dsa/microchip/ksz9477.c
@@ -18,6 +18,11 @@
#include "ksz9477_reg.h"
#include "ksz_common.h"
+/* Used with variable features to indicate capabilities. */
+#define GBIT_SUPPORT BIT(0)
+#define NEW_XMII BIT(1)
+#define IS_9893 BIT(2)
+
static const struct {
int index;
char string[ETH_GSTRING_LEN];
@@ -328,7 +333,12 @@ static void ksz9477_port_init_cnt(struct ksz_device *dev, int port)
static enum dsa_tag_protocol ksz9477_get_tag_protocol(struct dsa_switch *ds,
int port)
{
- return DSA_TAG_PROTO_KSZ9477;
+ enum dsa_tag_protocol proto = DSA_TAG_PROTO_KSZ9477;
+ struct ksz_device *dev = ds->priv;
+
+ if (dev->features & IS_9893)
+ proto = DSA_TAG_PROTO_KSZ9893;
+ return proto;
}
static int ksz9477_phy_read16(struct dsa_switch *ds, int addr, int reg)
@@ -353,7 +363,7 @@ static int ksz9477_phy_read16(struct dsa_switch *ds, int addr, int reg)
val = 0x796d;
break;
case MII_PHYSID1:
- val = 0x0022;
+ val = KSZ9477_ID_HI;
break;
case MII_PHYSID2:
val = 0x1631;
@@ -389,6 +399,10 @@ static int ksz9477_phy_write16(struct dsa_switch *ds, int addr, int reg,
/* No real PHY after this. */
if (addr >= dev->phy_port_cnt)
return 0;
+
+ /* No gigabit support. Do not write to this register. */
+ if (!(dev->features & GBIT_SUPPORT) && reg == MII_CTRL1000)
+ return 0;
ksz_pwrite16(dev, addr, 0x100 + (reg << 1), val);
return 0;
@@ -998,11 +1012,156 @@ static void ksz9477_port_mirror_del(struct dsa_switch *ds, int port,
static void ksz9477_phy_setup(struct ksz_device *dev, int port,
struct phy_device *phy)
{
- if (port < dev->phy_port_cnt) {
- /* The MAC actually cannot run in 1000 half-duplex mode. */
+ /* Only apply to port with PHY. */
+ if (port >= dev->phy_port_cnt)
+ return;
+
+ /* The MAC actually cannot run in 1000 half-duplex mode. */
+ phy_remove_link_mode(phy,
+ ETHTOOL_LINK_MODE_1000baseT_Half_BIT);
+
+ /* PHY does not support gigabit. */
+ if (!(dev->features & GBIT_SUPPORT))
phy_remove_link_mode(phy,
- ETHTOOL_LINK_MODE_1000baseT_Half_BIT);
+ ETHTOOL_LINK_MODE_1000baseT_Full_BIT);
+}
+
+static bool ksz9477_get_gbit(struct ksz_device *dev, u8 data)
+{
+ bool gbit;
+
+ if (dev->features & NEW_XMII)
+ gbit = !(data & PORT_MII_NOT_1GBIT);
+ else
+ gbit = !!(data & PORT_MII_1000MBIT_S1);
+ return gbit;
+}
+
+static void ksz9477_set_gbit(struct ksz_device *dev, bool gbit, u8 *data)
+{
+ if (dev->features & NEW_XMII) {
+ if (gbit)
+ *data &= ~PORT_MII_NOT_1GBIT;
+ else
+ *data |= PORT_MII_NOT_1GBIT;
+ } else {
+ if (gbit)
+ *data |= PORT_MII_1000MBIT_S1;
+ else
+ *data &= ~PORT_MII_1000MBIT_S1;
+ }
+}
+
+static int ksz9477_get_xmii(struct ksz_device *dev, u8 data)
+{
+ int mode;
+
+ if (dev->features & NEW_XMII) {
+ switch (data & PORT_MII_SEL_M) {
+ case PORT_MII_SEL:
+ mode = 0;
+ break;
+ case PORT_RMII_SEL:
+ mode = 1;
+ break;
+ case PORT_GMII_SEL:
+ mode = 2;
+ break;
+ default:
+ mode = 3;
+ }
+ } else {
+ switch (data & PORT_MII_SEL_M) {
+ case PORT_MII_SEL_S1:
+ mode = 0;
+ break;
+ case PORT_RMII_SEL_S1:
+ mode = 1;
+ break;
+ case PORT_GMII_SEL_S1:
+ mode = 2;
+ break;
+ default:
+ mode = 3;
+ }
+ }
+ return mode;
+}
+
+static void ksz9477_set_xmii(struct ksz_device *dev, int mode, u8 *data)
+{
+ u8 xmii;
+
+ if (dev->features & NEW_XMII) {
+ switch (mode) {
+ case 0:
+ xmii = PORT_MII_SEL;
+ break;
+ case 1:
+ xmii = PORT_RMII_SEL;
+ break;
+ case 2:
+ xmii = PORT_GMII_SEL;
+ break;
+ default:
+ xmii = PORT_RGMII_SEL;
+ break;
+ }
+ } else {
+ switch (mode) {
+ case 0:
+ xmii = PORT_MII_SEL_S1;
+ break;
+ case 1:
+ xmii = PORT_RMII_SEL_S1;
+ break;
+ case 2:
+ xmii = PORT_GMII_SEL_S1;
+ break;
+ default:
+ xmii = PORT_RGMII_SEL_S1;
+ break;
+ }
+ }
+ *data &= ~PORT_MII_SEL_M;
+ *data |= xmii;
+}
+
+static phy_interface_t ksz9477_get_interface(struct ksz_device *dev, int port)
+{
+ phy_interface_t interface;
+ bool gbit;
+ int mode;
+ u8 data8;
+
+ if (port < dev->phy_port_cnt)
+ return PHY_INTERFACE_MODE_NA;
+ ksz_pread8(dev, port, REG_PORT_XMII_CTRL_1, &data8);
+ gbit = ksz9477_get_gbit(dev, data8);
+ mode = ksz9477_get_xmii(dev, data8);
+ switch (mode) {
+ case 2:
+ interface = PHY_INTERFACE_MODE_GMII;
+ if (gbit)
+ break;
+ case 0:
+ interface = PHY_INTERFACE_MODE_MII;
+ break;
+ case 1:
+ interface = PHY_INTERFACE_MODE_RMII;
+ break;
+ default:
+ interface = PHY_INTERFACE_MODE_RGMII;
+ if (data8 & PORT_RGMII_ID_EG_ENABLE)
+ interface = PHY_INTERFACE_MODE_RGMII_TXID;
+ if (data8 & PORT_RGMII_ID_IG_ENABLE) {
+ interface = PHY_INTERFACE_MODE_RGMII_RXID;
+ if (data8 & PORT_RGMII_ID_EG_ENABLE)
+ interface = PHY_INTERFACE_MODE_RGMII_ID;
+ }
+ break;
}
+ return interface;
}
static void ksz9477_port_setup(struct ksz_device *dev, int port, bool cpu_port)
@@ -1051,24 +1210,25 @@ static void ksz9477_port_setup(struct ksz_device *dev, int port, bool cpu_port)
/* configure MAC to 1G & RGMII mode */
ksz_pread8(dev, port, REG_PORT_XMII_CTRL_1, &data8);
- data8 &= ~PORT_MII_NOT_1GBIT;
- data8 &= ~PORT_MII_SEL_M;
switch (dev->interface) {
case PHY_INTERFACE_MODE_MII:
- data8 |= PORT_MII_NOT_1GBIT;
- data8 |= PORT_MII_SEL;
+ ksz9477_set_xmii(dev, 0, &data8);
+ ksz9477_set_gbit(dev, false, &data8);
p->phydev.speed = SPEED_100;
break;
case PHY_INTERFACE_MODE_RMII:
- data8 |= PORT_MII_NOT_1GBIT;
- data8 |= PORT_RMII_SEL;
+ ksz9477_set_xmii(dev, 1, &data8);
+ ksz9477_set_gbit(dev, false, &data8);
p->phydev.speed = SPEED_100;
break;
case PHY_INTERFACE_MODE_GMII:
- data8 |= PORT_GMII_SEL;
+ ksz9477_set_xmii(dev, 2, &data8);
+ ksz9477_set_gbit(dev, true, &data8);
p->phydev.speed = SPEED_1000;
break;
default:
+ ksz9477_set_xmii(dev, 3, &data8);
+ ksz9477_set_gbit(dev, true, &data8);
data8 &= ~PORT_RGMII_ID_IG_ENABLE;
data8 &= ~PORT_RGMII_ID_EG_ENABLE;
if (dev->interface == PHY_INTERFACE_MODE_RGMII_ID ||
@@ -1077,7 +1237,6 @@ static void ksz9477_port_setup(struct ksz_device *dev, int port, bool cpu_port)
if (dev->interface == PHY_INTERFACE_MODE_RGMII_ID ||
dev->interface == PHY_INTERFACE_MODE_RGMII_TXID)
data8 |= PORT_RGMII_ID_EG_ENABLE;
- data8 |= PORT_RGMII_SEL;
p->phydev.speed = SPEED_1000;
break;
}
@@ -1115,10 +1274,25 @@ static void ksz9477_config_cpu_port(struct dsa_switch *ds)
for (i = 0; i < dev->port_cnt; i++) {
if (dsa_is_cpu_port(ds, i) && (dev->cpu_ports & (1 << i))) {
+ phy_interface_t interface;
+
dev->cpu_port = i;
dev->host_mask = (1 << dev->cpu_port);
dev->port_mask |= dev->host_mask;
+ /* Read from XMII register to determine host port
+ * interface. If set specifically in device tree
+ * note the difference to help debugging.
+ */
+ interface = ksz9477_get_interface(dev, i);
+ if (!dev->interface)
+ dev->interface = interface;
+ if (interface && interface != dev->interface)
+ dev_info(dev->dev,
+ "use %s instead of %s\n",
+ phy_modes(dev->interface),
+ phy_modes(interface));
+
/* enable cpu port */
ksz9477_port_setup(dev, i, true);
p = &dev->ports[dev->cpu_port];
@@ -1172,6 +1346,9 @@ static int ksz9477_setup(struct dsa_switch *ds)
ksz9477_cfg32(dev, REG_SW_QM_CTRL__4, UNICAST_VLAN_BOUNDARY,
true);
+ /* Do not work correctly with tail tagging. */
+ ksz_cfg(dev, REG_SW_MAC_CTRL_0, SW_CHECK_LENGTH, false);
+
/* accept packet up to 2000bytes */
ksz_cfg(dev, REG_SW_MAC_CTRL_1, SW_LEGAL_PACKET_DISABLE, true);
@@ -1230,6 +1407,8 @@ static u32 ksz9477_get_port_addr(int port, int offset)
static int ksz9477_switch_detect(struct ksz_device *dev)
{
u8 data8;
+ u8 id_hi;
+ u8 id_lo;
u32 id32;
int ret;
@@ -1247,11 +1426,40 @@ static int ksz9477_switch_detect(struct ksz_device *dev)
ret = ksz_read32(dev, REG_CHIP_ID0__1, &id32);
if (ret)
return ret;
+ ret = ksz_read8(dev, REG_GLOBAL_OPTIONS, &data8);
+ if (ret)
+ return ret;
/* Number of ports can be reduced depending on chip. */
dev->mib_port_cnt = TOTAL_PORT_NUM;
dev->phy_port_cnt = 5;
+ /* Default capability is gigabit capable. */
+ dev->features = GBIT_SUPPORT;
+
+ id_hi = (u8)(id32 >> 16);
+ id_lo = (u8)(id32 >> 8);
+ if ((id_lo & 0xf) == 3) {
+ /* Chip is from KSZ9893 design. */
+ dev->features |= IS_9893;
+
+ /* Chip does not support gigabit. */
+ if (data8 & SW_QW_ABLE)
+ dev->features &= ~GBIT_SUPPORT;
+ dev->mib_port_cnt = 3;
+ dev->phy_port_cnt = 2;
+ } else {
+ /* Chip uses new XMII register definitions. */
+ dev->features |= NEW_XMII;
+
+ /* Chip does not support gigabit. */
+ if (!(data8 & SW_GIGABIT_ABLE))
+ dev->features &= ~GBIT_SUPPORT;
+ }
+
+ /* Change chip id to known ones so it can be matched against them. */
+ id32 = (id_hi << 16) | (id_lo << 8);
+
dev->chip_id = id32;
return 0;
@@ -1286,6 +1494,15 @@ struct ksz_chip_data {
.cpu_ports = 0x7F, /* can be configured as cpu port */
.port_cnt = 7, /* total physical port count */
},
+ {
+ .chip_id = 0x00989300,
+ .dev_name = "KSZ9893",
+ .num_vlans = 4096,
+ .num_alus = 4096,
+ .num_statics = 16,
+ .cpu_ports = 0x07, /* can be configured as cpu port */
+ .port_cnt = 3, /* total port count */
+ },
};
static int ksz9477_switch_init(struct ksz_device *dev)
@@ -1333,7 +1550,6 @@ static int ksz9477_switch_init(struct ksz_device *dev)
if (!dev->ports[i].mib.counters)
return -ENOMEM;
}
- dev->interface = PHY_INTERFACE_MODE_RGMII_TXID;
return 0;
}
diff --git a/drivers/net/dsa/microchip/ksz9477_spi.c b/drivers/net/dsa/microchip/ksz9477_spi.c
index d757ba1..7517862 100644
--- a/drivers/net/dsa/microchip/ksz9477_spi.c
+++ b/drivers/net/dsa/microchip/ksz9477_spi.c
@@ -2,7 +2,7 @@
/*
* Microchip KSZ9477 series register access through SPI
*
- * Copyright (C) 2017-2018 Microchip Technology Inc.
+ * Copyright (C) 2017-2019 Microchip Technology Inc.
*/
#include <asm/unaligned.h>
@@ -155,6 +155,8 @@ static void ksz9477_spi_shutdown(struct spi_device *spi)
static const struct of_device_id ksz9477_dt_ids[] = {
{ .compatible = "microchip,ksz9477" },
{ .compatible = "microchip,ksz9897" },
+ { .compatible = "microchip,ksz9893" },
+ { .compatible = "microchip,ksz9563" },
{},
};
MODULE_DEVICE_TABLE(of, ksz9477_dt_ids);
diff --git a/drivers/net/dsa/microchip/ksz_common.c b/drivers/net/dsa/microchip/ksz_common.c
index 9328b88..39dace8 100644
--- a/drivers/net/dsa/microchip/ksz_common.c
+++ b/drivers/net/dsa/microchip/ksz_common.c
@@ -453,7 +453,9 @@ int ksz_switch_register(struct ksz_device *dev,
if (ret)
return ret;
- dev->interface = PHY_INTERFACE_MODE_MII;
+ /* Host port interface will be self detected, or specifically set in
+ * device tree.
+ */
if (dev->dev->of_node) {
ret = of_get_phy_mode(dev->dev->of_node);
if (ret >= 0)
diff --git a/include/net/dsa.h b/include/net/dsa.h
index e8ac5b3..ae480bb 100644
--- a/include/net/dsa.h
+++ b/include/net/dsa.h
@@ -38,6 +38,7 @@ enum dsa_tag_protocol {
DSA_TAG_PROTO_EDSA,
DSA_TAG_PROTO_GSWIP,
DSA_TAG_PROTO_KSZ9477,
+ DSA_TAG_PROTO_KSZ9893,
DSA_TAG_PROTO_LAN9303,
DSA_TAG_PROTO_MTK,
DSA_TAG_PROTO_QCA,
diff --git a/net/dsa/dsa.c b/net/dsa/dsa.c
index aee909b..36de4f2 100644
--- a/net/dsa/dsa.c
+++ b/net/dsa/dsa.c
@@ -57,6 +57,7 @@ static struct sk_buff *dsa_slave_notag_xmit(struct sk_buff *skb,
#endif
#ifdef CONFIG_NET_DSA_TAG_KSZ9477
[DSA_TAG_PROTO_KSZ9477] = &ksz9477_netdev_ops,
+ [DSA_TAG_PROTO_KSZ9893] = &ksz9893_netdev_ops,
#endif
#ifdef CONFIG_NET_DSA_TAG_LAN9303
[DSA_TAG_PROTO_LAN9303] = &lan9303_netdev_ops,
@@ -93,6 +94,7 @@ const char *dsa_tag_protocol_to_str(const struct dsa_device_ops *ops)
#endif
#ifdef CONFIG_NET_DSA_TAG_KSZ9477
[DSA_TAG_PROTO_KSZ9477] = "ksz9477",
+ [DSA_TAG_PROTO_KSZ9893] = "ksz9893",
#endif
#ifdef CONFIG_NET_DSA_TAG_LAN9303
[DSA_TAG_PROTO_LAN9303] = "lan9303",
diff --git a/net/dsa/dsa_priv.h b/net/dsa/dsa_priv.h
index c6caa58..093b7d1 100644
--- a/net/dsa/dsa_priv.h
+++ b/net/dsa/dsa_priv.h
@@ -216,6 +216,7 @@ static inline struct dsa_port *dsa_slave_to_port(const struct net_device *dev)
/* tag_ksz.c */
extern const struct dsa_device_ops ksz9477_netdev_ops;
+extern const struct dsa_device_ops ksz9893_netdev_ops;
/* tag_lan9303.c */
extern const struct dsa_device_ops lan9303_netdev_ops;
diff --git a/net/dsa/tag_ksz.c b/net/dsa/tag_ksz.c
index 927e9c8..de246c9 100644
--- a/net/dsa/tag_ksz.c
+++ b/net/dsa/tag_ksz.c
@@ -16,6 +16,7 @@
/* Typically only one byte is used for tail tag. */
#define KSZ_EGRESS_TAG_LEN 1
+#define KSZ_INGRESS_TAG_LEN 1
static struct sk_buff *ksz_common_xmit(struct sk_buff *skb,
struct net_device *dev, int len)
@@ -141,3 +142,36 @@ static struct sk_buff *ksz9477_rcv(struct sk_buff *skb, struct net_device *dev,
.rcv = ksz9477_rcv,
.overhead = KSZ9477_INGRESS_TAG_LEN,
};
+
+#define KSZ9893_TAIL_TAG_OVERRIDE BIT(5)
+#define KSZ9893_TAIL_TAG_LOOKUP BIT(6)
+
+static struct sk_buff *ksz9893_xmit(struct sk_buff *skb,
+ struct net_device *dev)
+{
+ struct dsa_port *dp = dsa_slave_to_port(dev);
+ struct sk_buff *nskb;
+ u8 *addr;
+ u8 *tag;
+
+ nskb = ksz_common_xmit(skb, dev, KSZ_INGRESS_TAG_LEN);
+ if (!nskb)
+ return NULL;
+
+ /* Tag encoding */
+ tag = skb_put(nskb, KSZ_INGRESS_TAG_LEN);
+ addr = skb_mac_header(nskb);
+
+ *tag = BIT(dp->index);
+
+ if (is_link_local_ether_addr(addr))
+ *tag |= KSZ9893_TAIL_TAG_OVERRIDE;
+
+ return nskb;
+}
+
+const struct dsa_device_ops ksz9893_netdev_ops = {
+ .xmit = ksz9893_xmit,
+ .rcv = ksz9477_rcv,
+ .overhead = KSZ_INGRESS_TAG_LEN,
+};
--
1.9.1
^ permalink raw reply related
* [PATCH net-next 1/3] dt-bindings: net: dsa: document additional Microchip KSZ9477 family switches
From: Tristram.Ha @ 2019-02-26 23:37 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, Pavel Machek
Cc: Tristram Ha, UNGLinuxDriver, netdev
In-Reply-To: <1551224265-9304-1-git-send-email-Tristram.Ha@microchip.com>
From: Tristram Ha <Tristram.Ha@microchip.com>
Document additional Microchip KSZ9477 family switches.
Show how KSZ8565 switch should be configured as the host port is port 7
instead of port 5.
Signed-off-by: Tristram Ha <Tristram.Ha@microchip.com>
---
Documentation/devicetree/bindings/net/dsa/ksz.txt | 43 +++++++++++++++++++++++
1 file changed, 43 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/dsa/ksz.txt b/Documentation/devicetree/bindings/net/dsa/ksz.txt
index 8d58c2a..b5fec1f 100644
--- a/Documentation/devicetree/bindings/net/dsa/ksz.txt
+++ b/Documentation/devicetree/bindings/net/dsa/ksz.txt
@@ -7,6 +7,11 @@ Required properties:
of the following:
- "microchip,ksz9477"
- "microchip,ksz9897"
+ - "microchip,ksz9896"
+ - "microchip,ksz9567"
+ - "microchip,ksz8565"
+ - "microchip,ksz9893"
+ - "microchip,ksz9563"
Optional properties:
@@ -73,4 +78,42 @@ Ethernet switch connected via SPI to the host, CPU port wired to eth0:
};
};
};
+ ksz8565: ksz8565@0 {
+ compatible = "microchip,ksz8565";
+ reg = <0>;
+
+ spi-max-frequency = <44000000>;
+ spi-cpha;
+ spi-cpol;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
+ reg = <0>;
+ label = "lan1";
+ };
+ port@1 {
+ reg = <1>;
+ label = "lan2";
+ };
+ port@2 {
+ reg = <2>;
+ label = "lan3";
+ };
+ port@3 {
+ reg = <3>;
+ label = "lan4";
+ };
+ port@4 {
+ reg = <6>;
+ label = "cpu";
+ ethernet = <ð0>;
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+ };
+ };
+ };
};
--
1.9.1
^ permalink raw reply related
* [PATCH net-next 0/3] net: dsa: microchip: add KSZ9893 switch support
From: Tristram.Ha @ 2019-02-26 23:37 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, Pavel Machek
Cc: Tristram Ha, UNGLinuxDriver, netdev
From: Tristram Ha <Tristram.Ha@microchip.com>
This series of patches is to modify the KSZ9477 DSA driver to support
running KSZ9893 and other switches in the KSZ9477 family.
The KSZ9893 switch is similar to KSZ9477 except the ingress tail tag has
1 byte instead of 2 bytes. The XMII register that governs the MAC
communication also has different register definitions.
Tristram Ha (3):
dt-bindings: net: dsa: document additional Microchip KSZ9477 family
switches
net: dsa: microchip: add KSZ9893 switch support
net: dsa: microchip: add other KSZ9477 switch variants
Documentation/devicetree/bindings/net/dsa/ksz.txt | 43 +++
drivers/net/dsa/microchip/ksz9477.c | 337 +++++++++++++++++++++-
drivers/net/dsa/microchip/ksz9477_spi.c | 7 +-
drivers/net/dsa/microchip/ksz_common.c | 8 +-
include/net/dsa.h | 1 +
net/dsa/dsa.c | 2 +
net/dsa/dsa_priv.h | 1 +
net/dsa/tag_ksz.c | 34 +++
8 files changed, 415 insertions(+), 18 deletions(-)
--
1.9.1
^ permalink raw reply
* Re: [PATCH 3/4] mwifiex: Flag wake-up interrupt as IRQ_NOAUTOEN rather than disabling it too late
From: Brian Norris @ 2019-02-26 23:34 UTC (permalink / raw)
To: Marc Zyngier
Cc: Amitkumar Karwar, Enric Balletbo i Serra, Ganapathi Bhat,
Heiko Stuebner, Kalle Valo, Nishant Sarmukadam, Rob Herring,
Xinming Hu, David S. Miller, devicetree, linux-arm-kernel,
linux-kernel, linux-rockchip, linux-wireless, netdev
In-Reply-To: <20190226233130.GB174696@google.com>
On Tue, Feb 26, 2019 at 03:31:31PM -0800, Brian Norris wrote:
> Hi Marc,
>
> On Sun, Feb 24, 2019 at 02:04:25PM +0000, Marc Zyngier wrote:
> > The mwifiex driver makes unsafe assumptions about the state of the
> > wake-up interrupt. It requests it and only then disable it. Of
> > course, the interrupt may be screaming for whatever reason at that
> > time, and the handler will then be called without the interrupt
> > having been registered with the PM/wakeup subsystem. Oops.
> >
> > The right way to handle this kind of situation is to flag the
> > interrupt with IRQ_NOAUTOEN before requesting it. It will then
> > stay disabled until someone (the wake-up subsystem) enables it.
> >
> > Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>
> This could be:
>
> Fixes: 853402a00823 ("mwifiex: Enable WoWLAN for both sdio and pcie")
Also, this comes after a different change (that's not quite as clearly a
backport-able bugfix). Perhaps it should go first in the series?
Brian
> although, that was just borrowing the existing antipattern from SDIO
> code..
>
> Reviewed-by: Brian Norris <briannorris@chromium.org>
>
> Thanks.
>
> > ---
> > drivers/net/wireless/marvell/mwifiex/main.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/wireless/marvell/mwifiex/main.c b/drivers/net/wireless/marvell/mwifiex/main.c
> > index 2105c2b7c627..82cf35e50579 100644
> > --- a/drivers/net/wireless/marvell/mwifiex/main.c
> > +++ b/drivers/net/wireless/marvell/mwifiex/main.c
> > @@ -1610,6 +1610,7 @@ static void mwifiex_probe_of(struct mwifiex_adapter *adapter)
> > "wake-up interrupt outside 'wake-up' subnode of %pOF\n",
> > adapter->dt_node);
> >
> > + irq_set_status_flags(adapter->irq_wakeup, IRQ_NOAUTOEN);
> > ret = devm_request_irq(dev, adapter->irq_wakeup,
> > mwifiex_irq_wakeup_handler, IRQF_TRIGGER_LOW,
> > "wifi_wake", adapter);
> > @@ -1619,7 +1620,6 @@ static void mwifiex_probe_of(struct mwifiex_adapter *adapter)
> > goto err_exit;
> > }
> >
> > - disable_irq(adapter->irq_wakeup);
> > if (device_init_wakeup(dev, true)) {
> > dev_err(dev, "fail to init wakeup for mwifiex\n");
> > goto err_exit;
> > --
> > 2.20.1
> >
^ permalink raw reply
* Re: [PATCH 3/4] mwifiex: Flag wake-up interrupt as IRQ_NOAUTOEN rather than disabling it too late
From: Brian Norris @ 2019-02-26 23:31 UTC (permalink / raw)
To: Marc Zyngier
Cc: Amitkumar Karwar, Enric Balletbo i Serra, Ganapathi Bhat,
Heiko Stuebner, Kalle Valo, Nishant Sarmukadam, Rob Herring,
Xinming Hu, David S. Miller, devicetree, linux-arm-kernel,
linux-kernel, linux-rockchip, linux-wireless, netdev
In-Reply-To: <20190224140426.3267-4-marc.zyngier@arm.com>
Hi Marc,
On Sun, Feb 24, 2019 at 02:04:25PM +0000, Marc Zyngier wrote:
> The mwifiex driver makes unsafe assumptions about the state of the
> wake-up interrupt. It requests it and only then disable it. Of
> course, the interrupt may be screaming for whatever reason at that
> time, and the handler will then be called without the interrupt
> having been registered with the PM/wakeup subsystem. Oops.
>
> The right way to handle this kind of situation is to flag the
> interrupt with IRQ_NOAUTOEN before requesting it. It will then
> stay disabled until someone (the wake-up subsystem) enables it.
>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
This could be:
Fixes: 853402a00823 ("mwifiex: Enable WoWLAN for both sdio and pcie")
although, that was just borrowing the existing antipattern from SDIO
code..
Reviewed-by: Brian Norris <briannorris@chromium.org>
Thanks.
> ---
> drivers/net/wireless/marvell/mwifiex/main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/marvell/mwifiex/main.c b/drivers/net/wireless/marvell/mwifiex/main.c
> index 2105c2b7c627..82cf35e50579 100644
> --- a/drivers/net/wireless/marvell/mwifiex/main.c
> +++ b/drivers/net/wireless/marvell/mwifiex/main.c
> @@ -1610,6 +1610,7 @@ static void mwifiex_probe_of(struct mwifiex_adapter *adapter)
> "wake-up interrupt outside 'wake-up' subnode of %pOF\n",
> adapter->dt_node);
>
> + irq_set_status_flags(adapter->irq_wakeup, IRQ_NOAUTOEN);
> ret = devm_request_irq(dev, adapter->irq_wakeup,
> mwifiex_irq_wakeup_handler, IRQF_TRIGGER_LOW,
> "wifi_wake", adapter);
> @@ -1619,7 +1620,6 @@ static void mwifiex_probe_of(struct mwifiex_adapter *adapter)
> goto err_exit;
> }
>
> - disable_irq(adapter->irq_wakeup);
> if (device_init_wakeup(dev, true)) {
> dev_err(dev, "fail to init wakeup for mwifiex\n");
> goto err_exit;
> --
> 2.20.1
>
^ permalink raw reply
* Re: [PATCH 0/4] mwifiex PCI/wake-up interrupt fixes
From: Brian Norris @ 2019-02-26 23:28 UTC (permalink / raw)
To: Marc Zyngier
Cc: Amitkumar Karwar, Enric Balletbo i Serra, Ganapathi Bhat,
Heiko Stuebner, Kalle Valo, Nishant Sarmukadam, Rob Herring,
Xinming Hu, David S. Miller, devicetree, linux-arm-kernel,
linux-kernel, linux-rockchip, linux-wireless, netdev, linux-pm,
Jeffy Chen, Rafael J. Wysocki, Tony Lindgren
In-Reply-To: <20190224140426.3267-1-marc.zyngier@arm.com>
+ others
Hi Marc,
Thanks for the series. I have a few bits of history to add to this, and
some comments.
On Sun, Feb 24, 2019 at 02:04:22PM +0000, Marc Zyngier wrote:
> For quite some time, I wondered why the PCI mwifiex device built in my
> Chromebook was unable to use the good old legacy interrupts. But as MSIs
> were working fine, I never really bothered investigating. I finally had a
> look, and the result isn't very pretty.
>
> On this machine (rk3399-based kevin), the wake-up interrupt is described as
> such:
>
> &pci_rootport {
> mvl_wifi: wifi@0,0 {
> compatible = "pci1b4b,2b42";
> reg = <0x83010000 0x0 0x00000000 0x0 0x00100000
> 0x83010000 0x0 0x00100000 0x0 0x00100000>;
> interrupt-parent = <&gpio0>;
> interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
> pinctrl-names = "default";
> pinctrl-0 = <&wlan_host_wake_l>;
> wakeup-source;
> };
> };
>
> Note how the interrupt is part of the properties directly attached to the
> PCI node. And yet, this interrupt has nothing to do with a PCI legacy
> interrupt, as it is attached to the wake-up widget that bypasses the PCIe RC
> altogether (Yay for the broken design!). This is in total violation of the
> IEEE Std 1275-1994 spec[1], which clearly documents that such interrupt
> specifiers describe the PCI device interrupts, and must obey the
> INT-{A,B,C,D} mapping. Oops!
You're not the first person to notice this. All the motivations are not
necessarily painted clearly in their cover letter, but here are some
previous attempts at solving this problem:
[RFC PATCH v11 0/5] PCI: rockchip: Move PCIe WAKE# handling into pci core
https://lkml.kernel.org/lkml/20171225114742.18920-1-jeffy.chen@rock-chips.com/
http://lkml.kernel.org/lkml/20171226023646.17722-1-jeffy.chen@rock-chips.com/
As you can see by the 12th iteration, it wasn't left unsolved for lack
of trying...
Frankly, if a proper DT replacement to the admittedly bad binding isn't
agreed upon quickly, I'd be very happy to just have WAKE# support
removed from the DTS for now, and the existing mwifiex binding should
just be removed. (Wake-on-WiFi was never properly vetted on these
platforms anyway.) It mostly serves to just cause problems like you've
noticed.
> The net effect of the above is that Linux tries to do something vaguely
> sensible, and uses the same interrupt for both the wake-up widget and the
> PCI device. This doesn't work for two reasons: (1) the wake-up widget grabs
> the interrupt in exclusive mode, and (2) the PCI interrupt is still routed
> to the RC, leading to a screaming interrupt. This simply cannot work.
>
> To sort out this mess, we need to lift the confusion between the two
> interrupts. This is done by extending the DT binding to allow the wake-up
> interrupt to be described in a 'wake-up' subnode, sidestepping the issue
> completely. On my Chromebook, it now looks like this:
>
> &pci_rootport {
> mvl_wifi: wifi@0,0 {
> compatible = "pci1b4b,2b42";
> reg = <0x83010000 0x0 0x00000000 0x0 0x00100000
> 0x83010000 0x0 0x00100000 0x0 0x00100000>;
> pinctrl-names = "default";
> pinctrl-0 = <&wlan_host_wake_l>;
> wake-up {
> interrupt-parent = <&gpio0>;
> interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
> wakeup-source;
> };
> };
> };
One problem Rockchip authors were also trying to resolve here is that
PCIe WAKE# handling should not really be something the PCI device driver
has to handle directly. Despite your complaints about not using in-band
TLP wakeup, a separate WAKE# pin is in fact a documented part of the
PCIe standard, and it so happens that the Rockchip RC does not support
handling TLPs in S3, if you want to have decent power consumption. (Your
"bad hardware" complaints could justifiably fall here, I suppose.)
Additionally, I've had pushback from PCI driver authors/maintainers on
adding more special handling for this sort of interrupt property (not
the binding specifically, but just the concept of handling WAKE# in the
driver), as they claim this should be handled by the system firmware,
when they set the appropriate wakeup flags, which filter down to
__pci_enable_wake() -> platform_pci_set_wakeup(). That's how x86 systems
do it (note: I know for a fact that many have a very similar
architecture -- WAKE# is not routed to the RC, because, why does it need
to? and they *don't* use TLP wakeup either -- they just hide it in
firmware better), and it Just Works.
So, we basically concluded that we should standardize on a way to
describe WAKE# interrupts such that PCI drivers don't have to deal with
it at all, and the PCI core can do it for us. 12 revisions later
and...we still never agreed on a good device tree binding for this.
IOW, maybe your wake-up sub-node is the best way to side-step the
problems of conflicting with the OF PCI spec. But I'd still really like
to avoid parsing it in mwifiex, if at all possible.
(We'd still be left with the marvell,wakeup-pin propery to parse
specifically in mwifiex, which sadly has to exist because....well,
Samsung decided to do chip-on-board, and then they failed to use the
correct pin on Marvell's side when wiring up WAKE#. Sigh.)
> The driver is then updated to look for this subnode first, and fallback to
> the original, broken behaviour (spitting out a warning in the offending
> configuration).
>
> For good measure, there are two additional patches:
>
> - The wake-up interrupt requesting is horribly racy, and could lead to
> unpredictable behaviours. Let's fix that properly.
Ack. That mistake was repeated in other drivers and has since been fixed
in those. We need it here too.
Brian
> - A final patch implementing the above transformation for the whole
> RK3399-based Chromebook range, which all use the same broken
> configuration.
>
> With all that, I finally have PCI legacy interrupts working with the mwifiex
> driver on my Chromebook.
>
> [1] http://www.devicetree.org/open-firmware/bindings/pci/pci2_1.pdf
>
> Marc Zyngier (4):
> dt-bindings/marvell-8xxx: Allow wake-up interrupt to be placed in a
> separate node
> mwifiex: Fetch wake-up interrupt from 'wake-up' subnode when it exists
> mwifiex: Flag wake-up interrupt as IRQ_NOAUTOEN rather than disabling
> it too late
> arm64: dts: rockchip: gru: Move wifi wake-up interrupt into its own
> subnode
>
> .../bindings/net/wireless/marvell-8xxx.txt | 23 ++++++++++++++++++-
> .../dts/rockchip/rk3399-gru-chromebook.dtsi | 8 ++++---
> drivers/net/wireless/marvell/mwifiex/main.c | 13 +++++++++--
> 3 files changed, 38 insertions(+), 6 deletions(-)
>
> --
> 2.20.1
>
^ permalink raw reply
* Re: [BUG] net/sched : qlen can not really be per cpu ?
From: Eric Dumazet @ 2019-02-26 23:19 UTC (permalink / raw)
To: Eric Dumazet, John Fastabend, Networking, Jamal Hadi Salim,
Cong Wang, Jiri Pirko
In-Reply-To: <5fb87db3-d5bd-714b-213d-6821f4bf37da@gmail.com>
On 02/25/2019 10:42 PM, Eric Dumazet wrote:
> HTB + pfifo_fast as a leaf qdisc hits badly the following warning in htb_activate() :
>
> WARN_ON(cl->level || !cl->leaf.q || !cl->leaf.q->q.qlen);
>
> This is because pfifo_fast does not update sch->q.qlen, but per cpu counters.
> So cl->leaf.q->q.qlen is zero.
>
> HFSC, CBQ, DRR, QFQ have the same problem.
>
> Any ideas how we can fix this ?
What about something simple for stable ?
( I yet have to boot/test this )
diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h
index 9481f2c142e26ee1174653d673e6134edd9851da..3a9e442fcaaf2ea48ae65bc87ee95f59cd7100c8 100644
--- a/include/net/sch_generic.h
+++ b/include/net/sch_generic.h
@@ -51,7 +51,10 @@ struct qdisc_size_table {
struct qdisc_skb_head {
struct sk_buff *head;
struct sk_buff *tail;
- __u32 qlen;
+ union {
+ __u32 qlen;
+ atomic_t atomic_qlen;
+ };
spinlock_t lock;
};
@@ -408,27 +411,19 @@ static inline void qdisc_cb_private_validate(const struct sk_buff *skb, int sz)
BUILD_BUG_ON(sizeof(qcb->data) < sz);
}
-static inline int qdisc_qlen_cpu(const struct Qdisc *q)
-{
- return this_cpu_ptr(q->cpu_qstats)->qlen;
-}
-
static inline int qdisc_qlen(const struct Qdisc *q)
{
return q->q.qlen;
}
-static inline int qdisc_qlen_sum(const struct Qdisc *q)
+static inline u32 qdisc_qlen_sum(const struct Qdisc *q)
{
- __u32 qlen = q->qstats.qlen;
- int i;
+ u32 qlen = q->qstats.qlen;
- if (q->flags & TCQ_F_NOLOCK) {
- for_each_possible_cpu(i)
- qlen += per_cpu_ptr(q->cpu_qstats, i)->qlen;
- } else {
+ if (q->flags & TCQ_F_NOLOCK)
+ qlen += atomic_read(&q->q.atomic_qlen);
+ else
qlen += q->q.qlen;
- }
return qlen;
}
@@ -827,12 +822,12 @@ static inline void qdisc_qstats_cpu_backlog_inc(struct Qdisc *sch,
static inline void qdisc_qstats_cpu_qlen_inc(struct Qdisc *sch)
{
- this_cpu_inc(sch->cpu_qstats->qlen);
+ atomic_inc(&sch->q.atomic_qlen);
}
static inline void qdisc_qstats_cpu_qlen_dec(struct Qdisc *sch)
{
- this_cpu_dec(sch->cpu_qstats->qlen);
+ atomic_dec(&sch->q.atomic_qlen);
}
static inline void qdisc_qstats_cpu_requeues_inc(struct Qdisc *sch)
^ permalink raw reply related
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