commit 36bd5bfe43496f6bb9ab512af46c95b8d152ee99 Author: Greg Kroah-Hartman Date: Sat Nov 26 09:57:13 2016 +0100 Linux 4.8.11 commit a9a0027757f8c317f1d7334c095bde96b4a0f84c Author: Phil Reid Date: Tue Nov 8 14:00:45 2016 +0800 gpio: pca953x: Fix corruption of other gpios in set_multiple. commit 53f8d322234649b4d6f1515b20c127a577efd164 upstream. gpiod_set_array_value_complex does not clear the bits field. Therefore when the drivers set_multiple funciton is called bits outside the mask are undefined and can be either set or not. So bank_val needs to be masked with bank_mask before or with the reg_val cache. Fixes: b4818afeacbd ("gpio: pca953x: Add set_multiple to allow multiple") Signed-off-by: Phil Reid Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 88fce76cf59055ddf97667001dbd26577b8760e0 Author: Phil Reid Date: Tue Nov 8 13:18:11 2016 +0800 gpio: pca953x: Move memcpy into mutex lock for set multiple commit 386377b5473043c09b2de40bfe5abfb0fc87e1b4 upstream. Need to ensure that reg_output is not updated while setting multiple bits. This makes the mutex locking behaviour for the set_multiple call consistent with that of the set_value call. Fixes: b4818afeacbd ("gpio: pca953x: Add set_multiple to allow multiple") Signed-off-by: Phil Reid Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 9a7b808949518e702eddddbd97c9948e4e6b7de9 Author: Anders K. Pedersen Date: Sun Oct 9 13:49:02 2016 +0000 netfilter: nft_dynset: fix element timeout for HZ != 1000 commit a8b1e36d0d1d6f51490e7adce35367ed6adb10e7 upstream. With HZ=100 element timeout in dynamic sets (i.e. flow tables) is 10 times higher than configured. Add proper conversion to/from jiffies, when interacting with userspace. I tested this on Linux 4.8.1, and it applies cleanly to current nf and nf-next trees. Fixes: 22fe54d5fefc ("netfilter: nf_tables: add support for dynamic set updates") Signed-off-by: Anders K. Pedersen Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit fd4251fa4d094d57b7e4ccd673350ce2f3d15be9 Author: Mark Bloch Date: Thu Oct 27 16:36:27 2016 +0300 IB/cm: Mark stale CM id's whenever the mad agent was unregistered commit 9db0ff53cb9b43ed75bacd42a89c1a0ab048b2b0 upstream. When there is a CM id object that has port assigned to it, it means that the cm-id asked for the specific port that it should go by it, but if that port was removed (hot-unplug event) the cm-id was not updated. In order to fix that the port keeps a list of all the cm-id's that are planning to go by it, whenever the port is removed it marks all of them as invalid. This commit fixes a kernel panic which happens when running traffic between guests and we force reboot a guest mid traffic, it triggers a kernel panic: Call Trace: [] ? panic+0xa7/0x16f [] ? oops_end+0xe4/0x100 [] ? no_context+0xfb/0x260 [] ? del_timer_sync+0x22/0x30 [] ? __bad_area_nosemaphore+0x125/0x1e0 [] ? process_timeout+0x0/0x10 [] ? bad_area_nosemaphore+0x13/0x20 [] ? __do_page_fault+0x31f/0x480 [] ? default_wake_function+0x0/0x20 [] ? free_msg+0x55/0x70 [mlx5_core] [] ? cmd_exec+0x124/0x840 [mlx5_core] [] ? find_busiest_group+0x244/0x9f0 [] ? do_page_fault+0x3e/0xa0 [] ? page_fault+0x25/0x30 [] ? cm_alloc_msg+0x35/0xc0 [ib_cm] [] ? ib_send_cm_dreq+0xb1/0x1e0 [ib_cm] [] ? cm_destroy_id+0x176/0x320 [ib_cm] [] ? ib_destroy_cm_id+0x10/0x20 [ib_cm] [] ? ipoib_cm_free_rx_reap_list+0xa7/0x110 [ib_ipoib] [] ? ipoib_cm_rx_reap+0x0/0x20 [ib_ipoib] [] ? ipoib_cm_rx_reap+0x15/0x20 [ib_ipoib] [] ? worker_thread+0x170/0x2a0 [] ? autoremove_wake_function+0x0/0x40 [] ? worker_thread+0x0/0x2a0 [] ? kthread+0x96/0xa0 [] ? child_rip+0xa/0x20 [] ? kthread+0x0/0xa0 [] ? child_rip+0x0/0x20 Fixes: a977049dacde ("[PATCH] IB: Add the kernel CM implementation") Signed-off-by: Mark Bloch Signed-off-by: Erez Shitrit Reviewed-by: Maor Gottlieb Signed-off-by: Leon Romanovsky Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit 8ce92be782f808aed386fbb0d76aba1db34735c6 Author: Tariq Toukan Date: Thu Oct 27 16:36:26 2016 +0300 IB/uverbs: Fix leak of XRC target QPs commit 5b810a242c28e1d8d64d718cebe75b79d86a0b2d upstream. The real QP is destroyed in case of the ref count reaches zero, but for XRC target QPs this call was missed and caused to QP leaks. Let's call to destroy for all flows. Fixes: 0e0ec7e0638e ('RDMA/core: Export ib_open_qp() to share XRC...') Signed-off-by: Tariq Toukan Signed-off-by: Noa Osherovich Signed-off-by: Leon Romanovsky Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit 160149299f71c36770be6e627f035bd2377ac3ab Author: Dennis Dalessandro Date: Tue Oct 25 13:12:46 2016 -0700 IB/hfi1: Remove incorrect IS_ERR check commit 2b16056f845207967a32497f41cf92b57849f934 upstream. Remove IS_ERR check from caching code as the function being called does not actually return error pointers. Fixes: f19bd643dbde: "IB/hfi1: Prevent NULL pointer deferences in caching code" Reported-by: Dan Carpenter Reviewed-by: Dean Luick Signed-off-by: Dennis Dalessandro Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit 46e47543175b6784b02f7b587ef83b44fd2c8f7d Author: Mark Bloch Date: Thu Oct 27 16:36:31 2016 +0300 IB/core: Avoid unsigned int overflow in sg_alloc_table commit 3c7ba5760ab8eedec01159b267bb9bfcffe522ac upstream. sg_alloc_table gets unsigned int as parameter while the driver returns it as size_t. Check npages isn't greater than maximum unsigned int. Fixes: eeb8461e36c9 ("IB: Refactor umem to use linear SG table") Signed-off-by: Mark Bloch Signed-off-by: Maor Gottlieb Signed-off-by: Leon Romanovsky Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit 82c377d0531156d30e6d26c3eb13122e8c1c8677 Author: Eli Cohen Date: Thu Oct 27 16:36:46 2016 +0300 IB/mlx5: Fix NULL pointer dereference on debug print commit a1ab8402d15d2305d2315d96ec3294bfdf16587e upstream. For XRC QP CQs may not exist. Check before attempting dereference. Fixes: e126ba97dba9 ('mlx5: Add driver for Mellanox Connect-IB adapters') Signed-off-by: Eli Cohen Signed-off-by: Maor Gottlieb Reviewed-by: Yishai Hadas Signed-off-by: Leon Romanovsky Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit 554e4b69f1bbcd55a6e1af505ae0e96d6f485140 Author: Eli Cohen Date: Thu Oct 27 16:36:44 2016 +0300 IB/mlx5: Fix fatal error dispatching commit dbaaff2a2caa03d472b5cc53a3fbfd415c97dc26 upstream. When an internal error condition is detected, make sure to set the device inactive after dispatching the event so ULPs can get a notification of this event. Fixes: e126ba97dba9 ('mlx5: Add driver for Mellanox Connect-IB adapters') Signed-off-by: Eli Cohen Signed-off-by: Maor Gottlieb Reviewed-by: Mohamad Haj Yahia Signed-off-by: Leon Romanovsky Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit 32091ee63d17a8eaaa25a9bcd99d12d236f2b603 Author: Majd Dibbiny Date: Thu Oct 27 16:36:39 2016 +0300 IB/mlx5: Fix memory leak in query device commit 90be7c8ab72853ff9fc407f01518a898df1f3045 upstream. We need to free dev->port when we fail to enable RoCE or initialize node data. Fixes: 0837e86a7a34 ('IB/mlx5: Add per port counters') Signed-off-by: Majd Dibbiny Signed-off-by: Maor Gottlieb Reviewed-by: Mark Bloch Signed-off-by: Leon Romanovsky Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit 21822a5bbddd7c097e8822b6f762c697f1fc6558 Author: Daniel Jurgens Date: Thu Oct 27 16:36:41 2016 +0300 IB/mlx5: Use cache line size to select CQE stride commit 16b0e0695a73b68d8ca40288c8f9614ef208917b upstream. When creating kernel CQs use 128B CQE stride if the cache line size is 128B, 64B otherwise. This prevents multiple CQEs from residing in a 128B cache line, which can cause retries when there are concurrent read and writes in one cache line. Tested with IPoIB on PPC64, saw ~5% throughput improvement. Fixes: e126ba97dba9 ('mlx5: Add driver for Mellanox Connect-IB adapters') Signed-off-by: Daniel Jurgens Signed-off-by: Maor Gottlieb Signed-off-by: Leon Romanovsky Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit ad886a0e9035e4963f9cc0306dcf62a7aba0f90d Author: Maor Gottlieb Date: Thu Oct 27 16:36:40 2016 +0300 IB/mlx5: Validate requested RQT size commit efd7f40082a0dfd112eb87ff2124467a5739216f upstream. Validate that the requested size of RQT is supported by firmware. Fixes: c5f9092936fe ('IB/mlx5: Add Receive Work Queue Indirection table operations') Signed-off-by: Maor Gottlieb Reviewed-by: Yishai Hadas Signed-off-by: Leon Romanovsky Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit 76a93a6f8dd7ee2468fd0ccb83e2112b94a886db Author: Matan Barak Date: Thu Nov 10 11:30:55 2016 +0200 IB/mlx4: Fix create CQ error flow commit 593ff73bcfdc79f79a8a0df55504f75ad3e5d1a9 upstream. Currently, if ib_copy_to_udata fails, the CQ won't be deleted from the radix tree and the HW (HW2SW). Fixes: 225c7b1feef1 ('IB/mlx4: Add a driver Mellanox ConnectX InfiniBand adapters') Signed-off-by: Matan Barak Signed-off-by: Daniel Jurgens Reviewed-by: Mark Bloch Signed-off-by: Leon Romanovsky Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit 4234e6a06f8bc04679bc827a475d9daeba359761 Author: Daniel Jurgens Date: Thu Nov 10 11:30:54 2016 +0200 IB/mlx4: Check gid_index return value commit 37995116fecfce2b61ee3da6e73b3e394c6818f9 upstream. Check the returned GID index value and return an error if it is invalid. Fixes: 5070cd2239bd ('IB/mlx4: Replace mechanism for RoCE GID management') Signed-off-by: Daniel Jurgens Reviewed-by: Mark Bloch Reviewed-by: Yuval Shaia Signed-off-by: Leon Romanovsky Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit fc9275365065937944ff7cdc494af8147a7e9443 Author: Yonatan Cohen Date: Wed Nov 16 10:39:17 2016 +0200 IB/rxe: Clear queue buffer when modifying QP to reset commit aa75b07b478a774b1432e2df1be5cd8ae834de0f upstream. RXE resets the send-q only once in rxe_qp_init_req() when QP is created, but when the QP is reused after QP reset, the send-q holds previous garbage data. This garbage data wrongly fails CQEs that otherwise should have completed successfully. Fixes: 8700e3e7c485 ("Soft RoCE driver") Signed-off-by: Yonatan Cohen Reviewed-by: Moni Shoua Signed-off-by: Leon Romanovsky Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit 3c87b4a8f6d5394990c73af07d56fcea748b1400 Author: Yonatan Cohen Date: Wed Nov 16 10:39:15 2016 +0200 IB/rxe: Fix handling of erroneous WR commit 002e062e13db10973adb8302f231e48b477c7ccf upstream. To correctly handle a erroneous WR this fix does the following 1. Make sure the bad WQE causes a user completion event. 2. Call rxe_completer to handle the erred WQE. Before the fix, when rxe_requester found a bad WQE, it changed its status to IB_WC_LOC_PROT_ERR and exit with 0 for non RC QPs. If this was the 1st WQE then there would be no ACK to invoke the completer and this bad WQE would be stuck in the QP's send-q. On top of that the requester exiting with 0 caused rxe_do_task to endlessly invoke rxe_requester, resulting in a soft-lockup attached below. In case the WQE was not the 1st and rxe_completer did get a chance to handle the bad WQE, it did not cause a complete event since the WQE's IB_SEND_SIGNALED flag was not set. Setting WQE status to IB_SEND_SIGNALED is subject to IBA spec version 1.2.1, section 10.7.3.1 Signaled Completions. NMI watchdog: BUG: soft lockup - CPU#7 stuck for 22s! [] ? rxe_pool_get_index+0x35/0xb0 [rdma_rxe] [] lookup_mem+0x3c/0xc0 [rdma_rxe] [] copy_data+0x1c4/0x230 [rdma_rxe] [] rxe_requester+0x9d0/0x1100 [rdma_rxe] [] ? kfree_skbmem+0x5a/0x60 [] rxe_do_task+0x89/0xf0 [rdma_rxe] [] rxe_run_task+0x12/0x30 [rdma_rxe] [] rxe_post_send+0x41a/0x550 [rdma_rxe] [] ? __kmalloc+0x182/0x200 [] ? down_read+0x12/0x40 [] ib_uverbs_post_send+0x532/0x540 [ib_uverbs] [] ? tcp_sendmsg+0x402/0xb80 [] ib_uverbs_write+0x18c/0x3f0 [ib_uverbs] [] ? inet_recvmsg+0x7e/0xb0 [] ? sock_recvmsg+0x3d/0x50 [] __vfs_write+0x37/0x140 [] vfs_write+0xb2/0x1b0 [] SyS_write+0x55/0xc0 [] entry_SYSCALL_64_fastpath+0x1a/0xa Fixes: 8700e3e7c485 ("Soft RoCE driver") Signed-off-by: Yonatan Cohen Reviewed-by: Moni Shoua Signed-off-by: Leon Romanovsky Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit c4605a0e9605540a58aaba32022c30e697a4a93f Author: Yonatan Cohen Date: Wed Nov 16 10:39:14 2016 +0200 IB/rxe: Fix kernel panic in UDP tunnel with GRO and RX checksum commit 1454ca3a97e147bb91e98b087446c39cf6692a48 upstream. Missing initialization of udp_tunnel_sock_cfg causes to following kernel panic, while kernel tries to execute gro_receive(). While being there, we converted udp_port_cfg to use the same initialization scheme as udp_tunnel_sock_cfg. ------------[ cut here ]------------ kernel tried to execute NX-protected page - exploit attempt? (uid: 0) BUG: unable to handle kernel paging request at ffffffffa0588c50 IP: [] __this_module+0x50/0xffffffffffff8400 [ib_rxe] PGD 1c09067 PUD 1c0a063 PMD bb394067 PTE 80000000ad5e8163 Oops: 0011 [#1] SMP Modules linked in: ib_rxe ip6_udp_tunnel udp_tunnel CPU: 5 PID: 0 Comm: swapper/5 Not tainted 4.7.0-rc3+ #2 Hardware name: Red Hat KVM, BIOS Bochs 01/01/2011 task: ffff880235e4e680 ti: ffff880235e68000 task.ti: ffff880235e68000 RIP: 0010:[] [] __this_module+0x50/0xffffffffffff8400 [ib_rxe] RSP: 0018:ffff880237343c80 EFLAGS: 00010282 RAX: 00000000dffe482d RBX: ffff8800ae330900 RCX: 000000002001b712 RDX: ffff8800ae330900 RSI: ffff8800ae102578 RDI: ffff880235589c00 RBP: ffff880237343cb0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8800ae33e262 R13: ffff880235589c00 R14: 0000000000000014 R15: ffff8800ae102578 FS: 0000000000000000(0000) GS:ffff880237340000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffa0588c50 CR3: 0000000001c06000 CR4: 00000000000006e0 Stack: ffffffff8160860e ffff8800ae330900 ffff8800ae102578 0000000000000014 000000000000004e ffff8800ae102578 ffff880237343ce0 ffffffff816088fb 0000000000000000 ffff8800ae330900 0000000000000000 00000000ffad0000 Call Trace: [] ? udp_gro_receive+0xde/0x130 [] udp4_gro_receive+0x10b/0x2d0 [] inet_gro_receive+0x1d3/0x270 [] dev_gro_receive+0x269/0x3b0 [] napi_gro_receive+0x38/0x120 [] mlx5e_handle_rx_cqe+0x27e/0x340 [mlx5_core] [] mlx5e_poll_rx_cq+0x66/0x6d0 [mlx5_core] [] mlx5e_napi_poll+0x8e/0x400 [mlx5_core] [] net_rx_action+0x160/0x380 [] __do_softirq+0xd7/0x2c5 [] irq_exit+0xf5/0x100 [] do_IRQ+0x56/0xd0 [] common_interrupt+0x8c/0x8c [] ? native_safe_halt+0x6/0x10 [] default_idle+0x1e/0xd0 [] arch_cpu_idle+0xf/0x20 [] default_idle_call+0x3c/0x50 [] cpu_startup_entry+0x323/0x3c0 [] start_secondary+0x15c/0x1a0 RIP [] __this_module+0x50/0xffffffffffff8400 [ib_rxe] RSP CR2: ffffffffa0588c50 ---[ end trace 489ee31fa7614ac5 ]--- Kernel panic - not syncing: Fatal exception in interrupt Kernel Offset: disabled ---[ end Kernel panic - not syncing: Fatal exception in interrupt ------------[ cut here ]------------ Fixes: 8700e3e7c485 ("Soft RoCE driver") Signed-off-by: Yonatan Cohen Reviewed-by: Moni Shoua Signed-off-by: Leon Romanovsky Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit 04d016249998e3600233e2b3057e1a6e56e6e433 Author: Yonatan Cohen Date: Wed Nov 16 10:39:18 2016 +0200 IB/rxe: Update qp state for user query commit 6d931308f55faaef3f30bd0346c47f99528b229d upstream. The method rxe_qp_error() transitions QP to error state and make sure the QP is drained. It did not though update the QP state for user's query. This patch fixes this. Fixes: 8700e3e7c485 ("Soft RoCE driver") Signed-off-by: Yonatan Cohen Reviewed-by: Moni Shoua Signed-off-by: Leon Romanovsky Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit bac1543b764c535d0dd51026f54cc28f8d8adf00 Author: Namhyung Kim Date: Tue Nov 8 22:08:33 2016 +0900 perf hists: Fix column length on --hierarchy commit c72ab446cac1d6c9551fd26c4cfef1b2fc5041fd upstream. Markus reported that there's a weird behavior on perf top --hierarchy regarding the column length. Looking at the code, I found a dubious code which affects the symptoms. When --hierarchy option is used, the last column length might be inaccurate since it skips to update the length on leaf entries. I cannot remember why it did and looks like a leftover from previous version during the development. Anyway, updating the column length often is not harmful. So let's move the code out. Reported-and-Tested-by: Markus Trippelsdorf Signed-off-by: Namhyung Kim Cc: Jiri Olsa Cc: Peter Zijlstra Fixes: 1a3906a7e6b9 ("perf hists: Resort hist entries with hierarchy") Link: http://lkml.kernel.org/r/20161108130833.9263-5-namhyung@kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 4cba876de64d448b458dd271f49c0e6a80a639ce Author: Brian Norris Date: Wed Nov 9 17:21:08 2016 -0800 PM / sleep: don't suspend parent when async child suspend_{noirq, late} fails commit 6f75c3fd56daf547d684127a7f83c283c3c160d1 upstream. Consider two devices, A and B, where B is a child of A, and B utilizes asynchronous suspend (it does not matter whether A is sync or async). If B fails to suspend_noirq() or suspend_late(), or is interrupted by a wakeup (pm_wakeup_pending()), then it aborts and sets the async_error variable. However, device A does not (immediately) check the async_error variable; it may continue to run its own suspend_noirq()/suspend_late() callback. This is bad. We can resolve this problem by doing our error and wakeup checking (particularly, for the async_error flag) after waiting for children to suspend, instead of before. This also helps align the logic for the noirq and late suspend cases with the logic in __device_suspend(). It's easy to observe this erroneous behavior by, for example, forcing a device to sleep a bit in its suspend_noirq() (to ensure the parent is waiting for the child to complete), then return an error, and watch the parent suspend_noirq() still get called. (Or similarly, fake a wakeup event at the right (or is it wrong?) time.) Fixes: de377b397272 (PM / sleep: Asynchronous threads for suspend_late) Fixes: 28b6fd6e3779 (PM / sleep: Asynchronous threads for suspend_noirq) Reported-by: Jeffy Chen Signed-off-by: Brian Norris Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 2e2c8f0e7502fe8a8b6879af6bc8957b949bf1af Author: Johan Hovold Date: Tue Nov 1 11:49:56 2016 +0100 PM / sleep: fix device reference leak in test_suspend commit ceb75787bc75d0a7b88519ab8a68067ac690f55a upstream. Make sure to drop the reference taken by class_find_device() after opening the RTC device. Fixes: 77437fd4e61f (pm: boot time suspend selftest) Signed-off-by: Johan Hovold Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit fd669bf2a09914ea7037302ec46985bb1eef8b4c Author: Johan Hovold Date: Tue Nov 1 12:13:31 2016 +0100 uwb: fix device reference leaks commit d6124b409ca33c100170ffde51cd8dff761454a1 upstream. This subsystem consistently fails to drop the device reference taken by class_find_device(). Note that some of these lookup functions already take a reference to the returned data, while others claim no reference is needed (or does not seem need one). Fixes: 183b9b592a62 ("uwb: add the UWB stack (core files)") Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit ab17baeaea9108fc9ad22955bf8bba8ed363577f Author: Scott Mayhew Date: Fri Nov 11 13:16:22 2016 -0500 sunrpc: svc_age_temp_xprts_now should not call setsockopt non-tcp transports commit ea08e39230e898844d9de5b60cdbb30067cebfe7 upstream. This fixes the following panic that can occur with NFSoRDMA. general protection fault: 0000 [#1] SMP Modules linked in: rpcrdma ib_isert iscsi_target_mod ib_iser libiscsi scsi_transport_iscsi ib_srpt target_core_mod ib_srp scsi_transport_srp scsi_tgt ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm ib_cm iw_cm mlx5_ib ib_core intel_powerclamp coretemp kvm_intel kvm sg ioatdma ipmi_devintf ipmi_ssif dcdbas iTCO_wdt iTCO_vendor_support pcspkr irqbypass sb_edac shpchp dca crc32_pclmul ghash_clmulni_intel edac_core lpc_ich aesni_intel lrw gf128mul glue_helper ablk_helper mei_me mei ipmi_si cryptd wmi ipmi_msghandler acpi_pad acpi_power_meter nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs libcrc32c sd_mod crc_t10dif crct10dif_generic mgag200 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt ahci fb_sys_fops ttm libahci mlx5_core tg3 crct10dif_pclmul drm crct10dif_common ptp i2c_core libata crc32c_intel pps_core fjes dm_mirror dm_region_hash dm_log dm_mod CPU: 1 PID: 120 Comm: kworker/1:1 Not tainted 3.10.0-514.el7.x86_64 #1 Hardware name: Dell Inc. PowerEdge R320/0KM5PX, BIOS 2.4.2 01/29/2015 Workqueue: events check_lifetime task: ffff88031f506dd0 ti: ffff88031f584000 task.ti: ffff88031f584000 RIP: 0010:[] [] _raw_spin_lock_bh+0x17/0x50 RSP: 0018:ffff88031f587ba8 EFLAGS: 00010206 RAX: 0000000000020000 RBX: 20041fac02080072 RCX: ffff88031f587fd8 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 20041fac02080072 RBP: ffff88031f587bb0 R08: 0000000000000008 R09: ffffffff8155be77 R10: ffff880322a59b00 R11: ffffea000bf39f00 R12: 20041fac02080072 R13: 000000000000000d R14: ffff8800c4fbd800 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff880322a40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f3c52d4547e CR3: 00000000019ba000 CR4: 00000000001407e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Stack: 20041fac02080002 ffff88031f587bd0 ffffffff81557830 20041fac02080002 ffff88031f587c78 ffff88031f587c40 ffffffff8155ae08 000000010157df32 0000000800000001 ffff88031f587c20 ffffffff81096acb ffffffff81aa37d0 Call Trace: [] lock_sock_nested+0x20/0x50 [] sock_setsockopt+0x78/0x940 [] ? lock_timer_base.isra.33+0x2b/0x50 [] kernel_setsockopt+0x4d/0x50 [] svc_age_temp_xprts_now+0x174/0x1e0 [sunrpc] [] nfsd_inetaddr_event+0x9d/0xd0 [nfsd] [] notifier_call_chain+0x4c/0x70 [] __blocking_notifier_call_chain+0x4d/0x70 [] blocking_notifier_call_chain+0x16/0x20 [] __inet_del_ifa+0x168/0x2d0 [] check_lifetime+0x25f/0x270 [] process_one_work+0x17b/0x470 [] worker_thread+0x126/0x410 [] ? rescuer_thread+0x460/0x460 [] kthread+0xcf/0xe0 [] ? kthread_create_on_node+0x140/0x140 [] ret_from_fork+0x58/0x90 [] ? kthread_create_on_node+0x140/0x140 Code: ca 75 f1 5d c3 0f 1f 80 00 00 00 00 eb d9 66 0f 1f 44 00 00 0f 1f 44 00 00 55 48 89 e5 53 48 89 fb e8 7e 04 a0 ff b8 00 00 02 00 0f c1 03 89 c2 c1 ea 10 66 39 c2 75 03 5b 5d c3 83 e2 fe 0f RIP [] _raw_spin_lock_bh+0x17/0x50 RSP Signed-off-by: Scott Mayhew Fixes: c3d4879e ("sunrpc: Add a function to close temporary transports immediately") Reviewed-by: Chuck Lever Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 8c7ea73e3a9baa74473a48207af1063f0f6f57de Author: Johan Hovold Date: Tue Nov 1 11:38:18 2016 +0100 mfd: core: Fix device reference leak in mfd_clone_cell commit 722f191080de641f023feaa7d5648caf377844f5 upstream. Make sure to drop the reference taken by bus_find_device_by_name() before returning from mfd_clone_cell(). Fixes: a9bbba996302 ("mfd: add platform_device sharing support for mfd") Signed-off-by: Johan Hovold Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit 545ea4003db9b73a5d29a4dd0d140382a8de85bd Author: Sara Sharon Date: Sun Oct 9 17:34:24 2016 +0300 iwlwifi: mvm: wake the wait queue when the RX sync counter is zero commit 3a732c65de427fdae67a243fd331356034b5a1e8 upstream. When we sync the RX queues the driver waits to receive echo notification on all the RX queues. The wait queue is set with timeout until all queues have received the notification. However, iwl_mvm_rx_queue_notif() never woke up the wait queue, with the result of the counter value being checked only when the timeout expired. This may cause a latency of up to 1 second. Fixes: 0636b938214c ("iwlwifi: mvm: implement driver RX queues sync command") Signed-off-by: Sara Sharon Signed-off-by: Luca Coelho Signed-off-by: Greg Kroah-Hartman commit 8bfaf856695b82abd92d77a50b507661c6960e34 Author: Luca Coelho Date: Wed Oct 5 11:24:12 2016 +0300 iwlwifi: mvm: fix d3_test with unified D0/D3 images commit 85cd69b8f1f7e289fe931a82889e673fd0f04842 upstream. When a unified D0/D3 image is used, we don't restart the FW in the D0->D3->D0 transitions. Therefore, the d3_test functionality should not call ieee8021_restart_hw() when the resuming either. Fixes: commit 23ae61282b88 ("iwlwifi: mvm: Do not switch to D3 image on suspend") Signed-off-by: Luca Coelho Signed-off-by: Greg Kroah-Hartman commit 8cdfd32398b59150a1c5c4b660c7fe4396d14200 Author: Luca Coelho Date: Wed Oct 5 09:28:53 2016 +0300 iwlwifi: mvm: fix netdetect starting/stopping for unified images commit 5a143db8c4a28dab6423cb6197e9f1389da375f2 upstream. With unified images, we need to make sure the net-detect scan is stopped after resuming, since we don't restart the FW. Also, we need to make sure we check if there are enough scan slots available to run it, as we do with other scans. Fixes: commit 23ae61282b88 ("iwlwifi: mvm: Do not switch to D3 image on suspend") Signed-off-by: Luca Coelho Signed-off-by: Greg Kroah-Hartman commit 6e3324dc039c10fb3add341bdb407ad20f2edcf7 Author: Johannes Berg Date: Thu Sep 22 10:31:41 2016 +0200 iwlwifi: pcie: mark command queue lock with separate lockdep class commit faead41cc7213ccef5a58c1bf518ac24816fe8a6 upstream. Emmanuel reports that when CMD_WANT_ASYNC_CALLBACK is used by mvm, the callback will be called with the command queue lock held, and mvm will try to stop all (other) TX queues, which acquires their locks - this caused a false lockdep recursive locking report. Suppress this report by marking the command queue lock with a new, separate, lock class so lockdep can tell the difference between the two types of queues. Fixes: 156f92f2b471 ("iwlwifi: block the queues when we send ADD_STA for uAPSD") Reported-by: Emmanuel Grumbach Signed-off-by: Johannes Berg Signed-off-by: Luca Coelho Signed-off-by: Greg Kroah-Hartman commit b822907865cc01c9debf8dfd52268112a9f53a9f Author: Luca Coelho Date: Thu Oct 13 10:07:07 2016 +0300 iwlwifi: pcie: fix SPLC structure parsing commit e0d9727c111a5917a1184c71c1a8e6f78c7fc41d upstream. The SPLC data parsing is too restrictive and was not trying find the correct element for WiFi. This causes problems with some BIOSes where the SPLC method exists, but doesn't have a WiFi entry on the first element of the list. The domain type values are also incorrect according to the specification. Fix this by complying with the actual specification. Additionally, replace all occurrences of SPLX to SPLC, since SPLX is only a structure internal to the ACPI tables, and may not even exist. Fixes: bcb079a14d75 ("iwlwifi: pcie: retrieve and parse ACPI power limitations") Reported-by: Chris Rorvick Tested-by: Paul Bolle Tested-by: Chris Rorvick Signed-off-by: Luca Coelho Signed-off-by: Greg Kroah-Hartman commit edb60ee4bc6546839ca0ee71c90d1b9c526e153c Author: Lokesh Vutla Date: Thu Oct 27 11:27:25 2016 +0530 rtc: omap: Fix selecting external osc commit 3984903a2e3906d3def220e688040ce93368200a upstream. RTC can be clocked from an external 32KHz oscillator, or from the Peripheral PLL. The RTC has an internal oscillator buffer to support direct operation with a crystal. ---------------------------------------- | Device --------- | | | | | | | RTCSS | | | --------- | | | OSC |<------| RTC | | | | |------>| OSC |--- | | | | -------- | | | | | ----|clk | | | -------- | | | | | | PRCM |--- | | | | -------- -------- | ---------------------------------------- The RTC functional clock is sourced by default from the clock derived from the Peripheral PLL. In order to select source as external osc clk the following changes needs to be done: - Enable the RTC OSC (RTC_OSC_REG[4]OSC32K_GZ = 0) - Enable the clock mux(RTC_OSC_REG[6]K32CLK_EN = 1) - Select the external clock source (RTC_OSC_REG[3]32KCLK_SEL = 1) Fixes: 399cf0f63f6f2 ("rtc: omap: Add external clock enabling support") Signed-off-by: Keerthy Signed-off-by: Lokesh Vutla Signed-off-by: Dave Gerlach Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit 5f95e68daae39717df995c430f0ebc9ac51544bb Author: Emil Lundmark Date: Wed Oct 12 12:31:40 2016 +0200 clk: imx: fix integer overflow in AV PLL round rate commit 5c2f117a22e46a4afee6ddee29b653a7a2a6b41f upstream. Since 'parent_rate * mfn' may overflow 32 bits, the result should be stored using 64 bits. The problem was discovered when trying to set the rate of the audio PLL (pll4_post_div) on an i.MX6Q. The desired rate was 196.608 MHz, but the actual rate returned was 192.000570 MHz. The round rate function should have been able to return 196.608 MHz, i.e., the desired rate. Fixes: ba7f4f557eb6 ("clk: imx: correct AV PLL rate formula") Cc: Anson Huang Signed-off-by: Emil Lundmark Reviewed-by: Fabio Estevam Acked-by: Shawn Guo Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit fec43900c9b7607989a02dadc77cf57f483d9d2a Author: Wei Yongjun Date: Sat Sep 17 15:54:13 2016 +0000 clk: mmp: mmp2: fix return value check in mmp2_clk_init() commit a29e52a6e66f4c0c895e7083e4bad2e7957f1fb5 upstream. Fix the retrn value check which testing the wrong variable in mmp2_clk_init(). Fixes: 1ec770d92a62 ("clk: mmp: add mmp2 DT support for clock driver") Signed-off-by: Wei Yongjun Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit 63465eaf7b2ed6d72767bb1ec2273cacd33d2c31 Author: Wei Yongjun Date: Sat Sep 17 15:54:28 2016 +0000 clk: mmp: pxa168: fix return value check in pxa168_clk_init() commit deab07261d54b4db7b627d38e0efac97f176c6d6 upstream. Fix the retrn value check which testing the wrong variable in pxa168_clk_init(). Fixes: ab08aefcd12d ("clk: mmp: add pxa168 DT support for clock driver") Signed-off-by: Wei Yongjun Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit a42bbd552dede523701c9d940654d37ce55d979e Author: Wei Yongjun Date: Sat Sep 17 15:55:56 2016 +0000 clk: mmp: pxa910: fix return value check in pxa910_clk_init() commit 10f2bfb092e3b49000526c02cfe8b2abbbdbb752 upstream. Fix the retrn value check which testing the wrong variable in pxa910_clk_init(). Fixes: 2bc61da9f7ff ("clk: mmp: add pxa910 DT support for clock driver") Signed-off-by: Wei Yongjun Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit bb6c9ec826be6e7194b7cf6fd2e4fcb7f3f4bd5e Author: Michael S. Tsirkin Date: Fri Nov 4 12:55:36 2016 +0200 virtio-net: drop legacy features in virtio 1 mode commit f3358507c11999c91abf54744658bccd49b5879c upstream. Virtio 1.0 spec says VIRTIO_F_ANY_LAYOUT and VIRTIO_NET_F_GSO are legacy-only feature bits. Do not negotiate them in virtio 1 mode. Note this is a spec violation so we need to backport it to stable/downstream kernels. Signed-off-by: Michael S. Tsirkin Reviewed-by: Cornelia Huck Acked-by: Jason Wang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 899f5426eebf63e75b8e328155260883524ab344 Author: Ville Syrjälä Date: Fri Nov 11 19:14:24 2016 +0200 drm/i915: Assume non-DP++ port if dvo_port is HDMI and there's no AUX ch specified in the VBT commit bc9db5ad3253c8e17969bd802c47b73e63f125ab upstream. My heuristic for detecting type 1 DVI DP++ adaptors based on the VBT port information apparently didn't survive the reality of buggy VBTs. In this particular case we have a machine with a natice HDMI port, but the VBT tells us it's a DP++ port based on its capabilities. The dvo_port information in VBT does claim that we're dealing with a HDMI port though, but we have other machines which do the same even when they actually have DP++ ports. So that piece of information alone isn't sufficient to tell the two apart. After staring at a bunch of VBTs from various machines, I have to conclude that the only other semi-reliable clue we can use is the presence of the AUX channel in the VBT. On this particular machine AUX channel is specified as zero, whereas on some of the other machines which listed the DP++ port as HDMI have a non-zero AUX channel. I've also seen VBTs which have dvo_port a DP but have a zero AUX channel. I believe those we need to treat as DP ports, so we'll limit the AUX channel check to just the cases where dvo_port is HDMI. If we encounter any more serious failures with this heuristic I think we'll have to have to throw it out entirely. But that could mean that there is a risk of type 1 DVI dongle users getting greeted by a black screen, so I'd rather not go there unless absolutely necessary. v2: Remove the duplicate PORT_A check (Daniel) Fix some typos in the commit message Cc: Daniel Otero Tested-by: Daniel Otero Fixes: d61992565bd3 ("drm/i915: Determine DP++ type 1 DVI adaptor presence based on VBT") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97994 Signed-off-by: Ville Syrjälä Link: http://patchwork.freedesktop.org/patch/msgid/1478884464-14251-1-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter (cherry picked from commit 7a17995a3dc8613f778a9e2fd20e870f17789544) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit f6920e5069922618e316cc41bade636fd1186c61 Author: Ville Syrjälä Date: Fri Oct 21 16:44:38 2016 +0300 drm/i915: Refresh that status of MST capable connectors in ->detect() commit fc22b787890f9f9067fd130feec42297a4ee62ba upstream. Once we've determined that the sink is MST capable we never end up running through the full detect cycle again, despite getting HPDs. Fix tht by ripping out the incorrect piece of code responsible. This got broken when I moved the long HPD handling to the ->detect() hook, but failed to remove the leftover code. Cc: Ander Conselvan de Oliveira Cc: drm-intel-fixes@lists.freedesktop.org Cc: Rui Tiago Matos Tested-by: Rui Tiago Matos Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98323 Cc: Kirill A. Shutemov Tested-by: Kirill A. Shutemov References: https://bugs.freedesktop.org/show_bug.cgi?id=98306 Fixes: 1015811609c0 ("drm/i915: Move long hpd handling into the hotplug work") Signed-off-by: Ville Syrjälä Link: http://patchwork.freedesktop.org/patch/msgid/1477057478-29328-1-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson (cherry picked from commit 1aab956c7b8872fb6976328316bfad62c6e67cf8) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 56a02a5f60ea91a3f21164a47188835b4b77ed29 Author: Mario Kleiner Date: Wed Nov 9 02:25:15 2016 +0100 drm/amdgpu: Attach exclusive fence to prime exported bo's. (v5) commit 8e94a46c1770884166b31adc99eba7da65a446a7 upstream. External clients which import our bo's wait only for exclusive dmabuf-fences, not on shared ones, ditto for bo's which we import from external providers and write to. Therefore attach exclusive fences on prime shared buffers if our exported buffer gets imported by an external client, or if we import a buffer from an external exporter. See discussion in thread: https://lists.freedesktop.org/archives/dri-devel/2016-October/122370.html Prime export tested on Intel iGPU + AMD Tonga dGPU as DRI3/Present Prime render offload, and with the Tonga standalone as primary gpu. v2: Add a wait for all shared fences before prime export, as suggested by Christian Koenig. v3: - Mark buffer prime_exported in amdgpu_gem_prime_pin, so we only use the exclusive fence when exporting a bo to external clients like a separate iGPU, but not when exporting/importing from/to ourselves as part of regular DRI3 fd passing. - Propagate failure of reservation_object_wait_rcu back to caller. v4: - Switch to a prime_shared_count counter instead of a flag, which gets in/decremented on prime_pin/unpin, so we can switch back to shared fences if all clients detach from our exported bo. - Also switch to exclusive fence for prime imported bo's. v5: - Drop lret, instead use int ret -> long ret, as proposed by Christian. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95472 Tested-by: Mike Lothian (v1) Signed-off-by: Mario Kleiner Reviewed-by: Christian König . Cc: Christian König Cc: Michel Dänzer Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 3eac4767dd7ec81e2ecc6d9a039b7d5b3a811ad6 Author: Benjamin Herrenschmidt Date: Tue Nov 15 15:28:33 2016 +1100 powerpc/64: Fix setting of AIL in hypervisor mode commit c0a36013639b06760f7c2c21a8387eac855432e1 upstream. Commit d3cbff1b5 "powerpc: Put exception configuration in a common place" broke the setting of the AIL bit (which enables taking exceptions with the MMU still on) on all processors, moving it incorrectly to a function called only on the boot CPU. This was correct for the guest case but not when running in hypervisor mode. This fixes it by partially reverting that commit, putting the setting back in cpu_ready_for_interrupts() Fixes: d3cbff1b5a90 ("powerpc: Put exception configuration in a common place") Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit fc312878ffe36d76c265ac0588393f823b65033e Author: Sven Ebenfeld Date: Mon Nov 7 18:51:34 2016 +0100 crypto: caam - do not register AES-XTS mode on LP units commit 83d2c9a9c17b1e9f23a3a0c24c03cd18e4b02520 upstream. When using AES-XTS on a Wandboard, we receive a Mode error: caam_jr 2102000.jr1: 20001311: CCB: desc idx 19: AES: Mode error. According to the Security Reference Manual, the Low Power AES units of the i.MX6 do not support the XTS mode. Therefore we must not register XTS implementations in the Crypto API. Signed-off-by: Sven Ebenfeld Reviewed-by: Horia Geantă Signed-off-by: Greg Kroah-Hartman Fixes: c6415a6016bf "crypto: caam - add support for acipher xts(aes)" Signed-off-by: Herbert Xu commit 54f28973e8a50af7a61e113ae2769a915526725d Author: Fabio Estevam Date: Thu Oct 27 13:06:44 2016 -0200 ARM: dts: imx53-qsb: Fix regulator constraints commit e3c9d9d6ebfeeeee29c6240e1b5978d40d31d21f upstream. Since commit fa93fd4ecc9c ("regulator: core: Ensure we are at least in bounds for our constraints") the imx53-qsb board populated with a Dialog DA9053 PMIC fails to boot: LDO3: Bringing 3300000uV into 1800000-1800000uV The LDO3 voltage constraints passed in the device tree do not match the valid range according to the datasheet, so fix this accordingly to allow the board booting again. While at it, fix the other voltage constraints as well. Signed-off-by: Fabio Estevam Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman commit 7001b98b9dced1acccc5956fba7318bc3b21fd0e Author: Theodore Ts'o Date: Fri Nov 18 13:00:24 2016 -0500 ext4: sanity check the block and cluster size at mount time commit 8cdf3372fe8368f56315e66bea9f35053c418093 upstream. If the block size or cluster size is insane, reject the mount. This is important for security reasons (although we shouldn't be just depending on this check). Ref: http://www.securityfocus.com/archive/1/539661 Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1332506 Reported-by: Borislav Petkov Reported-by: Nikolay Borisov Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 56df604296c2b6f785e627681757949a461b3a34 Author: Borislav Petkov Date: Mon Nov 14 19:41:31 2016 +0100 kbuild: Steal gcc's pie from the very beginning commit c6a385539175ebc603da53aafb7753d39089f32e upstream. So Sebastian turned off the PIE for kernel builds but that was too late - Kbuild.include already uses KBUILD_CFLAGS and trying to disable gcc options with, say cc-disable-warning, fails: gcc -D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs ... -Wno-sign-compare -fno-asynchronous-unwind-tables -Wframe-address -c -x c /dev/null -o .31392.tmp /dev/null:1:0: error: code model kernel does not support PIC mode because that returns an error and we can't disable the warning. For example in this case: KBUILD_CFLAGS += $(call cc-disable-warning,frame-address,) which leads to gcc issuing all those warnings again. So let's turn off PIE/PIC at the earliest possible moment, when we declare KBUILD_CFLAGS so that cc-disable-warning picks it up too. Also, we need the $(call cc-option ...) because -fno-PIE is supported since gcc v3.4 and our lowest supported gcc version is 3.2 right now. Signed-off-by: Borislav Petkov Cc: Ben Hutchings Cc: Sebastian Andrzej Siewior Signed-off-by: Michal Marek Signed-off-by: Greg Kroah-Hartman commit e14754cb8f0cbd32db8239fcf5f4e15b17ae9444 Author: Sebastian Andrzej Siewior Date: Fri Nov 4 19:39:40 2016 +0100 x86/kexec: add -fno-PIE commit 90944e40ba1838de4b2a9290cf273f9d76bd3bdd upstream. If the gcc is configured to do -fPIE by default then the build aborts later with: | Unsupported relocation type: unknown type rel type name (29) Tagging it stable so it is possible to compile recent stable kernels as well. Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Michal Marek Signed-off-by: Greg Kroah-Hartman commit ad4e2f324adec03341094acc54f9e20f1451923d Author: Sebastian Andrzej Siewior Date: Fri Nov 4 19:39:39 2016 +0100 scripts/has-stack-protector: add -fno-PIE commit 82031ea29e454b574bc6f49a33683a693ca5d907 upstream. Adding -no-PIE to the fstack protector check. -no-PIE was introduced before -fstack-protector so there is no need for a runtime check. Without it the build stops: |Cannot use CONFIG_CC_STACKPROTECTOR_STRONG: -fstack-protector-strong available but compiler is broken due to -mcmodel=kernel + -fPIE if -fPIE is enabled by default. Tagging it stable so it is possible to compile recent stable kernels as well. Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Michal Marek Signed-off-by: Greg Kroah-Hartman commit 1c7727d0bca0c620850834d8e4913a1f5bdc6cb7 Author: Sebastian Andrzej Siewior Date: Fri Nov 4 19:39:38 2016 +0100 kbuild: add -fno-PIE commit 8ae94224c9d72fc4d9aaac93b2d7833cf46d7141 upstream. Debian started to build the gcc with -fPIE by default so the kernel build ends before it starts properly with: |kernel/bounds.c:1:0: error: code model kernel does not support PIC mode Also add to KBUILD_AFLAGS due to: |gcc -Wp,-MD,arch/x86/entry/vdso/vdso32/.note.o.d … -mfentry -DCC_USING_FENTRY … vdso/vdso32/note.S |arch/x86/entry/vdso/vdso32/note.S:1:0: sorry, unimplemented: -mfentry isn’t supported for 32-bit in combination with -fpic Tagging it stable so it is possible to compile recent stable kernels as well. Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Michal Marek Signed-off-by: Greg Kroah-Hartman commit 20bcbe24693359b3ecb64366f0dc0368498915d7 Author: Linus Torvalds Date: Wed Oct 12 10:23:41 2016 -0700 Disable the __builtin_return_address() warning globally after all commit ef6000b4c6706cbb1787836442b5a74542b1809f upstream. This affectively reverts commit 377ccbb48373 ("Makefile: Mute warning for __builtin_return_address(>0) for tracing only") because it turns out that it really isn't tracing only - it's all over the tree. We already also had the warning disabled separately for mm/usercopy.c (which this commit also removes), and it turns out that we will also want to disable it for get_lock_parent_ip(), that is used for at least TRACE_IRQFLAGS. Which (when enabled) ends up being all over the tree. Steven Rostedt had a patch that tried to limit it to just the config options that actually triggered this, but quite frankly, the extra complexity and abstraction just isn't worth it. We have never actually had a case where the warning is actually useful, so let's just disable it globally and not worry about it. Acked-by: Steven Rostedt Cc: Thomas Gleixner Cc: Andrew Morton Cc: Ingo Molnar Cc: Peter Anvin Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 504b60516ba796e1b73a16b3fe3520ce73935401 Author: Alex Hemme Date: Sat Nov 19 10:48:38 2016 +0100 i2c: i2c-mux-pca954x: fix deselect enabling for device-tree commit ad092de60f865c1ad94221bd06d381ecea446cc8 upstream. Deselect functionality can be ignored for device-trees with "i2c-mux-idle-disconnect" entries if no platform_data is available. By enabling the deselect functionality outside the platform_data block the logic works as it did in previous kernels. Fixes: 7fcac9807175 ("i2c: i2c-mux-pca954x: convert to use an explicit i2c mux core") Signed-off-by: Alex Hemme Signed-off-by: Ziyang Wu [touched up a few minor issues /peda] Signed-off-by: Peter Rosin Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit 45244660281c9a5b802e2e0ea012c7955a76741e Author: Linus Walleij Date: Mon Nov 14 15:34:17 2016 +0100 i2c: mux: fix up dependencies commit 93d710a65ef02fb7fd48ae207e78f460bd7a6089 upstream. We get the following build error from UM Linux after adding an entry to drivers/iio/gyro/Kconfig that issues "select I2C_MUX": ERROR: "devm_ioremap_resource" [drivers/i2c/muxes/i2c-mux-reg.ko] undefined! ERROR: "of_address_to_resource" [drivers/i2c/muxes/i2c-mux-reg.ko] undefined! It appears that the I2C mux core code depends on HAS_IOMEM for historical reasons, while CONFIG_I2C_MUX_REG does *not* have a direct dependency on HAS_IOMEM. This creates a situation where a allyesconfig or allmodconfig for UM Linux will select I2C_MUX, and will implicitly enable I2C_MUX_REG as well, and the compilation will fail for the register driver. Fix this up by making I2C_MUX_REG depend on HAS_IOMEM and removing the dependency from I2C_MUX. Reported-by: kbuild test robot Reported-by: Jonathan Cameron Signed-off-by: Linus Walleij Acked-by: Jonathan Cameron Acked-by: Peter Rosin Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit ce97f5012b6d1c42507116bc62bdb61763cd3986 Author: Takashi Iwai Date: Fri Nov 11 12:33:20 2016 +0100 ALSA: hda - Fix mic regression by ASRock mobo fixup commit 9a2541910dc7eaaa6859eea8a0ffda673059a623 upstream. The commit [1a3f099101b8: ALSA: hda - Fix surround output pins for ASRock B150M mobo] introduced a fixup of pin configs for ASRock mobos to fix the surround outputs. However, this overrides the pin configs of the mic pins as if they are outputs-only, effectively disabling the mic inputs. Of course, it's a regression wrt mic functionality. Actually the pins 0x18 and 0x1a don't need to be changed; we just need to disable the bogus pins 0x14 and 0x15. Then the auto-parser will pick up mic pins as switchable and assign the surround outputs there. This patch removes the incorrect pin overrides of NID 0x18 and 0x1a from the ASRock fixup. Fixes: 1a3f099101b8 ('ALSA: hda - Fix surround output pins for ASRock...') Reported-and-tested-by: Vitor Antunes Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=187431 Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 23e14ee1abcf22341f8c235400a055829d21a343 Author: Hui Wang Date: Thu Nov 10 13:20:05 2016 +0800 ALSA: hda - add a new condition to check if it is thinkpad commit 2ecb704a1290edb5e3d53a75529192e7ed2a1a28 upstream. Latest Thinkpad laptops use the HKEY_HID LEN0268 instead of the LEN0068, as a result neither audio mute led nor mic mute led can work any more. After adding the new HKEY_HID into the is_thinkpad(), both of them works well as before. Signed-off-by: Hui Wang Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 85fcb62a58b281e3bed60ecdc34d1559ba06c9c1 Author: Takashi Iwai Date: Mon Nov 14 21:46:47 2016 +0100 ALSA: usb-audio: Fix use-after-free of usb_device at disconnect commit 6ff1a25318ebf688ef9593fe09cd449f6fb4ad31 upstream. The usb-audio driver implements the deferred device disconnection for the device in use. In this mode, the disconnection callback returns immediately while the actual ALSA card object removal happens later when all files get closed. As Shuah reported, this code flow, however, leads to a use-after-free, detected by KASAN: BUG: KASAN: use-after-free in snd_usb_audio_free+0x134/0x160 [snd_usb_audio] at addr ffff8801c863ce10 Write of size 8 by task pulseaudio/2244 Call Trace: [] dump_stack+0x67/0x94 [] kasan_object_err+0x21/0x70 [] kasan_report_error+0x1fa/0x4e0 [] ? kasan_slab_free+0x87/0xb0 [] __asan_report_store8_noabort+0x43/0x50 [] ? snd_usb_audio_free+0x134/0x160 [snd_usb_audio] [] snd_usb_audio_free+0x134/0x160 [snd_usb_audio] [] snd_usb_audio_dev_free+0x31/0x40 [snd_usb_audio] [] __snd_device_free+0x12a/0x210 [] snd_device_free_all+0x85/0xd0 [] release_card_device+0x34/0x130 [] device_release+0x76/0x1e0 [] kobject_release+0x107/0x370 ..... Object at ffff8801c863cc80, in cache kmalloc-2048 size: 2048 Allocated: [] save_stack_trace+0x2b/0x50 [] save_stack+0x46/0xd0 [] kasan_kmalloc+0xad/0xe0 [] kmem_cache_alloc_trace+0xfa/0x240 [] usb_alloc_dev+0x57/0xc90 [] hub_event+0xf1d/0x35f0 .... Freed: [] save_stack_trace+0x2b/0x50 [] save_stack+0x46/0xd0 [] kasan_slab_free+0x71/0xb0 [] kfree+0xd9/0x280 [] usb_release_dev+0xde/0x110 [] device_release+0x76/0x1e0 .... It's the code trying to clear drvdata of the assigned usb_device where the usb_device itself was already released in usb_release_dev() after the disconnect callback. This patch fixes it by checking whether the code path is via the disconnect callback, i.e. chip->shutdown flag is set. Fixes: 79289e24194a ('ALSA: usb-audio: Refer to chip->usb_id for quirks...') Reported-and-tested-by: Shuah Khan Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit e902f10da218c4af481337ed2a090c9bdf739630 Author: Linus Walleij Date: Sat Nov 12 15:01:09 2016 +0100 gpio: do not double-check direction on sleeping chips commit 60f8339eb388df8a46f8eb4282ff0e15f08f218c upstream. When locking a GPIO line as IRQ, we go to lengths to double-check that the line is really set as input before marking it as used for IRQ. This is not good on GPIO chips that can sleep, because this function is called in IRQ-safe context. Just skip this if it can't be checked quickly. Currently this happens on sleeping expanders such as STMPE or TC3589x: BUG: scheduling while atomic: swapper/1/0x00000002 Modules linked in: CPU: 0 PID: 1 Comm: swapper Not tainted 4.9.0-rc1+ #38 Hardware name: Nomadik STn8815 [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [] (show_stack) from [] (__schedule_bug+0x54/0x80) [] (__schedule_bug) from [] (__schedule+0x3a0/0x460) [] (__schedule) from [] (schedule+0x54/0xb8) (...) This patch fixes that problem and relies on the direction read from the chip when it was added. Fixes: 9c10280d85c1 ("gpio: flush direction status in gpiochip_lock_as_irq()") Cc: Patrice Chotard Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit b21b327d96bcfdd45ac22f2a55115291cf0fb6c4 Author: Oliver Hartkopp Date: Mon Oct 24 21:11:26 2016 +0200 can: bcm: fix warning in bcm_connect/proc_register commit deb507f91f1adbf64317ad24ac46c56eeccfb754 upstream. Andrey Konovalov reported an issue with proc_register in bcm.c. As suggested by Cong Wang this patch adds a lock_sock() protection and a check for unsuccessful proc_create_data() in bcm_connect(). Reference: http://marc.info/?l=linux-netdev&m=147732648731237 Reported-by: Andrey Konovalov Suggested-by: Cong Wang Signed-off-by: Oliver Hartkopp Acked-by: Cong Wang Tested-by: Andrey Konovalov Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 50e6cd2feff75eedcfaa0a23be6f08fe8410aab0 Author: Linus Walleij Date: Tue Nov 1 10:22:53 2016 +0100 mfd: stmpe: Fix RESET regression on STMPE2401 commit f40584200bc4af7aa4399635b9ac213c62a13ae7 upstream. Since commit c4dd1ba355aae2bc3d1213da6c66c53e3c31e028 ("mfd: stmpe: Add reset support for all STMPE variant") we're resetting the STMPE expanders before use. This caused a regression on the STMP2401 on the Nomadik NHK8815: stmpe-i2c 0-0043: stmpe2401 detected, chip id: 0x101 nmk-i2c 101f8000.i2c0: write to slave 0x43 timed out nmk-i2c 101f8000.i2c0: no ack received after address transmission stmpe-i2c 0-0044: stmpe2401 detected, chip id: 0x101 nmk-i2c 101f8000.i2c0: write to slave 0x44 timed out nmk-i2c 101f8000.i2c0: no ack received after address transmission It turns out that we start to poll for the reset bit to go low again too quickly: the STMPE2401 is not yet online and ready to be asked for the status of the RESET bit. By introducing a 10ms delay before starting to hammer the register for information, we get back to normal: stmpe-i2c 0-0043: stmpe2401 detected, chip id: 0x101 stmpe-i2c 0-0044: stmpe2401 detected, chip id: 0x101 Cc: Amelie Delaunay Fixes: c4dd1ba355aa ("mfd: stmpe: Add reset support for all STMPE variant") Signed-off-by: Linus Walleij Acked-by: Patrice Chotard Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit e015527c6fbdf9778853c91a0307aadc83be80eb Author: Azhar Shaikh Date: Wed Oct 12 10:12:20 2016 -0700 mfd: intel-lpss: Do not put device in reset state on suspend commit 274e43edcda6f709aa67e436b3123e45a6270923 upstream. Commit 41a3da2b8e163 ("mfd: intel-lpss: Save register context on suspend") saved the register context while going to suspend and also put the device in reset state. Due to the resetting of device, system cannot enter S3/S0ix states when no_console_suspend flag is enabled. The system and serial console both hang. The resetting of device is not needed while going to suspend. Hence remove this code. Fixes: 41a3da2b8e163 ("mfd: intel-lpss: Save register context on suspend") Signed-off-by: Azhar Shaikh Acked-by: Mika Westerberg Reviewed-by: Andy Shevchenko Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit 8b4d44f46bf22c7b77fdc91ed668c50261f9b536 Author: Ira Weiny Date: Mon Oct 17 04:20:09 2016 -0700 IB/hfi1: Fix rnr_timer addition commit 458ed666fe14a54dfb6690a1a7f541782d1342c9 upstream. The new s_rnr_timeout was not properly being set and the code was incorrectly setting a different timer. Found by code inspection. Fixes: 08279d5c9424 ("staging/rdma/hfi1: use new RNR timer") Reviewed-by: Mike Marciniszyn Signed-off-by: Ira Weiny Signed-off-by: Dennis Dalessandro Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit 06eac15f11e014e471f1486fa47817d3a3697b4d Author: Dennis Dalessandro Date: Mon Oct 10 06:14:45 2016 -0700 IB/rdmavt: rdmavt can handle non aligned page maps commit e1fafdcbe0e3e769c6a83317dd845bc99b4fe61d upstream. The initial code for rdmavt carried with it a restriction that was a vestige from the qib driver, that to dma map a page it had to be less than a page size. This is not the case on modern hardware, both qib and hfi1 will be just fine with unaligned map requests. This fixes a 4.8 regression where by an IPoIB transfer of > PAGE_SIZE will hang because the dma map page call always fails. This was introduced after commit 5faba5469522 ("IB/ipoib: Report SG feature regardless of HW UD CSUM capability") added the capability to use SG by default. Rather than override this, the HW supports it, so allow SG. Reviewed-by: Mike Marciniszyn Signed-off-by: Dennis Dalessandro Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit ca720a2b11b4c90d1798b406d3c191cd5395b5e3 Author: Miklos Szeredi Date: Thu Aug 18 09:10:44 2016 +0200 fuse: fix fuse_write_end() if zero bytes were copied commit 59c3b76cc61d1d676f965c192cc7969aa5cb2744 upstream. If pos is at the beginning of a page and copied is zero then page is not zeroed but is marked uptodate. Fix by skipping everything except unlock/put of page if zero bytes were copied. Reported-by: Al Viro Fixes: 6b12c1b37e55 ("fuse: Implement write_begin/write_end callbacks") Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit de58c50e84e27ede34b509ad900414e43da5721a Author: Thomas Gleixner Date: Mon Nov 7 19:57:00 2016 +0100 genirq: Use irq type from irqdata instead of irqdesc commit 7ee7e87dfb158e79019ea1d5ea1b0e6f2bc93ee4 upstream. The type flags in the irq descriptor are there for historical reasons and only updated via irq_modify_status() or irq_set_type(). Both functions also update the type flags in irqdata. __setup_irq() is the only left over user of the type flags in the irq descriptor. If __setup_irq() is called with empty irq type flags, then the type flags are retrieved from irqdata. If an interrupt is shared, then the type flags are compared with the type flags stored in the irq descriptor. On x86 the ioapic does not have a irq_set_type() callback because the type is defined in the BIOS tables and cannot be changed. The type is stored in irqdata at setup time without updating the type data in the irq descriptor. As a result the comparison described above fails. There is no point in updating the irq descriptor flags because the only relevant storage is irqdata. Use the type flags from irqdata for both retrieval and comparison in __setup_irq() instead. Aside of that the print out in case of non matching type flags has the old and new type flags arguments flipped. Fix that as well. For correctness sake the flags stored in the irq descriptor should be removed, but this is beyond the scope of this bugfix and will be done in a later patch. Fixes: 4b357daed698 ("genirq: Look-up trigger type if not specified by caller") Reported-and-tested-by: Mika Westerberg Signed-off-by: Thomas Gleixner Cc: Marc Zyngier Cc: Jon Hunter Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1611072020360.3501@nanos Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 8844024c883972fe9ce983a60cd9cc55cfb073ae Author: Steven Rostedt (Red Hat) Date: Mon Nov 14 16:31:49 2016 -0500 ftrace: Add more checks for FTRACE_FL_DISABLED in processing ip records commit 546fece4eae871f033925ccf0ff2b740725ae915 upstream. When a module is first loaded and its function ip records are added to the ftrace list of functions to modify, they are set to DISABLED, as their text is still in a read only state. When the module is fully loaded, and can be updated, the flag is cleared, and if their's any functions that should be tracing them, it is updated at that moment. But there's several locations that do record accounting and should ignore records that are marked as disabled, or they can cause issues. Alexei already fixed one location, but others need to be addressed. Fixes: b7ffffbb46f2 "ftrace: Add infrastructure for delayed enabling of module functions" Reported-by: Alexei Starovoitov Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit c5d20ce0b459b6e2d00f58b599543eb0e8e725e4 Author: Alexei Starovoitov Date: Mon Nov 7 15:14:20 2016 -0800 ftrace: Ignore FTRACE_FL_DISABLED while walking dyn_ftrace records commit 977c1f9c8c022d0173181766b34a0db3705265a4 upstream. ftrace_shutdown() checks for sanity of ftrace records and if dyn_ftrace->flags is not zero, it will warn. It can happen that 'flags' are set to FTRACE_FL_DISABLED at this point, since some module was loaded, but before ftrace_module_enable() cleared the flags for this module. In other words the module.c is doing: ftrace_module_init(mod); // calls ftrace_update_code() that sets flags=FTRACE_FL_DISABLED ... // here ftrace_shutdown() is called that warns, since err = prepare_coming_module(mod); // didn't have a chance to clear FTRACE_FL_DISABLED Fix it by ignoring disabled records. It's similar to what __ftrace_hash_rec_update() is already doing. Link: http://lkml.kernel.org/r/1478560460-3818619-1-git-send-email-ast@fb.com Fixes: b7ffffbb46f2 "ftrace: Add infrastructure for delayed enabling of module functions" Signed-off-by: Alexei Starovoitov Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit f271087fb2ea6eb4352340893225655f6ab491d0 Author: Wei Huang Date: Wed Nov 16 11:09:20 2016 -0600 KVM: arm64: Fix the issues when guest PMCCFILTR is configured commit b112c84a6ff035271d41d548c10215f18443d6a6 upstream. KVM calls kvm_pmu_set_counter_event_type() when PMCCFILTR is configured. But this function can't deals with PMCCFILTR correctly because the evtCount bits of PMCCFILTR, which is reserved 0, conflits with the SW_INCR event type of other PMXEVTYPER registers. To fix it, when eventsel == 0, this function shouldn't return immediately; instead it needs to check further if select_idx is ARMV8_PMU_CYCLE_IDX. Another issue is that KVM shouldn't copy the eventsel bits of PMCCFILTER blindly to attr.config. Instead it ought to convert the request to the "cpu cycle" event type (i.e. 0x11). To support this patch and to prevent duplicated definitions, a limited set of ARMv8 perf event types were relocated from perf_event.c to asm/perf_event.h. Acked-by: Will Deacon Signed-off-by: Wei Huang Signed-off-by: Marc Zyngier Signed-off-by: Greg Kroah-Hartman commit 8d8b37e242decffb789cd86f501100dd881ded10 Author: Wei Huang Date: Wed Nov 16 09:20:57 2016 +0000 arm64: KVM: pmu: Fix AArch32 cycle counter access commit 9e3f7a29694049edd728e2400ab57ad7553e5aa9 upstream. We're missing the handling code for the cycle counter accessed from a 32bit guest, leading to unexpected results. Signed-off-by: Wei Huang Signed-off-by: Marc Zyngier Signed-off-by: Greg Kroah-Hartman commit 1cb9b2489e778b4f0d97a98ef35be00b2498d94d Author: Ignacio Alvarado Date: Fri Nov 4 12:15:55 2016 -0700 KVM: Disable irq while unregistering user notifier commit 1650b4ebc99da4c137bfbfc531be4a2405f951dd upstream. Function user_notifier_unregister should be called only once for each registered user notifier. Function kvm_arch_hardware_disable can be executed from an IPI context which could cause a race condition with a VCPU returning to user mode and attempting to unregister the notifier. Signed-off-by: Ignacio Alvarado Fixes: 18863bdd60f8 ("KVM: x86 shared msr infrastructure") Reviewed-by: Paolo Bonzini Signed-off-by: Radim Krčmář Signed-off-by: Greg Kroah-Hartman commit 23555ca21394c0f5a146c891128bd4edc3e78862 Author: Paolo Bonzini Date: Thu Nov 17 15:55:46 2016 +0100 KVM: x86: fix missed SRCU usage in kvm_lapic_set_vapic_addr commit 7301d6abaea926d685832f7e1f0c37dd206b01f4 upstream. Reported by syzkaller: [ INFO: suspicious RCU usage. ] 4.9.0-rc4+ #47 Not tainted ------------------------------- ./include/linux/kvm_host.h:536 suspicious rcu_dereference_check() usage! stack backtrace: CPU: 1 PID: 6679 Comm: syz-executor Not tainted 4.9.0-rc4+ #47 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 ffff880039e2f6d0 ffffffff81c2e46b ffff88003e3a5b40 0000000000000000 0000000000000001 ffffffff83215600 ffff880039e2f700 ffffffff81334ea9 ffffc9000730b000 0000000000000004 ffff88003c4f8420 ffff88003d3f8000 Call Trace: [< inline >] __dump_stack lib/dump_stack.c:15 [] dump_stack+0xb3/0x118 lib/dump_stack.c:51 [] lockdep_rcu_suspicious+0x139/0x180 kernel/locking/lockdep.c:4445 [< inline >] __kvm_memslots include/linux/kvm_host.h:534 [< inline >] kvm_memslots include/linux/kvm_host.h:541 [] kvm_gfn_to_hva_cache_init+0xa1e/0xce0 virt/kvm/kvm_main.c:1941 [] kvm_lapic_set_vapic_addr+0xed/0x140 arch/x86/kvm/lapic.c:2217 Reported-by: Dmitry Vyukov Fixes: fda4e2e85589191b123d31cdc21fd33ee70f50fd Cc: Andrew Honig Signed-off-by: Paolo Bonzini Reviewed-by: David Hildenbrand Signed-off-by: Radim Krčmář Signed-off-by: Greg Kroah-Hartman commit f8c74cf95655e814d253307283561cf2d47398df Author: Yazen Ghannam Date: Tue Nov 8 09:35:06 2016 +0100 x86/cpu/AMD: Fix cpu_llc_id for AMD Fam17h systems commit b0b6e86846093c5f8820386bc01515f857dd8faa upstream. cpu_llc_id (Last Level Cache ID) derivation on AMD Fam17h has an underflow bug when extracting the socket_id value. It starts from 0 so subtracting 1 from it will result in an invalid value. This breaks scheduling topology later on since the cpu_llc_id will be incorrect. For example, the the cpu_llc_id of the *other* CPU in the loops in set_cpu_sibling_map() underflows and we're generating the funniest thread_siblings masks and then when I run 8 threads of nbench, they get spread around the LLC domains in a very strange pattern which doesn't give you the normal scheduling spread one would expect for performance. Other things like EDAC use cpu_llc_id so they will be b0rked too. So, the APIC ID is preset in APICx020 for bits 3 and above: they contain the core complex, node and socket IDs. The LLC is at the core complex level so we can find a unique cpu_llc_id by right shifting the APICID by 3 because then the least significant bit will be the Core Complex ID. Tested-by: Borislav Petkov Signed-off-by: Yazen Ghannam [ Cleaned up and extended the commit message. ] Signed-off-by: Borislav Petkov Acked-by: Thomas Gleixner Cc: Aravind Gopalakrishnan Cc: Linus Torvalds Cc: Peter Zijlstra Fixes: 3849e91f571d ("x86/AMD: Fix last level cache topology for AMD Fam17h systems") Link: http://lkml.kernel.org/r/20161108083506.rvqb5h4chrcptj7d@pd.tnic Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman