summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2018-11-28s390/qeth: fix length check in SNMP processingJulian Wiedmann
The response for a SNMP request can consist of multiple parts, which the cmd callback stages into a kernel buffer until all parts have been received. If the callback detects that the staging buffer provides insufficient space, it bails out with error. This processing is buggy for the first part of the response - while it initially checks for a length of 'data_len', it later copies an additional amount of 'offsetof(struct qeth_snmp_cmd, data)' bytes. Fix the calculation of 'data_len' for the first part of the response. This also nicely cleans up the memcpy code. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com> Reviewed-by: Ursula Braun <ubraun@linux.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-11-28dax: Don't access a freed inodeMatthew Wilcox
After we drop the i_pages lock, the inode can be freed at any time. The get_unlocked_entry() code has no choice but to reacquire the lock, so it can't be used here. Create a new wait_entry_unlocked() which takes care not to acquire the lock or dereference the address_space in any way. Fixes: c2a7d2a11552 ("filesystem-dax: Introduce dax_lock_mapping_entry()") Cc: <stable@vger.kernel.org> Signed-off-by: Matthew Wilcox <willy@infradead.org> Reviewed-by: Jan Kara <jack@suse.cz> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2018-11-28dax: Check page->mapping isn't NULLMatthew Wilcox
If we race with inode destroy, it's possible for page->mapping to be NULL before we even enter this routine, as well as after having slept waiting for the dax entry to become unlocked. Fixes: c2a7d2a11552 ("filesystem-dax: Introduce dax_lock_mapping_entry()") Cc: <stable@vger.kernel.org> Reported-by: Jan Kara <jack@suse.cz> Signed-off-by: Matthew Wilcox <willy@infradead.org> Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de> Reviewed-by: Jan Kara <jack@suse.cz> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2018-11-28Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nfDavid S. Miller
Pablo Neira Ayuso says: ==================== Netfilter fixes for net The following patchset contains Netfilter fixes for net: 1) Disable BH while holding list spinlock in nf_conncount, from Taehee Yoo. 2) List corruption in nf_conncount, also from Taehee. 3) Fix race that results in leaving around an empty list node in nf_conncount, from Taehee Yoo. 4) Proper chain handling for inactive chains from the commit path, from Florian Westphal. This includes a selftest for this. 5) Do duplicate rule handles when replacing rules, also from Florian. 6) Remove net_exit path in xt_RATEEST that results in splat, from Taehee. 7) Possible use-after-free in nft_compat when releasing extensions. From Florian. 8) Memory leak in xt_hashlimit, from Taehee. 9) Call ip_vs_dst_notifier after ipv6_dev_notf, from Xin Long. 10) Fix cttimeout with udplite and gre, from Florian. 11) Preserve oif for IPv6 link-local generated traffic from mangle table, from Alin Nastac. 12) Missing error handling in masquerade notifiers, from Taehee Yoo. 13) Use mutex to protect registration/unregistration of masquerade extensions in order to prevent a race, from Taehee. 14) Incorrect condition check in tree_nodes_free(), also from Taehee. 15) Fix chain counter leak in rule replacement path, from Taehee. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2018-11-28net: hisilicon: remove unexpected free_netdevPan Bian
The net device ndev is freed via free_netdev when failing to register the device. The control flow then jumps to the error handling code block. ndev is used and freed again. Resulting in a use-after-free bug. Signed-off-by: Pan Bian <bianpan2016@163.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-11-28rapidio/rionet: do not free skb before reading its lengthPan Bian
skb is freed via dev_kfree_skb_any, however, skb->len is read then. This may result in a use-after-free bug. Fixes: e6161d64263 ("rapidio/rionet: rework driver initialization and removal") Signed-off-by: Pan Bian <bianpan2016@163.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-11-28scsi: lpfc: fix block guard enablement on SLI3 adaptersMartin Wilck
Since f44ac12f1dcc, BG enablement is tracked with the LPFC_SLI3_BG_ENABLED bit, which is set in lpfc_get_cfgparam before lpfc_sli_config_sli_port() is called. The bit shouldn't be cleared before checking the feature. Based on problem analysis by David Bond. Fixes: f44ac12f1dcc "scsi: lpfc: Memory allocation error during driver start-up on power8" Tested-by: David Bond <dbond@suse.com> Signed-off-by: Martin Wilck <mwilck@suse.com> Cc: stable@vger.kernel.org # 4.17.x Cc: stable@vger.kernel.org # 4.18.x Cc: stable@vger.kernel.org # 4.19.x Reviewed-by: Hannes Reinecke <hare@suse.com> Acked-by: James Smart <jsmart2021@gmail.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2018-11-28ASoC: pcm3168a: Don't disable pcm3168a when CONFIG_PM definedJiada Wang
pcm3168 codec support runtime_[resume|suspend], whenever it is not active, it enters suspend mode, and it's clock and regulators will be disabled. so there is no need to disable them again in remove callback. Otherwise we got following kernel warnings, when unload pcm3168a driver [ 222.257514] unbalanced disables for amp-en-regulator [ 222.262526] ------------[ cut here ]------------ [ 222.267158] WARNING: CPU: 0 PID: 2423 at drivers/regulator/core.c:2264 _regulator_disable+0x28/0x108 [ 222.276291] Modules linked in: [ 222.279343] snd_soc_pcm3168a_i2c(-) [ 222.282916] snd_aloop [ 222.285272] arc4 [ 222.287194] wl18xx [ 222.289289] wlcore [ 222.291385] mac80211 [ 222.293654] cfg80211 [ 222.295923] aes_ce_blk [ 222.298366] crypto_simd [ 222.300896] cryptd [ 222.302992] aes_ce_cipher [ 222.305696] crc32_ce [ 222.307965] ghash_ce [ 222.310234] aes_arm64 [ 222.312590] gf128mul [ 222.314860] snd_soc_rcar [ 222.317476] sha2_ce [ 222.319658] xhci_plat_hcd [ 222.322362] sha256_arm64 [ 222.324978] xhci_hcd [ 222.327247] sha1_ce [ 222.329430] renesas_usbhs [ 222.332133] evdev [ 222.334142] sha1_generic [ 222.336758] rcar_gen3_thermal [ 222.339810] cpufreq_dt [ 222.342253] ravb_streaming(C) [ 222.345304] wlcore_sdio [ 222.347834] thermal_sys [ 222.350363] udc_core [ 222.352632] mch_core(C) [ 222.355161] usb_dmac [ 222.357430] snd_soc_pcm3168a [ 222.360394] snd_soc_ak4613 [ 222.363184] gpio_keys [ 222.365540] virt_dma [ 222.367809] nfsd [ 222.369730] ipv6 [ 222.371652] autofs4 [ 222.373834] [last unloaded: snd_soc_pcm3168a_i2c] [ 222.378629] CPU: 0 PID: 2423 Comm: rmmod Tainted: G WC 4.14.63-04798-gd456126e4a42-dirty #457 [ 222.388196] Hardware name: Renesas H3ULCB Kingfisher board based on r8a7795 ES2.0+ (DT) [ 222.396199] task: ffff8006fa8c6200 task.stack: ffff00000a0a0000 [ 222.402117] PC is at _regulator_disable+0x28/0x108 [ 222.406906] LR is at _regulator_disable+0x28/0x108 [ 222.411695] pc : [<ffff0000083bd89c>] lr : [<ffff0000083bd89c>] pstate: 00000145 [ 222.419089] sp : ffff00000a0a3c80 [ 222.422401] x29: ffff00000a0a3c80 [ 222.425799] x28: ffff8006fa8c6200 [ 222.429199] x27: ffff0000086f1000 [ 222.432597] x26: 000000000000006a [ 222.435997] x25: 0000000000000124 [ 222.439395] x24: 0000000000000018 [ 222.442795] x23: 0000000000000006 [ 222.446193] x22: ffff8006f925d490 [ 222.449592] x21: ffff8006f9ac2068 [ 222.452991] x20: ffff8006f9ac2000 [ 222.456390] x19: 0000000000000005 [ 222.459787] x18: 000000000000000a [ 222.463186] x17: 0000000000000000 [ 222.466584] x16: 0000000000000000 [ 222.469984] x15: 000000000d3f616a [ 222.473382] x14: 0720072007200720 [ 222.476781] x13: 0720072007200720 [ 222.480179] x12: 0720072007200720 [ 222.483578] x11: 0720072007200720 [ 222.486975] x10: 0720072007200720 [ 222.490375] x9 : 0720072007200720 [ 222.493773] x8 : 07200772076f0774 [ 222.497172] x7 : 0000000000000000 [ 222.500570] x6 : 0000000000000007 [ 222.503969] x5 : 0000000000000000 [ 222.507367] x4 : 0000000000000000 [ 222.510766] x3 : 0000000000000000 [ 222.514164] x2 : c790b852091e2600 [ 222.517563] x1 : 0000000000000000 [ 222.520961] x0 : 0000000000000028 [ 222.524361] Call trace: [ 222.526805] Exception stack(0xffff00000a0a3b40 to 0xffff00000a0a3c80) [ 222.533245] 3b40: 0000000000000028 0000000000000000 c790b852091e2600 0000000000000000 [ 222.541075] 3b60: 0000000000000000 0000000000000000 0000000000000007 0000000000000000 [ 222.548905] 3b80: 07200772076f0774 0720072007200720 0720072007200720 0720072007200720 [ 222.556735] 3ba0: 0720072007200720 0720072007200720 0720072007200720 000000000d3f616a [ 222.564564] 3bc0: 0000000000000000 0000000000000000 000000000000000a 0000000000000005 [ 222.572394] 3be0: ffff8006f9ac2000 ffff8006f9ac2068 ffff8006f925d490 0000000000000006 [ 222.580224] 3c00: 0000000000000018 0000000000000124 000000000000006a ffff0000086f1000 [ 222.588053] 3c20: ffff8006fa8c6200 ffff00000a0a3c80 ffff0000083bd89c ffff00000a0a3c80 [ 222.595883] 3c40: ffff0000083bd89c 0000000000000145 0000000000000000 0000000000000000 [ 222.603713] 3c60: 0000ffffffffffff ffff00000a0a3c30 ffff00000a0a3c80 ffff0000083bd89c [ 222.611543] [<ffff0000083bd89c>] _regulator_disable+0x28/0x108 [ 222.617375] [<ffff0000083bd9c4>] regulator_disable+0x48/0x68 [ 222.623033] [<ffff0000083be8e4>] regulator_bulk_disable+0x58/0xc0 [ 222.629134] [<ffff0000007d831c>] pcm3168a_remove+0x30/0x50 [snd_soc_pcm3168a] [ 222.636270] [<ffff0000007e5010>] pcm3168a_i2c_remove+0x10/0x1c [snd_soc_pcm3168a_i2c] [ 222.644106] [<ffff0000084b9d9c>] i2c_device_remove+0x38/0x70 [ 222.649766] [<ffff00000843cd5c>] device_release_driver_internal+0xd0/0x1c0 [ 222.656640] [<ffff00000843ced8>] driver_detach+0x70/0x7c [ 222.661951] [<ffff00000843bf68>] bus_remove_driver+0x74/0xa0 [ 222.667609] [<ffff00000843d7e4>] driver_unregister+0x48/0x4c [ 222.673268] [<ffff0000084ba8dc>] i2c_del_driver+0x24/0x30 [ 222.678666] [<ffff0000007e5078>] pcm3168a_i2c_driver_exit+0x10/0xf98 [snd_soc_pcm3168a_i2c] [ 222.687019] [<ffff00000811bd28>] SyS_delete_module+0x198/0x1d4 [ 222.692850] Exception stack(0xffff00000a0a3ec0 to 0xffff00000a0a4000) [ 222.699289] 3ec0: 0000aaaafeb4b268 0000000000000800 14453f6470497100 0000fffffaa520d8 [ 222.707119] 3ee0: 0000fffffaa520d9 000000000000000a 1999999999999999 0000000000000000 [ 222.714948] 3f00: 000000000000006a 0000ffffa8f7d1d8 000000000000000a 0000000000000005 [ 222.722778] 3f20: 0000000000000000 0000000000000000 000000000000002d 0000000000000000 [ 222.730607] 3f40: 0000aaaae19b9f68 0000ffffa8f411f0 0000000000000000 0000aaaae19b9000 [ 222.738436] 3f60: 0000fffffaa533b8 0000fffffaa531f0 0000000000000000 0000000000000001 [ 222.746266] 3f80: 0000fffffaa53ec6 0000000000000000 0000aaaafeb4b200 0000aaaafeb4a010 [ 222.754096] 3fa0: 0000000000000000 0000fffffaa53130 0000aaaae199f36c 0000fffffaa53130 [ 222.761926] 3fc0: 0000ffffa8f411f8 0000000000000000 0000aaaafeb4b268 000000000000006a [ 222.769755] 3fe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 222.777589] [<ffff0000080832c0>] el0_svc_naked+0x34/0x38 [ 222.782899] ---[ end trace eaf8939a3698b1a8 ]--- [ 222.787609] Failed to disable VCCDA2: -5 [ 222.791649] ------------[ cut here ]------------ [ 222.796283] WARNING: CPU: 0 PID: 2423 at drivers/clk/clk.c:595 clk_core_disable+0xc/0x1d8 [ 222.804460] Modules linked in: [ 222.807511] snd_soc_pcm3168a_i2c(-) [ 222.811083] snd_aloop [ 222.813439] arc4 [ 222.815360] wl18xx [ 222.817456] wlcore [ 222.819551] mac80211 [ 222.821820] cfg80211 [ 222.824088] aes_ce_blk [ 222.826531] crypto_simd [ 222.829060] cryptd [ 222.831155] aes_ce_cipher [ 222.833859] crc32_ce [ 222.836127] ghash_ce [ 222.838396] aes_arm64 [ 222.840752] gf128mul [ 222.843020] snd_soc_rcar [ 222.845637] sha2_ce [ 222.847818] xhci_plat_hcd [ 222.850522] sha256_arm64 [ 222.853138] xhci_hcd [ 222.855407] sha1_ce [ 222.857589] renesas_usbhs [ 222.860292] evdev [ 222.862300] sha1_generic [ 222.864917] rcar_gen3_thermal [ 222.867968] cpufreq_dt [ 222.870410] ravb_streaming(C) [ 222.873461] wlcore_sdio [ 222.875991] thermal_sys [ 222.878520] udc_core [ 222.880789] mch_core(C) [ 222.883318] usb_dmac [ 222.885587] snd_soc_pcm3168a [ 222.888551] snd_soc_ak4613 [ 222.891341] gpio_keys [ 222.893696] virt_dma [ 222.895965] nfsd [ 222.897886] ipv6 [ 222.899808] autofs4 [ 222.901990] [last unloaded: snd_soc_pcm3168a_i2c] [ 222.906783] CPU: 0 PID: 2423 Comm: rmmod Tainted: G WC 4.14.63-04798-gd456126e4a42-dirty #457 [ 222.916349] Hardware name: Renesas H3ULCB Kingfisher board based on r8a7795 ES2.0+ (DT) [ 222.924351] task: ffff8006fa8c6200 task.stack: ffff00000a0a0000 [ 222.930270] PC is at clk_core_disable+0xc/0x1d8 [ 222.934799] LR is at clk_core_disable_lock+0x20/0x34 [ 222.939761] pc : [<ffff0000083ab9b8>] lr : [<ffff0000083acd28>] pstate: 800001c5 [ 222.947154] sp : ffff00000a0a3cf0 [ 222.950466] x29: ffff00000a0a3cf0 [ 222.953864] x28: ffff8006fa8c6200 [ 222.957263] x27: ffff0000086f1000 [ 222.960661] x26: 000000000000006a [ 222.964061] x25: 0000000000000124 [ 222.967458] x24: 0000000000000015 [ 222.970858] x23: ffff8006f9ffa8d0 [ 222.974256] x22: ffff8006faf16480 [ 222.977655] x21: ffff0000007e7040 [ 222.981053] x20: ffff8006faadd100 [ 222.984452] x19: 0000000000000140 [ 222.987850] x18: 000000000000000a [ 222.991249] x17: 0000000000000000 [ 222.994647] x16: 0000000000000000 [ 222.998046] x15: 000000000d477819 [ 223.001444] x14: 0720072007200720 [ 223.004843] x13: 0720072007200720 [ 223.008242] x12: 0720072007200720 [ 223.011641] x11: 0720072007200720 [ 223.015039] x10: 0720072007200720 [ 223.018438] x9 : 0720072007200720 [ 223.021837] x8 : 0720072007200720 [ 223.025236] x7 : 0000000000000000 [ 223.028634] x6 : 0000000000000007 [ 223.032034] x5 : 0000000000000000 [ 223.035432] x4 : 0000000000000000 [ 223.038831] x3 : 0000000000000000 [ 223.042229] x2 : 0000000004720471 [ 223.045628] x1 : 0000000000000000 [ 223.049026] x0 : ffff8006faadd100 [ 223.052426] Call trace: [ 223.054870] Exception stack(0xffff00000a0a3bb0 to 0xffff00000a0a3cf0) [ 223.061309] 3ba0: ffff8006faadd100 0000000000000000 [ 223.069139] 3bc0: 0000000004720471 0000000000000000 0000000000000000 0000000000000000 [ 223.076969] 3be0: 0000000000000007 0000000000000000 0720072007200720 0720072007200720 [ 223.084798] 3c00: 0720072007200720 0720072007200720 0720072007200720 0720072007200720 [ 223.092628] 3c20: 0720072007200720 000000000d477819 0000000000000000 0000000000000000 [ 223.100458] 3c40: 000000000000000a 0000000000000140 ffff8006faadd100 ffff0000007e7040 [ 223.108287] 3c60: ffff8006faf16480 ffff8006f9ffa8d0 0000000000000015 0000000000000124 [ 223.116117] 3c80: 000000000000006a ffff0000086f1000 ffff8006fa8c6200 ffff00000a0a3cf0 [ 223.123947] 3ca0: ffff0000083acd28 ffff00000a0a3cf0 ffff0000083ab9b8 00000000800001c5 [ 223.131777] 3cc0: ffff00000a0a3cf0 ffff0000083acd1c 0000ffffffffffff ffff8006faadd100 [ 223.139606] 3ce0: ffff00000a0a3cf0 ffff0000083ab9b8 [ 223.144483] [<ffff0000083ab9b8>] clk_core_disable+0xc/0x1d8 [ 223.150054] [<ffff0000083acd58>] clk_disable+0x1c/0x28 [ 223.155198] [<ffff0000007d8328>] pcm3168a_remove+0x3c/0x50 [snd_soc_pcm3168a] [ 223.162334] [<ffff0000007e5010>] pcm3168a_i2c_remove+0x10/0x1c [snd_soc_pcm3168a_i2c] [ 223.170167] [<ffff0000084b9d9c>] i2c_device_remove+0x38/0x70 [ 223.175826] [<ffff00000843cd5c>] device_release_driver_internal+0xd0/0x1c0 [ 223.182700] [<ffff00000843ced8>] driver_detach+0x70/0x7c [ 223.188012] [<ffff00000843bf68>] bus_remove_driver+0x74/0xa0 [ 223.193669] [<ffff00000843d7e4>] driver_unregister+0x48/0x4c [ 223.199329] [<ffff0000084ba8dc>] i2c_del_driver+0x24/0x30 [ 223.204726] [<ffff0000007e5078>] pcm3168a_i2c_driver_exit+0x10/0xf98 [snd_soc_pcm3168a_i2c] [ 223.213079] [<ffff00000811bd28>] SyS_delete_module+0x198/0x1d4 [ 223.218909] Exception stack(0xffff00000a0a3ec0 to 0xffff00000a0a4000) [ 223.225349] 3ec0: 0000aaaafeb4b268 0000000000000800 14453f6470497100 0000fffffaa520d8 [ 223.233179] 3ee0: 0000fffffaa520d9 000000000000000a 1999999999999999 0000000000000000 [ 223.241008] 3f00: 000000000000006a 0000ffffa8f7d1d8 000000000000000a 0000000000000005 [ 223.248838] 3f20: 0000000000000000 0000000000000000 000000000000002d 0000000000000000 [ 223.256668] 3f40: 0000aaaae19b9f68 0000ffffa8f411f0 0000000000000000 0000aaaae19b9000 [ 223.264497] 3f60: 0000fffffaa533b8 0000fffffaa531f0 0000000000000000 0000000000000001 [ 223.272327] 3f80: 0000fffffaa53ec6 0000000000000000 0000aaaafeb4b200 0000aaaafeb4a010 [ 223.280157] 3fa0: 0000000000000000 0000fffffaa53130 0000aaaae199f36c 0000fffffaa53130 [ 223.287986] 3fc0: 0000ffffa8f411f8 0000000000000000 0000aaaafeb4b268 000000000000006a [ 223.295816] 3fe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 223.303648] [<ffff0000080832c0>] el0_svc_naked+0x34/0x38 [ 223.308958] ---[ end trace eaf8939a3698b1a9 ]--- [ 223.313752] ------------[ cut here ]------------ [ 223.318383] WARNING: CPU: 0 PID: 2423 at drivers/clk/clk.c:477 clk_core_unprepare+0xc/0x1ac [ 223.326733] Modules linked in: [ 223.329784] snd_soc_pcm3168a_i2c(-) [ 223.333356] snd_aloop [ 223.335712] arc4 [ 223.337633] wl18xx [ 223.339728] wlcore [ 223.341823] mac80211 [ 223.344092] cfg80211 [ 223.346360] aes_ce_blk [ 223.348803] crypto_simd [ 223.351332] cryptd [ 223.353428] aes_ce_cipher [ 223.356131] crc32_ce [ 223.358400] ghash_ce [ 223.360668] aes_arm64 [ 223.363024] gf128mul [ 223.365293] snd_soc_rcar [ 223.367909] sha2_ce [ 223.370091] xhci_plat_hcd [ 223.372794] sha256_arm64 [ 223.375410] xhci_hcd [ 223.377679] sha1_ce [ 223.379861] renesas_usbhs [ 223.382564] evdev [ 223.384572] sha1_generic [ 223.387188] rcar_gen3_thermal [ 223.390239] cpufreq_dt [ 223.392682] ravb_streaming(C) [ 223.395732] wlcore_sdio [ 223.398261] thermal_sys [ 223.400790] udc_core [ 223.403059] mch_core(C) [ 223.405588] usb_dmac [ 223.407856] snd_soc_pcm3168a [ 223.410820] snd_soc_ak4613 [ 223.413609] gpio_keys [ 223.415965] virt_dma [ 223.418234] nfsd [ 223.420155] ipv6 [ 223.422076] autofs4 [ 223.424258] [last unloaded: snd_soc_pcm3168a_i2c] [ 223.429050] CPU: 0 PID: 2423 Comm: rmmod Tainted: G WC 4.14.63-04798-gd456126e4a42-dirty #457 [ 223.438616] Hardware name: Renesas H3ULCB Kingfisher board based on r8a7795 ES2.0+ (DT) [ 223.446618] task: ffff8006fa8c6200 task.stack: ffff00000a0a0000 [ 223.452536] PC is at clk_core_unprepare+0xc/0x1ac [ 223.457239] LR is at clk_unprepare+0x28/0x3c [ 223.461506] pc : [<ffff0000083ab5a4>] lr : [<ffff0000083ace4c>] pstate: 60000145 [ 223.468900] sp : ffff00000a0a3d00 [ 223.472211] x29: ffff00000a0a3d00 [ 223.475609] x28: ffff8006fa8c6200 [ 223.479009] x27: ffff0000086f1000 [ 223.482407] x26: 000000000000006a [ 223.485807] x25: 0000000000000124 [ 223.489205] x24: 0000000000000015 [ 223.492604] x23: ffff8006f9ffa8d0 [ 223.496003] x22: ffff8006faf16480 [ 223.499402] x21: ffff0000007e7040 [ 223.502800] x20: ffff8006faf16420 [ 223.506199] x19: ffff8006faadd100 [ 223.509597] x18: 000000000000000a [ 223.512997] x17: 0000000000000000 [ 223.516395] x16: 0000000000000000 [ 223.519794] x15: 0000000000000000 [ 223.523192] x14: 00000033fe89076c [ 223.526591] x13: 0000000000000400 [ 223.529989] x12: 0000000000000400 [ 223.533388] x11: 0000000000000000 [ 223.536786] x10: 00000000000009e0 [ 223.540185] x9 : ffff00000a0a3be0 [ 223.543583] x8 : ffff8006fa8c6c40 [ 223.546982] x7 : ffff8006fa8c6400 [ 223.550380] x6 : 0000000000000001 [ 223.553780] x5 : 0000000000000000 [ 223.557178] x4 : ffff8006fa8c6200 [ 223.560577] x3 : 0000000000000000 [ 223.563975] x2 : ffff8006fa8c6200 [ 223.567374] x1 : 0000000000000000 [ 223.570772] x0 : ffff8006faadd100 [ 223.574170] Call trace: [ 223.576615] Exception stack(0xffff00000a0a3bc0 to 0xffff00000a0a3d00) [ 223.583054] 3bc0: ffff8006faadd100 0000000000000000 ffff8006fa8c6200 0000000000000000 [ 223.590884] 3be0: ffff8006fa8c6200 0000000000000000 0000000000000001 ffff8006fa8c6400 [ 223.598714] 3c00: ffff8006fa8c6c40 ffff00000a0a3be0 00000000000009e0 0000000000000000 [ 223.606544] 3c20: 0000000000000400 0000000000000400 00000033fe89076c 0000000000000000 [ 223.614374] 3c40: 0000000000000000 0000000000000000 000000000000000a ffff8006faadd100 [ 223.622204] 3c60: ffff8006faf16420 ffff0000007e7040 ffff8006faf16480 ffff8006f9ffa8d0 [ 223.630033] 3c80: 0000000000000015 0000000000000124 000000000000006a ffff0000086f1000 [ 223.637863] 3ca0: ffff8006fa8c6200 ffff00000a0a3d00 ffff0000083ace4c ffff00000a0a3d00 [ 223.645693] 3cc0: ffff0000083ab5a4 0000000060000145 0000000000000140 ffff8006faadd100 [ 223.653523] 3ce0: 0000ffffffffffff ffff0000083ace44 ffff00000a0a3d00 ffff0000083ab5a4 [ 223.661353] [<ffff0000083ab5a4>] clk_core_unprepare+0xc/0x1ac [ 223.667103] [<ffff0000007d8330>] pcm3168a_remove+0x44/0x50 [snd_soc_pcm3168a] [ 223.674239] [<ffff0000007e5010>] pcm3168a_i2c_remove+0x10/0x1c [snd_soc_pcm3168a_i2c] [ 223.682070] [<ffff0000084b9d9c>] i2c_device_remove+0x38/0x70 [ 223.687731] [<ffff00000843cd5c>] device_release_driver_internal+0xd0/0x1c0 [ 223.694604] [<ffff00000843ced8>] driver_detach+0x70/0x7c [ 223.699915] [<ffff00000843bf68>] bus_remove_driver+0x74/0xa0 [ 223.705572] [<ffff00000843d7e4>] driver_unregister+0x48/0x4c [ 223.711230] [<ffff0000084ba8dc>] i2c_del_driver+0x24/0x30 [ 223.716628] [<ffff0000007e5078>] pcm3168a_i2c_driver_exit+0x10/0xf98 [snd_soc_pcm3168a_i2c] [ 223.724980] [<ffff00000811bd28>] SyS_delete_module+0x198/0x1d4 [ 223.730811] Exception stack(0xffff00000a0a3ec0 to 0xffff00000a0a4000) [ 223.737250] 3ec0: 0000aaaafeb4b268 0000000000000800 14453f6470497100 0000fffffaa520d8 [ 223.745079] 3ee0: 0000fffffaa520d9 000000000000000a 1999999999999999 0000000000000000 [ 223.752909] 3f00: 000000000000006a 0000ffffa8f7d1d8 000000000000000a 0000000000000005 [ 223.760739] 3f20: 0000000000000000 0000000000000000 000000000000002d 0000000000000000 [ 223.768568] 3f40: 0000aaaae19b9f68 0000ffffa8f411f0 0000000000000000 0000aaaae19b9000 [ 223.776398] 3f60: 0000fffffaa533b8 0000fffffaa531f0 0000000000000000 0000000000000001 [ 223.784227] 3f80: 0000fffffaa53ec6 0000000000000000 0000aaaafeb4b200 0000aaaafeb4a010 [ 223.792057] 3fa0: 0000000000000000 0000fffffaa53130 0000aaaae199f36c 0000fffffaa53130 [ 223.799886] 3fc0: 0000ffffa8f411f8 0000000000000000 0000aaaafeb4b268 000000000000006a [ 223.807715] 3fe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 223.815546] [<ffff0000080832c0>] el0_svc_naked+0x34/0x38 [ 223.820855] ---[ end trace eaf8939a3698b1aa ]--- Fix this issue by only disable clock and regulators in remove callback when CONFIG_PM isn't defined Signed-off-by: Jiada Wang <jiada_wang@mentor.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-11-28i40e: fix kerneldoc for xsk methodsJan Sokolowski
One method, xsk_umem_setup, had an incorrect kernel doc description, which has been corrected. Also fixes small typos found in the comments. Signed-off-by: Jan Sokolowski <jan.sokolowski@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-11-28Merge tag 'for-4.20-rc4-tag' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux Pull btrfs fixes from David Sterba: "Some of these bugs are being hit during testing so we'd like to get them merged, otherwise there are usual stability fixes for stable trees" * tag 'for-4.20-rc4-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux: btrfs: relocation: set trans to be NULL after ending transaction Btrfs: fix race between enabling quotas and subvolume creation Btrfs: send, fix infinite loop due to directory rename dependencies Btrfs: ensure path name is null terminated at btrfs_control_ioctl Btrfs: fix rare chances for data loss when doing a fast fsync btrfs: Always try all copies when reading extent buffers
2018-11-28Merge tag 'spi-fix-v4.20-rc4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi Pull spi fixes from Mark Brown: "A few driver specific fixes here, nothing big or that stands out for anyone other than the driver users. The omap2-mcspi fix is for issues that started showing up with a change in defconfig in this release to make cpuidle get turned on by default" * tag 'spi-fix-v4.20-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: spi: omap2-mcspi: Add missing suspend and resume calls spi: mediatek: use correct mata->xfer_len when in fifo transfer spi: uniphier: fix incorrect property items
2018-11-28ixgbe: recognize 1000BaseLX SFP modules as 1GbpsJosh Elsasser
Add the two 1000BaseLX enum values to the X550's check for 1Gbps modules, allowing the core driver code to establish a link over this SFP type. This is done by the out-of-tree driver but the fix wasn't in mainline. Fixes: e23f33367882 ("ixgbe: Fix 1G and 10G link stability for X550EM_x SFP+”) Fixes: 6a14ee0cfb19 ("ixgbe: Add X550 support function pointers") Signed-off-by: Josh Elsasser <jelsasser@appneta.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-11-28Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvmLinus Torvalds
Pull kvm fixes from Paolo Bonzini: "Bugfixes, many of them reported by syzkaller and mostly predating the merge window" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: kvm: svm: Ensure an IBPB on all affected CPUs when freeing a vmcb kvm: mmu: Fix race in emulated page table writes KVM: nVMX: vmcs12 revision_id is always VMCS12_REVISION even when copied from eVMCS KVM: nVMX: Verify eVMCS revision id match supported eVMCS version on eVMCS VMPTRLD KVM: nVMX/nSVM: Fix bug which sets vcpu->arch.tsc_offset to L1 tsc_offset x86/kvm/vmx: fix old-style function declaration KVM: x86: fix empty-body warnings KVM: VMX: Update shared MSRs to be saved/restored on MSR_EFER.LMA changes KVM: x86: Fix kernel info-leak in KVM_HC_CLOCK_PAIRING hypercall KVM: nVMX: Fix kernel info-leak when enabling KVM_CAP_HYPERV_ENLIGHTENED_VMCS more than once svm: Add mutex_lock to protect apic_access_page_done on AMD systems KVM: X86: Fix scan ioapic use-before-initialization KVM: LAPIC: Fix pv ipis use-before-initialization KVM: VMX: re-add ple_gap module parameter KVM: PPC: Book3S HV: Fix handling for interrupted H_ENTER_NESTED
2018-11-28i40e: Fix deletion of MAC filtersLihong Yang
In __i40e_del_filter function, the flag __I40E_MACVLAN_SYNC_PENDING for the PF state is wrongly set for the VSI. Deleting any of the MAC filters has caused the incorrect syncing for the PF. Fix it by setting this state flag to the intended PF. CC: stable <stable@vger.kernel.org> Signed-off-by: Lihong Yang <lihong.yang@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-11-28igb: fix uninitialized variablesYunjian Wang
This patch fixes the variable 'phy_word' may be used uninitialized. Signed-off-by: Yunjian Wang <wangyunjian@huawei.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-11-28ASoC: dmic: introduce module_param wakeup_delayJenny TC
Introducing a module param for wakeup_delay in order to align with modeswitch_delay parameter. With this change, both wakeup_delay and modeswitch_delay parameters can be passed as module parameters. Signed-off-by: Jenny TC <jenny.tc@intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-11-28ASoC: dmic: introduce mode switch delayJenny TC
On startup, applications such as PulseAudio or CRAS enable playback or capture on all PCM devices to verify that configurations are correct, and close them immediately. For DMICs, this can result in the clock being turned off very quickly, which may not compatible with internal state machine transition requirements. This patch add a mode-switch delay which will prevent the clock from being turned off without complying with manufacturer timing specifications. While the DMIC clock may be controlled at a lower level, be it with hardware or firmware, applying the delay during the STOP_TRIGGER phase ensures that there is no race condition, e.g. with the hardware/firmware turning off the clock earlier Signed-off-by: Sathyanarayana Nujella <sathyanarayana.nujella@intel.com> Signed-off-by: Jairaj Arava <jairaj.arava@intel.com> Signed-off-by: Harsha Priya <harshapriya.n@intel.com> Signed-off-by: Jenny TC <jenny.tc@intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-11-28dt-bindings: sound: omap-mcpdm: Update documentation for pdmclkPeter Ujfalusi
McPDM module receives it's functional clock from external source. This clock is the pdmclk provided by the twl6040 audio IC. If the clock is not available all register accesses to McPDM fails and the module is not operational. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-11-28ASoC: qcom: sdm845: Create and setup jack in init callbackCheng-Yi Chiang
Add a callback for init ops on dai_link to create and setup jack. Signed-off-by: Rohit kumar <rohitkr@codeaurora.org> Signed-off-by: Cheng-Yi Chiang <cychiang@chromium.org> Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-11-28ASoC: qcom: sdm845: Add board specific dapm widgetsCheng-Yi Chiang
Add board specific dapm widgets so these widgets can be used in the route. Signed-off-by: Rohit kumar <rohitkr@codeaurora.org> Signed-off-by: Cheng-Yi Chiang <cychiang@chromium.org> Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-11-28cachefiles: Fix page leak in cachefiles_read_backing_file while vmscan is activeKiran Kumar Modukuri
[Description] In a heavily loaded system where the system pagecache is nearing memory limits and fscache is enabled, pages can be leaked by fscache while trying read pages from cachefiles backend. This can happen because two applications can be reading same page from a single mount, two threads can be trying to read the backing page at same time. This results in one of the threads finding that a page for the backing file or netfs file is already in the radix tree. During the error handling cachefiles does not clean up the reference on backing page, leading to page leak. [Fix] The fix is straightforward, to decrement the reference when error is encountered. [dhowells: Note that I've removed the clearance and put of newpage as they aren't attested in the commit message and don't appear to actually achieve anything since a new page is only allocated is newpage!=NULL and any residual new page is cleared before returning.] [Testing] I have tested the fix using following method for 12+ hrs. 1) mkdir -p /mnt/nfs ; mount -o vers=3,fsc <server_ip>:/export /mnt/nfs 2) create 10000 files of 2.8MB in a NFS mount. 3) start a thread to simulate heavy VM presssure (while true ; do echo 3 > /proc/sys/vm/drop_caches ; sleep 1 ; done)& 4) start multiple parallel reader for data set at same time find /mnt/nfs -type f | xargs -P 80 cat > /dev/null & find /mnt/nfs -type f | xargs -P 80 cat > /dev/null & find /mnt/nfs -type f | xargs -P 80 cat > /dev/null & .. .. find /mnt/nfs -type f | xargs -P 80 cat > /dev/null & find /mnt/nfs -type f | xargs -P 80 cat > /dev/null & 5) finally check using cat /proc/fs/fscache/stats | grep -i pages ; free -h , cat /proc/meminfo and page-types -r -b lru to ensure all pages are freed. Reviewed-by: Daniel Axtens <dja@axtens.net> Signed-off-by: Shantanu Goel <sgoel01@yahoo.com> Signed-off-by: Kiran Kumar Modukuri <kiran.modukuri@gmail.com> [dja: forward ported to current upstream] Signed-off-by: Daniel Axtens <dja@axtens.net> Signed-off-by: David Howells <dhowells@redhat.com>
2018-11-28mtd: nand: Fix memory allocation in nanddev_bbt_init()Frieder Schrempf
Fix the size of the buffer allocated to store the in-memory BBT. This bug was previously hidden by a different bug, that was fixed in commit d098093ba06e ("mtd: nand: Fix nanddev_neraseblocks()"). Fixes: 9c3736a3de21 ("mtd: nand: Add core infrastructure to deal with NAND devices") Cc: <stable@vger.kernel.org> Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de> Acked-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
2018-11-28fscache: Fix race in fscache_op_complete() due to split atomic_sub & readkiran.modukuri
The code in fscache_retrieval_complete is using atomic_sub followed by an atomic_read: atomic_sub(n_pages, &op->n_pages); if (atomic_read(&op->n_pages) <= 0) fscache_op_complete(&op->op, true); This causes two threads doing a decrement of n_pages to race with each other seeing the op->refcount 0 at same time - and they end up calling fscache_op_complete() in both the threads leading to an assertion failure. Fix this by using atomic_sub_return_relaxed() instead of two calls. Note that I'm using 'relaxed' rather than, say, 'release' as there aren't multiple variables that appear to need ordering across the release. The oops looks something like: FS-Cache: Assertion failed FS-Cache: 0 > 0 is false ... kernel BUG at /usr/src/linux-4.4.0/fs/fscache/operation.c:449! ... Workqueue: fscache_operation fscache_op_work_func [fscache] ... RIP: 0010:[<ffffffffc037eacd>] fscache_op_complete+0x10d/0x180 [fscache] ... Call Trace: [<ffffffffc1464cf9>] cachefiles_read_copier+0x3a9/0x410 [cachefiles] [<ffffffffc037e272>] fscache_op_work_func+0x22/0x50 [fscache] [<ffffffff81096da0>] process_one_work+0x150/0x3f0 [<ffffffff8109751a>] worker_thread+0x11a/0x470 [<ffffffff81808e59>] ? __schedule+0x359/0x980 [<ffffffff81097400>] ? rescuer_thread+0x310/0x310 [<ffffffff8109cdd6>] kthread+0xd6/0xf0 [<ffffffff8109cd00>] ? kthread_park+0x60/0x60 [<ffffffff8180d0cf>] ret_from_fork+0x3f/0x70 [<ffffffff8109cd00>] ? kthread_park+0x60/0x60 This seen this in 4.4.x kernels and the same bug affects fscache in latest upstreams kernels. Fixes: 1bb4b7f98f36 ("FS-Cache: The retrieval remaining-pages counter needs to be atomic_t") Signed-off-by: Kiran Kumar Modukuri <kiran.modukuri@gmail.com> Signed-off-by: David Howells <dhowells@redhat.com>
2018-11-28cachefiles: Fix an assertion failure when trying to update a failed objectDavid Howells
If cachefiles gets an error other then ENOENT when trying to look up an object in the cache (in this case, EACCES), the object state machine will eventually transition to the DROP_OBJECT state. This state invokes fscache_drop_object() which tries to sync the auxiliary data with the cache (this is done lazily since commit 402cb8dda949d) on an incomplete cache object struct. The problem comes when cachefiles_update_object_xattr() is called to rewrite the xattr holding the data. There's an assertion there that the cache object points to a dentry as we're going to update its xattr. The assertion trips, however, as dentry didn't get set. Fix the problem by skipping the update in cachefiles if the object doesn't refer to a dentry. A better way to do it could be to skip the update from the DROP_OBJECT state handler in fscache, but that might deny the cache the opportunity to update intermediate state. If this error occurs, the kernel log includes lines that look like the following: CacheFiles: Lookup failed error -13 CacheFiles: CacheFiles: Assertion failed ------------[ cut here ]------------ kernel BUG at fs/cachefiles/xattr.c:138! ... Workqueue: fscache_object fscache_object_work_func [fscache] RIP: 0010:cachefiles_update_object_xattr.cold.4+0x18/0x1a [cachefiles] ... Call Trace: cachefiles_update_object+0xdd/0x1c0 [cachefiles] fscache_update_aux_data+0x23/0x30 [fscache] fscache_drop_object+0x18e/0x1c0 [fscache] fscache_object_work_func+0x74/0x2b0 [fscache] process_one_work+0x18d/0x340 worker_thread+0x2e/0x390 ? pwq_unbound_release_workfn+0xd0/0xd0 kthread+0x112/0x130 ? kthread_bind+0x30/0x30 ret_from_fork+0x35/0x40 Note that there are actually two issues here: (1) EACCES happened on a cache object and (2) an oops occurred. I think that the second is a consequence of the first (it certainly looks like it ought to be). This patch only deals with the second. Fixes: 402cb8dda949 ("fscache: Attach the index key and aux data to the cookie") Reported-by: Zhibin Li <zhibli@redhat.com> Signed-off-by: David Howells <dhowells@redhat.com>
2018-11-28ASoC: davinci-mcasp: Implement configurable dismod handlingPeter Ujfalusi
If the dismod is specified in the DT node, use the specified custom value to configure the drive on state of the inactive TX slots. If the dismod is not present or booted in legacy mode, the dismod is set to low as it was the original behavior. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-11-28ASoC: davinci-mcasp: Document dismod optional propertyPeter Ujfalusi
The dismod property can be used to specify the drive on level of inactive TX slots. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-11-28ASoC: davinci-mcasp: Update PDIR (pin direction) register handlingPeter Ujfalusi
When McASP is master and the PDIR for the clock pins are configured as outputs before the clocking is configured it will output whatever clock is generated at the moment internally. The clock will switch to the correct rate only when the we start the clock generators. To avoid this we must only set the pin as output after the clock is configured and enabled. AXR pins configured as outputs behaves somehow interesting as well: when McASP is not enabled and the pin is selected as output it will not honor the DISMOD settings for the inactive state, but will pull the pin down. Add a new bitfield and mark the pins there which needs to be output and set the pins only at the time when they will behave correctly. On stream stop configure the pins back to input which makes them to obey the global pin configuration regarding to pull up/down. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-11-28ASoC: davinci-mcasp: Clear TXSTAT register before activating serializersPeter Ujfalusi
Follow the guideline from the TRM: Before starting, clear the respective transmitter and receiver status registers To avoid stale state stored in the status registers. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-11-28ASoC: Intel: Skylake: Add FW reply for MCLK/SCLK IPCSubhransu S. Prusty
If mclk/sclk is already running, FW responds with IPC reply MCLK/SCLK already running. Add these to the IPC reply lookup table. Signed-off-by: Subhransu S. Prusty <subhransu.s.prusty@intel.com> Signed-off-by: Sriram Periyasamy <sriramx.periyasamy@intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-11-28ASoC: Intel: Skylake: Make DSP replies more human readableSubhransu S. Prusty
Add more meaning to the IPC replies for easy debugging. Replace the switch case with a lookup table to lookup for the IPC replies and print in human readable form. Signed-off-by: Subhransu S. Prusty <subhransu.s.prusty@intel.com> Signed-off-by: Sriram Periyasamy <sriramx.periyasamy@intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-11-28x86/speculation: Provide IBPB always command line optionsThomas Gleixner
Provide the possibility to enable IBPB always in combination with 'prctl' and 'seccomp'. Add the extra command line options and rework the IBPB selection to evaluate the command instead of the mode selected by the STIPB switch case. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Ingo Molnar <mingo@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Jiri Kosina <jkosina@suse.cz> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: David Woodhouse <dwmw@amazon.co.uk> Cc: Tim Chen <tim.c.chen@linux.intel.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Casey Schaufler <casey.schaufler@intel.com> Cc: Asit Mallick <asit.k.mallick@intel.com> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Jon Masters <jcm@redhat.com> Cc: Waiman Long <longman9394@gmail.com> Cc: Greg KH <gregkh@linuxfoundation.org> Cc: Dave Stewart <david.c.stewart@intel.com> Cc: Kees Cook <keescook@chromium.org> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20181125185006.144047038@linutronix.de
2018-11-28x86/speculation: Add seccomp Spectre v2 user space protection modeThomas Gleixner
If 'prctl' mode of user space protection from spectre v2 is selected on the kernel command-line, STIBP and IBPB are applied on tasks which restrict their indirect branch speculation via prctl. SECCOMP enables the SSBD mitigation for sandboxed tasks already, so it makes sense to prevent spectre v2 user space to user space attacks as well. The Intel mitigation guide documents how STIPB works: Setting bit 1 (STIBP) of the IA32_SPEC_CTRL MSR on a logical processor prevents the predicted targets of indirect branches on any logical processor of that core from being controlled by software that executes (or executed previously) on another logical processor of the same core. Ergo setting STIBP protects the task itself from being attacked from a task running on a different hyper-thread and protects the tasks running on different hyper-threads from being attacked. While the document suggests that the branch predictors are shielded between the logical processors, the observed performance regressions suggest that STIBP simply disables the branch predictor more or less completely. Of course the document wording is vague, but the fact that there is also no requirement for issuing IBPB when STIBP is used points clearly in that direction. The kernel still issues IBPB even when STIBP is used until Intel clarifies the whole mechanism. IBPB is issued when the task switches out, so malicious sandbox code cannot mistrain the branch predictor for the next user space task on the same logical processor. Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Ingo Molnar <mingo@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: David Woodhouse <dwmw@amazon.co.uk> Cc: Tim Chen <tim.c.chen@linux.intel.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Casey Schaufler <casey.schaufler@intel.com> Cc: Asit Mallick <asit.k.mallick@intel.com> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Jon Masters <jcm@redhat.com> Cc: Waiman Long <longman9394@gmail.com> Cc: Greg KH <gregkh@linuxfoundation.org> Cc: Dave Stewart <david.c.stewart@intel.com> Cc: Kees Cook <keescook@chromium.org> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20181125185006.051663132@linutronix.de
2018-11-28x86/speculation: Enable prctl mode for spectre_v2_userThomas Gleixner
Now that all prerequisites are in place: - Add the prctl command line option - Default the 'auto' mode to 'prctl' - When SMT state changes, update the static key which controls the conditional STIBP evaluation on context switch. - At init update the static key which controls the conditional IBPB evaluation on context switch. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Ingo Molnar <mingo@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Jiri Kosina <jkosina@suse.cz> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: David Woodhouse <dwmw@amazon.co.uk> Cc: Tim Chen <tim.c.chen@linux.intel.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Casey Schaufler <casey.schaufler@intel.com> Cc: Asit Mallick <asit.k.mallick@intel.com> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Jon Masters <jcm@redhat.com> Cc: Waiman Long <longman9394@gmail.com> Cc: Greg KH <gregkh@linuxfoundation.org> Cc: Dave Stewart <david.c.stewart@intel.com> Cc: Kees Cook <keescook@chromium.org> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20181125185005.958421388@linutronix.de
2018-11-28x86/speculation: Add prctl() control for indirect branch speculationThomas Gleixner
Add the PR_SPEC_INDIRECT_BRANCH option for the PR_GET_SPECULATION_CTRL and PR_SET_SPECULATION_CTRL prctls to allow fine grained per task control of indirect branch speculation via STIBP and IBPB. Invocations: Check indirect branch speculation status with - prctl(PR_GET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, 0, 0, 0); Enable indirect branch speculation with - prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_ENABLE, 0, 0); Disable indirect branch speculation with - prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_DISABLE, 0, 0); Force disable indirect branch speculation with - prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_FORCE_DISABLE, 0, 0); See Documentation/userspace-api/spec_ctrl.rst. Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Ingo Molnar <mingo@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Jiri Kosina <jkosina@suse.cz> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: David Woodhouse <dwmw@amazon.co.uk> Cc: Andi Kleen <ak@linux.intel.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Casey Schaufler <casey.schaufler@intel.com> Cc: Asit Mallick <asit.k.mallick@intel.com> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Jon Masters <jcm@redhat.com> Cc: Waiman Long <longman9394@gmail.com> Cc: Greg KH <gregkh@linuxfoundation.org> Cc: Dave Stewart <david.c.stewart@intel.com> Cc: Kees Cook <keescook@chromium.org> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20181125185005.866780996@linutronix.de
2018-11-28x86/speculation: Prepare arch_smt_update() for PRCTL modeThomas Gleixner
The upcoming fine grained per task STIBP control needs to be updated on CPU hotplug as well. Split out the code which controls the strict mode so the prctl control code can be added later. Mark the SMP function call argument __unused while at it. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Ingo Molnar <mingo@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Jiri Kosina <jkosina@suse.cz> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: David Woodhouse <dwmw@amazon.co.uk> Cc: Tim Chen <tim.c.chen@linux.intel.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Casey Schaufler <casey.schaufler@intel.com> Cc: Asit Mallick <asit.k.mallick@intel.com> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Jon Masters <jcm@redhat.com> Cc: Waiman Long <longman9394@gmail.com> Cc: Greg KH <gregkh@linuxfoundation.org> Cc: Dave Stewart <david.c.stewart@intel.com> Cc: Kees Cook <keescook@chromium.org> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20181125185005.759457117@linutronix.de
2018-11-28x86/speculation: Prevent stale SPEC_CTRL msr contentThomas Gleixner
The seccomp speculation control operates on all tasks of a process, but only the current task of a process can update the MSR immediately. For the other threads the update is deferred to the next context switch. This creates the following situation with Process A and B: Process A task 2 and Process B task 1 are pinned on CPU1. Process A task 2 does not have the speculation control TIF bit set. Process B task 1 has the speculation control TIF bit set. CPU0 CPU1 MSR bit is set ProcB.T1 schedules out ProcA.T2 schedules in MSR bit is cleared ProcA.T1 seccomp_update() set TIF bit on ProcA.T2 ProcB.T1 schedules in MSR is not updated <-- FAIL This happens because the context switch code tries to avoid the MSR update if the speculation control TIF bits of the incoming and the outgoing task are the same. In the worst case ProcB.T1 and ProcA.T2 are the only tasks scheduling back and forth on CPU1, which keeps the MSR stale forever. In theory this could be remedied by IPIs, but chasing the remote task which could be migrated is complex and full of races. The straight forward solution is to avoid the asychronous update of the TIF bit and defer it to the next context switch. The speculation control state is stored in task_struct::atomic_flags by the prctl and seccomp updates already. Add a new TIF_SPEC_FORCE_UPDATE bit and set this after updating the atomic_flags. Check the bit on context switch and force a synchronous update of the speculation control if set. Use the same mechanism for updating the current task. Reported-by: Tim Chen <tim.c.chen@linux.intel.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Jiri Kosina <jkosina@suse.cz> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: David Woodhouse <dwmw@amazon.co.uk> Cc: Tim Chen <tim.c.chen@linux.intel.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Casey Schaufler <casey.schaufler@intel.com> Cc: Asit Mallick <asit.k.mallick@intel.com> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Jon Masters <jcm@redhat.com> Cc: Waiman Long <longman9394@gmail.com> Cc: Greg KH <gregkh@linuxfoundation.org> Cc: Dave Stewart <david.c.stewart@intel.com> Cc: Kees Cook <keescook@chromium.org> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/alpine.DEB.2.21.1811272247140.1875@nanos.tec.linutronix.de
2018-11-28x86/speculation: Split out TIF updateThomas Gleixner
The update of the TIF_SSBD flag and the conditional speculation control MSR update is done in the ssb_prctl_set() function directly. The upcoming prctl support for controlling indirect branch speculation via STIBP needs the same mechanism. Split the code out and make it reusable. Reword the comment about updates for other tasks. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Ingo Molnar <mingo@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Jiri Kosina <jkosina@suse.cz> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: David Woodhouse <dwmw@amazon.co.uk> Cc: Tim Chen <tim.c.chen@linux.intel.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Casey Schaufler <casey.schaufler@intel.com> Cc: Asit Mallick <asit.k.mallick@intel.com> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Jon Masters <jcm@redhat.com> Cc: Waiman Long <longman9394@gmail.com> Cc: Greg KH <gregkh@linuxfoundation.org> Cc: Dave Stewart <david.c.stewart@intel.com> Cc: Kees Cook <keescook@chromium.org> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20181125185005.652305076@linutronix.de
2018-11-28ptrace: Remove unused ptrace_may_access_sched() and MODE_IBRSThomas Gleixner
The IBPB control code in x86 removed the usage. Remove the functionality which was introduced for this. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Ingo Molnar <mingo@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Jiri Kosina <jkosina@suse.cz> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: David Woodhouse <dwmw@amazon.co.uk> Cc: Tim Chen <tim.c.chen@linux.intel.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Casey Schaufler <casey.schaufler@intel.com> Cc: Asit Mallick <asit.k.mallick@intel.com> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Jon Masters <jcm@redhat.com> Cc: Waiman Long <longman9394@gmail.com> Cc: Greg KH <gregkh@linuxfoundation.org> Cc: Dave Stewart <david.c.stewart@intel.com> Cc: Kees Cook <keescook@chromium.org> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20181125185005.559149393@linutronix.de
2018-11-28x86/speculation: Prepare for conditional IBPB in switch_mm()Thomas Gleixner
The IBPB speculation barrier is issued from switch_mm() when the kernel switches to a user space task with a different mm than the user space task which ran last on the same CPU. An additional optimization is to avoid IBPB when the incoming task can be ptraced by the outgoing task. This optimization only works when switching directly between two user space tasks. When switching from a kernel task to a user space task the optimization fails because the previous task cannot be accessed anymore. So for quite some scenarios the optimization is just adding overhead. The upcoming conditional IBPB support will issue IBPB only for user space tasks which have the TIF_SPEC_IB bit set. This requires to handle the following cases: 1) Switch from a user space task (potential attacker) which has TIF_SPEC_IB set to a user space task (potential victim) which has TIF_SPEC_IB not set. 2) Switch from a user space task (potential attacker) which has TIF_SPEC_IB not set to a user space task (potential victim) which has TIF_SPEC_IB set. This needs to be optimized for the case where the IBPB can be avoided when only kernel threads ran in between user space tasks which belong to the same process. The current check whether two tasks belong to the same context is using the tasks context id. While correct, it's simpler to use the mm pointer because it allows to mangle the TIF_SPEC_IB bit into it. The context id based mechanism requires extra storage, which creates worse code. When a task is scheduled out its TIF_SPEC_IB bit is mangled as bit 0 into the per CPU storage which is used to track the last user space mm which was running on a CPU. This bit can be used together with the TIF_SPEC_IB bit of the incoming task to make the decision whether IBPB needs to be issued or not to cover the two cases above. As conditional IBPB is going to be the default, remove the dubious ptrace check for the IBPB always case and simply issue IBPB always when the process changes. Move the storage to a different place in the struct as the original one created a hole. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Ingo Molnar <mingo@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Jiri Kosina <jkosina@suse.cz> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: David Woodhouse <dwmw@amazon.co.uk> Cc: Tim Chen <tim.c.chen@linux.intel.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Casey Schaufler <casey.schaufler@intel.com> Cc: Asit Mallick <asit.k.mallick@intel.com> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Jon Masters <jcm@redhat.com> Cc: Waiman Long <longman9394@gmail.com> Cc: Greg KH <gregkh@linuxfoundation.org> Cc: Dave Stewart <david.c.stewart@intel.com> Cc: Kees Cook <keescook@chromium.org> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20181125185005.466447057@linutronix.de
2018-11-28x86/speculation: Avoid __switch_to_xtra() callsThomas Gleixner
The TIF_SPEC_IB bit does not need to be evaluated in the decision to invoke __switch_to_xtra() when: - CONFIG_SMP is disabled - The conditional STIPB mode is disabled The TIF_SPEC_IB bit still controls IBPB in both cases so the TIF work mask checks might invoke __switch_to_xtra() for nothing if TIF_SPEC_IB is the only set bit in the work masks. Optimize it out by masking the bit at compile time for CONFIG_SMP=n and at run time when the static key controlling the conditional STIBP mode is disabled. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Ingo Molnar <mingo@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Jiri Kosina <jkosina@suse.cz> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: David Woodhouse <dwmw@amazon.co.uk> Cc: Tim Chen <tim.c.chen@linux.intel.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Casey Schaufler <casey.schaufler@intel.com> Cc: Asit Mallick <asit.k.mallick@intel.com> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Jon Masters <jcm@redhat.com> Cc: Waiman Long <longman9394@gmail.com> Cc: Greg KH <gregkh@linuxfoundation.org> Cc: Dave Stewart <david.c.stewart@intel.com> Cc: Kees Cook <keescook@chromium.org> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20181125185005.374062201@linutronix.de
2018-11-28x86/process: Consolidate and simplify switch_to_xtra() codeThomas Gleixner
Move the conditional invocation of __switch_to_xtra() into an inline function so the logic can be shared between 32 and 64 bit. Remove the handthrough of the TSS pointer and retrieve the pointer directly in the bitmap handling function. Use this_cpu_ptr() instead of the per_cpu() indirection. This is a preparatory change so integration of conditional indirect branch speculation optimization happens only in one place. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Ingo Molnar <mingo@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Jiri Kosina <jkosina@suse.cz> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: David Woodhouse <dwmw@amazon.co.uk> Cc: Tim Chen <tim.c.chen@linux.intel.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Casey Schaufler <casey.schaufler@intel.com> Cc: Asit Mallick <asit.k.mallick@intel.com> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Jon Masters <jcm@redhat.com> Cc: Waiman Long <longman9394@gmail.com> Cc: Greg KH <gregkh@linuxfoundation.org> Cc: Dave Stewart <david.c.stewart@intel.com> Cc: Kees Cook <keescook@chromium.org> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20181125185005.280855518@linutronix.de
2018-11-28x86/speculation: Prepare for per task indirect branch speculation controlTim Chen
To avoid the overhead of STIBP always on, it's necessary to allow per task control of STIBP. Add a new task flag TIF_SPEC_IB and evaluate it during context switch if SMT is active and flag evaluation is enabled by the speculation control code. Add the conditional evaluation to x86_virt_spec_ctrl() as well so the guest/host switch works properly. This has no effect because TIF_SPEC_IB cannot be set yet and the static key which controls evaluation is off. Preparatory patch for adding the control code. [ tglx: Simplify the context switch logic and make the TIF evaluation depend on SMP=y and on the static key controlling the conditional update. Rename it to TIF_SPEC_IB because it controls both STIBP and IBPB ] Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Ingo Molnar <mingo@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Jiri Kosina <jkosina@suse.cz> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: David Woodhouse <dwmw@amazon.co.uk> Cc: Andi Kleen <ak@linux.intel.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Casey Schaufler <casey.schaufler@intel.com> Cc: Asit Mallick <asit.k.mallick@intel.com> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Jon Masters <jcm@redhat.com> Cc: Waiman Long <longman9394@gmail.com> Cc: Greg KH <gregkh@linuxfoundation.org> Cc: Dave Stewart <david.c.stewart@intel.com> Cc: Kees Cook <keescook@chromium.org> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20181125185005.176917199@linutronix.de
2018-11-28x86/speculation: Add command line control for indirect branch speculationThomas Gleixner
Add command line control for user space indirect branch speculation mitigations. The new option is: spectre_v2_user= The initial options are: - on: Unconditionally enabled - off: Unconditionally disabled -auto: Kernel selects mitigation (default off for now) When the spectre_v2= command line argument is either 'on' or 'off' this implies that the application to application control follows that state even if a contradicting spectre_v2_user= argument is supplied. Originally-by: Tim Chen <tim.c.chen@linux.intel.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Ingo Molnar <mingo@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Jiri Kosina <jkosina@suse.cz> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: David Woodhouse <dwmw@amazon.co.uk> Cc: Andi Kleen <ak@linux.intel.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Casey Schaufler <casey.schaufler@intel.com> Cc: Asit Mallick <asit.k.mallick@intel.com> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Jon Masters <jcm@redhat.com> Cc: Waiman Long <longman9394@gmail.com> Cc: Greg KH <gregkh@linuxfoundation.org> Cc: Dave Stewart <david.c.stewart@intel.com> Cc: Kees Cook <keescook@chromium.org> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20181125185005.082720373@linutronix.de
2018-11-28x86/speculation: Unify conditional spectre v2 print functionsThomas Gleixner
There is no point in having two functions and a conditional at the call site. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Ingo Molnar <mingo@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Jiri Kosina <jkosina@suse.cz> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: David Woodhouse <dwmw@amazon.co.uk> Cc: Tim Chen <tim.c.chen@linux.intel.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Casey Schaufler <casey.schaufler@intel.com> Cc: Asit Mallick <asit.k.mallick@intel.com> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Jon Masters <jcm@redhat.com> Cc: Waiman Long <longman9394@gmail.com> Cc: Greg KH <gregkh@linuxfoundation.org> Cc: Dave Stewart <david.c.stewart@intel.com> Cc: Kees Cook <keescook@chromium.org> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20181125185004.986890749@linutronix.de
2018-11-28x86/speculataion: Mark command line parser data __initdataThomas Gleixner
No point to keep that around. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Ingo Molnar <mingo@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Jiri Kosina <jkosina@suse.cz> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: David Woodhouse <dwmw@amazon.co.uk> Cc: Tim Chen <tim.c.chen@linux.intel.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Casey Schaufler <casey.schaufler@intel.com> Cc: Asit Mallick <asit.k.mallick@intel.com> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Jon Masters <jcm@redhat.com> Cc: Waiman Long <longman9394@gmail.com> Cc: Greg KH <gregkh@linuxfoundation.org> Cc: Dave Stewart <david.c.stewart@intel.com> Cc: Kees Cook <keescook@chromium.org> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20181125185004.893886356@linutronix.de
2018-11-28x86/speculation: Mark string arrays const correctlyThomas Gleixner
checkpatch.pl muttered when reshuffling the code: WARNING: static const char * array should probably be static const char * const Fix up all the string arrays. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Ingo Molnar <mingo@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Jiri Kosina <jkosina@suse.cz> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: David Woodhouse <dwmw@amazon.co.uk> Cc: Tim Chen <tim.c.chen@linux.intel.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Casey Schaufler <casey.schaufler@intel.com> Cc: Asit Mallick <asit.k.mallick@intel.com> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Jon Masters <jcm@redhat.com> Cc: Waiman Long <longman9394@gmail.com> Cc: Greg KH <gregkh@linuxfoundation.org> Cc: Dave Stewart <david.c.stewart@intel.com> Cc: Kees Cook <keescook@chromium.org> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20181125185004.800018931@linutronix.de
2018-11-28x86/speculation: Reorder the spec_v2 codeThomas Gleixner
Reorder the code so it is better grouped. No functional change. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Ingo Molnar <mingo@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Jiri Kosina <jkosina@suse.cz> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: David Woodhouse <dwmw@amazon.co.uk> Cc: Tim Chen <tim.c.chen@linux.intel.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Casey Schaufler <casey.schaufler@intel.com> Cc: Asit Mallick <asit.k.mallick@intel.com> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Jon Masters <jcm@redhat.com> Cc: Waiman Long <longman9394@gmail.com> Cc: Greg KH <gregkh@linuxfoundation.org> Cc: Dave Stewart <david.c.stewart@intel.com> Cc: Kees Cook <keescook@chromium.org> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20181125185004.707122879@linutronix.de
2018-11-28x86/l1tf: Show actual SMT stateThomas Gleixner
Use the now exposed real SMT state, not the SMT sysfs control knob state. This reflects the state of the system when the mitigation status is queried. This does not change the warning in the VMX launch code. There the dependency on the control knob makes sense because siblings could be brought online anytime after launching the VM. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Ingo Molnar <mingo@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Jiri Kosina <jkosina@suse.cz> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: David Woodhouse <dwmw@amazon.co.uk> Cc: Tim Chen <tim.c.chen@linux.intel.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Casey Schaufler <casey.schaufler@intel.com> Cc: Asit Mallick <asit.k.mallick@intel.com> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Jon Masters <jcm@redhat.com> Cc: Waiman Long <longman9394@gmail.com> Cc: Greg KH <gregkh@linuxfoundation.org> Cc: Dave Stewart <david.c.stewart@intel.com> Cc: Kees Cook <keescook@chromium.org> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20181125185004.613357354@linutronix.de
2018-11-28x86/speculation: Rework SMT state changeThomas Gleixner
arch_smt_update() is only called when the sysfs SMT control knob is changed. This means that when SMT is enabled in the sysfs control knob the system is considered to have SMT active even if all siblings are offline. To allow finegrained control of the speculation mitigations, the actual SMT state is more interesting than the fact that siblings could be enabled. Rework the code, so arch_smt_update() is invoked from each individual CPU hotplug function, and simplify the update function while at it. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Ingo Molnar <mingo@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Jiri Kosina <jkosina@suse.cz> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: David Woodhouse <dwmw@amazon.co.uk> Cc: Tim Chen <tim.c.chen@linux.intel.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Casey Schaufler <casey.schaufler@intel.com> Cc: Asit Mallick <asit.k.mallick@intel.com> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Jon Masters <jcm@redhat.com> Cc: Waiman Long <longman9394@gmail.com> Cc: Greg KH <gregkh@linuxfoundation.org> Cc: Dave Stewart <david.c.stewart@intel.com> Cc: Kees Cook <keescook@chromium.org> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20181125185004.521974984@linutronix.de
2018-11-28sched/smt: Expose sched_smt_present static keyThomas Gleixner
Make the scheduler's 'sched_smt_present' static key globaly available, so it can be used in the x86 speculation control code. Provide a query function and a stub for the CONFIG_SMP=n case. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Ingo Molnar <mingo@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Jiri Kosina <jkosina@suse.cz> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: David Woodhouse <dwmw@amazon.co.uk> Cc: Tim Chen <tim.c.chen@linux.intel.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Casey Schaufler <casey.schaufler@intel.com> Cc: Asit Mallick <asit.k.mallick@intel.com> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Jon Masters <jcm@redhat.com> Cc: Waiman Long <longman9394@gmail.com> Cc: Greg KH <gregkh@linuxfoundation.org> Cc: Dave Stewart <david.c.stewart@intel.com> Cc: Kees Cook <keescook@chromium.org> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20181125185004.430168326@linutronix.de