<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/net, branch v4.9.82</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>b43: Add missing MODULE_FIRMWARE()</title>
<updated>2018-02-13T11:35:57+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2017-05-04T09:27:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=0a01ecbd23a9547b60b1a1d7e83f60704b176925'/>
<id>0a01ecbd23a9547b60b1a1d7e83f60704b176925</id>
<content type='text'>
commit 3c89a72ad80c64bdbd5ff851ee9c328a191f7e01 upstream.

Some firmware entries were forgotten to be added via MODULE_FIRMWARE(), which
may result in the non-functional state when the driver is loaded in initrd.

Link: http://bugzilla.opensuse.org/show_bug.cgi?id=1037344
Fixes: 15be8e89cdd9 ("b43: add more bcma cores")
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 3c89a72ad80c64bdbd5ff851ee9c328a191f7e01 upstream.

Some firmware entries were forgotten to be added via MODULE_FIRMWARE(), which
may result in the non-functional state when the driver is loaded in initrd.

Link: http://bugzilla.opensuse.org/show_bug.cgi?id=1037344
Fixes: 15be8e89cdd9 ("b43: add more bcma cores")
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>r8169: fix RTL8168EP take too long to complete driver initialization.</title>
<updated>2018-02-13T11:35:56+00:00</updated>
<author>
<name>Chunhao Lin</name>
<email>hau@realtek.com</email>
</author>
<published>2018-01-30T17:32:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=5db5cabbf09dd793bf42e65cea9abe66fad62c13'/>
<id>5db5cabbf09dd793bf42e65cea9abe66fad62c13</id>
<content type='text'>
[ Upstream commit 086ca23d03c0d2f4088f472386778d293e15c5f6 ]

Driver check the wrong register bit in rtl_ocp_tx_cond() that keep driver
waiting until timeout.

Fix this by waiting for the right register bit.

Signed-off-by: Chunhao Lin &lt;hau@realtek.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 086ca23d03c0d2f4088f472386778d293e15c5f6 ]

Driver check the wrong register bit in rtl_ocp_tx_cond() that keep driver
waiting until timeout.

Fix this by waiting for the right register bit.

Signed-off-by: Chunhao Lin &lt;hau@realtek.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>qmi_wwan: Add support for Quectel EP06</title>
<updated>2018-02-13T11:35:56+00:00</updated>
<author>
<name>Kristian Evensen</name>
<email>kristian.evensen@gmail.com</email>
</author>
<published>2018-01-30T13:12:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=9f2f873d5a1c3f6b22b18db0e4c9f3a30164b8f0'/>
<id>9f2f873d5a1c3f6b22b18db0e4c9f3a30164b8f0</id>
<content type='text'>
[ Upstream commit c0b91a56a2e57a5a370655b25d677ae0ebf8a2d0 ]

The Quectel EP06 is a Cat. 6 LTE modem. It uses the same interface as
the EC20/EC25 for QMI, and requires the same "set DTR"-quirk to work.

Signed-off-by: Kristian Evensen &lt;kristian.evensen@gmail.com&gt;
Acked-by: Bjørn Mork &lt;bjorn@mork.no&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit c0b91a56a2e57a5a370655b25d677ae0ebf8a2d0 ]

The Quectel EP06 is a Cat. 6 LTE modem. It uses the same interface as
the EC20/EC25 for QMI, and requires the same "set DTR"-quirk to work.

Signed-off-by: Kristian Evensen &lt;kristian.evensen@gmail.com&gt;
Acked-by: Bjørn Mork &lt;bjorn@mork.no&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>qlcnic: fix deadlock bug</title>
<updated>2018-02-13T11:35:56+00:00</updated>
<author>
<name>Junxiao Bi</name>
<email>junxiao.bi@oracle.com</email>
</author>
<published>2018-01-29T09:53:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=97fe899816a68e3970b877e766bcb8d66013076b'/>
<id>97fe899816a68e3970b877e766bcb8d66013076b</id>
<content type='text'>
[ Upstream commit 233ac3891607f501f08879134d623b303838f478 ]

The following soft lockup was caught. This is a deadlock caused by
recusive locking.

Process kworker/u40:1:28016 was holding spin lock "mbx-&gt;queue_lock" in
qlcnic_83xx_mailbox_worker(), while a softirq came in and ask the same spin
lock in qlcnic_83xx_enqueue_mbx_cmd(). This lock should be hold by disable
bh..

[161846.962125] NMI watchdog: BUG: soft lockup - CPU#1 stuck for 22s! [kworker/u40:1:28016]
[161846.962367] Modules linked in: tun ocfs2 xen_netback xen_blkback xen_gntalloc xen_gntdev xen_evtchn xenfs xen_privcmd autofs4 ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue configfs bnx2fc fcoe libfcoe libfc sunrpc 8021q mrp garp bridge stp llc bonding dm_round_robin dm_multipath iTCO_wdt iTCO_vendor_support pcspkr sb_edac edac_core i2c_i801 shpchp lpc_ich mfd_core ioatdma ipmi_devintf ipmi_si ipmi_msghandler sg ext4 jbd2 mbcache2 sr_mod cdrom sd_mod igb i2c_algo_bit i2c_core ahci libahci megaraid_sas ixgbe dca ptp pps_core vxlan udp_tunnel ip6_udp_tunnel qla2xxx scsi_transport_fc qlcnic crc32c_intel be2iscsi bnx2i cnic uio cxgb4i cxgb4 cxgb3i libcxgbi ipv6 cxgb3 mdio libiscsi_tcp qla4xxx iscsi_boot_sysfs libiscsi scsi_transport_iscsi dm_mirror dm_region_hash dm_log dm_mod
[161846.962454]
[161846.962460] CPU: 1 PID: 28016 Comm: kworker/u40:1 Not tainted 4.1.12-94.5.9.el6uek.x86_64 #2
[161846.962463] Hardware name: Oracle Corporation SUN SERVER X4-2L      /ASSY,MB,X4-2L         , BIOS 26050100 09/19/2017
[161846.962489] Workqueue: qlcnic_mailbox qlcnic_83xx_mailbox_worker [qlcnic]
[161846.962493] task: ffff8801f2e34600 ti: ffff88004ca5c000 task.ti: ffff88004ca5c000
[161846.962496] RIP: e030:[&lt;ffffffff810013aa&gt;]  [&lt;ffffffff810013aa&gt;] xen_hypercall_sched_op+0xa/0x20
[161846.962506] RSP: e02b:ffff880202e43388  EFLAGS: 00000206
[161846.962509] RAX: 0000000000000000 RBX: ffff8801f6996b70 RCX: ffffffff810013aa
[161846.962511] RDX: ffff880202e433cc RSI: ffff880202e433b0 RDI: 0000000000000003
[161846.962513] RBP: ffff880202e433d0 R08: 0000000000000000 R09: ffff8801fe893200
[161846.962516] R10: ffff8801fe400538 R11: 0000000000000206 R12: ffff880202e4b000
[161846.962518] R13: 0000000000000050 R14: 0000000000000001 R15: 000000000000020d
[161846.962528] FS:  0000000000000000(0000) GS:ffff880202e40000(0000) knlGS:ffff880202e40000
[161846.962531] CS:  e033 DS: 0000 ES: 0000 CR0: 0000000080050033
[161846.962533] CR2: 0000000002612640 CR3: 00000001bb796000 CR4: 0000000000042660
[161846.962536] Stack:
[161846.962538]  ffff880202e43608 0000000000000000 ffffffff813f0442 ffff880202e433b0
[161846.962543]  0000000000000000 ffff880202e433cc ffffffff00000001 0000000000000000
[161846.962547]  00000009813f03d6 ffff880202e433e0 ffffffff813f0460 ffff880202e43440
[161846.962552] Call Trace:
[161846.962555]  &lt;IRQ&gt;
[161846.962565]  [&lt;ffffffff813f0442&gt;] ? xen_poll_irq_timeout+0x42/0x50
[161846.962570]  [&lt;ffffffff813f0460&gt;] xen_poll_irq+0x10/0x20
[161846.962578]  [&lt;ffffffff81014222&gt;] xen_lock_spinning+0xe2/0x110
[161846.962583]  [&lt;ffffffff81013f01&gt;] __raw_callee_save_xen_lock_spinning+0x11/0x20
[161846.962592]  [&lt;ffffffff816e5c57&gt;] ? _raw_spin_lock+0x57/0x80
[161846.962609]  [&lt;ffffffffa028acfc&gt;] qlcnic_83xx_enqueue_mbx_cmd+0x7c/0xe0 [qlcnic]
[161846.962623]  [&lt;ffffffffa028e008&gt;] qlcnic_83xx_issue_cmd+0x58/0x210 [qlcnic]
[161846.962636]  [&lt;ffffffffa028caf2&gt;] qlcnic_83xx_sre_macaddr_change+0x162/0x1d0 [qlcnic]
[161846.962649]  [&lt;ffffffffa028cb8b&gt;] qlcnic_83xx_change_l2_filter+0x2b/0x30 [qlcnic]
[161846.962657]  [&lt;ffffffff8160248b&gt;] ? __skb_flow_dissect+0x18b/0x650
[161846.962670]  [&lt;ffffffffa02856e5&gt;] qlcnic_send_filter+0x205/0x250 [qlcnic]
[161846.962682]  [&lt;ffffffffa0285c77&gt;] qlcnic_xmit_frame+0x547/0x7b0 [qlcnic]
[161846.962691]  [&lt;ffffffff8160ac22&gt;] xmit_one+0x82/0x1a0
[161846.962696]  [&lt;ffffffff8160ad90&gt;] dev_hard_start_xmit+0x50/0xa0
[161846.962701]  [&lt;ffffffff81630112&gt;] sch_direct_xmit+0x112/0x220
[161846.962706]  [&lt;ffffffff8160b80f&gt;] __dev_queue_xmit+0x1df/0x5e0
[161846.962710]  [&lt;ffffffff8160bc33&gt;] dev_queue_xmit_sk+0x13/0x20
[161846.962721]  [&lt;ffffffffa0575bd5&gt;] bond_dev_queue_xmit+0x35/0x80 [bonding]
[161846.962729]  [&lt;ffffffffa05769fb&gt;] __bond_start_xmit+0x1cb/0x210 [bonding]
[161846.962736]  [&lt;ffffffffa0576a71&gt;] bond_start_xmit+0x31/0x60 [bonding]
[161846.962740]  [&lt;ffffffff8160ac22&gt;] xmit_one+0x82/0x1a0
[161846.962745]  [&lt;ffffffff8160ad90&gt;] dev_hard_start_xmit+0x50/0xa0
[161846.962749]  [&lt;ffffffff8160bb1e&gt;] __dev_queue_xmit+0x4ee/0x5e0
[161846.962754]  [&lt;ffffffff8160bc33&gt;] dev_queue_xmit_sk+0x13/0x20
[161846.962760]  [&lt;ffffffffa05cfa72&gt;] vlan_dev_hard_start_xmit+0xb2/0x150 [8021q]
[161846.962764]  [&lt;ffffffff8160ac22&gt;] xmit_one+0x82/0x1a0
[161846.962769]  [&lt;ffffffff8160ad90&gt;] dev_hard_start_xmit+0x50/0xa0
[161846.962773]  [&lt;ffffffff8160bb1e&gt;] __dev_queue_xmit+0x4ee/0x5e0
[161846.962777]  [&lt;ffffffff8160bc33&gt;] dev_queue_xmit_sk+0x13/0x20
[161846.962789]  [&lt;ffffffffa05adf74&gt;] br_dev_queue_push_xmit+0x54/0xa0 [bridge]
[161846.962797]  [&lt;ffffffffa05ae4ff&gt;] br_forward_finish+0x2f/0x90 [bridge]
[161846.962807]  [&lt;ffffffff810b0dad&gt;] ? ttwu_do_wakeup+0x1d/0x100
[161846.962811]  [&lt;ffffffff815f929b&gt;] ? __alloc_skb+0x8b/0x1f0
[161846.962818]  [&lt;ffffffffa05ae04d&gt;] __br_forward+0x8d/0x120 [bridge]
[161846.962822]  [&lt;ffffffff815f613b&gt;] ? __kmalloc_reserve+0x3b/0xa0
[161846.962829]  [&lt;ffffffff810be55e&gt;] ? update_rq_runnable_avg+0xee/0x230
[161846.962836]  [&lt;ffffffffa05ae176&gt;] br_forward+0x96/0xb0 [bridge]
[161846.962845]  [&lt;ffffffffa05af85e&gt;] br_handle_frame_finish+0x1ae/0x420 [bridge]
[161846.962853]  [&lt;ffffffffa05afc4f&gt;] br_handle_frame+0x17f/0x260 [bridge]
[161846.962862]  [&lt;ffffffffa05afad0&gt;] ? br_handle_frame_finish+0x420/0x420 [bridge]
[161846.962867]  [&lt;ffffffff8160d057&gt;] __netif_receive_skb_core+0x1f7/0x870
[161846.962872]  [&lt;ffffffff8160d6f2&gt;] __netif_receive_skb+0x22/0x70
[161846.962877]  [&lt;ffffffff8160d913&gt;] netif_receive_skb_internal+0x23/0x90
[161846.962884]  [&lt;ffffffffa07512ea&gt;] ? xenvif_idx_release+0xea/0x100 [xen_netback]
[161846.962889]  [&lt;ffffffff816e5a10&gt;] ? _raw_spin_unlock_irqrestore+0x20/0x50
[161846.962893]  [&lt;ffffffff8160e624&gt;] netif_receive_skb_sk+0x24/0x90
[161846.962899]  [&lt;ffffffffa075269a&gt;] xenvif_tx_submit+0x2ca/0x3f0 [xen_netback]
[161846.962906]  [&lt;ffffffffa0753f0c&gt;] xenvif_tx_action+0x9c/0xd0 [xen_netback]
[161846.962915]  [&lt;ffffffffa07567f5&gt;] xenvif_poll+0x35/0x70 [xen_netback]
[161846.962920]  [&lt;ffffffff8160e01b&gt;] napi_poll+0xcb/0x1e0
[161846.962925]  [&lt;ffffffff8160e1c0&gt;] net_rx_action+0x90/0x1c0
[161846.962931]  [&lt;ffffffff8108aaba&gt;] __do_softirq+0x10a/0x350
[161846.962938]  [&lt;ffffffff8108ae75&gt;] irq_exit+0x125/0x130
[161846.962943]  [&lt;ffffffff813f03a9&gt;] xen_evtchn_do_upcall+0x39/0x50
[161846.962950]  [&lt;ffffffff816e7ffe&gt;] xen_do_hypervisor_callback+0x1e/0x40
[161846.962952]  &lt;EOI&gt;
[161846.962959]  [&lt;ffffffff816e5c4a&gt;] ? _raw_spin_lock+0x4a/0x80
[161846.962964]  [&lt;ffffffff816e5b1e&gt;] ? _raw_spin_lock_irqsave+0x1e/0xa0
[161846.962978]  [&lt;ffffffffa028e279&gt;] ? qlcnic_83xx_mailbox_worker+0xb9/0x2a0 [qlcnic]
[161846.962991]  [&lt;ffffffff810a14e1&gt;] ? process_one_work+0x151/0x4b0
[161846.962995]  [&lt;ffffffff8100c3f2&gt;] ? check_events+0x12/0x20
[161846.963001]  [&lt;ffffffff810a1960&gt;] ? worker_thread+0x120/0x480
[161846.963005]  [&lt;ffffffff816e187b&gt;] ? __schedule+0x30b/0x890
[161846.963010]  [&lt;ffffffff810a1840&gt;] ? process_one_work+0x4b0/0x4b0
[161846.963015]  [&lt;ffffffff810a1840&gt;] ? process_one_work+0x4b0/0x4b0
[161846.963021]  [&lt;ffffffff810a6b3e&gt;] ? kthread+0xce/0xf0
[161846.963025]  [&lt;ffffffff810a6a70&gt;] ? kthread_freezable_should_stop+0x70/0x70
[161846.963031]  [&lt;ffffffff816e6522&gt;] ? ret_from_fork+0x42/0x70
[161846.963035]  [&lt;ffffffff810a6a70&gt;] ? kthread_freezable_should_stop+0x70/0x70
[161846.963037] Code: cc 51 41 53 b8 1c 00 00 00 0f 05 41 5b 59 c3 cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc 51 41 53 b8 1d 00 00 00 0f 05 &lt;41&gt; 5b 59 c3 cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc

Signed-off-by: Junxiao Bi &lt;junxiao.bi@oracle.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 233ac3891607f501f08879134d623b303838f478 ]

The following soft lockup was caught. This is a deadlock caused by
recusive locking.

Process kworker/u40:1:28016 was holding spin lock "mbx-&gt;queue_lock" in
qlcnic_83xx_mailbox_worker(), while a softirq came in and ask the same spin
lock in qlcnic_83xx_enqueue_mbx_cmd(). This lock should be hold by disable
bh..

[161846.962125] NMI watchdog: BUG: soft lockup - CPU#1 stuck for 22s! [kworker/u40:1:28016]
[161846.962367] Modules linked in: tun ocfs2 xen_netback xen_blkback xen_gntalloc xen_gntdev xen_evtchn xenfs xen_privcmd autofs4 ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue configfs bnx2fc fcoe libfcoe libfc sunrpc 8021q mrp garp bridge stp llc bonding dm_round_robin dm_multipath iTCO_wdt iTCO_vendor_support pcspkr sb_edac edac_core i2c_i801 shpchp lpc_ich mfd_core ioatdma ipmi_devintf ipmi_si ipmi_msghandler sg ext4 jbd2 mbcache2 sr_mod cdrom sd_mod igb i2c_algo_bit i2c_core ahci libahci megaraid_sas ixgbe dca ptp pps_core vxlan udp_tunnel ip6_udp_tunnel qla2xxx scsi_transport_fc qlcnic crc32c_intel be2iscsi bnx2i cnic uio cxgb4i cxgb4 cxgb3i libcxgbi ipv6 cxgb3 mdio libiscsi_tcp qla4xxx iscsi_boot_sysfs libiscsi scsi_transport_iscsi dm_mirror dm_region_hash dm_log dm_mod
[161846.962454]
[161846.962460] CPU: 1 PID: 28016 Comm: kworker/u40:1 Not tainted 4.1.12-94.5.9.el6uek.x86_64 #2
[161846.962463] Hardware name: Oracle Corporation SUN SERVER X4-2L      /ASSY,MB,X4-2L         , BIOS 26050100 09/19/2017
[161846.962489] Workqueue: qlcnic_mailbox qlcnic_83xx_mailbox_worker [qlcnic]
[161846.962493] task: ffff8801f2e34600 ti: ffff88004ca5c000 task.ti: ffff88004ca5c000
[161846.962496] RIP: e030:[&lt;ffffffff810013aa&gt;]  [&lt;ffffffff810013aa&gt;] xen_hypercall_sched_op+0xa/0x20
[161846.962506] RSP: e02b:ffff880202e43388  EFLAGS: 00000206
[161846.962509] RAX: 0000000000000000 RBX: ffff8801f6996b70 RCX: ffffffff810013aa
[161846.962511] RDX: ffff880202e433cc RSI: ffff880202e433b0 RDI: 0000000000000003
[161846.962513] RBP: ffff880202e433d0 R08: 0000000000000000 R09: ffff8801fe893200
[161846.962516] R10: ffff8801fe400538 R11: 0000000000000206 R12: ffff880202e4b000
[161846.962518] R13: 0000000000000050 R14: 0000000000000001 R15: 000000000000020d
[161846.962528] FS:  0000000000000000(0000) GS:ffff880202e40000(0000) knlGS:ffff880202e40000
[161846.962531] CS:  e033 DS: 0000 ES: 0000 CR0: 0000000080050033
[161846.962533] CR2: 0000000002612640 CR3: 00000001bb796000 CR4: 0000000000042660
[161846.962536] Stack:
[161846.962538]  ffff880202e43608 0000000000000000 ffffffff813f0442 ffff880202e433b0
[161846.962543]  0000000000000000 ffff880202e433cc ffffffff00000001 0000000000000000
[161846.962547]  00000009813f03d6 ffff880202e433e0 ffffffff813f0460 ffff880202e43440
[161846.962552] Call Trace:
[161846.962555]  &lt;IRQ&gt;
[161846.962565]  [&lt;ffffffff813f0442&gt;] ? xen_poll_irq_timeout+0x42/0x50
[161846.962570]  [&lt;ffffffff813f0460&gt;] xen_poll_irq+0x10/0x20
[161846.962578]  [&lt;ffffffff81014222&gt;] xen_lock_spinning+0xe2/0x110
[161846.962583]  [&lt;ffffffff81013f01&gt;] __raw_callee_save_xen_lock_spinning+0x11/0x20
[161846.962592]  [&lt;ffffffff816e5c57&gt;] ? _raw_spin_lock+0x57/0x80
[161846.962609]  [&lt;ffffffffa028acfc&gt;] qlcnic_83xx_enqueue_mbx_cmd+0x7c/0xe0 [qlcnic]
[161846.962623]  [&lt;ffffffffa028e008&gt;] qlcnic_83xx_issue_cmd+0x58/0x210 [qlcnic]
[161846.962636]  [&lt;ffffffffa028caf2&gt;] qlcnic_83xx_sre_macaddr_change+0x162/0x1d0 [qlcnic]
[161846.962649]  [&lt;ffffffffa028cb8b&gt;] qlcnic_83xx_change_l2_filter+0x2b/0x30 [qlcnic]
[161846.962657]  [&lt;ffffffff8160248b&gt;] ? __skb_flow_dissect+0x18b/0x650
[161846.962670]  [&lt;ffffffffa02856e5&gt;] qlcnic_send_filter+0x205/0x250 [qlcnic]
[161846.962682]  [&lt;ffffffffa0285c77&gt;] qlcnic_xmit_frame+0x547/0x7b0 [qlcnic]
[161846.962691]  [&lt;ffffffff8160ac22&gt;] xmit_one+0x82/0x1a0
[161846.962696]  [&lt;ffffffff8160ad90&gt;] dev_hard_start_xmit+0x50/0xa0
[161846.962701]  [&lt;ffffffff81630112&gt;] sch_direct_xmit+0x112/0x220
[161846.962706]  [&lt;ffffffff8160b80f&gt;] __dev_queue_xmit+0x1df/0x5e0
[161846.962710]  [&lt;ffffffff8160bc33&gt;] dev_queue_xmit_sk+0x13/0x20
[161846.962721]  [&lt;ffffffffa0575bd5&gt;] bond_dev_queue_xmit+0x35/0x80 [bonding]
[161846.962729]  [&lt;ffffffffa05769fb&gt;] __bond_start_xmit+0x1cb/0x210 [bonding]
[161846.962736]  [&lt;ffffffffa0576a71&gt;] bond_start_xmit+0x31/0x60 [bonding]
[161846.962740]  [&lt;ffffffff8160ac22&gt;] xmit_one+0x82/0x1a0
[161846.962745]  [&lt;ffffffff8160ad90&gt;] dev_hard_start_xmit+0x50/0xa0
[161846.962749]  [&lt;ffffffff8160bb1e&gt;] __dev_queue_xmit+0x4ee/0x5e0
[161846.962754]  [&lt;ffffffff8160bc33&gt;] dev_queue_xmit_sk+0x13/0x20
[161846.962760]  [&lt;ffffffffa05cfa72&gt;] vlan_dev_hard_start_xmit+0xb2/0x150 [8021q]
[161846.962764]  [&lt;ffffffff8160ac22&gt;] xmit_one+0x82/0x1a0
[161846.962769]  [&lt;ffffffff8160ad90&gt;] dev_hard_start_xmit+0x50/0xa0
[161846.962773]  [&lt;ffffffff8160bb1e&gt;] __dev_queue_xmit+0x4ee/0x5e0
[161846.962777]  [&lt;ffffffff8160bc33&gt;] dev_queue_xmit_sk+0x13/0x20
[161846.962789]  [&lt;ffffffffa05adf74&gt;] br_dev_queue_push_xmit+0x54/0xa0 [bridge]
[161846.962797]  [&lt;ffffffffa05ae4ff&gt;] br_forward_finish+0x2f/0x90 [bridge]
[161846.962807]  [&lt;ffffffff810b0dad&gt;] ? ttwu_do_wakeup+0x1d/0x100
[161846.962811]  [&lt;ffffffff815f929b&gt;] ? __alloc_skb+0x8b/0x1f0
[161846.962818]  [&lt;ffffffffa05ae04d&gt;] __br_forward+0x8d/0x120 [bridge]
[161846.962822]  [&lt;ffffffff815f613b&gt;] ? __kmalloc_reserve+0x3b/0xa0
[161846.962829]  [&lt;ffffffff810be55e&gt;] ? update_rq_runnable_avg+0xee/0x230
[161846.962836]  [&lt;ffffffffa05ae176&gt;] br_forward+0x96/0xb0 [bridge]
[161846.962845]  [&lt;ffffffffa05af85e&gt;] br_handle_frame_finish+0x1ae/0x420 [bridge]
[161846.962853]  [&lt;ffffffffa05afc4f&gt;] br_handle_frame+0x17f/0x260 [bridge]
[161846.962862]  [&lt;ffffffffa05afad0&gt;] ? br_handle_frame_finish+0x420/0x420 [bridge]
[161846.962867]  [&lt;ffffffff8160d057&gt;] __netif_receive_skb_core+0x1f7/0x870
[161846.962872]  [&lt;ffffffff8160d6f2&gt;] __netif_receive_skb+0x22/0x70
[161846.962877]  [&lt;ffffffff8160d913&gt;] netif_receive_skb_internal+0x23/0x90
[161846.962884]  [&lt;ffffffffa07512ea&gt;] ? xenvif_idx_release+0xea/0x100 [xen_netback]
[161846.962889]  [&lt;ffffffff816e5a10&gt;] ? _raw_spin_unlock_irqrestore+0x20/0x50
[161846.962893]  [&lt;ffffffff8160e624&gt;] netif_receive_skb_sk+0x24/0x90
[161846.962899]  [&lt;ffffffffa075269a&gt;] xenvif_tx_submit+0x2ca/0x3f0 [xen_netback]
[161846.962906]  [&lt;ffffffffa0753f0c&gt;] xenvif_tx_action+0x9c/0xd0 [xen_netback]
[161846.962915]  [&lt;ffffffffa07567f5&gt;] xenvif_poll+0x35/0x70 [xen_netback]
[161846.962920]  [&lt;ffffffff8160e01b&gt;] napi_poll+0xcb/0x1e0
[161846.962925]  [&lt;ffffffff8160e1c0&gt;] net_rx_action+0x90/0x1c0
[161846.962931]  [&lt;ffffffff8108aaba&gt;] __do_softirq+0x10a/0x350
[161846.962938]  [&lt;ffffffff8108ae75&gt;] irq_exit+0x125/0x130
[161846.962943]  [&lt;ffffffff813f03a9&gt;] xen_evtchn_do_upcall+0x39/0x50
[161846.962950]  [&lt;ffffffff816e7ffe&gt;] xen_do_hypervisor_callback+0x1e/0x40
[161846.962952]  &lt;EOI&gt;
[161846.962959]  [&lt;ffffffff816e5c4a&gt;] ? _raw_spin_lock+0x4a/0x80
[161846.962964]  [&lt;ffffffff816e5b1e&gt;] ? _raw_spin_lock_irqsave+0x1e/0xa0
[161846.962978]  [&lt;ffffffffa028e279&gt;] ? qlcnic_83xx_mailbox_worker+0xb9/0x2a0 [qlcnic]
[161846.962991]  [&lt;ffffffff810a14e1&gt;] ? process_one_work+0x151/0x4b0
[161846.962995]  [&lt;ffffffff8100c3f2&gt;] ? check_events+0x12/0x20
[161846.963001]  [&lt;ffffffff810a1960&gt;] ? worker_thread+0x120/0x480
[161846.963005]  [&lt;ffffffff816e187b&gt;] ? __schedule+0x30b/0x890
[161846.963010]  [&lt;ffffffff810a1840&gt;] ? process_one_work+0x4b0/0x4b0
[161846.963015]  [&lt;ffffffff810a1840&gt;] ? process_one_work+0x4b0/0x4b0
[161846.963021]  [&lt;ffffffff810a6b3e&gt;] ? kthread+0xce/0xf0
[161846.963025]  [&lt;ffffffff810a6a70&gt;] ? kthread_freezable_should_stop+0x70/0x70
[161846.963031]  [&lt;ffffffff816e6522&gt;] ? ret_from_fork+0x42/0x70
[161846.963035]  [&lt;ffffffff810a6a70&gt;] ? kthread_freezable_should_stop+0x70/0x70
[161846.963037] Code: cc 51 41 53 b8 1c 00 00 00 0f 05 41 5b 59 c3 cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc 51 41 53 b8 1d 00 00 00 0f 05 &lt;41&gt; 5b 59 c3 cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc

Signed-off-by: Junxiao Bi &lt;junxiao.bi@oracle.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>iwlwifi: mvm: fix the TX queue hang timeout for MONITOR vif type</title>
<updated>2018-02-03T16:05:41+00:00</updated>
<author>
<name>Emmanuel Grumbach</name>
<email>emmanuel.grumbach@intel.com</email>
</author>
<published>2017-11-15T12:12:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=9adb2a0f9a470b59ccca26e07ed279c11200f0db'/>
<id>9adb2a0f9a470b59ccca26e07ed279c11200f0db</id>
<content type='text'>
[ Upstream commit d1b275ffec459c5ae12b5c7086c84175696e5a9f ]

The MONITOR type is missing in the interface type switch.
Add it.

Signed-off-by: Emmanuel Grumbach &lt;emmanuel.grumbach@intel.com&gt;
Signed-off-by: Luca Coelho &lt;luciano.coelho@intel.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit d1b275ffec459c5ae12b5c7086c84175696e5a9f ]

The MONITOR type is missing in the interface type switch.
Add it.

Signed-off-by: Emmanuel Grumbach &lt;emmanuel.grumbach@intel.com&gt;
Signed-off-by: Luca Coelho &lt;luciano.coelho@intel.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>net: ethernet: xilinx: Mark XILINX_LL_TEMAC broken on 64-bit</title>
<updated>2018-02-03T16:05:39+00:00</updated>
<author>
<name>Geert Uytterhoeven</name>
<email>geert+renesas@glider.be</email>
</author>
<published>2017-11-29T10:01:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=d47907bcac94cc455a62d50e6c71ae5341cee0ea'/>
<id>d47907bcac94cc455a62d50e6c71ae5341cee0ea</id>
<content type='text'>
[ Upstream commit 15bfe05c8d6386f1a90e9340d15336e85e32aad6 ]

On 64-bit (e.g. powerpc64/allmodconfig):

    drivers/net/ethernet/xilinx/ll_temac_main.c: In function 'temac_start_xmit_done':
    drivers/net/ethernet/xilinx/ll_temac_main.c:633:22: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
	dev_kfree_skb_irq((struct sk_buff *)cur_p-&gt;app4);
			  ^

cdmac_bd.app4 is u32, so it is too small to hold a kernel pointer.

Note that several other fields in struct cdmac_bd are also too small to
hold physical addresses on 64-bit platforms.

Signed-off-by: Geert Uytterhoeven &lt;geert+renesas@glider.be&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 15bfe05c8d6386f1a90e9340d15336e85e32aad6 ]

On 64-bit (e.g. powerpc64/allmodconfig):

    drivers/net/ethernet/xilinx/ll_temac_main.c: In function 'temac_start_xmit_done':
    drivers/net/ethernet/xilinx/ll_temac_main.c:633:22: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
	dev_kfree_skb_irq((struct sk_buff *)cur_p-&gt;app4);
			  ^

cdmac_bd.app4 is u32, so it is too small to hold a kernel pointer.

Note that several other fields in struct cdmac_bd are also too small to
hold physical addresses on 64-bit platforms.

Signed-off-by: Geert Uytterhoeven &lt;geert+renesas@glider.be&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>bnxt_en: Fix an error handling path in 'bnxt_get_module_eeprom()'</title>
<updated>2018-02-03T16:05:39+00:00</updated>
<author>
<name>Christophe JAILLET</name>
<email>christophe.jaillet@wanadoo.fr</email>
</author>
<published>2017-11-21T19:46:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=98ae1ca7534e47508719ee54657f01df55437f62'/>
<id>98ae1ca7534e47508719ee54657f01df55437f62</id>
<content type='text'>
[ Upstream commit dea521a2b9f96e905fa2bb2f95e23ec00c2ec436 ]

Error code returned by 'bnxt_read_sfp_module_eeprom_info()' is handled a
few lines above when reading the A0 portion of the EEPROM.
The same should be done when reading the A2 portion of the EEPROM.

In order to correctly propagate an error, update 'rc' in this 2nd call as
well, otherwise 0 (success) is returned.

Signed-off-by: Christophe JAILLET &lt;christophe.jaillet@wanadoo.fr&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit dea521a2b9f96e905fa2bb2f95e23ec00c2ec436 ]

Error code returned by 'bnxt_read_sfp_module_eeprom_info()' is handled a
few lines above when reading the A0 portion of the EEPROM.
The same should be done when reading the A2 portion of the EEPROM.

In order to correctly propagate an error, update 'rc' in this 2nd call as
well, otherwise 0 (success) is returned.

Signed-off-by: Christophe JAILLET &lt;christophe.jaillet@wanadoo.fr&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>xen-netfront: remove warning when unloading module</title>
<updated>2018-02-03T16:05:38+00:00</updated>
<author>
<name>Eduardo Otubo</name>
<email>otubo@redhat.com</email>
</author>
<published>2017-11-23T14:18:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=c6a34556f539c69366bd7bcbeff490a6949f95ce'/>
<id>c6a34556f539c69366bd7bcbeff490a6949f95ce</id>
<content type='text'>
[ Upstream commit 5b5971df3bc2775107ddad164018a8a8db633b81 ]

v2:
 * Replace busy wait with wait_event()/wake_up_all()
 * Cannot garantee that at the time xennet_remove is called, the
   xen_netback state will not be XenbusStateClosed, so added a
   condition for that
 * There's a small chance for the xen_netback state is
   XenbusStateUnknown by the time the xen_netfront switches to Closed,
   so added a condition for that.

When unloading module xen_netfront from guest, dmesg would output
warning messages like below:

  [  105.236836] xen:grant_table: WARNING: g.e. 0x903 still in use!
  [  105.236839] deferring g.e. 0x903 (pfn 0x35805)

This problem relies on netfront and netback being out of sync. By the time
netfront revokes the g.e.'s netback didn't have enough time to free all of
them, hence displaying the warnings on dmesg.

The trick here is to make netfront to wait until netback frees all the g.e.'s
and only then continue to cleanup for the module removal, and this is done by
manipulating both device states.

Signed-off-by: Eduardo Otubo &lt;otubo@redhat.com&gt;
Acked-by: Juergen Gross &lt;jgross@suse.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 5b5971df3bc2775107ddad164018a8a8db633b81 ]

v2:
 * Replace busy wait with wait_event()/wake_up_all()
 * Cannot garantee that at the time xennet_remove is called, the
   xen_netback state will not be XenbusStateClosed, so added a
   condition for that
 * There's a small chance for the xen_netback state is
   XenbusStateUnknown by the time the xen_netfront switches to Closed,
   so added a condition for that.

When unloading module xen_netfront from guest, dmesg would output
warning messages like below:

  [  105.236836] xen:grant_table: WARNING: g.e. 0x903 still in use!
  [  105.236839] deferring g.e. 0x903 (pfn 0x35805)

This problem relies on netfront and netback being out of sync. By the time
netfront revokes the g.e.'s netback didn't have enough time to free all of
them, hence displaying the warnings on dmesg.

The trick here is to make netfront to wait until netback frees all the g.e.'s
and only then continue to cleanup for the module removal, and this is done by
manipulating both device states.

Signed-off-by: Eduardo Otubo &lt;otubo@redhat.com&gt;
Acked-by: Juergen Gross &lt;jgross@suse.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>igb: Free IRQs when device is hotplugged</title>
<updated>2018-02-03T16:05:35+00:00</updated>
<author>
<name>Lyude Paul</name>
<email>lyude@redhat.com</email>
</author>
<published>2017-12-12T19:31:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=30942f91b5a57a1ca7557998e901367901d1bccf'/>
<id>30942f91b5a57a1ca7557998e901367901d1bccf</id>
<content type='text'>
commit 888f22931478a05bc81ceb7295c626e1292bf0ed upstream.

Recently I got a Caldigit TS3 Thunderbolt 3 dock, and noticed that upon
hotplugging my kernel would immediately crash due to igb:

[  680.825801] kernel BUG at drivers/pci/msi.c:352!
[  680.828388] invalid opcode: 0000 [#1] SMP
[  680.829194] Modules linked in: igb(O) thunderbolt i2c_algo_bit joydev vfat fat btusb btrtl btbcm btintel bluetooth ecdh_generic hp_wmi sparse_keymap rfkill wmi_bmof iTCO_wdt intel_rapl x86_pkg_temp_thermal coretemp crc32_pclmul snd_pcm rtsx_pci_ms mei_me snd_timer memstick snd pcspkr mei soundcore i2c_i801 tpm_tis psmouse shpchp wmi tpm_tis_core tpm video hp_wireless acpi_pad rtsx_pci_sdmmc mmc_core crc32c_intel serio_raw rtsx_pci mfd_core xhci_pci xhci_hcd i2c_hid i2c_core [last unloaded: igb]
[  680.831085] CPU: 1 PID: 78 Comm: kworker/u16:1 Tainted: G           O     4.15.0-rc3Lyude-Test+ #6
[  680.831596] Hardware name: HP HP ZBook Studio G4/826B, BIOS P71 Ver. 01.03 06/09/2017
[  680.832168] Workqueue: kacpi_hotplug acpi_hotplug_work_fn
[  680.832687] RIP: 0010:free_msi_irqs+0x180/0x1b0
[  680.833271] RSP: 0018:ffffc9000030fbf0 EFLAGS: 00010286
[  680.833761] RAX: ffff8803405f9c00 RBX: ffff88033e3d2e40 RCX: 000000000000002c
[  680.834278] RDX: 0000000000000000 RSI: 00000000000000ac RDI: ffff880340be2178
[  680.834832] RBP: 0000000000000000 R08: ffff880340be1ff0 R09: ffff8803405f9c00
[  680.835342] R10: 0000000000000000 R11: 0000000000000040 R12: ffff88033d63a298
[  680.835822] R13: ffff88033d63a000 R14: 0000000000000060 R15: ffff880341959000
[  680.836332] FS:  0000000000000000(0000) GS:ffff88034f440000(0000) knlGS:0000000000000000
[  680.836817] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  680.837360] CR2: 000055e64044afdf CR3: 0000000001c09002 CR4: 00000000003606e0
[  680.837954] Call Trace:
[  680.838853]  pci_disable_msix+0xce/0xf0
[  680.839616]  igb_reset_interrupt_capability+0x5d/0x60 [igb]
[  680.840278]  igb_remove+0x9d/0x110 [igb]
[  680.840764]  pci_device_remove+0x36/0xb0
[  680.841279]  device_release_driver_internal+0x157/0x220
[  680.841739]  pci_stop_bus_device+0x7d/0xa0
[  680.842255]  pci_stop_bus_device+0x2b/0xa0
[  680.842722]  pci_stop_bus_device+0x3d/0xa0
[  680.843189]  pci_stop_and_remove_bus_device+0xe/0x20
[  680.843627]  trim_stale_devices+0xf3/0x140
[  680.844086]  trim_stale_devices+0x94/0x140
[  680.844532]  trim_stale_devices+0xa6/0x140
[  680.845031]  ? get_slot_status+0x90/0xc0
[  680.845536]  acpiphp_check_bridge.part.5+0xfe/0x140
[  680.846021]  acpiphp_hotplug_notify+0x175/0x200
[  680.846581]  ? free_bridge+0x100/0x100
[  680.847113]  acpi_device_hotplug+0x8a/0x490
[  680.847535]  acpi_hotplug_work_fn+0x1a/0x30
[  680.848076]  process_one_work+0x182/0x3a0
[  680.848543]  worker_thread+0x2e/0x380
[  680.848963]  ? process_one_work+0x3a0/0x3a0
[  680.849373]  kthread+0x111/0x130
[  680.849776]  ? kthread_create_worker_on_cpu+0x50/0x50
[  680.850188]  ret_from_fork+0x1f/0x30
[  680.850601] Code: 43 14 85 c0 0f 84 d5 fe ff ff 31 ed eb 0f 83 c5 01 39 6b 14 0f 86 c5 fe ff ff 8b 7b 10 01 ef e8 b7 e4 d2 ff 48 83 78 70 00 74 e3 &lt;0f&gt; 0b 49 8d b5 a0 00 00 00 e8 62 6f d3 ff e9 c7 fe ff ff 48 8b
[  680.851497] RIP: free_msi_irqs+0x180/0x1b0 RSP: ffffc9000030fbf0

As it turns out, normally the freeing of IRQs that would fix this is called
inside of the scope of __igb_close(). However, since the device is
already gone by the point we try to unregister the netdevice from the
driver due to a hotplug we end up seeing that the netif isn't present
and thus, forget to free any of the device IRQs.

So: make sure that if we're in the process of dismantling the netdev, we
always allow __igb_close() to be called so that IRQs may be freed
normally. Additionally, only allow igb_close() to be called from
__igb_close() if it hasn't already been called for the given adapter.

Signed-off-by: Lyude Paul &lt;lyude@redhat.com&gt;
Fixes: 9474933caf21 ("igb: close/suspend race in netif_device_detach")
Cc: Todd Fujinaka &lt;todd.fujinaka@intel.com&gt;
Cc: Stephen Hemminger &lt;stephen@networkplumber.org&gt;
Tested-by: Aaron Brown &lt;aaron.f.brown@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 888f22931478a05bc81ceb7295c626e1292bf0ed upstream.

Recently I got a Caldigit TS3 Thunderbolt 3 dock, and noticed that upon
hotplugging my kernel would immediately crash due to igb:

[  680.825801] kernel BUG at drivers/pci/msi.c:352!
[  680.828388] invalid opcode: 0000 [#1] SMP
[  680.829194] Modules linked in: igb(O) thunderbolt i2c_algo_bit joydev vfat fat btusb btrtl btbcm btintel bluetooth ecdh_generic hp_wmi sparse_keymap rfkill wmi_bmof iTCO_wdt intel_rapl x86_pkg_temp_thermal coretemp crc32_pclmul snd_pcm rtsx_pci_ms mei_me snd_timer memstick snd pcspkr mei soundcore i2c_i801 tpm_tis psmouse shpchp wmi tpm_tis_core tpm video hp_wireless acpi_pad rtsx_pci_sdmmc mmc_core crc32c_intel serio_raw rtsx_pci mfd_core xhci_pci xhci_hcd i2c_hid i2c_core [last unloaded: igb]
[  680.831085] CPU: 1 PID: 78 Comm: kworker/u16:1 Tainted: G           O     4.15.0-rc3Lyude-Test+ #6
[  680.831596] Hardware name: HP HP ZBook Studio G4/826B, BIOS P71 Ver. 01.03 06/09/2017
[  680.832168] Workqueue: kacpi_hotplug acpi_hotplug_work_fn
[  680.832687] RIP: 0010:free_msi_irqs+0x180/0x1b0
[  680.833271] RSP: 0018:ffffc9000030fbf0 EFLAGS: 00010286
[  680.833761] RAX: ffff8803405f9c00 RBX: ffff88033e3d2e40 RCX: 000000000000002c
[  680.834278] RDX: 0000000000000000 RSI: 00000000000000ac RDI: ffff880340be2178
[  680.834832] RBP: 0000000000000000 R08: ffff880340be1ff0 R09: ffff8803405f9c00
[  680.835342] R10: 0000000000000000 R11: 0000000000000040 R12: ffff88033d63a298
[  680.835822] R13: ffff88033d63a000 R14: 0000000000000060 R15: ffff880341959000
[  680.836332] FS:  0000000000000000(0000) GS:ffff88034f440000(0000) knlGS:0000000000000000
[  680.836817] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  680.837360] CR2: 000055e64044afdf CR3: 0000000001c09002 CR4: 00000000003606e0
[  680.837954] Call Trace:
[  680.838853]  pci_disable_msix+0xce/0xf0
[  680.839616]  igb_reset_interrupt_capability+0x5d/0x60 [igb]
[  680.840278]  igb_remove+0x9d/0x110 [igb]
[  680.840764]  pci_device_remove+0x36/0xb0
[  680.841279]  device_release_driver_internal+0x157/0x220
[  680.841739]  pci_stop_bus_device+0x7d/0xa0
[  680.842255]  pci_stop_bus_device+0x2b/0xa0
[  680.842722]  pci_stop_bus_device+0x3d/0xa0
[  680.843189]  pci_stop_and_remove_bus_device+0xe/0x20
[  680.843627]  trim_stale_devices+0xf3/0x140
[  680.844086]  trim_stale_devices+0x94/0x140
[  680.844532]  trim_stale_devices+0xa6/0x140
[  680.845031]  ? get_slot_status+0x90/0xc0
[  680.845536]  acpiphp_check_bridge.part.5+0xfe/0x140
[  680.846021]  acpiphp_hotplug_notify+0x175/0x200
[  680.846581]  ? free_bridge+0x100/0x100
[  680.847113]  acpi_device_hotplug+0x8a/0x490
[  680.847535]  acpi_hotplug_work_fn+0x1a/0x30
[  680.848076]  process_one_work+0x182/0x3a0
[  680.848543]  worker_thread+0x2e/0x380
[  680.848963]  ? process_one_work+0x3a0/0x3a0
[  680.849373]  kthread+0x111/0x130
[  680.849776]  ? kthread_create_worker_on_cpu+0x50/0x50
[  680.850188]  ret_from_fork+0x1f/0x30
[  680.850601] Code: 43 14 85 c0 0f 84 d5 fe ff ff 31 ed eb 0f 83 c5 01 39 6b 14 0f 86 c5 fe ff ff 8b 7b 10 01 ef e8 b7 e4 d2 ff 48 83 78 70 00 74 e3 &lt;0f&gt; 0b 49 8d b5 a0 00 00 00 e8 62 6f d3 ff e9 c7 fe ff ff 48 8b
[  680.851497] RIP: free_msi_irqs+0x180/0x1b0 RSP: ffffc9000030fbf0

As it turns out, normally the freeing of IRQs that would fix this is called
inside of the scope of __igb_close(). However, since the device is
already gone by the point we try to unregister the netdevice from the
driver due to a hotplug we end up seeing that the netif isn't present
and thus, forget to free any of the device IRQs.

So: make sure that if we're in the process of dismantling the netdev, we
always allow __igb_close() to be called so that IRQs may be freed
normally. Additionally, only allow igb_close() to be called from
__igb_close() if it hasn't already been called for the given adapter.

Signed-off-by: Lyude Paul &lt;lyude@redhat.com&gt;
Fixes: 9474933caf21 ("igb: close/suspend race in netif_device_detach")
Cc: Todd Fujinaka &lt;todd.fujinaka@intel.com&gt;
Cc: Stephen Hemminger &lt;stephen@networkplumber.org&gt;
Tested-by: Aaron Brown &lt;aaron.f.brown@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>tun: fix a memory leak for tfile-&gt;tx_array</title>
<updated>2018-01-31T11:55:56+00:00</updated>
<author>
<name>Cong Wang</name>
<email>xiyou.wangcong@gmail.com</email>
</author>
<published>2018-01-15T19:37:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=18717ee28ef5c0285ff969d1e9357529a8a9233f'/>
<id>18717ee28ef5c0285ff969d1e9357529a8a9233f</id>
<content type='text'>
[ Upstream commit 4df0bfc79904b7169dc77dcce44598b1545721f9 ]

tfile-&gt;tun could be detached before we close the tun fd,
via tun_detach_all(), so it should not be used to check for
tfile-&gt;tx_array.

As Jason suggested, we probably have to clean it up
unconditionally both in __tun_deatch() and tun_detach_all(),
but this requires to check if it is initialized or not.
Currently skb_array_cleanup() doesn't have such a check,
so I check it in the caller and introduce a helper function,
it is a bit ugly but we can always improve it in net-next.

Reported-by: Dmitry Vyukov &lt;dvyukov@google.com&gt;
Fixes: 1576d9860599 ("tun: switch to use skb array for tx")
Cc: Jason Wang &lt;jasowang@redhat.com&gt;
Signed-off-by: Cong Wang &lt;xiyou.wangcong@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 4df0bfc79904b7169dc77dcce44598b1545721f9 ]

tfile-&gt;tun could be detached before we close the tun fd,
via tun_detach_all(), so it should not be used to check for
tfile-&gt;tx_array.

As Jason suggested, we probably have to clean it up
unconditionally both in __tun_deatch() and tun_detach_all(),
but this requires to check if it is initialized or not.
Currently skb_array_cleanup() doesn't have such a check,
so I check it in the caller and introduce a helper function,
it is a bit ugly but we can always improve it in net-next.

Reported-by: Dmitry Vyukov &lt;dvyukov@google.com&gt;
Fixes: 1576d9860599 ("tun: switch to use skb array for tx")
Cc: Jason Wang &lt;jasowang@redhat.com&gt;
Signed-off-by: Cong Wang &lt;xiyou.wangcong@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
