* Kopie van: "Fw :pingyanwu
From: Bergjuffer.nl @ 2017-12-22 10:56 UTC (permalink / raw)
To: netdev
Kopie van:
Dit is een aanvraag via http://www.bergjuffer.nl/ van:
tangquegao <netdev@vger.kernel.org>
【太阳城集团】： www.3330780.com/? 一路真诚相伴，注册送28，存10送18，存50送28。
电子游艺投注1元起，天天返水1.8%无上限；公司存款倾情回馈1%起，笔笔皆有送！
您想要的女神范都在这里，百家乐你准备好了吗？
+QQ：362563309 获得〖特邀〗存款开运金（最高8888元）。
闭门群动息，积雪透疏林。有客寒方觉，无声晓已深。
蚕饥使君马，雁避将军箭。宝柱惜离弦，流黄悲赤县。
孟轲分邪正，眸子看了眊.杳然粹而清，可以镇浮躁，
从军古云乐，谈笑青油幕。灯明夜观棋，月暗秋城柝。 ——李正封
^ permalink raw reply
* Re: INFO: task hung in bpf_exit_net
From: Marcelo Ricardo Leitner @ 2017-12-22 11:16 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: David Ahern, syzbot, LKML, Ingo Molnar, Peter Zijlstra,
syzkaller-bugs, David Miller, Florian Westphal, Daniel Borkmann,
Xin Long, jakub.kicinski, mschiffer, Vladislav Yasevich,
Jiri Benc, netdev, Neil Horman, linux-sctp
In-Reply-To: <CACT4Y+aaSX4S3KHJjqkiQhhOZAtEN_fMD1m_Ve3rz4u4x9KSWg@mail.gmail.com>
On Fri, Dec 22, 2017 at 11:58:08AM +0100, Dmitry Vyukov wrote:
> On Tue, Dec 19, 2017 at 7:20 PM, David Ahern <dsahern@gmail.com> wrote:
> > On 12/19/17 5:47 AM, Dmitry Vyukov wrote:
> >> On Tue, Dec 19, 2017 at 1:36 PM, syzbot
> >> <bot+21b498fc12cf2041655f8e1eeae0733807d794b3@syzkaller.appspotmail.com>
> >> wrote:
> >>> Hello,
> >>>
> >>> syzkaller hit the following crash on
> >>> 7ceb97a071e80f1b5e4cd5a36de135612a836388
> >>> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
> >>> compiler: gcc (GCC) 7.1.1 20170620
> >>> .config is attached
> >>> Raw console output is attached.
> >>>
> >>> Unfortunately, I don't have any reproducer for this bug yet.
> >>>
> >>>
> >>> sctp: sctp_transport_update_pmtu: Reported pmtu 508 too low, using default
> >>> minimum of 512
> >>> INFO: task kworker/u4:0:5 blocked for more than 120 seconds.
> >>> Not tainted 4.15.0-rc2-next-20171205+ #59
> >>> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> >>> kworker/u4:0 D15808 5 2 0x80000000
> >>> Workqueue: netns cleanup_net
> >>> Call Trace:
> >>> context_switch kernel/sched/core.c:2800 [inline]
> >>> __schedule+0x8eb/0x2060 kernel/sched/core.c:3376
> >>> schedule+0xf5/0x430 kernel/sched/core.c:3435
> >>> schedule_preempt_disabled+0x10/0x20 kernel/sched/core.c:3493
> >>> __mutex_lock_common kernel/locking/mutex.c:833 [inline]
> >>> __mutex_lock+0xaad/0x1a80 kernel/locking/mutex.c:893
> >>> mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:908
> >>> rtnl_lock+0x17/0x20 net/core/rtnetlink.c:74
> >>> tc_action_net_exit include/net/act_api.h:125 [inline]
> >>> bpf_exit_net+0x1a2/0x340 net/sched/act_bpf.c:408
> >>> ops_exit_list.isra.6+0xae/0x150 net/core/net_namespace.c:142
> >>> cleanup_net+0x5c7/0xb60 net/core/net_namespace.c:484
> >>> process_one_work+0xbfd/0x1bc0 kernel/workqueue.c:2113
> >>> worker_thread+0x223/0x1990 kernel/workqueue.c:2247
> >>> kthread+0x37a/0x440 kernel/kthread.c:238
> >>> ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:517
> >>>
> >>> Showing all locks held in the system:
> >>> 4 locks held by kworker/u4:0/5:
> >>> #0: ((wq_completion)"%s""netns"){+.+.}, at: [<00000000b9f061a2>]
> >>> __write_once_size include/linux/compiler.h:212 [inline]
> >>> #0: ((wq_completion)"%s""netns"){+.+.}, at: [<00000000b9f061a2>]
> >>> atomic64_set arch/x86/include/asm/atomic64_64.h:34 [inline]
> >>> #0: ((wq_completion)"%s""netns"){+.+.}, at: [<00000000b9f061a2>]
> >>> atomic_long_set include/asm-generic/atomic-long.h:57 [inline]
> >>> #0: ((wq_completion)"%s""netns"){+.+.}, at: [<00000000b9f061a2>]
> >>> set_work_data kernel/workqueue.c:619 [inline]
> >>> #0: ((wq_completion)"%s""netns"){+.+.}, at: [<00000000b9f061a2>]
> >>> set_work_pool_and_clear_pending kernel/workqueue.c:646 [inline]
> >>> #0: ((wq_completion)"%s""netns"){+.+.}, at: [<00000000b9f061a2>]
> >>> process_one_work+0xad4/0x1bc0 kernel/workqueue.c:2084
> >>> #1: (net_cleanup_work){+.+.}, at: [<000000006c7c48a3>]
> >>> process_one_work+0xb2f/0x1bc0 kernel/workqueue.c:2088
> >>> #2: (net_mutex){+.+.}, at: [<00000000bf4709f3>] cleanup_net+0x247/0xb60
> >>> net/core/net_namespace.c:450
> >>> #3: (rtnl_mutex){+.+.}, at: [<0000000053390f0b>] rtnl_lock+0x17/0x20
> >>> net/core/rtnetlink.c:74
> >>> 3 locks held by kworker/1:0/17:
> >>> #0: ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at: [<00000000b9f061a2>]
> >>> __write_once_size include/linux/compiler.h:212 [inline]
> >>> #0: ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at: [<00000000b9f061a2>]
> >>> atomic64_set arch/x86/include/asm/atomic64_64.h:34 [inline]
> >>> #0: ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at: [<00000000b9f061a2>]
> >>> atomic_long_set include/asm-generic/atomic-long.h:57 [inline]
> >>> #0: ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at: [<00000000b9f061a2>]
> >>> set_work_data kernel/workqueue.c:619 [inline]
> >>> #0: ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at: [<00000000b9f061a2>]
> >>> set_work_pool_and_clear_pending kernel/workqueue.c:646 [inline]
> >>> #0: ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at: [<00000000b9f061a2>]
> >>> process_one_work+0xad4/0x1bc0 kernel/workqueue.c:2084
> >>> #1: ((addr_chk_work).work){+.+.}, at: [<000000006c7c48a3>]
> >>> process_one_work+0xb2f/0x1bc0 kernel/workqueue.c:2088
> >>> #2: (rtnl_mutex){+.+.}, at: [<0000000053390f0b>] rtnl_lock+0x17/0x20
> >>> net/core/rtnetlink.c:74
> >>> 2 locks held by khungtaskd/675:
> >>> #0: (rcu_read_lock){....}, at: [<00000000587c8471>]
> >>> check_hung_uninterruptible_tasks kernel/hung_task.c:175 [inline]
> >>> #0: (rcu_read_lock){....}, at: [<00000000587c8471>] watchdog+0x1c5/0xd60
> >>> kernel/hung_task.c:249
> >>> #1: (tasklist_lock){.+.+}, at: [<000000005288685e>]
> >>> debug_show_all_locks+0xd3/0x400 kernel/locking/lockdep.c:4554
> >>> 1 lock held by rsyslogd/2974:
> >>> #0: (&f->f_pos_lock){+.+.}, at: [<0000000011e00499>]
> >>> __fdget_pos+0x131/0x1a0 fs/file.c:770
> >>> 2 locks held by getty/3056:
> >>> #0: (&tty->ldisc_sem){++++}, at: [<00000000b9fd70a9>]
> >>> ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
> >>> #1: (&ldata->atomic_read_lock){+.+.}, at: [<00000000abb3bd08>]
> >>> n_tty_read+0x2f2/0x1a10 drivers/tty/n_tty.c:2131
> >>> 2 locks held by getty/3057:
> >>> #0: (&tty->ldisc_sem){++++}, at: [<00000000b9fd70a9>]
> >>> ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
> >>> #1: (&ldata->atomic_read_lock){+.+.}, at: [<00000000abb3bd08>]
> >>> n_tty_read+0x2f2/0x1a10 drivers/tty/n_tty.c:2131
> >>> 2 locks held by getty/3058:
> >>> #0: (&tty->ldisc_sem){++++}, at: [<00000000b9fd70a9>]
> >>> ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
> >>> #1: (&ldata->atomic_read_lock){+.+.}, at: [<00000000abb3bd08>]
> >>> n_tty_read+0x2f2/0x1a10 drivers/tty/n_tty.c:2131
> >>> 2 locks held by getty/3059:
> >>> #0: (&tty->ldisc_sem){++++}, at: [<00000000b9fd70a9>]
> >>> ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
> >>> #1: (&ldata->atomic_read_lock){+.+.}, at: [<00000000abb3bd08>]
> >>> n_tty_read+0x2f2/0x1a10 drivers/tty/n_tty.c:2131
> >>> 2 locks held by getty/3060:
> >>> #0: (&tty->ldisc_sem){++++}, at: [<00000000b9fd70a9>]
> >>> ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
> >>> #1: (&ldata->atomic_read_lock){+.+.}, at: [<00000000abb3bd08>]
> >>> n_tty_read+0x2f2/0x1a10 drivers/tty/n_tty.c:2131
> >>> 2 locks held by getty/3061:
> >>> #0: (&tty->ldisc_sem){++++}, at: [<00000000b9fd70a9>]
> >>> ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
> >>> #1: (&ldata->atomic_read_lock){+.+.}, at: [<00000000abb3bd08>]
> >>> n_tty_read+0x2f2/0x1a10 drivers/tty/n_tty.c:2131
> >>> 2 locks held by getty/3062:
> >>> #0: (&tty->ldisc_sem){++++}, at: [<00000000b9fd70a9>]
> >>> ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
> >>> #1: (&ldata->atomic_read_lock){+.+.}, at: [<00000000abb3bd08>]
> >>> n_tty_read+0x2f2/0x1a10 drivers/tty/n_tty.c:2131
> >>>
> >>> =============================================
> >>>
> >>> NMI backtrace for cpu 0
> >>> CPU: 0 PID: 675 Comm: khungtaskd Not tainted 4.15.0-rc2-next-20171205+ #59
> >>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> >>> Google 01/01/2011
> >>> Call Trace:
> >>> __dump_stack lib/dump_stack.c:17 [inline]
> >>> dump_stack+0x194/0x257 lib/dump_stack.c:53
> >>> nmi_cpu_backtrace+0x1d2/0x210 lib/nmi_backtrace.c:103
> >>> nmi_trigger_cpumask_backtrace+0x122/0x180 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:138 [inline]
> >>> check_hung_task kernel/hung_task.c:132 [inline]
> >>> check_hung_uninterruptible_tasks kernel/hung_task.c:190 [inline]
> >>> watchdog+0x90c/0xd60 kernel/hung_task.c:249
> >>> kthread+0x37a/0x440 kernel/kthread.c:238
> >>> ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:517
> >>> Sending NMI from CPU 0 to CPUs 1:
> >>> NMI backtrace for cpu 1
> >>> CPU: 1 PID: 13156 Comm: syz-executor7 Not tainted 4.15.0-rc2-next-20171205+
> >>> #59
> >>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> >>> Google 01/01/2011
> >>> task: 000000005209c120 task.stack: 00000000ffaab0e8
> >>> RIP: 0010:inb arch/x86/include/asm/io.h:348 [inline]
> >>> RIP: 0010:io_serial_in+0x6b/0x90 drivers/tty/serial/8250/8250_port.c:434
> >>> RSP: 0018:ffff8801c0a16e70 EFLAGS: 00000002
> >>> RAX: dffffc0000000000 RBX: 00000000000003fd RCX: 0000000000000000
> >>> RDX: 00000000000003fd RSI: ffffc90003745000 RDI: ffffffff87cf1a40
> >>> RBP: ffff8801c0a16e80 R08: 0000000000000005 R09: 000000000000000c
> >>> R10: 0000000000000000 R11: ffffffff8748dd20 R12: ffffffff87cf1a00
> >>> R13: 0000000000000020 R14: fffffbfff0f9e387 R15: fffffbfff0f9e34a
> >>> FS: 00007f6d52e3f700(0000) GS:ffff8801db500000(0000) knlGS:0000000000000000
> >>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> >>> CR2: 000000c42005de80 CR3: 00000001c368a000 CR4: 00000000001406e0
> >>> DR0: 0000000020000000 DR1: 0000000000000000 DR2: 0000000000000000
> >>> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600
> >>> Call Trace:
> >>> serial_in drivers/tty/serial/8250/8250.h:111 [inline]
> >>> wait_for_xmitr+0x93/0x1e0 drivers/tty/serial/8250/8250_port.c:2033
> >>> serial8250_console_putchar+0x1f/0x60
> >>> drivers/tty/serial/8250/8250_port.c:3170
> >>> uart_console_write+0xac/0xe0 drivers/tty/serial/serial_core.c:1858
> >>> serial8250_console_write+0x647/0xa20
> >>> drivers/tty/serial/8250/8250_port.c:3236
> >>> univ8250_console_write+0x5f/0x70 drivers/tty/serial/8250/8250_core.c:590
> >>> call_console_drivers kernel/printk/printk.c:1574 [inline]
> >>> console_unlock+0x788/0xd70 kernel/printk/printk.c:2233
> >>> vprintk_emit+0x4ad/0x590 kernel/printk/printk.c:1757
> >>> vprintk_default+0x28/0x30 kernel/printk/printk.c:1796
> >>> vprintk_func+0x57/0xc0 kernel/printk/printk_safe.c:379
> >>> printk+0xaa/0xca kernel/printk/printk.c:1829
> >>> nla_parse+0x374/0x3d0 lib/nlattr.c:257
> >>> nlmsg_parse include/net/netlink.h:398 [inline]
> >>> nl80211_dump_wiphy_parse.isra.37.constprop.83+0x138/0x5c0
> >>> net/wireless/nl80211.c:1920
> >>> nl80211_dump_interface+0x596/0x820 net/wireless/nl80211.c:2660
> >>> genl_lock_dumpit+0x68/0x90 net/netlink/genetlink.c:480
> >>> netlink_dump+0x48c/0xce0 net/netlink/af_netlink.c:2186
> >>> __netlink_dump_start+0x4f0/0x6d0 net/netlink/af_netlink.c:2283
> >>> genl_family_rcv_msg+0xd27/0xfc0 net/netlink/genetlink.c:548
> >>> genl_rcv_msg+0xb2/0x140 net/netlink/genetlink.c:624
> >>> netlink_rcv_skb+0x216/0x440 net/netlink/af_netlink.c:2405
> >>> genl_rcv+0x28/0x40 net/netlink/genetlink.c:635
> >>> netlink_unicast_kernel net/netlink/af_netlink.c:1272 [inline]
> >>> netlink_unicast+0x4e8/0x6f0 net/netlink/af_netlink.c:1298
> >>> netlink_sendmsg+0xa4a/0xe70 net/netlink/af_netlink.c:1861
> >>> sock_sendmsg_nosec net/socket.c:636 [inline]
> >>> sock_sendmsg+0xca/0x110 net/socket.c:646
> >>> sock_write_iter+0x320/0x5e0 net/socket.c:915
> >>> call_write_iter include/linux/fs.h:1776 [inline]
> >>> new_sync_write fs/read_write.c:469 [inline]
> >>> __vfs_write+0x68a/0x970 fs/read_write.c:482
> >>> vfs_write+0x18f/0x510 fs/read_write.c:544
> >>> SYSC_write fs/read_write.c:589 [inline]
> >>> SyS_write+0xef/0x220 fs/read_write.c:581
> >>> entry_SYSCALL_64_fastpath+0x1f/0x96
> >>> RIP: 0033:0x4529d9
> >>> RSP: 002b:00007f6d52e3ec58 EFLAGS: 00000212 ORIG_RAX: 0000000000000001
> >>> RAX: ffffffffffffffda RBX: 00007f6d52e3f700 RCX: 00000000004529d9
> >>> RDX: 0000000000000024 RSI: 0000000020454000 RDI: 0000000000000016
> >>> RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
> >>> R10: 0000000000000000 R11: 0000000000000212 R12: 0000000000000000
> >>> R13: 0000000000a6f7ff R14: 00007f6d52e3f9c0 R15: 0000000000000000
> >>> Code: 24 d9 00 00 00 49 8d 7c 24 40 48 b8 00 00 00 00 00 fc ff df 48 89 fa
> >>> 48 c1 ea 03 d3 e3 80 3c 02 00 75 17 41 03 5c 24 40 89 da ec <5b> 0f b6 c0 41
> >>> 5c 5d c3 e8 38 b0 18 ff eb c2 e8 91 b0 18 ff eb
> >>>
> >>>
> >>> ---
> >>> This bug is generated by a dumb bot. It may contain errors.
> >>> See https://goo.gl/tpsmEJ for details.
> >>> Direct all questions to syzkaller@googlegroups.com.
> >>> Please credit me with: Reported-by: syzbot <syzkaller@googlegroups.com>
> >>>
> >>> syzbot will keep track of this bug report.
> >>> Once a fix for this bug is merged into any tree, reply to this email with:
> >>> #syz fix: exact-commit-title
> >>> To mark this as a duplicate of another syzbot report, please reply with:
> >>> #syz dup: exact-subject-of-another-report
> >>> If it's a one-off invalid bug report, please reply with:
> >>> #syz invalid
> >>> Note: if the crash happens again, it will cause creation of a new bug
> >>> report.
> >>> Note: all commands must start from beginning of the line in the email body.
> >>>
> >>> --
> >>> 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/001a1143fd00a8cc790560b0b552%40google.com.
> >>> For more options, visit https://groups.google.com/d/optout.
> >>
> >>
> >> This looks like +rtnetlink issue.
> >>
> >
> > Same with this one, perhaps related to / fixed by:
> > http://patchwork.ozlabs.org/patch/850957/
> >
>
>
>
> Looking at the log, this one seems to be an infinite loop in SCTP code
> with console output in it. Kernel is busy printing gazilion of:
Do you have a link for such log? I don't seem to have received the
initial syzbot email, so I don't have its attachments. Or if you may,
please fwd it to me/list.
Thanks.
>
> [ 176.491099] sctp: sctp_transport_update_pmtu: Reported pmtu 508 too
> low, using default minimum of 512
> ** 110 printk messages dropped **
> [ 176.503409] sctp: sctp_transport_update_pmtu: Reported pmtu 508 too
> low, using default minimum of 512
> ** 103 printk messages dropped **
> ...
> [ 246.742374] sctp: sctp_transport_update_pmtu: Reported pmtu 508 too
> low, using default minimum of 512
> [ 246.742484] sctp: sctp_transport_update_pmtu: Reported pmtu 508 too
> low, using default minimum of 512
> [ 246.742590] sctp: sctp_transport_update_pmtu: Reported pmtu 508 too
> low, using default minimum of 512
>
> Looks like a different issue.
>
^ permalink raw reply
* Driver i40e issues changing NIC queue runtime under high-load
From: Jesper Dangaard Brouer @ 2017-12-22 11:04 UTC (permalink / raw)
To: Jeff Kirsher, Björn Töpel, netdev@vger.kernel.org,
intel-wired-lan
Cc: brouer, Karlsson, Magnus
Hi Intel,
I discovered an issue with the driver i40e, when changing the number
of NIC queues, while running a high-load packet generator, and while
having an XDP program loaded.
Tested on clean latest net-next kernel at commit 0a80f0c26bf5
- kernel 4.15.0-rc3-net-next-01003-g0a80f0c26bf5
The NIC goes into a fault state after reporting "PF reset failed, -15"
in dmesg. See below:
i40e 0000:04:00.0: PF reset failed, -15
i40e 0000:04:00.0: User requested queue count/HW max RSS count: 2/64
i40e 0000:04:00.0: ignoring delete macvlan error on PF, err I40E_ERR_QUEUE_EMPTY, aq_err OK
i40e 0000:04:00.0: PF reset failed, -15
The net_device is in a strange state, with ifconfig showing all zero
counters. The driver ethtool stats show packets, but nothing reach
the kernel. Loading a new xdp prog also shows zero counters (thus NIC
HW must drop these packets).
The workaround is to wait for a long while, and then change the number
of queues again.
* If it didn't work you see:
"i40e 0000:04:00.0: PF reset failed, -15"
* If it worked you see:
"i40e 0000:04:00.0: User requested queue count/HW max RSS count: 6/64"
Could some Intel people take a closer look, and explain why the HW goes
into this state? (and explain why it recovers...)
Reproducer setup info:
----------------------
Running xdp program: samples/bpf/xdp1
Tested on latest net-next kernel at commit 0a80f0c26bf5, clean kernel
without any of my patches.
- kernel 4.15.0-rc3-net-next-01003-g0a80f0c26bf5
Packet generator script: pktgen_sample04_many_flows.sh
with 12 threads (-t12) generating arround 12 Mpps.
Command used for changing NIC queues (--set-channels|-L):
ethtool -L i40e1 combined 2
The NIC ethtool stats report RX packets, but nothing reach the kernel:
Show adapter(s) (i40e1) statistics (ONLY that changed!)
Ethtool(i40e1 ) stat: 809566977 ( 809,566,977) <= port.rx_bytes /sec
Ethtool(i40e1 ) stat: 12649480 ( 12,649,480) <= port.rx_size_64 /sec
Ethtool(i40e1 ) stat: 12649479 ( 12,649,479) <= port.rx_unicast /sec
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
Could some people take a closer look, wh
^ permalink raw reply
* Re: INFO: task hung in bpf_exit_net
From: Dmitry Vyukov @ 2017-12-22 10:58 UTC (permalink / raw)
To: David Ahern
Cc: syzbot, LKML, Ingo Molnar, Peter Zijlstra, syzkaller-bugs,
David Miller, Florian Westphal, Daniel Borkmann, Xin Long,
jakub.kicinski, mschiffer, Vladislav Yasevich, Jiri Benc, netdev,
Neil Horman, linux-sctp
In-Reply-To: <f519a1f0-8166-027e-e063-13aa718ce4e4@gmail.com>
On Tue, Dec 19, 2017 at 7:20 PM, David Ahern <dsahern@gmail.com> wrote:
> On 12/19/17 5:47 AM, Dmitry Vyukov wrote:
>> On Tue, Dec 19, 2017 at 1:36 PM, syzbot
>> <bot+21b498fc12cf2041655f8e1eeae0733807d794b3@syzkaller.appspotmail.com>
>> wrote:
>>> Hello,
>>>
>>> syzkaller hit the following crash on
>>> 7ceb97a071e80f1b5e4cd5a36de135612a836388
>>> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
>>> compiler: gcc (GCC) 7.1.1 20170620
>>> .config is attached
>>> Raw console output is attached.
>>>
>>> Unfortunately, I don't have any reproducer for this bug yet.
>>>
>>>
>>> sctp: sctp_transport_update_pmtu: Reported pmtu 508 too low, using default
>>> minimum of 512
>>> INFO: task kworker/u4:0:5 blocked for more than 120 seconds.
>>> Not tainted 4.15.0-rc2-next-20171205+ #59
>>> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
>>> kworker/u4:0 D15808 5 2 0x80000000
>>> Workqueue: netns cleanup_net
>>> Call Trace:
>>> context_switch kernel/sched/core.c:2800 [inline]
>>> __schedule+0x8eb/0x2060 kernel/sched/core.c:3376
>>> schedule+0xf5/0x430 kernel/sched/core.c:3435
>>> schedule_preempt_disabled+0x10/0x20 kernel/sched/core.c:3493
>>> __mutex_lock_common kernel/locking/mutex.c:833 [inline]
>>> __mutex_lock+0xaad/0x1a80 kernel/locking/mutex.c:893
>>> mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:908
>>> rtnl_lock+0x17/0x20 net/core/rtnetlink.c:74
>>> tc_action_net_exit include/net/act_api.h:125 [inline]
>>> bpf_exit_net+0x1a2/0x340 net/sched/act_bpf.c:408
>>> ops_exit_list.isra.6+0xae/0x150 net/core/net_namespace.c:142
>>> cleanup_net+0x5c7/0xb60 net/core/net_namespace.c:484
>>> process_one_work+0xbfd/0x1bc0 kernel/workqueue.c:2113
>>> worker_thread+0x223/0x1990 kernel/workqueue.c:2247
>>> kthread+0x37a/0x440 kernel/kthread.c:238
>>> ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:517
>>>
>>> Showing all locks held in the system:
>>> 4 locks held by kworker/u4:0/5:
>>> #0: ((wq_completion)"%s""netns"){+.+.}, at: [<00000000b9f061a2>]
>>> __write_once_size include/linux/compiler.h:212 [inline]
>>> #0: ((wq_completion)"%s""netns"){+.+.}, at: [<00000000b9f061a2>]
>>> atomic64_set arch/x86/include/asm/atomic64_64.h:34 [inline]
>>> #0: ((wq_completion)"%s""netns"){+.+.}, at: [<00000000b9f061a2>]
>>> atomic_long_set include/asm-generic/atomic-long.h:57 [inline]
>>> #0: ((wq_completion)"%s""netns"){+.+.}, at: [<00000000b9f061a2>]
>>> set_work_data kernel/workqueue.c:619 [inline]
>>> #0: ((wq_completion)"%s""netns"){+.+.}, at: [<00000000b9f061a2>]
>>> set_work_pool_and_clear_pending kernel/workqueue.c:646 [inline]
>>> #0: ((wq_completion)"%s""netns"){+.+.}, at: [<00000000b9f061a2>]
>>> process_one_work+0xad4/0x1bc0 kernel/workqueue.c:2084
>>> #1: (net_cleanup_work){+.+.}, at: [<000000006c7c48a3>]
>>> process_one_work+0xb2f/0x1bc0 kernel/workqueue.c:2088
>>> #2: (net_mutex){+.+.}, at: [<00000000bf4709f3>] cleanup_net+0x247/0xb60
>>> net/core/net_namespace.c:450
>>> #3: (rtnl_mutex){+.+.}, at: [<0000000053390f0b>] rtnl_lock+0x17/0x20
>>> net/core/rtnetlink.c:74
>>> 3 locks held by kworker/1:0/17:
>>> #0: ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at: [<00000000b9f061a2>]
>>> __write_once_size include/linux/compiler.h:212 [inline]
>>> #0: ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at: [<00000000b9f061a2>]
>>> atomic64_set arch/x86/include/asm/atomic64_64.h:34 [inline]
>>> #0: ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at: [<00000000b9f061a2>]
>>> atomic_long_set include/asm-generic/atomic-long.h:57 [inline]
>>> #0: ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at: [<00000000b9f061a2>]
>>> set_work_data kernel/workqueue.c:619 [inline]
>>> #0: ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at: [<00000000b9f061a2>]
>>> set_work_pool_and_clear_pending kernel/workqueue.c:646 [inline]
>>> #0: ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at: [<00000000b9f061a2>]
>>> process_one_work+0xad4/0x1bc0 kernel/workqueue.c:2084
>>> #1: ((addr_chk_work).work){+.+.}, at: [<000000006c7c48a3>]
>>> process_one_work+0xb2f/0x1bc0 kernel/workqueue.c:2088
>>> #2: (rtnl_mutex){+.+.}, at: [<0000000053390f0b>] rtnl_lock+0x17/0x20
>>> net/core/rtnetlink.c:74
>>> 2 locks held by khungtaskd/675:
>>> #0: (rcu_read_lock){....}, at: [<00000000587c8471>]
>>> check_hung_uninterruptible_tasks kernel/hung_task.c:175 [inline]
>>> #0: (rcu_read_lock){....}, at: [<00000000587c8471>] watchdog+0x1c5/0xd60
>>> kernel/hung_task.c:249
>>> #1: (tasklist_lock){.+.+}, at: [<000000005288685e>]
>>> debug_show_all_locks+0xd3/0x400 kernel/locking/lockdep.c:4554
>>> 1 lock held by rsyslogd/2974:
>>> #0: (&f->f_pos_lock){+.+.}, at: [<0000000011e00499>]
>>> __fdget_pos+0x131/0x1a0 fs/file.c:770
>>> 2 locks held by getty/3056:
>>> #0: (&tty->ldisc_sem){++++}, at: [<00000000b9fd70a9>]
>>> ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
>>> #1: (&ldata->atomic_read_lock){+.+.}, at: [<00000000abb3bd08>]
>>> n_tty_read+0x2f2/0x1a10 drivers/tty/n_tty.c:2131
>>> 2 locks held by getty/3057:
>>> #0: (&tty->ldisc_sem){++++}, at: [<00000000b9fd70a9>]
>>> ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
>>> #1: (&ldata->atomic_read_lock){+.+.}, at: [<00000000abb3bd08>]
>>> n_tty_read+0x2f2/0x1a10 drivers/tty/n_tty.c:2131
>>> 2 locks held by getty/3058:
>>> #0: (&tty->ldisc_sem){++++}, at: [<00000000b9fd70a9>]
>>> ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
>>> #1: (&ldata->atomic_read_lock){+.+.}, at: [<00000000abb3bd08>]
>>> n_tty_read+0x2f2/0x1a10 drivers/tty/n_tty.c:2131
>>> 2 locks held by getty/3059:
>>> #0: (&tty->ldisc_sem){++++}, at: [<00000000b9fd70a9>]
>>> ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
>>> #1: (&ldata->atomic_read_lock){+.+.}, at: [<00000000abb3bd08>]
>>> n_tty_read+0x2f2/0x1a10 drivers/tty/n_tty.c:2131
>>> 2 locks held by getty/3060:
>>> #0: (&tty->ldisc_sem){++++}, at: [<00000000b9fd70a9>]
>>> ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
>>> #1: (&ldata->atomic_read_lock){+.+.}, at: [<00000000abb3bd08>]
>>> n_tty_read+0x2f2/0x1a10 drivers/tty/n_tty.c:2131
>>> 2 locks held by getty/3061:
>>> #0: (&tty->ldisc_sem){++++}, at: [<00000000b9fd70a9>]
>>> ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
>>> #1: (&ldata->atomic_read_lock){+.+.}, at: [<00000000abb3bd08>]
>>> n_tty_read+0x2f2/0x1a10 drivers/tty/n_tty.c:2131
>>> 2 locks held by getty/3062:
>>> #0: (&tty->ldisc_sem){++++}, at: [<00000000b9fd70a9>]
>>> ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
>>> #1: (&ldata->atomic_read_lock){+.+.}, at: [<00000000abb3bd08>]
>>> n_tty_read+0x2f2/0x1a10 drivers/tty/n_tty.c:2131
>>>
>>> =============================================
>>>
>>> NMI backtrace for cpu 0
>>> CPU: 0 PID: 675 Comm: khungtaskd Not tainted 4.15.0-rc2-next-20171205+ #59
>>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>>> Google 01/01/2011
>>> Call Trace:
>>> __dump_stack lib/dump_stack.c:17 [inline]
>>> dump_stack+0x194/0x257 lib/dump_stack.c:53
>>> nmi_cpu_backtrace+0x1d2/0x210 lib/nmi_backtrace.c:103
>>> nmi_trigger_cpumask_backtrace+0x122/0x180 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:138 [inline]
>>> check_hung_task kernel/hung_task.c:132 [inline]
>>> check_hung_uninterruptible_tasks kernel/hung_task.c:190 [inline]
>>> watchdog+0x90c/0xd60 kernel/hung_task.c:249
>>> kthread+0x37a/0x440 kernel/kthread.c:238
>>> ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:517
>>> Sending NMI from CPU 0 to CPUs 1:
>>> NMI backtrace for cpu 1
>>> CPU: 1 PID: 13156 Comm: syz-executor7 Not tainted 4.15.0-rc2-next-20171205+
>>> #59
>>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>>> Google 01/01/2011
>>> task: 000000005209c120 task.stack: 00000000ffaab0e8
>>> RIP: 0010:inb arch/x86/include/asm/io.h:348 [inline]
>>> RIP: 0010:io_serial_in+0x6b/0x90 drivers/tty/serial/8250/8250_port.c:434
>>> RSP: 0018:ffff8801c0a16e70 EFLAGS: 00000002
>>> RAX: dffffc0000000000 RBX: 00000000000003fd RCX: 0000000000000000
>>> RDX: 00000000000003fd RSI: ffffc90003745000 RDI: ffffffff87cf1a40
>>> RBP: ffff8801c0a16e80 R08: 0000000000000005 R09: 000000000000000c
>>> R10: 0000000000000000 R11: ffffffff8748dd20 R12: ffffffff87cf1a00
>>> R13: 0000000000000020 R14: fffffbfff0f9e387 R15: fffffbfff0f9e34a
>>> FS: 00007f6d52e3f700(0000) GS:ffff8801db500000(0000) knlGS:0000000000000000
>>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>> CR2: 000000c42005de80 CR3: 00000001c368a000 CR4: 00000000001406e0
>>> DR0: 0000000020000000 DR1: 0000000000000000 DR2: 0000000000000000
>>> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600
>>> Call Trace:
>>> serial_in drivers/tty/serial/8250/8250.h:111 [inline]
>>> wait_for_xmitr+0x93/0x1e0 drivers/tty/serial/8250/8250_port.c:2033
>>> serial8250_console_putchar+0x1f/0x60
>>> drivers/tty/serial/8250/8250_port.c:3170
>>> uart_console_write+0xac/0xe0 drivers/tty/serial/serial_core.c:1858
>>> serial8250_console_write+0x647/0xa20
>>> drivers/tty/serial/8250/8250_port.c:3236
>>> univ8250_console_write+0x5f/0x70 drivers/tty/serial/8250/8250_core.c:590
>>> call_console_drivers kernel/printk/printk.c:1574 [inline]
>>> console_unlock+0x788/0xd70 kernel/printk/printk.c:2233
>>> vprintk_emit+0x4ad/0x590 kernel/printk/printk.c:1757
>>> vprintk_default+0x28/0x30 kernel/printk/printk.c:1796
>>> vprintk_func+0x57/0xc0 kernel/printk/printk_safe.c:379
>>> printk+0xaa/0xca kernel/printk/printk.c:1829
>>> nla_parse+0x374/0x3d0 lib/nlattr.c:257
>>> nlmsg_parse include/net/netlink.h:398 [inline]
>>> nl80211_dump_wiphy_parse.isra.37.constprop.83+0x138/0x5c0
>>> net/wireless/nl80211.c:1920
>>> nl80211_dump_interface+0x596/0x820 net/wireless/nl80211.c:2660
>>> genl_lock_dumpit+0x68/0x90 net/netlink/genetlink.c:480
>>> netlink_dump+0x48c/0xce0 net/netlink/af_netlink.c:2186
>>> __netlink_dump_start+0x4f0/0x6d0 net/netlink/af_netlink.c:2283
>>> genl_family_rcv_msg+0xd27/0xfc0 net/netlink/genetlink.c:548
>>> genl_rcv_msg+0xb2/0x140 net/netlink/genetlink.c:624
>>> netlink_rcv_skb+0x216/0x440 net/netlink/af_netlink.c:2405
>>> genl_rcv+0x28/0x40 net/netlink/genetlink.c:635
>>> netlink_unicast_kernel net/netlink/af_netlink.c:1272 [inline]
>>> netlink_unicast+0x4e8/0x6f0 net/netlink/af_netlink.c:1298
>>> netlink_sendmsg+0xa4a/0xe70 net/netlink/af_netlink.c:1861
>>> sock_sendmsg_nosec net/socket.c:636 [inline]
>>> sock_sendmsg+0xca/0x110 net/socket.c:646
>>> sock_write_iter+0x320/0x5e0 net/socket.c:915
>>> call_write_iter include/linux/fs.h:1776 [inline]
>>> new_sync_write fs/read_write.c:469 [inline]
>>> __vfs_write+0x68a/0x970 fs/read_write.c:482
>>> vfs_write+0x18f/0x510 fs/read_write.c:544
>>> SYSC_write fs/read_write.c:589 [inline]
>>> SyS_write+0xef/0x220 fs/read_write.c:581
>>> entry_SYSCALL_64_fastpath+0x1f/0x96
>>> RIP: 0033:0x4529d9
>>> RSP: 002b:00007f6d52e3ec58 EFLAGS: 00000212 ORIG_RAX: 0000000000000001
>>> RAX: ffffffffffffffda RBX: 00007f6d52e3f700 RCX: 00000000004529d9
>>> RDX: 0000000000000024 RSI: 0000000020454000 RDI: 0000000000000016
>>> RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
>>> R10: 0000000000000000 R11: 0000000000000212 R12: 0000000000000000
>>> R13: 0000000000a6f7ff R14: 00007f6d52e3f9c0 R15: 0000000000000000
>>> Code: 24 d9 00 00 00 49 8d 7c 24 40 48 b8 00 00 00 00 00 fc ff df 48 89 fa
>>> 48 c1 ea 03 d3 e3 80 3c 02 00 75 17 41 03 5c 24 40 89 da ec <5b> 0f b6 c0 41
>>> 5c 5d c3 e8 38 b0 18 ff eb c2 e8 91 b0 18 ff eb
>>>
>>>
>>> ---
>>> This bug is generated by a dumb bot. It may contain errors.
>>> See https://goo.gl/tpsmEJ for details.
>>> Direct all questions to syzkaller@googlegroups.com.
>>> Please credit me with: Reported-by: syzbot <syzkaller@googlegroups.com>
>>>
>>> syzbot will keep track of this bug report.
>>> Once a fix for this bug is merged into any tree, reply to this email with:
>>> #syz fix: exact-commit-title
>>> To mark this as a duplicate of another syzbot report, please reply with:
>>> #syz dup: exact-subject-of-another-report
>>> If it's a one-off invalid bug report, please reply with:
>>> #syz invalid
>>> Note: if the crash happens again, it will cause creation of a new bug
>>> report.
>>> Note: all commands must start from beginning of the line in the email body.
>>>
>>> --
>>> 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/001a1143fd00a8cc790560b0b552%40google.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>> This looks like +rtnetlink issue.
>>
>
> Same with this one, perhaps related to / fixed by:
> http://patchwork.ozlabs.org/patch/850957/
>
Looking at the log, this one seems to be an infinite loop in SCTP code
with console output in it. Kernel is busy printing gazilion of:
[ 176.491099] sctp: sctp_transport_update_pmtu: Reported pmtu 508 too
low, using default minimum of 512
** 110 printk messages dropped **
[ 176.503409] sctp: sctp_transport_update_pmtu: Reported pmtu 508 too
low, using default minimum of 512
** 103 printk messages dropped **
...
[ 246.742374] sctp: sctp_transport_update_pmtu: Reported pmtu 508 too
low, using default minimum of 512
[ 246.742484] sctp: sctp_transport_update_pmtu: Reported pmtu 508 too
low, using default minimum of 512
[ 246.742590] sctp: sctp_transport_update_pmtu: Reported pmtu 508 too
low, using default minimum of 512
Looks like a different issue.
^ permalink raw reply
* [PATCH 3/3] tg3: Enable PHY reset in MTU change path for 5720
From: Siva Reddy Kallam @ 2017-12-22 10:35 UTC (permalink / raw)
To: davem; +Cc: netdev, michael.chan, prashant, satish.baddipadige,
Siva Reddy Kallam
In-Reply-To: <1513938929-115972-1-git-send-email-siva.kallam@broadom.com>
From: Siva Reddy Kallam <siva.kallam@broadcom.com>
A customer noticed RX path hang when MTU is changed on the fly while
running heavy traffic with NCSI enabled for 5717 and 5719. Since 5720
belongs to same ASIC family, we observed same issue and same fix
could solve this problem for 5720.
Signed-off-by: Siva Reddy Kallam <siva.kallam@broadcom.com>
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
---
drivers/net/ethernet/broadcom/tg3.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c
index a0caa71..8995cfe 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -14239,7 +14239,8 @@ static int tg3_change_mtu(struct net_device *dev, int new_mtu)
*/
if (tg3_asic_rev(tp) == ASIC_REV_57766 ||
tg3_asic_rev(tp) == ASIC_REV_5717 ||
- tg3_asic_rev(tp) == ASIC_REV_5719)
+ tg3_asic_rev(tp) == ASIC_REV_5719 ||
+ tg3_asic_rev(tp) == ASIC_REV_5720)
reset_phy = true;
err = tg3_restart_hw(tp, reset_phy);
--
2.1.0
^ permalink raw reply related
* [PATCH 2/3] tg3: Add workaround to restrict 5762 MRRS to 2048
From: Siva Reddy Kallam @ 2017-12-22 10:35 UTC (permalink / raw)
To: davem; +Cc: netdev, michael.chan, prashant, satish.baddipadige,
Siva Reddy Kallam
In-Reply-To: <1513938929-115972-1-git-send-email-siva.kallam@broadom.com>
From: Siva Reddy Kallam <siva.kallam@broadcom.com>
One of AMD based server with 5762 hangs with jumbo frame traffic.
This AMD platform has southbridge limitation which is restricting MRRS
to 4000. As a work around, driver to restricts the MRRS to 2048 for
this particular 5762 NX1 card.
Signed-off-by: Siva Reddy Kallam <siva.kallam@broadcom.com>
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
---
drivers/net/ethernet/broadcom/tg3.c | 10 ++++++++++
drivers/net/ethernet/broadcom/tg3.h | 4 ++++
2 files changed, 14 insertions(+)
diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c
index 5fe8d9b..a0caa71 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -10054,6 +10054,16 @@ static int tg3_reset_hw(struct tg3 *tp, bool reset_phy)
tw32(GRC_MODE, tp->grc_mode | val);
+ /* On one of the AMD platform, MRRS is restricted to 4000 because of
+ * south bridge limitation. As a workaround, Driver is setting MRRS
+ * to 2048 instead of default 4096.
+ */
+ if (tp->pdev->subsystem_vendor == PCI_VENDOR_ID_DELL &&
+ tp->pdev->subsystem_device == TG3PCI_SUBDEVICE_ID_DELL_5762) {
+ val = tr32(TG3PCI_DEV_STATUS_CTRL) & ~MAX_READ_REQ_MASK;
+ tw32(TG3PCI_DEV_STATUS_CTRL, val | MAX_READ_REQ_SIZE_2048);
+ }
+
/* Setup the timer prescalar register. Clock is always 66Mhz. */
val = tr32(GRC_MISC_CFG);
val &= ~0xff;
diff --git a/drivers/net/ethernet/broadcom/tg3.h b/drivers/net/ethernet/broadcom/tg3.h
index 3d60fc7..1f0271f 100644
--- a/drivers/net/ethernet/broadcom/tg3.h
+++ b/drivers/net/ethernet/broadcom/tg3.h
@@ -97,6 +97,7 @@
#define TG3PCI_SUBDEVICE_ID_DELL_JAGUAR 0x0106
#define TG3PCI_SUBDEVICE_ID_DELL_MERLOT 0x0109
#define TG3PCI_SUBDEVICE_ID_DELL_SLIM_MERLOT 0x010a
+#define TG3PCI_SUBDEVICE_ID_DELL_5762 0x07f0
#define TG3PCI_SUBVENDOR_ID_COMPAQ PCI_VENDOR_ID_COMPAQ
#define TG3PCI_SUBDEVICE_ID_COMPAQ_BANSHEE 0x007c
#define TG3PCI_SUBDEVICE_ID_COMPAQ_BANSHEE_2 0x009a
@@ -282,6 +283,9 @@
#define TG3PCI_STD_RING_PROD_IDX 0x00000098 /* 64-bit */
#define TG3PCI_RCV_RET_RING_CON_IDX 0x000000a0 /* 64-bit */
/* 0xa8 --> 0xb8 unused */
+#define TG3PCI_DEV_STATUS_CTRL 0x000000b4
+#define MAX_READ_REQ_SIZE_2048 0x00004000
+#define MAX_READ_REQ_MASK 0x00007000
#define TG3PCI_DUAL_MAC_CTRL 0x000000b8
#define DUAL_MAC_CTRL_CH_MASK 0x00000003
#define DUAL_MAC_CTRL_ID 0x00000004
--
2.1.0
^ permalink raw reply related
* [PATCH net 0/3] update on copyright and couple of fixes
From: Siva Reddy Kallam @ 2017-12-22 10:35 UTC (permalink / raw)
To: davem; +Cc: netdev, michael.chan, prashant, satish.baddipadige,
Siva Reddy Kallam
First patch:
Update copyright
Second patch:
Add workaround to restrict 5762 MRRS
Third patch:
Add PHY reset in change MTU path for 5720
Siva Reddy Kallam (3):
tg3: Update copyright
tg3: Add workaround to restrict 5762 MRRS to 2048
tg3: Enable PHY reset in MTU change path for 5720
drivers/net/ethernet/broadcom/tg3.c | 18 +++++++++++++++---
drivers/net/ethernet/broadcom/tg3.h | 7 ++++++-
2 files changed, 21 insertions(+), 4 deletions(-)
--
2.1.0
^ permalink raw reply
* [PATCH 1/3] tg3: Update copyright
From: Siva Reddy Kallam @ 2017-12-22 10:35 UTC (permalink / raw)
To: davem; +Cc: netdev, michael.chan, prashant, satish.baddipadige,
Siva Reddy Kallam
In-Reply-To: <1513938929-115972-1-git-send-email-siva.kallam@broadom.com>
From: Siva Reddy Kallam <siva.kallam@broadcom.com>
Signed-off-by: Siva Reddy Kallam <siva.kallam@broadcom.com>
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
---
drivers/net/ethernet/broadcom/tg3.c | 6 ++++--
drivers/net/ethernet/broadcom/tg3.h | 3 ++-
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c
index d09c5a9..5fe8d9b 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -4,11 +4,13 @@
* Copyright (C) 2001, 2002, 2003, 2004 David S. Miller (davem@redhat.com)
* Copyright (C) 2001, 2002, 2003 Jeff Garzik (jgarzik@pobox.com)
* Copyright (C) 2004 Sun Microsystems Inc.
- * Copyright (C) 2005-2014 Broadcom Corporation.
+ * Copyright (C) 2005-2016 Broadcom Corporation.
+ * Copyright (C) 2016-2017 Broadcom Limited.
*
* Firmware is:
* Derived from proprietary unpublished source code,
- * Copyright (C) 2000-2003 Broadcom Corporation.
+ * Copyright (C) 2000-2016 Broadcom Corporation.
+ * Copyright (C) 2016-2017 Broadcom Ltd.
*
* Permission is hereby granted for the distribution of this firmware
* data in hexadecimal or equivalent format, provided this copyright
diff --git a/drivers/net/ethernet/broadcom/tg3.h b/drivers/net/ethernet/broadcom/tg3.h
index c2d02d0..3d60fc7 100644
--- a/drivers/net/ethernet/broadcom/tg3.h
+++ b/drivers/net/ethernet/broadcom/tg3.h
@@ -5,7 +5,8 @@
* Copyright (C) 2001, 2002, 2003, 2004 David S. Miller (davem@redhat.com)
* Copyright (C) 2001 Jeff Garzik (jgarzik@pobox.com)
* Copyright (C) 2004 Sun Microsystems Inc.
- * Copyright (C) 2007-2014 Broadcom Corporation.
+ * Copyright (C) 2007-2016 Broadcom Corporation.
+ * Copyright (C) 2016-2017 Broadcom Limited.
*/
#ifndef _T3_H
--
2.1.0
^ permalink raw reply related
* Re: [PATCH net-next] ipv6: Reinject IPv6 packets if IPsec policy matches after SNAT
From: Steffen Klassert @ 2017-12-22 10:35 UTC (permalink / raw)
To: Tobias Brunner; +Cc: davem, netdev
In-Reply-To: <4aeb83c2-bd0d-8a11-39e0-18d3b7cd12ca@strongswan.org>
On Thu, Dec 21, 2017 at 05:32:24PM +0100, Tobias Brunner wrote:
> If SNAT modifies the source address the resulting packet might match
> an IPsec policy, reinject the packet if that's the case.
>
> The exact same thing is already done for IPv4.
Right, this was forgotten when IPv6 got NAT support.
Acked-by: Steffen Klassert <steffen.klassert@secunet.com>
Thanks!
^ permalink raw reply
* Re: [PATCH 1/3] net: Fix possible race in peernet2id_alloc()
From: Kirill Tkhai @ 2017-12-22 10:30 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: netdev, davem, eric.dumazet
In-Reply-To: <87ind0ou8v.fsf@xmission.com>
Hi, Eric,
On 21.12.2017 20:39, Eric W. Biederman wrote:
> Kirill Tkhai <ktkhai@virtuozzo.com> writes:
>
>> peernet2id_alloc() is racy without rtnl_lock() as atomic_read(&peer->count)
>> under net->nsid_lock does not guarantee, peer is alive:
>>
>> rcu_read_lock()
>> peernet2id_alloc() ..
>> spin_lock_bh(&net->nsid_lock) ..
>> atomic_read(&peer->count) == 1 ..
>> .. put_net()
>> .. cleanup_net()
>> .. for_each_net(tmp)
>> .. spin_lock_bh(&tmp->nsid_lock)
>> .. __peernet2id(tmp, net) == -1
>> .. ..
>> .. ..
>> __peernet2id_alloc(alloc == true) ..
>> .. ..
>> rcu_read_unlock() ..
>> .. synchronize_rcu()
>> .. kmem_cache_free(net)
>>
>> After the above situation, net::netns_id contains id pointing to freed memory,
>> and any other dereferencing by the id will operate with this freed memory.
>>
>> Currently, peernet2id_alloc() is used under rtnl_lock() everywhere except
>> ovs_vport_cmd_fill_info(), and this race can't occur. But peernet2id_alloc()
>> is generic interface, and better we fix it before someone really starts
>> use it in wrong context.
>
> So it comes down to this piece of code from ovs and just let me say ick.
> if (!net_eq(net, dev_net(vport->dev))) {
> int id = peernet2id_alloc(net, dev_net(vport->dev));
>
> if (nla_put_s32(skb, OVS_VPORT_ATTR_NETNSID, id))
> goto nla_put_failure;
> }
>
> Without the rtnl lock dev_net can cange between the test and the
> call of peernet2id_alloc.
The places like this are usually protected via netdevice notifier. There is
ovs_dp_device_notifier in openvswitch and it seems to be a handler for
the situation above. But I'm not sure it's safe, and it's not clear for
me why it does not take ovl_mutex to synchronize with ovs_vport_cmd_fill_info(),
and whether there is another synchronization.
> At first glance it looks like the bug is that we are running a control
> path of the networking stack without the rtnl lock. So it may be that
> ASSERT_RTNL() is the better fix.
Do you mean inserting ASSERT_RTNL() into peernet2id_alloc()?
If so, it's not need, as all nsid are protected via separate lock starting from
commit 95f38411df05 "netns: use a spin_lock to protect nsid management"
and commit de133464c9e7 "netns: make nsid_lock per net".
nsid primitives are aimed to be safe without respect to rtnl_lock().
My patch just adds some sanity checks to make them more safe.
> Given that it would be nice to reduce the scope of the rtnl lock this
> might not be a bad direction. Let me see.
>> Is rtnl_notify safe without the rtnl lock?
It seems they have to be safe, as there is only sending a skb to netlink.
rtnl_notify() is used without rtnl_lock() in most other places of net code.
The only reason rtnl_lock() is needed in cleanup_net() is we unlink net from the list.
rtnl_lock() around nsid cleanup is leftover after nsid are made protected via
separate lock. So we may relax rtnl_lock() in cleanup_net() and I'm going to do that
in one of next patches (not yet sent).
>>
>> Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
>> ---
>> net/core/net_namespace.c | 23 +++++++++++++++++++----
>> 1 file changed, 19 insertions(+), 4 deletions(-)
>>
>> diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
>> index 60a71be75aea..6a4eab438221 100644
>> --- a/net/core/net_namespace.c
>> +++ b/net/core/net_namespace.c
>> @@ -221,17 +221,32 @@ static void rtnl_net_notifyid(struct net *net, int cmd, int id);
>> */
>> int peernet2id_alloc(struct net *net, struct net *peer)
>> {
>> - bool alloc;
>> + bool alloc = false, alive = false;
>> int id;
>
> ^^^ Perhaps we want "ASSERT_RTNL();" here?
>>
>> - if (atomic_read(&net->count) == 0)
>> - return NETNSA_NSID_NOT_ASSIGNED;
>
> Moving this hunk is of no benefit. The code must be called with a valid
> reference to net. Which means net->count is a fancy way of testing to
> see if the code is in cleanup_net. In all other cases net->count should
> be non-zero and it should remain that way because of our caller must
> keep a reference.
Let me discuss about this.
This interface is exported to drivers, and they don't always follow the rules
about what is allowed or disallowed. This hunk adds sanity checks, which
protects us from bad drivers code etc. Some people want to use peernet2id_alloc()
in generic functions, which may be called in different context (also, for net
obtained from rcu list). Instead of every user makes such a test in its function,
this hunks introduces generic valid check, which allows people do not insert n+1
their own checks.
Also, unlocked check does not give performance advantages as later we take the lock
*almost always*. So, my suggestion is to make peernet2id_alloc() more safe for
end user.
>> spin_lock_bh(&net->nsid_lock);
>> - alloc = atomic_read(&peer->count) == 0 ? false : true;
>> + /* Spinlock guarantees we never hash a peer to net->netns_ids
>> + * after idr_destroy(&net->netns_ids) occurs in cleanup_net().
>> + */
>> + if (atomic_read(&net->count) == 0) {
>> + id = NETNSA_NSID_NOT_ASSIGNED;
>> + goto unlock;
>> + }
>> + /*
>> + * When peer is obtained from RCU lists, we may race with
>> + * its cleanup. Check whether it's alive, and this guarantees
>> + * we never hash a peer back to net->netns_ids, after it has
>> + * just been idr_remove()'d from there in cleanup_net().
>> + */
>> + if (maybe_get_net(peer))
>> + alive = alloc = true;
>
> Yes this does seem reasonable. The more obvious looking code which
> would return NETNSA_NSID_NOT_ASSIGNED if the peer has a count of 0, is
> silly as it makes would make it appear that a peer is momentary outside
> of a network namespace when the peer is in fact moving from one network
> namespace to another.
>
>> id = __peernet2id_alloc(net, peer, &alloc);
>> +unlock:
>> spin_unlock_bh(&net->nsid_lock);
>> if (alloc && id >= 0)
>> rtnl_net_notifyid(net, RTM_NEWNSID, id);
> ^^^^^^
> Is this safe without the rtnl lock?
Yes, it seems to be safe. Please, look above.
>> + if (alive)
>> + put_net(peer);
>> return id;
>> }
>> EXPORT_SYMBOL_GPL(peernet2id_alloc);
Kirill
^ permalink raw reply
* Re: [Patch net] net_sched: fix a missing rcu barrier in mini_qdisc_pair_swap()
From: Jiri Pirko @ 2017-12-22 10:24 UTC (permalink / raw)
To: Cong Wang; +Cc: netdev, Jiri Pirko, John Fastabend
In-Reply-To: <20171221072624.6204-1-xiyou.wangcong@gmail.com>
Thu, Dec 21, 2017 at 08:26:24AM CET, xiyou.wangcong@gmail.com wrote:
>The rcu_barrier_bh() in mini_qdisc_pair_swap() is to wait for
>flying RCU callback installed by a previous mini_qdisc_pair_swap(),
>however we miss it on the tp_head==NULL path, which leads to that
>the RCU callback still uses miniq_old->rcu after it is freed together
>with qdisc in qdisc_graft(). So just add it on that path too.
>
>Fixes: 46209401f8f6 ("net: core: introduce mini_Qdisc and eliminate usage of tp->q for clsact fastpath ")
>Reported-by: Jakub Kicinski <jakub.kicinski@netronome.com>
>Tested-by: Jakub Kicinski <jakub.kicinski@netronome.com>
>Cc: Jiri Pirko <jiri@mellanox.com>
>Cc: John Fastabend <john.fastabend@gmail.com>
>Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
^ permalink raw reply
* Re: [Patch net] net_sched: fix a missing rcu barrier in mini_qdisc_pair_swap()
From: Jiri Pirko @ 2017-12-22 10:23 UTC (permalink / raw)
To: Cong Wang; +Cc: Linux Kernel Network Developers, Jiri Pirko, John Fastabend
In-Reply-To: <CAM_iQpVfYUsJ6D5fpE+Ng8wGxK6uoN3PRntYO_Y0j+7YRKdSqg@mail.gmail.com>
Thu, Dec 21, 2017 at 08:01:35PM CET, xiyou.wangcong@gmail.com wrote:
>On Thu, Dec 21, 2017 at 1:03 AM, Jiri Pirko <jiri@resnulli.us> wrote:
>> Thu, Dec 21, 2017 at 08:26:24AM CET, xiyou.wangcong@gmail.com wrote:
[...]
>
>
>Seriously? It is this call_rcu still flying after we free the qdisc.
>Did you seriously look into the stack trace from Jakub?
Got it now. You are right. Thank you for politely helping me to get out
of my confusion.
^ permalink raw reply
* Re: [PATCH RFC 18/18] r8168: use link speed information as maintained by phylib
From: Andrew Lunn @ 2017-12-22 10:22 UTC (permalink / raw)
To: Heiner Kallweit
Cc: Realtek linux nic maintainers, Chun-Hao Lin, David Miller,
netdev@vger.kernel.org
In-Reply-To: <98e89d73-7d9d-61f6-f3be-ea53b557b7b0@gmail.com>
On Thu, Dec 21, 2017 at 09:50:55PM +0100, Heiner Kallweit wrote:
> Let's use the speed information as maintained by phylib instead of
> reading it directly from a register.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH RFC 17/18] r8168: remove use of struct mii_if_info
From: Andrew Lunn @ 2017-12-22 10:21 UTC (permalink / raw)
To: Heiner Kallweit
Cc: Realtek linux nic maintainers, Chun-Hao Lin, David Miller,
netdev@vger.kernel.org
In-Reply-To: <335edd3a-0956-72c9-dbf2-4dfb992c69f7@gmail.com>
On Thu, Dec 21, 2017 at 09:50:52PM +0100, Heiner Kallweit wrote:
> @@ -1188,21 +1188,6 @@ static void rtl_w0w1_phy(struct rtl8168_private *tp, int reg_addr, int p, int m)
> rtl_writephy(tp, reg_addr, (val & ~m) | p);
> }
>
> -static void rtl_mdio_write(struct net_device *dev, int phy_id, int location,
> - int val)
> -{
> - struct rtl8168_private *tp = netdev_priv(dev);
> -
> - rtl_writephy(tp, location, val);
> -}
> -
> -static int rtl_mdio_read(struct net_device *dev, int phy_id, int location)
> -{
> - struct rtl8168_private *tp = netdev_priv(dev);
> -
> - return rtl_readphy(tp, location);
> -}
Hi Heiner
With these two gone, it would be nice to rename r8168_mdio_read_reg()
and r8168_mdio_write_reg() to rtl_mdio_read() and rtl_mdio_write().
Andrew
^ permalink raw reply
* Re: [PATCH RFC 13/18] r8168: replace speed_down with genphy_restart_aneg
From: Andrew Lunn @ 2017-12-22 10:14 UTC (permalink / raw)
To: Heiner Kallweit
Cc: Realtek linux nic maintainers, Chun-Hao Lin, David Miller,
netdev@vger.kernel.org
In-Reply-To: <704cc35b-d54a-4220-2a24-dec9521e05af@gmail.com>
On Thu, Dec 21, 2017 at 09:50:39PM +0100, Heiner Kallweit wrote:
> Dealing with link partner abilities is handled by phylib, so let's
> just trigger autonegotiation here.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
> ---
> drivers/net/ethernet/realtek/r8168.c | 26 +-------------------------
> 1 file changed, 1 insertion(+), 25 deletions(-)
>
> diff --git a/drivers/net/ethernet/realtek/r8168.c b/drivers/net/ethernet/realtek/r8168.c
> index d33f93a31..6b398915f 100644
> --- a/drivers/net/ethernet/realtek/r8168.c
> +++ b/drivers/net/ethernet/realtek/r8168.c
> @@ -4360,30 +4360,6 @@ static void rtl_init_mdio_ops(struct rtl8168_private *tp)
> }
> }
>
> -static void rtl_speed_down(struct rtl8168_private *tp)
> -{
> - u32 adv;
> - int lpa;
> -
> - rtl_writephy(tp, 0x1f, 0x0000);
> - lpa = rtl_readphy(tp, MII_LPA);
> -
> - if (lpa & (LPA_10HALF | LPA_10FULL))
> - adv = ADVERTISED_10baseT_Half | ADVERTISED_10baseT_Full;
> - else if (lpa & (LPA_100HALF | LPA_100FULL))
> - adv = ADVERTISED_10baseT_Half | ADVERTISED_10baseT_Full |
> - ADVERTISED_100baseT_Half | ADVERTISED_100baseT_Full;
> - else
> - adv = ADVERTISED_10baseT_Half | ADVERTISED_10baseT_Full |
> - ADVERTISED_100baseT_Half | ADVERTISED_100baseT_Full |
> - (tp->mii.supports_gmii ?
> - ADVERTISED_1000baseT_Half |
> - ADVERTISED_1000baseT_Full : 0);
> -
> - rtl8168_set_speed(tp->dev, AUTONEG_ENABLE, SPEED_1000, DUPLEX_FULL,
> - adv);
> -}
> -
> static void rtl_wol_suspend_quirk(struct rtl8168_private *tp)
> {
> void __iomem *ioaddr = tp->mmio_addr;
> @@ -4424,7 +4400,7 @@ static bool rtl_wol_pll_power_down(struct rtl8168_private *tp)
> if (!(__rtl8168_get_wol(tp) & WAKE_ANY))
> return false;
>
> - rtl_speed_down(tp);
> + genphy_restart_aneg(tp->dev->phydev);
> rtl_wol_suspend_quirk(tp);
>
> return true;
I'm not too clear what is going on here? Is this suspend while WOL is
enabled? There should be no need to change the PHY settings. The PHY
driver should leave the PHY running in whatever state it was
configured to. The only danger here is that the MAC driver has called
phy_stop() during suspend. That should not be done when WOL is
enabled.
Is the wol being passed to the phylib? phy_ethtool_set_wol() and
phy_ethtool_get_wol()?
Andrew
^ permalink raw reply
* [PATCH net-next] phylib: rename reset-(post-)delay-us to reset-(de)assert-us
From: Richard Leitner @ 2017-12-22 10:08 UTC (permalink / raw)
To: robh+dt, mark.rutland, andrew, f.fainelli, frowand.list
Cc: davem, richard.leitner, geert+renesas, lukma, sergei.shtylyov,
martin.blumenstingl, david.wu, baruch, devicetree, netdev,
linux-kernel
From: Richard Leitner <richard.leitner@skidata.com>
As suggested by Rob Herring [1] rename the previously introduced
reset-{,post-}delay-us bindings to the clearer reset-{,de}assert-us
[1] https://patchwork.kernel.org/patch/10104905/
Signed-off-by: Richard Leitner <richard.leitner@skidata.com>
---
Documentation/devicetree/bindings/net/phy.txt | 8 ++++----
drivers/net/phy/mdio_device.c | 2 +-
drivers/of/of_mdio.c | 7 ++++---
include/linux/mdio.h | 4 ++--
4 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/phy.txt b/Documentation/devicetree/bindings/net/phy.txt
index 72860ce7f610..d2169a56f5e3 100644
--- a/Documentation/devicetree/bindings/net/phy.txt
+++ b/Documentation/devicetree/bindings/net/phy.txt
@@ -55,10 +55,10 @@ Optional Properties:
- reset-gpios: The GPIO phandle and specifier for the PHY reset signal.
-- reset-delay-us: Delay after the reset was asserted in microseconds.
+- reset-assert-us: Delay after the reset was asserted in microseconds.
If this property is missing the delay will be skipped.
-- reset-post-delay-us: Delay after the reset was deasserted in microseconds.
+- reset-deassert-us: Delay after the reset was deasserted in microseconds.
If this property is missing the delay will be skipped.
Example:
@@ -70,6 +70,6 @@ ethernet-phy@0 {
reg = <0>;
reset-gpios = <&gpio1 4 GPIO_ACTIVE_LOW>;
- reset-delay-us = <1000>;
- reset-post-delay-us = <2000>;
+ reset-assert-us = <1000>;
+ reset-deassert-us = <2000>;
};
diff --git a/drivers/net/phy/mdio_device.c b/drivers/net/phy/mdio_device.c
index 843c1dde93e4..c924700cf37b 100644
--- a/drivers/net/phy/mdio_device.c
+++ b/drivers/net/phy/mdio_device.c
@@ -126,7 +126,7 @@ void mdio_device_reset(struct mdio_device *mdiodev, int value)
gpiod_set_value(mdiodev->reset, value);
- d = value ? mdiodev->reset_delay : mdiodev->reset_post_delay;
+ d = value ? mdiodev->reset_assert_delay : mdiodev->reset_deassert_delay;
if (d)
usleep_range(d, d + max_t(unsigned int, d / 10, 100));
}
diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
index f4c73292b304..1b9ef35cf0d9 100644
--- a/drivers/of/of_mdio.c
+++ b/drivers/of/of_mdio.c
@@ -77,9 +77,10 @@ static int of_mdiobus_register_phy(struct mii_bus *mdio,
if (of_property_read_bool(child, "broken-turn-around"))
mdio->phy_ignore_ta_mask |= 1 << addr;
- of_property_read_u32(child, "reset-delay-us", &phy->mdio.reset_delay);
- of_property_read_u32(child, "reset-post-delay-us",
- &phy->mdio.reset_post_delay);
+ of_property_read_u32(child, "reset-assert-us",
+ &phy->mdio.reset_assert_delay);
+ of_property_read_u32(child, "reset-deassert-us",
+ &phy->mdio.reset_deassert_delay);
/* Associate the OF node with the device structure so it
* can be looked up later */
diff --git a/include/linux/mdio.h b/include/linux/mdio.h
index e37c21d8eb19..268aad47ecd3 100644
--- a/include/linux/mdio.h
+++ b/include/linux/mdio.h
@@ -41,8 +41,8 @@ struct mdio_device {
int addr;
int flags;
struct gpio_desc *reset;
- unsigned int reset_delay;
- unsigned int reset_post_delay;
+ unsigned int reset_assert_delay;
+ unsigned int reset_deassert_delay;
};
#define to_mdio_device(d) container_of(d, struct mdio_device, dev)
--
2.11.0
^ permalink raw reply related
* Re: [PATCH RFC 12/18] r8168: switch to phy_mii_ioctl
From: Andrew Lunn @ 2017-12-22 10:00 UTC (permalink / raw)
To: Heiner Kallweit
Cc: Realtek linux nic maintainers, Chun-Hao Lin, David Miller,
netdev@vger.kernel.org
In-Reply-To: <b0618215-d3b7-5b65-1485-9634b74e0ac2@gmail.com>
> static int rtl8168_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
> {
> - struct rtl8168_private *tp = netdev_priv(dev);
> - struct mii_ioctl_data *data = if_mii(ifr);
> + if (!netif_running(dev))
> + return -ENODEV;
It is sometimes useful to be able to prod and poke the PHY when the
MAC is not running. Is this limit because of power saving?
Otherwise, this patch looks good.
Thanks
Andrew
^ permalink raw reply
* Re: [PATCH RFC 11/18] r8168: switch to phy_ethtool_nway_reset
From: Andrew Lunn @ 2017-12-22 9:58 UTC (permalink / raw)
To: Heiner Kallweit
Cc: Realtek linux nic maintainers, Chun-Hao Lin, David Miller,
netdev@vger.kernel.org
In-Reply-To: <4af35668-a944-a1d1-3b3e-6b8a36ff561b@gmail.com>
On Thu, Dec 21, 2017 at 09:50:34PM +0100, Heiner Kallweit wrote:
> Switch to phy_ethtool_nway_reset.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net-next] qed*: Utilize FW 8.33.1.0
From: kbuild test robot @ 2017-12-22 9:57 UTC (permalink / raw)
To: Tomer Tayar
Cc: kbuild-all, davem, netdev, linux-rdma, linux-scsi, Tomer Tayar,
Ariel Elior, Michal Kalderon, Yuval Bason, Ram Amrani,
Manish Chopra, Chad Dupuis, Manish Rangankar
In-Reply-To: <1513692323-26684-1-git-send-email-Tomer.Tayar@cavium.com>
[-- Attachment #1: Type: text/plain, Size: 1412 bytes --]
Hi Tomer,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on net-next/master]
url: https://github.com/0day-ci/linux/commits/Tomer-Tayar/qed-Utilize-FW-8-33-1-0/20171221-180506
config: x86_64-randconfig-s0-12221644 (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
In file included from drivers/net/ethernet/qlogic/qed/qed_sp_commands.c:48:0:
>> drivers/net/ethernet/qlogic/qed/qed_sriov.h:464:1: error: static declaration of 'qed_iov_is_valid_vfid' follows non-static declaration
qed_iov_is_valid_vfid(struct qed_hwfn *p_hwfn,
^~~~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/qlogic/qed/qed_sriov.h:144:6: note: previous declaration of 'qed_iov_is_valid_vfid' was here
bool qed_iov_is_valid_vfid(struct qed_hwfn *p_hwfn,
^~~~~~~~~~~~~~~~~~~~~
vim +/qed_iov_is_valid_vfid +464 drivers/net/ethernet/qlogic/qed/qed_sriov.h
462
463 static inline bool
> 464 qed_iov_is_valid_vfid(struct qed_hwfn *p_hwfn,
465 int rel_vf_id, bool b_enabled_only, bool b_non_malicious)
466 {
467 return false;
468 }
469 #endif
470
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 29104 bytes --]
^ permalink raw reply
* Re: [PATCH RFC 10/18] r8168: switch to phy_ethtool_get/set_link_ksettings
From: Andrew Lunn @ 2017-12-22 9:57 UTC (permalink / raw)
To: Heiner Kallweit
Cc: Realtek linux nic maintainers, Chun-Hao Lin, David Miller,
netdev@vger.kernel.org
In-Reply-To: <b9009707-a953-b35d-31db-26a209e290fd@gmail.com>
On Thu, Dec 21, 2017 at 09:50:31PM +0100, Heiner Kallweit wrote:
> Use phy_ethtool_get/set_link_ksettings instead of open coding these
> ethtool ops.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH RFC 09/18] r8168: use genphy_soft_reset instead of open coding the soft reset
From: Andrew Lunn @ 2017-12-22 9:57 UTC (permalink / raw)
To: Heiner Kallweit
Cc: Realtek linux nic maintainers, Chun-Hao Lin, David Miller,
netdev@vger.kernel.org
In-Reply-To: <13598591-49fe-0020-443e-9d6cedb53cfb@gmail.com>
On Thu, Dec 21, 2017 at 09:50:28PM +0100, Heiner Kallweit wrote:
> Use genphy_soft_reset instead of open coding the soft reset.
Hi Heiner
At this point, you have swapped over the phylib. Does one of the
drivers in drivers/net/phy now take control of the PHY? Does the PHY
ID match one of those in realtek.c?
The PHY driver and phylib should be responsible for resetting the
PHY. The MAC driver should not need to do this.
Andrew
^ permalink raw reply
* Re: [PATCH ipsec-next] xfrm: update the stats documentation
From: Steffen Klassert @ 2017-12-22 9:48 UTC (permalink / raw)
To: Shannon Nelson; +Cc: netdev
In-Reply-To: <1513895178-30226-1-git-send-email-shannon.nelson@oracle.com>
On Thu, Dec 21, 2017 at 02:26:18PM -0800, Shannon Nelson wrote:
> Add a couple of stats that aren't in the documentation file
> and rework the top description to be a little more readable.
>
> Signed-off-by: Shannon Nelson <shannon.nelson@oracle.com>
Applied to ipsec-next, thanks Shannon!
^ permalink raw reply
* [PATCH 8/8] xfrm: Reinject transport-mode packets through tasklet
From: Steffen Klassert @ 2017-12-22 9:45 UTC (permalink / raw)
To: David Miller; +Cc: Herbert Xu, Steffen Klassert, netdev
In-Reply-To: <20171222094501.23345-1-steffen.klassert@secunet.com>
From: Herbert Xu <herbert@gondor.apana.org.au>
This is an old bugbear of mine:
https://www.mail-archive.com/netdev@vger.kernel.org/msg03894.html
By crafting special packets, it is possible to cause recursion
in our kernel when processing transport-mode packets at levels
that are only limited by packet size.
The easiest one is with DNAT, but an even worse one is where
UDP encapsulation is used in which case you just have to insert
an UDP encapsulation header in between each level of recursion.
This patch avoids this problem by reinjecting tranport-mode packets
through a tasklet.
Fixes: b05e106698d9 ("[IPV4/6]: Netfilter IPsec input hooks")
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
include/net/xfrm.h | 3 +++
net/ipv4/xfrm4_input.c | 12 ++++++++++-
net/ipv6/xfrm6_input.c | 10 ++++++++-
net/xfrm/xfrm_input.c | 57 ++++++++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 80 insertions(+), 2 deletions(-)
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index dc28a98ce97c..ae35991b5877 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -1570,6 +1570,9 @@ int xfrm_init_state(struct xfrm_state *x);
int xfrm_prepare_input(struct xfrm_state *x, struct sk_buff *skb);
int xfrm_input(struct sk_buff *skb, int nexthdr, __be32 spi, int encap_type);
int xfrm_input_resume(struct sk_buff *skb, int nexthdr);
+int xfrm_trans_queue(struct sk_buff *skb,
+ int (*finish)(struct net *, struct sock *,
+ struct sk_buff *));
int xfrm_output_resume(struct sk_buff *skb, int err);
int xfrm_output(struct sock *sk, struct sk_buff *skb);
int xfrm_inner_extract_output(struct xfrm_state *x, struct sk_buff *skb);
diff --git a/net/ipv4/xfrm4_input.c b/net/ipv4/xfrm4_input.c
index e50b7fea57ee..bcfc00e88756 100644
--- a/net/ipv4/xfrm4_input.c
+++ b/net/ipv4/xfrm4_input.c
@@ -23,6 +23,12 @@ int xfrm4_extract_input(struct xfrm_state *x, struct sk_buff *skb)
return xfrm4_extract_header(skb);
}
+static int xfrm4_rcv_encap_finish2(struct net *net, struct sock *sk,
+ struct sk_buff *skb)
+{
+ return dst_input(skb);
+}
+
static inline int xfrm4_rcv_encap_finish(struct net *net, struct sock *sk,
struct sk_buff *skb)
{
@@ -33,7 +39,11 @@ static inline int xfrm4_rcv_encap_finish(struct net *net, struct sock *sk,
iph->tos, skb->dev))
goto drop;
}
- return dst_input(skb);
+
+ if (xfrm_trans_queue(skb, xfrm4_rcv_encap_finish2))
+ goto drop;
+
+ return 0;
drop:
kfree_skb(skb);
return NET_RX_DROP;
diff --git a/net/ipv6/xfrm6_input.c b/net/ipv6/xfrm6_input.c
index fe04e23af986..841f4a07438e 100644
--- a/net/ipv6/xfrm6_input.c
+++ b/net/ipv6/xfrm6_input.c
@@ -32,6 +32,14 @@ int xfrm6_rcv_spi(struct sk_buff *skb, int nexthdr, __be32 spi,
}
EXPORT_SYMBOL(xfrm6_rcv_spi);
+static int xfrm6_transport_finish2(struct net *net, struct sock *sk,
+ struct sk_buff *skb)
+{
+ if (xfrm_trans_queue(skb, ip6_rcv_finish))
+ __kfree_skb(skb);
+ return -1;
+}
+
int xfrm6_transport_finish(struct sk_buff *skb, int async)
{
struct xfrm_offload *xo = xfrm_offload(skb);
@@ -56,7 +64,7 @@ int xfrm6_transport_finish(struct sk_buff *skb, int async)
NF_HOOK(NFPROTO_IPV6, NF_INET_PRE_ROUTING,
dev_net(skb->dev), NULL, skb, skb->dev, NULL,
- ip6_rcv_finish);
+ xfrm6_transport_finish2);
return -1;
}
diff --git a/net/xfrm/xfrm_input.c b/net/xfrm/xfrm_input.c
index da6447389ffb..3f6f6f8c9fa5 100644
--- a/net/xfrm/xfrm_input.c
+++ b/net/xfrm/xfrm_input.c
@@ -8,15 +8,29 @@
*
*/
+#include <linux/bottom_half.h>
+#include <linux/interrupt.h>
#include <linux/slab.h>
#include <linux/module.h>
#include <linux/netdevice.h>
+#include <linux/percpu.h>
#include <net/dst.h>
#include <net/ip.h>
#include <net/xfrm.h>
#include <net/ip_tunnels.h>
#include <net/ip6_tunnel.h>
+struct xfrm_trans_tasklet {
+ struct tasklet_struct tasklet;
+ struct sk_buff_head queue;
+};
+
+struct xfrm_trans_cb {
+ int (*finish)(struct net *net, struct sock *sk, struct sk_buff *skb);
+};
+
+#define XFRM_TRANS_SKB_CB(__skb) ((struct xfrm_trans_cb *)&((__skb)->cb[0]))
+
static struct kmem_cache *secpath_cachep __read_mostly;
static DEFINE_SPINLOCK(xfrm_input_afinfo_lock);
@@ -25,6 +39,8 @@ static struct xfrm_input_afinfo const __rcu *xfrm_input_afinfo[AF_INET6 + 1];
static struct gro_cells gro_cells;
static struct net_device xfrm_napi_dev;
+static DEFINE_PER_CPU(struct xfrm_trans_tasklet, xfrm_trans_tasklet);
+
int xfrm_input_register_afinfo(const struct xfrm_input_afinfo *afinfo)
{
int err = 0;
@@ -477,9 +493,41 @@ int xfrm_input_resume(struct sk_buff *skb, int nexthdr)
}
EXPORT_SYMBOL(xfrm_input_resume);
+static void xfrm_trans_reinject(unsigned long data)
+{
+ struct xfrm_trans_tasklet *trans = (void *)data;
+ struct sk_buff_head queue;
+ struct sk_buff *skb;
+
+ __skb_queue_head_init(&queue);
+ skb_queue_splice_init(&trans->queue, &queue);
+
+ while ((skb = __skb_dequeue(&queue)))
+ XFRM_TRANS_SKB_CB(skb)->finish(dev_net(skb->dev), NULL, skb);
+}
+
+int xfrm_trans_queue(struct sk_buff *skb,
+ int (*finish)(struct net *, struct sock *,
+ struct sk_buff *))
+{
+ struct xfrm_trans_tasklet *trans;
+
+ trans = this_cpu_ptr(&xfrm_trans_tasklet);
+
+ if (skb_queue_len(&trans->queue) >= netdev_max_backlog)
+ return -ENOBUFS;
+
+ XFRM_TRANS_SKB_CB(skb)->finish = finish;
+ skb_queue_tail(&trans->queue, skb);
+ tasklet_schedule(&trans->tasklet);
+ return 0;
+}
+EXPORT_SYMBOL(xfrm_trans_queue);
+
void __init xfrm_input_init(void)
{
int err;
+ int i;
init_dummy_netdev(&xfrm_napi_dev);
err = gro_cells_init(&gro_cells, &xfrm_napi_dev);
@@ -490,4 +538,13 @@ void __init xfrm_input_init(void)
sizeof(struct sec_path),
0, SLAB_HWCACHE_ALIGN|SLAB_PANIC,
NULL);
+
+ for_each_possible_cpu(i) {
+ struct xfrm_trans_tasklet *trans;
+
+ trans = &per_cpu(xfrm_trans_tasklet, i);
+ __skb_queue_head_init(&trans->queue);
+ tasklet_init(&trans->tasklet, xfrm_trans_reinject,
+ (unsigned long)trans);
+ }
}
--
2.14.1
^ permalink raw reply related
* [PATCH 7/8] xfrm: put policies when reusing pcpu xdst entry
From: Steffen Klassert @ 2017-12-22 9:45 UTC (permalink / raw)
To: David Miller; +Cc: Herbert Xu, Steffen Klassert, netdev
In-Reply-To: <20171222094501.23345-1-steffen.klassert@secunet.com>
From: Florian Westphal <fw@strlen.de>
We need to put the policies when re-using the pcpu xdst entry, else
this leaks the reference.
Fixes: ec30d78c14a813db39a647b6a348b428 ("xfrm: add xdst pcpu cache")
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
net/xfrm/xfrm_policy.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
index 038ec68f6901..70aa5cb0c659 100644
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -1839,6 +1839,7 @@ xfrm_resolve_and_create_bundle(struct xfrm_policy **pols, int num_pols,
sizeof(struct xfrm_policy *) * num_pols) == 0 &&
xfrm_xdst_can_reuse(xdst, xfrm, err)) {
dst_hold(&xdst->u.dst);
+ xfrm_pols_put(pols, num_pols);
while (err > 0)
xfrm_state_put(xfrm[--err]);
return xdst;
--
2.14.1
^ permalink raw reply related
* [PATCH 3/8] xfrm: Fix xfrm_input() to verify state is valid when (encap_type < 0)
From: Steffen Klassert @ 2017-12-22 9:44 UTC (permalink / raw)
To: David Miller; +Cc: Herbert Xu, Steffen Klassert, netdev
In-Reply-To: <20171222094501.23345-1-steffen.klassert@secunet.com>
From: Aviv Heller <avivh@mellanox.com>
Code path when (encap_type < 0) does not verify the state is valid
before progressing.
This will result in a crash if, for instance, x->km.state ==
XFRM_STATE_ACQ.
Fixes: 7785bba299a8 ("esp: Add a software GRO codepath")
Signed-off-by: Aviv Heller <avivh@mellanox.com>
Signed-off-by: Yevgeny Kliteynik <kliteyn@mellanox.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
net/xfrm/xfrm_input.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/net/xfrm/xfrm_input.c b/net/xfrm/xfrm_input.c
index 347ab31574d5..da6447389ffb 100644
--- a/net/xfrm/xfrm_input.c
+++ b/net/xfrm/xfrm_input.c
@@ -207,7 +207,7 @@ int xfrm_input(struct sk_buff *skb, int nexthdr, __be32 spi, int encap_type)
xfrm_address_t *daddr;
struct xfrm_mode *inner_mode;
u32 mark = skb->mark;
- unsigned int family;
+ unsigned int family = AF_UNSPEC;
int decaps = 0;
int async = 0;
bool xfrm_gro = false;
@@ -216,6 +216,16 @@ int xfrm_input(struct sk_buff *skb, int nexthdr, __be32 spi, int encap_type)
if (encap_type < 0) {
x = xfrm_input_state(skb);
+
+ if (unlikely(x->km.state != XFRM_STATE_VALID)) {
+ if (x->km.state == XFRM_STATE_ACQ)
+ XFRM_INC_STATS(net, LINUX_MIB_XFRMACQUIREERROR);
+ else
+ XFRM_INC_STATS(net,
+ LINUX_MIB_XFRMINSTATEINVALID);
+ goto drop;
+ }
+
family = x->outer_mode->afinfo->family;
/* An encap_type of -1 indicates async resumption. */
--
2.14.1
^ 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