AgeCommit message (Collapse)Author
2016-11-26perf hists: Fix column length on --hierarchyNamhyung Kim
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: Signed-off-by: Arnaldo Carvalho de Melo <> Signed-off-by: Greg Kroah-Hartman <>
2016-11-26PM / sleep: don't suspend parent when async child suspend_{noirq, late} failsBrian Norris
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 <>
2016-11-26PM / sleep: fix device reference leak in test_suspendJohan Hovold
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 <>
2016-11-26uwb: fix device reference leaksJohan Hovold
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 <>
2016-11-26sunrpc: svc_age_temp_xprts_now should not call setsockopt non-tcp transportsScott Mayhew
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:[<ffffffff8168d847>] [<ffffffff8168d847>] _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: [<ffffffff81557830>] lock_sock_nested+0x20/0x50 [<ffffffff8155ae08>] sock_setsockopt+0x78/0x940 [<ffffffff81096acb>] ? lock_timer_base.isra.33+0x2b/0x50 [<ffffffff8155397d>] kernel_setsockopt+0x4d/0x50 [<ffffffffa0386284>] svc_age_temp_xprts_now+0x174/0x1e0 [sunrpc] [<ffffffffa03b681d>] nfsd_inetaddr_event+0x9d/0xd0 [nfsd] [<ffffffff81691ebc>] notifier_call_chain+0x4c/0x70 [<ffffffff810b687d>] __blocking_notifier_call_chain+0x4d/0x70 [<ffffffff810b68b6>] blocking_notifier_call_chain+0x16/0x20 [<ffffffff815e8538>] __inet_del_ifa+0x168/0x2d0 [<ffffffff815e8cef>] check_lifetime+0x25f/0x270 [<ffffffff810a7f3b>] process_one_work+0x17b/0x470 [<ffffffff810a8d76>] worker_thread+0x126/0x410 [<ffffffff810a8c50>] ? rescuer_thread+0x460/0x460 [<ffffffff810b052f>] kthread+0xcf/0xe0 [<ffffffff810b0460>] ? kthread_create_on_node+0x140/0x140 [<ffffffff81696418>] ret_from_fork+0x58/0x90 [<ffffffff810b0460>] ? 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 <f0> 0f c1 03 89 c2 c1 ea 10 66 39 c2 75 03 5b 5d c3 83 e2 fe 0f RIP [<ffffffff8168d847>] _raw_spin_lock_bh+0x17/0x50 RSP <ffff88031f587ba8> 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 <>
2016-11-26mfd: core: Fix device reference leak in mfd_clone_cellJohan Hovold
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 <>
2016-11-26iwlwifi: mvm: wake the wait queue when the RX sync counter is zeroSara Sharon
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 <>
2016-11-26iwlwifi: mvm: fix d3_test with unified D0/D3 imagesLuca Coelho
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 <>
2016-11-26iwlwifi: mvm: fix netdetect starting/stopping for unified imagesLuca Coelho
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 <>
2016-11-26iwlwifi: pcie: mark command queue lock with separate lockdep classJohannes Berg
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 <>
2016-11-26iwlwifi: pcie: fix SPLC structure parsingLuca Coelho
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 <>
2016-11-26rtc: omap: Fix selecting external oscLokesh Vutla
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 <>
2016-11-26clk: imx: fix integer overflow in AV PLL round rateEmil Lundmark
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 <>
2016-11-26clk: mmp: mmp2: fix return value check in mmp2_clk_init()Wei Yongjun
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 <>
2016-11-26clk: mmp: pxa168: fix return value check in pxa168_clk_init()Wei Yongjun
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 <>
2016-11-26clk: mmp: pxa910: fix return value check in pxa910_clk_init()Wei Yongjun
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 <>
2016-11-26virtio-net: drop legacy features in virtio 1 modeMichael S. Tsirkin
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 <>
2016-11-26drm/i915: Assume non-DP++ port if dvo_port is HDMI and there's no AUX ch ↵Ville Syrjälä
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: Signed-off-by: Ville Syrjälä <> Link: Reviewed-by: Daniel Vetter <> (cherry picked from commit 7a17995a3dc8613f778a9e2fd20e870f17789544) Signed-off-by: Jani Nikula <> Signed-off-by: Greg Kroah-Hartman <>
2016-11-26drm/i915: Refresh that status of MST capable connectors in ->detect()Ville Syrjälä
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: Cc: Rui Tiago Matos <> Tested-by: Rui Tiago Matos <> Bugzilla: Cc: Kirill A. Shutemov <> Tested-by: Kirill A. Shutemov <> References: Fixes: 1015811609c0 ("drm/i915: Move long hpd handling into the hotplug work") Signed-off-by: Ville Syrjälä <> Link: Reviewed-by: Chris Wilson <> (cherry picked from commit 1aab956c7b8872fb6976328316bfad62c6e67cf8) Signed-off-by: Jani Nikula <> Signed-off-by: Greg Kroah-Hartman <>
2016-11-26drm/amdgpu: Attach exclusive fence to prime exported bo's. (v5)Mario Kleiner
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: 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: 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 <>
2016-11-26powerpc/64: Fix setting of AIL in hypervisor modeBenjamin Herrenschmidt
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 <>
2016-11-26crypto: caam - do not register AES-XTS mode on LP unitsSven Ebenfeld
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 <>
2016-11-26ARM: dts: imx53-qsb: Fix regulator constraintsFabio Estevam
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 <>
2016-11-26ext4: sanity check the block and cluster size at mount timeTheodore Ts'o
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: Ref: Reported-by: Borislav Petkov <> Reported-by: Nikolay Borisov <> Signed-off-by: Theodore Ts'o <> Signed-off-by: Greg Kroah-Hartman <>
2016-11-26kbuild: Steal gcc's pie from the very beginningBorislav Petkov
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 <>
2016-11-26x86/kexec: add -fno-PIESebastian Andrzej Siewior
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 <>
2016-11-26scripts/has-stack-protector: add -fno-PIESebastian Andrzej Siewior
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 <>
2016-11-26kbuild: add -fno-PIESebastian Andrzej Siewior
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 <>
2016-11-26Disable the __builtin_return_address() warning globally after allLinus Torvalds
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 <>
2016-11-26i2c: i2c-mux-pca954x: fix deselect enabling for device-treeAlex Hemme
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 <>
2016-11-26i2c: mux: fix up dependenciesLinus Walleij
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 <>
2016-11-26ALSA: hda - Fix mic regression by ASRock mobo fixupTakashi Iwai
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: Signed-off-by: Takashi Iwai <> Signed-off-by: Greg Kroah-Hartman <>
2016-11-26ALSA: hda - add a new condition to check if it is thinkpadHui Wang
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 <>
2016-11-26ALSA: usb-audio: Fix use-after-free of usb_device at disconnectTakashi Iwai
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: [<ffffffff81b31473>] dump_stack+0x67/0x94 [<ffffffff81564ef1>] kasan_object_err+0x21/0x70 [<ffffffff8156518a>] kasan_report_error+0x1fa/0x4e0 [<ffffffff81564ad7>] ? kasan_slab_free+0x87/0xb0 [<ffffffff81565733>] __asan_report_store8_noabort+0x43/0x50 [<ffffffffa0fc0f54>] ? snd_usb_audio_free+0x134/0x160 [snd_usb_audio] [<ffffffffa0fc0f54>] snd_usb_audio_free+0x134/0x160 [snd_usb_audio] [<ffffffffa0fc0fb1>] snd_usb_audio_dev_free+0x31/0x40 [snd_usb_audio] [<ffffffff8243c78a>] __snd_device_free+0x12a/0x210 [<ffffffff8243d1f5>] snd_device_free_all+0x85/0xd0 [<ffffffff8242cae4>] release_card_device+0x34/0x130 [<ffffffff81ef1846>] device_release+0x76/0x1e0 [<ffffffff81b37ad7>] kobject_release+0x107/0x370 ..... Object at ffff8801c863cc80, in cache kmalloc-2048 size: 2048 Allocated: [<ffffffff810804eb>] save_stack_trace+0x2b/0x50 [<ffffffff81564296>] save_stack+0x46/0xd0 [<ffffffff8156450d>] kasan_kmalloc+0xad/0xe0 [<ffffffff81560d1a>] kmem_cache_alloc_trace+0xfa/0x240 [<ffffffff8214ea47>] usb_alloc_dev+0x57/0xc90 [<ffffffff8216349d>] hub_event+0xf1d/0x35f0 .... Freed: [<ffffffff810804eb>] save_stack_trace+0x2b/0x50 [<ffffffff81564296>] save_stack+0x46/0xd0 [<ffffffff81564ac1>] kasan_slab_free+0x71/0xb0 [<ffffffff81560929>] kfree+0xd9/0x280 [<ffffffff8214de6e>] usb_release_dev+0xde/0x110 [<ffffffff81ef1846>] 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 <>
2016-11-26gpio: do not double-check direction on sleeping chipsLinus Walleij
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 [<c000f2e0>] (unwind_backtrace) from [<c000d244>] (show_stack+0x10/0x14) [<c000d244>] (show_stack) from [<c0037b78>] (__schedule_bug+0x54/0x80) [<c0037b78>] (__schedule_bug) from [<c042df14>] (__schedule+0x3a0/0x460) [<c042df14>] (__schedule) from [<c042e028>] (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 <>
2016-11-26can: bcm: fix warning in bcm_connect/proc_registerOliver Hartkopp
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: 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 <>
2016-11-26mfd: stmpe: Fix RESET regression on STMPE2401Linus Walleij
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 <>
2016-11-26mfd: intel-lpss: Do not put device in reset state on suspendAzhar Shaikh
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 <>
2016-11-26IB/hfi1: Fix rnr_timer additionIra Weiny
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 <>
2016-11-26IB/rdmavt: rdmavt can handle non aligned page mapsDennis Dalessandro
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 <>
2016-11-26fuse: fix fuse_write_end() if zero bytes were copiedMiklos Szeredi
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 <>
2016-11-26genirq: Use irq type from irqdata instead of irqdescThomas Gleixner
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: Signed-off-by: Thomas Gleixner <> Signed-off-by: Greg Kroah-Hartman <>
2016-11-26ftrace: Add more checks for FTRACE_FL_DISABLED in processing ip recordsSteven Rostedt (Red Hat)
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 <>
2016-11-26ftrace: Ignore FTRACE_FL_DISABLED while walking dyn_ftrace recordsAlexei Starovoitov
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: 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 <>
2016-11-26KVM: arm64: Fix the issues when guest PMCCFILTR is configuredWei Huang
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<n> 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 <>
2016-11-26arm64: KVM: pmu: Fix AArch32 cycle counter accessWei Huang
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 <>
2016-11-26KVM: Disable irq while unregistering user notifierIgnacio Alvarado
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 <>
2016-11-26KVM: x86: fix missed SRCU usage in kvm_lapic_set_vapic_addrPaolo Bonzini
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 [<ffffffff81c2e46b>] dump_stack+0xb3/0x118 lib/dump_stack.c:51 [<ffffffff81334ea9>] 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 [<ffffffff8105d6ae>] kvm_gfn_to_hva_cache_init+0xa1e/0xce0 virt/kvm/kvm_main.c:1941 [<ffffffff8112685d>] 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 <>
2016-11-26x86/cpu/AMD: Fix cpu_llc_id for AMD Fam17h systemsYazen Ghannam
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: Signed-off-by: Ingo Molnar <> Signed-off-by: Greg Kroah-Hartman <>
2016-11-21Linux 4.8.10Greg Kroah-Hartman