commit 835365932f0dc25468840753e071c05ad6abc76f Author: Greg Kroah-Hartman Date: Sat May 25 18:16:51 2019 +0200 Linux 5.1.5 commit fa416e2b3ebe3c045ffeb9699aba7456fc0a0a5b Author: Yifeng Li Date: Tue Apr 2 17:14:10 2019 +0200 fbdev: sm712fb: fix memory frequency by avoiding a switch/case fallthrough commit 9dc20113988b9a75ea6b3abd68dc45e2d73ccdab upstream. A fallthrough in switch/case was introduced in f627caf55b8e ("fbdev: sm712fb: fix crashes and garbled display during DPMS modesetting"), due to my copy-paste error, which would cause the memory clock frequency for SM720 to be programmed to SM712. Since it only reprograms the clock to a different frequency, it's only a benign issue without visible side-effect, so it also evaded Sudip Mukherjee's code review and regression tests. scripts/checkpatch.pl also failed to discover the issue, possibly due to nested switch statements. This issue was found by Stephen Rothwell by building linux-next with -Wimplicit-fallthrough. Reported-by: Stephen Rothwell Fixes: f627caf55b8e ("fbdev: sm712fb: fix crashes and garbled display during DPMS modesetting") Signed-off-by: Yifeng Li Cc: Sudip Mukherjee Cc: "Gustavo A. R. Silva" Cc: Kees Cook Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Greg Kroah-Hartman commit bf5ccf415dde3d25b4e93533623b83bd2833be39 Author: Adam Ford Date: Tue Apr 2 14:19:08 2019 -0500 ARM: dts: imx6q-logicpd: Reduce inrush current on start commit dbb58e291cd47e594b64293bd91a4ce40626513c upstream. The main 3.3V regulator sources a series of additional regulators. This patch adds a small delay, so when the 3.3V regulator comes on it delays a bit before the subsequent regulators can come on. This reduces the inrush current a bit on the external DC power supply to help prevent a situation where the sourcing power supply cannot source enough current and overloads and the kit fails to start. Fixes: 1c207f911fe9 ("ARM: dts: imx: Add support for Logic PD i.MX6QD EVM") Signed-off-by: Adam Ford Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman commit 5397a98f08c0c5e0686b784bbe263d93dfc0caf3 Author: Adam Ford Date: Tue Apr 2 14:32:04 2019 -0500 ARM: dts: imx6q-logicpd: Reduce inrush current on USBH1 commit 7aedca875074b33795bc77066b325898b1eb8032 upstream. Some USB peripherals draw more power, and the sourcing regulator take a little time to turn on. This patch fixes an issue where some devices occasionally do not get detected, because the power isn't quite ready when communication starts, so we add a bit of a delay. Fixes: 1c207f911fe9 ("ARM: dts: imx: Add support for Logic PD i.MX6QD EVM") Signed-off-by: Adam Ford Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman commit a28d37d7bef79fc0bd97d69b3748c32b0d309653 Author: Qu Wenruo Date: Mon Mar 18 10:48:19 2019 +0800 btrfs: reloc: Fix NULL pointer dereference due to expanded reloc_root lifespan commit 10995c0491204c861948c9850939a7f4e90760a4 upstream. Commit d2311e698578 ("btrfs: relocation: Delay reloc tree deletion after merge_reloc_roots()") expands the life span of root->reloc_root. This breaks certain checs of fs_info->reloc_ctl. Before that commit, if we have a root with valid reloc_root, then it's ensured to have fs_info->reloc_ctl. But now since reloc_root doesn't always mean a valid fs_info->reloc_ctl, such check is unreliable and can cause the following NULL pointer dereference: BUG: unable to handle kernel NULL pointer dereference at 00000000000005c1 IP: btrfs_reloc_pre_snapshot+0x20/0x50 [btrfs] PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI CPU: 0 PID: 10379 Comm: snapperd Not tainted Call Trace: create_pending_snapshot+0xd7/0xfc0 [btrfs] create_pending_snapshots+0x8e/0xb0 [btrfs] btrfs_commit_transaction+0x2ac/0x8f0 [btrfs] btrfs_mksubvol+0x561/0x570 [btrfs] btrfs_ioctl_snap_create_transid+0x189/0x190 [btrfs] btrfs_ioctl_snap_create_v2+0x102/0x150 [btrfs] btrfs_ioctl+0x5c9/0x1e60 [btrfs] do_vfs_ioctl+0x90/0x5f0 SyS_ioctl+0x74/0x80 do_syscall_64+0x7b/0x150 entry_SYSCALL_64_after_hwframe+0x3d/0xa2 RIP: 0033:0x7fd7cdab8467 Fix it by explicitly checking fs_info->reloc_ctl other than using the implied root->reloc_root. Fixes: d2311e698578 ("btrfs: relocation: Delay reloc tree deletion after merge_reloc_roots") Signed-off-by: Qu Wenruo Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 9e195a420c6bae5d194b61897448d5b9c156196f Author: Arnd Bergmann Date: Mon Apr 29 15:19:37 2019 +0200 y2038: Make CONFIG_64BIT_TIME unconditional commit f3d964673b2f1c5d5c68c77273efcf7103eed03b upstream. As Stepan Golosunov points out, there is a small mistake in the get_timespec64() function in the kernel. It was originally added under the assumption that CONFIG_64BIT_TIME would get enabled on all 32-bit and 64-bit architectures, but when the conversion was done, it was only turned on for 32-bit ones. The effect is that the get_timespec64() function never clears the upper half of the tv_nsec field for 32-bit tasks in compat mode. Clearing this is required for POSIX compliant behavior of functions that pass a 'timespec' structure with a 64-bit tv_sec and a 32-bit tv_nsec, plus uninitialized padding. The easiest fix for linux-5.1 is to just make the Kconfig symbol unconditional, as it was originally intended. As a follow-up, the #ifdef CONFIG_64BIT_TIME can be removed completely.. Note: for native 32-bit mode, no change is needed, this works as designed and user space should never need to clear the upper 32 bits of the tv_nsec field, in or out of the kernel. Fixes: 00bf25d693e7 ("y2038: use time32 syscall names on 32-bit") Signed-off-by: Arnd Bergmann Signed-off-by: Thomas Gleixner Cc: Joseph Myers Cc: libc-alpha@sourceware.org Cc: linux-api@vger.kernel.org Cc: Deepa Dinamani Cc: Lukasz Majewski Cc: Stepan Golosunov Link: https://lore.kernel.org/lkml/20190422090710.bmxdhhankurhafxq@sghpc.golosunov.pp.ru/ Link: https://lkml.kernel.org/r/20190429131951.471701-1-arnd@arndb.de Signed-off-by: Greg Kroah-Hartman commit 9503419a8b35d924c91ba5f0a80c054273d12d05 Author: Daniel Borkmann Date: Tue May 14 01:18:56 2019 +0200 bpf, lru: avoid messing with eviction heuristics upon syscall lookup commit 50b045a8c0ccf44f76640ac3eea8d80ca53979a3 upstream. One of the biggest issues we face right now with picking LRU map over regular hash table is that a map walk out of user space, for example, to just dump the existing entries or to remove certain ones, will completely mess up LRU eviction heuristics and wrong entries such as just created ones will get evicted instead. The reason for this is that we mark an entry as "in use" via bpf_lru_node_set_ref() from system call lookup side as well. Thus upon walk, all entries are being marked, so information of actual least recently used ones are "lost". In case of Cilium where it can be used (besides others) as a BPF based connection tracker, this current behavior causes disruption upon control plane changes that need to walk the map from user space to evict certain entries. Discussion result from bpfconf [0] was that we should simply just remove marking from system call side as no good use case could be found where it's actually needed there. Therefore this patch removes marking for regular LRU and per-CPU flavor. If there ever should be a need in future, the behavior could be selected via map creation flag, but due to mentioned reason we avoid this here. [0] http://vger.kernel.org/bpfconf.html Fixes: 29ba732acbee ("bpf: Add BPF_MAP_TYPE_LRU_HASH") Fixes: 8f8449384ec3 ("bpf: Add BPF_MAP_TYPE_LRU_PERCPU_HASH") Signed-off-by: Daniel Borkmann Acked-by: Martin KaFai Lau Signed-off-by: Alexei Starovoitov Signed-off-by: Greg Kroah-Hartman commit 45b5613806e47c91f9b3487a926e9e3eb6b7bb4b Author: Daniel Borkmann Date: Tue May 14 01:18:55 2019 +0200 bpf: add map_lookup_elem_sys_only for lookups from syscall side commit c6110222c6f49ea68169f353565eb865488a8619 upstream. Add a callback map_lookup_elem_sys_only() that map implementations could use over map_lookup_elem() from system call side in case the map implementation needs to handle the latter differently than from the BPF data path. If map_lookup_elem_sys_only() is set, this will be preferred pick for map lookups out of user space. This hook is used in a follow-up fix for LRU map, but once development window opens, we can convert other map types from map_lookup_elem() (here, the one called upon BPF_MAP_LOOKUP_ELEM cmd is meant) over to use the callback to simplify and clean up the latter. Signed-off-by: Daniel Borkmann Acked-by: Martin KaFai Lau Signed-off-by: Alexei Starovoitov Signed-off-by: Greg Kroah-Hartman commit 832f7c334678c4d5f0113e3fc95e7bbd151083f3 Author: Chenbo Feng Date: Tue May 14 19:42:57 2019 -0700 bpf: relax inode permission check for retrieving bpf program commit e547ff3f803e779a3898f1f48447b29f43c54085 upstream. For iptable module to load a bpf program from a pinned location, it only retrieve a loaded program and cannot change the program content so requiring a write permission for it might not be necessary. Also when adding or removing an unrelated iptable rule, it might need to flush and reload the xt_bpf related rules as well and triggers the inode permission check. It might be better to remove the write premission check for the inode so we won't need to grant write access to all the processes that flush and restore iptables rules. Signed-off-by: Chenbo Feng Signed-off-by: Alexei Starovoitov Signed-off-by: Daniel Borkmann Signed-off-by: Greg Kroah-Hartman commit 04bdef8340c1477c5f55b96c17b8956d656c6411 Author: John Garry Date: Thu Mar 28 18:08:05 2019 +0800 driver core: Postpone DMA tear-down until after devres release for probe failure commit 0b777eee88d712256ba8232a9429edb17c4f9ceb upstream. In commit 376991db4b64 ("driver core: Postpone DMA tear-down until after devres release"), we changed the ordering of tearing down the device DMA ops and releasing all the device's resources; this was because the DMA ops should be maintained until we release the device's managed DMA memories. However, we have seen another crash on an arm64 system when a device driver probe fails: hisi_sas_v3_hw 0000:74:02.0: Adding to iommu group 2 scsi host1: hisi_sas_v3_hw BUG: Bad page state in process swapper/0 pfn:313f5 page:ffff7e0000c4fd40 count:1 mapcount:0 mapping:0000000000000000 index:0x0 flags: 0xfffe00000001000(reserved) raw: 0fffe00000001000 ffff7e0000c4fd48 ffff7e0000c4fd48 0000000000000000 raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000 page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set bad because of flags: 0x1000(reserved) Modules linked in: CPU: 49 PID: 1 Comm: swapper/0 Not tainted 5.1.0-rc1-43081-g22d97fd-dirty #1433 Hardware name: Huawei D06/D06, BIOS Hisilicon D06 UEFI RC0 - V1.12.01 01/29/2019 Call trace: dump_backtrace+0x0/0x118 show_stack+0x14/0x1c dump_stack+0xa4/0xc8 bad_page+0xe4/0x13c free_pages_check_bad+0x4c/0xc0 __free_pages_ok+0x30c/0x340 __free_pages+0x30/0x44 __dma_direct_free_pages+0x30/0x38 dma_direct_free+0x24/0x38 dma_free_attrs+0x9c/0xd8 dmam_release+0x20/0x28 release_nodes+0x17c/0x220 devres_release_all+0x34/0x54 really_probe+0xc4/0x2c8 driver_probe_device+0x58/0xfc device_driver_attach+0x68/0x70 __driver_attach+0x94/0xdc bus_for_each_dev+0x5c/0xb4 driver_attach+0x20/0x28 bus_add_driver+0x14c/0x200 driver_register+0x6c/0x124 __pci_register_driver+0x48/0x50 sas_v3_pci_driver_init+0x20/0x28 do_one_initcall+0x40/0x25c kernel_init_freeable+0x2b8/0x3c0 kernel_init+0x10/0x100 ret_from_fork+0x10/0x18 Disabling lock debugging due to kernel taint BUG: Bad page state in process swapper/0 pfn:313f6 page:ffff7e0000c4fd80 count:1 mapcount:0 mapping:0000000000000000 index:0x0 [ 89.322983] flags: 0xfffe00000001000(reserved) raw: 0fffe00000001000 ffff7e0000c4fd88 ffff7e0000c4fd88 0000000000000000 raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000 The crash occurs for the same reason. In this case, on the really_probe() failure path, we are still clearing the DMA ops prior to releasing the device's managed memories. This patch fixes this issue by reordering the DMA ops teardown and the call to devres_release_all() on the failure path. Reported-by: Xiang Chen Tested-by: Xiang Chen Signed-off-by: John Garry Reviewed-by: Robin Murphy Signed-off-by: Greg Kroah-Hartman commit 40aab1990f71a828e28d7b0c907be0f726c30a1c Author: Angus Ainslie (Purism) Date: Fri Mar 29 08:21:29 2019 -0700 dmaengine: imx-sdma: Only check ratio on parts that support 1:1 commit 941acd566b1807b291bbdca31cc5158e26ffcf83 upstream. On imx8mq B0 chip, AHB/SDMA clock ratio 2:1 can't be supported, since SDMA clock ratio has to be increased to 250Mhz, AHB can't reach to 500Mhz, so use 1:1 instead. To limit this change to the imx8mq for now this patch also adds an im8mq-sdma compatible string. Signed-off-by: Angus Ainslie (Purism) Acked-by: Robin Gong Signed-off-by: Vinod Koul Cc: Richard Leitner Signed-off-by: Greg Kroah-Hartman commit 859c4c2852c6d43a8fda88035c40672b94a6ffe6 Author: Nigel Croxon Date: Tue Apr 16 09:50:09 2019 -0700 md/raid: raid5 preserve the writeback action after the parity check commit b2176a1dfb518d870ee073445d27055fea64dfb8 upstream. The problem is that any 'uptodate' vs 'disks' check is not precise in this path. Put a "WARN_ON(!test_bit(R5_UPTODATE, &dev->flags)" on the device that might try to kick off writes and then skip the action. Better to prevent the raid driver from taking unexpected action *and* keep the system alive vs killing the machine with BUG_ON. Note: fixed warning reported by kbuild test robot Signed-off-by: Dan Williams Signed-off-by: Nigel Croxon Signed-off-by: Song Liu Signed-off-by: Greg Kroah-Hartman commit c42adfe635469f40e1809938b1dcbf9150d1d301 Author: Song Liu Date: Tue Apr 16 09:34:21 2019 -0700 Revert "Don't jump to compute_result state from check_result state" commit a25d8c327bb41742dbd59f8c545f59f3b9c39983 upstream. This reverts commit 4f4fd7c5798bbdd5a03a60f6269cf1177fbd11ef. Cc: Dan Williams Cc: Nigel Croxon Cc: Xiao Ni Signed-off-by: Song Liu Signed-off-by: Greg Kroah-Hartman commit 871e122d55e8d1cd7c0d5dec9bdba1fe45406196 Author: Michael Lass Date: Tue May 21 21:58:07 2019 +0200 dm: make sure to obey max_io_len_target_boundary commit 51b86f9a8d1c4bb4e3862ee4b4c5f46072f7520d upstream. Commit 61697a6abd24 ("dm: eliminate 'split_discard_bios' flag from DM target interface") incorrectly removed code from __send_changing_extent_only() that is required to impose a per-target IO boundary on IO that exceeds max_io_len_target_boundary(). Otherwise "special" IO (e.g. DISCARD, WRITE SAME, WRITE ZEROES) can write beyond where allowed. Fix this by restoring the max_io_len_target_boundary() limit in __send_changing_extent_only() Fixes: 61697a6abd24 ("dm: eliminate 'split_discard_bios' flag from DM target interface") Cc: stable@vger.kernel.org # 5.1+ Signed-off-by: Michael Lass Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 5bb2a758f2ed58df37d589f69bcb1400bd43ed89 Author: Kirill Smelkov Date: Wed Apr 24 07:13:57 2019 +0000 fuse: Add FOPEN_STREAM to use stream_open() commit bbd84f33652f852ce5992d65db4d020aba21f882 upstream. Starting from commit 9c225f2655e3 ("vfs: atomic f_pos accesses as per POSIX") files opened even via nonseekable_open gate read and write via lock and do not allow them to be run simultaneously. This can create read vs write deadlock if a filesystem is trying to implement a socket-like file which is intended to be simultaneously used for both read and write from filesystem client. See commit 10dce8af3422 ("fs: stream_open - opener for stream-like files so that read and write can run simultaneously without deadlock") for details and e.g. commit 581d21a2d02a ("xenbus: fix deadlock on writes to /proc/xen/xenbus") for a similar deadlock example on /proc/xen/xenbus. To avoid such deadlock it was tempting to adjust fuse_finish_open to use stream_open instead of nonseekable_open on just FOPEN_NONSEEKABLE flags, but grepping through Debian codesearch shows users of FOPEN_NONSEEKABLE, and in particular GVFS which actually uses offset in its read and write handlers https://codesearch.debian.net/search?q=-%3Enonseekable+%3D https://gitlab.gnome.org/GNOME/gvfs/blob/1.40.0-6-gcbc54396/client/gvfsfusedaemon.c#L1080 https://gitlab.gnome.org/GNOME/gvfs/blob/1.40.0-6-gcbc54396/client/gvfsfusedaemon.c#L1247-1346 https://gitlab.gnome.org/GNOME/gvfs/blob/1.40.0-6-gcbc54396/client/gvfsfusedaemon.c#L1399-1481 so if we would do such a change it will break a real user. Add another flag (FOPEN_STREAM) for filesystem servers to indicate that the opened handler is having stream-like semantics; does not use file position and thus the kernel is free to issue simultaneous read and write request on opened file handle. This patch together with stream_open() should be added to stable kernels starting from v3.14+. This will allow to patch OSSPD and other FUSE filesystems that provide stream-like files to return FOPEN_STREAM | FOPEN_NONSEEKABLE in open handler and this way avoid the deadlock on all kernel versions. This should work because fuse_finish_open ignores unknown open flags returned from a filesystem and so passing FOPEN_STREAM to a kernel that is not aware of this flag cannot hurt. In turn the kernel that is not aware of FOPEN_STREAM will be < v3.14 where just FOPEN_NONSEEKABLE is sufficient to implement streams without read vs write deadlock. Cc: stable@vger.kernel.org # v3.14+ Signed-off-by: Kirill Smelkov Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 2f961166e6b3595345bbc42d8764d57e82fb211d Author: Martin Wilck Date: Mon Apr 29 11:48:15 2019 +0200 dm mpath: always free attached_handler_name in parse_path() commit 940bc471780b004a5277c1931f52af363c2fc9da upstream. Commit b592211c33f7 ("dm mpath: fix attached_handler_name leak and dangling hw_handler_name pointer") fixed a memory leak for the case where setup_scsi_dh() returns failure. But setup_scsi_dh may return success and not "use" attached_handler_name if the retain_attached_hwhandler flag is not set on the map. As setup_scsi_sh properly "steals" the pointer by nullifying it, freeing it unconditionally in parse_path() is safe. Fixes: b592211c33f7 ("dm mpath: fix attached_handler_name leak and dangling hw_handler_name pointer") Cc: stable@vger.kernel.org Reported-by: Yufen Yu Signed-off-by: Martin Wilck Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 2b62694b05f5caf519d962153968412f99a9ac46 Author: Helen Koike Date: Wed May 15 13:50:54 2019 -0300 dm ioctl: fix hang in early create error condition commit 0f41fcf78849c902ddca564f99a8e23ccfc80333 upstream. The dm_early_create() function (which deals with "dm-mod.create=" kernel command line option) calls dm_hash_insert() who gets an extra reference to the md object. In case of failure, this reference wasn't being released, causing dm_destroy() to hang, thus hanging the whole boot process. Fix this by calling __hash_remove() in the error path. Fixes: 6bbc923dfcf57d ("dm: add support to directly boot to a mapped device") Cc: stable@vger.kernel.org Signed-off-by: Helen Koike Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit c318890db33cb60fed9c73c91c82606189d8fc62 Author: Mikulas Patocka Date: Tue May 7 14:28:35 2019 -0400 dm integrity: correctly calculate the size of metadata area commit 30bba430ddf737978e40561198693ba91386dac1 upstream. When we use separate devices for data and metadata, dm-integrity would incorrectly calculate the size of the metadata device as if it had 512-byte block size - and it would refuse activation with larger block size and smaller metadata device. Fix this so that it takes actual block size into account, which fixes the following reported issue: https://gitlab.com/cryptsetup/cryptsetup/issues/450 Fixes: 356d9d52e122 ("dm integrity: allow separate metadata device") Cc: stable@vger.kernel.org # v4.19+ Signed-off-by: Mikulas Patocka Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 743bcc1ac5061a59979a069bf767e19043b49783 Author: Milan Broz Date: Wed May 15 16:23:43 2019 +0200 dm crypt: move detailed message into debug level commit 7a1cd7238fde6ab367384a4a2998cba48330c398 upstream. The information about tag size should not be printed without debug info set. Also print device major:minor in the error message to identify the device instance. Also use rate limiting and debug level for info about used crypto API implementaton. This is important because during online reencryption the existing message saturates syslog (because we are moving hotzone across the whole device). Cc: stable@vger.kernel.org Signed-off-by: Milan Broz Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 9611f37caee2d7c80e655b7b64362303c78cac9b Author: Mikulas Patocka Date: Thu Apr 25 12:07:54 2019 -0400 dm delay: fix a crash when invalid device is specified commit 81bc6d150ace6250503b825d9d0c10f7bbd24095 upstream. When the target line contains an invalid device, delay_ctr() will call delay_dtr() with NULL workqueue. Attempting to destroy the NULL workqueue causes a crash. Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 7ea065d60114380f2c04c5e301198144d0bee603 Author: Helen Koike Date: Fri Apr 26 17:09:55 2019 -0300 dm init: fix max devices/targets checks commit 8e890c1ab1b1e0f765cd8da82c4dee011698a5e8 upstream. dm-init should allow up to DM_MAX_{DEVICES,TARGETS} for devices/targets, and not DM_MAX_{DEVICES,TARGETS} - 1. Fix the checks and also fix the error message when the number of devices is surpassed. Fixes: 6bbc923dfcf57d ("dm: add support to directly boot to a mapped device") Cc: stable@vger.kernel.org Signed-off-by: Helen Koike Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 29374659f6ca21dc227bd31ce262fb88d40d2bdb Author: Damien Le Moal Date: Thu Apr 18 18:03:07 2019 +0900 dm zoned: Fix zone report handling commit 7aedf75ff740a98f3683439449cd91c8662d03b2 upstream. The function blkdev_report_zones() returns success even if no zone information is reported (empty report). Empty zone reports can only happen if the report start sector passed exceeds the device capacity. The conditions for this to happen are either a bug in the caller code, or, a change in the device that forced the low level driver to change the device capacity to a value that is lower than the report start sector. This situation includes a failed disk revalidation resulting in the disk capacity being changed to 0. If this change happens while dm-zoned is in its initialization phase executing dmz_init_zones(), this function may enter an infinite loop and hang the system. To avoid this, add a check to disallow empty zone reports and bail out early. Also fix the function dmz_update_zone() to make sure that the report for the requested zone was correctly obtained. Fixes: 3b1a94c88b79 ("dm zoned: drive-managed zoned block device target") Cc: stable@vger.kernel.org Signed-off-by: Damien Le Moal Reviewed-by: Shaun Tancheff Signed-off-by: Damien Le Moal Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 9a467ab54161a3ef7ba2b68361473ff36f858f35 Author: Nikos Tsironis Date: Wed Apr 17 17:19:18 2019 +0300 dm cache metadata: Fix loading discard bitset commit e28adc3bf34e434b30e8d063df4823ba0f3e0529 upstream. Add missing dm_bitset_cursor_next() to properly advance the bitset cursor. Otherwise, the discarded state of all blocks is set according to the discarded state of the first block. Fixes: ae4a46a1f6 ("dm cache metadata: use bitset cursor api to load discard bitset") Cc: stable@vger.kernel.org Signed-off-by: Nikos Tsironis Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit a04b93692f6d137c7d0e75a6897990c6a5b959ef Author: Stefan Mätje Date: Fri Mar 29 18:07:35 2019 +0100 PCI: Work around Pericom PCIe-to-PCI bridge Retrain Link erratum commit 4ec73791a64bab25cabf16a6067ee478692e506d upstream. Due to an erratum in some Pericom PCIe-to-PCI bridges in reverse mode (conventional PCI on primary side, PCIe on downstream side), the Retrain Link bit needs to be cleared manually to allow the link training to complete successfully. If it is not cleared manually, the link training is continuously restarted and no devices below the PCI-to-PCIe bridge can be accessed. That means drivers for devices below the bridge will be loaded but won't work and may even crash because the driver is only reading 0xffff. See the Pericom Errata Sheet PI7C9X111SLB_errata_rev1.2_102711.pdf for details. Devices known as affected so far are: PI7C9X110, PI7C9X111SL, PI7C9X130. Add a new flag, clear_retrain_link, in struct pci_dev. Quirks for affected devices set this bit. Note that pcie_retrain_link() lives in aspm.c because that's currently the only place we use it, but this erratum is not specific to ASPM, and we may retrain links for other reasons in the future. Signed-off-by: Stefan Mätje [bhelgaas: apply regardless of CONFIG_PCIEASPM] Signed-off-by: Bjorn Helgaas Reviewed-by: Andy Shevchenko CC: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 989d2c419a51c36d04f20d8804b191aa3b20e654 Author: Stefan Mätje Date: Fri Mar 29 18:07:34 2019 +0100 PCI: Factor out pcie_retrain_link() function commit 86fa6a344209d9414ea962b1f1ac6ade9dd7563a upstream. Factor out pcie_retrain_link() to use for Pericom Retrain Link quirk. No functional change intended. Signed-off-by: Stefan Mätje Signed-off-by: Bjorn Helgaas Reviewed-by: Andy Shevchenko CC: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 0fcad44e68152b7151c1bba35c01d5b39f2b67f8 Author: Kazufumi Ikeda Date: Mon Mar 25 20:43:19 2019 +0100 PCI: rcar: Add the initialization of PCIe link in resume_noirq() commit be20bbcb0a8cb5597cc62b3e28d275919f3431df upstream. Reestablish the PCIe link very early in the resume process in case it went down to prevent PCI accesses from hanging the bus. Such accesses can happen early in the PCI resume process, as early as the SUSPEND_RESUME_NOIRQ step, thus the link must be reestablished in the driver resume_noirq() callback. Fixes: e015f88c368d ("PCI: rcar: Add support for R-Car H3 to pcie-rcar") Signed-off-by: Kazufumi Ikeda Signed-off-by: Gaku Inami Signed-off-by: Marek Vasut [lorenzo.pieralisi@arm.com: reformatted commit log] Signed-off-by: Lorenzo Pieralisi Reviewed-by: Simon Horman Reviewed-by: Geert Uytterhoeven Acked-by: Wolfram Sang Cc: stable@vger.kernel.org Cc: Geert Uytterhoeven Cc: Phil Edworthy Cc: Simon Horman Cc: Wolfram Sang Cc: linux-renesas-soc@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 8bdfb57a954ae94d6088fb9b2e9103502265cdb6 Author: Jisheng Zhang Date: Fri Apr 12 06:43:06 2019 +0000 PCI/AER: Change pci_aer_init() stub to return void commit 31f996efbd5a7825f4d30150469e9d110aea00e8 upstream. Commit 60ed982a4e78 ("PCI/AER: Move internal declarations to drivers/pci/pci.h") changed pci_aer_init() to return "void", but didn't change the stub for when CONFIG_PCIEAER isn't enabled. Change the stub to match. Fixes: 60ed982a4e78 ("PCI/AER: Move internal declarations to drivers/pci/pci.h") Signed-off-by: Jisheng Zhang Signed-off-by: Bjorn Helgaas CC: stable@vger.kernel.org # v4.19+ Signed-off-by: Greg Kroah-Hartman commit c1f52d4b8b6e5009a2cd966ebfabd35358b6c02c Author: Jean-Philippe Brucker Date: Mon Mar 18 16:07:18 2019 +0000 PCI: Init PCIe feature bits for managed host bridge alloc commit 6302bf3ef78dd210b5ff4a922afcb7d8eff8a211 upstream. Two functions allocate a host bridge: devm_pci_alloc_host_bridge() and pci_alloc_host_bridge(). At the moment, only the unmanaged one initializes the PCIe feature bits, which prevents from using features such as hotplug or AER on some systems, when booting with device tree. Make the initialization code common. Fixes: 02bfeb484230 ("PCI/portdrv: Simplify PCIe feature permission checking") Signed-off-by: Jean-Philippe Brucker Signed-off-by: Bjorn Helgaas CC: stable@vger.kernel.org # v4.17+ Signed-off-by: Greg Kroah-Hartman commit 3266b1098dfeeeec8ff1c10f14c50060b333812c Author: Lyude Paul Date: Tue Feb 12 17:02:30 2019 -0500 PCI: Reset Lenovo ThinkPad P50 nvgpu at boot if necessary commit e0547c81bfcfad01cbbfa93a5e66bb98ab932f80 upstream. On ThinkPad P50 SKUs with an Nvidia Quadro M1000M instead of the M2000M variant, the BIOS does not always reset the secondary Nvidia GPU during reboot if the laptop is configured in Hybrid Graphics mode. The reason is unknown, but the following steps and possibly a good bit of patience will reproduce the issue: 1. Boot up the laptop normally in Hybrid Graphics mode 2. Make sure nouveau is loaded and that the GPU is awake 3. Allow the Nvidia GPU to runtime suspend itself after being idle 4. Reboot the machine, the more sudden the better (e.g. sysrq-b may help) 5. If nouveau loads up properly, reboot the machine again and go back to step 2 until you reproduce the issue This results in some very strange behavior: the GPU will be left in exactly the same state it was in when the previously booted kernel started the reboot. This has all sorts of bad side effects: for starters, this completely breaks nouveau starting with a mysterious EVO channel failure that happens well before we've actually used the EVO channel for anything: nouveau 0000:01:00.0: disp: chid 0 mthd 0000 data 00000400 00001000 00000002 This causes a timeout trying to bring up the GR ctx: nouveau 0000:01:00.0: timeout WARNING: CPU: 0 PID: 12 at drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf100.c:1547 gf100_grctx_generate+0x7b2/0x850 [nouveau] Hardware name: LENOVO 20EQS64N0B/20EQS64N0B, BIOS N1EET82W (1.55 ) 12/18/2018 Workqueue: events_long drm_dp_mst_link_probe_work [drm_kms_helper] ... nouveau 0000:01:00.0: gr: wait for idle timeout (en: 1, ctxsw: 0, busy: 1) nouveau 0000:01:00.0: gr: wait for idle timeout (en: 1, ctxsw: 0, busy: 1) nouveau 0000:01:00.0: fifo: fault 01 [WRITE] at 0000000000008000 engine 00 [GR] client 15 [HUB/SCC_NB] reason c4 [] on channel -1 [0000000000 unknown] The GPU never manages to recover. Booting without loading nouveau causes issues as well, since the GPU starts sending spurious interrupts that cause other device's IRQs to get disabled by the kernel: irq 16: nobody cared (try booting with the "irqpoll" option) ... handlers: [<000000007faa9e99>] i801_isr [i2c_i801] Disabling IRQ #16 ... serio: RMI4 PS/2 pass-through port at rmi4-00.fn03 i801_smbus 0000:00:1f.4: Timeout waiting for interrupt! i801_smbus 0000:00:1f.4: Transaction timeout rmi4_f03 rmi4-00.fn03: rmi_f03_pt_write: Failed to write to F03 TX register (-110). i801_smbus 0000:00:1f.4: Timeout waiting for interrupt! i801_smbus 0000:00:1f.4: Transaction timeout rmi4_physical rmi4-00: rmi_driver_set_irq_bits: Failed to change enabled interrupts! This causes the touchpad and sometimes other things to get disabled. Since this happens without nouveau, we can't fix this problem from nouveau itself. Add a PCI quirk for the specific P50 variant of this GPU. Make sure the GPU is advertising NoReset- so we don't reset the GPU when the machine is in Dedicated graphics mode (where the GPU being initialized by the BIOS is normal and expected). Map the GPU MMIO space and read the magic 0x2240c register, which will have bit 1 set if the device was POSTed during a previous boot. Once we've confirmed all of this, reset the GPU and re-disable it - bringing it back to a healthy state. Link: https://bugzilla.kernel.org/show_bug.cgi?id=203003 Link: https://lore.kernel.org/lkml/20190212220230.1568-1-lyude@redhat.com Signed-off-by: Lyude Paul Signed-off-by: Bjorn Helgaas Cc: nouveau@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Cc: Karol Herbst Cc: Ben Skeggs Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 07c4e6b51ef3af8133ac6984f18bb53364c50832 Author: James Prestwood Date: Mon Jan 7 13:32:48 2019 -0800 PCI: Mark Atheros AR9462 to avoid bus reset commit 6afb7e26978da5e86e57e540fdce65c8b04f398a upstream. When using PCI passthrough with this device, the host machine locks up completely when starting the VM, requiring a hard reboot. Add a quirk to avoid bus resets on this device. Fixes: c3e59ee4e766 ("PCI: Mark Atheros AR93xx to avoid bus reset") Link: https://lore.kernel.org/linux-pci/20190107213248.3034-1-james.prestwood@linux.intel.com Signed-off-by: James Prestwood Signed-off-by: Bjorn Helgaas CC: stable@vger.kernel.org # v3.14+ Signed-off-by: Greg Kroah-Hartman commit 978bb18728d21a9233b88eb3b5f6c5a4ea8e0ed4 Author: Nikolai Kostrigin Date: Mon Apr 8 13:37:25 2019 +0300 PCI: Mark AMD Stoney Radeon R7 GPU ATS as broken commit d28ca864c493637f3c957f4ed9348a94fca6de60 upstream. ATS is broken on the Radeon R7 GPU (at least for Stoney Ridge based laptop) and causes IOMMU stalls and system failure. Disable ATS on these devices to make them usable again with IOMMU enabled. Thanks to Joerg Roedel for help. [bhelgaas: In the email thread mentioned below, Alex suspects the real problem is in sbios or iommu, so it may affect only certain systems, and it may affect other devices in those systems as well. However, per Joerg we lack the ability to debug further, so this quirk is the best we can do for now.] Link: https://bugzilla.kernel.org/show_bug.cgi?id=194521 Link: https://lore.kernel.org/lkml/20190408103725.30426-1-nickel@altlinux.org Fixes: 9b44b0b09dec ("PCI: Mark AMD Stoney GPU ATS as broken") Signed-off-by: Nikolai Kostrigin Signed-off-by: Bjorn Helgaas Acked-by: Joerg Roedel CC: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 24f7e248fff2f23d77a016016f2463047e800941 Author: Yifeng Li Date: Mon Apr 1 17:46:59 2019 +0200 fbdev: sm712fb: fix crashes and garbled display during DPMS modesetting commit f627caf55b8e735dcec8fa6538e9668632b55276 upstream. On a Thinkpad s30 (Pentium III / i440MX, Lynx3DM), blanking the display or starting the X server will crash and freeze the system, or garble the display. Experiments showed this problem can mostly be solved by adjusting the order of register writes. Also, sm712fb failed to consider the difference of clock frequency when unblanking the display, and programs the clock for SM712 to SM720. Fix them by adjusting the order of register writes, and adding an additional check for SM720 for programming the clock frequency. Signed-off-by: Yifeng Li Tested-by: Sudip Mukherjee Cc: Teddy Wang Cc: # v4.4+ Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Greg Kroah-Hartman commit c0615dcf1695ef6131e55c6170322210799a025a Author: Yifeng Li Date: Mon Apr 1 17:46:59 2019 +0200 fbdev: sm712fb: use 1024x768 by default on non-MIPS, fix garbled display commit 4ed7d2ccb7684510ec5f7a8f7ef534bc6a3d55b2 upstream. Loongson MIPS netbooks use 1024x600 LCD panels, which is the original target platform of this driver, but nearly all old x86 laptops have 1024x768. Lighting 768 panels using 600's timings would partially garble the display. Since it's not possible to distinguish them reliably, we change the default to 768, but keep 600 as-is on MIPS. Further, earlier laptops, such as IBM Thinkpad 240X, has a 800x600 LCD panel, this driver would probably garbled those display. As we don't have one for testing, the original behavior of the driver is kept as-is, but the problem has been documented is the comments. Signed-off-by: Yifeng Li Tested-by: Sudip Mukherjee Cc: Teddy Wang Cc: # v4.4+ Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Greg Kroah-Hartman commit ace34e8e233da05697705d664e343000fd518100 Author: Yifeng Li Date: Mon Apr 1 17:46:59 2019 +0200 fbdev: sm712fb: fix support for 1024x768-16 mode commit 6053d3a4793e5bde6299ac5388e76a3bf679ff65 upstream. In order to support the 1024x600 panel on Yeeloong Loongson MIPS laptop, the original 1024x768-16 table was modified to 1024x600-16, without leaving the original. It causes problem on x86 laptop as the 1024x768-16 support was still claimed but not working. Fix it by introducing the 1024x768-16 mode. Signed-off-by: Yifeng Li Tested-by: Sudip Mukherjee Cc: Teddy Wang Cc: # v4.4+ Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Greg Kroah-Hartman commit fb29479697d47ae5863d80bbb3286a706dc3fce2 Author: Yifeng Li Date: Mon Apr 1 17:46:59 2019 +0200 fbdev: sm712fb: fix crashes during framebuffer writes by correctly mapping VRAM commit 9e0e59993df0601cddb95c4f6c61aa3d5e753c00 upstream. On a Thinkpad s30 (Pentium III / i440MX, Lynx3DM), running fbtest or X will crash the machine instantly, because the VRAM/framebuffer is not mapped correctly. On SM712, the framebuffer starts at the beginning of address space, but SM720's framebuffer starts at the 1 MiB offset from the beginning. However, sm712fb fails to take this into account, as a result, writing to the framebuffer will destroy all the registers and kill the system immediately. Another problem is the driver assumes 8 MiB of VRAM for SM720, but some SM720 system, such as this IBM Thinkpad, only has 4 MiB of VRAM. Fix this problem by removing the hardcoded VRAM size, adding a function to query the amount of VRAM from register MCR76 on SM720, and adding proper framebuffer offset. Please note that the memory map may have additional problems on Big-Endian system, which is not available for testing by myself. But I highly suspect that the original code is also broken on Big-Endian machines for SM720, so at least we are not making the problem worse. More, the driver also assumed SM710/SM712 has 4 MiB of VRAM, but it has a 2 MiB version as well, and used in earlier laptops, such as IBM Thinkpad 240X, the driver would probably crash on them. I've never seen one of those machines and cannot fix it, but I have documented these problems in the comments. Signed-off-by: Yifeng Li Tested-by: Sudip Mukherjee Cc: Teddy Wang Cc: # v4.4+ Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Greg Kroah-Hartman commit 61f7fcb302a31fd3f6ca65ee879d6e828bc05dfa Author: Yifeng Li Date: Mon Apr 1 17:46:59 2019 +0200 fbdev: sm712fb: fix boot screen glitch when sm712fb replaces VGA commit ec1587d5073f29820e358f3a383850d61601d981 upstream. When the machine is booted in VGA mode, loading sm712fb would cause a glitch of random pixels shown on the screen. To prevent it from happening, we first clear the entire framebuffer, and we also need to stop calling smtcfb_setmode() during initialization, the fbdev layer will call it for us later when it's ready. Signed-off-by: Yifeng Li Tested-by: Sudip Mukherjee Cc: Teddy Wang Cc: # v4.4+ Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Greg Kroah-Hartman commit c77769b7feaffdc9febdc9ae0b0f1295cd55a699 Author: Yifeng Li Date: Mon Apr 1 17:46:58 2019 +0200 fbdev: sm712fb: fix white screen of death on reboot, don't set CR3B-CR3F commit 8069053880e0ee3a75fd6d7e0a30293265fe3de4 upstream. On a Thinkpad s30 (Pentium III / i440MX, Lynx3DM), rebooting with sm712fb framebuffer driver would cause a white screen of death on the next POST, presumably the proper timings for the LCD panel was not reprogrammed properly by the BIOS. Experiments showed a few CRTC Scratch Registers, including CRT3D, CRT3E and CRT3F may be used internally by BIOS as some flags. CRT3B is a hardware testing register, we shouldn't mess with it. CRT3C has blanking signal and line compare control, which is not needed for this driver. Stop writing to CR3B-CR3F (a.k.a CRT3B-CRT3F) registers. Even if these registers don't have side-effect on other systems, writing to them is also highly questionable. Signed-off-by: Yifeng Li Tested-by: Sudip Mukherjee Cc: Teddy Wang Cc: # v4.4+ Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Greg Kroah-Hartman commit 60c4e62cf559dc7b865a4c021c9ea376f2b05dd3 Author: Yifeng Li Date: Mon Apr 1 17:46:58 2019 +0200 fbdev: sm712fb: fix VRAM detection, don't set SR70/71/74/75 commit dcf9070595e100942c539e229dde4770aaeaa4e9 upstream. On a Thinkpad s30 (Pentium III / i440MX, Lynx3DM), the amount of Video RAM is not detected correctly by the xf86-video-siliconmotion driver. This is because sm712fb overwrites the GPR71 Scratch Pad Register, which is set by BIOS on x86 and used to indicate amount of VRAM. Other Scratch Pad Registers, including GPR70/74/75, don't have the same side-effect, but overwriting to them is still questionable, as they are not related to modesetting. Stop writing to SR70/71/74/75 (a.k.a GPR70/71/74/75). Signed-off-by: Yifeng Li Tested-by: Sudip Mukherjee Cc: Teddy Wang Cc: # v4.4+ Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Greg Kroah-Hartman commit 860bb76a02c7a439ff8e5b0fd11ca26c3f84b58a Author: Yifeng Li Date: Mon Apr 1 17:46:58 2019 +0200 fbdev: sm712fb: fix brightness control on reboot, don't set SR30 commit 5481115e25e42b9215f2619452aa99c95f08492f upstream. On a Thinkpad s30 (Pentium III / i440MX, Lynx3DM), rebooting with sm712fb framebuffer driver would cause the role of brightness up/down button to swap. Experiments showed the FPR30 register caused this behavior. Moreover, even if this register don't have side-effect on other systems, over- writing it is also highly questionable, since it was originally configurated by the motherboard manufacturer by hardwiring pull-down resistors to indicate the type of LCD panel. We should not mess with it. Stop writing to the SR30 (a.k.a FPR30) register. Signed-off-by: Yifeng Li Tested-by: Sudip Mukherjee Cc: Teddy Wang Cc: # v4.4+ Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Greg Kroah-Hartman commit 6623270e4672f67face73b9ffe24dcb59952559c Author: Ard Biesheuvel Date: Thu May 16 23:31:59 2019 +0200 fbdev/efifb: Ignore framebuffer memmap entries that lack any memory types commit f8585539df0a1527c78b5d760665c89fe1c105a9 upstream. The following commit: 38ac0287b7f4 ("fbdev/efifb: Honour UEFI memory map attributes when mapping the FB") updated the EFI framebuffer code to use memory mappings for the linear framebuffer that are permitted by the memory attributes described by the EFI memory map for the particular region, if the framebuffer happens to be covered by the EFI memory map (which is typically only the case for framebuffers in shared memory). This is required since non-x86 systems may require cacheable attributes for memory mappings that are shared with other masters (such as GPUs), and this information cannot be described by the Graphics Output Protocol (GOP) EFI protocol itself, and so we rely on the EFI memory map for this. As reported by James, this breaks some x86 systems: [ 1.173368] efifb: probing for efifb [ 1.173386] efifb: abort, cannot remap video memory 0x1d5000 @ 0xcf800000 [ 1.173395] Trying to free nonexistent resource <00000000cf800000-00000000cf9d4bff> [ 1.173413] efi-framebuffer: probe of efi-framebuffer.0 failed with error -5 The problem turns out to be that the memory map entry that describes the framebuffer has no memory attributes listed at all, and so we end up with a mem_flags value of 0x0. So work around this by ensuring that the memory map entry's attribute field has a sane value before using it to mask the set of usable attributes. Reported-by: James Hilliard Tested-by: James Hilliard Signed-off-by: Ard Biesheuvel Cc: # v4.19+ Cc: Borislav Petkov Cc: James Morse Cc: Linus Torvalds Cc: Matt Fleming Cc: Peter Jones Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-efi@vger.kernel.org Fixes: 38ac0287b7f4 ("fbdev/efifb: Honour UEFI memory map attributes when ...") Link: http://lkml.kernel.org/r/20190516213159.3530-2-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit bed41691293dfef5aff2fedebabf1df39d86fec1 Author: Dave Hansen Date: Fri Apr 19 12:47:47 2019 -0700 x86/mpx, mm/core: Fix recursive munmap() corruption commit 5a28fc94c9143db766d1ba5480cae82d856ad080 upstream. This is a bit of a mess, to put it mildly. But, it's a bug that only seems to have showed up in 4.20 but wasn't noticed until now, because nobody uses MPX. MPX has the arch_unmap() hook inside of munmap() because MPX uses bounds tables that protect other areas of memory. When memory is unmapped, there is also a need to unmap the MPX bounds tables. Barring this, unused bounds tables can eat 80% of the address space. But, the recursive do_munmap() that gets called vi arch_unmap() wreaks havoc with __do_munmap()'s state. It can result in freeing populated page tables, accessing bogus VMA state, double-freed VMAs and more. See the "long story" further below for the gory details. To fix this, call arch_unmap() before __do_unmap() has a chance to do anything meaningful. Also, remove the 'vma' argument and force the MPX code to do its own, independent VMA lookup. == UML / unicore32 impact == Remove unused 'vma' argument to arch_unmap(). No functional change. I compile tested this on UML but not unicore32. == powerpc impact == powerpc uses arch_unmap() well to watch for munmap() on the VDSO and zeroes out 'current->mm->context.vdso_base'. Moving arch_unmap() makes this happen earlier in __do_munmap(). But, 'vdso_base' seems to only be used in perf and in the signal delivery that happens near the return to userspace. I can not find any likely impact to powerpc, other than the zeroing happening a little earlier. powerpc does not use the 'vma' argument and is unaffected by its removal. I compile-tested a 64-bit powerpc defconfig. == x86 impact == For the common success case this is functionally identical to what was there before. For the munmap() failure case, it's possible that some MPX tables will be zapped for memory that continues to be in use. But, this is an extraordinarily unlikely scenario and the harm would be that MPX provides no protection since the bounds table got reset (zeroed). I can't imagine anyone doing this: ptr = mmap(); // use ptr ret = munmap(ptr); if (ret) // oh, there was an error, I'll // keep using ptr. Because if you're doing munmap(), you are *done* with the memory. There's probably no good data in there _anyway_. This passes the original reproducer from Richard Biener as well as the existing mpx selftests/. The long story: munmap() has a couple of pieces: 1. Find the affected VMA(s) 2. Split the start/end one(s) if neceesary 3. Pull the VMAs out of the rbtree 4. Actually zap the memory via unmap_region(), including freeing page tables (or queueing them to be freed). 5. Fix up some of the accounting (like fput()) and actually free the VMA itself. This specific ordering was actually introduced by: dd2283f2605e ("mm: mmap: zap pages with read mmap_sem in munmap") during the 4.20 merge window. The previous __do_munmap() code was actually safe because the only thing after arch_unmap() was remove_vma_list(). arch_unmap() could not see 'vma' in the rbtree because it was detached, so it is not even capable of doing operations unsafe for remove_vma_list()'s use of 'vma'. Richard Biener reported a test that shows this in dmesg: [1216548.787498] BUG: Bad rss-counter state mm:0000000017ce560b idx:1 val:551 [1216548.787500] BUG: non-zero pgtables_bytes on freeing mm: 24576 What triggered this was the recursive do_munmap() called via arch_unmap(). It was freeing page tables that has not been properly zapped. But, the problem was bigger than this. For one, arch_unmap() can free VMAs. But, the calling __do_munmap() has variables that *point* to VMAs and obviously can't handle them just getting freed while the pointer is still in use. I tried a couple of things here. First, I tried to fix the page table freeing problem in isolation, but I then found the VMA issue. I also tried having the MPX code return a flag if it modified the rbtree which would force __do_munmap() to re-walk to restart. That spiralled out of control in complexity pretty fast. Just moving arch_unmap() and accepting that the bonkers failure case might eat some bounds tables seems like the simplest viable fix. This was also reported in the following kernel bugzilla entry: https://bugzilla.kernel.org/show_bug.cgi?id=203123 There are some reports that this commit triggered this bug: dd2283f2605 ("mm: mmap: zap pages with read mmap_sem in munmap") While that commit certainly made the issues easier to hit, I believe the fundamental issue has been with us as long as MPX itself, thus the Fixes: tag below is for one of the original MPX commits. [ mingo: Minor edits to the changelog and the patch. ] Reported-by: Richard Biener Reported-by: H.J. Lu Signed-off-by: Dave Hansen Reviewed-by Thomas Gleixner Reviewed-by: Yang Shi Acked-by: Michael Ellerman Cc: Andrew Morton Cc: Andy Lutomirski Cc: Anton Ivanov Cc: Benjamin Herrenschmidt Cc: Borislav Petkov Cc: Guan Xuetao Cc: H. Peter Anvin Cc: Jeff Dike Cc: Linus Torvalds Cc: Michal Hocko Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Richard Weinberger Cc: Rik van Riel Cc: Vlastimil Babka Cc: linux-arch@vger.kernel.org Cc: linux-mm@kvack.org Cc: linux-um@lists.infradead.org Cc: linuxppc-dev@lists.ozlabs.org Cc: stable@vger.kernel.org Fixes: dd2283f2605e ("mm: mmap: zap pages with read mmap_sem in munmap") Link: http://lkml.kernel.org/r/20190419194747.5E1AD6DC@viggo.jf.intel.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 30e61ff2385543b8270581cbc5cff4792229ab42 Author: Nathan Chancellor Date: Thu May 16 12:49:42 2019 -0500 objtool: Allow AR to be overridden with HOSTAR commit 8ea58f1e8b11cca3087b294779bf5959bf89cc10 upstream. Currently, this Makefile hardcodes GNU ar, meaning that if it is not available, there is no way to supply a different one and the build will fail. $ make AR=llvm-ar CC=clang LD=ld.lld HOSTAR=llvm-ar HOSTCC=clang \ HOSTLD=ld.lld HOSTLDFLAGS=-fuse-ld=lld defconfig modules_prepare ... AR /out/tools/objtool/libsubcmd.a /bin/sh: 1: ar: not found ... Follow the logic of HOST{CC,LD} and allow the user to specify a different ar tool via HOSTAR (which is used elsewhere in other tools/ Makefiles). Signed-off-by: Nathan Chancellor Signed-off-by: Josh Poimboeuf Reviewed-by: Nick Desaulniers Reviewed-by: Mukesh Ojha Cc: Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/80822a9353926c38fd7a152991c6292491a9d0e8.1558028966.git.jpoimboe@redhat.com Link: https://github.com/ClangBuiltLinux/linux/issues/481 Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit b70cb36481ad41c398e1c6451e957a2155fd63c0 Author: Florian Fainelli Date: Thu May 9 11:30:47 2019 -0700 MIPS: perf: Fix build with CONFIG_CPU_BMIPS5000 enabled commit 1b1f01b653b408ebe58fec78c566d1075d285c64 upstream. arch/mips/kernel/perf_event_mipsxx.c: In function 'mipsxx_pmu_enable_event': arch/mips/kernel/perf_event_mipsxx.c:326:21: error: unused variable 'event' [-Werror=unused-variable] struct perf_event *event = container_of(evt, struct perf_event, hw); ^~~~~ Fix this by making use of IS_ENABLED() to simplify the code and avoid unnecessary ifdefery. Fixes: 84002c88599d ("MIPS: perf: Fix perf with MT counting other threads") Signed-off-by: Florian Fainelli Signed-off-by: Paul Burton Cc: linux-mips@linux-mips.org Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Arnaldo Carvalho de Melo Cc: Alexander Shishkin Cc: Jiri Olsa Cc: Namhyung Kim Cc: Ralf Baechle Cc: James Hogan Cc: linux-kernel@vger.kernel.org Cc: linux-mips@vger.kernel.org Cc: stable@vger.kernel.org # v4.18+ Signed-off-by: Greg Kroah-Hartman commit 36dcf6efc9ffc9faa94d6f6e1b0ce1b6cc299dd2 Author: Adrian Hunter Date: Fri May 10 15:41:43 2019 +0300 perf intel-pt: Fix sample timestamp wrt non-taken branches commit 1b6599a9d8e6c9f7e9b0476012383b1777f7fc93 upstream. The sample timestamp is updated to ensure that the timestamp represents the time of the sample and not a branch that the decoder is still walking towards. The sample timestamp is updated when the decoder returns, but the decoder does not return for non-taken branches. Update the sample timestamp then also. Note that commit 3f04d98e972b5 ("perf intel-pt: Improve sample timestamp") was also a stable fix and appears, for example, in v4.4 stable tree as commit a4ebb58fd124 ("perf intel-pt: Improve sample timestamp"). Signed-off-by: Adrian Hunter Cc: Jiri Olsa Cc: stable@vger.kernel.org # v4.4+ Fixes: 3f04d98e972b ("perf intel-pt: Improve sample timestamp") Link: http://lkml.kernel.org/r/20190510124143.27054-4-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 41be88f5a65044d4c9105ed211e205ae77552ac6 Author: Adrian Hunter Date: Fri May 10 15:41:42 2019 +0300 perf intel-pt: Fix improved sample timestamp commit 61b6e08dc8e3ea80b7485c9b3f875ddd45c8466b upstream. The decoder uses its current timestamp in samples. Usually that is a timestamp that has already passed, but in some cases it is a timestamp for a branch that the decoder is walking towards, and consequently hasn't reached. The intel_pt_sample_time() function decides which is which, but was not handling TNT packets exactly correctly. In the case of TNT, the timestamp applies to the first branch, so the decoder must first walk to that branch. That means intel_pt_sample_time() should return true for TNT, and this patch makes that change. However, if the first branch is a non-taken branch (i.e. a 'N'), then intel_pt_sample_time() needs to return false for subsequent taken branches in the same TNT packet. To handle that, introduce a new state INTEL_PT_STATE_TNT_CONT to distinguish the cases. Note that commit 3f04d98e972b5 ("perf intel-pt: Improve sample timestamp") was also a stable fix and appears, for example, in v4.4 stable tree as commit a4ebb58fd124 ("perf intel-pt: Improve sample timestamp"). Signed-off-by: Adrian Hunter Cc: Jiri Olsa Cc: stable@vger.kernel.org # v4.4+ Fixes: 3f04d98e972b5 ("perf intel-pt: Improve sample timestamp") Link: http://lkml.kernel.org/r/20190510124143.27054-3-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 40dc1fa62ae9921ceeb56d8e02b6ef5f4cc21a1c Author: Adrian Hunter Date: Fri May 10 15:41:41 2019 +0300 perf intel-pt: Fix instructions sampling rate commit 7ba8fa20e26eb3c0c04d747f7fd2223694eac4d5 upstream. The timestamp used to determine if an instruction sample is made, is an estimate based on the number of instructions since the last known timestamp. A consequence is that it might go backwards, which results in extra samples. Change it so that a sample is only made when the timestamp goes forwards. Note this does not affect a sampling period of 0 or sampling periods specified as a count of instructions. Example: Before: $ perf script --itrace=i10us ls 13812 [003] 2167315.222583: 3270 instructions:u: 7fac71e2e494 __GI___tunables_init+0xf4 (/lib/x86_64-linux-gnu/ld-2.28.so) ls 13812 [003] 2167315.222667: 30902 instructions:u: 7fac71e2da0f _dl_cache_libcmp+0x2f (/lib/x86_64-linux-gnu/ld-2.28.so) ls 13812 [003] 2167315.222667: 10 instructions:u: 7fac71e2d9ff _dl_cache_libcmp+0x1f (/lib/x86_64-linux-gnu/ld-2.28.so) ls 13812 [003] 2167315.222667: 8 instructions:u: 7fac71e2d9ea _dl_cache_libcmp+0xa (/lib/x86_64-linux-gnu/ld-2.28.so) ls 13812 [003] 2167315.222667: 14 instructions:u: 7fac71e2d9ea _dl_cache_libcmp+0xa (/lib/x86_64-linux-gnu/ld-2.28.so) ls 13812 [003] 2167315.222667: 6 instructions:u: 7fac71e2d9ff _dl_cache_libcmp+0x1f (/lib/x86_64-linux-gnu/ld-2.28.so) ls 13812 [003] 2167315.222667: 14 instructions:u: 7fac71e2d9ff _dl_cache_libcmp+0x1f (/lib/x86_64-linux-gnu/ld-2.28.so) ls 13812 [003] 2167315.222667: 4 instructions:u: 7fac71e2dab2 _dl_cache_libcmp+0xd2 (/lib/x86_64-linux-gnu/ld-2.28.so) ls 13812 [003] 2167315.222728: 16423 instructions:u: 7fac71e2477a _dl_map_object_deps+0x1ba (/lib/x86_64-linux-gnu/ld-2.28.so) ls 13812 [003] 2167315.222734: 12731 instructions:u: 7fac71e27938 _dl_name_match_p+0x68 (/lib/x86_64-linux-gnu/ld-2.28.so) ... After: $ perf script --itrace=i10us ls 13812 [003] 2167315.222583: 3270 instructions:u: 7fac71e2e494 __GI___tunables_init+0xf4 (/lib/x86_64-linux-gnu/ld-2.28.so) ls 13812 [003] 2167315.222667: 30902 instructions:u: 7fac71e2da0f _dl_cache_libcmp+0x2f (/lib/x86_64-linux-gnu/ld-2.28.so) ls 13812 [003] 2167315.222728: 16479 instructions:u: 7fac71e2477a _dl_map_object_deps+0x1ba (/lib/x86_64-linux-gnu/ld-2.28.so) ... Signed-off-by: Adrian Hunter Cc: Jiri Olsa Cc: stable@vger.kernel.org Fixes: f4aa081949e7b ("perf tools: Add Intel PT decoder") Link: http://lkml.kernel.org/r/20190510124143.27054-2-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 2c626991206b116b9e8f390946800ad553375c7d Author: Dmitry Osipenko Date: Fri Apr 12 01:12:48 2019 +0300 memory: tegra: Fix integer overflow on tick value calculation commit b906c056b6023c390f18347169071193fda57dde upstream. Multiplying the Memory Controller clock rate by the tick count results in an integer overflow and in result the truncated tick value is being programmed into hardware, such that the GR3D memory client performance is reduced by two times. Cc: stable Signed-off-by: Dmitry Osipenko Signed-off-by: Thierry Reding Signed-off-by: Greg Kroah-Hartman commit cd5aa12839098e275e3163a63e9fd3dc832026dd Author: Masami Hiramatsu Date: Tue May 7 22:56:02 2019 +0900 tracing: probeevent: Fix to make the type of $comm string commit 3dd1f7f24f8ceec00bbbc364c2ac3c893f0fdc4c upstream. Fix to make the type of $comm "string". If we set the other type to $comm argument, it shows meaningless value or wrong data. Currently probe events allow us to set string array type (e.g. ":string[2]"), or other digit types like x8 on $comm. But since clearly $comm is just a string data, it should not be fetched by other types including array. Link: http://lkml.kernel.org/r/155723736241.9149.14582064184468574539.stgit@devnote2 Cc: Andreas Ziegler Cc: Ingo Molnar Cc: stable@vger.kernel.org Fixes: 533059281ee5 ("tracing: probeevent: Introduce new argument fetching code") Signed-off-by: Masami Hiramatsu Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 692cbbd481524c650a6845fd5539d3906e1b291f Author: Elazar Leibovich Date: Mon Dec 31 13:58:37 2018 +0200 tracing: Fix partial reading of trace event's id file commit cbe08bcbbe787315c425dde284dcb715cfbf3f39 upstream. When reading only part of the id file, the ppos isn't tracked correctly. This is taken care by simple_read_from_buffer. Reading a single byte, and then the next byte would result EOF. While this seems like not a big deal, this breaks abstractions that reads information from files unbuffered. See for example https://github.com/golang/go/issues/29399 This code was mentioned as problematic in commit cd458ba9d5a5 ("tracing: Do not (ab)use trace_seq in event_id_read()") An example C code that show this bug is: #include #include #include #include #include #include int main(int argc, char **argv) { if (argc < 2) return 1; int fd = open(argv[1], O_RDONLY); char c; read(fd, &c, 1); printf("First %c\n", c); read(fd, &c, 1); printf("Second %c\n", c); } Then run with, e.g. sudo ./a.out /sys/kernel/debug/tracing/events/tcp/tcp_set_state/id You'll notice you're getting the first character twice, instead of the first two characters in the id file. Link: http://lkml.kernel.org/r/20181231115837.4932-1-elazar@lightbitslabs.com Cc: Orit Wasserman Cc: Oleg Nesterov Cc: Ingo Molnar Cc: stable@vger.kernel.org Fixes: 23725aeeab10b ("ftrace: provide an id file for each event") Signed-off-by: Elazar Leibovich Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit d559f0642b42806076ecfe0a8ec6047432a81d33 Author: Peter Zijlstra Date: Wed May 1 15:11:17 2019 +0200 ftrace/x86_64: Emulate call function while updating in breakpoint handler commit 9e298e8604088a600d8100a111a532a9d342af09 upstream. Nicolai Stange discovered[1] that if live kernel patching is enabled, and the function tracer started tracing the same function that was patched, the conversion of the fentry call site during the translation of going from calling the live kernel patch trampoline to the iterator trampoline, would have as slight window where it didn't call anything. As live kernel patching depends on ftrace to always call its code (to prevent the function being traced from being called, as it will redirect it). This small window would allow the old buggy function to be called, and this can cause undesirable results. Nicolai submitted new patches[2] but these were controversial. As this is similar to the static call emulation issues that came up a while ago[3]. But after some debate[4][5] adding a gap in the stack when entering the breakpoint handler allows for pushing the return address onto the stack to easily emulate a call. [1] http://lkml.kernel.org/r/20180726104029.7736-1-nstange@suse.de [2] http://lkml.kernel.org/r/20190427100639.15074-1-nstange@suse.de [3] http://lkml.kernel.org/r/3cf04e113d71c9f8e4be95fb84a510f085aa4afa.1541711457.git.jpoimboe@redhat.com [4] http://lkml.kernel.org/r/CAHk-=wh5OpheSU8Em_Q3Hg8qw_JtoijxOdPtHru6d+5K8TWM=A@mail.gmail.com [5] http://lkml.kernel.org/r/CAHk-=wjvQxY4DvPrJ6haPgAa6b906h=MwZXO6G8OtiTGe=N7_w@mail.gmail.com [ Live kernel patching is not implemented on x86_32, thus the emulate calls are only for x86_64. ] Cc: Andy Lutomirski Cc: Nicolai Stange Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: "H. Peter Anvin" Cc: the arch/x86 maintainers Cc: Josh Poimboeuf Cc: Jiri Kosina Cc: Miroslav Benes Cc: Petr Mladek Cc: Joe Lawrence Cc: Shuah Khan Cc: Konrad Rzeszutek Wilk Cc: Tim Chen Cc: Sebastian Andrzej Siewior Cc: Mimi Zohar Cc: Juergen Gross Cc: Nick Desaulniers Cc: Nayna Jain Cc: Masahiro Yamada Cc: Joerg Roedel Cc: "open list:KERNEL SELFTEST FRAMEWORK" Cc: stable@vger.kernel.org Fixes: b700e7f03df5 ("livepatch: kernel: add support for live patching") Tested-by: Nicolai Stange Reviewed-by: Nicolai Stange Reviewed-by: Masami Hiramatsu Signed-off-by: Peter Zijlstra (Intel) [ Changed to only implement emulated calls for x86_64 ] Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 988bb5e54a0d8dbc1b1865c2b99fca30367db351 Author: Peter Zijlstra Date: Wed May 1 15:11:17 2019 +0200 x86_64: Allow breakpoints to emulate call instructions commit 4b33dadf37666c0860b88f9e52a16d07bf6d0b03 upstream. In order to allow breakpoints to emulate call instructions, they need to push the return address onto the stack. The x86_64 int3 handler adds a small gap to allow the stack to grow some. Use this gap to add the return address to be able to emulate a call instruction at the breakpoint location. These helper functions are added: int3_emulate_jmp(): changes the location of the regs->ip to return there. (The next two are only for x86_64) int3_emulate_push(): to push the address onto the gap in the stack int3_emulate_call(): push the return address and change regs->ip Cc: Andy Lutomirski Cc: Nicolai Stange Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: "H. Peter Anvin" Cc: the arch/x86 maintainers Cc: Josh Poimboeuf Cc: Jiri Kosina Cc: Miroslav Benes Cc: Petr Mladek Cc: Joe Lawrence Cc: Shuah Khan Cc: Konrad Rzeszutek Wilk Cc: Tim Chen Cc: Sebastian Andrzej Siewior Cc: Mimi Zohar Cc: Juergen Gross Cc: Nick Desaulniers Cc: Nayna Jain Cc: Masahiro Yamada Cc: Joerg Roedel Cc: "open list:KERNEL SELFTEST FRAMEWORK" Cc: stable@vger.kernel.org Fixes: b700e7f03df5 ("livepatch: kernel: add support for live patching") Tested-by: Nicolai Stange Reviewed-by: Nicolai Stange Reviewed-by: Masami Hiramatsu Signed-off-by: Peter Zijlstra (Intel) [ Modified to only work for x86_64 and added comment to int3_emulate_push() ] Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit ffc4f5edb9c6da868f830119ff4ea6657f681ca8 Author: Josh Poimboeuf Date: Fri Nov 30 12:39:17 2018 -0600 x86_64: Add gap to int3 to allow for call emulation commit 2700fefdb2d9751c416ad56897e27d41e409324a upstream. To allow an int3 handler to emulate a call instruction, it must be able to push a return address onto the stack. Add a gap to the stack to allow the int3 handler to push the return address and change the return from int3 to jump straight to the emulated called function target. Link: http://lkml.kernel.org/r/20181130183917.hxmti5josgq4clti@treble Link: http://lkml.kernel.org/r/20190502162133.GX2623@hirez.programming.kicks-ass.net [ Note, this is needed to allow Live Kernel Patching to not miss calling a patched function when tracing is enabled. -- Steven Rostedt ] Cc: stable@vger.kernel.org Fixes: b700e7f03df5 ("livepatch: kernel: add support for live patching") Tested-by: Nicolai Stange Reviewed-by: Nicolai Stange Reviewed-by: Masami Hiramatsu Signed-off-by: Josh Poimboeuf Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 34de970342a5f6a850b9bd162b3b9f9eff0dd15a Author: Jeff Layton Date: Tue May 7 09:20:54 2019 -0400 ceph: flush dirty inodes before proceeding with remount commit 00abf69dd24f4444d185982379c5cc3bb7b6d1fc upstream. xfstest generic/452 was triggering a "Busy inodes after umount" warning. ceph was allowing the mount to go read-only without first flushing out dirty inodes in the cache. Ensure we sync out the filesystem before allowing a remount to proceed. Cc: stable@vger.kernel.org Link: http://tracker.ceph.com/issues/39571 Signed-off-by: Jeff Layton Reviewed-by: "Yan, Zheng" Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit 8fd5e42a3d09eb685e285d5384714b64890c81cc Author: Dmitry Osipenko Date: Thu Mar 7 01:50:07 2019 +0300 iommu/tegra-smmu: Fix invalid ASID bits on Tegra30/114 commit 43a0541e312f7136e081e6bf58f6c8a2e9672688 upstream. Both Tegra30 and Tegra114 have 4 ASID's and the corresponding bitfield of the TLB_FLUSH register differs from later Tegra generations that have 128 ASID's. In a result the PTE's are now flushed correctly from TLB and this fixes problems with graphics (randomly failing tests) on Tegra30. Cc: stable Signed-off-by: Dmitry Osipenko Acked-by: Thierry Reding Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit 7c4055601afe513121a9f76c65aa50db40f87f4a Author: Chris Packham Date: Fri May 10 21:00:25 2019 +1200 gcc-plugins: arm_ssp_per_task_plugin: Fix for older GCC < 6 commit 259799ea5a9aa099a267f3b99e1f7078bbaf5c5e upstream. Use gen_rtx_set instead of gen_rtx_SET. The former is a wrapper macro that handles the difference between GCC versions implementing the latter. This fixes the following error on my system with g++ 5.4.0 as the host compiler HOSTCXX -fPIC scripts/gcc-plugins/arm_ssp_per_task_plugin.o scripts/gcc-plugins/arm_ssp_per_task_plugin.c:42:14: error: macro "gen_rtx_SET" requires 3 arguments, but only 2 given mask)), ^ scripts/gcc-plugins/arm_ssp_per_task_plugin.c: In function ‘unsigned int arm_pertask_ssp_rtl_execute()’: scripts/gcc-plugins/arm_ssp_per_task_plugin.c:39:20: error: ‘gen_rtx_SET’ was not declared in this scope emit_insn_before(gen_rtx_SET Signed-off-by: Chris Packham Fixes: 189af4657186 ("ARM: smp: add support for per-task stack canaries") Cc: stable@vger.kernel.org Tested-by: Douglas Anderson Signed-off-by: Kees Cook Signed-off-by: Greg Kroah-Hartman commit 63ede3f7499b1ea0357af4d29b2723bc62561f6f Author: Amir Goldstein Date: Sun May 5 12:15:49 2019 +0300 fsnotify: fix unlink performance regression commit 4d8e7055a4058ee191296699803c5090e14f0dff upstream. __fsnotify_parent() has an optimization in place to avoid unneeded take_dentry_name_snapshot(). When fsnotify_nameremove() was changed not to call __fsnotify_parent(), we left out the optimization. Kernel test robot reported a 5% performance regression in concurrent unlink() workload. Reported-by: kernel test robot Link: https://lore.kernel.org/lkml/20190505062153.GG29809@shao2-debian/ Link: https://lore.kernel.org/linux-fsdevel/20190104090357.GD22409@quack2.suse.cz/ Fixes: 5f02a8776384 ("fsnotify: annotate directory entry modification events") CC: stable@vger.kernel.org Signed-off-by: Amir Goldstein Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit 8b1e66946c409d11cc17dcaa29ff1d37ddd2e275 Author: Amir Goldstein Date: Tue Jan 22 07:01:39 2019 +0200 ovl: fix missing upper fs freeze protection on copy up for ioctl commit 3428030da004a1128cbdcf93dc03e16f184d845b upstream. Generalize the helper ovl_open_maybe_copy_up() and use it to copy up file with data before FS_IOC_SETFLAGS ioctl. The FS_IOC_SETFLAGS ioctl is a bit of an odd ball in vfs, which probably caused the confusion. File may be open O_RDONLY, but ioctl modifies the file. VFS does not call mnt_want_write_file() nor lock inode mutex, but fs-specific code for FS_IOC_SETFLAGS does. So ovl_ioctl() calls mnt_want_write_file() for the overlay file, and fs-specific code calls mnt_want_write_file() for upper fs file, but there was no call for ovl_want_write() for copy up duration which prevents overlayfs from copying up on a frozen upper fs. Fixes: dab5ca8fd9dd ("ovl: add lsattr/chattr support") Cc: # v4.19 Signed-off-by: Amir Goldstein Acked-by: Vivek Goyal Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 62b91cdf1f9a63f46772766b58f5297b8a448599 Author: Liu Bo Date: Thu Apr 18 04:04:41 2019 +0800 fuse: honor RLIMIT_FSIZE in fuse_file_fallocate commit 0cbade024ba501313da3b7e5dd2a188a6bc491b5 upstream. fstests generic/228 reported this failure that fuse fallocate does not honor what 'ulimit -f' has set. This adds the necessary inode_newsize_ok() check. Signed-off-by: Liu Bo Fixes: 05ba1f082300 ("fuse: add FALLOCATE operation") Cc: # v3.5 Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 5ff78d234cd170972b3a9061e2cae6bdfc637f41 Author: Miklos Szeredi Date: Wed Apr 24 17:05:06 2019 +0200 fuse: fix writepages on 32bit commit 9de5be06d0a89ca97b5ab902694d42dfd2bb77d2 upstream. Writepage requests were cropped to i_size & 0xffffffff, which meant that mmaped writes to any file larger than 4G might be silently discarded. Fix by storing the file size in a properly sized variable (loff_t instead of size_t). Reported-by: Antonio SJ Musumeci Fixes: 6eaf4782eb09 ("fuse: writepages: crop secondary requests") Cc: # v3.13 Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 15f4d39ae4db2ba2ae261849836bc1e939a7b6bc Author: Mikulas Patocka Date: Mon Apr 1 17:46:57 2019 +0200 udlfb: introduce a rendering mutex commit babc250e278eac7b0e671bdaedf833759b43bb78 upstream. Rendering calls may be done simultaneously from the workqueue, dlfb_ops_write, dlfb_ops_ioctl, dlfb_ops_set_par and dlfb_dpy_deferred_io. The code is robust enough so that it won't crash on concurrent rendering. However, concurrent rendering may cause display corruption if the same pixel is simultaneously being rendered. In order to avoid this corruption, this patch adds a mutex around the rendering calls. Signed-off-by: Mikulas Patocka Cc: Bernie Thompson Cc: Ladislav Michl Cc: [b.zolnierkie: replace "dlfb:" with "uldfb:" in the patch summary] Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Greg Kroah-Hartman commit d6763d4f7ceb1ffdd073be74fef6d7574bcf5f31 Author: Mikulas Patocka Date: Mon Apr 1 17:46:56 2019 +0200 udlfb: fix sleeping inside spinlock commit 6b11f9d8433b471fdd3ebed232b43a4b723be6ff upstream. If a framebuffer device is used as a console, the rendering calls (copyarea, fillrect, imageblit) may be done with the console spinlock held. On udlfb, these function call dlfb_handle_damage that takes a blocking semaphore before acquiring an URB. In order to fix the bug, this patch changes the calls copyarea, fillrect and imageblit to offload USB work to a workqueue. A side effect of this patch is 3x improvement in console scrolling speed because the device doesn't have to be updated after each copyarea call. Signed-off-by: Mikulas Patocka Cc: Bernie Thompson Cc: Ladislav Michl Cc: Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Greg Kroah-Hartman commit fb869586ca942e16c6032b622efd944ade84472f Author: Mikulas Patocka Date: Mon Apr 1 17:46:56 2019 +0200 udlfb: delete the unused parameter for dlfb_handle_damage commit bd86b6c5c60711dbd4fa21bdb497a188ecb6cf63 upstream. Remove the unused parameter "data" and unused variable "ret". Signed-off-by: Mikulas Patocka Cc: Bernie Thompson Cc: Ladislav Michl Cc: Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Greg Kroah-Hartman commit 4fe70b40fed30713bcd4619660df9f4afb0f95a7 Author: Jonas Karlman Date: Sun Mar 10 12:00:45 2019 +0000 clk: rockchip: fix wrong clock definitions for rk3328 commit fb903392131a324a243c7731389277db1cd9f8df upstream. This patch fixes definition of several clock gate and select register that is wrong for rk3328 referring to the TRM and vendor kernel. Also use correct number of softrst registers. Fix clock definition for: - clk_crypto - aclk_h265 - pclk_h265 - aclk_h264 - hclk_h264 - aclk_axisram - aclk_gmac - aclk_usb3otg Fixes: fe3511ad8a1c ("clk: rockchip: add clock controller for rk3328") Cc: stable@vger.kernel.org Signed-off-by: Jonas Karlman Tested-by: Peter Geis Signed-off-by: Heiko Stuebner Signed-off-by: Greg Kroah-Hartman commit f7346dc0634cbad7fca5d951b91ad2e13f497b0b Author: Owen Chen Date: Tue Mar 5 13:05:38 2019 +0800 clk: mediatek: Disable tuner_en before change PLL rate commit be17ca6ac76a5cfd07cc3a0397dd05d6929fcbbb upstream. PLLs with tuner_en bit, such as APLL1, need to disable tuner_en before apply new frequency settings, or the new frequency settings (pcw) will not be applied. The tuner_en bit will be disabled during changing PLL rate and be restored after new settings applied. Fixes: e2f744a82d725 (clk: mediatek: Add MT2712 clock support) Cc: Signed-off-by: Owen Chen Signed-off-by: Weiyi Lu Reviewed-by: James Liao Reviewed-by: Matthias Brugger Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit 0cf3cbe969f56f564eabf78b71539b7b46a0a805 Author: Dmitry Osipenko Date: Fri Apr 12 00:48:34 2019 +0300 clk: tegra: Fix PLLM programming on Tegra124+ when PMC overrides divider commit 40db569d6769ffa3864fd1b89616b1a7323568a8 upstream. There are wrongly set parenthesis in the code that are resulting in a wrong configuration being programmed for PLLM. The original fix was made by Danny Huang in the downstream kernel. The patch was tested on Nyan Big Tegra124 chromebook, PLLM rate changing works correctly now and system doesn't lock up after changing the PLLM rate due to EMC scaling. Cc: Tested-by: Steev Klimaszewski Signed-off-by: Dmitry Osipenko Acked-By: Peter De Schrijver Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit 4c39548c7f39b9348b7b6e796d850210ef552f8e Author: Leo Yan Date: Wed Mar 20 18:05:08 2019 +0800 clk: hi3660: Mark clk_gate_ufs_subsys as critical commit 9f77a60669d13ed4ddfa6cd7374c9d88da378ffa upstream. clk_gate_ufs_subsys is a system bus clock, turning off it will introduce lockup issue during system suspend flow. Let's mark clk_gate_ufs_subsys as critical clock, thus keeps it on during system suspend and resume. Fixes: d374e6fd5088 ("clk: hisilicon: Add clock driver for hi3660 SoC") Cc: stable@vger.kernel.org Cc: Zhong Kaihua Cc: John Stultz Cc: Zhangfei Gao Suggested-by: Dong Zhang Signed-off-by: Leo Yan Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit 073a705933982ad4650ee07b09eee4361a8ce02c Author: Olga Kornievskaia Date: Tue May 7 13:41:49 2019 -0400 PNFS fallback to MDS if no deviceid found commit b1029c9bc078a6f1515f55dd993b507dcc7e3440 upstream. If we fail to find a good deviceid while trying to pnfs instead of propogating an error back fallback to doing IO to the MDS. Currently, code with fals the IO with EINVAL. Signed-off-by: Olga Kornievskaia Fixes: 8d40b0f14846f ("NFS filelayout:call GETDEVICEINFO after pnfs_layout_process completes" Cc: stable@vger.kernel.org # v4.11+ Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit cceac19918cdbe03e798e6d03a07b0f844acaa51 Author: ZhangXiaoxu Date: Mon May 6 11:57:03 2019 +0800 NFS4: Fix v4.0 client state corruption when mount commit f02f3755dbd14fb935d24b14650fff9ba92243b8 upstream. stat command with soft mount never return after server is stopped. When alloc a new client, the state of the client will be set to NFS4CLNT_LEASE_EXPIRED. When the server is stopped, the state manager will work, and accord the state to recover. But the state is NFS4CLNT_LEASE_EXPIRED, it will drain the slot table and lead other task to wait queue, until the client recovered. Then the stat command is hung. When discover server trunking, the client will renew the lease, but check the client state, it lead the client state corruption. So, we need to call state manager to recover it when detect server ip trunking. Signed-off-by: ZhangXiaoxu Cc: stable@vger.kernel.org Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit e98e6acfb23cb55068a27870d0df4a6013f88c5f Author: Leon Romanovsky Date: Mon May 6 14:23:04 2019 +0300 RDMA/ipoib: Allow user space differentiate between valid dev_port commit b79656ed44c6865e17bcd93472ec39488bcc4984 upstream. Systemd triggers the following warning during IPoIB device load: mlx5_core 0000:00:0c.0 ib0: "systemd-udevd" wants to know my dev_id. Should it look at dev_port instead? See Documentation/ABI/testing/sysfs-class-net for more info. This is caused due to user space attempt to differentiate old systems without dev_port and new systems with dev_port. In case dev_port will be zero, the systemd will try to read dev_id instead. There is no need to print a warning in such case, because it is valid situation and it is needed to ensure systemd compatibility with old kernels. Link: https://github.com/systemd/systemd/blob/master/src/udev/udev-builtin-net_id.c#L358 Cc: # 4.19 Fixes: f6350da41dc7 ("IB/ipoib: Log sysfs 'dev_id' accesses from userspace") Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 8f6e34eb485259f913919c25443d58db759dfd2b Author: Jason Gunthorpe Date: Tue Apr 16 14:07:29 2019 +0300 RDMA/mlx5: Use get_zeroed_page() for clock_info commit ddcdc368b1033e19fd3a5f750752e10e28a87826 upstream. get_zeroed_page() returns a virtual address for the page which is better than allocating a struct page and doing a permanent kmap on it. Cc: stable@vger.kernel.org Signed-off-by: Jason Gunthorpe Reviewed-by: Haggai Eran Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit e0cfe523cf5bb94fbb022f471916e87865f5e321 Author: Steve Longerbeam Date: Wed Feb 20 18:53:32 2019 -0500 media: imx: Don't register IPU subdevs/links if CSI port missing commit dee747f88167124884a918855c1f438e2f7f39e2 upstream. The second IPU internal sub-devices were being registered and links to them created even when the second IPU is not present. This is wrong for i.MX6 S/DL and i.MX53 which have only a single IPU. Fixes: e130291212df5 ("[media] media: Add i.MX media core driver") Signed-off-by: Steve Longerbeam Reviewed-by: Philipp Zabel Cc: stable@vger.kernel.org Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 5774e9e5e7511f2f936ae32dfb61fc198d98bd89 Author: Steve Longerbeam Date: Wed Feb 20 18:53:31 2019 -0500 media: imx: Rename functions that add IPU-internal subdevs commit 085b26da62211cb77622008082adff56aefa771d upstream. For the functions that add and remove the internal IPU subdevice descriptors, rename them to make clear they are the subdevs internal to the IPU. Also rename the platform data structure for the internal IPU subdevices. No functional changes. Signed-off-by: Steve Longerbeam Acked-by: Philipp Zabel Cc: stable@vger.kernel.org Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit b327f262f057814d89849c48e3d9076ebfc96539 Author: Steve Longerbeam Date: Wed Feb 20 18:53:30 2019 -0500 media: imx: Clear fwnode link struct for each endpoint iteration commit 107927fa597c99eaeee4f51865ca0956ec71b6a2 upstream. In imx_media_create_csi_of_links(), the 'struct v4l2_fwnode_link' must be cleared for each endpoint iteration, otherwise if the remote port has no "reg" property, link.remote_port will not be reset to zero. This was discovered on the i.MX53 SMD board, since the OV5642 connects directly to ipu1_csi0 and has a single source port with no "reg" property. Fixes: 621b08eabcddb ("media: staging/imx: remove static media link arrays") Signed-off-by: Steve Longerbeam Cc: stable@vger.kernel.org Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 4604e56f00d8620589a8825ec62fdf7cbfe95e21 Author: Steve Longerbeam Date: Wed Feb 20 18:53:29 2019 -0500 media: imx: csi: Allow unknown nearest upstream entities commit 904371f90b2c0c749a5ab75478c129a4682ac3d8 upstream. On i.MX6, the nearest upstream entity to the CSI can only be the CSI video muxes or the Synopsys DW MIPI CSI-2 receiver. However the i.MX53 has no CSI video muxes or a MIPI CSI-2 receiver. So allow for the nearest upstream entity to the CSI to be something other than those. Fixes: bf3cfaa712e5c ("media: staging/imx: get CSI bus type from nearest upstream entity") Signed-off-by: Steve Longerbeam Cc: stable@vger.kernel.org Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 3fea924a8199d83f40942f76f4178000bfb099a7 Author: Arnd Bergmann Date: Wed Mar 13 17:18:07 2019 -0400 media: seco-cec: fix building with RC_CORE=m commit 63604a143fe168094fbbccba56f6e3241683e399 upstream. I previously added an RC_CORE dependency here, but missed the corner case of CONFIG_VIDEO_SECO_CEC=y with CONFIG_RC_CORE=m, which still causes a link error: drivers/media/platform/seco-cec/seco-cec.o: In function `secocec_probe': seco-cec.c:(.text+0x1b8): undefined reference to `devm_rc_allocate_device' seco-cec.c:(.text+0x2e8): undefined reference to `devm_rc_register_device' drivers/media/platform/seco-cec/seco-cec.o: In function `secocec_irq_handler': seco-cec.c:(.text+0xa2c): undefined reference to `rc_keydown' Refine the dependency to disallow building the RC subdriver in this case. This is the same logic we apply in other drivers like it. Fixes: f27dd0ad6885 ("media: seco-cec: fix RC_CORE dependency") Cc: # 5.1 Signed-off-by: Arnd Bergmann Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 5090537b4d88d8790f3d819b635ccbe035979e62 Author: Janusz Krzysztofik Date: Sun Mar 24 20:21:12 2019 -0400 media: ov6650: Fix sensor possibly not detected on probe commit 933c1320847f5ed6b61a7d10f0a948aa98ccd7b0 upstream. After removal of clock_start() from before soc_camera_init_i2c() in soc_camera_probe() by commit 9aea470b399d ("[media] soc-camera: switch I2C subdevice drivers to use v4l2-clk") introduced in v3.11, the ov6650 driver could no longer probe the sensor successfully because its clock was no longer turned on in advance. The issue was initially worked around by adding that missing clock_start() equivalent to OMAP1 camera interface driver - the only user of this sensor - but a propoer fix should be rather implemented in the sensor driver code itself. Fix the issue by inserting a delay between the clock is turned on and the sensor I2C registers are read for the first time. Tested on Amstrad Delta with now out of tree but still locally maintained omap1_camera host driver. Fixes: 9aea470b399d ("[media] soc-camera: switch I2C subdevice drivers to use v4l2-clk") Signed-off-by: Janusz Krzysztofik Cc: stable@vger.kernel.org Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 9c36a718e1c31a03d605b45ed64c7c9e44adaa24 Author: Colin Ian King Date: Tue Feb 19 14:53:49 2019 +0000 phy: ti-pipe3: fix missing bit-wise or operator when assigning val commit e6577cb5103b7ca7c0204c0c86ef4af8aa6288f6 upstream. There seems to be a missing bit-wise or operator when setting val, fix this by adding it in. Fixes: 2796ceb0c18a ("phy: ti-pipe3: Update pcie phy settings") Cc: stable@vger.kernel.org # v4.19+ Signed-off-by: Colin Ian King Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Greg Kroah-Hartman commit 6e6ac425fadd7fbef65b697c53e5756213a372cf Author: Christoph Probst Date: Tue May 7 17:16:40 2019 +0200 cifs: fix strcat buffer overflow and reduce raciness in smb21_set_oplock_level() commit 6a54b2e002c9d00b398d35724c79f9fe0d9b38fb upstream. Change strcat to strncpy in the "None" case to fix a buffer overflow when cinode->oplock is reset to 0 by another thread accessing the same cinode. It is never valid to append "None" to any other message. Consolidate multiple writes to cinode->oplock to reduce raciness. Signed-off-by: Christoph Probst Reviewed-by: Pavel Shilovsky Signed-off-by: Steve French CC: Stable Signed-off-by: Greg Kroah-Hartman commit ae9711f0541c5b3e73f8f0ffa90d473c6ec0298c Author: Ronnie Sahlberg Date: Wed May 1 12:03:41 2019 +1000 cifs: fix credits leak for SMB1 oplock breaks commit d69cb728e70c40268762182a62f5d5d6fa51c5b2 upstream. For SMB1 oplock breaks we would grab one credit while sending the PDU but we would never relese the credit back since we will never receive a response to this from the server. Eventuallt this would lead to a hang once all credits are leaked. Fix this by defining a new flag CIFS_NO_SRV_RSP which indicates that there is no server response to this command and thus we need to add any credits back immediately after sending the PDU. CC: Stable #v5.0+ Signed-off-by: Ronnie Sahlberg Reviewed-by: Pavel Shilovsky Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 6e3e47a87c0260e00d3780d711141d88b08be25e Author: Hans de Goede Date: Mon Apr 22 22:41:23 2019 +0200 brcmfmac: Add DMI nvram filename quirk for ACEPC T8 and T11 mini PCs commit b1a0ba8f772d7a6dcb5aa3e856f5bd8274989ebe upstream. The ACEPC T8 and T11 mini PCs contain quite generic names in the sys_vendor and product_name DMI strings, without this patch brcmfmac will try to load: "brcmfmac43455-sdio.Default string-Default string.txt" as nvram file which is way too generic. The DMI strings on which we are matching are somewhat generic too, but "To be filled by O.E.M." is less common then "Default string" and the system-sku and bios-version strings are pretty unique. Beside the DMI strings we also check the wifi-module chip-id and revision. I'm confident that the combination of all this is unique. Both the T8 and T11 use the same wifi-module, this commit adds DMI quirks for both mini PCs pointing to brcmfmac43455-sdio.acepc-t8.txt . BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1690852 Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit 4b2e01fa83022146c4e175591ca6ed8e63537fb9 Author: Phong Tran Date: Tue Apr 30 21:56:24 2019 +0700 of: fix clang -Wunsequenced for be32_to_cpu() commit 440868661f36071886ed360d91de83bd67c73b4f upstream. Now, make the loop explicit to avoid clang warning. ./include/linux/of.h:238:37: warning: multiple unsequenced modifications to 'cell' [-Wunsequenced] r = (r << 32) | be32_to_cpu(*(cell++)); ^~ ./include/linux/byteorder/generic.h:95:21: note: expanded from macro 'be32_to_cpu' ^ ./include/uapi/linux/byteorder/little_endian.h:40:59: note: expanded from macro '__be32_to_cpu' ^ ./include/uapi/linux/swab.h:118:21: note: expanded from macro '__swab32' ___constant_swab32(x) : \ ^ ./include/uapi/linux/swab.h:18:12: note: expanded from macro '___constant_swab32' (((__u32)(x) & (__u32)0x000000ffUL) << 24) | \ ^ Signed-off-by: Phong Tran Reported-by: Nick Desaulniers Link: https://github.com/ClangBuiltLinux/linux/issues/460 Suggested-by: David Laight Reviewed-by: Nick Desaulniers Cc: stable@vger.kernel.org [robh: fix up whitespace] Signed-off-by: Rob Herring Signed-off-by: Greg Kroah-Hartman commit 4c79b1e03cb26badf2648a700f186745ba2b3922 Author: Pan Bian Date: Wed Apr 17 17:41:23 2019 +0800 p54: drop device reference count if fails to enable device commit 8149069db81853570a665f5e5648c0e526dc0e43 upstream. The function p54p_probe takes an extra reference count of the PCI device. However, the extra reference count is not dropped when it fails to enable the PCI device. This patch fixes the bug. Cc: stable@vger.kernel.org Signed-off-by: Pan Bian Acked-by: Christian Lamparter Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit a78beced9f6d349d65de89432dcd00e30dc352b4 Author: Alexander Shishkin Date: Fri May 3 11:44:34 2019 +0300 intel_th: msu: Fix single mode with IOMMU commit 4e0eaf239fb33ebc671303e2b736fa043462e2f4 upstream. Currently, the pages that are allocated for the single mode of MSC are not mapped into the device's dma space and the code is incorrectly using *_to_phys() in place of a dma address. This fails with IOMMU enabled and is otherwise bad practice. Fix the single mode buffer allocation to map the pages into the device's DMA space. Signed-off-by: Alexander Shishkin Fixes: ba82664c134e ("intel_th: Add Memory Storage Unit driver") Cc: stable@vger.kernel.org # v4.4+ Signed-off-by: Greg Kroah-Hartman commit 86261d27b2a7c58c7b8a116288202699848d7d8b Author: Al Viro Date: Fri Mar 15 22:23:19 2019 -0400 dcache: sort the freeing-without-RCU-delay mess for good. commit 5467a68cbf6884c9a9d91e2a89140afb1839c835 upstream. For lockless accesses to dentries we don't have pinned we rely (among other things) upon having an RCU delay between dropping the last reference and actually freeing the memory. On the other hand, for things like pipes and sockets we neither do that kind of lockless access, nor want to deal with the overhead of an RCU delay every time a socket gets closed. So delay was made optional - setting DCACHE_RCUACCESS in ->d_flags made sure it would happen. We tried to avoid setting it unless we knew we need it. Unfortunately, that had led to recurring class of bugs, in which we missed the need to set it. We only really need it for dentries that are created by d_alloc_pseudo(), so let's not bother with trying to be smart - just make having an RCU delay the default. The ones that do *not* get it set the replacement flag (DCACHE_NORCU) and we'd better use that sparingly. d_alloc_pseudo() is the only such user right now. FWIW, the race that finally prompted that switch had been between __lock_parent() of immediate subdirectory of what's currently the root of a disconnected tree (e.g. from open-by-handle in progress) racing with d_splice_alias() elsewhere picking another alias for the same inode, either on outright corrupted fs image, or (in case of open-by-handle on NFS) that subdirectory having been just moved on server. It's not easy to hit, so the sky is not falling, but that's not the first race on similar missed cases and the logics for settinf DCACHE_RCUACCESS has gotten ridiculously convoluted. Cc: stable@vger.kernel.org Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 3e8487c0ce9c0f6cc9608fb91562aa15de34696b Author: Christoph Hellwig Date: Thu Apr 4 18:56:10 2019 +0200 md: add a missing endianness conversion in check_sb_changes commit ed4d0a4ea11e19863952ac6a7cea3bbb27ccd452 upstream. The on-disk value is little endian and we need to convert it to native endian before storing the value in the in-core structure. Fixes: 7564beda19b36 ("md-cluster/raid10: support add disk under grow mode") Cc: # 4.20+ Acked-by: Guoqing Jiang Signed-off-by: Christoph Hellwig Signed-off-by: Song Liu Signed-off-by: Greg Kroah-Hartman commit ad58eb2c5cba97ddf50471c9b6d5d48e80dd0f7a Author: Yufen Yu Date: Tue Apr 2 14:22:14 2019 +0800 md: add mddev->pers to avoid potential NULL pointer dereference commit ee37e62191a59d253fc916b9fc763deb777211e2 upstream. When doing re-add, we need to ensure rdev->mddev->pers is not NULL, which can avoid potential NULL pointer derefence in fallowing add_bound_rdev(). Fixes: a6da4ef85cef ("md: re-add a failed disk") Cc: Xiao Ni Cc: NeilBrown Cc: # 4.4+ Reviewed-by: NeilBrown Signed-off-by: Yufen Yu Signed-off-by: Song Liu Signed-off-by: Greg Kroah-Hartman commit ae586c606aeebd9bbfab181b08c55daede4c0500 Author: NeilBrown Date: Fri Mar 29 10:46:17 2019 -0700 md: batch flush requests. commit 2bc13b83e6298486371761de503faeffd15b7534 upstream. Currently if many flush requests are submitted to an md device is quick succession, they are serialized and can take a long to process them all. We don't really need to call flush all those times - a single flush call can satisfy all requests submitted before it started. So keep track of when the current flush started and when it finished, allow any pending flush that was requested before the flush started to complete without waiting any more. Test results from Xiao: Test is done on a raid10 device which is created by 4 SSDs. The tool is dbench. 1. The latest linux stable kernel Operation Count AvgLat MaxLat -------------------------------------------------- Deltree 768 10.509 78.305 Flush 2078376 0.013 10.094 Close 21787697 0.019 18.821 LockX 96580 0.007 3.184 Mkdir 384 0.008 0.062 Rename 1255883 0.191 23.534 ReadX 46495589 0.020 14.230 WriteX 14790591 7.123 60.706 Unlink 5989118 0.440 54.551 UnlockX 96580 0.005 2.736 FIND_FIRST 10393845 0.042 12.079 SET_FILE_INFORMATION 2415558 0.129 10.088 QUERY_FILE_INFORMATION 4711725 0.005 8.462 QUERY_PATH_INFORMATION 26883327 0.032 21.715 QUERY_FS_INFORMATION 4929409 0.010 8.238 NTCreateX 29660080 0.100 53.268 Throughput 1034.88 MB/sec (sync open) 128 clients 128 procs max_latency=60.712 ms 2. With patch1 "Revert "MD: fix lock contention for flush bios"" Operation Count AvgLat MaxLat -------------------------------------------------- Deltree 256 8.326 36.761 Flush 693291 3.974 180.269 Close 7266404 0.009 36.929 LockX 32160 0.006 0.840 Mkdir 128 0.008 0.021 Rename 418755 0.063 29.945 ReadX 15498708 0.007 7.216 WriteX 4932310 22.482 267.928 Unlink 1997557 0.109 47.553 UnlockX 32160 0.004 1.110 FIND_FIRST 3465791 0.036 7.320 SET_FILE_INFORMATION 805825 0.015 1.561 QUERY_FILE_INFORMATION 1570950 0.005 2.403 QUERY_PATH_INFORMATION 8965483 0.013 14.277 QUERY_FS_INFORMATION 1643626 0.009 3.314 NTCreateX 9892174 0.061 41.278 Throughput 345.009 MB/sec (sync open) 128 clients 128 procs max_latency=267.939 m 3. With patch1 and patch2 Operation Count AvgLat MaxLat -------------------------------------------------- Deltree 768 9.570 54.588 Flush 2061354 0.666 15.102 Close 21604811 0.012 25.697 LockX 95770 0.007 1.424 Mkdir 384 0.008 0.053 Rename 1245411 0.096 12.263 ReadX 46103198 0.011 12.116 WriteX 14667988 7.375 60.069 Unlink 5938936 0.173 30.905 UnlockX 95770 0.005 4.147 FIND_FIRST 10306407 0.041 11.715 SET_FILE_INFORMATION 2395987 0.048 7.640 QUERY_FILE_INFORMATION 4672371 0.005 9.291 QUERY_PATH_INFORMATION 26656735 0.018 19.719 QUERY_FS_INFORMATION 4887940 0.010 7.654 NTCreateX 29410811 0.059 28.551 Throughput 1026.21 MB/sec (sync open) 128 clients 128 procs max_latency=60.075 ms Cc: # v4.19+ Tested-by: Xiao Ni Signed-off-by: NeilBrown Signed-off-by: Song Liu Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 2fc0111ffd7418694cd4190d1ce00375c95d1939 Author: NeilBrown Date: Fri Mar 29 10:46:16 2019 -0700 Revert "MD: fix lock contention for flush bios" commit 4bc034d35377196c854236133b07730a777c4aba upstream. This reverts commit 5a409b4f56d50b212334f338cb8465d65550cd85. This patch has two problems. 1/ it make multiple calls to submit_bio() from inside a make_request_fn. The bios thus submitted will be queued on current->bio_list and not submitted immediately. As the bios are allocated from a mempool, this can theoretically result in a deadlock - all the pool of requests could be in various ->bio_list queues and a subsequent mempool_alloc could block waiting for one of them to be released. 2/ It aims to handle a case when there are many concurrent flush requests. It handles this by submitting many requests in parallel - all of which are identical and so most of which do nothing useful. It would be more efficient to just send one lower-level request, but allow that to satisfy multiple upper-level requests. Fixes: 5a409b4f56d5 ("MD: fix lock contention for flush bios") Cc: # v4.19+ Tested-by: Xiao Ni Signed-off-by: NeilBrown Signed-off-by: Song Liu Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit bb2601cb4125dd07f341384d056f269a2617111a Author: Paul Moore Date: Fri Apr 19 14:55:12 2019 -0400 proc: prevent changes to overridden credentials commit 35a196bef449b5824033865b963ed9a43fb8c730 upstream. Prevent userspace from changing the the /proc/PID/attr values if the task's credentials are currently overriden. This not only makes sense conceptually, it also prevents some really bizarre error cases caused when trying to commit credentials to a task with overridden credentials. Cc: Reported-by: "chengjian (D)" Signed-off-by: Paul Moore Acked-by: John Johansen Acked-by: James Morris Acked-by: Casey Schaufler Signed-off-by: Greg Kroah-Hartman commit c733b76d25a7d2afd6da8dea95c5acab24dc1591 Author: Hou Tao Date: Mon Apr 22 21:23:21 2019 +0800 brd: re-enable __GFP_HIGHMEM in brd_insert_page() commit f6b50160a06d4a0d6a3999ab0c5aec4f52dba248 upstream. __GFP_HIGHMEM is disabled if dax is enabled on brd, however dax support for brd has been removed since commit (7a862fbbdec6 "brd: remove dax support"), so restore __GFP_HIGHMEM in brd_insert_page(). Also remove the no longer applicable comments about DAX and highmem. Cc: stable@vger.kernel.org Fixes: 7a862fbbdec6 ("brd: remove dax support") Signed-off-by: Hou Tao Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 0eb3a49df5aef517a973e2d854a3faaf55f4ca8c Author: Alexander Shishkin Date: Wed Apr 17 10:35:35 2019 +0300 stm class: Fix channel bitmap on 32-bit systems commit 51e0f227812ed81a368de54157ebe14396b4be03 upstream. Commit 7bd1d4093c2f ("stm class: Introduce an abstraction for System Trace Module devices") naively calculates the channel bitmap size in 64-bit chunks regardless of the size of underlying unsigned long, making the bitmap half as big on a 32-bit system. This leads to an out of bounds access with the upper half of the bitmap. Fix this by using BITS_TO_LONGS. While at it, convert to using struct_size() for the total size calculation of the master struct. Signed-off-by: Alexander Shishkin Fixes: 7bd1d4093c2f ("stm class: Introduce an abstraction for System Trace Module devices") Reported-by: Mulu He Cc: stable@vger.kernel.org # v4.4+ Signed-off-by: Greg Kroah-Hartman commit ec1db10094cbb4d76c8afad17bb72e0e7dd199b7 Author: Tingwei Zhang Date: Wed Apr 17 10:35:34 2019 +0300 stm class: Fix channel free in stm output free path commit ee496da4c3915de3232b5f5cd20e21ae3e46fe8d upstream. Number of free masters is not set correctly in stm free path. Fix this by properly adding the number of output channels before setting them to 0 in stm_output_disclaim(). Currently it is equivalent to doing nothing since master->nr_free is incremented by 0. Fixes: 7bd1d4093c2f ("stm class: Introduce an abstraction for System Trace Module devices") Signed-off-by: Tingwei Zhang Signed-off-by: Sai Prakash Ranjan Cc: stable@vger.kernel.org # v4.4 Signed-off-by: Alexander Shishkin Signed-off-by: Greg Kroah-Hartman commit 458cb8489966a7c399faf3c476b2e14084f30de5 Author: Helge Deller Date: Sun May 5 23:54:34 2019 +0200 parisc: Rename LEVEL to PA_ASM_LEVEL to avoid name clash with DRBD code commit 1829dda0e87f4462782ca81be474c7890efe31ce upstream. LEVEL is a very common word, and now after many years it suddenly clashed with another LEVEL define in the DRBD code. Rename it to PA_ASM_LEVEL instead. Reported-by: kbuild test robot Signed-off-by: Helge Deller Cc: Signed-off-by: Greg Kroah-Hartman commit 1af64ba7b3538b7494c92cfb36a06802fa60e16c Author: Helge Deller Date: Sun May 5 23:55:02 2019 +0200 parisc: Use PA_ASM_LEVEL in boot code commit bdca5d64ee92abeacd6dada0bc6f6f8e6350dd67 upstream. The LEVEL define clashed with the DRBD code. Reported-by: kbuild test robot Signed-off-by: Helge Deller Cc: # v4.14+ Signed-off-by: Greg Kroah-Hartman commit 5ac8e698528149bb1618111d64e22bd8bb784256 Author: Helge Deller Date: Wed May 1 14:59:58 2019 +0200 parisc: Allow live-patching of __meminit functions commit d19a12906e5e558c0f6b6cfece7b7caf1012ef95 upstream. When making the text sections writeable with set_kernel_text_rw(1), include all text sections including those in the __init section. Otherwise functions marked with __meminit will stay read-only. Signed-off-by: Helge Deller Cc: # 4.20+ Signed-off-by: Greg Kroah-Hartman commit 7049b323c0646531647c285843b618f5d936041d Author: Helge Deller Date: Sat Apr 27 23:57:49 2019 +0200 parisc: Add memory barrier to asm pdc and sync instructions commit 2d94a832e246ac00fd32eec241e6f1aa6fbc5700 upstream. Add compiler memory barriers to ensure the compiler doesn't reorder memory operations around these instructions. Cc: stable@vger.kernel.org # v4.20+ Fixes: 3847dab77421 ("parisc: Add alternative coding infrastructure") Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit e7be05c847d314df0d3864a6a0f30a5d026c6ceb Author: Helge Deller Date: Tue Apr 2 12:17:08 2019 +0200 parisc: Skip registering LED when running in QEMU commit b438749044356dd1329c45e9b5a9377b6ea13eb2 upstream. No need to spend CPU cycles when we run on QEMU. Signed-off-by: Helge Deller CC: stable@vger.kernel.org # v4.9+ Signed-off-by: Greg Kroah-Hartman commit 2e9549e198e005fa44f0476c8cf895274152d5ba Author: John David Anglin Date: Sun Apr 21 19:47:17 2019 -0400 parisc: Add memory clobber to TLB purges commit 44224bdb99150ad17cf394973b25736cb92c246a upstream. The pdtlb and pitlb instructions are strongly ordered. The asms invoking these instructions should be compiler memory barriers to ensure the compiler doesn't reorder memory operations around these instructions. Signed-off-by: John David Anglin CC: stable@vger.kernel.org # v4.20+ Fixes: 3847dab77421 ("parisc: Add alternative coding infrastructure") Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit a93f69fd77b9e0985728999957a5890b82f44bbc Author: Helge Deller Date: Sat Apr 6 16:45:14 2019 +0200 parisc: Export running_on_qemu symbol for modules commit 3e1120f4b57bc12437048494ab56648edaa5b57d upstream. Signed-off-by: Helge Deller CC: stable@vger.kernel.org # v4.9+ Signed-off-by: Greg Kroah-Hartman commit 4c0642c4b7a032bc78f3b5eff4b1a977fbc2d784 Author: Steve Twiss Date: Mon Mar 18 16:17:57 2019 +0000 regulator: core: fix error path for regulator_set_voltage_unlocked commit 70b464918e5331e488058870fcc6821d54c4e541 upstream. During several error paths in the function regulator_set_voltage_unlocked() the value of 'ret' can take on negative error values. However, in calls that go through the 'goto out' statement, this return value is lost and return 0 is used instead, indicating a 'pass'. There are several cases where this function should legitimately return a fail instead of a pass: one such case includes constraints check during voltage selection in the call to regulator_check_voltage(), which can have -EINVAL for the case when an unsupported voltage is incorrectly requested. In that case, -22 is expected as the return value, not 0. Fixes: 9243a195be7a ("regulator: core: Change voltage setting path") Cc: stable Signed-off-by: Steve Twiss Reviewed-by: Dmitry Osipenko Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 94ba80afbef465ff756e0cf0b62555853c9f5ad5 Author: Ming Lei Date: Tue Apr 30 09:52:25 2019 +0800 blk-mq: free hw queue's resource in hctx's release handler commit c7e2d94b3d1634988a95ac4d77a72dc7487ece06 upstream. Once blk_cleanup_queue() returns, tags shouldn't be used any more, because blk_mq_free_tag_set() may be called. Commit 45a9c9d909b2 ("blk-mq: Fix a use-after-free") fixes this issue exactly. However, that commit introduces another issue. Before 45a9c9d909b2, we are allowed to run queue during cleaning up queue if the queue's kobj refcount is held. After that commit, queue can't be run during queue cleaning up, otherwise oops can be triggered easily because some fields of hctx are freed by blk_mq_free_queue() in blk_cleanup_queue(). We have invented ways for addressing this kind of issue before, such as: 8dc765d438f1 ("SCSI: fix queue cleanup race before queue initialization is done") c2856ae2f315 ("blk-mq: quiesce queue before freeing queue") But still can't cover all cases, recently James reports another such kind of issue: https://marc.info/?l=linux-scsi&m=155389088124782&w=2 This issue can be quite hard to address by previous way, given scsi_run_queue() may run requeues for other LUNs. Fixes the above issue by freeing hctx's resources in its release handler, and this way is safe becasue tags isn't needed for freeing such hctx resource. This approach follows typical design pattern wrt. kobject's release handler. Cc: Dongli Zhang Cc: James Smart Cc: Bart Van Assche Cc: linux-scsi@vger.kernel.org, Cc: Martin K . Petersen , Cc: Christoph Hellwig , Cc: James E . J . Bottomley , Reported-by: James Smart Fixes: 45a9c9d909b2 ("blk-mq: Fix a use-after-free") Cc: stable@vger.kernel.org Reviewed-by: Hannes Reinecke Reviewed-by: Christoph Hellwig Tested-by: James Smart Signed-off-by: Ming Lei Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 9bc7fcde5d97e23ebea699c255e0a6f922f63df6 Author: Saeed Mahameed Date: Tue May 7 12:59:38 2019 -0700 net/mlx5e: Fix ethtool rxfh commands when CONFIG_MLX5_EN_RXNFC is disabled [ Upstream commit 8f0916c6dc5cd5e3bc52416fa2a9ff4075080180 ] ethtool user spaces needs to know ring count via ETHTOOL_GRXRINGS when executing (ethtool -x) which is retrieved via ethtool get_rxnfc callback, in mlx5 this callback is disabled when CONFIG_MLX5_EN_RXNFC=n. This patch allows only ETHTOOL_GRXRINGS command on mlx5e_get_rxnfc() when CONFIG_MLX5_EN_RXNFC is disabled, so ethtool -x will continue working. Fixes: fe6d86b3c316 ("net/mlx5e: Add CONFIG_MLX5_EN_RXNFC for ethtool rx nfc") Signed-off-by: Saeed Mahameed Signed-off-by: Greg Kroah-Hartman commit abf7b7f7cba6daf07048a9d99083ee60ee60d2a5 Author: Saeed Mahameed Date: Tue May 7 13:15:20 2019 -0700 net/mlx5: Imply MLXFW in mlx5_core [ Upstream commit bad861f31bb15a99becef31aab59640eaeb247e2 ] mlxfw can be compiled as external module while mlx5_core can be builtin, in such case mlx5 will act like mlxfw is disabled. Since mlxfw is just a service library for mlx* drivers, imply it in mlx5_core to make it always reachable if it was enabled. Fixes: 3ffaabecd1a1 ("net/mlx5e: Support the flash device ethtool callback") Signed-off-by: Saeed Mahameed Signed-off-by: Greg Kroah-Hartman commit feded96a7ddbfd60e6e8383f3d59a1cdfa1a97b3 Author: Dmytro Linkin Date: Thu May 2 15:21:38 2019 +0000 net/mlx5e: Additional check for flow destination comparison [ Upstream commit c979c445a88e1c9dd7d8f90838c10456ae4ecd09 ] Flow destination comparison has an inaccuracy: code see no difference between same vf ports, which belong to different pfs. Example: If start ping from VF0 (PF1) to VF1 (PF1) and mirror all traffic to VF0 (PF2), icmp reply to VF0 (PF1) and mirrored flow to VF0 (PF2) would be determined as same destination. It lead to creating flow handler with rule nodes, which not added to node tree. When later driver try to delete this flow rules we got kernel crash. Add comparison of vhca_id field to avoid this. Fixes: 1228e912c934 ("net/mlx5: Consider encapsulation properties when comparing destinations") Signed-off-by: Dmytro Linkin Reviewed-by: Roi Dayan Reviewed-by: Vlad Buslov Signed-off-by: Saeed Mahameed Signed-off-by: Greg Kroah-Hartman commit 94e359d9ff8dc918b1bf064069546eeb89305a65 Author: Dmytro Linkin Date: Thu Apr 25 08:52:02 2019 +0000 net/mlx5e: Add missing ethtool driver info for representors [ Upstream commit cf83c8fdcd4756644595521f48748ec22f7efede ] For all representors added firmware version info to show in ethtool driver info. For uplink representor, because only it is tied to the pci device sysfs, added pci bus info. Fixes: ff9b85de5d5d ("net/mlx5e: Add some ethtool port control entries to the uplink rep netdev") Signed-off-by: Dmytro Linkin Reviewed-by: Gavi Teitz Reviewed-by: Roi Dayan Signed-off-by: Saeed Mahameed Signed-off-by: Greg Kroah-Hartman commit 8c12593ba25b375aadb50b9208fdc0ffcfab09e4 Author: Jorge E. Moreira Date: Thu May 16 13:51:07 2019 -0700 vsock/virtio: Initialize core virtio vsock before registering the driver [ Upstream commit ba95e5dfd36647622d8897a2a0470dde60e59ffd ] Avoid a race in which static variables in net/vmw_vsock/af_vsock.c are accessed (while handling interrupts) before they are initialized. [ 4.201410] BUG: unable to handle kernel paging request at ffffffffffffffe8 [ 4.207829] IP: vsock_addr_equals_addr+0x3/0x20 [ 4.211379] PGD 28210067 P4D 28210067 PUD 28212067 PMD 0 [ 4.211379] Oops: 0000 [#1] PREEMPT SMP PTI [ 4.211379] Modules linked in: [ 4.211379] CPU: 1 PID: 30 Comm: kworker/1:1 Not tainted 4.14.106-419297-gd7e28cc1f241 #1 [ 4.211379] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014 [ 4.211379] Workqueue: virtio_vsock virtio_transport_rx_work [ 4.211379] task: ffffa3273d175280 task.stack: ffffaea1800e8000 [ 4.211379] RIP: 0010:vsock_addr_equals_addr+0x3/0x20 [ 4.211379] RSP: 0000:ffffaea1800ebd28 EFLAGS: 00010286 [ 4.211379] RAX: 0000000000000002 RBX: 0000000000000000 RCX: ffffffffb94e42f0 [ 4.211379] RDX: 0000000000000400 RSI: ffffffffffffffe0 RDI: ffffaea1800ebdd0 [ 4.211379] RBP: ffffaea1800ebd58 R08: 0000000000000001 R09: 0000000000000001 [ 4.211379] R10: 0000000000000000 R11: ffffffffb89d5d60 R12: ffffaea1800ebdd0 [ 4.211379] R13: 00000000828cbfbf R14: 0000000000000000 R15: ffffaea1800ebdc0 [ 4.211379] FS: 0000000000000000(0000) GS:ffffa3273fd00000(0000) knlGS:0000000000000000 [ 4.211379] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 4.211379] CR2: ffffffffffffffe8 CR3: 000000002820e001 CR4: 00000000001606e0 [ 4.211379] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 4.211379] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 4.211379] Call Trace: [ 4.211379] ? vsock_find_connected_socket+0x6c/0xe0 [ 4.211379] virtio_transport_recv_pkt+0x15f/0x740 [ 4.211379] ? detach_buf+0x1b5/0x210 [ 4.211379] virtio_transport_rx_work+0xb7/0x140 [ 4.211379] process_one_work+0x1ef/0x480 [ 4.211379] worker_thread+0x312/0x460 [ 4.211379] kthread+0x132/0x140 [ 4.211379] ? process_one_work+0x480/0x480 [ 4.211379] ? kthread_destroy_worker+0xd0/0xd0 [ 4.211379] ret_from_fork+0x35/0x40 [ 4.211379] Code: c7 47 08 00 00 00 00 66 c7 07 28 00 c7 47 08 ff ff ff ff c7 47 04 ff ff ff ff c3 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 00 8b 47 08 <3b> 46 08 75 0a 8b 47 04 3b 46 04 0f 94 c0 c3 31 c0 c3 90 66 2e [ 4.211379] RIP: vsock_addr_equals_addr+0x3/0x20 RSP: ffffaea1800ebd28 [ 4.211379] CR2: ffffffffffffffe8 [ 4.211379] ---[ end trace f31cc4a2e6df3689 ]--- [ 4.211379] Kernel panic - not syncing: Fatal exception in interrupt [ 4.211379] Kernel Offset: 0x37000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) [ 4.211379] Rebooting in 5 seconds.. Fixes: 22b5c0b63f32 ("vsock/virtio: fix kernel panic after device hot-unplug") Cc: Stefan Hajnoczi Cc: Stefano Garzarella Cc: "David S. Miller" Cc: kvm@vger.kernel.org Cc: virtualization@lists.linux-foundation.org Cc: netdev@vger.kernel.org Cc: kernel-team@android.com Cc: stable@vger.kernel.org [4.9+] Signed-off-by: Jorge E. Moreira Reviewed-by: Stefano Garzarella Reviewed-by: Stefan Hajnoczi Acked-by: Stefan Hajnoczi Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 3dd665b049dbbf1eb39f58a4930fa71badfb14ce Author: Bodong Wang Date: Mon Apr 29 09:56:18 2019 -0500 net/mlx5: Fix peer pf disable hca command [ Upstream commit dd06486710d251140edc86ec3bbef0c25dcec1cb ] The command was mistakenly using enable_hca in embedded CPU field. Fixes: 22e939a91dcb (net/mlx5: Update enable HCA dependency) Signed-off-by: Bodong Wang Reported-by: Alex Rosenbaum Signed-off-by: Alex Rosenbaum Reviewed-by: Daniel Jurgens Signed-off-by: Saeed Mahameed Signed-off-by: Greg Kroah-Hartman commit cd9962cd291ff4732f681c24602b925c5a1ef095 Author: Jianbo Liu Date: Tue May 14 21:18:50 2019 +0100 net/mlx5e: Fix calling wrong function to get inner vlan key and mask [ Upstream commit 12d5cbf89a6599f6bbd7b373dba0e74b5bd9c505 ] When flow_rule_match_XYZ() functions were first introduced, flow_rule_match_cvlan() for inner vlan is missing. In mlx5_core driver, to get inner vlan key and mask, flow_rule_match_vlan() is just called, which is wrong because it obtains outer vlan information by FLOW_DISSECTOR_KEY_VLAN. This commit fixes this by changing to call flow_rule_match_cvlan() after it's added. Fixes: 8f2566225ae2 ("flow_offload: add flow_rule and flow_match structures and use them") Signed-off-by: Jianbo Liu Signed-off-by: Edward Cree Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 1da630670facd8f16984c0fb7b32f001665fbbf5 Author: Edward Cree Date: Tue May 14 21:18:12 2019 +0100 flow_offload: support CVLAN match [ Upstream commit bae9ed69029c7d499c57485593b2faae475fd704 ] Plumb it through from the flow_dissector. Signed-off-by: Edward Cree Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 6bc867d1387f6a857f21630e6bf0b74a32e881a9 Author: Vadim Pasternak Date: Sat May 18 18:58:29 2019 +0300 mlxsw: core: Prevent reading unsupported slave address from SFP EEPROM [ Upstream commit f1436c8036fa3632b2ee78841cf5184b7ef0ad87 ] Prevent reading unsupported slave address from SFP EEPROM by testing Diagnostic Monitoring Type byte in EEPROM. Read only page zero of EEPROM, in case this byte is zero. If some SFP transceiver does not support Digital Optical Monitoring (DOM), reading SFP EEPROM slave address 0x51 could return an error. Availability of DOM support is verified by reading from zero page Diagnostic Monitoring Type byte describing how diagnostic monitoring is implemented by transceiver. If bit 6 of this byte is set, it indicates that digital diagnostic monitoring has been implemented. Otherwise it is not and transceiver could fail to reply to transaction for slave address 0x51 [1010001X (A2h)], which is used to access measurements page. Such issue has been observed when reading cable MCP2M00-xxxx, MCP7F00-xxxx, and few others. Fixes: 2ea109039cd3 ("mlxsw: spectrum: Add support for access cable info via ethtool") Fixes: 4400081b631a ("mlxsw: spectrum: Fix EEPROM access in case of SFP/SFP+") Signed-off-by: Vadim Pasternak Acked-by: Jiri Pirko Signed-off-by: Ido Schimmel Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit c89c9af998fef2af4e5b2b35fb723693f17e05ef Author: Vadim Pasternak Date: Sat May 18 18:58:28 2019 +0300 mlxsw: core: Prevent QSFP module initialization for old hardware [ Upstream commit c52ecff7e6439ca8c9b03282e8869a005aa94831 ] Old Mellanox silicons, like switchx-2, switch-ib do not support reading QSFP modules temperature through MTMP register. Attempt to access this register on systems equipped with the this kind of silicon will cause initialization flow failure. Test for hardware resource capability is added in order to distinct between old and new silicon - old silicons do not have such capability. Fixes: 6a79507cfe94 ("mlxsw: core: Extend thermal module with per QSFP module thermal zones") Fixes: 5c42eaa07bd0 ("mlxsw: core: Extend hwmon interface with QSFP module temperature attributes") Reported-by: Jiri Pirko Signed-off-by: Vadim Pasternak Signed-off-by: Ido Schimmel Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 2d08f204328acaf85ac2c6fe5d5d9d4760f12e13 Author: Junwei Hu Date: Fri May 17 19:27:34 2019 +0800 tipc: fix modprobe tipc failed after switch order of device registration [ Upstream commit 532b0f7ece4cb2ffd24dc723ddf55242d1188e5e ] Error message printed: modprobe: ERROR: could not insert 'tipc': Address family not supported by protocol. when modprobe tipc after the following patch: switch order of device registration, commit 7e27e8d6130c ("tipc: switch order of device registration to fix a crash") Because sock_create_kern(net, AF_TIPC, ...) is called by tipc_topsrv_create_listener() in the initialization process of tipc_net_ops, tipc_socket_init() must be execute before that. I move tipc_socket_init() into function tipc_init_net(). Fixes: 7e27e8d6130c ("tipc: switch order of device registration to fix a crash") Signed-off-by: Junwei Hu Reported-by: Wang Wang Reviewed-by: Kang Zhou Reviewed-by: Suanming Mou Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 7d29c9ad0ed525c1b10e29cfca4fb1eece1e93fb Author: Stefano Garzarella Date: Fri May 17 16:45:43 2019 +0200 vsock/virtio: free packets during the socket release [ Upstream commit ac03046ece2b158ebd204dfc4896fd9f39f0e6c8 ] When the socket is released, we should free all packets queued in the per-socket list in order to avoid a memory leak. Signed-off-by: Stefano Garzarella Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 4f747a79d52821fc8b0602ee5bdf380fab978e20 Author: Junwei Hu Date: Thu May 16 10:51:15 2019 +0800 tipc: switch order of device registration to fix a crash [ Upstream commit 7e27e8d6130c5e88fac9ddec4249f7f2337fe7f8 ] When tipc is loaded while many processes try to create a TIPC socket, a crash occurs: PANIC: Unable to handle kernel paging request at virtual address "dfff20000000021d" pc : tipc_sk_create+0x374/0x1180 [tipc] lr : tipc_sk_create+0x374/0x1180 [tipc] Exception class = DABT (current EL), IL = 32 bits Call trace: tipc_sk_create+0x374/0x1180 [tipc] __sock_create+0x1cc/0x408 __sys_socket+0xec/0x1f0 __arm64_sys_socket+0x74/0xa8 ... This is due to race between sock_create and unfinished register_pernet_device. tipc_sk_insert tries to do "net_generic(net, tipc_net_id)". but tipc_net_id is not initialized yet. So switch the order of the two to close the race. This can be reproduced with multiple processes doing socket(AF_TIPC, ...) and one process doing module removal. Fixes: a62fbccecd62 ("tipc: make subscriber server support net namespace") Signed-off-by: Junwei Hu Reported-by: Wang Wang Reviewed-by: Xiaogang Wang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 92166190b8282d9925e90a66961879782c50d037 Author: Sabrina Dubroca Date: Tue May 14 15:12:19 2019 +0200 rtnetlink: always put IFLA_LINK for links with a link-netnsid [ Upstream commit feadc4b6cf42a53a8a93c918a569a0b7e62bd350 ] Currently, nla_put_iflink() doesn't put the IFLA_LINK attribute when iflink == ifindex. In some cases, a device can be created in a different netns with the same ifindex as its parent. That device will not dump its IFLA_LINK attribute, which can confuse some userspace software that expects it. For example, if the last ifindex created in init_net and foo are both 8, these commands will trigger the issue: ip link add parent type dummy # ifindex 9 ip link add link parent netns foo type macvlan # ifindex 9 in ns foo So, in case a device puts the IFLA_LINK_NETNSID attribute in a dump, always put the IFLA_LINK attribute as well. Thanks to Dan Winship for analyzing the original OpenShift bug down to the missing netlink attribute. v2: change Fixes tag, it's been here forever, as Nicolas Dichtel said add Nicolas' ack v3: change Fixes tag fix subject typo, spotted by Edward Cree Analyzed-by: Dan Winship Fixes: d8a5ec672768 ("[NET]: netlink support for moving devices between network namespaces.") Signed-off-by: Sabrina Dubroca Acked-by: Nicolas Dichtel Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 00cb7490bce9f333c51afab4a636c2db3debfb95 Author: YueHaibing Date: Tue May 14 22:55:32 2019 +0800 ppp: deflate: Fix possible crash in deflate_init [ Upstream commit 3ebe1bca58c85325c97a22d4fc3f5b5420752e6f ] BUG: unable to handle kernel paging request at ffffffffa018f000 PGD 3270067 P4D 3270067 PUD 3271063 PMD 2307eb067 PTE 0 Oops: 0000 [#1] PREEMPT SMP CPU: 0 PID: 4138 Comm: modprobe Not tainted 5.1.0-rc7+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014 RIP: 0010:ppp_register_compressor+0x3e/0xd0 [ppp_generic] Code: 98 4a 3f e2 48 8b 15 c1 67 00 00 41 8b 0c 24 48 81 fa 40 f0 19 a0 75 0e eb 35 48 8b 12 48 81 fa 40 f0 19 a0 74 RSP: 0018:ffffc90000d93c68 EFLAGS: 00010287 RAX: ffffffffa018f000 RBX: ffffffffa01a3000 RCX: 000000000000001a RDX: ffff888230c750a0 RSI: 0000000000000000 RDI: ffffffffa019f000 RBP: ffffc90000d93c80 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffffffa0194080 R13: ffff88822ee1a700 R14: 0000000000000000 R15: ffffc90000d93e78 FS: 00007f2339557540(0000) GS:ffff888237a00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffa018f000 CR3: 000000022bde4000 CR4: 00000000000006f0 Call Trace: ? 0xffffffffa01a3000 deflate_init+0x11/0x1000 [ppp_deflate] ? 0xffffffffa01a3000 do_one_initcall+0x6c/0x3cc ? kmem_cache_alloc_trace+0x248/0x3b0 do_init_module+0x5b/0x1f1 load_module+0x1db1/0x2690 ? m_show+0x1d0/0x1d0 __do_sys_finit_module+0xc5/0xd0 __x64_sys_finit_module+0x15/0x20 do_syscall_64+0x6b/0x1d0 entry_SYSCALL_64_after_hwframe+0x49/0xbe If ppp_deflate fails to register in deflate_init, module initialization failed out, however ppp_deflate_draft may has been regiestred and not unregistered before return. Then the seconed modprobe will trigger crash like this. Reported-by: Hulk Robot Signed-off-by: YueHaibing Acked-by: Guillaume Nault Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 684414422d1b7a6c671dfa7deb29024674fa8eb5 Author: Pieter Jansen van Vuuren Date: Tue May 14 14:28:19 2019 -0700 nfp: flower: add rcu locks when accessing netdev for tunnels [ Upstream commit cb07d915bf278a7a3938b983bbcb4921366b5eff ] Add rcu locks when accessing netdev when processing route request and tunnel keep alive messages received from hardware. Fixes: 8e6a9046b66a ("nfp: flower vxlan neighbour offload") Fixes: 856f5b135758 ("nfp: flower vxlan neighbour keep-alive") Signed-off-by: Pieter Jansen van Vuuren Reviewed-by: Jakub Kicinski Reviewed-by: John Hurley Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 356ffdbc2fc3bfb228b2eb39adcc218e3a443337 Author: Daniele Palmas Date: Wed May 15 17:29:43 2019 +0200 net: usb: qmi_wwan: add Telit 0x1260 and 0x1261 compositions [ Upstream commit b4e467c82f8c12af78b6f6fa5730cb7dea7af1b4 ] Added support for Telit LE910Cx 0x1260 and 0x1261 compositions. Signed-off-by: Daniele Palmas Acked-by: Bjørn Mork Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 912d8c4cf9f19c93dfdf06b822eeadec9d71494d Author: Willem de Bruijn Date: Wed May 15 13:29:16 2019 -0400 net: test nouarg before dereferencing zerocopy pointers [ Upstream commit 185ce5c38ea76f29b6bd9c7c8c7a5e5408834920 ] Zerocopy skbs without completion notification were added for packet sockets with PACKET_TX_RING user buffers. Those signal completion through the TP_STATUS_USER bit in the ring. Zerocopy annotation was added only to avoid premature notification after clone or orphan, by triggering a copy on these paths for these packets. The mechanism had to define a special "no-uarg" mode because packet sockets already use skb_uarg(skb) == skb_shinfo(skb)->destructor_arg for a different pointer. Before deferencing skb_uarg(skb), verify that it is a real pointer. Fixes: 5cd8d46ea1562 ("packet: copy user buffers before orphan or clone") Signed-off-by: Willem de Bruijn Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 3f8c89043e4eb8f8ad58591a1b5a98be32a40991 Author: Yunjian Wang Date: Tue May 14 19:03:19 2019 +0800 net/mlx4_core: Change the error print to info print [ Upstream commit 00f9fec48157f3734e52130a119846e67a12314b ] The error print within mlx4_flow_steer_promisc_add() should be a info print. Fixes: 592e49dda812 ('net/mlx4: Implement promiscuous mode with device managed flow-steering') Signed-off-by: Yunjian Wang Reviewed-by: Tariq Toukan Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 032cb3ac33026712927d4c53367fb7e398916b0c Author: Eric Dumazet Date: Thu May 16 08:09:57 2019 -0700 net: avoid weird emergency message [ Upstream commit d7c04b05c9ca14c55309eb139430283a45c4c25f ] When host is under high stress, it is very possible thread running netdev_wait_allrefs() returns from msleep(250) 10 seconds late. This leads to these messages in the syslog : [...] unregister_netdevice: waiting for syz_tun to become free. Usage count = 0 If the device refcount is zero, the wait is over. Signed-off-by: Eric Dumazet Reported-by: syzbot Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b3be76062964d9ca9c707d092c7409537ae3a2c9 Author: Florian Fainelli Date: Mon May 13 14:06:24 2019 -0700 net: Always descend into dsa/ [ Upstream commit 0fe9f173d6cda95874edeb413b1fa9907b5ae830 ] Jiri reported that with a kernel built with CONFIG_FIXED_PHY=y, CONFIG_NET_DSA=m and CONFIG_NET_DSA_LOOP=m, we would not get to a functional state where the mock-up driver is registered. Turns out that we are not descending into drivers/net/dsa/ unconditionally, and we won't be able to link-in dsa_loop_bdinfo.o which does the actual mock-up mdio device registration. Reported-by: Jiri Pirko Fixes: 40013ff20b1b ("net: dsa: Fix functional dsa-loop dependency on FIXED_PHY") Signed-off-by: Florian Fainelli Reviewed-by: Vivien Didelot Tested-by: Jiri Pirko Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 471bdd1c062aa58c4d7b80b5c574ad1e1407d7b0 Author: Eric Dumazet Date: Wed May 15 19:39:52 2019 -0700 ipv6: prevent possible fib6 leaks [ Upstream commit 61fb0d01680771f72cc9d39783fb2c122aaad51e ] At ipv6 route dismantle, fib6_drop_pcpu_from() is responsible for finding all percpu routes and set their ->from pointer to NULL, so that fib6_ref can reach its expected value (1). The problem right now is that other cpus can still catch the route being deleted, since there is no rcu grace period between the route deletion and call to fib6_drop_pcpu_from() This can leak the fib6 and associated resources, since no notifier will take care of removing the last reference(s). I decided to add another boolean (fib6_destroying) instead of reusing/renaming exception_bucket_flushed to ease stable backports, and properly document the memory barriers used to implement this fix. This patch has been co-developped with Wei Wang. Fixes: 93531c674315 ("net/ipv6: separate handling of FIB entries from dst based routes") Signed-off-by: Eric Dumazet Reported-by: syzbot Cc: Wei Wang Cc: David Ahern Cc: Martin Lau Acked-by: Wei Wang Acked-by: Martin KaFai Lau Reviewed-by: David Ahern Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 9cbc590df61673960a371d20371a42d1b250f046 Author: Wei Wang Date: Thu May 16 13:30:54 2019 -0700 ipv6: fix src addr routing with the exception table [ Upstream commit 510e2ceda031eed97a7a0f9aad65d271a58b460d ] When inserting route cache into the exception table, the key is generated with both src_addr and dest_addr with src addr routing. However, current logic always assumes the src_addr used to generate the key is a /128 host address. This is not true in the following scenarios: 1. When the route is a gateway route or does not have next hop. (rt6_is_gw_or_nonexthop() == false) 2. When calling ip6_rt_cache_alloc(), saddr is passed in as NULL. This means, when looking for a route cache in the exception table, we have to do the lookup twice: first time with the passed in /128 host address, second time with the src_addr stored in fib6_info. This solves the pmtu discovery issue reported by Mikael Magnusson where a route cache with a lower mtu info is created for a gateway route with src addr. However, the lookup code is not able to find this route cache. Fixes: 2b760fcf5cfb ("ipv6: hook up exception table to store dst cache") Reported-by: Mikael Magnusson Bisected-by: David Ahern Signed-off-by: Wei Wang Cc: Martin Lau Cc: Eric Dumazet Acked-by: Martin KaFai Lau Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman