commit 3a2c23838bc57431265ff0c3682e826f3315bfa8 Author: Greg Kroah-Hartman Date: Wed Sep 5 09:29:56 2018 +0200 Linux 4.18.6 commit 8e6d15678656e3770e7d3720600a41a02d9a841f Author: Jann Horn Date: Tue Aug 28 17:49:01 2018 +0200 x86/dumpstack: Don't dump kernel memory based on usermode RIP commit 342db04ae71273322f0011384a9ed414df8bdae4 upstream. show_opcodes() is used both for dumping kernel instructions and for dumping user instructions. If userspace causes #PF by jumping to a kernel address, show_opcodes() can be reached with regs->ip controlled by the user, pointing to kernel code. Make sure that userspace can't trick us into dumping kernel memory into dmesg. Fixes: 7cccf0725cf7 ("x86/dumpstack: Add a show_ip() function") Signed-off-by: Jann Horn Signed-off-by: Thomas Gleixner Reviewed-by: Kees Cook Reviewed-by: Borislav Petkov Cc: "H. Peter Anvin" Cc: Andy Lutomirski Cc: security@kernel.org Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20180828154901.112726-1-jannh@google.com Signed-off-by: Greg Kroah-Hartman commit 6575b15002bfe33cc8345c6b6c3845365e154c85 Author: Scott Bauer Date: Thu Apr 26 11:51:08 2018 -0600 cdrom: Fix info leak/OOB read in cdrom_ioctl_drive_status commit 8f3fafc9c2f0ece10832c25f7ffcb07c97a32ad4 upstream. Like d88b6d04: "cdrom: information leak in cdrom_ioctl_media_changed()" There is another cast from unsigned long to int which causes a bounds check to fail with specially crafted input. The value is then used as an index in the slot array in cdrom_slot_status(). Signed-off-by: Scott Bauer Signed-off-by: Scott Bauer Cc: stable@vger.kernel.org Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit f90252556e1aa90e6b9567560829a54488187c16 Author: Vincent Whitchurch Date: Tue Aug 21 17:25:07 2018 +0200 watchdog: Mark watchdog touch functions as notrace commit cb9d7fd51d9fbb329d182423bd7b92d0f8cb0e01 upstream. Some architectures need to use stop_machine() to patch functions for ftrace, and the assumption is that the stopped CPUs do not make function calls to traceable functions when they are in the stopped state. Commit ce4f06dcbb5d ("stop_machine: Touch_nmi_watchdog() after MULTI_STOP_PREPARE") added calls to the watchdog touch functions from the stopped CPUs and those functions lack notrace annotations. This leads to crashes when enabling/disabling ftrace on ARM kernels built with the Thumb-2 instruction set. Fix it by adding the necessary notrace annotations. Fixes: ce4f06dcbb5d ("stop_machine: Touch_nmi_watchdog() after MULTI_STOP_PREPARE") Signed-off-by: Vincent Whitchurch Signed-off-by: Thomas Gleixner Cc: Peter Zijlstra Cc: oleg@redhat.com Cc: tj@kernel.org Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20180821152507.18313-1-vincent.whitchurch@axis.com Signed-off-by: Greg Kroah-Hartman commit 0f9bf062f1f134dc4087ce321fc9b54319e2006f Author: H. Nikolaus Schaller Date: Tue Jun 26 15:28:30 2018 +0200 power: generic-adc-battery: check for duplicate properties copied from iio channels commit a427503edaaed9b75ed9746a654cece7e93e60a8 upstream. If an iio channel defines a basic property, there are duplicate entries in /sys/class/power/*/uevent. So add a check to avoid duplicates. Since all channels may be duplicates, we have to modify the related error check. Signed-off-by: H. Nikolaus Schaller Cc: stable@vger.kernel.org Fixes: e60fea794e6e ("power: battery: Generic battery driver using IIO") Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman commit 7ffb7b7e834844097b6fc8118e46c5e2e4fe6fb8 Author: H. Nikolaus Schaller Date: Tue Jun 26 15:28:29 2018 +0200 power: generic-adc-battery: fix out-of-bounds write when copying channel properties commit 932d47448c3caa0fa99e84d7f5bc302aa286efd8 upstream. We did have sporadic problems in the pinctrl framework during boot where a pin group name unexpectedly became NULL leading to a NULL dereference in strcmp. Detailled analysis of the failing cases did reveal that there were two devm allocated objects close to each other. The second one was the affected group_desc in pinmux and the first one was the psy_desc->properties buffer of the gab driver. Review of the gab code showed that the address calculation for one memcpy() is wrong. It does properties + sizeof(type) * index but C is defined to do the index multiplication already for pointer + integer additions. Hence the factor was applied twice and the memcpy() does write outside of the properties buffer. Sometimes it happened to be the pinctrl and triggered the strcmp(NULL). Anyways, it is overkill to use a memcpy() here instead of a simple assignment, which is easier to read and has less risk for wrong address calculations. So we change code to a simple assignment. If we initialize the index to the first free location, we can even remove the local variable 'properties'. This bug seems to exist right from the beginning in 3.7-rc1 in commit e60fea794e6e ("power: battery: Generic battery driver using IIO") Signed-off-by: H. Nikolaus Schaller Cc: stable@vger.kernel.org Fixes: e60fea794e6e ("power: battery: Generic battery driver using IIO") Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman commit 86b0dd9d0ebc78a799075c13f34ca48cc9fc2cc0 Author: Dan Carpenter Date: Thu Aug 23 16:59:25 2018 +0300 PM / clk: signedness bug in of_pm_clk_add_clks() commit 5e2e2f9f76e157063a656351728703cb02b068f1 upstream. "count" needs to be signed for the error handling to work. I made "i" signed as well so they match. Fixes: 02113ba93ea4 (PM / clk: Add support for obtaining clocks from device-tree) Cc: 4.6+ # 4.6+ Signed-off-by: Dan Carpenter Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 350192f495ae331e278af227af3ac16b81e12f1c Author: Gustavo A. R. Silva Date: Thu Aug 23 18:06:54 2018 -0500 clk: npcm7xx: fix memory allocation commit 450b6b9b169382205f88858541a8b79830262ce7 upstream. One of the more common cases of allocation size calculations is finding the size of a structure that has a zero-sized array at the end, along with memory for some number of elements for that array. For example: struct foo { int stuff; void *entry[]; }; instance = kzalloc(sizeof(struct foo) + sizeof(void *) * count, GFP_KERNEL); Instead of leaving these open-coded and prone to type mistakes, we can now use the new struct_size() helper: instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL); Notice that, currently, there is a bug during the allocation: sizeof(npcm7xx_clk_data) should be sizeof(*npcm7xx_clk_data) Fix this bug by using struct_size() in kzalloc() This issue was detected with the help of Coccinelle. Cc: stable@vger.kernel.org Signed-off-by: Gustavo A. R. Silva Reviewed-by: Kees Cook Reviewed-by: Avi Fishman Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit a8b0c3c7c4948b1b30b36d77b823c5246f838779 Author: Alberto Panizzo Date: Fri Jul 6 15:18:51 2018 +0200 clk: rockchip: fix clk_i2sout parent selection bits on rk3399 commit a64ad008980c65d38e6cf6858429c78e6b740c41 upstream. Register, shift and mask were wrong according to datasheet. Fixes: 115510053e5e ("clk: rockchip: add clock controller for the RK3399") Cc: stable@vger.kernel.org Signed-off-by: Alberto Panizzo Signed-off-by: Anthony Brandon Signed-off-by: Heiko Stuebner Signed-off-by: Greg Kroah-Hartman commit f905fc199d7d947d33b1e5f3ee394e0d8333a319 Author: Abhishek Sahu Date: Wed Jun 20 12:57:33 2018 +0530 mtd: rawnand: qcom: wait for desc completion in all BAM channels commit 6f20070d51a20e489ef117603210264c6bcde8a5 upstream. The BAM has 3 channels - tx, rx and command. command channel is used for register read/writes, tx channel for data writes and rx channel for data reads. Currently, the driver assumes the transfer completion once it gets all the command descriptors completed. Sometimes, there is race condition between data channel (tx/rx) and command channel completion. In these cases, the data present in buffer is not valid during small window between command descriptor completion and data descriptor completion. This patch generates NAND transfer completion when both (Data and Command) DMA channels have completed all its DMA descriptors. It assigns completion callback in last DMA descriptors of that channel and wait for completion. Fixes: 8d6b6d7e135e ("mtd: nand: qcom: support for command descriptor formation") Cc: stable@vger.kernel.org Signed-off-by: Abhishek Sahu Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit 21ab6022cb673ec0e1b1251c1c768ab244ae1362 Author: Daniel Mack Date: Sun Jul 8 02:10:06 2018 +0200 mtd: rawnand: marvell: add suspend and resume hooks commit bd9c3f9b3c00da322b5e784e820533f1598f690a upstream. This patch restores the suspend and resume hooks that the old driver used to have. Apart from stopping and starting the clocks, the resume callback also nullifies the selected_chip pointer, so the next command that is issued will re-select the chip and thereby restore the timing registers. Factor out some code from marvell_nfc_init() into a new function marvell_nfc_reset() and also call it at resume time to reset some registers that don't retain their contents during low-power mode. Without this patch, a PXA3xx based system would cough up an error similar to the one below after resume. [ 44.660162] marvell-nfc 43100000.nand-controller: Timeout waiting for RB signal [ 44.671492] ubi0 error: ubi_io_write: error -110 while writing 2048 bytes to PEB 102:38912, written 0 bytes [ 44.682887] CPU: 0 PID: 1417 Comm: remote-control Not tainted 4.18.0-rc2+ #344 [ 44.691197] Hardware name: Marvell PXA3xx (Device Tree Support) [ 44.697111] Backtrace: [ 44.699593] [] (dump_backtrace) from [] (show_stack+0x18/0x1c) [ 44.708931] r7:00000800 r6:00009800 r5:00000066 r4:c6139000 [ 44.715833] [] (show_stack) from [] (dump_stack+0x20/0x28) [ 44.724206] [] (dump_stack) from [] (ubi_io_write+0x3d4/0x630) [ 44.732925] [] (ubi_io_write) from [] (ubi_eba_write_leb+0x690/0x6fc) ... Fixes: 02f26ecf8c77 ("mtd: nand: add reworked Marvell NAND controller driver") Cc: stable@vger.kernel.org Signed-off-by: Daniel Mack Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit f05cb63dc0dc01c45957fd1dd90536ba072198d2 Author: Boris Brezillon Date: Wed Jul 18 10:28:14 2018 +0200 mtd: rawnand: fsmc: Stop using chip->read_buf() commit 79e1ca37cc0c056f224cc1dd4a301b9dc2f94167 upstream. chip->read_buf is left unassigned since commit 4da712e70294 ("mtd: nand: fsmc: use ->exec_op()"), leading to a NULL pointer dereference when it's called from fsmc_read_page_hwecc(). Fix that by using the appropriate helper to read data out of the NAND. Fixes: 4da712e70294 ("mtd: nand: fsmc: use ->exec_op()") Cc: Signed-off-by: Boris Brezillon Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit 307b0cf42c9b628945ea1d1c29e64bde2944e1c4 Author: Boris Brezillon Date: Wed Jul 4 16:08:58 2018 +0200 mtd: rawnand: hynix: Use ->exec_op() in hynix_nand_reg_write_op() commit 20366e19e28f9954b25580c020d7a4e0db6055c4 upstream. Modern NAND controller drivers implement ->exec_op() instead of ->cmdfunc(), make sure we don't end up with a NULL pointer dereference when hynix_nand_reg_write_op() is called. Fixes: 8878b126df76 ("mtd: nand: add ->exec_op() implementation") Cc: Signed-off-by: Boris Brezillon Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit d47b35b84da5406a2ba2d81d902b120945046cf9 Author: Mike Christie Date: Thu Jul 26 12:13:49 2018 -0500 iscsi target: fix session creation failure handling commit 26abc916a898d34c5ad159315a2f683def3c5555 upstream. The problem is that iscsi_login_zero_tsih_s1 sets conn->sess early in iscsi_login_set_conn_values. If the function fails later like when we alloc the idr it does kfree(sess) and leaves the conn->sess pointer set. iscsi_login_zero_tsih_s1 then returns -Exyz and we then call iscsi_target_login_sess_out and access the freed memory. This patch has iscsi_login_zero_tsih_s1 either completely setup the session or completely tear it down, so later in iscsi_target_login_sess_out we can just check for it being set to the connection. Cc: stable@vger.kernel.org Fixes: 0957627a9960 ("iscsi-target: Fix sess allocation leak in...") Signed-off-by: Mike Christie Acked-by: Martin K. Petersen Signed-off-by: Matthew Wilcox Signed-off-by: Greg Kroah-Hartman commit 9558fc1bab40614e8cd6d97b1830501458721e6a Author: Bart Van Assche Date: Thu Aug 2 10:51:41 2018 -0700 scsi: core: Avoid that SCSI device removal through sysfs triggers a deadlock commit 0ee223b2e1f67cb2de9c0e3247c510d846e74d63 upstream. A long time ago the unfortunate decision was taken to add a self-deletion attribute to the sysfs SCSI device directory. That decision was unfortunate because self-deletion is really tricky. We can't drop that attribute because widely used user space software depends on it, namely the rescan-scsi-bus.sh script. Hence this patch that avoids that writing into that attribute triggers a deadlock. See also commit 7973cbd9fbd9 ("[PATCH] add sysfs attributes to scan and delete scsi_devices"). This patch avoids that self-removal triggers the following deadlock: ====================================================== WARNING: possible circular locking dependency detected 4.18.0-rc2-dbg+ #5 Not tainted ------------------------------------------------------ modprobe/6539 is trying to acquire lock: 000000008323c4cd (kn->count#202){++++}, at: kernfs_remove_by_name_ns+0x45/0x90 but task is already holding lock: 00000000a6ec2c69 (&shost->scan_mutex){+.+.}, at: scsi_remove_host+0x21/0x150 [scsi_mod] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&shost->scan_mutex){+.+.}: __mutex_lock+0xfe/0xc70 mutex_lock_nested+0x1b/0x20 scsi_remove_device+0x26/0x40 [scsi_mod] sdev_store_delete+0x27/0x30 [scsi_mod] dev_attr_store+0x3e/0x50 sysfs_kf_write+0x87/0xa0 kernfs_fop_write+0x190/0x230 __vfs_write+0xd2/0x3b0 vfs_write+0x101/0x270 ksys_write+0xab/0x120 __x64_sys_write+0x43/0x50 do_syscall_64+0x77/0x230 entry_SYSCALL_64_after_hwframe+0x49/0xbe -> #0 (kn->count#202){++++}: lock_acquire+0xd2/0x260 __kernfs_remove+0x424/0x4a0 kernfs_remove_by_name_ns+0x45/0x90 remove_files.isra.1+0x3a/0x90 sysfs_remove_group+0x5c/0xc0 sysfs_remove_groups+0x39/0x60 device_remove_attrs+0x82/0xb0 device_del+0x251/0x580 __scsi_remove_device+0x19f/0x1d0 [scsi_mod] scsi_forget_host+0x37/0xb0 [scsi_mod] scsi_remove_host+0x9b/0x150 [scsi_mod] sdebug_driver_remove+0x4b/0x150 [scsi_debug] device_release_driver_internal+0x241/0x360 device_release_driver+0x12/0x20 bus_remove_device+0x1bc/0x290 device_del+0x259/0x580 device_unregister+0x1a/0x70 sdebug_remove_adapter+0x8b/0xf0 [scsi_debug] scsi_debug_exit+0x76/0xe8 [scsi_debug] __x64_sys_delete_module+0x1c1/0x280 do_syscall_64+0x77/0x230 entry_SYSCALL_64_after_hwframe+0x49/0xbe other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&shost->scan_mutex); lock(kn->count#202); lock(&shost->scan_mutex); lock(kn->count#202); *** DEADLOCK *** 2 locks held by modprobe/6539: #0: 00000000efaf9298 (&dev->mutex){....}, at: device_release_driver_internal+0x68/0x360 #1: 00000000a6ec2c69 (&shost->scan_mutex){+.+.}, at: scsi_remove_host+0x21/0x150 [scsi_mod] stack backtrace: CPU: 10 PID: 6539 Comm: modprobe Not tainted 4.18.0-rc2-dbg+ #5 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014 Call Trace: dump_stack+0xa4/0xf5 print_circular_bug.isra.34+0x213/0x221 __lock_acquire+0x1a7e/0x1b50 lock_acquire+0xd2/0x260 __kernfs_remove+0x424/0x4a0 kernfs_remove_by_name_ns+0x45/0x90 remove_files.isra.1+0x3a/0x90 sysfs_remove_group+0x5c/0xc0 sysfs_remove_groups+0x39/0x60 device_remove_attrs+0x82/0xb0 device_del+0x251/0x580 __scsi_remove_device+0x19f/0x1d0 [scsi_mod] scsi_forget_host+0x37/0xb0 [scsi_mod] scsi_remove_host+0x9b/0x150 [scsi_mod] sdebug_driver_remove+0x4b/0x150 [scsi_debug] device_release_driver_internal+0x241/0x360 device_release_driver+0x12/0x20 bus_remove_device+0x1bc/0x290 device_del+0x259/0x580 device_unregister+0x1a/0x70 sdebug_remove_adapter+0x8b/0xf0 [scsi_debug] scsi_debug_exit+0x76/0xe8 [scsi_debug] __x64_sys_delete_module+0x1c1/0x280 do_syscall_64+0x77/0x230 entry_SYSCALL_64_after_hwframe+0x49/0xbe See also https://www.mail-archive.com/linux-scsi@vger.kernel.org/msg54525.html. Fixes: ac0ece9174ac ("scsi: use device_remove_file_self() instead of device_schedule_callback()") Signed-off-by: Bart Van Assche Cc: Greg Kroah-Hartman Acked-by: Tejun Heo Cc: Johannes Thumshirn Cc: Signed-off-by: Greg Kroah-Hartman Signed-off-by: Martin K. Petersen commit 807d1d299a04e9ad9a9dac55419c1137a105254b Author: Bart Van Assche Date: Thu Aug 2 10:51:40 2018 -0700 scsi: sysfs: Introduce sysfs_{un,}break_active_protection() commit 2afc9166f79b8f6da5f347f48515215ceee4ae37 upstream. Introduce these two functions and export them such that the next patch can add calls to these functions from the SCSI core. Signed-off-by: Bart Van Assche Acked-by: Tejun Heo Acked-by: Greg Kroah-Hartman Cc: Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 373a1411a10306721596f84b34d8b39ccd2309b6 Author: Bart Van Assche Date: Fri Jun 15 14:41:58 2018 -0700 scsi: mpt3sas: Fix _transport_smp_handler() error path commit 91b7bdb2c0089cbbb817df6888ab1458c645184e upstream. This patch avoids that smatch complains about a double unlock on ioc->transport_cmds.mutex. Fixes: 651a01364994 ("scsi: scsi_transport_sas: switch to bsg-lib for SMP passthrough") Signed-off-by: Bart Van Assche Cc: Christoph Hellwig Cc: Sathya Prakash Cc: Chaitra P B Cc: Suganath Prabu Subramani Cc: stable@vger.kernel.org Reviewed-by: Christoph Hellwig Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 8039fa72ff4d365e7eb029a63dd3bd0c03d55d8e Author: Sreekanth Reddy Date: Thu Jul 12 12:53:29 2018 -0400 scsi: mpt3sas: Fix calltrace observed while running IO & reset commit e70183143cc472960bc60dfee1b7bbe1949feffb upstream. Below kernel BUG was observed while running IOs with host reset (issued from application), mpt3sas_cm0: diag reset: SUCCESS ------------[ cut here ]------------ WARNING: CPU: 12 PID: 4336 at drivers/scsi/mpt3sas/mpt3sas_base.c:3282 mpt3sas_base_clear_st+0x3d/0x40 [mpt3sas] Modules linked in: macsec tcp_diag udp_diag inet_diag unix_diag af_packet_diag netlink_diag binfmt_misc fuse xt_CHECKSUM ipt_MASQUERADE nf_nat_masquerade_ipv4 tun devlink ip6t_rpfilter ipt_REJECT nf_reject_ipv4 ip6t_REJECT nf_reject_ipv6 xt_conntrack ip_set nfnetlink ebtable_nat ebtable_broute bridge stp llc ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter sunrpc vfat fat sb_edac intel_powerclamp coretemp intel_rapl iosf_mbi kvm_intel kvm irqbypass crc32_pclmul ghash_clmulni_intel aesni_intel lrw gf128mul glue_helper ablk_helper cryptd iTCO_wdt iTCO_vendor_support dcdbas pcspkr joydev ipmi_ssif ses enclosure sg ipmi_devintf acpi_pad ipmi_msghandler acpi_power_meter mei_me lpc_ich wmi mei shpchp ip_tables xfs libcrc32c sd_mod crc_t10dif crct10dif_generic ata_generic pata_acpi uas usb_storage mgag200 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm ata_piix mpt3sas libata crct10dif_pclmul crct10dif_common tg3 crc32c_intel i2c_core raid_class ptp scsi_transport_sas pps_core dm_mirror dm_region_hash dm_log dm_mod CPU: 12 PID: 4336 Comm: python Kdump: loaded Tainted: G W ------------ 3.10.0-875.el7.brdc.x86_64 #1 Hardware name: Dell Inc. PowerEdge R820/0YWR73, BIOS 1.5.0 03/08/2013 Call Trace: [] dump_stack+0x19/0x1b [] __warn+0xd8/0x100 [] warn_slowpath_null+0x1d/0x20 [] mpt3sas_base_clear_st+0x3d/0x40 [mpt3sas] [] _scsih_flush_running_cmds+0x92/0xe0 [mpt3sas] [] mpt3sas_scsih_reset_handler+0x43b/0xaf0 [mpt3sas] [] ? vprintk_default+0x29/0x40 [] ? printk+0x60/0x77 [] ? _base_diag_reset+0x238/0x340 [mpt3sas] [] mpt3sas_base_hard_reset_handler+0x1ad/0x420 [mpt3sas] [] _ctl_ioctl_main.isra.12+0x11b9/0x1200 [mpt3sas] [] ? xfs_file_aio_write+0x155/0x1b0 [xfs] [] ? do_sync_write+0x93/0xe0 [] _ctl_ioctl+0x1a/0x20 [mpt3sas] [] do_vfs_ioctl+0x350/0x560 [] ? __sb_end_write+0x31/0x60 [] SyS_ioctl+0xa1/0xc0 [] ? system_call_after_swapgs+0xa2/0x146 [] system_call_fastpath+0x1c/0x21 [] ? system_call_after_swapgs+0xae/0x146 ---[ end trace 5dac5b98d89aaa3c ]--- ------------[ cut here ]------------ kernel BUG at block/blk-core.c:1476! invalid opcode: 0000 [#1] SMP Modules linked in: macsec tcp_diag udp_diag inet_diag unix_diag af_packet_diag netlink_diag binfmt_misc fuse xt_CHECKSUM ipt_MASQUERADE nf_nat_masquerade_ipv4 tun devlink ip6t_rpfilter ipt_REJECT nf_reject_ipv4 ip6t_REJECT nf_reject_ipv6 xt_conntrack ip_set nfnetlink ebtable_nat ebtable_broute bridge stp llc ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter sunrpc vfat fat sb_edac intel_powerclamp coretemp intel_rapl iosf_mbi kvm_intel kvm irqbypass crc32_pclmul ghash_clmulni_intel aesni_intel lrw gf128mul glue_helper ablk_helper cryptd iTCO_wdt iTCO_vendor_support dcdbas pcspkr joydev ipmi_ssif ses enclosure sg ipmi_devintf acpi_pad ipmi_msghandler acpi_power_meter mei_me lpc_ich wmi mei shpchp ip_tables xfs libcrc32c sd_mod crc_t10dif crct10dif_generic ata_generic pata_acpi uas usb_storage mgag200 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm ata_piix mpt3sas libata crct10dif_pclmul crct10dif_common tg3 crc32c_intel i2c_core raid_class ptp scsi_transport_sas pps_core dm_mirror dm_region_hash dm_log dm_mod CPU: 12 PID: 4336 Comm: python Kdump: loaded Tainted: G W ------------ 3.10.0-875.el7.brdc.x86_64 #1 Hardware name: Dell Inc. PowerEdge R820/0YWR73, BIOS 1.5.0 03/08/2013 task: ffff903fc96e0fd0 ti: ffff903fb1eec000 task.ti: ffff903fb1eec000 RIP: 0010:[] [] blk_requeue_request+0x90/0xa0 RSP: 0018:ffff903c6b783dc0 EFLAGS: 00010087 RAX: ffff903bb67026d0 RBX: ffff903b7d6a6140 RCX: dead000000000200 RDX: ffff903bb67026d0 RSI: ffff903bb6702580 RDI: ffff903bb67026d0 RBP: ffff903c6b783dd8 R08: ffff903bb67026d0 R09: ffffd97e80000000 R10: ffff903c658bac00 R11: 0000000000000000 R12: ffff903bb6702580 R13: ffff903fa9a292f0 R14: 0000000000000246 R15: 0000000000001057 FS: 00007f7026f5b740(0000) GS:ffff903c6b780000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f298877c004 CR3: 00000000caf36000 CR4: 00000000000607e0 Call Trace: [] __scsi_queue_insert+0xbf/0x110 [] scsi_io_completion+0x5da/0x6a0 [] scsi_finish_command+0xdc/0x140 [] scsi_softirq_done+0x132/0x160 [] blk_done_softirq+0x96/0xc0 [] __do_softirq+0xf5/0x280 [] call_softirq+0x1c/0x30 [] do_softirq+0x65/0xa0 [] irq_exit+0x105/0x110 [] smp_apic_timer_interrupt+0x48/0x60 [] apic_timer_interrupt+0x162/0x170 [] ? scsi_done+0x21/0x60 [] ? delay_tsc+0x38/0x60 [] __const_udelay+0x2d/0x30 [] _base_handshake_req_reply_wait+0x8e/0x4a0 [mpt3sas] [] _base_get_ioc_facts+0x123/0x590 [mpt3sas] [] ? _base_diag_reset+0x238/0x340 [mpt3sas] [] mpt3sas_base_hard_reset_handler+0x1f3/0x420 [mpt3sas] [] _ctl_ioctl_main.isra.12+0x11b9/0x1200 [mpt3sas] [] ? xfs_file_aio_write+0x155/0x1b0 [xfs] [] ? do_sync_write+0x93/0xe0 [] _ctl_ioctl+0x1a/0x20 [mpt3sas] [] do_vfs_ioctl+0x350/0x560 [] ? __sb_end_write+0x31/0x60 [] SyS_ioctl+0xa1/0xc0 [] ? system_call_after_swapgs+0xa2/0x146 [] system_call_fastpath+0x1c/0x21 [] ? system_call_after_swapgs+0xae/0x146 Code: 83 c3 10 4c 89 e2 4c 89 ee e8 8d 21 04 00 48 8b 03 48 85 c0 75 e5 41 f6 44 24 4a 10 74 ad 4c 89 e6 4c 89 ef e8 b2 42 00 00 eb a0 <0f> 0b 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 RIP [] blk_requeue_request+0x90/0xa0 RSP As a part of host reset operation, driver will flushout all IOs outstanding at driver level with "DID_RESET" result. To find which are all commands outstanding at the driver level, driver loops with smid starting from one to HBA queue depth and calls mpt3sas_scsih_scsi_lookup_get() to get scmd as shown below for (smid = 1; smid <= ioc->scsiio_depth; smid++) { scmd = mpt3sas_scsih_scsi_lookup_get(ioc, smid); if (!scmd) continue; But in mpt3sas_scsih_scsi_lookup_get() function, driver returns some scsi cmnds which are not outstanding at the driver level (possibly request is constructed at block layer since QUEUE_FLAG_QUIESCED is not set. Even if driver uses scsi_block_requests and scsi_unblock_requests, issue still persists as they will be just blocking further IO from scsi layer and not from block layer) and these commands are flushed with DID_RESET host bytes thus resulting into above kernel BUG. This issue got introduced by commit dbec4c9040ed ("scsi: mpt3sas: lockless command submission"). To fix this issue, we have modified the mpt3sas_scsih_scsi_lookup_get() to check for smid equals to zero (note: whenever any scsi cmnd is processing at the driver level then smid for that scsi cmnd will be non-zero, always it starts from one) before it returns the scmd pointer to the caller. If smid is zero then this function returns scmd pointer as NULL and driver won't flushout those scsi cmnds at driver level with DID_RESET host byte thus this issue will not be observed. [mkp: amended with updated fix from Sreekanth] Signed-off-by: Sreekanth Reddy Fixes: dbec4c9040ed ("scsi: mpt3sas: lockless command submission") Cc: stable@vger.kernel.org # v4.16+ Reviewed-by: Tomas Henzl Reviewed-by: Bart Van Assche Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 7624ac8705f5cc2d59259c1a7259170b89402685 Author: Tomas Winkler Date: Thu Jun 28 18:13:33 2018 +0300 tpm: separate cmd_ready/go_idle from runtime_pm commit 627448e85c766587f6fdde1ea3886d6615081c77 upstream. Fix tpm ptt initialization error: tpm tpm0: A TPM error (378) occurred get tpm pcr allocation. We cannot use go_idle cmd_ready commands via runtime_pm handles as with the introduction of localities this is no longer an optional feature, while runtime pm can be not enabled. Though cmd_ready/go_idle provides a power saving, it's also a part of TPM2 protocol and should be called explicitly. This patch exposes cmd_read/go_idle via tpm class ops and removes runtime pm support as it is not used by any driver. When calling from nested context always use both flags: TPM_TRANSMIT_UNLOCKED and TPM_TRANSMIT_RAW. Both are needed to resolve tpm spaces and locality request recursive calls to tpm_transmit(). TPM_TRANSMIT_RAW should never be used standalone as it will fail on double locking. While TPM_TRANSMIT_UNLOCKED standalone should be called from non-recursive locked contexts. New wrappers are added tpm_cmd_ready() and tpm_go_idle() to streamline tpm_try_transmit code. tpm_crb no longer needs own power saving functions and can drop using tpm_pm_suspend/resume. This patch cannot be really separated from the locality fix. Fixes: 888d867df441 (tpm: cmd_ready command can be issued only after granting locality) Cc: stable@vger.kernel.org Fixes: 888d867df441 (tpm: cmd_ready command can be issued only after granting locality) Signed-off-by: Tomas Winkler Tested-by: Jarkko Sakkinen Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit b64b3b46074e66c2cd0a620e26984a5f134cb64f Author: Ricardo Schwarzmeier Date: Tue Jun 26 17:31:45 2018 +0200 tpm: Return the actual size when receiving an unsupported command commit 36a11029b07ee30bdc4553274d0efea645ed9d91 upstream. The userpace expects to read the number of bytes stated in the header. Returning the size of the buffer instead would be unexpected. Cc: stable@vger.kernel.org Fixes: 095531f891e6 ("tpm: return a TPM_RC_COMMAND_CODE response if command is not implemented") Signed-off-by: Ricardo Schwarzmeier Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit d07d4e8b68fd87533cd0b2cbbcf9f93c9129841f Author: Paul Burton Date: Tue Aug 21 12:12:59 2018 -0700 MIPS: lib: Provide MIPS64r6 __multi3() for GCC < 7 commit 690d9163bf4b8563a2682e619f938e6a0443947f upstream. Some versions of GCC suboptimally generate calls to the __multi3() intrinsic for MIPS64r6 builds, resulting in link failures due to the missing function: LD vmlinux.o MODPOST vmlinux.o kernel/bpf/verifier.o: In function `kmalloc_array': include/linux/slab.h:631: undefined reference to `__multi3' fs/select.o: In function `kmalloc_array': include/linux/slab.h:631: undefined reference to `__multi3' ... We already have a workaround for this in which we provide the instrinsic, but we do so selectively for GCC 7 only. Unfortunately the issue occurs with older GCC versions too - it has been observed with both GCC 5.4.0 & GCC 6.4.0. MIPSr6 support was introduced in GCC 5, so all major GCC versions prior to GCC 8 are affected and we extend our workaround accordingly to all MIPS64r6 builds using GCC versions older than GCC 8. Signed-off-by: Paul Burton Reported-by: Vladimir Kondratiev Fixes: ebabcf17bcd7 ("MIPS: Implement __multi3 for GCC7 MIPS64r6 builds") Patchwork: https://patchwork.linux-mips.org/patch/20297/ Cc: James Hogan Cc: Ralf Baechle Cc: linux-mips@linux-mips.org Cc: stable@vger.kernel.org # 4.15+ Signed-off-by: Greg Kroah-Hartman commit 8f55e1f507d6e2436d876cf5c4f1a80b51a23432 Author: Huacai Chen Date: Fri Jul 13 15:37:57 2018 +0800 MIPS: Change definition of cpu_relax() for Loongson-3 commit a30718868915fbb991a9ae9e45594b059f28e9ae upstream. Linux expects that if a CPU modifies a memory location, then that modification will eventually become visible to other CPUs in the system. Loongson 3 CPUs include a Store Fill Buffer (SFB) which sits between a core & its L1 data cache, queueing memory accesses & allowing for faster forwarding of data from pending stores to younger loads from the core. Unfortunately the SFB prioritizes loads such that a continuous stream of loads may cause a pending write to be buffered indefinitely. This is problematic if we end up with 2 CPUs which each perform a store that the other polls for - one or both CPUs may end up with their stores buffered in the SFB, never reaching cache due to the continuous reads from the poll loop. Such a deadlock condition has been observed whilst running qspinlock code. This patch changes the definition of cpu_relax() to smp_mb() for Loongson-3, forcing a flush of the SFB on SMP systems which will cause any pending writes to make it as far as the L1 caches where they will become visible to other CPUs. If the kernel is not compiled for SMP support, this will expand to a barrier() as before. This workaround matches that currently implemented for ARM when CONFIG_ARM_ERRATA_754327=y, which was introduced by commit 534be1d5a2da ("ARM: 6194/1: change definition of cpu_relax() for ARM11MPCore"). Although the workaround is only required when the Loongson 3 SFB functionality is enabled, and we only began explicitly enabling that functionality in v4.7 with commit 1e820da3c9af ("MIPS: Loongson-3: Introduce CONFIG_LOONGSON3_ENHANCEMENT"), existing or future firmware may enable the SFB which means we may need the workaround backported to earlier kernels too. [paul.burton@mips.com: - Reword commit message & comment. - Limit stable backport to v3.15+ where we support Loongson 3 CPUs.] Signed-off-by: Huacai Chen Signed-off-by: Paul Burton References: 534be1d5a2da ("ARM: 6194/1: change definition of cpu_relax() for ARM11MPCore") References: 1e820da3c9af ("MIPS: Loongson-3: Introduce CONFIG_LOONGSON3_ENHANCEMENT") Patchwork: https://patchwork.linux-mips.org/patch/19830/ Cc: Ralf Baechle Cc: James Hogan Cc: linux-mips@linux-mips.org Cc: Fuxin Zhang Cc: Zhangjin Wu Cc: Huacai Chen Cc: stable@vger.kernel.org # v3.15+ Signed-off-by: Greg Kroah-Hartman commit 9238ea28869e42f0869529f4e910f0b1d28e1a8e Author: Paul Burton Date: Mon Jun 18 17:37:59 2018 -0700 MIPS: Always use -march=, not - shortcuts commit 344ebf09949c31bcb8818d8458b65add29f1d67b upstream. The VDSO Makefile filters CFLAGS to select a subset which it uses whilst building the VDSO ELF. One of the flags it allows through is the -march= flag that selects the architecture/ISA to target. Unfortunately in cases where CONFIG_CPU_MIPS32_R{1,2}=y and the toolchain defaults to building for MIPS64, the main MIPS Makefile ends up using the short-form - flags in cflags-y. This is because the calls to cc-option always fail to use the long-form -march= flag due to the lack of an -mabi= flag in KBUILD_CFLAGS at the point where the cc-option function is executed. The resulting GCC invocation is something like: $ mips64-linux-gcc -Werror -march=mips32r2 -c -x c /dev/null -o tmp cc1: error: '-march=mips32r2' is not compatible with the selected ABI These short-form - flags are dropped by the VDSO Makefile's filtering, and so we attempt to build the VDSO without specifying any architecture. This results in an attempt to build the VDSO using whatever the compiler's default architecture is, regardless of whether that is suitable for the kernel configuration. One encountered build failure resulting from this mismatch is a rejection of the sync instruction if the kernel is configured for a MIPS32 or MIPS64 r1 or r2 target but the toolchain defaults to an older architecture revision such as MIPS1 which did not include the sync instruction: CC arch/mips/vdso/gettimeofday.o /tmp/ccGQKoOj.s: Assembler messages: /tmp/ccGQKoOj.s:273: Error: opcode not supported on this processor: mips1 (mips1) `sync' /tmp/ccGQKoOj.s:329: Error: opcode not supported on this processor: mips1 (mips1) `sync' /tmp/ccGQKoOj.s:520: Error: opcode not supported on this processor: mips1 (mips1) `sync' /tmp/ccGQKoOj.s:714: Error: opcode not supported on this processor: mips1 (mips1) `sync' /tmp/ccGQKoOj.s:1009: Error: opcode not supported on this processor: mips1 (mips1) `sync' /tmp/ccGQKoOj.s:1066: Error: opcode not supported on this processor: mips1 (mips1) `sync' /tmp/ccGQKoOj.s:1114: Error: opcode not supported on this processor: mips1 (mips1) `sync' /tmp/ccGQKoOj.s:1279: Error: opcode not supported on this processor: mips1 (mips1) `sync' /tmp/ccGQKoOj.s:1334: Error: opcode not supported on this processor: mips1 (mips1) `sync' /tmp/ccGQKoOj.s:1374: Error: opcode not supported on this processor: mips1 (mips1) `sync' /tmp/ccGQKoOj.s:1459: Error: opcode not supported on this processor: mips1 (mips1) `sync' /tmp/ccGQKoOj.s:1514: Error: opcode not supported on this processor: mips1 (mips1) `sync' /tmp/ccGQKoOj.s:1814: Error: opcode not supported on this processor: mips1 (mips1) `sync' /tmp/ccGQKoOj.s:2002: Error: opcode not supported on this processor: mips1 (mips1) `sync' /tmp/ccGQKoOj.s:2066: Error: opcode not supported on this processor: mips1 (mips1) `sync' make[2]: *** [scripts/Makefile.build:318: arch/mips/vdso/gettimeofday.o] Error 1 make[1]: *** [scripts/Makefile.build:558: arch/mips/vdso] Error 2 make[1]: *** Waiting for unfinished jobs.... This can be reproduced for example by attempting to build pistachio_defconfig using Arnd's GCC 8.1.0 mips64 toolchain from kernel.org: https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/8.1.0/x86_64-gcc-8.1.0-nolibc-mips64-linux.tar.xz Resolve this problem by using the long-form -march= in all cases, which makes it through the arch/mips/vdso/Makefile's filtering & is thus consistently used to build both the kernel proper & the VDSO. The use of cc-option to prefer the long-form & fall back to the short-form flags makes no sense since the short-form is just an abbreviation for the also-supported long-form in all GCC versions that we support building with. This means there is no case in which we have to use the short-form - flags, so we can simply remove them. The manual redefinition of _MIPS_ISA is removed naturally along with the use of the short-form flags that it accompanied, and whilst here we remove the separate assembler ISA selection. I suspect that both of these were only required due to the mips32 vs mips2 mismatch that was introduced by commit 59b3e8e9aac6 ("[MIPS] Makefile crapectomy.") and fixed but not cleaned up by commit 9200c0b2a07c ("[MIPS] Fix Makefile bugs for MIPS32/MIPS64 R1 and R2."). I've marked this for backport as far as v4.4 where the MIPS VDSO was introduced. In earlier kernels there should be no ill effect to using the short-form flags. Signed-off-by: Paul Burton Cc: Ralf Baechle Cc: linux-mips@linux-mips.org Cc: stable@vger.kernel.org # v4.4+ Reviewed-by: James Hogan Patchwork: https://patchwork.linux-mips.org/patch/19579/ Signed-off-by: Greg Kroah-Hartman commit 8d6a4b45018c0c95322dcd52ce0cb5dfd8caecd2 Author: Matt Redfearn Date: Wed May 23 14:39:58 2018 +0100 MIPS: memset.S: Fix byte_fixup for MIPSr6 commit b1c03f1ef48d36ff28afb06e8f0c1233ef072f1d upstream. The __clear_user function is defined to return the number of bytes that could not be cleared. From the underlying memset / bzero implementation this means setting register a2 to that number on return. Currently if a page fault is triggered within the MIPSr6 version of setting of initial unaligned bytes, the value loaded into a2 on return is meaningless. During the MIPSr6 version of the initial unaligned bytes block, register a2 contains the number of bytes to be set beyond the initial unaligned bytes. The t0 register is initally set to the number of unaligned bytes - STORSIZE, effectively a negative version of the number of unaligned bytes. This is then incremented before each byte is saved. The label .Lbyte_fixup\@ is jumped to on page fault. Currently the value in a2 is incorrectly replaced by 0 - t0 + 1, effectively the number of unaligned bytes remaining. This leads to the failures being reported by the following test code: static int __init test_clear_user(void) { int j, k; pr_info("\n\n\nTesting clear_user\n"); for (j = 0; j < 512; j++) { if ((k = clear_user(NULL+3, j)) != j) { pr_err("clear_user (NULL %d) returned %d\n", j, k); } } return 0; } late_initcall(test_clear_user); Which reports: [ 3.965439] Testing clear_user [ 3.973169] clear_user (NULL 8) returned 6 [ 3.976782] clear_user (NULL 9) returned 6 [ 3.980390] clear_user (NULL 10) returned 6 [ 3.984052] clear_user (NULL 11) returned 6 [ 3.987524] clear_user (NULL 12) returned 6 Fix this by subtracting t0 from a2 (rather than $0), effectivey giving: unset_bytes = (#bytes - (#unaligned bytes)) - (-#unaligned bytes remaining + 1) + 1 a2 = a2 - t0 + 1 This fixes the value returned from __clear user when the number of bytes to set is > LONGSIZE and the address is invalid and unaligned. Unfortunately, this breaks the fixup handling for unaligned bytes after the final long, where register a2 still contains the number of bytes remaining to be set and the t0 register is to 0 - the number of unaligned bytes remaining. Because t0 is now is now subtracted from a2 rather than 0, the number of bytes unset is reported incorrectly: static int __init test_clear_user(void) { char *test; int j, k; pr_info("\n\n\nTesting clear_user\n"); test = vmalloc(PAGE_SIZE); for (j = 256; j < 512; j++) { if ((k = clear_user(test + PAGE_SIZE - 254, j)) != j - 254) { pr_err("clear_user (%px %d) returned %d\n", test + PAGE_SIZE - 254, j, k); } } return 0; } late_initcall(test_clear_user); [ 3.976775] clear_user (c00000000000df02 256) returned 4 [ 3.981957] clear_user (c00000000000df02 257) returned 6 [ 3.986425] clear_user (c00000000000df02 258) returned 8 [ 3.990850] clear_user (c00000000000df02 259) returned 10 [ 3.995332] clear_user (c00000000000df02 260) returned 12 [ 3.999815] clear_user (c00000000000df02 261) returned 14 Fix this by ensuring that a2 is set to 0 during the set of final unaligned bytes. Signed-off-by: Matt Redfearn Signed-off-by: Paul Burton Fixes: 8c56208aff77 ("MIPS: lib: memset: Add MIPS R6 support") Patchwork: https://patchwork.linux-mips.org/patch/19338/ Cc: James Hogan Cc: Ralf Baechle Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org # v4.0+ Signed-off-by: Greg Kroah-Hartman commit d06e5e4a8a284006769c99b7e5d216b0e3c9c735 Author: Maciej W. Rozycki Date: Tue May 15 23:33:26 2018 +0100 MIPS: Correct the 64-bit DSP accumulator register size commit f5958b4cf4fc38ed4583ab83fb7c4cd1ab05f47b upstream. Use the `unsigned long' rather than `__u32' type for DSP accumulator registers, like with the regular MIPS multiply/divide accumulator and general-purpose registers, as all are 64-bit in 64-bit implementations and using a 32-bit data type leads to contents truncation on context saving. Update `arch_ptrace' and `compat_arch_ptrace' accordingly, removing casts that are similarly not used with multiply/divide accumulator or general-purpose register accesses. Signed-off-by: Maciej W. Rozycki Signed-off-by: Paul Burton Fixes: e50c0a8fa60d ("Support the MIPS32 / MIPS64 DSP ASE.") Patchwork: https://patchwork.linux-mips.org/patch/19329/ Cc: Alexander Viro Cc: James Hogan Cc: Ralf Baechle Cc: linux-fsdevel@vger.kernel.org Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org # 2.6.15+ Signed-off-by: Greg Kroah-Hartman commit 968a9a4a8a972028ab9ba0d13335709628996d3e Author: Masami Hiramatsu Date: Sat Apr 28 21:35:01 2018 +0900 kprobes: Make list and blacklist root user read only commit f2a3ab36077222437b4826fc76111caa14562b7c upstream. Since the blacklist and list files on debugfs indicates a sensitive address information to reader, it should be restricted to the root user. Suggested-by: Thomas Richter Suggested-by: Ingo Molnar Signed-off-by: Masami Hiramatsu Cc: Ananth N Mavinakayanahalli Cc: Anil S Keshavamurthy Cc: Arnd Bergmann Cc: David Howells Cc: David S . Miller Cc: Heiko Carstens Cc: Jon Medhurst Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Tobin C . Harding Cc: Will Deacon Cc: acme@kernel.org Cc: akpm@linux-foundation.org Cc: brueckner@linux.vnet.ibm.com Cc: linux-arch@vger.kernel.org Cc: rostedt@goodmis.org Cc: schwidefsky@de.ibm.com Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/lkml/152491890171.9916.5183693615601334087.stgit@devbox Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 2f56c8af315b40a751251fed97fc8f044244d829 Author: Masami Hiramatsu Date: Sat Apr 28 21:37:33 2018 +0900 kprobes/arm: Fix %p uses in error messages commit 75b2f5f5911fe7a2fc82969b2b24dde34e8f820d upstream. Fix %p uses in error messages by removing it and using general dumper. Signed-off-by: Masami Hiramatsu Cc: Ananth N Mavinakayanahalli Cc: Anil S Keshavamurthy Cc: Arnd Bergmann Cc: David Howells Cc: David S . Miller Cc: Heiko Carstens Cc: Jon Medhurst Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Thomas Richter Cc: Tobin C . Harding Cc: Will Deacon Cc: acme@kernel.org Cc: akpm@linux-foundation.org Cc: brueckner@linux.vnet.ibm.com Cc: linux-arch@vger.kernel.org Cc: rostedt@goodmis.org Cc: schwidefsky@de.ibm.com Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/lkml/152491905361.9916.15300852365956231645.stgit@devbox Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 10334e1ad3d0fc325b52ccad96912e50174e2556 Author: Masami Hiramatsu Date: Sat Apr 28 21:36:33 2018 +0900 kprobes: Replace %p with other pointer types commit 4458515b2c52831ee622411d2fe3e774d1f5c49a upstream. Replace %p with %pS or just remove it if unneeded. And use WARN_ONCE() if it is a single bug. Signed-off-by: Masami Hiramatsu Cc: Ananth N Mavinakayanahalli Cc: Anil S Keshavamurthy Cc: Arnd Bergmann Cc: David Howells Cc: David S . Miller Cc: Heiko Carstens Cc: Jon Medhurst Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Thomas Richter Cc: Tobin C . Harding Cc: Will Deacon Cc: acme@kernel.org Cc: akpm@linux-foundation.org Cc: brueckner@linux.vnet.ibm.com Cc: linux-arch@vger.kernel.org Cc: rostedt@goodmis.org Cc: schwidefsky@de.ibm.com Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/lkml/152491899284.9916.5350534544808158621.stgit@devbox Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit b143efb4242cdaae12ef0042289d75b1e71ad755 Author: Masami Hiramatsu Date: Sat Apr 28 21:35:32 2018 +0900 kprobes: Show blacklist addresses as same as kallsyms does commit ffb9bd68ebdb3b8d00ef5a79bbe8167a3281cace upstream. Show kprobes blacklist addresses under same condition of showing kallsyms addresses. Since there are several name conflict for local symbols, kprobe blacklist needs to show each addresses so that user can identify where is on blacklist by comparing with kallsyms. Signed-off-by: Masami Hiramatsu Cc: Ananth N Mavinakayanahalli Cc: Anil S Keshavamurthy Cc: Arnd Bergmann Cc: David Howells Cc: David S . Miller Cc: Heiko Carstens Cc: Jon Medhurst Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Thomas Richter Cc: Tobin C . Harding Cc: Will Deacon Cc: acme@kernel.org Cc: akpm@linux-foundation.org Cc: brueckner@linux.vnet.ibm.com Cc: linux-arch@vger.kernel.org Cc: rostedt@goodmis.org Cc: schwidefsky@de.ibm.com Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/lkml/152491893217.9916.14760965896164273464.stgit@devbox Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit d6c96d240daacb09833f8dde1ef8cb34c8b79d99 Author: Philipp Rudo Date: Tue Jun 26 18:24:52 2018 +0200 s390/purgatory: Add missing FORCE to Makefile targets commit c315e69308c739a43c4ebc539bedbc1ac8d79854 upstream. Without FORCE make does not detect changes only made to the command line options. So object files might not be re-built even when they should be. Fix this by adding FORCE where it is missing. Fixes: 840798a1f5299 ("s390/kexec_file: Add purgatory") Cc: # 4.17 Signed-off-by: Philipp Rudo Acked-by: Heiko Carstens Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit 5a2e51f95908150ce7b107389b0c089938809e91 Author: Philipp Rudo Date: Tue Jun 26 12:24:30 2018 +0200 s390/purgatory: Fix crash with expoline enabled commit ad03b821fbc30395b72af438f5bb41676a5f891d upstream. When the kernel is built with CONFIG_EXPOLINE=y and a compiler with indirect branch mitigation enabled the purgatory crashes. The reason for that is that the macros defined for expoline are used in mem.S. These macros define new sections (.text.__s390x_indirect_*) which are marked executable. Due to the missing linker script those sections are linked to address 0, just as the .text section. In combination with the entry point also being at address 0 this causes the purgatory load code (kernel/kexec_file.c: kexec_purgatory_setup_sechdrs) to update the entry point twice. Thus the old kernel jumps to some 'random' address causing the crash. To fix this turn off expolines for the purgatory. There is no problem with this in this case due to the fact that the purgatory only runs once and the tlb is purged (diag 308) in the end. Fixes: 840798a1f5299 ("s390/kexec_file: Add purgatory") Cc: # 4.17 Signed-off-by: Philipp Rudo Reviewed-by: Heiko Carstens Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit 87509861a989f86a2256b1245ac88721db5222f4 Author: Sebastian Ott Date: Mon Aug 13 11:26:46 2018 +0200 s390/pci: fix out of bounds access during irq setup commit 866f3576a72b2233a76dffb80290f8086dc49e17 upstream. During interrupt setup we allocate interrupt vectors, walk the list of msi descriptors, and fill in the message data. Requesting more interrupts than supported on s390 can lead to an out of bounds access. When we restrict the number of interrupts we should also stop walking the msi list after all supported interrupts are handled. Cc: stable@vger.kernel.org Signed-off-by: Sebastian Ott Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman commit b51627dc7fdb1c3e743659559c968832626837c2 Author: Martin Schwidefsky Date: Tue Jul 31 16:14:18 2018 +0200 s390/numa: move initial setup of node_to_cpumask_map commit fb7d7518b0d65955f91c7b875c36eae7694c69bd upstream. The numa_init_early initcall sets the node_to_cpumask_map[0] to the full cpu_possible_mask. Unfortunately this early_initcall is too late, the NUMA setup for numa=emu is done even earlier. The order of calls is numa_setup() -> emu_update_cpu_topology(), then the early_initcalls(), followed by sched_init_domains(). Starting with git commit 051f3ca02e46432c0965e8948f00c07d8a2f09c0 "sched/topology: Introduce NUMA identity node sched domain" the incorrect node_to_cpumask_map[0] really screws up the domain setup and the kernel panics with the follow oops: Cc: # v4.15+ Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit d695333c5de693a22b94d071a28c9f3408e17026 Author: Julian Wiedmann Date: Wed May 16 09:37:25 2018 +0200 s390/qdio: reset old sbal_state flags commit 64e03ff72623b8c2ea89ca3cb660094e019ed4ae upstream. When allocating a new AOB fails, handle_outbound() is still capable of transmitting the selected buffer (just without async completion). But if a previous transfer on this queue slot used async completion, its sbal_state flags field is still set to QDIO_OUTBUF_STATE_FLAG_PENDING. So when the upper layer driver sees this stale flag, it expects an async completion that never happens. Fix this by unconditionally clearing the flags field. Fixes: 104ea556ee7f ("qdio: support asynchronous delivery of storage blocks") Cc: #v3.2+ Signed-off-by: Julian Wiedmann Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit dacf5e5947082e8ae4df3b3105eb3d851bcda23a Author: Martin Schwidefsky Date: Mon Aug 6 14:26:39 2018 +0200 s390: fix br_r1_trampoline for machines without exrl commit 26f843848bae973817b3587780ce6b7b0200d3e4 upstream. For machines without the exrl instruction the BFP jit generates code that uses an "br %r1" instruction located in the lowcore page. Unfortunately there is a cut & paste error that puts an additional "larl %r1,.+14" instruction in the code that clobbers the branch target address in %r1. Remove the larl instruction. Cc: # v4.17+ Fixes: de5cb6eb51 ("s390: use expoline thunks in the BPF JIT") Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit 6a32f6f857afff26a736997a0bd702e33aaf6582 Author: Martin Schwidefsky Date: Mon Aug 6 13:49:47 2018 +0200 s390/lib: use expoline for all bcr instructions commit 5eda25b10297684c1f46a14199ec00210f3c346e upstream. The memove, memset, memcpy, __memset16, __memset32 and __memset64 function have an additional indirect return branch in form of a "bzr" instruction. These need to use expolines as well. Cc: # v4.17+ Fixes: 97489e0663 ("s390/lib: use expoline for indirect branches") Reviewed-by: Heiko Carstens Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit 120c776a2ab1bb6639ff9806cee0f9a2395f06cd Author: Gerald Schaefer Date: Tue Aug 7 18:57:11 2018 +0200 s390/mm: fix addressing exception after suspend/resume commit 37a366face294facb9c9d9fdd9f5b64a27456cbd upstream. Commit c9b5ad546e7d "s390/mm: tag normal pages vs pages used in page tables" accidentally changed the logic in arch_set_page_states(), which is used by the suspend/resume code. set_page_stable(page, order) was changed to set_page_stable_dat(page, 0). After this, only the first page of higher order pages will be set to stable, and a write to one of the unstable pages will result in an addressing exception. Fix this by using "order" again, instead of "0". Fixes: c9b5ad546e7d ("s390/mm: tag normal pages vs pages used in page tables") Cc: stable@vger.kernel.org # 4.14+ Reviewed-by: Heiko Carstens Signed-off-by: Gerald Schaefer Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit 77207a7ee4b6af6228f832d8259596e6ecc88fcb Author: Ben Hutchings Date: Wed Aug 29 20:43:17 2018 +0100 x86: Allow generating user-space headers without a compiler commit 829fe4aa9ac16417a904ad1de1307de906854bcf upstream. When bootstrapping an architecture, it's usual to generate the kernel's user-space headers (make headers_install) before building a compiler. Move the compiler check (for asm goto support) to the archprepare target so that it is only done when building code for the target. Fixes: e501ce957a78 ("x86: Force asm-goto") Reported-by: Helmut Grohne Signed-off-by: Ben Hutchings Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20180829194317.GA4765@decadent.org.uk Signed-off-by: Greg Kroah-Hartman commit 3fef5c2f4d9c0862056f1ef5490e1ddea77c737a Author: Jann Horn Date: Tue Aug 28 20:40:33 2018 +0200 x86/entry/64: Wipe KASAN stack shadow before rewind_stack_do_exit() commit f12d11c5c184626b4befdee3d573ec8237405a33 upstream. Reset the KASAN shadow state of the task stack before rewinding RSP. Without this, a kernel oops will leave parts of the stack poisoned, and code running under do_exit() can trip over such poisoned regions and cause nonsensical false-positive KASAN reports about stack-out-of-bounds bugs. This does not wipe the exception stacks; if an oops happens on an exception stack, it might result in random KASAN false-positives from other tasks afterwards. This is probably relatively uninteresting, since if the kernel oopses on an exception stack, there are most likely bigger things to worry about. It'd be more interesting if vmapped stacks and KASAN were compatible, since then handle_stack_overflow() would oops from exception stack context. Fixes: 2deb4be28077 ("x86/dumpstack: When OOPSing, rewind the stack before do_exit()") Signed-off-by: Jann Horn Signed-off-by: Thomas Gleixner Acked-by: Andrey Ryabinin Cc: Andy Lutomirski Cc: Dmitry Vyukov Cc: Alexander Potapenko Cc: Kees Cook Cc: kasan-dev@googlegroups.com Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20180828184033.93712-1-jannh@google.com Signed-off-by: Greg Kroah-Hartman commit b1491daecd6e241e99701ac13930f7ff789f4fc6 Author: Gustavo A. R. Silva Date: Wed Aug 15 08:14:37 2018 -0500 hwmon: (nct6775) Fix potential Spectre v1 commit d49dbfade96d5b0863ca8a90122a805edd5ef50a upstream. val can be indirectly controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability. This issue was detected with the help of Smatch: vers/hwmon/nct6775.c:2698 store_pwm_weight_temp_sel() warn: potential spectre issue 'data->temp_src' [r] Fix this by sanitizing val before using it to index data->temp_src Notice that given that speculation windows are large, the policy is to kill the speculation on the first load and not worry if it can be completed with a dependent load/store [1]. [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2 Cc: stable@vger.kernel.org Signed-off-by: Gustavo A. R. Silva Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 2ff13cec042e5793bbcee126729c49d1a4869583 Author: Andi Kleen Date: Fri Aug 24 10:03:50 2018 -0700 x86/speculation/l1tf: Increase l1tf memory limit for Nehalem+ commit cc51e5428ea54f575d49cfcede1d4cb3a72b4ec4 upstream. On Nehalem and newer core CPUs the CPU cache internally uses 44 bits physical address space. The L1TF workaround is limited by this internal cache address width, and needs to have one bit free there for the mitigation to work. Older client systems report only 36bit physical address space so the range check decides that L1TF is not mitigated for a 36bit phys/32GB system with some memory holes. But since these actually have the larger internal cache width this warning is bogus because it would only really be needed if the system had more than 43bits of memory. Add a new internal x86_cache_bits field. Normally it is the same as the physical bits field reported by CPUID, but for Nehalem and newerforce it to be at least 44bits. Change the L1TF memory size warning to use the new cache_bits field to avoid bogus warnings and remove the bogus comment about memory size. Fixes: 17dbca119312 ("x86/speculation/l1tf: Add sysfs reporting for l1tf") Reported-by: George Anchev Reported-by: Christopher Snowhill Signed-off-by: Andi Kleen Signed-off-by: Thomas Gleixner Cc: x86@kernel.org Cc: linux-kernel@vger.kernel.org Cc: Michael Hocko Cc: vbabka@suse.cz Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20180824170351.34874-1-andi@firstfloor.org Signed-off-by: Greg Kroah-Hartman commit 084c0d5b4cf5b79906de7ff822350804a9b51baf Author: Andi Kleen Date: Fri Aug 24 10:03:51 2018 -0700 x86/spectre: Add missing family 6 check to microcode check commit 1ab534e85c93945f7862378d8c8adcf408205b19 upstream. The check for Spectre microcodes does not check for family 6, only the model numbers. Add a family 6 check to avoid ambiguity with other families. Fixes: a5b296636453 ("x86/cpufeature: Blacklist SPEC_CTRL/PRED_CMD on early Spectre v2 microcodes") Signed-off-by: Andi Kleen Signed-off-by: Thomas Gleixner Cc: x86@kernel.org Cc: linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20180824170351.34874-2-andi@firstfloor.org Signed-off-by: Greg Kroah-Hartman commit c6941f12e9e4f9a46a83d4df410ffcf4ae44a203 Author: Nick Desaulniers Date: Mon Aug 27 14:40:09 2018 -0700 x86/irqflags: Mark native_restore_fl extern inline commit 1f59a4581b5ecfe9b4f049a7a2cf904d8352842d upstream. This should have been marked extern inline in order to pick up the out of line definition in arch/x86/kernel/irqflags.S. Fixes: 208cbb325589 ("x86/irqflags: Provide a declaration for native_save_fl") Reported-by: Ben Hutchings Signed-off-by: Nick Desaulniers Signed-off-by: Thomas Gleixner Reviewed-by: Juergen Gross Cc: "H. Peter Anvin" Cc: Boris Ostrovsky Cc: Greg Kroah-Hartman Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20180827214011.55428-1-ndesaulniers@google.com Signed-off-by: Greg Kroah-Hartman commit 20a103149aa5ea70d7aef53062b108398f6a0a5c Author: Andy Lutomirski Date: Wed Aug 29 08:47:18 2018 -0700 x86/nmi: Fix NMI uaccess race against CR3 switching commit 4012e77a903d114f915fc607d6d2ed54a3d6c9b1 upstream. A NMI can hit in the middle of context switching or in the middle of switch_mm_irqs_off(). In either case, CR3 might not match current->mm, which could cause copy_from_user_nmi() and friends to read the wrong memory. Fix it by adding a new nmi_uaccess_okay() helper and checking it in copy_from_user_nmi() and in __copy_from_user_nmi()'s callers. Signed-off-by: Andy Lutomirski Signed-off-by: Thomas Gleixner Reviewed-by: Rik van Riel Cc: Nadav Amit Cc: Borislav Petkov Cc: Jann Horn Cc: Peter Zijlstra Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/dd956eba16646fd0b15c3c0741269dfd84452dac.1535557289.git.luto@kernel.org Signed-off-by: Greg Kroah-Hartman commit aa3ad43145515c29d2d1176288cbc5e2b5ae00e4 Author: Samuel Neves Date: Sat Sep 1 21:14:52 2018 +0100 x86/vdso: Fix lsl operand order commit e78e5a91456fcecaa2efbb3706572fe043766f4d upstream. In the __getcpu function, lsl is using the wrong target and destination registers. Luckily, the compiler tends to choose %eax for both variables, so it has been working so far. Fixes: a582c540ac1b ("x86/vdso: Use RDPID in preference to LSL when available") Signed-off-by: Samuel Neves Signed-off-by: Thomas Gleixner Acked-by: Andy Lutomirski Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20180901201452.27828-1-sneves@dei.uc.pt Signed-off-by: Greg Kroah-Hartman commit 306f625c2231b85b5c9bfcf9da964a6939ed9c6f Author: Himanshu Madhani Date: Thu Aug 2 13:16:55 2018 -0700 scsi: qla2xxx: Fix stalled relogin commit 15b6c3c9568765f0717b2dd3aa67a5f7eadd9734 upstream. This patch sets and clears FCF_ASYNC_{SENT|ACTIVE} flags to prevent stalling of relogin attempt. Once flag are correctly set/cleared, relogin timer can retry relogin attempt for driver to continue login. Fixes: fa83e65885b9 ("scsi: qla2xxx: ensure async flags are reset correctly") Cc: stable@vger.kernel.org #4.17 Signed-off-by: Himanshu Madhani Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 82964fac7ac276591dbb2e4fd0c0ec8f021b0107 Author: Dan Carpenter Date: Fri Jul 13 17:55:15 2018 +0300 pinctrl: freescale: off by one in imx1_pinconf_group_dbg_show() commit 19da44cd33a3a6ff7c97fff0189999ff15b241e4 upstream. The info->groups[] array is allocated in imx1_pinctrl_parse_dt(). It has info->ngroups elements. Thus the > here should be >= to prevent reading one element beyond the end of the array. Cc: stable@vger.kernel.org Fixes: 30612cd90005 ("pinctrl: imx1 core driver") Signed-off-by: Dan Carpenter Reviewed-by: Uwe Kleine-König Acked-by: Dong Aisheng Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit f8fa13e1f53a77bf61a0117b2ebe209398e3bd23 Author: Johan Hovold Date: Tue Jun 12 14:41:41 2018 +0200 soc: qcom: rmtfs-mem: fix memleak in probe error paths commit 78ee559d7fc65e37670a46cfbeaaa62cb014af67 upstream. Make sure to set the mem device release callback before calling put_device() in a couple of probe error paths so that the containing object also gets freed. Fixes: d1de6d6c639b ("soc: qcom: Remote filesystem memory driver") Cc: stable # 4.15 Cc: Bjorn Andersson Signed-off-by: Johan Hovold Signed-off-by: Andy Gross Signed-off-by: Greg Kroah-Hartman commit e550a74a7d129dd3c68b84cd966c6fe106cb1335 Author: Ajit Pandey Date: Tue Aug 7 18:30:42 2018 +0100 ASoC: wm_adsp: Correct DSP pointer for preloader control commit b1470d4ce77c2d60661c7d5325d4fb8063e15ff8 upstream. The offset of the DSP core needs to be taken into account for the DSP preloader control get and put. Currently the dsp->preloaded variable will only ever be read/updated on the first DSP, whilst this doesn't affect the operation of the control the readback will be incorrect. Signed-off-by: Ajit Pandey Signed-off-by: Charles Keepax Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 00bdd9bfd3ebed3f41b117a48b9b39795b0cbadd Author: Gustavo A. R. Silva Date: Thu Jul 26 15:49:10 2018 -0500 ASoC: sirf: Fix potential NULL pointer dereference commit ae1c696a480c67c45fb23b35162183f72c6be0e1 upstream. There is a potential execution path in which function platform_get_resource() returns NULL. If this happens, we will end up having a NULL pointer dereference. Fix this by replacing devm_ioremap with devm_ioremap_resource, which has the NULL check and the memory region request. This code was detected with the help of Coccinelle. Cc: stable@vger.kernel.org Fixes: 2bd8d1d5cf89 ("ASoC: sirf: Add audio usp interface driver") Signed-off-by: Gustavo A. R. Silva Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit cde7486adce18babaf8a571bc667a17c8f1241b0 Author: Takashi Iwai Date: Wed Jul 25 22:40:49 2018 +0200 ASoC: zte: Fix incorrect PCM format bit usages commit c889a45d229938a94b50aadb819def8bb11a6a54 upstream. zx-tdm driver sets the DAI driver definitions with the format bits wrongly set with SNDRV_PCM_FORMAT_*, instead of SNDRV_PCM_FMTBIT_*. This patch corrects the definitions. Spotted by a sparse warning: sound/soc/zte/zx-tdm.c:363:35: warning: restricted snd_pcm_format_t degrades to integer Fixes: 870e0ddc4345 ("ASoC: zx-tdm: add zte's tdm controller driver") Cc: Signed-off-by: Takashi Iwai Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit aeb4906d32223bf4cfd6a2254a0146476facf38a Author: Jerome Brunet Date: Wed Jun 27 17:36:38 2018 +0200 ASoC: dpcm: don't merge format from invalid codec dai commit 4febced15ac8ddb9cf3e603edb111842e4863d9a upstream. When merging codec formats, dpcm_runtime_base_format() should skip the codecs which are not supporting the current stream direction. At the moment, if a BE link has more than one codec, and only one of these codecs has no capture DAI, it becomes impossible to start a capture stream because the merged format would be 0. Skipping invalid codec DAI solves the problem. Fixes: b073ed4e2126 ("ASoC: soc-pcm: DPCM cares BE format") Signed-off-by: Jerome Brunet Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit a8d156323e5ba15c35466da5cd5ff137a2394451 Author: Michael Buesch Date: Tue Jul 31 21:14:04 2018 +0200 b43/leds: Ensure NUL-termination of LED name string commit 2aa650d1950fce94f696ebd7db30b8830c2c946f upstream. strncpy might not NUL-terminate the string, if the name equals the buffer size. Use strlcpy instead. Signed-off-by: Michael Buesch Cc: stable@vger.kernel.org Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit 579cdda6ba4cdeda3d04035f87004d3ddeb3d058 Author: Michael Buesch Date: Tue Jul 31 21:14:16 2018 +0200 b43legacy/leds: Ensure NUL-termination of LED name string commit 4d77a89e3924b12f4a5628b21237e57ab4703866 upstream. strncpy might not NUL-terminate the string, if the name equals the buffer size. Use strlcpy instead. Signed-off-by: Michael Buesch Cc: stable@vger.kernel.org Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit dccaa28ec448d4925f079e5d3da4cb5baa292a89 Author: Mikulas Patocka Date: Sun Jun 3 16:41:00 2018 +0200 udl-kms: avoid division commit 91ba11fb7d7ca0a3bbe8a512e65e666e2ec1e889 upstream. Division is slow, so it shouldn't be done by the pixel generating code. The driver supports only 2 or 4 bytes per pixel, so we can replace division with a shift. Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 930e10ea2156d518e5e1e7831e2b4cc213ba1b19 Author: Mikulas Patocka Date: Sun Jun 3 16:40:57 2018 +0200 udl-kms: fix crash due to uninitialized memory commit 09a00abe3a9941c2715ca83eb88172cd2f54d8fd upstream. We must use kzalloc when allocating the fb_deferred_io structure. Otherwise, the field first_io is undefined and it causes a crash. Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 723119f9aab51606c380a8b7d21624c164a5acec Author: Mikulas Patocka Date: Sun Jun 3 16:40:56 2018 +0200 udl-kms: handle allocation failure commit 542bb9788a1f485eb1a2229178f665d8ea166156 upstream. Allocations larger than PAGE_ALLOC_COSTLY_ORDER are unreliable and they may fail anytime. This patch fixes the udl kms driver so that when a large alloactions fails, it tries to do multiple smaller allocations. Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 69900129d68f00328694a00cf0bc6f3f0f345439 Author: Mikulas Patocka Date: Sun Jun 3 16:40:55 2018 +0200 udl-kms: change down_interruptible to down commit 8456b99c16d193c4c3b7df305cf431e027f0189c upstream. If we leave urbs around, it causes not only leak, but also memory corruption. This patch fixes the function udl_free_urb_list, so that it always waits for all urbs that are in progress. Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 684ca9975c536dd4fe68ddb8735a72e6b59aa8ba Author: Bart Van Assche Date: Mon Aug 6 15:34:21 2018 -0700 lib/vsprintf: Do not handle %pO[^F] as %px commit 554ec508653688c21d9b8024af73a1ffaa0164b9 upstream. This patch avoids that gcc reports the following when building with W=1: lib/vsprintf.c:1941:3: warning: this statement may fall through [-Wimplicit-fallthrough=] switch (fmt[1]) { ^~~~~~ Fixes: 7b1924a1d930eb2 ("vsprintf: add printk specifier %px") Link: http://lkml.kernel.org/r/20180806223421.11995-1-bart.vanassche@wdc.com Cc: linux-kernel@vger.kernel.org Cc: Bart Van Assche Cc: Pantelis Antoniou Cc: Joe Perches Cc: Rob Herring Cc: v4.15+ Signed-off-by: Bart Van Assche Signed-off-by: Petr Mladek Signed-off-by: Greg Kroah-Hartman commit 15b584de9ab18fca0f7b5bec1b7479242b33a2d4 Author: Kirill Tkhai Date: Thu Jul 19 15:49:39 2018 +0300 fuse: Add missed unlock_page() to fuse_readpages_fill() commit 109728ccc5933151c68d1106e4065478a487a323 upstream. The above error path returns with page unlocked, so this place seems also to behave the same. Fixes: f8dbdf81821b ("fuse: rework fuse_readpages()") Signed-off-by: Kirill Tkhai Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit c00f07a1f66c59ae82af000a843e658bf97b2eff Author: Miklos Szeredi Date: Thu Jul 26 16:13:11 2018 +0200 fuse: Fix oops at process_init_reply() commit e8f3bd773d22f488724dffb886a1618da85c2966 upstream. syzbot is hitting NULL pointer dereference at process_init_reply(). This is because deactivate_locked_super() is called before response for initial request is processed. Fix this by aborting and waiting for all requests (including FUSE_INIT) before resetting fc->sb. Original patch by Tetsuo Handa . Reported-by: syzbot Fixes: e27c9d3877a0 ("fuse: fuse: add time_gran to INIT_OUT") Cc: # v3.19 Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit e4631745286f266dd3e97af937629352e96961f0 Author: Miklos Szeredi Date: Thu Jul 26 16:13:11 2018 +0200 fuse: umount should wait for all requests commit b8f95e5d13f5f0191dcb4b9113113d241636e7cb upstream. fuse_abort_conn() does not guarantee that all async requests have actually finished aborting (i.e. their ->end() function is called). This could actually result in still used inodes after umount. Add a helper to wait until all requests are fully done. This is done by looking at the "num_waiting" counter. When this counter drops to zero, we can be sure that no more requests are outstanding. Fixes: 0d8e84b0432b ("fuse: simplify request abort") Cc: # v4.2 Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 19e0fafd9e687cf908555a6cc7ef1f63f7befad7 Author: Miklos Szeredi Date: Thu Jul 26 16:13:11 2018 +0200 fuse: fix unlocked access to processing queue commit 45ff350bbd9d0f0977ff270a0d427c71520c0c37 upstream. fuse_dev_release() assumes that it's the only one referencing the fpq->processing list, but that's not true, since fuse_abort_conn() can be doing the same without any serialization between the two. Fixes: c3696046beb3 ("fuse: separate pqueue for clones") Cc: # v4.2 Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit bcdb9bd38da665c870c3990d30a496746e671bd0 Author: Miklos Szeredi Date: Thu Jul 26 16:13:11 2018 +0200 fuse: fix double request_end() commit 87114373ea507895a62afb10d2910bd9adac35a8 upstream. Refcounting of request is broken when fuse_abort_conn() is called and request is on the fpq->io list: - ref is taken too late - then it is not dropped Fixes: 0d8e84b0432b ("fuse: simplify request abort") Cc: # v4.2 Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 6ffb58d4f74ed2f7439a67fae303464c93c08295 Author: Miklos Szeredi Date: Thu Jul 26 16:13:11 2018 +0200 fuse: fix initial parallel dirops commit 63576c13bd17848376c8ba4a98f5d5151140c4ac upstream. If parallel dirops are enabled in FUSE_INIT reply, then first operation may leave fi->mutex held. Reported-by: syzbot Fixes: 5c672ab3f0ee ("fuse: serialize dirops by default") Cc: # v4.7 Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 8bebc8585faba7c11fef7faaea9dfebfc1dfc66c Author: Andrey Ryabinin Date: Tue Jul 17 19:00:33 2018 +0300 fuse: Don't access pipe->buffers without pipe_lock() commit a2477b0e67c52f4364a47c3ad70902bc2a61bd4c upstream. fuse_dev_splice_write() reads pipe->buffers to determine the size of 'bufs' array before taking the pipe_lock(). This is not safe as another thread might change the 'pipe->buffers' between the allocation and taking the pipe_lock(). So we end up with too small 'bufs' array. Move the bufs allocations inside pipe_lock()/pipe_unlock() to fix this. Fixes: dd3bb14f44a6 ("fuse: support splice() writing to fuse device") Signed-off-by: Andrey Ryabinin Cc: # v2.6.35 Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 9b4b6acf0280641208f3eb2512a71e4a44836d72 Author: Thomas Gleixner Date: Sun Aug 12 20:41:45 2018 +0200 KVM: x86: SVM: Call x86_spec_ctrl_set_guest/host() with interrupts disabled commit 024d83cadc6b2af027e473720f3c3da97496c318 upstream. Mikhail reported the following lockdep splat: WARNING: possible irq lock inversion dependency detected CPU 0/KVM/10284 just changed the state of lock: 000000000d538a88 (&st->lock){+...}, at: speculative_store_bypass_update+0x10b/0x170 but this lock was taken by another, HARDIRQ-safe lock in the past: (&(&sighand->siglock)->rlock){-.-.} and interrupts could create inverse lock ordering between them. Possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&st->lock); local_irq_disable(); lock(&(&sighand->siglock)->rlock); lock(&st->lock); lock(&(&sighand->siglock)->rlock); *** DEADLOCK *** The code path which connects those locks is: speculative_store_bypass_update() ssb_prctl_set() do_seccomp() do_syscall_64() In svm_vcpu_run() speculative_store_bypass_update() is called with interupts enabled via x86_virt_spec_ctrl_set_guest/host(). This is actually a false positive, because GIF=0 so interrupts are disabled even if IF=1; however, we can easily move the invocations of x86_virt_spec_ctrl_set_guest/host() into the interrupt disabled region to cure it, and it's a good idea to keep the GIF=0/IF=1 area as small and self-contained as possible. Fixes: 1f50ddb4f418 ("x86/speculation: Handle HT correctly on AMD") Reported-by: Mikhail Gavrilov Signed-off-by: Thomas Gleixner Tested-by: Mikhail Gavrilov Cc: Joerg Roedel Cc: Paolo Bonzini Cc: Radim Krčmář Cc: Matthew Wilcox Cc: Borislav Petkov Cc: Konrad Rzeszutek Wilk Cc: Tom Lendacky Cc: kvm@vger.kernel.org Cc: x86@kernel.org Cc: stable@vger.kernel.org Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 150b420a29593aa752d2252d396b6a5909a9318a Author: Paolo Bonzini Date: Thu Jul 26 13:01:52 2018 +0200 KVM: x86: ensure all MSRs can always be KVM_GET/SET_MSR'd commit 44883f01fe6ae436a8604c47d8435276fef369b0 upstream. Some of the MSRs returned by GET_MSR_INDEX_LIST currently cannot be sent back to KVM_GET_MSR and/or KVM_SET_MSR; either they can never be sent back, or you they are only accepted under special conditions. This makes the API a pain to use. To avoid this pain, this patch makes it so that the result of the get-list ioctl can always be used for host-initiated get and set. Since we don't have a separate way to check for read-only MSRs, this means some Hyper-V MSRs are ignored when written. Arguably they should not even be in the result of GET_MSR_INDEX_LIST, but I am leaving there in case userspace is using the outcome of GET_MSR_INDEX_LIST to derive the support for the corresponding Hyper-V feature. Cc: stable@vger.kernel.org Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 1e227ae17f08a37de4165fbb359a5ee2963bfa3c Author: Rian Hunter Date: Sun Aug 19 16:08:53 2018 -0700 x86/process: Re-export start_thread() commit dc76803e57cc86589c4efcb5362918f9b0c0436f upstream. The consolidation of the start_thread() functions removed the export unintentionally. This breaks binfmt handlers built as a module. Add it back. Fixes: e634d8fc792c ("x86-64: merge the standard and compat start_thread() functions") Signed-off-by: Rian Hunter Signed-off-by: Thomas Gleixner Cc: "H. Peter Anvin" Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Vitaly Kuznetsov Cc: Joerg Roedel Cc: Dmitry Safonov Cc: Josh Poimboeuf Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20180819230854.7275-1-rian@alum.mit.edu Signed-off-by: Greg Kroah-Hartman commit e0fb4e0e375efced8565c17a6455089ce21e244b Author: Andy Lutomirski Date: Thu Aug 16 12:41:15 2018 -0700 x86/vdso: Fix vDSO build if a retpoline is emitted commit 2e549b2ee0e358bc758480e716b881f9cabedb6a upstream. Currently, if the vDSO ends up containing an indirect branch or call, GCC will emit the "external thunk" style of retpoline, and it will fail to link. Fix it by building the vDSO with inline retpoline thunks. I haven't seen any reports of this triggering on an unpatched kernel. Fixes: commit 76b043848fd2 ("x86/retpoline: Add initial retpoline support") Signed-off-by: Andy Lutomirski Signed-off-by: Thomas Gleixner Acked-by: Matt Rickard Cc: Borislav Petkov Cc: Jason Vas Dias Cc: David Woodhouse Cc: Peter Zijlstra Cc: Andi Kleen Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/c76538cd3afbe19c6246c2d1715bc6a60bd63985.1534448381.git.luto@kernel.org Signed-off-by: Greg Kroah-Hartman commit 0ea75fa0f6bd8bb79bbccdeb77b313bb9463bde3 Author: Vlastimil Babka Date: Thu Aug 23 16:21:29 2018 +0200 x86/speculation/l1tf: Suggest what to do on systems with too much RAM commit 6a012288d6906fee1dbc244050ade1dafe4a9c8d upstream. Two users have reported [1] that they have an "extremely unlikely" system with more than MAX_PA/2 memory and L1TF mitigation is not effective. Make the warning more helpful by suggesting the proper mem=X kernel boot parameter to make it effective and a link to the L1TF document to help decide if the mitigation is worth the unusable RAM. [1] https://bugzilla.suse.com/show_bug.cgi?id=1105536 Suggested-by: Michal Hocko Signed-off-by: Vlastimil Babka Acked-by: Michal Hocko Cc: "H . Peter Anvin" Cc: Linus Torvalds Cc: Andi Kleen Cc: Dave Hansen Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/966571f0-9d7f-43dc-92c6-a10eec7a1254@suse.cz Signed-off-by: Greg Kroah-Hartman commit ed1fa683e01b6f22ad05c6931ca3d0083413b0a5 Author: Vlastimil Babka Date: Thu Aug 23 15:44:18 2018 +0200 x86/speculation/l1tf: Fix off-by-one error when warning that system has too much RAM commit b0a182f875689647b014bc01d36b340217792852 upstream. Two users have reported [1] that they have an "extremely unlikely" system with more than MAX_PA/2 memory and L1TF mitigation is not effective. In fact it's a CPU with 36bits phys limit (64GB) and 32GB memory, but due to holes in the e820 map, the main region is almost 500MB over the 32GB limit: [ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000081effffff] usable Suggestions to use 'mem=32G' to enable the L1TF mitigation while losing the 500MB revealed, that there's an off-by-one error in the check in l1tf_select_mitigation(). l1tf_pfn_limit() returns the last usable pfn (inclusive) and the range check in the mitigation path does not take this into account. Instead of amending the range check, make l1tf_pfn_limit() return the first PFN which is over the limit which is less error prone. Adjust the other users accordingly. [1] https://bugzilla.suse.com/show_bug.cgi?id=1105536 Fixes: 17dbca119312 ("x86/speculation/l1tf: Add sysfs reporting for l1tf") Reported-by: George Anchev Reported-by: Christopher Snowhill Signed-off-by: Vlastimil Babka Signed-off-by: Thomas Gleixner Cc: "H . Peter Anvin" Cc: Linus Torvalds Cc: Andi Kleen Cc: Dave Hansen Cc: Michal Hocko Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20180823134418.17008-1-vbabka@suse.cz Signed-off-by: Greg Kroah-Hartman commit 63da8b8a387b8975ba1a66aab0b9ecba06c3d0b2 Author: Vlastimil Babka Date: Mon Aug 20 11:58:35 2018 +0200 x86/speculation/l1tf: Fix overflow in l1tf_pfn_limit() on 32bit commit 9df9516940a61d29aedf4d91b483ca6597e7d480 upstream. On 32bit PAE kernels on 64bit hardware with enough physical bits, l1tf_pfn_limit() will overflow unsigned long. This in turn affects max_swapfile_size() and can lead to swapon returning -EINVAL. This has been observed in a 32bit guest with 42 bits physical address size, where max_swapfile_size() overflows exactly to 1 << 32, thus zero, and produces the following warning to dmesg: [ 6.396845] Truncating oversized swap area, only using 0k out of 2047996k Fix this by using unsigned long long instead. Fixes: 17dbca119312 ("x86/speculation/l1tf: Add sysfs reporting for l1tf") Fixes: 377eeaa8e11f ("x86/speculation/l1tf: Limit swap file size to MAX_PA/2") Reported-by: Dominique Leuenberger Reported-by: Adrian Schroeter Signed-off-by: Vlastimil Babka Signed-off-by: Thomas Gleixner Acked-by: Andi Kleen Acked-by: Michal Hocko Cc: "H . Peter Anvin" Cc: Linus Torvalds Cc: Dave Hansen Cc: Michal Hocko Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20180820095835.5298-1-vbabka@suse.cz Signed-off-by: Greg Kroah-Hartman commit e43594dabdc84a5cd1aec575feb06ffb2f0247ab Author: Peter Zijlstra Date: Wed Aug 22 17:30:15 2018 +0200 mm/tlb, x86/mm: Support invalidating TLB caches for RCU_TABLE_FREE commit d86564a2f085b79ec046a5cba90188e612352806 upstream. Jann reported that x86 was missing required TLB invalidates when he hit the !*batch slow path in tlb_remove_table(). This is indeed the case; RCU_TABLE_FREE does not provide TLB (cache) invalidates, the PowerPC-hash where this code originated and the Sparc-hash where this was subsequently used did not need that. ARM which later used this put an explicit TLB invalidate in their __p*_free_tlb() functions, and PowerPC-radix followed that example. But when we hooked up x86 we failed to consider this. Fix this by (optionally) hooking tlb_remove_table() into the TLB invalidate code. NOTE: s390 was also needing something like this and might now be able to use the generic code again. [ Modified to be on top of Nick's cleanups, which simplified this patch now that tlb_flush_mmu_tlbonly() really only flushes the TLB - Linus ] Fixes: 9e52fc2b50de ("x86/mm: Enable RCU based page table freeing (CONFIG_HAVE_RCU_TABLE_FREE=y)") Reported-by: Jann Horn Signed-off-by: Peter Zijlstra (Intel) Acked-by: Rik van Riel Cc: Nicholas Piggin Cc: David Miller Cc: Will Deacon Cc: Martin Schwidefsky Cc: Michael Ellerman Cc: stable@kernel.org Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 575a66cbe443bc4ab7c4e26b713963bf1b6cb4cd Author: Nicholas Piggin Date: Thu Aug 23 18:47:08 2018 +1000 mm: move tlb_table_flush to tlb_flush_mmu_free commit db7ddef301128dad394f1c0f77027f86ee9a4edb upstream. There is no need to call this from tlb_flush_mmu_tlbonly, it logically belongs with tlb_flush_mmu_free. This makes future fixes simpler. [ This was originally done to allow code consolidation for the mmu_notifier fix, but it also ends up helping simplify the HAVE_RCU_TABLE_INVALIDATE fix. - Linus ] Signed-off-by: Nicholas Piggin Acked-by: Will Deacon Cc: Peter Zijlstra Cc: stable@kernel.org Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 8c718160802642899c71f61b743124c683d3d906 Author: Takashi Iwai Date: Fri Jun 22 10:59:17 2018 +0200 platform/x86: ideapad-laptop: Apply no_hw_rfkill to Y20-15IKBM, too commit 58e73aa177850babb947555257fd4f79e5275cf1 upstream. The commit 5d9f40b56630 ("platform/x86: ideapad-laptop: Add Y520-15IKBN to no_hw_rfkill") added the entry for Y20-15IKBN, and it turned out that another variant, Y20-15IKBM, also requires the no_hw_rfkill. Trim the last letter from the string so that it matches to both Y20-15IKBN and Y20-15IKBM models. Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=1098626 Cc: Signed-off-by: Takashi Iwai Signed-off-by: Darren Hart (VMware) Signed-off-by: Greg Kroah-Hartman commit 6ef37c5f0142cc2be7523ecd949869c081c1e6a0 Author: Kees Cook Date: Wed Jun 20 14:31:41 2018 -0700 platform/x86: wmi: Do not mix pages and kmalloc commit 6fb741076a9fc53355e56dff2e2b46782b3a46d3 upstream. The probe handler_data was being allocated with __get_free_pages() for no reason I could find. The error path was using kfree(). Since other things are happily using kmalloc() in the probe path, switch to kmalloc() entirely. This fixes the error path mismatch and will avoid issues with CONFIG_HARDENED_USERCOPY_PAGESPAN=y. Reported-by: Mihai Donțu Signed-off-by: Kees Cook Acked-by: Mario Limonciello Cc: stable@vger.kernel.org Signed-off-by: Darren Hart (VMware) Signed-off-by: Greg Kroah-Hartman commit 6bdd19331fc6b9405f78e74bc9fca0beca2a194a Author: Paulo Zanoni Date: Fri May 4 13:32:51 2018 -0700 x86/gpu: reserve ICL's graphics stolen memory commit db0c8d8b031d2b5960f6407f7f2ca20e97e00605 upstream. ICL changes the registers and addresses to 64 bits. I also briefly looked at implementing an u64 version of the PCI config read functions, but I concluded this wouldn't be trivial, so it's not worth doing it for a single user that can't have any racing problems while reading the register in two separate operations. v2: - Scrub the development (non-public) changelog (Joonas). - Remove the i915.ko bits so this can be easily backported in order to properly avoid stolen memory even on machines without i915.ko (Joonas). - CC stable for the reasons above. Issue: VIZ-9250 CC: stable@vger.kernel.org Cc: Ingo Molnar Cc: H. Peter Anvin Cc: x86@kernel.org Cc: Daniele Ceraolo Spurio Cc: Joonas Lahtinen Signed-off-by: Paulo Zanoni Fixes: 412310019a20 ("drm/i915/icl: Add initial Icelake definitions.") Reviewed-by: Joonas Lahtinen Acked-by: Ingo Molnar Signed-off-by: Rodrigo Vivi Link: https://patchwork.freedesktop.org/patch/msgid/20180504203252.28048-1-paulo.r.zanoni@intel.com Signed-off-by: Greg Kroah-Hartman commit 4debdc1d06a73d99f57a071875e229a35bc1da39 Author: Michal Wnukowski Date: Wed Aug 15 15:51:57 2018 -0700 nvme-pci: add a memory barrier to nvme_dbbuf_update_and_check_event commit f1ed3df20d2d223e0852cc4ac1f19bba869a7e3c upstream. In many architectures loads may be reordered with older stores to different locations. In the nvme driver the following two operations could be reordered: - Write shadow doorbell (dbbuf_db) into memory. - Read EventIdx (dbbuf_ei) from memory. This can result in a potential race condition between driver and VM host processing requests (if given virtual NVMe controller has a support for shadow doorbell). If that occurs, then the NVMe controller may decide to wait for MMIO doorbell from guest operating system, and guest driver may decide not to issue MMIO doorbell on any of subsequent commands. This issue is purely timing-dependent one, so there is no easy way to reproduce it. Currently the easiest known approach is to run "Oracle IO Numbers" (orion) that is shipped with Oracle DB: orion -run advanced -num_large 0 -size_small 8 -type rand -simulate \ concat -write 40 -duration 120 -matrix row -testname nvme_test Where nvme_test is a .lun file that contains a list of NVMe block devices to run test against. Limiting number of vCPUs assigned to given VM instance seems to increase chances for this bug to occur. On test environment with VM that got 4 NVMe drives and 1 vCPU assigned the virtual NVMe controller hang could be observed within 10-20 minutes. That correspond to about 400-500k IO operations processed (or about 100GB of IO read/writes). Orion tool was used as a validation and set to run in a loop for 36 hours (equivalent of pushing 550M IO operations). No issues were observed. That suggest that the patch fixes the issue. Fixes: f9f38e33389c ("nvme: improve performance for virtual NVMe devices") Signed-off-by: Michal Wnukowski Reviewed-by: Keith Busch Reviewed-by: Sagi Grimberg [hch: updated changelog and comment a bit] Signed-off-by: Christoph Hellwig Signed-off-by: Greg Kroah-Hartman commit 7036ab0189478d62957535074650ca58fbaf4d09 Author: Wang Shilong Date: Sun Jul 29 17:27:45 2018 -0400 ext4: fix race when setting the bitmap corrupted flag commit 9af0b3d1257756394ebbd06b14937b557e3a756b upstream. Whenever we hit block or inode bitmap corruptions we set bit and then reduce this block group free inode/clusters counter to expose right available space. However some of ext4_mark_group_bitmap_corrupted() is called inside group spinlock, some are not, this could make it happen that we double reduce one block group free counters from system. Always hold group spinlock for it could fix it, but it looks a little heavy, we could use test_and_set_bit() to fix race problems here. Signed-off-by: Wang Shilong Signed-off-by: Theodore Ts'o Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit eafb2d82ca7e4d19f78940c1d44ed452c86eb92a Author: Eric Sandeen Date: Sun Jul 29 17:13:42 2018 -0400 ext4: reset error code in ext4_find_entry in fallback commit f39b3f45dbcb0343822cce31ea7636ad66e60bc2 upstream. When ext4_find_entry() falls back to "searching the old fashioned way" due to a corrupt dx dir, it needs to reset the error code to NULL so that the nonstandard ERR_BAD_DX_DIR code isn't returned to userspace. https://bugzilla.kernel.org/show_bug.cgi?id=199947 Reported-by: Anatoly Trosinenko Reviewed-by: Andreas Dilger Signed-off-by: Eric Sandeen Signed-off-by: Theodore Ts'o Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 3f2541a7e58c7381cfefa0866079b5f624ce0d98 Author: Arnd Bergmann Date: Sun Jul 29 15:48:00 2018 -0400 ext4: sysfs: print ext4_super_block fields as little-endian commit a4d2aadca184ece182418950d45ba4ffc7b652d2 upstream. While working on extended rand for last_error/first_error timestamps, I noticed that the endianess is wrong; we access the little-endian fields in struct ext4_super_block as native-endian when we print them. This adds a special case in ext4_attr_show() and ext4_attr_store() to byteswap the superblock fields if needed. In older kernels, this code was part of super.c, it got moved to sysfs.c in linux-4.4. Cc: stable@vger.kernel.org Fixes: 52c198c6820f ("ext4: add sysfs entry showing whether the fs contains errors") Reviewed-by: Andreas Dilger Signed-off-by: Arnd Bergmann Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 6891c3c114fcbec5cf7d082f4684ec31d64813e2 Author: Wang Shilong Date: Wed Aug 1 12:02:31 2018 -0400 ext4: use ext4_warning() for sb_getblk failure commit 5ef2a69993676a0dfd49bf60ae1323eb8a288366 upstream. Out of memory should not be considered as critical errors; so replace ext4_error() with ext4_warnig(). Signed-off-by: Wang Shilong Signed-off-by: Theodore Ts'o Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit f34a0bc19575b0934ad0534fb908dcab25681749 Author: Theodore Ts'o Date: Wed Aug 1 12:36:52 2018 -0400 ext4: check for NUL characters in extended attribute's name commit 7d95178c77014dbd8dce36ee40bbbc5e6c121ff5 upstream. Extended attribute names are defined to be NUL-terminated, so the name must not contain a NUL character. This is important because there are places when remove extended attribute, the code uses strlen to determine the length of the entry. That should probably be fixed at some point, but code is currently really messy, so the simplest fix for now is to simply validate that the extended attributes are sane. https://bugzilla.kernel.org/show_bug.cgi?id=200401 Reported-by: Wen Xu Signed-off-by: Theodore Ts'o Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 55472d881c48502fdc9c4ea41ee1d9f00dcf827f Author: Prasad Sodagudi Date: Fri Aug 3 13:56:06 2018 -0700 stop_machine: Atomically queue and wake stopper threads commit cfd355145c32bb7ccb65fccbe2d67280dc2119e1 upstream. When cpu_stop_queue_work() releases the lock for the stopper thread that was queued into its wake queue, preemption is enabled, which leads to the following deadlock: CPU0 CPU1 sched_setaffinity(0, ...) __set_cpus_allowed_ptr() stop_one_cpu(0, ...) stop_two_cpus(0, 1, ...) cpu_stop_queue_work(0, ...) cpu_stop_queue_two_works(0, ..., 1, ...) -grabs lock for migration/0- -spins with preemption disabled, waiting for migration/0's lock to be released- -adds work items for migration/0 and queues migration/0 to its wake_q- -releases lock for migration/0 and preemption is enabled- -current thread is preempted, and __set_cpus_allowed_ptr has changed the thread's cpu allowed mask to CPU1 only- -acquires migration/0 and migration/1's locks- -adds work for migration/0 but does not add migration/0 to wake_q, since it is already in a wake_q- -adds work for migration/1 and adds migration/1 to its wake_q- -releases migration/0 and migration/1's locks, wakes migration/1, and enables preemption- -since migration/1 is requested to run, migration/1 begins to run and waits on migration/0, but migration/0 will never be able to run, since the thread that can wake it is affine to CPU1- Disable preemption in cpu_stop_queue_work() before queueing works for stopper threads, and queueing the stopper thread in the wake queue, to ensure that the operation of queueing the works and waking the stopper threads is atomic. Fixes: 0b26351b910f ("stop_machine, sched: Fix migrate_swap() vs. active_balance() deadlock") Signed-off-by: Prasad Sodagudi Signed-off-by: Isaac J. Manjarres Signed-off-by: Thomas Gleixner Cc: peterz@infradead.org Cc: matt@codeblueprint.co.uk Cc: bigeasy@linutronix.de Cc: gregkh@linuxfoundation.org Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/1533329766-4856-1-git-send-email-isaacm@codeaurora.org Signed-off-by: Greg Kroah-Hartman Co-Developed-by: Isaac J. Manjarres commit 3fc7316acc6750f5a5e3fbcec887e6e3be0fcbda Author: Peter Zijlstra Date: Mon Jul 30 13:21:40 2018 +0200 stop_machine: Reflow cpu_stop_queue_two_works() commit b80a2bfce85e1051056d98d04ecb2d0b55cbbc1c upstream. The code flow in cpu_stop_queue_two_works() is a little arcane; fix this by lifting the preempt_disable() to the top to create more natural nesting wrt the spinlocks and make the wake_up_q() and preempt_enable() unconditional at the end. Furthermore, enable preemption in the -EDEADLK case, such that we spin-wait with preemption enabled. Suggested-by: Thomas Gleixner Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Thomas Gleixner Cc: Sebastian Andrzej Siewior Cc: isaacm@codeaurora.org Cc: matt@codeblueprint.co.uk Cc: psodagud@codeaurora.org Cc: gregkh@linuxfoundation.org Cc: pkondeti@codeaurora.org Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20180730112140.GH2494@hirez.programming.kicks-ass.net Signed-off-by: Greg Kroah-Hartman commit 19a5808f8b734505e85c38b633e19a59c7e34042 Author: Thomas Richter Date: Thu Jul 12 09:09:36 2018 +0200 perf kvm: Fix subcommands on s390 commit 8a95c8994509c55abf1e38c0cc037b1205725e21 upstream. With commit eca0fa28cd0d ("perf record: Provide detailed information on s390 CPU") s390 platform provides detailed type/model/capacity information in the CPU identifier string instead of just "IBM/S390". This breaks 'perf kvm' support which uses hard coded string IBM/S390 to compare with the CPU identifier string. Fix this by changing the comparison. Reported-by: Stefan Raspl Signed-off-by: Thomas Richter Reviewed-by: Hendrik Brueckner Tested-by: Stefan Raspl Acked-by: Christian Borntraeger Cc: Heiko Carstens Cc: Martin Schwidefsky Cc: stable@vger.kernel.org Fixes: eca0fa28cd0d ("perf record: Provide detailed information on s390 CPU") Link: http://lkml.kernel.org/r/20180712070936.67547-1-tmricht@linux.ibm.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 32a52f0bded3fa6866c93ad5b776d9994398b2fb Author: Claudio Imbrenda Date: Mon Jul 16 10:38:57 2018 +0200 s390/kvm: fix deadlock when killed by oom commit 306d6c49ac9ded11114cb53b0925da52f2c2ada1 upstream. When the oom killer kills a userspace process in the page fault handler while in guest context, the fault handler fails to release the mm_sem if the FAULT_FLAG_RETRY_NOWAIT option is set. This leads to a deadlock when tearing down the mm when the process terminates. This bug can only happen when pfault is enabled, so only KVM clients are affected. The problem arises in the rare cases in which handle_mm_fault does not release the mm_sem. This patch fixes the issue by manually releasing the mm_sem when needed. Fixes: 24eb3a824c4f3 ("KVM: s390: Add FAULT_FLAG_RETRY_NOWAIT for guest fault") Cc: # 3.15+ Signed-off-by: Claudio Imbrenda Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit 1d0bd8c92361c2a97fcdd38fa2302ef8e3e746f2 Author: Punit Agrawal Date: Mon Aug 13 11:43:51 2018 +0100 KVM: arm/arm64: Skip updating PTE entry if no change commit 976d34e2dab10ece5ea8fe7090b7692913f89084 upstream. When there is contention on faulting in a particular page table entry at stage 2, the break-before-make requirement of the architecture can lead to additional refaulting due to TLB invalidation. Avoid this by skipping a page table update if the new value of the PTE matches the previous value. Cc: stable@vger.kernel.org Fixes: d5d8184d35c9 ("KVM: ARM: Memory virtualization setup") Reviewed-by: Suzuki Poulose Acked-by: Christoffer Dall Signed-off-by: Punit Agrawal Signed-off-by: Marc Zyngier Signed-off-by: Greg Kroah-Hartman commit c7bcb09e4e353f11162fd16b93f181305edcc21d Author: Punit Agrawal Date: Mon Aug 13 11:43:50 2018 +0100 KVM: arm/arm64: Skip updating PMD entry if no change commit 86658b819cd0a9aa584cd84453ed268a6f013770 upstream. Contention on updating a PMD entry by a large number of vcpus can lead to duplicate work when handling stage 2 page faults. As the page table update follows the break-before-make requirement of the architecture, it can lead to repeated refaults due to clearing the entry and flushing the tlbs. This problem is more likely when - * there are large number of vcpus * the mapping is large block mapping such as when using PMD hugepages (512MB) with 64k pages. Fix this by skipping the page table update if there is no change in the entry being updated. Cc: stable@vger.kernel.org Fixes: ad361f093c1e ("KVM: ARM: Support hugetlbfs backed huge pages") Reviewed-by: Suzuki Poulose Acked-by: Christoffer Dall Signed-off-by: Punit Agrawal Signed-off-by: Marc Zyngier Signed-off-by: Greg Kroah-Hartman commit 166b04aee70ee7cfa0dc4d1b06cd1aeedd439f5b Author: Christoffer Dall Date: Wed Jul 25 10:21:28 2018 +0100 KVM: arm/arm64: Fix lost IRQs from emulated physcial timer when blocked commit 245715cbe83ca934af5d20e078fd85175c62995e upstream. When the VCPU is blocked (for example from WFI) we don't inject the physical timer interrupt if it should fire while the CPU is blocked, but instead we just wake up the VCPU and expect kvm_timer_vcpu_load to take care of injecting the interrupt. Unfortunately, kvm_timer_vcpu_load() doesn't actually do that, it only has support to schedule a soft timer if the emulated phys timer is expected to fire in the future. Follow the same pattern as kvm_timer_update_state() and update the irq state after potentially scheduling a soft timer. Reported-by: Andre Przywara Cc: Stable # 4.15+ Fixes: bbdd52cfcba29 ("KVM: arm/arm64: Avoid phys timer emulation in vcpu entry/exit") Signed-off-by: Christoffer Dall Signed-off-by: Marc Zyngier Signed-off-by: Greg Kroah-Hartman commit 52df41f653bb6b18da67c0f8c22ef6f8c4efb088 Author: Christoffer Dall Date: Wed Jul 25 10:21:27 2018 +0100 KVM: arm/arm64: Fix potential loss of ptimer interrupts commit 7afc4ddbf299a13aaf28406783d141a34c6b4f5a upstream. kvm_timer_update_state() is called when changing the phys timer configuration registers, either via vcpu reset, as a result of a trap from the guest, or when userspace programs the registers. phys_timer_emulate() is in turn called by kvm_timer_update_state() to either cancel an existing software timer, or program a new software timer, to emulate the behavior of a real phys timer, based on the change in configuration registers. Unfortunately, the interaction between these two functions left a small race; if the conceptual emulated phys timer should actually fire, but the soft timer hasn't executed its callback yet, we cancel the timer in phys_timer_emulate without injecting an irq. This only happens if the check in kvm_timer_update_state is called before the timer should fire, which is relatively unlikely, but possible. The solution is to update the state of the phys timer after calling phys_timer_emulate, which will pick up the pending timer state and update the interrupt value. Note that this leaves the opportunity of raising the interrupt twice, once in the just-programmed soft timer, and once in kvm_timer_update_state. Since this always happens synchronously with the VCPU execution, there is no harm in this, and the guest ever only sees a single timer interrupt. Cc: Stable # 4.15+ Signed-off-by: Christoffer Dall Signed-off-by: Marc Zyngier Signed-off-by: Greg Kroah-Hartman commit 5c2fd3598fb84fc3e467f18e635e0fa72ef6eeab Author: Huibin Hong Date: Fri Jul 6 16:03:57 2018 +0800 arm64: dts: rockchip: corrected uart1 clock-names for rk3328 commit d0414fdd58eb51ffd6528280fd66705123663964 upstream. Corrected the uart clock-names or the uart driver might fail. Fixes: 52e02d377a72 ("arm64: dts: rockchip: add core dtsi file for RK3328 SoCs") Cc: stable@vger.kernel.org Signed-off-by: Huibin Hong Signed-off-by: Heiko Stuebner Signed-off-by: Greg Kroah-Hartman commit 88e798da7c292ea811694e0271f6e4cf728a72e5 Author: Greg Hackmann Date: Wed Aug 15 12:51:21 2018 -0700 arm64: mm: check for upper PAGE_SHIFT bits in pfn_valid() commit 5ad356eabc47d26a92140a0c4b20eba471c10de3 upstream. ARM64's pfn_valid() shifts away the upper PAGE_SHIFT bits of the input before seeing if the PFN is valid. This leads to false positives when some of the upper bits are set, but the lower bits match a valid PFN. For example, the following userspace code looks up a bogus entry in /proc/kpageflags: int pagemap = open("/proc/self/pagemap", O_RDONLY); int pageflags = open("/proc/kpageflags", O_RDONLY); uint64_t pfn, val; lseek64(pagemap, [...], SEEK_SET); read(pagemap, &pfn, sizeof(pfn)); if (pfn & (1UL << 63)) { /* valid PFN */ pfn &= ((1UL << 55) - 1); /* clear flag bits */ pfn |= (1UL << 55); lseek64(pageflags, pfn * sizeof(uint64_t), SEEK_SET); read(pageflags, &val, sizeof(val)); } On ARM64 this causes the userspace process to crash with SIGSEGV rather than reading (1 << KPF_NOPAGE). kpageflags_read() treats the offset as valid, and stable_page_flags() will try to access an address between the user and kernel address ranges. Fixes: c1cc1552616d ("arm64: MMU initialisation") Cc: stable@vger.kernel.org Signed-off-by: Greg Hackmann Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit ca41d82d4e66b357698c26d8159694e6c2a55a9c Author: Suzuki K Poulose Date: Wed Jul 4 23:07:46 2018 +0100 arm64: Handle mismatched cache type commit 314d53d297980676011e6fd83dac60db4a01dc70 upstream. Track mismatches in the cache type register (CTR_EL0), other than the D/I min line sizes and trap user accesses if there are any. Fixes: be68a8aaf925 ("arm64: cpufeature: Fix CTR_EL0 field definitions") Cc: Cc: Mark Rutland Cc: Will Deacon Cc: Catalin Marinas Signed-off-by: Suzuki K Poulose Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit faed5cb96b91ed5822e13e9bab5682b626aaa4ce Author: Suzuki K Poulose Date: Wed Jul 4 23:07:45 2018 +0100 arm64: Fix mismatched cache line size detection commit 4c4a39dd5fe2d13e2d2fa5fceb8ef95d19fc389a upstream. If there is a mismatch in the I/D min line size, we must always use the system wide safe value both in applications and in the kernel, while performing cache operations. However, we have been checking more bits than just the min line sizes, which triggers false negatives. We may need to trap the user accesses in such cases, but not necessarily patch the kernel. This patch fixes the check to do the right thing as advertised. A new capability will be added to check mismatches in other fields and ensure we trap the CTR accesses. Fixes: be68a8aaf925 ("arm64: cpufeature: Fix CTR_EL0 field definitions") Cc: Cc: Mark Rutland Cc: Catalin Marinas Reported-by: Will Deacon Signed-off-by: Suzuki K Poulose Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit bc10c237ecd8faa2e45a53b76b4091176127d6b7 Author: Masami Hiramatsu Date: Sat Apr 28 21:38:04 2018 +0900 kprobes/arm64: Fix %p uses in error messages commit 0722867dcbc28cc9b269b57acd847c7c1aa638d6 upstream. Fix %p uses in error messages by removing it because those are redundant or meaningless. Signed-off-by: Masami Hiramatsu Acked-by: Will Deacon Cc: Ananth N Mavinakayanahalli Cc: Anil S Keshavamurthy Cc: Arnd Bergmann Cc: David Howells Cc: David S . Miller Cc: Heiko Carstens Cc: Jon Medhurst Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Thomas Richter Cc: Tobin C . Harding Cc: acme@kernel.org Cc: akpm@linux-foundation.org Cc: brueckner@linux.vnet.ibm.com Cc: linux-arch@vger.kernel.org Cc: rostedt@goodmis.org Cc: schwidefsky@de.ibm.com Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/lkml/152491908405.9916.12425053035317241111.stgit@devbox Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit a4ed70a386c07d27e02dc5bcfebca12158389189 Author: Petr Mladek Date: Wed Jun 27 16:20:28 2018 +0200 printk/nmi: Prevent deadlock when accessing the main log buffer in NMI commit 03fc7f9c99c1e7ae2925d459e8487f1a6f199f79 upstream. The commit 719f6a7040f1bdaf96 ("printk: Use the main logbuf in NMI when logbuf_lock is available") brought back the possible deadlocks in printk() and NMI. The check of logbuf_lock is done only in printk_nmi_enter() to prevent mixed output. But another CPU might take the lock later, enter NMI, and: + Both NMIs might be serialized by yet another lock, for example, the one in nmi_cpu_backtrace(). + The other CPU might get stopped in NMI, see smp_send_stop() in panic(). The only safe solution is to use trylock when storing the message into the main log-buffer. It might cause reordering when some lines go to the main lock buffer directly and others are delayed via the per-CPU buffer. It means that it is not useful in general. This patch replaces the problematic NMI deferred context with NMI direct context. It can be used to mark a code that might produce many messages in NMI and the risk of losing them is more critical than problems with eventual reordering. The context is then used when dumping trace buffers on oops. It was the primary motivation for the original fix. Also the reordering is even smaller issue there because some traces have their own time stamps. Finally, nmi_cpu_backtrace() need not longer be serialized because it will always us the per-CPU buffers again. Fixes: 719f6a7040f1bdaf96 ("printk: Use the main logbuf in NMI when logbuf_lock is available") Cc: stable@vger.kernel.org Link: http://lkml.kernel.org/r/20180627142028.11259-1-pmladek@suse.com To: Steven Rostedt Cc: Peter Zijlstra Cc: Tetsuo Handa Cc: Sergey Senozhatsky Cc: linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org Acked-by: Sergey Senozhatsky Signed-off-by: Petr Mladek Signed-off-by: Greg Kroah-Hartman commit 50631d1b2613ffa22f3bcd7a0c8c171580a32c88 Author: Petr Mladek Date: Wed Jun 27 16:08:16 2018 +0200 printk: Create helper function to queue deferred console handling commit a338f84dc196f44b63ba0863d2f34fd9b1613572 upstream. It is just a preparation step. The patch does not change the existing behavior. Link: http://lkml.kernel.org/r/20180627140817.27764-3-pmladek@suse.com To: Steven Rostedt Cc: Peter Zijlstra Cc: Tetsuo Handa Cc: Sergey Senozhatsky Cc: linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org Acked-by: Sergey Senozhatsky Signed-off-by: Petr Mladek Signed-off-by: Greg Kroah-Hartman commit b0eea4d14b94691ca32c59f049d0ba93df18894d Author: Petr Mladek Date: Wed Jun 27 16:08:15 2018 +0200 printk: Split the code for storing a message into the log buffer commit ba552399954dde1b388f7749fecad5c349216981 upstream. It is just a preparation step. The patch does not change the existing behavior. Link: http://lkml.kernel.org/r/20180627140817.27764-2-pmladek@suse.com To: Steven Rostedt Cc: Peter Zijlstra Cc: Tetsuo Handa Cc: Sergey Senozhatsky Cc: linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org Acked-by: Sergey Senozhatsky Signed-off-by: Petr Mladek Signed-off-by: Greg Kroah-Hartman commit 2297091c7a6c2a03d88d1ac3ff6067e1b8ef3118 Author: Vivek Gautam Date: Thu Jul 19 23:23:56 2018 +0530 iommu/arm-smmu: Error out only if not enough context interrupts commit d1e20222d5372e951bbb2fd3f6489ec4a6ea9b11 upstream. Currently we check if the number of context banks is not equal to num_context_interrupts. However, there are booloaders such as, one on sdm845 that reserves few context banks and thus kernel views less than the total available context banks. So, although the hardware definition in device tree would mention the correct number of context interrupts, this number can be greater than the number of context banks visible to smmu in kernel. We should therefore error out only when the number of context banks is greater than the available number of context interrupts. Signed-off-by: Vivek Gautam Suggested-by: Tomasz Figa Cc: Robin Murphy Cc: Will Deacon [will: drop useless printk] Signed-off-by: Will Deacon Cc: Jitendra Bhivare Signed-off-by: Greg Kroah-Hartman commit b5563064b99ec1e446d4b8264ff0035db7f56bf2 Author: Charles Keepax Date: Tue Jun 19 16:10:00 2018 +0100 regulator: arizona-ldo1: Use correct device to get enable GPIO commit a9191579ba1086d91842199263e6fe6bb5eec1ba upstream. Currently the enable GPIO is being looked up on the regulator device itself but that does not have its own DT node, this causes the lookup to fail and the regulator not to get its GPIO. The DT node is shared across the whole MFD and as such the lookup needs to happen on that parent device. Moving the lookup to the parent device also means devres can no longer be used as the life time would attach to the wrong device. Additionally, the enable GPIO is active high so we should be passing GPIOD_OUT_LOW to ensure the regulator starts in its off state allowing the driver to enable it when it is ready. Fixes: e1739e86f0cb ("regulator: arizona-ldo1: Look up a descriptor and pass to the core") Reported-by: Matthias Reichl Signed-off-by: Charles Keepax Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman From: Matthias Reichl commit 29ac604e627b6668718b9ebc65c690b78159788b Author: Daniel Borkmann Date: Sat Aug 18 00:21:34 2018 +0200 bpf, arm32: fix stack var offset in jit Commit 38ca93060163 ("bpf, arm32: save 4 bytes of unneeded stack space") messed up STACK_VAR() by 4 bytes presuming it was related to skb scratch buffer space, but it clearly isn't as this refers to the top word in stack, therefore restore it. This fixes a NULL pointer dereference seen during bootup when JIT is enabled and BPF program run in sk_filter_trim_cap() triggered by systemd-udevd. JIT rework in 1c35ba122d4a ("ARM: net: bpf: use negative numbers for stacked registers") and 96cced4e774a ("ARM: net: bpf: access eBPF scratch space using ARM FP register") removed the affected parts, so only needed in 4.18 stable. Fixes: 38ca93060163 ("bpf, arm32: save 4 bytes of unneeded stack space") Reported-by: Peter Robinson Reported-by: Marc Haber Tested-by: Stefan Wahren Tested-by: Peter Robinson Cc: Russell King Cc: Alexei Starovoitov Signed-off-by: Daniel Borkmann Acked-by: Alexei Starovoitov commit 6289b80699af425ee8a4c84dfb58d5e4d7ca71d5 Author: Michael Larabel Date: Tue Aug 7 09:54:54 2018 -0400 hwmon: (k10temp) 27C Offset needed for Threadripper2 commit 484a84f25ca7817c3662001316ba7d1e06b74ae2 upstream. For at least the Threadripper 2950X and Threadripper 2990WX, it's confirmed a 27 degree offset is needed. Signed-off-by: Michael Larabel Cc: stable@vger.kernel.org Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit df5c4d19606d7b91e8b5a97f5cef229071a064d7 Author: Filipe Manana Date: Mon Jul 30 12:39:58 2018 +0100 Btrfs: send, fix incorrect file layout after hole punching beyond eof commit 22d3151c2c4cb517a309154d1e828a28106508c7 upstream. When doing an incremental send, if we have a file in the parent snapshot that has prealloc extents beyond EOF and in the send snapshot it got a hole punch that partially covers the prealloc extents, the send stream, when replayed by a receiver, can result in a file that has a size bigger than it should and filled with zeroes past the correct EOF. For example: $ mkfs.btrfs -f /dev/sdb $ mount /dev/sdb /mnt $ xfs_io -f -c "falloc -k 0 4M" /mnt/foobar $ xfs_io -c "pwrite -S 0xea 0 1M" /mnt/foobar $ btrfs subvolume snapshot -r /mnt /mnt/snap1 $ btrfs send -f /tmp/1.send /mnt/snap1 $ xfs_io -c "fpunch 1M 2M" /mnt/foobar $ btrfs subvolume snapshot -r /mnt /mnt/snap2 $ btrfs send -f /tmp/2.send -p /mnt/snap1 /mnt/snap2 $ stat --format %s /mnt/snap2/foobar 1048576 $ md5sum /mnt/snap2/foobar d31659e82e87798acd4669a1e0a19d4f /mnt/snap2/foobar $ umount /mnt $ mkfs.btrfs -f /dev/sdc $ mount /dev/sdc /mnt $ btrfs receive -f /mnt/1.snap /mnt $ btrfs receive -f /mnt/2.snap /mnt $ stat --format %s /mnt/snap2/foobar 3145728 # --> should be 1Mb and not 3Mb (which was the end offset of hole # punch operation) $ md5sum /mnt/snap2/foobar 117baf295297c2a995f92da725b0b651 /mnt/snap2/foobar # --> should be d31659e82e87798acd4669a1e0a19d4f as in the original fs This issue actually happens only since commit ffa7c4296e93 ("Btrfs: send, do not issue unnecessary truncate operations"), but before that commit we were issuing a write operation full of zeroes (to "punch" a hole) which was extending the file size beyond the correct value and then immediately issue a truncate operation to the correct size and undoing the previous write operation. Since the send protocol does not support fallocate, for extent preallocation and hole punching, fix this by not even attempting to send a "hole" (regular write full of zeroes) if it starts at an offset greater then or equals to the file's size. This approach, besides being much more simple then making send issue the truncate operation, adds the benefit of avoiding the useless pair of write of zeroes and truncate operations, saving time and IO at the receiver and reducing the size of the send stream. A test case for fstests follows soon. Fixes: ffa7c4296e93 ("Btrfs: send, do not issue unnecessary truncate operations") CC: stable@vger.kernel.org # 4.17+ Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 23dd2c5d90a1c13aa1a80374fc2da6e936a5f530 Author: Filipe Manana Date: Tue Jul 24 11:54:04 2018 +0100 Btrfs: fix send failure when root has deleted files still open commit 46b2f4590aab71d31088a265c86026b1e96c9de4 upstream. The more common use case of send involves creating a RO snapshot and then use it for a send operation. In this case it's not possible to have inodes in the snapshot that have a link count of zero (inode with an orphan item) since during snapshot creation we do the orphan cleanup. However, other less common use cases for send can end up seeing inodes with a link count of zero and in this case the send operation fails with a ENOENT error because any attempt to generate a path for the inode, with the purpose of creating it or updating it at the receiver, fails since there are no inode reference items. One use case it to use a regular subvolume for a send operation after turning it to RO mode or turning a RW snapshot into RO mode and then using it for a send operation. In both cases, if a file gets all its hard links deleted while there is an open file descriptor before turning the subvolume/snapshot into RO mode, the send operation will encounter an inode with a link count of zero and then fail with errno ENOENT. Example using a full send with a subvolume: $ mkfs.btrfs -f /dev/sdb $ mount /dev/sdb /mnt $ btrfs subvolume create /mnt/sv1 $ touch /mnt/sv1/foo $ touch /mnt/sv1/bar # keep an open file descriptor on file bar $ exec 73> /mnt/sv1/bar $ btrfs subvolume snapshot -r /mnt/sv1 /mnt/snap2 # Turn the second snapshot to RW mode and delete file foo while # holding an open file descriptor on it. $ btrfs property set /mnt/snap2 ro false $ exec 73 Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 7ecc8a106c535336577e0dfcfa61500fbee57eee Author: Josef Bacik Date: Fri Jul 20 11:46:10 2018 -0700 Btrfs: fix btrfs_write_inode vs delayed iput deadlock commit 3c4276936f6fbe52884b4ea4e6cc120b890a0f9f upstream. We recently ran into the following deadlock involving btrfs_write_inode(): [ +0.005066] __schedule+0x38e/0x8c0 [ +0.007144] schedule+0x36/0x80 [ +0.006447] bit_wait+0x11/0x60 [ +0.006446] __wait_on_bit+0xbe/0x110 [ +0.007487] ? bit_wait_io+0x60/0x60 [ +0.007319] __inode_wait_for_writeback+0x96/0xc0 [ +0.009568] ? autoremove_wake_function+0x40/0x40 [ +0.009565] inode_wait_for_writeback+0x21/0x30 [ +0.009224] evict+0xb0/0x190 [ +0.006099] iput+0x1a8/0x210 [ +0.006103] btrfs_run_delayed_iputs+0x73/0xc0 [ +0.009047] btrfs_commit_transaction+0x799/0x8c0 [ +0.009567] btrfs_write_inode+0x81/0xb0 [ +0.008008] __writeback_single_inode+0x267/0x320 [ +0.009569] writeback_sb_inodes+0x25b/0x4e0 [ +0.008702] wb_writeback+0x102/0x2d0 [ +0.007487] wb_workfn+0xa4/0x310 [ +0.006794] ? wb_workfn+0xa4/0x310 [ +0.007143] process_one_work+0x150/0x410 [ +0.008179] worker_thread+0x6d/0x520 [ +0.007490] kthread+0x12c/0x160 [ +0.006620] ? put_pwq_unlocked+0x80/0x80 [ +0.008185] ? kthread_park+0xa0/0xa0 [ +0.007484] ? do_syscall_64+0x53/0x150 [ +0.007837] ret_from_fork+0x29/0x40 Writeback calls: btrfs_write_inode btrfs_commit_transaction btrfs_run_delayed_iputs If iput() is called on that same inode, evict() will wait for writeback forever. btrfs_write_inode() was originally added way back in 4730a4bc5bf3 ("btrfs_dirty_inode") to support O_SYNC writes. However, ->write_inode() hasn't been used for O_SYNC since 148f948ba877 ("vfs: Introduce new helpers for syncing after writing to O_SYNC file or IS_SYNC inode"), so btrfs_write_inode() is actually unnecessary (and leads to a bunch of unnecessary commits). Get rid of it, which also gets rid of the deadlock. CC: stable@vger.kernel.org # 3.2+ Signed-off-by: Josef Bacik [Omar: new commit message] Signed-off-by: Omar Sandoval Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 84717fb63dad27bff4aafe8f3ac4207744d8a338 Author: Filipe Manana Date: Fri Jul 20 10:59:06 2018 +0100 Btrfs: fix mount failure after fsync due to hard link recreation commit 0d836392cadd5535f4184d46d901a82eb276ed62 upstream. If we end up with logging an inode reference item which has the same name but different index from the one we have persisted, we end up failing when replaying the log with an errno value of -EEXIST. The error comes from btrfs_add_link(), which is called from add_inode_ref(), when we are replaying an inode reference item. Example scenario where this happens: $ mkfs.btrfs -f /dev/sdb $ mount /dev/sdb /mnt $ touch /mnt/foo $ ln /mnt/foo /mnt/bar $ sync # Rename the first hard link (foo) to a new name and rename the second # hard link (bar) to the old name of the first hard link (foo). $ mv /mnt/foo /mnt/qwerty $ mv /mnt/bar /mnt/foo # Create a new file, in the same parent directory, with the old name of # the second hard link (bar) and fsync this new file. # We do this instead of calling fsync on foo/qwerty because if we did # that the fsync resulted in a full transaction commit, not triggering # the problem. $ touch /mnt/bar $ xfs_io -c "fsync" /mnt/bar $ mount /dev/sdb /mnt mount: mount /dev/sdb on /mnt failed: File exists So fix this by checking if a conflicting inode reference exists (same name, same parent but different index), removing it (and the associated dir index entries from the parent inode) if it exists, before attempting to add the new reference. A test case for fstests follows soon. CC: stable@vger.kernel.org # 4.4+ Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 8b08e816f47ae3b566dba440750e68e1b0e87482 Author: Josef Bacik Date: Thu Jul 19 10:49:51 2018 -0400 btrfs: don't leak ret from do_chunk_alloc commit 4559b0a71749c442d34f7cfb9e72c9e58db83948 upstream. If we're trying to make a data reservation and we have to allocate a data chunk we could leak ret == 1, as do_chunk_alloc() will return 1 if it allocated a chunk. Since the end of the function is the success path just return 0. CC: stable@vger.kernel.org # 4.4+ Signed-off-by: Josef Bacik Reviewed-by: Nikolay Borisov Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 258c1eb7cde6dc91655421f13913425376f7c906 Author: Ethan Lien Date: Mon Jul 2 15:44:58 2018 +0800 btrfs: use correct compare function of dirty_metadata_bytes commit d814a49198eafa6163698bdd93961302f3a877a4 upstream. We use customized, nodesize batch value to update dirty_metadata_bytes. We should also use batch version of compare function or we will easily goto fast path and get false result from percpu_counter_compare(). Fixes: e2d845211eda ("Btrfs: use percpu counter for dirty metadata count") CC: stable@vger.kernel.org # 4.4+ Signed-off-by: Ethan Lien Reviewed-by: Nikolay Borisov Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit fb35368feb7f5712f9a929b4d49b67999dd16e45 Author: Steve French Date: Sun Jun 24 23:18:52 2018 -0500 smb3: fill in statfs fsid and correct namelen commit 21ba3845b59c733a79ed4fe1c4f3732e7ece9df7 upstream. Fil in the correct namelen (typically 255 not 4096) in the statfs response and also fill in a reasonably unique fsid (in this case taken from the volume id, and the creation time of the volume). In the case of the POSIX statfs all fields are now filled in, and in the case of non-POSIX mounts, all fields are filled in which can be. Signed-off-by: Steve French CC: Stable Reviewed-by: Aurelien Aptel Signed-off-by: Greg Kroah-Hartman commit 107d9ee2e080cb038a819a4f41784013bc6c9b60 Author: Steve French Date: Fri Jul 27 22:01:49 2018 -0500 smb3: don't request leases in symlink creation and query commit 22783155f4bf956c346a81624ec9258930a6fe06 upstream. Fixes problem pointed out by Pavel in discussions about commit 729c0c9dd55204f0c9a823ac8a7bfa83d36c7e78 Signed-off-by: Pavel Shilovsky Signed-off-by: Steve French Reviewed-by: Ronnie Sahlberg CC: Stable # 3.18.x+ Signed-off-by: Greg Kroah-Hartman commit 1316a0cc27d11fa94c864f147f96ad1362e9876d Author: Steve French Date: Thu Aug 2 20:28:18 2018 -0500 smb3: Do not send SMB3 SET_INFO if nothing changed commit fd09b7d3b352105f08b8e02f7afecf7e816380ef upstream. An earlier commit had a typo which prevented the optimization from working: commit 18dd8e1a65dd ("Do not send SMB3 SET_INFO request if nothing is changing") Thank you to Metze for noticing this. Also clear a reserved field in the FILE_BASIC_INFO struct we send that should be zero (all the other fields in that struct were set or cleared explicitly already in cifs_set_file_info). Reviewed-by: Pavel Shilovsky CC: Stable # 4.9.x+ Reported-by: Stefan Metzmacher Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 25b981bfe192fd208ba04c81f4aa30ffb5141660 Author: Steve French Date: Thu Aug 9 14:33:12 2018 -0500 smb3: enumerating snapshots was leaving part of the data off end commit e02789a53d71334b067ad72eee5d4e88a0158083 upstream. When enumerating snapshots, the last few bytes of the final snapshot could be left off since we were miscalculating the length returned (leaving off the sizeof struct SRV_SNAPSHOT_ARRAY) See MS-SMB2 section 2.2.32.2. In addition fixup the length used to allow smaller buffer to be passed in, in order to allow returning the size of the whole snapshot array more easily. Sample userspace output with a kernel patched with this (mounted to a Windows volume with two snapshots). Before this patch, the second snapshot would be missing a few bytes at the end. ~/cifs-2.6# ~/enum-snapshots /mnt/file press enter to issue the ioctl to retrieve snapshot information ... size of snapshot array = 102 Num snapshots: 2 Num returned: 2 Array Size: 102 Snapshot 0:@GMT-2018.06.30-19.34.17 Snapshot 1:@GMT-2018.06.30-19.33.37 CC: Stable Signed-off-by: Steve French Reviewed-by: Pavel Shilovsky Signed-off-by: Greg Kroah-Hartman commit a66f62737197b1b80216f629fc70b4ad7e332061 Author: Nicholas Mc Guire Date: Thu Aug 23 12:24:02 2018 +0200 cifs: check kmalloc before use commit 126c97f4d0d1b5b956e8b0740c81a2b2a2ae548c upstream. The kmalloc was not being checked - if it fails issue a warning and return -ENOMEM to the caller. Signed-off-by: Nicholas Mc Guire Fixes: b8da344b74c8 ("cifs: dynamic allocation of ntlmssp blob") Signed-off-by: Steve French Reviewed-by: Pavel Shilovsky cc: Stable ` Signed-off-by: Greg Kroah-Hartman commit a1ac808c81a6e2219101ab12d86a228a4364805a Author: Ronnie Sahlberg Date: Tue Jul 31 08:48:22 2018 +1000 cifs: use a refcount to protect open/closing the cached file handle commit 9da6ec7775d2cd76df53fbf4f1f35f6d490204f5 upstream. Signed-off-by: Ronnie Sahlberg Signed-off-by: Steve French Reviewed-by: Pavel Shilovsky Cc: Signed-off-by: Greg Kroah-Hartman commit 5ba293d099ceee0a69aec2e47a74674a61493ac6 Author: Steve French Date: Thu Jun 28 18:46:40 2018 -0500 cifs: add missing debug entries for kconfig options commit 950132afd59385caf6e2b84e5235d069fa10681d upstream. /proc/fs/cifs/DebugData displays the features (Kconfig options) used to build cifs.ko but it was missing some, and needed comma separator. These can be useful in debugging certain problems so we know which optional features were enabled in the user's build. Also clarify them, by making them more closely match the corresponding CONFIG_CIFS_* parm. Old format: Features: dfs fscache posix spnego xattr acl New format: Features: DFS,FSCACHE,SMB_DIRECT,STATS,DEBUG2,ALLOW_INSECURE_LEGACY,CIFS_POSIX,UPCALL(SPNEGO),XATTR,ACL Signed-off-by: Steve French Reviewed-by: Ronnie Sahlberg Reviewed-by: Pavel Shilovsky Reviewed-by: Paulo Alcantara CC: Stable Signed-off-by: Greg Kroah-Hartman commit 52b9e2a58be215521bd7cbada56f51eb29c2d393 Author: Aurelien Aptel Date: Thu Aug 2 16:39:52 2018 +0200 CIFS: fix uninitialized ptr deref in smb2 signing commit a5c62f4833c2c8e6e0f35367b99b717b78f5c029 upstream. server->secmech.sdeschmacsha256 is not properly initialized before smb2_shash_allocate(), set shash after that call. also fix typo in error message Fixes: 8de8c4608fe9 ("cifs: Fix validation of signed data in smb2") Signed-off-by: Aurelien Aptel Reviewed-by: Paulo Alcantara Reported-by: Xiaoli Feng Signed-off-by: Steve French CC: Stable Signed-off-by: Greg Kroah-Hartman commit a673044fbe8b16c27fedb595959167e1ac9bda71 Author: Ronnie Sahlberg Date: Fri Aug 10 11:03:55 2018 +1000 cifs: add missing support for ACLs in SMB 3.11 commit c1777df1a5d541cda918ff0450c8adcc8b69c2fd upstream. We were missing the methods for get_acl and friends for the 3.11 dialect. Signed-off-by: Ronnie Sahlberg Signed-off-by: Steve French CC: Stable Reviewed-by: Pavel Shilovsky Signed-off-by: Greg Kroah-Hartman commit 08aee5c2c26f5f8a17446da9a137ac8400a0e692 Author: Alexander Usyskin Date: Mon Jul 9 12:21:44 2018 +0300 mei: don't update offset in write commit a103af1b64d74853a5e08ca6c86aeb0e5c6ca4f1 upstream. MEI enables writes of complete messages only while read can be performed in parts, hence write should not update the file offset to not break interleaving partial reads with writes. Cc: Signed-off-by: Alexander Usyskin Signed-off-by: Tomas Winkler Signed-off-by: Greg Kroah-Hartman commit 6bdbaa2fdd481cf038de27ecc913881d0981e07d Author: Chuck Lever Date: Sat Jul 28 10:46:47 2018 -0400 xprtrdma: Fix disconnect regression commit 8d4fb8ff427a23e573c9373b2bb3d1d6e8ea4399 upstream. I found that injecting disconnects with v4.18-rc resulted in random failures of the multi-threaded git regression test. The root cause appears to be that, after a reconnect, the RPC/RDMA transport is waking pending RPCs before the transport has posted enough Receive buffers to receive the Replies. If a Reply arrives before enough Receive buffers are posted, the connection is dropped. A few connection drops happen in quick succession as the client and server struggle to regain credit synchronization. This regression was introduced with commit 7c8d9e7c8863 ("xprtrdma: Move Receive posting to Receive handler"). The client is supposed to post a single Receive when a connection is established because it's not supposed to send more than one RPC Call before it gets a fresh credit grant in the first RPC Reply [RFC 8166, Section 3.3.3]. Unfortunately there appears to be a longstanding bug in the Linux client's credit accounting mechanism. On connect, it simply dumps all pending RPC Calls onto the new connection. It's possible it has done this ever since the RPC/RDMA transport was added to the kernel ten years ago. Servers have so far been tolerant of this bad behavior. Currently no server implementation ever changes its credit grant over reconnects, and servers always repost enough Receives before connections are fully established. The Linux client implementation used to post a Receive before each of these Calls. This has covered up the flooding send behavior. I could try to correct this old bug so that the client sends exactly one RPC Call and waits for a Reply. Since we are so close to the next merge window, I'm going to instead provide a simple patch to post enough Receives before a reconnect completes (based on the number of credits granted to the previous connection). The spurious disconnects will be gone, but the client will still send multiple RPC Calls immediately after a reconnect. Addressing the latter problem will wait for a merge window because a) I expect it to be a large change requiring lots of testing, and b) obviously the Linux client has interoperated successfully since day zero while still being broken. Fixes: 7c8d9e7c8863 ("xprtrdma: Move Receive posting to ... ") Cc: stable@vger.kernel.org # v4.18+ Signed-off-by: Chuck Lever Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit 84342771f595b576a2d64775c0fd88d3bb95138e Author: Jason Yan Date: Thu May 10 11:05:16 2018 +0800 scsi: libsas: dynamically allocate and free ata host commit 2fa4a32613c9182b00e46872755b0662374424a7 upstream. Commit 2623c7a5f2 ("libata: add refcounting to ata_host") v4.17+ introduced refcounting to ata_host and will increase or decrease the refcount when adding or deleting transport ATA port. Now the ata host for libsas is embedded in domain_device, and the ->kref member is not initialized. Afer we add ata transport class, ata_host_get() will be called when adding transport ATA port and a warning will be triggered as below: refcount_t: increment on 0; use-after-free. WARNING: CPU: 2 PID: 103 at lib/refcount.c:153 refcount_inc+0x40/0x48 ...... Call trace: refcount_inc+0x40/0x48 ata_host_get+0x10/0x18 ata_tport_add+0x40/0x120 ata_sas_tport_add+0xc/0x14 sas_ata_init+0x7c/0xc8 sas_discover_domain+0x380/0x53c process_one_work+0x12c/0x288 worker_thread+0x58/0x3f0 kthread+0xfc/0x128 ret_from_fork+0x10/0x18 And also when removing transport ATA port ata_host_put() will be called and another similar warning will be triggered. If the refcount decreased to zero, the ata host will be freed. But this ata host is only part of domain_device, it cannot be freed directly. So we have to change this embedded static ata host to a dynamically allocated ata host and initialize the ->kref member. To use ata_host_get() and ata_host_put() in libsas, we need to move the declaration of these functions to the public libata.h and export them. Fixes: b6240a4df018 ("scsi: libsas: add transport class for ATA devices") Signed-off-by: Jason Yan CC: John Garry CC: Taras Kondratiuk CC: Tejun Heo Acked-by: Tejun Heo Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 16edb8e6d47225d316cdd7f74c9a19e92b5fa860 Author: Ben Hutchings Date: Sun Aug 5 17:41:09 2018 +0100 scripts/kernel-doc: Escape all literal braces in regexes commit 673bb2dfc36488abfdbbfc2ce2631204eaf682f2 upstream. Commit 701b3a3c0ac4 ("PATCH scripts/kernel-doc") fixed the two instances of literal braces that Perl 5.28 warns about, but there are still more than it doesn't warn about. Escape all left braces that are treated as literal characters. Also escape literal right braces, for consistency and to avoid confusing bracket-matching in text editors. Signed-off-by: Ben Hutchings Signed-off-by: Jonathan Corbet Cc: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman commit 10bb2648f16c22a18766588f2fcd0f1f9426453e Author: Valdis Kletnieks Date: Tue Jul 17 12:57:29 2018 -0400 PATCH scripts/kernel-doc commit 701b3a3c0ac42630f74a5efba8545d61ac0e3293 upstream. Fix a warning whinge from Perl introduced by "scripts: kernel-doc: parse next structs/unions" Unescaped left brace in regex is deprecated here (and will be fatal in Perl 5.32), passed through in regex; marked by <-- HERE in m/({ <-- HERE [^\{\}]*})/ at ./scripts/kernel-doc line 1155. Unescaped left brace in regex is deprecated here (and will be fatal in Perl 5.32), passed through in regex; marked by <-- HERE in m/({ <-- HERE )/ at ./scripts/kernel-doc line 1179. Signed-off-by: Valdis Kletnieks Reviewed-by: Mauro Carvalho Chehab Signed-off-by: Jonathan Corbet Cc: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman