commit 6006d5b025224f2db8751d317e2e6bcdad69d4b6 Author: Greg Kroah-Hartman Date: Sat May 4 09:21:23 2019 +0200 Linux 5.0.12 commit 310f9b1e52c00715b0413bc47deeb2c997da1fcf Author: Rasmus Villemoes Date: Thu Mar 14 15:06:14 2019 +0100 leds: trigger: netdev: use memcpy in device_name_store [ Upstream commit 909346433064b8d840dc82af26161926b8d37558 ] If userspace doesn't end the input with a newline (which can easily happen if the write happens from a C program that does write(fd, iface, strlen(iface))), we may end up including garbage from a previous, longer value in the device_name. For example # cat device_name # printf 'eth12' > device_name # cat device_name eth12 # printf 'eth3' > device_name # cat device_name eth32 I highly doubt anybody is relying on this behaviour, so switch to simply copying the bytes (we've already checked that size is < IFNAMSIZ) and unconditionally zero-terminate it; of course, we also still have to strip a trailing newline. This is also preparation for future patches. Fixes: 06f502f57d0d ("leds: trigger: Introduce a NETDEV trigger") Signed-off-by: Rasmus Villemoes Acked-by: Pavel Machek Signed-off-by: Jacek Anaszewski Signed-off-by: Sasha Levin (Microsoft) commit 004ec01370bc183a83d715d975aa742d99a556f0 Author: Kangjie Lu Date: Sat Mar 9 00:04:11 2019 -0600 leds: pca9532: fix a potential NULL pointer dereference [ Upstream commit 0aab8e4df4702b31314a27ec4b0631dfad0fae0a ] In case of_match_device cannot find a match, return -EINVAL to avoid NULL pointer dereference. Fixes: fa4191a609f2 ("leds: pca9532: Add device tree support") Signed-off-by: Kangjie Lu Signed-off-by: Jacek Anaszewski Signed-off-by: Sasha Levin (Microsoft) commit 107cfb99c81f37a8df6dc4726495db7b5e22967f Author: Andrei Vagin Date: Thu Mar 28 20:44:13 2019 -0700 ptrace: take into account saved_sigmask in PTRACE{GET,SET}SIGMASK [ Upstream commit fcfc2aa0185f4a731d05a21e9f359968fdfd02e7 ] There are a few system calls (pselect, ppoll, etc) which replace a task sigmask while they are running in a kernel-space When a task calls one of these syscalls, the kernel saves a current sigmask in task->saved_sigmask and sets a syscall sigmask. On syscall-exit-stop, ptrace traps a task before restoring the saved_sigmask, so PTRACE_GETSIGMASK returns the syscall sigmask and PTRACE_SETSIGMASK does nothing, because its sigmask is replaced by saved_sigmask, when the task returns to user-space. This patch fixes this problem. PTRACE_GETSIGMASK returns saved_sigmask if it's set. PTRACE_SETSIGMASK drops the TIF_RESTORE_SIGMASK flag. Link: http://lkml.kernel.org/r/20181120060616.6043-1-avagin@gmail.com Fixes: 29000caecbe8 ("ptrace: add ability to get/set signal-blocked mask") Signed-off-by: Andrei Vagin Acked-by: Oleg Nesterov Cc: "Eric W. Biederman" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin (Microsoft) commit 87eaf3d8ac51577c6123b43245e547c94c54dc06 Author: Qian Cai Date: Thu Mar 28 20:43:15 2019 -0700 kasan: fix variable 'tag' set but not used warning [ Upstream commit c412a769d2452161e97f163c4c4f31efc6626f06 ] set_tag() compiles away when CONFIG_KASAN_SW_TAGS=n, so make arch_kasan_set_tag() a static inline function to fix warnings below. mm/kasan/common.c: In function '__kasan_kmalloc': mm/kasan/common.c:475:5: warning: variable 'tag' set but not used [-Wunused-but-set-variable] u8 tag; ^~~ Link: http://lkml.kernel.org/r/20190307185244.54648-1-cai@lca.pw Signed-off-by: Qian Cai Reviewed-by: Andrey Konovalov Cc: Andrey Ryabinin Cc: Alexander Potapenko Cc: Dmitry Vyukov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin (Microsoft) commit 514860ee66333ed2baa99aa2c43ec83320105ed3 Author: Joerg Roedel Date: Thu Mar 28 11:44:59 2019 +0100 iommu/amd: Reserve exclusion range in iova-domain [ Upstream commit 8aafaaf2212192012f5bae305bb31cdf7681d777 ] If a device has an exclusion range specified in the IVRS table, this region needs to be reserved in the iova-domain of that device. This hasn't happened until now and can cause data corruption on data transfered with these devices. Treat exclusion ranges as reserved regions in the iommu-core to fix the problem. Fixes: be2a022c0dd0 ('x86, AMD IOMMU: add functions to parse IOMMU memory mapping requirements for devices') Signed-off-by: Joerg Roedel Reviewed-by: Gary R Hook Signed-off-by: Sasha Levin (Microsoft) commit 8bd7d23a4a76241c748aa5e2a2359b44839acc80 Author: Changbin Du Date: Mon Mar 25 15:16:47 2019 +0000 kconfig/[mn]conf: handle backspace (^H) key [ Upstream commit 9c38f1f044080392603c497ecca4d7d09876ff99 ] Backspace is not working on some terminal emulators which do not send the key code defined by terminfo. Terminals either send '^H' (8) or '^?' (127). But currently only '^?' is handled. Let's also handle '^H' for those terminals. Signed-off-by: Changbin Du Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin (Microsoft) commit 44fe72aeaae884358549acd27a434825f1cb3ca3 Author: Wei Li Date: Thu Feb 28 17:20:03 2019 +0800 perf machine: Update kernel map address and re-order properly [ Upstream commit 977c7a6d1e263ff1d755f28595b99e4bc0c48a9f ] Since commit 1fb87b8e9599 ("perf machine: Don't search for active kernel start in __machine__create_kernel_maps"), the __machine__create_kernel_maps() just create a map what start and end are both zero. Though the address will be updated later, the order of map in the rbtree may be incorrect. The commit ee05d21791db ("perf machine: Set main kernel end address properly") fixed the logic in machine__create_kernel_maps(), but it's still wrong in function machine__process_kernel_mmap_event(). To reproduce this issue, we need an environment which the module address is before the kernel text segment. I tested it on an aarch64 machine with kernel 4.19.25: [root@localhost hulk]# grep _stext /proc/kallsyms ffff000008081000 T _stext [root@localhost hulk]# grep _etext /proc/kallsyms ffff000009780000 R _etext [root@localhost hulk]# tail /proc/modules hisi_sas_v2_hw 77824 0 - Live 0xffff00000191d000 nvme_core 126976 7 nvme, Live 0xffff0000018b6000 mdio 20480 1 ixgbe, Live 0xffff0000018ab000 hisi_sas_main 106496 1 hisi_sas_v2_hw, Live 0xffff000001861000 hns_mdio 20480 2 - Live 0xffff000001822000 hnae 28672 3 hns_dsaf,hns_enet_drv, Live 0xffff000001815000 dm_mirror 40960 0 - Live 0xffff000001804000 dm_region_hash 32768 1 dm_mirror, Live 0xffff0000017f5000 dm_log 32768 2 dm_mirror,dm_region_hash, Live 0xffff0000017e7000 dm_mod 315392 17 dm_mirror,dm_log, Live 0xffff000001780000 [root@localhost hulk]# Before fix: [root@localhost bin]# perf record sleep 3 [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.011 MB perf.data (9 samples) ] [root@localhost bin]# perf buildid-list -i perf.data 4c4e46c971ca935f781e603a09b52a92e8bdfee8 [vdso] [root@localhost bin]# perf buildid-list -i perf.data -H 0000000000000000000000000000000000000000 /proc/kcore [root@localhost bin]# After fix: [root@localhost tools]# ./perf/perf record sleep 3 [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.011 MB perf.data (9 samples) ] [root@localhost tools]# ./perf/perf buildid-list -i perf.data 28a6c690262896dbd1b5e1011ed81623e6db0610 [kernel.kallsyms] 106c14ce6e4acea3453e484dc604d66666f08a2f [vdso] [root@localhost tools]# ./perf/perf buildid-list -i perf.data -H 28a6c690262896dbd1b5e1011ed81623e6db0610 /proc/kcore Signed-off-by: Wei Li Acked-by: Jiri Olsa Acked-by: Namhyung Kim Cc: Alexander Shishkin Cc: David Ahern Cc: Hanjun Guo Cc: Kim Phillips Cc: Li Bin Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/20190228092003.34071-1-liwei391@huawei.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin (Microsoft) commit 441d23c8764449c3219e7d97eb3b5a98be7c534f Author: Solomon Tan Date: Fri Mar 22 13:22:55 2019 +0800 perf cs-etm: Add missing case value [ Upstream commit c8fa7a807f3c5f946bd92076fbaf7826edb650dc ] The following error was thrown when compiling `tools/perf` using OpenCSD v0.11.1. This patch fixes said error. CC util/intel-pt-decoder/intel-pt-log.o CC util/cs-etm-decoder/cs-etm-decoder.o util/cs-etm-decoder/cs-etm-decoder.c: In function ‘cs_etm_decoder__buffer_range’: util/cs-etm-decoder/cs-etm-decoder.c:370:2: error: enumeration value ‘OCSD_INSTR_WFI_WFE’ not handled in switch [-Werror=switch-enum] switch (elem->last_i_type) { ^~~~~~ CC util/intel-pt-decoder/intel-pt-decoder.o cc1: all warnings being treated as errors Because `OCSD_INSTR_WFI_WFE` case was added only in v0.11.0, the minimum required OpenCSD library version for this patch is no longer v0.10.0. Signed-off-by: Solomon Tan Cc: Alexander Shishkin Cc: Jiri Olsa Cc: Mathieu Poirier Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Robert Walker Cc: Suzuki K Poulouse Cc: linux-arm-kernel@lists.infradead.org Link: http://lkml.kernel.org/r/20190322052255.GA4809@w-OptiPlex-7050 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin (Microsoft) commit b8bc52cd62e883929d1ad465ad9ad084fb9bb628 Author: Max Gurtovoy Date: Thu Mar 28 12:54:03 2019 +0200 nvmet: fix error flow during ns enable [ Upstream commit a536b49785759bf99465fdf6e248d34322123fcd ] In case we fail to enable p2pmem on the current namespace, disable the backing store device before exiting. Cc: Stephen Bates Signed-off-by: Max Gurtovoy Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin (Microsoft) commit 163719bdcd9c1b84c9840e72e9a4f43ae1936c2c Author: Ming Lei Date: Wed Mar 27 17:07:22 2019 +0800 nvmet: fix building bvec from sg list [ Upstream commit 02db99548d3608a625cf481cff2bb7b626829b3f ] There are two mistakes for building bvec from sg list for file backed ns: - use request data length to compute number of io vector, this way doesn't consider sg->offset, and the result may be smaller than required io vectors - bvec->bv_len isn't capped by sg->length This patch fixes this issue by building bvec from sg directly, given the whole IO stack is ready for multi-page bvec. Reported-by: Yi Zhang Fixes: 3a85a5de29ea ("nvme-loop: add a NVMe loopback host driver") Signed-off-by: Ming Lei Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin (Microsoft) commit 2e7d5b2e1fa0060de5ed2b1c2432b9d877296e1e Author: Martin George Date: Wed Mar 27 09:52:56 2019 +0100 nvme-multipath: relax ANA state check [ Upstream commit cc2278c413c3a06a93c23ee8722e4dd3d621de12 ] When undergoing state transitions I/O might be requeued, hence we should always call nvme_mpath_set_live() to schedule requeue_work whenever the nvme device is live, independent on whether the old state was live or not. Signed-off-by: Martin George Signed-off-by: Gargi Srinivas Signed-off-by: Hannes Reinecke Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin (Microsoft) commit a72f60dbb55745c943ec304dba7911ed27dbc172 Author: Geert Uytterhoeven Date: Thu Mar 28 14:13:47 2019 +0100 gpio: of: Fix of_gpiochip_add() error path [ Upstream commit f7299d441a4da8a5088e651ea55023525a793a13 ] If the call to of_gpiochip_scan_gpios() in of_gpiochip_add() fails, no error handling is performed. This lead to the need of callers to call of_gpiochip_remove() on failure, which causes "BAD of_node_put() on ..." if the failure happened before the call to of_node_get(). Fix this by adding proper error handling. Note that calling gpiochip_remove_pin_ranges() multiple times causes no harm: subsequent calls are a no-op. Fixes: dfbd379ba9b7431e ("gpio: of: Return error if gpio hog configuration failed") Signed-off-by: Geert Uytterhoeven Reviewed-by: Mukesh Ojha Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin (Microsoft) commit 41a94b1909a4560f2d37e58403c59c9f5ac783cb Author: Sean Christopherson Date: Wed Mar 13 16:49:31 2019 -0700 KVM: selftests: complete IO before migrating guest state [ Upstream commit 0f73bbc851ed32d22bbd86be09e0365c460bcd2e ] Documentation/virtual/kvm/api.txt states: NOTE: For KVM_EXIT_IO, KVM_EXIT_MMIO, KVM_EXIT_OSI, KVM_EXIT_PAPR and KVM_EXIT_EPR the corresponding operations are complete (and guest state is consistent) only after userspace has re-entered the kernel with KVM_RUN. The kernel side will first finish incomplete operations and then check for pending signals. Userspace can re-enter the guest with an unmasked signal pending to complete pending operations. Because guest state may be inconsistent, starting state migration after an IO exit without first completing IO may result in test failures, e.g. a proposed change to KVM's handling of %rip in its fast PIO handling[1] will cause the new VM, i.e. the post-migration VM, to have its %rip set to the IN instruction that triggered KVM_EXIT_IO, leading to a test assertion due to a stage mismatch. For simplicitly, require KVM_CAP_IMMEDIATE_EXIT to complete IO and skip the test if it's not available. The addition of KVM_CAP_IMMEDIATE_EXIT predates the state selftest by more than a year. [1] https://patchwork.kernel.org/patch/10848545/ Fixes: fa3899add1056 ("kvm: selftests: add basic test for state save and restore") Reported-by: Jim Mattson Signed-off-by: Sean Christopherson Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin (Microsoft) commit a312d0eaf90d39b5b321d8f6028240ff206d1188 Author: Sean Christopherson Date: Wed Mar 13 12:43:14 2019 -0700 KVM: selftests: disable stack protector for all KVM tests [ Upstream commit ffac839d040619847217647434b2b02469926871 ] Since 4.8.3, gcc has enabled -fstack-protector by default. This is problematic for the KVM selftests as they do not configure fs or gs segments (the stack canary is pulled from fs:0x28). With the default behavior, gcc will insert a stack canary on any function that creates buffers of 8 bytes or more. As a result, ucall() will hit a triple fault shutdown due to reading a bad fs segment when inserting its stack canary, i.e. every test fails with an unexpected SHUTDOWN. Fixes: 14c47b7530e2d ("kvm: selftests: introduce ucall") Signed-off-by: Sean Christopherson Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin (Microsoft) commit 77507936fea3c1533432f33023d3f9274c445868 Author: Sean Christopherson Date: Wed Mar 13 16:19:30 2019 -0700 KVM: selftests: explicitly disable PIE for tests [ Upstream commit 0a3f29b5a77d6c27796d7a7adabafd199dc066d5 ] KVM selftests embed the guest "image" as a function in the test itself and extract the guest code at runtime by manually parsing the elf headers. The parsing is very simple and doesn't supporting fancy things like position independent executables. Recent versions of gcc enable pie by default, which results in triple fault shutdowns in the guest due to the virtual address in the headers not matching up with the virtual address retrieved from the function pointer. Signed-off-by: Sean Christopherson Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin (Microsoft) commit e478d1c9b5853998e3bab7668c457e9890a7967d Author: Sean Christopherson Date: Wed Mar 13 13:19:26 2019 -0700 KVM: selftests: assert on exit reason in CR4/cpuid sync test [ Upstream commit 8df98ae0ab2ead9a02228756eec26f8d7b17f499 ] ...so that the test doesn't end up in an infinite loop if it fails for whatever reason, e.g. SHUTDOWN due to gcc inserting stack canary code into ucall() and attempting to derefence a null segment. Fixes: ca359066889f7 ("kvm: selftests: add cr4_cpuid_sync_test") Cc: Wei Huang Signed-off-by: Sean Christopherson Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin (Microsoft) commit 02a7fc6c77d5f06b351f1aa8f72f2e42a0d4049a Author: Vitaly Kuznetsov Date: Wed Mar 13 18:13:42 2019 +0100 x86/kvm/hyper-v: avoid spurious pending stimer on vCPU init [ Upstream commit 013cc6ebbf41496ce4badedd71ea6d4a6d198c14 ] When userspace initializes guest vCPUs it may want to zero all supported MSRs including Hyper-V related ones including HV_X64_MSR_STIMERn_CONFIG/ HV_X64_MSR_STIMERn_COUNT. With commit f3b138c5d89a ("kvm/x86: Update SynIC timers on guest entry only") we began doing stimer_mark_pending() unconditionally on every config change. The issue I'm observing manifests itself as following: - Qemu writes 0 to STIMERn_{CONFIG,COUNT} MSRs and marks all stimers as pending in stimer_pending_bitmap, arms KVM_REQ_HV_STIMER; - kvm_hv_has_stimer_pending() starts returning true; - kvm_vcpu_has_events() starts returning true; - kvm_arch_vcpu_runnable() starts returning true; - when kvm_arch_vcpu_ioctl_run() gets into (vcpu->arch.mp_state == KVM_MP_STATE_UNINITIALIZED) case: - kvm_vcpu_block() gets in 'kvm_vcpu_check_block(vcpu) < 0' and returns immediately, avoiding normal wait path; - -EAGAIN is returned from kvm_arch_vcpu_ioctl_run() immediately forcing userspace to retry. So instead of normal wait path we get a busy loop on all secondary vCPUs before they get INIT signal. This seems to be undesirable, especially given that this happens even when Hyper-V extensions are not used. Generally, it seems to be pointless to mark an stimer as pending in stimer_pending_bitmap and arm KVM_REQ_HV_STIMER as the only thing kvm_hv_process_stimers() will do is clear the corresponding bit. We may just not mark disabled timers as pending instead. Fixes: f3b138c5d89a ("kvm/x86: Update SynIC timers on guest entry only") Signed-off-by: Vitaly Kuznetsov Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin (Microsoft) commit e10edda577cc4db621e0eb713c56e8f749c72b69 Author: Xiaoyao Li Date: Fri Mar 8 15:57:20 2019 +0800 kvm/x86: Move MSR_IA32_ARCH_CAPABILITIES to array emulated_msrs [ Upstream commit 2bdb76c015df7125783d8394d6339d181cb5bc30 ] Since MSR_IA32_ARCH_CAPABILITIES is emualted unconditionally even if host doesn't suppot it. We should move it to array emulated_msrs from arry msrs_to_save, to report to userspace that guest support this msr. Signed-off-by: Xiaoyao Li Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin (Microsoft) commit 3d714ded80f65bcf68667e272495536e85bc3daf Author: Singh, Brijesh Date: Fri Feb 15 17:24:12 2019 +0000 KVM: SVM: Workaround errata#1096 (insn_len maybe zero on SMAP violation) [ Upstream commit 05d5a48635259e621ea26d01e8316c6feeb34190 ] Errata#1096: On a nested data page fault when CR.SMAP=1 and the guest data read generates a SMAP violation, GuestInstrBytes field of the VMCB on a VMEXIT will incorrectly return 0h instead the correct guest instruction bytes . Recommend Workaround: To determine what instruction the guest was executing the hypervisor will have to decode the instruction at the instruction pointer. The recommended workaround can not be implemented for the SEV guest because guest memory is encrypted with the guest specific key, and instruction decoder will not be able to decode the instruction bytes. If we hit this errata in the SEV guest then log the message and request a guest shutdown. Reported-by: Venkatesh Srinivas Cc: Jim Mattson Cc: Tom Lendacky Cc: Borislav Petkov Cc: Joerg Roedel Cc: "Radim Krčmář" Cc: Paolo Bonzini Signed-off-by: Brijesh Singh Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin (Microsoft) commit 5369433777ecc0330e60eb5b7f0b2d92361d63b0 Author: Sean Christopherson Date: Thu Mar 7 15:27:43 2019 -0800 KVM: nVMX: Do not inherit quadrant and invalid for the root shadow EPT [ Upstream commit 552c69b1dc714854a5f4e27d37a43c6d797adf7d ] Explicitly zero out quadrant and invalid instead of inheriting them from the root_mmu. Functionally, this patch is a nop as we (should) never set quadrant for a direct mapped (EPT) root_mmu and nested EPT is only allowed if EPT is used for L1, and the root_mmu will never be invalid at this point. Explicitly setting flags sets the stage for repurposing the legacy paging bits in role, e.g. nxe, cr0_wp, and sm{a,e}p_andnot_wp, at which point 'smm' would be the only flag to be inherited from root_mmu. Signed-off-by: Sean Christopherson Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin (Microsoft) commit e8b8dde69f819253e7a6cd83a834618f166a52b7 Author: Andrey Smirnov Date: Mon Mar 25 23:32:09 2019 -0700 gpio: of: Check for "spi-cs-high" in child instead of parent node [ Upstream commit 7ce40277bf848391705011ba37eac2e377cbd9e6 ] "spi-cs-high" is going to be specified in child node of an SPI controller's representing attached SPI device, so change the code to look for it there, instead of checking parent node. Signed-off-by: Andrey Smirnov Cc: Linus Walleij Cc: Bartosz Golaszewski Cc: Chris Healy Cc: linux-gpio@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin (Microsoft) commit 0e48494c0edf1d7d90ff32c8a116664c3c0e1eb0 Author: Andrey Smirnov Date: Mon Mar 25 23:32:08 2019 -0700 gpio: of: Check propname before applying "cs-gpios" quirks [ Upstream commit e5545c94e43b8f6599ffc01df8d1aedf18ee912a ] SPI GPIO device has more than just "cs-gpio" property in its node and would request those GPIOs as a part of its initialization. To avoid applying CS-specific quirk to all of them add a check to make sure that propname is "cs-gpios". Signed-off-by: Andrey Smirnov Cc: Linus Walleij Cc: Bartosz Golaszewski Cc: Chris Healy Cc: linux-gpio@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin (Microsoft) commit fb853a4a77483848e42fafb1270fd5cff0a97338 Author: David Howells Date: Wed Mar 27 22:48:02 2019 +0000 afs: Fix StoreData op marshalling [ Upstream commit 8c7ae38d1ce12a0eaeba655df8562552b3596c7f ] The marshalling of AFS.StoreData, AFS.StoreData64 and YFS.StoreData64 calls generated by ->setattr() ops for the purpose of expanding a file is incorrect due to older documentation incorrectly describing the way the RPC 'FileLength' parameter is meant to work. The older documentation says that this is the length the file is meant to end up at the end of the operation; however, it was never implemented this way in any of the servers, but rather the file is truncated down to this before the write operation is effected, and never expanded to it (and, indeed, it was renamed to 'TruncPos' in 2014). Fix this by setting the position parameter to the new file length and doing a zero-lengh write there. The bug causes Xwayland to SIGBUS due to unexpected non-expansion of a file it then mmaps. This can be tested by giving the following test program a filename in an AFS directory: #include #include #include #include #include int main(int argc, char *argv[]) { char *p; int fd; if (argc != 2) { fprintf(stderr, "Format: test-trunc-mmap \n"); exit(2); } fd = open(argv[1], O_RDWR | O_CREAT | O_TRUNC); if (fd < 0) { perror(argv[1]); exit(1); } if (ftruncate(fd, 0x140008) == -1) { perror("ftruncate"); exit(1); } p = mmap(NULL, 4096, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); if (p == MAP_FAILED) { perror("mmap"); exit(1); } p[0] = 'a'; if (munmap(p, 4096) < 0) { perror("munmap"); exit(1); } if (close(fd) < 0) { perror("close"); exit(1); } exit(0); } Fixes: 31143d5d515e ("AFS: implement basic file write support") Reported-by: Jonathan Billings Tested-by: Jonathan Billings Signed-off-by: David Howells Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin (Microsoft) commit c6d02b1ea4d7c58e3f631d4bc7b5287b3f72ca53 Author: Masahiro Yamada Date: Tue Mar 26 13:02:19 2019 +0900 kbuild: skip parsing pre sub-make code for recursion [ Upstream commit 221cc2d27ddc49b3e06d4637db02bf78e70c573c ] When Make recurses to the top Makefile with sub-make-done unset, the code block surrounded by 'ifneq ($(sub-make-done),1) ... endif' is parsed multiple times. This happens for in-tree building of include/config/auto.conf, *-pkg, etc. with GNU Make 4.x. This is a slight regression by commit 688931a5ad4e ("kbuild: skip sub-make for in-tree build with GNU Make 4.x") in terms of performance since that code block contains one $(shell ...) invocation. Fix it by exporting the variable irrespective of sub-make being run. I renamed it because GNU Make cannot properly export variables containing hyphens. This is probably a bug of GNU Make, and the issue in Kbuild had already been reported by commit 2bfbe7881ee0 ("kbuild: Do not use hyphen in exported variable name"). Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin (Microsoft) commit 479e1afd232e0bf502f2a92a21fd09c0ee6747ca Author: raymond pang Date: Thu Mar 28 12:19:25 2019 +0000 libata: fix using DMA buffers on stack [ Upstream commit dd08a8d9a66de4b54575c294a92630299f7e0fe7 ] When CONFIG_VMAP_STACK=y, __pa() returns incorrect physical address for a stack virtual address. Stack DMA buffers must be avoided. Signed-off-by: raymond pang Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin (Microsoft) commit 8d3c7282cec428196344f4dcf3aab78d59f1a398 Author: Ralph Campbell Date: Mon Mar 25 17:18:17 2019 -0700 x86/mm: Don't exceed the valid physical address space [ Upstream commit 92c77f7c4d5dfaaf45b2ce19360e69977c264766 ] valid_phys_addr_range() is used to sanity check the physical address range of an operation, e.g., access to /dev/mem. It uses __pa(high_memory) internally. If memory is populated at the end of the physical address space, then __pa(high_memory) is outside of the physical address space because: high_memory = (void *)__va(max_pfn * PAGE_SIZE - 1) + 1; For the comparison in valid_phys_addr_range() this is not an issue, but if CONFIG_DEBUG_VIRTUAL is enabled, __pa() maps to __phys_addr(), which verifies that the resulting physical address is within the valid physical address space of the CPU. So in the case that memory is populated at the end of the physical address space, this is not true and triggers a VIRTUAL_BUG_ON(). Use __pa(high_memory - 1) to prevent the conversion from going beyond the end of valid physical addresses. Fixes: be62a3204406 ("x86/mm: Limit mmap() of /dev/mem to valid physical addresses") Signed-off-by: Ralph Campbell Signed-off-by: Thomas Gleixner Cc: Craig Bergstrom Cc: Linus Torvalds Cc: Boris Ostrovsky Cc: Fengguang Wu Cc: Greg Kroah-Hartman Cc: Hans Verkuil Cc: Mauro Carvalho Chehab Cc: Peter Zijlstra Cc: Sander Eikelenboom Cc: Sean Young Link: https://lkml.kernel.org/r/20190326001817.15413-2-rcampbell@nvidia.com Signed-off-by: Sasha Levin (Microsoft) commit ab4a5df699b58fb17c2bfd88570a4342d0a566a7 Author: Steffen Maier Date: Tue Mar 26 14:37:00 2019 +0100 scsi: zfcp: reduce flood of fcrscn1 trace records on multi-element RSCN [ Upstream commit c8206579175c34a2546de8a74262456278a7795a ] If an incoming ELS of type RSCN contains more than one element, zfcp suboptimally causes repeated erp trigger NOP trace records for each previously failed port. These could be ports that went away. It loops over each RSCN element, and for each of those in an inner loop over all zfcp_ports. The trigger to recover failed ports should be just the reception of some RSCN, no matter how many elements it has. So we can loop over failed ports separately, and only then loop over each RSCN element to handle the non-failed ports. The call chain was: zfcp_fc_incoming_rscn for (i = 1; i < no_entries; i++) _zfcp_fc_incoming_rscn list_for_each_entry(port, &adapter->port_list, list) if (masked port->d_id match) zfcp_fc_test_link if (!port->d_id) zfcp_erp_port_reopen "fcrscn1" <=== In order the reduce the "flooding" of the REC trace area in such cases, we factor out handling the failed ports to be outside of the entries loop: zfcp_fc_incoming_rscn if (no_entries > 1) <=== list_for_each_entry(port, &adapter->port_list, list) <=== if (!port->d_id) zfcp_erp_port_reopen "fcrscn1" <=== for (i = 1; i < no_entries; i++) _zfcp_fc_incoming_rscn list_for_each_entry(port, &adapter->port_list, list) if (masked port->d_id match) zfcp_fc_test_link Abbreviated example trace records before this code change: Tag : fcrscn1 WWPN : 0x500507630310d327 ERP want : 0x02 ERP need : 0x02 Tag : fcrscn1 WWPN : 0x500507630310d327 ERP want : 0x02 ERP need : 0x00 NOP => superfluous trace record The last trace entry repeats if there are more than 2 RSCN elements. Signed-off-by: Steffen Maier Reviewed-by: Benjamin Block Reviewed-by: Jens Remus Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin (Microsoft) commit b0921da055f17621210fdf42d34d78b49590b7b5 Author: Al Viro Date: Tue Mar 26 01:38:58 2019 +0000 ceph: fix use-after-free on symlink traversal [ Upstream commit daf5cc27eed99afdea8d96e71b89ba41f5406ef6 ] free the symlink body after the same RCU delay we have for freeing the struct inode itself, so that traversal during RCU pathwalk wouldn't step into freed memory. Signed-off-by: Al Viro Reviewed-by: Jeff Layton Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin (Microsoft) commit 1ab2566c5329bda0c06036669dcb936b1eb6f881 Author: Mukesh Ojha Date: Tue Mar 26 13:42:22 2019 +0530 usb: u132-hcd: fix resource leak [ Upstream commit f276e002793cdb820862e8ea8f76769d56bba575 ] if platform_driver_register fails, cleanup the allocated resource gracefully. Signed-off-by: Mukesh Ojha Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin (Microsoft) commit 4f5d11bf2ecafbb04c7a2b841cfb88ae1f8b0c90 Author: Matteo Croce Date: Tue Mar 26 21:30:46 2019 +0100 x86/realmode: Don't leak the trampoline kernel address [ Upstream commit b929a500d68479163c48739d809cbf4c1335db6f ] Since commit ad67b74d2469 ("printk: hash addresses printed with %p") at boot "____ptrval____" is printed instead of the trampoline addresses: Base memory trampoline at [(____ptrval____)] 99000 size 24576 Remove the print as we don't want to leak kernel addresses and this statement is not needed anymore. Fixes: ad67b74d2469d9b8 ("printk: hash addresses printed with %p") Signed-off-by: Matteo Croce Signed-off-by: Borislav Petkov Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Thomas Gleixner Cc: x86-ml Link: https://lkml.kernel.org/r/20190326203046.20787-1-mcroce@redhat.com Signed-off-by: Sasha Levin (Microsoft) commit 89ae17728a98b7a36811d2d5e6b86d2ba4f0bb5e Author: Alakesh Haloi Date: Tue Mar 26 02:00:01 2019 +0000 SUNRPC: fix uninitialized variable warning [ Upstream commit 01f2f5b82a2b523ae76af53f2ff43c48dde10a00 ] Avoid following compiler warning on uninitialized variable net/sunrpc/xprtsock.c: In function ‘xs_read_stream_request.constprop’: net/sunrpc/xprtsock.c:525:10: warning: ‘read’ may be used uninitialized in this function [-Wmaybe-uninitialized] return read; ^~~~ net/sunrpc/xprtsock.c:529:23: warning: ‘ret’ may be used uninitialized in this function [-Wmaybe-uninitialized] return ret < 0 ? ret : read; ~~~~~~~~~~~~~~^~~~~~ Signed-off-by: Alakesh Haloi Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin (Microsoft) commit ec44e4273006d34d67765faaf002036ae2d03cbe Author: Rafał Miłecki Date: Thu Feb 28 22:57:33 2019 +0100 leds: trigger: netdev: fix refcnt leak on interface rename [ Upstream commit 4cb6560514fa19d556954b88128f3846fee66a03 ] Renaming a netdev-trigger-tracked interface was resulting in an unbalanced dev_hold(). Example: > iw phy phy0 interface add foo type __ap > echo netdev > trigger > echo foo > device_name > ip link set foo name bar > iw dev bar del [ 237.355366] unregister_netdevice: waiting for bar to become free. Usage count = 1 [ 247.435362] unregister_netdevice: waiting for bar to become free. Usage count = 1 [ 257.545366] unregister_netdevice: waiting for bar to become free. Usage count = 1 Above problem was caused by trigger checking a dev->name which obviously changes after renaming an interface. It meant missing all further events including the NETDEV_UNREGISTER which is required for calling dev_put(). This change fixes that by: 1) Comparing device struct *address* for notification-filtering purposes 2) Dropping unneeded NETDEV_CHANGENAME code (no behavior change) Fixes: 06f502f57d0d ("leds: trigger: Introduce a NETDEV trigger") Signed-off-by: Rafał Miłecki Acked-by: Pavel Machek Signed-off-by: Jacek Anaszewski Signed-off-by: Sasha Levin (Microsoft) commit facfcac8357da74e84a2a89fa836f668766b1fca Author: Aditya Pakki Date: Wed Mar 20 10:27:11 2019 -0500 usb: usb251xb: fix to avoid potential NULL pointer dereference [ Upstream commit 41f00e6e9e55546390031996b773e7f3c1d95928 ] of_match_device in usb251xb_probe can fail and returns a NULL pointer. The patch avoids a potential NULL pointer dereference in this scenario. Signed-off-by: Aditya Pakki Reviewed-by: Richard Leitner Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin (Microsoft) commit 3ce3290dee8440f60b59ad7da0be3ba97662eaa4 Author: Kangjie Lu Date: Thu Mar 14 01:30:59 2019 -0500 scsi: qla4xxx: fix a potential NULL pointer dereference [ Upstream commit fba1bdd2a9a93f3e2181ec1936a3c2f6b37e7ed6 ] In case iscsi_lookup_endpoint fails, the fix returns -EINVAL to avoid NULL pointer dereference. Signed-off-by: Kangjie Lu Acked-by: Manish Rangankar Reviewed-by: Mukesh Ojha Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin (Microsoft) commit ab602d0043a4915a21c749656c56319ca3c35ab0 Author: Dave Carroll Date: Fri Mar 22 12:16:03 2019 -0600 scsi: aacraid: Insure we don't access PCIe space during AER/EEH [ Upstream commit b6554cfe09e1f610aed7d57164ab7760be57acd9 ] There are a few windows during AER/EEH when we can access PCIe I/O mapped registers. This will harden the access to insure we do not allow PCIe access during errors Signed-off-by: Dave Carroll Reviewed-by: Sagar Biradar Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin (Microsoft) commit 9a5795520b91e1ccba3cb581b67e1c1280dec734 Author: Sreekanth Reddy Date: Mon Mar 4 07:26:35 2019 -0500 scsi: mpt3sas: Fix kernel panic during expander reset [ Upstream commit c2fe742ff6e77c5b4fe4ad273191ddf28fdea25e ] During expander reset handling, the driver invokes kernel function scsi_host_find_tag() to obtain outstanding requests associated with the scsi host managed by the driver. Driver loops from tag value zero to hba queue depth to obtain the outstanding scmds. But when blk-mq is enabled, the block layer may return stale entry for one or more requests. This may lead to kernel panic if the returned value is inaccessible or the memory pointed by the returned value is reused. Reference of upstream discussion: https://patchwork.kernel.org/patch/10734933/ Instead of calling scsi_host_find_tag() API for each and every smid (smid is tag +1) from one to shost->can_queue, now driver will call this API (to obtain the outstanding scmd) only for those smid's which are outstanding at the driver level. Driver will determine whether this smid is outstanding at driver level by looking into it's corresponding MPI request frame, if its MPI request frame is empty, then it means that this smid is free and does not need to call scsi_host_find_tag() for it. By doing this, driver will invoke scsi_host_find_tag() for only those tags which are outstanding at the driver level. Driver will check whether particular MPI request frame is empty or not by looking into the "DevHandle" field. If this field is zero then it means that this MPI request is empty. For active MPI request DevHandle must be non-zero. Also driver will memset the MPI request frame once the corresponding scmd is processed (i.e. just before calling scmd->done function). Signed-off-by: Sreekanth Reddy Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin (Microsoft) commit 08dd1acccb43bad1df5a893341f517fdac517ac1 Author: Dan Carpenter Date: Mon Mar 25 11:56:59 2019 +0300 staging: vc04_services: Fix an error code in vchiq_probe() [ Upstream commit 9b9c87cf51783cbe7140c51472762094033cfeab ] We need to set "err" on this error path. Fixes: 187ac53e590c ("staging: vchiq_arm: rework probe and init functions") Signed-off-by: Dan Carpenter Acked-by: Stefan Wahren Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin (Microsoft) commit b2814ce32d478878ddcc44bc98e5d6ca282b1554 Author: Ming Lei Date: Fri Mar 22 09:13:51 2019 +0800 sbitmap: order READ/WRITE freed instance and setting clear bit [ Upstream commit e6d1fa584e0dd9bfebaf345e9feea588cf75ead2 ] Inside sbitmap_queue_clear(), once the clear bit is set, it will be visiable to allocation path immediately. Meantime READ/WRITE on old associated instance(such as request in case of blk-mq) may be out-of-order with the setting clear bit, so race with re-allocation may be triggered. Adds one memory barrier for ordering READ/WRITE of the freed associated instance with setting clear bit for avoiding race with re-allocation. The following kernel oops triggerd by block/006 on aarch64 may be fixed: [ 142.330954] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000330 [ 142.338794] Mem abort info: [ 142.341554] ESR = 0x96000005 [ 142.344632] Exception class = DABT (current EL), IL = 32 bits [ 142.350500] SET = 0, FnV = 0 [ 142.353544] EA = 0, S1PTW = 0 [ 142.356678] Data abort info: [ 142.359528] ISV = 0, ISS = 0x00000005 [ 142.363343] CM = 0, WnR = 0 [ 142.366305] user pgtable: 64k pages, 48-bit VAs, pgdp = 000000002a3c51c0 [ 142.372983] [0000000000000330] pgd=0000000000000000, pud=0000000000000000 [ 142.379777] Internal error: Oops: 96000005 [#1] SMP [ 142.384613] Modules linked in: null_blk ib_isert iscsi_target_mod ib_srpt target_core_mod ib_srp scsi_transport_srp vfat fat rpcrdma sunrpc rdma_ucm ib_iser rdma_cm iw_cm libiscsi ib_umad scsi_transport_iscsi ib_ipoib ib_cm mlx5_ib ib_uverbs ib_core sbsa_gwdt crct10dif_ce ghash_ce ipmi_ssif sha2_ce ipmi_devintf sha256_arm64 sg sha1_ce ipmi_msghandler ip_tables xfs libcrc32c mlx5_core sdhci_acpi mlxfw ahci_platform at803x sdhci libahci_platform qcom_emac mmc_core hdma hdma_mgmt i2c_dev [last unloaded: null_blk] [ 142.429753] CPU: 7 PID: 1983 Comm: fio Not tainted 5.0.0.cki #2 [ 142.449458] pstate: 00400005 (nzcv daif +PAN -UAO) [ 142.454239] pc : __blk_mq_free_request+0x4c/0xa8 [ 142.458830] lr : blk_mq_free_request+0xec/0x118 [ 142.463344] sp : ffff00003360f6a0 [ 142.466646] x29: ffff00003360f6a0 x28: ffff000010e70000 [ 142.471941] x27: ffff801729a50048 x26: 0000000000010000 [ 142.477232] x25: ffff00003360f954 x24: ffff7bdfff021440 [ 142.482529] x23: 0000000000000000 x22: 00000000ffffffff [ 142.487830] x21: ffff801729810000 x20: 0000000000000000 [ 142.493123] x19: ffff801729a50000 x18: 0000000000000000 [ 142.498413] x17: 0000000000000000 x16: 0000000000000001 [ 142.503709] x15: 00000000000000ff x14: ffff7fe000000000 [ 142.509003] x13: ffff8017dcde09a0 x12: 0000000000000000 [ 142.514308] x11: 0000000000000001 x10: 0000000000000008 [ 142.519597] x9 : ffff8017dcde09a0 x8 : 0000000000002000 [ 142.524889] x7 : ffff8017dcde0a00 x6 : 000000015388f9be [ 142.530187] x5 : 0000000000000001 x4 : 0000000000000000 [ 142.535478] x3 : 0000000000000000 x2 : 0000000000000000 [ 142.540777] x1 : 0000000000000001 x0 : ffff00001041b194 [ 142.546071] Process fio (pid: 1983, stack limit = 0x000000006460a0ea) [ 142.552500] Call trace: [ 142.554926] __blk_mq_free_request+0x4c/0xa8 [ 142.559181] blk_mq_free_request+0xec/0x118 [ 142.563352] blk_mq_end_request+0xfc/0x120 [ 142.567444] end_cmd+0x3c/0xa8 [null_blk] [ 142.571434] null_complete_rq+0x20/0x30 [null_blk] [ 142.576194] blk_mq_complete_request+0x108/0x148 [ 142.580797] null_handle_cmd+0x1d4/0x718 [null_blk] [ 142.585662] null_queue_rq+0x60/0xa8 [null_blk] [ 142.590171] blk_mq_try_issue_directly+0x148/0x280 [ 142.594949] blk_mq_try_issue_list_directly+0x9c/0x108 [ 142.600064] blk_mq_sched_insert_requests+0xb0/0xd0 [ 142.604926] blk_mq_flush_plug_list+0x16c/0x2a0 [ 142.609441] blk_flush_plug_list+0xec/0x118 [ 142.613608] blk_finish_plug+0x3c/0x4c [ 142.617348] blkdev_direct_IO+0x3b4/0x428 [ 142.621336] generic_file_read_iter+0x84/0x180 [ 142.625761] blkdev_read_iter+0x50/0x78 [ 142.629579] aio_read.isra.6+0xf8/0x190 [ 142.633409] __io_submit_one.isra.8+0x148/0x738 [ 142.637912] io_submit_one.isra.9+0x88/0xb8 [ 142.642078] __arm64_sys_io_submit+0xe0/0x238 [ 142.646428] el0_svc_handler+0xa0/0x128 [ 142.650238] el0_svc+0x8/0xc [ 142.653104] Code: b9402a63 f9000a7f 3100047f 540000a0 (f9419a81) [ 142.659202] ---[ end trace 467586bc175eb09d ]--- Fixes: ea86ea2cdced20057da ("sbitmap: ammortize cost of clearing bits") Reported-and-bisected_and_tested-by: Yi Zhang Cc: Yi Zhang Cc: "jianchao.wang" Reviewed-by: Omar Sandoval Signed-off-by: Ming Lei Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin (Microsoft) commit 44a7849ecbd24805b13be92a83455bb419e18886 Author: Sekhar Nori Date: Wed Feb 20 16:36:52 2019 +0530 ARM: davinci: fix build failure with allnoconfig [ Upstream commit 2dbed152e2d4c3fe2442284918d14797898b1e8a ] allnoconfig build with just ARCH_DAVINCI enabled fails because drivers/clk/davinci/* depends on REGMAP being enabled. Fix it by selecting REGMAP_MMIO when building in DaVinci support. Signed-off-by: Sekhar Nori Reviewed-by: David Lechner Signed-off-by: Arnd Bergmann Signed-off-by: Sasha Levin (Microsoft) commit e24c5428060f4041e5878bdb863ccb375246588a Author: Jean-Philippe Brucker Date: Fri Mar 22 15:26:57 2019 +0000 drm/meson: Uninstall IRQ handler [ Upstream commit 2d8f92897ad816f5dda54b2ed2fd9f2d7cb1abde ] meson_drv_unbind() doesn't unregister the IRQ handler, which can lead to use-after-free if the IRQ fires after unbind: [ 64.656876] Unable to handle kernel paging request at virtual address ffff000011706dbc ... [ 64.662001] pc : meson_irq+0x18/0x30 [meson_drm] I'm assuming that a similar problem could happen on the error path of bind(), so uninstall the IRQ handler there as well. Fixes: bbbe775ec5b5 ("drm: Add support for Amlogic Meson Graphic Controller") Signed-off-by: Jean-Philippe Brucker Acked-by: Neil Armstrong Signed-off-by: Neil Armstrong Link: https://patchwork.freedesktop.org/patch/msgid/20190322152657.13752-2-jean-philippe.brucker@arm.com Signed-off-by: Sasha Levin (Microsoft) commit da9c64dc934a57b9404a87e4ad8869e10b0bea29 Author: Jean-Philippe Brucker Date: Fri Mar 22 15:26:56 2019 +0000 drm/meson: Fix invalid pointer in meson_drv_unbind() [ Upstream commit 776e78677f514ecddd12dba48b9040958999bd5a ] meson_drv_bind() registers a meson_drm struct as the device's privdata, but meson_drv_unbind() tries to retrieve a drm_device. This may cause a segfault on shutdown: [ 5194.593429] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000197 ... [ 5194.788850] Call trace: [ 5194.791349] drm_dev_unregister+0x1c/0x118 [drm] [ 5194.795848] meson_drv_unbind+0x50/0x78 [meson_drm] Retrieve the right pointer in meson_drv_unbind(). Fixes: bbbe775ec5b5 ("drm: Add support for Amlogic Meson Graphic Controller") Signed-off-by: Jean-Philippe Brucker Acked-by: Neil Armstrong Signed-off-by: Neil Armstrong Link: https://patchwork.freedesktop.org/patch/msgid/20190322152657.13752-1-jean-philippe.brucker@arm.com Signed-off-by: Sasha Levin (Microsoft) commit 55a5c46268ff48cc2c734d831f30b5b5878d2e42 Author: Kangjie Lu Date: Sun Mar 24 18:10:02 2019 -0500 gpio: aspeed: fix a potential NULL pointer dereference [ Upstream commit 6cf4511e9729c00a7306cf94085f9cc3c52ee723 ] In case devm_kzalloc, the patch returns ENOMEM to avoid potential NULL pointer dereference. Signed-off-by: Kangjie Lu Reviewed-by: Andrew Jeffery Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin (Microsoft) commit e9917fd844ecfa08591c08d2fd4dc3f71a962e98 Author: Noralf Trønnes Date: Fri Feb 8 15:01:02 2019 +0100 drm: Fix drm_release() and device unplug [ Upstream commit 3f04e0a6cfebf48152ac64502346cdc258811f79 ] If userspace has open fd(s) when drm_dev_unplug() is run, it will result in drm_dev_unregister() being called twice. First in drm_dev_unplug() and then later in drm_release() through the call to drm_put_dev(). Since userspace already holds a ref on drm_device through the drm_minor, it's not necessary to add extra ref counting based on no open file handles. Instead just drm_dev_put() unconditionally in drm_dev_unplug(). We now have this: - Userpace holds a ref on drm_device as long as there's open fd(s) - The driver holds a ref on drm_device as long as it's bound to the struct device When both sides are done with drm_device, it is released. Signed-off-by: Noralf Trønnes Reviewed-by: Oleksandr Andrushchenko Reviewed-by: Daniel Vetter Reviewed-by: Sean Paul Signed-off-by: Dave Airlie Link: https://patchwork.freedesktop.org/patch/msgid/20190208140103.28919-2-noralf@tronnes.org Signed-off-by: Sasha Levin (Microsoft) commit c4cdbd4075a6d910cbf8e58b5e87cde491f424c8 Author: Wen Yang Date: Fri Mar 22 11:04:09 2019 +0800 net: ethernet: ti: fix possible object reference leak [ Upstream commit 75eac7b5f68b0a0671e795ac636457ee27cc11d8 ] The call to of_get_child_by_name returns a node pointer with refcount incremented thus it must be explicitly decremented after the last usage. Detected by coccinelle with the following warnings: ./drivers/net/ethernet/ti/netcp_ethss.c:3661:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 3654, but without a corresponding object release within this function. ./drivers/net/ethernet/ti/netcp_ethss.c:3665:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 3654, but without a corresponding object release within this function. Signed-off-by: Wen Yang Cc: Wingman Kwok Cc: Murali Karicheri Cc: "David S. Miller" Cc: netdev@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: David S. Miller Signed-off-by: Sasha Levin (Microsoft) commit 6e4f7c129b2400f375ec8a65459e3e7f8ab9506d Author: Wen Yang Date: Fri Mar 22 11:04:08 2019 +0800 net: ibm: fix possible object reference leak [ Upstream commit be693df3cf9dd113ff1d2c0d8150199efdba37f6 ] The call to ehea_get_eth_dn returns a node pointer with refcount incremented thus it must be explicitly decremented after the last usage. Detected by coccinelle with the following warnings: ./drivers/net/ethernet/ibm/ehea/ehea_main.c:3163:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 3154, but without a corresponding object release within this function. Signed-off-by: Wen Yang Cc: Douglas Miller Cc: "David S. Miller" Cc: netdev@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: David S. Miller Signed-off-by: Sasha Levin (Microsoft) commit 3da122192cde6f8cc6465e2f824867149378d114 Author: Wen Yang Date: Fri Mar 22 11:04:07 2019 +0800 net: xilinx: fix possible object reference leak [ Upstream commit fa3a419d2f674b431d38748cb58fb7da17ee8949 ] The call to of_parse_phandle returns a node pointer with refcount incremented thus it must be explicitly decremented after the last usage. Detected by coccinelle with the following warnings: ./drivers/net/ethernet/xilinx/xilinx_axienet_main.c:1624:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 1569, but without a corresponding object release within this function. Signed-off-by: Wen Yang Cc: Anirudha Sarangi Cc: John Linn Cc: "David S. Miller" Cc: Michal Simek Cc: netdev@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Signed-off-by: David S. Miller Signed-off-by: Sasha Levin (Microsoft) commit 8dcf6dce402312bbec71826f6293a559e4897d38 Author: Trond Myklebust Date: Thu Mar 21 17:57:56 2019 -0400 NFS: Fix a typo in nfs_init_timeout_values() [ Upstream commit 5a698243930c441afccec04e4d5dc8febfd2b775 ] Specifying a retrans=0 mount parameter to a NFS/TCP mount, is inadvertently causing the NFS client to rewrite any specified timeout parameter to the default of 60 seconds. Fixes: a956beda19a6 ("NFS: Allow the mount option retrans=0") Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin (Microsoft) commit 4d88134c2f7ca1935cb29c5534d214bf60281e68 Author: Thierry Reding Date: Mon Feb 11 11:51:20 2019 +0100 drm/tegra: hub: Fix dereference before check [ Upstream commit 7cf77b273a8fc51e7de622fa6691abd4436a9a6b ] Reported-by: Dan Carpenter Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin (Microsoft) commit ec44a9a47e7e7fb83221facf77566c2d3173a011 Author: Masanari Iida Date: Tue Mar 19 01:30:09 2019 +0900 ARM: dts: imx6qdl: Fix typo in imx6qdl-icore-rqs.dtsi [ Upstream commit 41b37f4c0fa67185691bcbd30201cad566f2f0d1 ] This patch fixes a spelling typo. Signed-off-by: Masanari Iida Fixes: cc42603de320 ("ARM: dts: imx6q-icore-rqs: Add Engicam IMX6 Q7 initial support") Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin (Microsoft) commit 4da511ff427b43f7db6ee6368223bde1b925e4f4 Author: Davide Caratti Date: Wed Mar 20 15:00:15 2019 +0100 net/sched: don't dereference a->goto_chain to read the chain index [ Upstream commit fe384e2fa36ca084a456fd30558cccc75b4b3fbd ] callers of tcf_gact_goto_chain_index() can potentially read an old value of the chain index, or even dereference a NULL 'goto_chain' pointer, because 'goto_chain' and 'tcfa_action' are read in the traffic path without caring of concurrent write in the control path. The most recent value of chain index can be read also from a->tcfa_action (it's encoded there together with TC_ACT_GOTO_CHAIN bits), so we don't really need to dereference 'goto_chain': just read the chain id from the control action. Fixes: e457d86ada27 ("net: sched: add couple of goto_chain helpers") Signed-off-by: Davide Caratti Signed-off-by: David S. Miller Signed-off-by: Sasha Levin (Microsoft) commit fe9fae9c5bff1389ad5045bd9baba0bd144a56da Author: Harini Katakam Date: Wed Mar 20 19:12:22 2019 +0530 net: macb: Add null check for PCLK and HCLK [ Upstream commit cd5afa91f078c0787be0a62b5ef90301c00b0271 ] Both PCLK and HCLK are "required" clocks according to macb devicetree documentation. There is a chance that devm_clk_get doesn't return a negative error but just a NULL clock structure instead. In such a case the driver proceeds as usual and uses pclk value 0 to calculate MDC divisor which is incorrect. Hence fix the same in clock initialization. Signed-off-by: Harini Katakam Signed-off-by: David S. Miller Signed-off-by: Sasha Levin (Microsoft) commit ead946dc38247eef58aa7d01cdd494267fd41385 Author: Dan Murphy Date: Wed Mar 20 07:36:55 2019 -0500 net: phy: Add DP83825I to the DP83822 driver [ Upstream commit 06acc17a96215a11134114aee26532b12dc8fde1 ] Add the DP83825I ethernet PHY to the DP83822 driver. These devices share the same WoL register bits and addresses. The phy_driver init was made into a macro as there may be future devices appended to this driver that will share the register space. http://www.ti.com/lit/gpn/dp83825i Reviewed-by: Florian Fainelli Signed-off-by: Dan Murphy Signed-off-by: David S. Miller Signed-off-by: Sasha Levin (Microsoft) commit 9bd87bbd2988f3a5cd5c463418b2012b92913a5f Author: Aditya Pakki Date: Wed Mar 20 10:42:32 2019 -0500 staging: rtlwifi: Fix potential NULL pointer dereference of kzalloc [ Upstream commit 6a8ca24590a2136921439b376c926c11a6effc0e ] phydm.internal is allocated using kzalloc which is used multiple times without a check for NULL pointer. This patch avoids such a scenario by returning 0, consistent with the failure case. Signed-off-by: Aditya Pakki Reviewed-by: Mukesh Ojha Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin (Microsoft) commit 62d91f5a1ea4598375beca40dc3c094f1854f25a Author: Dan Carpenter Date: Thu Mar 21 09:26:38 2019 +0300 staging: rtl8712: uninitialized memory in read_bbreg_hdl() [ Upstream commit 22c971db7dd4b0ad8dd88e99c407f7a1f4231a2e ] Colin King reported a bug in read_bbreg_hdl(): memcpy(pcmd->rsp, (u8 *)&val, pcmd->rspsz); The problem is that "val" is uninitialized. This code is obviously not useful, but so far as I can tell "pcmd->cmdcode" is never GEN_CMD_CODE(_Read_BBREG) so it's not harmful either. For now the easiest fix is to just call r8712_free_cmd_obj() and return. Fixes: 2865d42c78a9 ("staging: r8712u: Add the new driver to the mainline kernel") Reported-by: Colin Ian King Signed-off-by: Dan Carpenter Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin (Microsoft) commit 6300a60f50b91cedd52baa38ec6623ef49449c08 Author: Aditya Pakki Date: Wed Mar 20 12:02:49 2019 -0500 staging: rtlwifi: rtl8822b: fix to avoid potential NULL pointer dereference [ Upstream commit d70d70aec9632679dd00dcc1b1e8b2517e2c7da0 ] skb allocated via dev_alloc_skb can fail and return a NULL pointer. This patch avoids such a scenario and returns, consistent with other invocations. Signed-off-by: Aditya Pakki Reviewed-by: Mukesh Ojha Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin (Microsoft) commit 5fad07771fb815935c651ca05d754b9fdcdd2a07 Author: Aditya Pakki Date: Wed Mar 20 12:21:35 2019 -0500 staging: rtl8188eu: Fix potential NULL pointer dereference of kcalloc [ Upstream commit 7671ce0d92933762f469266daf43bd34d422d58c ] hwxmits is allocated via kcalloc and not checked for failure before its dereference. The patch fixes this problem by returning error upstream in rtl8723bs, rtl8188eu. Signed-off-by: Aditya Pakki Acked-by: Mukesh Ojha Reviewed-by: Hans de Goede Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin (Microsoft) commit fe4e7a03c7428e6d7d464270a2f5e61345fb73d0 Author: Lukas Wunner Date: Wed Mar 20 15:02:00 2019 +0100 net: ks8851: Set initial carrier state to down [ Upstream commit 9624bafa5f6418b9ca5b3f66d1f6a6a2e8bf6d4c ] The ks8851 chip's initial carrier state is down. A Link Change Interrupt is signaled once interrupts are enabled if the carrier is up. The ks8851 driver has it backwards by assuming that the initial carrier state is up. The state is therefore misrepresented if the interface is opened with no cable attached. Fix it. The Link Change interrupt is sometimes not signaled unless the P1MBSR register (which contains the Link Status bit) is read on ->ndo_open(). This might be a hardware erratum. Read the register by calling mii_check_link(), which has the desirable side effect of setting the carrier state to down if the cable was detached while the interface was closed. Signed-off-by: Lukas Wunner Cc: Frank Pavlic Cc: Ben Dooks Cc: Tristram Ha Signed-off-by: David S. Miller Signed-off-by: Sasha Levin (Microsoft) commit 372b41d6efe32629c6eb4b4f60aa60c76aad20ae Author: Lukas Wunner Date: Wed Mar 20 15:02:00 2019 +0100 net: ks8851: Delay requesting IRQ until opened [ Upstream commit d268f31552794abf5b6aa5af31021643411f25f5 ] The ks8851 driver currently requests the IRQ before registering the net_device. Because the net_device name is used as IRQ name and is still "eth%d" when the IRQ is requested, it's impossibe to tell IRQs apart if multiple ks8851 chips are present. Most other drivers delay requesting the IRQ until the net_device is opened. Do the same. The driver doesn't enable interrupts on the chip before opening the net_device and disables them when closing it, so there doesn't seem to be a need to request the IRQ already on probe. Signed-off-by: Lukas Wunner Cc: Frank Pavlic Cc: Ben Dooks Cc: Tristram Ha Signed-off-by: David S. Miller Signed-off-by: Sasha Levin (Microsoft) commit 860fd08630a6ee7ef0ef78f3820805c2d928b93f Author: Lukas Wunner Date: Wed Mar 20 15:02:00 2019 +0100 net: ks8851: Reassert reset pin if chip ID check fails [ Upstream commit 761cfa979a0c177d6c2d93ef5585cd79ae49a7d5 ] Commit 73fdeb82e963 ("net: ks8851: Add optional vdd_io regulator and reset gpio") amended the ks8851 driver to briefly assert the chip's reset pin on probe. It also amended the probe routine's error path to reassert the reset pin if a subsequent initialization step fails. However the commit misplaced reassertion of the reset pin in the error path such that it is not performed if the check of the Chip ID and Enable Register (CIDER) fails. The error path is therefore slightly asymmetrical to the probe routine's body. Fix it. Signed-off-by: Lukas Wunner Cc: Frank Pavlic Cc: Stephen Boyd Cc: Nishanth Menon Signed-off-by: David S. Miller Signed-off-by: Sasha Levin (Microsoft) commit 75e3e76a45c6fb4f7bfa43fe5a0b623fe3a9545e Author: Lukas Wunner Date: Wed Mar 20 15:02:00 2019 +0100 net: ks8851: Dequeue RX packets explicitly [ Upstream commit 536d3680fd2dab5c39857d62a3e084198fc74ff9 ] The ks8851 driver lets the chip auto-dequeue received packets once they have been read in full. It achieves that by setting the ADRFE flag in the RXQCR register ("Auto-Dequeue RXQ Frame Enable"). However if allocation of a packet's socket buffer or retrieval of the packet over the SPI bus fails, the packet will not have been read in full and is not auto-dequeued. Such partial retrieval of a packet confuses the chip's RX queue management: On the next RX interrupt, the first packet read from the queue will be the one left there previously and this one can be retrieved without issues. But for any newly received packets, the frame header status and byte count registers (RXFHSR and RXFHBCR) contain bogus values, preventing their retrieval. The chip allows explicitly dequeueing a packet from the RX queue by setting the RRXEF flag in the RXQCR register ("Release RX Error Frame"). This could be used to dequeue the packet in case of an error, but if that error is a failed SPI transfer, it is unknown if the packet was transferred in full and was auto-dequeued or if it was only transferred in part and requires an explicit dequeue. The safest approach is thus to always dequeue packets explicitly and forgo auto-dequeueing. Without this change, I've witnessed packet retrieval break completely when an SPI DMA transfer fails, requiring a chip reset. Explicit dequeueing magically fixes this and makes packet retrieval absolutely robust for me. The chip's documentation suggests auto-dequeuing and uses the RRXEF flag only to dequeue error frames which the driver doesn't want to retrieve. But that seems to be a fair-weather approach. Signed-off-by: Lukas Wunner Cc: Frank Pavlic Cc: Ben Dooks Cc: Tristram Ha Signed-off-by: David S. Miller Signed-off-by: Sasha Levin (Microsoft) commit 07c5093a04f824fcbee179d7c7408d47f1ac6931 Author: Suzuki K Poulose Date: Wed Mar 20 14:57:19 2019 +0000 KVM: arm/arm64: Fix handling of stage2 huge mappings [ Upstream commit 3c3736cd32bf5197aed1410ae826d2d254a5b277 ] We rely on the mmu_notifier call backs to handle the split/merge of huge pages and thus we are guaranteed that, while creating a block mapping, either the entire block is unmapped at stage2 or it is missing permission. However, we miss a case where the block mapping is split for dirty logging case and then could later be made block mapping, if we cancel the dirty logging. This not only creates inconsistent TLB entries for the pages in the the block, but also leakes the table pages for PMD level. Handle this corner case for the huge mappings at stage2 by unmapping the non-huge mapping for the block. This could potentially release the upper level table. So we need to restart the table walk once we unmap the range. Fixes : ad361f093c1e31d ("KVM: ARM: Support hugetlbfs backed huge pages") Reported-by: Zheng Xiang Cc: Zheng Xiang Cc: Zenghui Yu Cc: Christoffer Dall Signed-off-by: Suzuki K Poulose Signed-off-by: Marc Zyngier Signed-off-by: Sasha Levin (Microsoft) commit e68cc902c624d7a5cf1ebde8f27e484ab1756da6 Author: Jarkko Nikula Date: Fri Mar 15 12:56:49 2019 +0200 i2c: i801: Add support for Intel Comet Lake [ Upstream commit 5cd1c56c42beb6d228cc8d4373fdc5f5ec78a5ad ] Add PCI ID for Intel Comet Lake PCH. Signed-off-by: Jarkko Nikula Reviewed-by: Jean Delvare Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin (Microsoft) commit bcc78b63f0b44db998062901d4e160d890137d98 Author: Marco Felsch Date: Mon Mar 4 11:49:40 2019 +0100 ARM: dts: pfla02: increase phy reset duration [ Upstream commit 032f85c9360fb1a08385c584c2c4ed114b33c260 ] Increase the reset duration to ensure correct phy functionality. The reset duration is taken from barebox commit 52fdd510de ("ARM: dts: pfla02: use long enough reset for ethernet phy"): Use a longer reset time for ethernet phy Micrel KSZ9031RNX. Otherwise a small percentage of modules have 'transmission timeouts' errors like barebox@Phytec phyFLEX-i.MX6 Quad Carrier-Board:/ ifup eth0 warning: No MAC address set. Using random address 7e:94:4d:02:f8:f3 eth0: 1000Mbps full duplex link detected eth0: transmission timeout T eth0: transmission timeout T eth0: transmission timeout T eth0: transmission timeout T eth0: transmission timeout Cc: Stefan Christ Cc: Christian Hemp Signed-off-by: Marco Felsch Fixes: 3180f956668e ("ARM: dts: Phytec imx6q pfla02 and pbab01 support") Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin (Microsoft) commit 2af87002a5e4545c9c66323b7fbbb3adb17dff20 Author: Guido Kiener Date: Mon Mar 18 09:18:34 2019 +0100 usb: gadget: net2272: Fix net2272_dequeue() [ Upstream commit 091dacc3cc10979ab0422f0a9f7fcc27eee97e69 ] Restore the status of ep->stopped in function net2272_dequeue(). When the given request is not found in the endpoint queue the function returns -EINVAL without restoring the state of ep->stopped. Thus the endpoint keeps blocked and does not transfer any data anymore. This fix is only compile-tested, since we do not have a corresponding hardware. An analogous fix was tested in the sibling driver. See "usb: gadget: net2280: Fix net2280_dequeue()" Acked-by: Alan Stern Signed-off-by: Guido Kiener Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin (Microsoft) commit 202db3b5c17c709f36460af47bcc26aea705472b Author: Guido Kiener Date: Mon Mar 18 09:18:33 2019 +0100 usb: gadget: net2280: Fix net2280_dequeue() [ Upstream commit f1d3fba17cd4eeea20397f1324b7b9c69a6a935c ] When a request must be dequeued with net2280_dequeue() e.g. due to a device clear action and the same request is finished by the function scan_dma_completions() then the function net2280_dequeue() does not find the request in the following search loop and returns the error -EINVAL without restoring the status ep->stopped. Thus the endpoint keeps blocked and does not receive any data anymore. This fix restores the status and does not issue an error message. Acked-by: Alan Stern Signed-off-by: Guido Kiener Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin (Microsoft) commit ad7be5bfe9694eb9f71b260a4e409cecd4b97c77 Author: Guido Kiener Date: Tue Mar 19 19:12:03 2019 +0100 usb: gadget: net2280: Fix overrun of OUT messages [ Upstream commit 9d6a54c1430647355a5e23434881b2ca3d192b48 ] The OUT endpoint normally blocks (NAK) subsequent packets when a short packet was received and returns an incomplete queue entry to the gadget driver. Thereby the gadget driver can detect a short packet when reading queue entries with a length that is not equal to a multiple of packet size. The start_queue() function enables receiving OUT packets regardless of the content of the OUT FIFO. This results in a race: With the current code, it's possible that the "!ep->is_in && (readl(&ep->regs->ep_stat) & BIT(NAK_OUT_PACKETS))" test in start_dma() will fail, then a short packet will be received, and then start_queue() will call stop_out_naking(). That's what we don't want (OUT naking gets turned off while there is data in the FIFO) because then the next driver request might receive a mixture of old and new packets. With the patch, this race can't occur because the FIFO's state is tested after we know that OUT naking is already turned on, and OUT naking is stopped only when both of the conditions are met. This ensures that all received data is delivered to the gadget driver, which can detect a short packet now before new packets are appended to the last short packet. Acked-by: Alan Stern Signed-off-by: Guido Kiener Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin (Microsoft) commit e5a7f0905664cb60d1acc1081102374c298379df Author: Felipe Balbi Date: Thu Jan 31 11:04:19 2019 +0200 usb: dwc3: pci: add support for Comet Lake PCH ID [ Upstream commit 7ae622c978db6b2e28b4fced6ecd2a174492059d ] This patch simply adds a new PCI Device ID Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin (Microsoft) commit 7f482404c11eecd024dbe434272de9fe4acf7c4f Author: Marc Zyngier Date: Tue Mar 19 12:56:23 2019 +0000 KVM: arm/arm64: vgic-its: Take the srcu lock when parsing the memslots [ Upstream commit 7494cec6cb3ba7385a6a223b81906384f15aae34 ] Calling kvm_is_visible_gfn() implies that we're parsing the memslots, and doing this without the srcu lock is frown upon: [12704.164532] ============================= [12704.164544] WARNING: suspicious RCU usage [12704.164560] 5.1.0-rc1-00008-g600025238f51-dirty #16 Tainted: G W [12704.164573] ----------------------------- [12704.164589] ./include/linux/kvm_host.h:605 suspicious rcu_dereference_check() usage! [12704.164602] other info that might help us debug this: [12704.164616] rcu_scheduler_active = 2, debug_locks = 1 [12704.164631] 6 locks held by qemu-system-aar/13968: [12704.164644] #0: 000000007ebdae4f (&kvm->lock){+.+.}, at: vgic_its_set_attr+0x244/0x3a0 [12704.164691] #1: 000000007d751022 (&its->its_lock){+.+.}, at: vgic_its_set_attr+0x250/0x3a0 [12704.164726] #2: 00000000219d2706 (&vcpu->mutex){+.+.}, at: lock_all_vcpus+0x64/0xd0 [12704.164761] #3: 00000000a760aecd (&vcpu->mutex){+.+.}, at: lock_all_vcpus+0x64/0xd0 [12704.164794] #4: 000000000ef8e31d (&vcpu->mutex){+.+.}, at: lock_all_vcpus+0x64/0xd0 [12704.164827] #5: 000000007a872093 (&vcpu->mutex){+.+.}, at: lock_all_vcpus+0x64/0xd0 [12704.164861] stack backtrace: [12704.164878] CPU: 2 PID: 13968 Comm: qemu-system-aar Tainted: G W 5.1.0-rc1-00008-g600025238f51-dirty #16 [12704.164887] Hardware name: rockchip evb_rk3399/evb_rk3399, BIOS 2019.04-rc3-00124-g2feec69fb1 03/15/2019 [12704.164896] Call trace: [12704.164910] dump_backtrace+0x0/0x138 [12704.164920] show_stack+0x24/0x30 [12704.164934] dump_stack+0xbc/0x104 [12704.164946] lockdep_rcu_suspicious+0xcc/0x110 [12704.164958] gfn_to_memslot+0x174/0x190 [12704.164969] kvm_is_visible_gfn+0x28/0x70 [12704.164980] vgic_its_check_id.isra.0+0xec/0x1e8 [12704.164991] vgic_its_save_tables_v0+0x1ac/0x330 [12704.165001] vgic_its_set_attr+0x298/0x3a0 [12704.165012] kvm_device_ioctl_attr+0x9c/0xd8 [12704.165022] kvm_device_ioctl+0x8c/0xf8 [12704.165035] do_vfs_ioctl+0xc8/0x960 [12704.165045] ksys_ioctl+0x8c/0xa0 [12704.165055] __arm64_sys_ioctl+0x28/0x38 [12704.165067] el0_svc_common+0xd8/0x138 [12704.165078] el0_svc_handler+0x38/0x78 [12704.165089] el0_svc+0x8/0xc Make sure the lock is taken when doing this. Fixes: bf308242ab98 ("KVM: arm/arm64: VGIC/ITS: protect kvm_read_guest() calls with SRCU lock") Reviewed-by: Eric Auger Signed-off-by: Marc Zyngier Signed-off-by: Sasha Levin (Microsoft) commit d2eecdbc6ecab9719113fc448d6df4eb387f1148 Author: Marc Zyngier Date: Tue Mar 19 12:47:11 2019 +0000 KVM: arm/arm64: vgic-its: Take the srcu lock when writing to guest memory [ Upstream commit a6ecfb11bf37743c1ac49b266595582b107b61d4 ] When halting a guest, QEMU flushes the virtual ITS caches, which amounts to writing to the various tables that the guest has allocated. When doing this, we fail to take the srcu lock, and the kernel shouts loudly if running a lockdep kernel: [ 69.680416] ============================= [ 69.680819] WARNING: suspicious RCU usage [ 69.681526] 5.1.0-rc1-00008-g600025238f51-dirty #18 Not tainted [ 69.682096] ----------------------------- [ 69.682501] ./include/linux/kvm_host.h:605 suspicious rcu_dereference_check() usage! [ 69.683225] [ 69.683225] other info that might help us debug this: [ 69.683225] [ 69.683975] [ 69.683975] rcu_scheduler_active = 2, debug_locks = 1 [ 69.684598] 6 locks held by qemu-system-aar/4097: [ 69.685059] #0: 0000000034196013 (&kvm->lock){+.+.}, at: vgic_its_set_attr+0x244/0x3a0 [ 69.686087] #1: 00000000f2ed935e (&its->its_lock){+.+.}, at: vgic_its_set_attr+0x250/0x3a0 [ 69.686919] #2: 000000005e71ea54 (&vcpu->mutex){+.+.}, at: lock_all_vcpus+0x64/0xd0 [ 69.687698] #3: 00000000c17e548d (&vcpu->mutex){+.+.}, at: lock_all_vcpus+0x64/0xd0 [ 69.688475] #4: 00000000ba386017 (&vcpu->mutex){+.+.}, at: lock_all_vcpus+0x64/0xd0 [ 69.689978] #5: 00000000c2c3c335 (&vcpu->mutex){+.+.}, at: lock_all_vcpus+0x64/0xd0 [ 69.690729] [ 69.690729] stack backtrace: [ 69.691151] CPU: 2 PID: 4097 Comm: qemu-system-aar Not tainted 5.1.0-rc1-00008-g600025238f51-dirty #18 [ 69.691984] Hardware name: rockchip evb_rk3399/evb_rk3399, BIOS 2019.04-rc3-00124-g2feec69fb1 03/15/2019 [ 69.692831] Call trace: [ 69.694072] lockdep_rcu_suspicious+0xcc/0x110 [ 69.694490] gfn_to_memslot+0x174/0x190 [ 69.694853] kvm_write_guest+0x50/0xb0 [ 69.695209] vgic_its_save_tables_v0+0x248/0x330 [ 69.695639] vgic_its_set_attr+0x298/0x3a0 [ 69.696024] kvm_device_ioctl_attr+0x9c/0xd8 [ 69.696424] kvm_device_ioctl+0x8c/0xf8 [ 69.696788] do_vfs_ioctl+0xc8/0x960 [ 69.697128] ksys_ioctl+0x8c/0xa0 [ 69.697445] __arm64_sys_ioctl+0x28/0x38 [ 69.697817] el0_svc_common+0xd8/0x138 [ 69.698173] el0_svc_handler+0x38/0x78 [ 69.698528] el0_svc+0x8/0xc The fix is to obviously take the srcu lock, just like we do on the read side of things since bf308242ab98. One wonders why this wasn't fixed at the same time, but hey... Fixes: bf308242ab98 ("KVM: arm/arm64: VGIC/ITS: protect kvm_read_guest() calls with SRCU lock") Signed-off-by: Marc Zyngier Signed-off-by: Sasha Levin (Microsoft) commit d6d23d3356721c3949208f9ac35535f104b6e801 Author: Marc Zyngier Date: Wed Mar 13 18:07:50 2019 +0000 arm64: KVM: Always set ICH_HCR_EL2.EN if GICv4 is enabled [ Upstream commit ca71228b42a96908eca7658861eafacd227856c9 ] The normal interrupt flow is not to enable the vgic when no virtual interrupt is to be injected (i.e. the LRs are empty). But when a guest is likely to use GICv4 for LPIs, we absolutely need to switch it on at all times. Otherwise, VLPIs only get delivered when there is something in the LRs, which doesn't happen very often. Reported-by: Nianyao Tang Tested-by: Shameerali Kolothum Thodi Signed-off-by: Marc Zyngier Signed-off-by: Sasha Levin (Microsoft) commit e38694c6b9a8e5a29d8b044acdb53b3e18cc04f1 Author: Marc Zyngier Date: Mon Mar 4 17:37:44 2019 +0000 KVM: arm64: Reset the PMU in preemptible context [ Upstream commit ebff0b0e3d3c862c16c487959db5e0d879632559 ] We've become very cautious to now always reset the vcpu when nothing is loaded on the physical CPU. To do so, we now disable preemption and do a kvm_arch_vcpu_put() to make sure we have all the state in memory (and that it won't be loaded behind out back). This now causes issues with resetting the PMU, which calls into perf. Perf itself uses mutexes, which clashes with the lack of preemption. It is worth realizing that the PMU is fully emulated, and that no PMU state is ever loaded on the physical CPU. This means we can perfectly reset the PMU outside of the non-preemptible section. Fixes: e761a927bc9a ("KVM: arm/arm64: Reset the VCPU without preemption and vcpu state loaded") Reported-by: Julien Grall Tested-by: Julien Grall Signed-off-by: Marc Zyngier Signed-off-by: Sasha Levin (Microsoft) commit 4343cbf52e36d45631efdfb3867475f07cea4e17 Author: Petr Štetiar Date: Wed Mar 6 17:54:03 2019 +0100 serial: ar933x_uart: Fix build failure with disabled console [ Upstream commit 72ff51d8dd262d1fef25baedc2ac35116435be47 ] Andrey has reported on OpenWrt's bug tracking system[1], that he currently can't use ar93xx_uart as pure serial UART without console (CONFIG_SERIAL_8250_CONSOLE and CONFIG_SERIAL_AR933X_CONSOLE undefined), because compilation ends with following error: ar933x_uart.c: In function 'ar933x_uart_console_write': ar933x_uart.c:550:14: error: 'struct uart_port' has no member named 'sysrq' So this patch moves all the code related to console handling behind series of CONFIG_SERIAL_AR933X_CONSOLE ifdefs. 1. https://bugs.openwrt.org/index.php?do=details&task_id=2152 Cc: Greg Kroah-Hartman Cc: Jiri Slaby Cc: Andrey Batyiev Reported-by: Andrey Batyiev Tested-by: Andrey Batyiev Signed-off-by: Petr Štetiar Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin (Microsoft) commit d25b0c89b3b9ab045154497ca344cea5713ced10 Author: Mao Wenan Date: Fri Mar 8 22:08:31 2019 +0800 sc16is7xx: missing unregister/delete driver on error in sc16is7xx_init() [ Upstream commit ac0cdb3d990108df795b676cd0d0e65ac34b2273 ] Add the missing uart_unregister_driver() and i2c_del_driver() before return from sc16is7xx_init() in the error handling case. Signed-off-by: Mao Wenan Reviewed-by: Vladimir Zapolskiy Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin (Microsoft) commit 0bb1f79a14273a388f5a667cfa649d2eb6efdaab Author: Wen Yang Date: Fri Mar 1 16:56:46 2019 +0800 ARM: imx51: fix a leaked reference by adding missing of_node_put [ Upstream commit 0c17e83fe423467e3ccf0a02f99bd050a73bbeb4 ] The call to of_get_next_child returns a node pointer with refcount incremented thus it must be explicitly decremented after the last usage. Detected by coccinelle with the following warnings: ./arch/arm/mach-imx/mach-imx51.c:64:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 57, but without a corresponding object release within this function. Signed-off-by: Wen Yang Cc: Russell King Cc: Shawn Guo Cc: Sascha Hauer Cc: Pengutronix Kernel Team Cc: Fabio Estevam Cc: NXP Linux Team Cc: Lucas Stach Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin (Microsoft) commit 42ed22a8b969cbea8c66f829a0deb991551f3d73 Author: Julian Wiedmann Date: Mon Mar 18 16:40:55 2019 +0100 s390/qeth: fix race when initializing the IP address table [ Upstream commit 7221b727f0079a32aca91f657141e1de564d4b97 ] The ucast IP table is utilized by some of the L3-specific sysfs attributes that qeth_l3_create_device_attributes() provides. So initialize the table _before_ registering the attributes. Fixes: ebccc7397e4a ("s390/qeth: add missing hash table initializations") Signed-off-by: Julian Wiedmann Signed-off-by: David S. Miller Signed-off-by: Sasha Levin (Microsoft) commit f0028f723428b623dd990d34f711acb84e0d9e51 Author: Kangjie Lu Date: Thu Mar 14 02:58:18 2019 -0500 netfilter: ip6t_srh: fix NULL pointer dereferences [ Upstream commit 6d65561f3d5ec933151939c543d006b79044e7a6 ] skb_header_pointer may return NULL. The current code dereference its return values without a NULL check. The fix inserts the checks to avoid NULL pointer dereferences. Fixes: 202a8ff545cc ("netfilter: add IPv6 segment routing header 'srh' match") Signed-off-by: Kangjie Lu Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin (Microsoft) commit 21fde4fcbbd2f64d9805abb3ecbe047ec47f3018 Author: Arnd Bergmann Date: Wed Mar 13 22:15:59 2019 +0100 netfilter: fix NETFILTER_XT_TARGET_TEE dependencies [ Upstream commit d1fa381033eb718df5c602f64b6e88676138dfc6 ] With NETFILTER_XT_TARGET_TEE=y and IP6_NF_IPTABLES=m, we get a link error when referencing the NF_DUP_IPV6 module: net/netfilter/xt_TEE.o: In function `tee_tg6': xt_TEE.c:(.text+0x14): undefined reference to `nf_dup_ipv6' The problem here is the 'select NF_DUP_IPV6 if IP6_NF_IPTABLES' that forces NF_DUP_IPV6 to be =m as well rather than setting it to =y as was intended here. Adding a soft dependency on IP6_NF_IPTABLES avoids that broken configuration. Fixes: 5d400a4933e8 ("netfilter: Kconfig: Change select IPv6 dependencies") Cc: Máté Eckl Cc: Taehee Yoo Link: https://patchwork.ozlabs.org/patch/999498/ Link: https://lore.kernel.org/patchwork/patch/960062/ Reported-by: Randy Dunlap Reported-by: Stephen Rothwell Signed-off-by: Arnd Bergmann Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin (Microsoft) commit eb213c54aaacbad41496302d805c9522a85c2d61 Author: Xin Long Date: Wed Mar 13 16:33:29 2019 +0800 netfilter: bridge: set skb transport_header before entering NF_INET_PRE_ROUTING [ Upstream commit e166e4fdaced850bee3d5ee12a5740258fb30587 ] Since Commit 21d1196a35f5 ("ipv4: set transport header earlier"), skb->transport_header has been always set before entering INET netfilter. This patch is to set skb->transport_header for bridge before entering INET netfilter by bridge-nf-call-iptables. It also fixes an issue that sctp_error() couldn't compute a right csum due to unset skb->transport_header. Fixes: e6d8b64b34aa ("net: sctp: fix and consolidate SCTP checksumming code") Reported-by: Li Shuang Suggested-by: Pablo Neira Ayuso Signed-off-by: Xin Long Acked-by: Neil Horman Acked-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin (Microsoft) commit 0f9c88c5ccc9fb7421d43edcd11622565e8fcdfc Author: Pablo Neira Ayuso Date: Tue Mar 12 12:10:59 2019 +0100 netfilter: nft_set_rbtree: check for inactive element after flag mismatch [ Upstream commit 05b7639da55f5555b9866a1f4b7e8995232a6323 ] Otherwise, we hit bogus ENOENT when removing elements. Fixes: e701001e7cbe ("netfilter: nft_rbtree: allow adjacent intervals with dynamic updates") Reported-by: Václav Zindulka Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin (Microsoft) commit 7f0d096410affc37659366b16663e12debd00c7c Author: Maxim Zhukov Date: Sat Mar 9 12:54:00 2019 +0300 staging, mt7621-pci: fix build without pci support [ Upstream commit 90cd9bed5adb3e3bd4d3ac4cbcecbc4a8028bbaf ] Add depends on PCI for PCI_MT7621 Signed-off-by: Maxim Zhukov Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin (Microsoft) commit 6c41d389904c62758ade7d09a47f18c0125b9f3c Author: Arnd Bergmann Date: Mon Mar 4 20:43:00 2019 +0100 staging: axis-fifo: add CONFIG_OF dependency [ Upstream commit 1beea6204e2304dd11600791d8dad8e7350af6ad ] When building without CONFIG_OF, the compiler loses track of the flow control in axis_fifo_probe(), and thinks that many variables are used without an initialization even though we actually leave the function before the first use: drivers/staging/axis-fifo/axis-fifo.c: In function 'axis_fifo_probe': drivers/staging/axis-fifo/axis-fifo.c:900:5: error: 'rxd_tdata_width' may be used uninitialized in this function [-Werror=maybe-uninitialized] if (rxd_tdata_width != 32) { ^ drivers/staging/axis-fifo/axis-fifo.c:907:5: error: 'txd_tdata_width' may be used uninitialized in this function [-Werror=maybe-uninitialized] if (txd_tdata_width != 32) { ^ drivers/staging/axis-fifo/axis-fifo.c:914:5: error: 'has_tdest' may be used uninitialized in this function [-Werror=maybe-uninitialized] if (has_tdest) { ^ drivers/staging/axis-fifo/axis-fifo.c:919:5: error: 'has_tid' may be used uninitialized in this function [-Werror=maybe-uninitialized] When CONFIG_OF is set, this does not happen, and since the driver cannot work without it, just add that option as a Kconfig dependency. Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin (Microsoft) commit 5227fe96b107d7cbf91d2d8f5093b0a007bb2e7b Author: Björn Töpel Date: Wed Mar 13 15:15:49 2019 +0100 xsk: fix umem memory leak on cleanup [ Upstream commit 044175a06706d516aa42874bb44dbbfc3c4d20eb ] When the umem is cleaned up, the task that created it might already be gone. If the task was gone, the xdp_umem_release function did not free the pages member of struct xdp_umem. It turned out that the task lookup was not needed at all; The code was a left-over when we moved from task accounting to user accounting [1]. This patch fixes the memory leak by removing the task lookup logic completely. [1] https://lore.kernel.org/netdev/20180131135356.19134-3-bjorn.topel@gmail.com/ Link: https://lore.kernel.org/netdev/c1cb2ca8-6a14-3980-8672-f3de0bb38dfd@suse.cz/ Fixes: c0c77d8fb787 ("xsk: add user memory registration support sockopt") Reported-by: Jiri Slaby Signed-off-by: Björn Töpel Signed-off-by: Daniel Borkmann Signed-off-by: Sasha Levin (Microsoft) commit 9fc5c6e8fce8d322c97d479579e06da0bbb7e806 Author: Aditya Pakki Date: Thu Mar 14 15:31:40 2019 -0500 qlcnic: Avoid potential NULL pointer dereference [ Upstream commit 5bf7295fe34a5251b1d241b9736af4697b590670 ] netdev_alloc_skb can fail and return a NULL pointer which is dereferenced without a check. The patch avoids such a scenario. Signed-off-by: Aditya Pakki Signed-off-by: David S. Miller Signed-off-by: Sasha Levin (Microsoft) commit 2e75be8dd6faf8cf21ec1006df732e9e8a947df1 Author: Aaro Koskinen Date: Thu Mar 14 21:43:20 2019 +0200 net: stmmac: fix jumbo frame sending with non-linear skbs [ Upstream commit 58f2ce6f61615dfd8dd3cc01c9e5bb54ed35637e ] When sending non-linear skbs with jumbo frames, we set up the non-paged data and mark that as a last segment, although the paged fragments are also prepared. This will stall the TX queue and trigger a watchdog warning (a simple reproducer is to run an iperf client mode TCP test with a large MTU - networking fails instantly). Fix by checking if the skb is non-linear. Signed-off-by: Aaro Koskinen Acked-by: Jose Abreu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin (Microsoft) commit 53485ee41fc31bab225d9bf8fe6b8301929825f9 Author: Aaro Koskinen Date: Thu Mar 14 21:43:19 2019 +0200 net: stmmac: don't set own bit too early for jumbo frames [ Upstream commit 80acbed9f8fca1db3fbe915540b756f048aa0fd7 ] Commit 0e80bdc9a72d ("stmmac: first frame prep at the end of xmit routine") overlooked jumbo frames when re-ordering the code, and as a result the own bit was not getting set anymore for the first jumbo frame descriptor. Commit 487e2e22ab79 ("net: stmmac: Set OWN bit for jumbo frames") tried to fix this, but now the bit is getting set too early and the DMA may start while we are still setting up the remaining descriptors. And with the chain mode the own bit remains still unset. Fix by setting the own bit at the end of xmit also with jumbo frames. Fixes: 0e80bdc9a72d ("stmmac: first frame prep at the end of xmit routine") Fixes: 487e2e22ab79 ("net: stmmac: Set OWN bit for jumbo frames") Signed-off-by: Aaro Koskinen Acked-by: Jose Abreu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin (Microsoft) commit 099a26557db93b71751d9e380c5e58de83ac2fd5 Author: Filipe Manana Date: Wed Feb 27 13:42:30 2019 +0000 Btrfs: fix file corruption after snapshotting due to mix of buffered/DIO writes [ Upstream commit 609e804d771f59dc5d45a93e5ee0053c74bbe2bf ] When we are mixing buffered writes with direct IO writes against the same file and snapshotting is happening concurrently, we can end up with a corrupt file content in the snapshot. Example: 1) Inode/file is empty. 2) Snapshotting starts. 2) Buffered write at offset 0 length 256Kb. This updates the i_size of the inode to 256Kb, disk_i_size remains zero. This happens after the task doing the snapshot flushes all existing delalloc. 3) DIO write at offset 256Kb length 768Kb. Once the ordered extent completes it sets the inode's disk_i_size to 1Mb (256Kb + 768Kb) and updates the inode item in the fs tree with a size of 1Mb (which is the value of disk_i_size). 4) The dealloc for the range [0, 256Kb[ did not start yet. 5) The transaction used in the DIO ordered extent completion, which updated the inode item, is committed by the snapshotting task. 6) Snapshot creation completes. 7) Dealloc for the range [0, 256Kb[ is flushed. After that when reading the file from the snapshot we always get zeroes for the range [0, 256Kb[, the file has a size of 1Mb and the data written by the direct IO write is found. From an application's point of view this is a corruption, since in the source subvolume it could never read a version of the file that included the data from the direct IO write without the data from the buffered write included as well. In the snapshot's tree, file extent items are missing for the range [0, 256Kb[. The issue, obviously, does not happen when using the -o flushoncommit mount option. Fix this by flushing delalloc for all the roots that are about to be snapshotted when committing a transaction. This guarantees total ordering when updating the disk_i_size of an inode since the flush for dealloc is done when a transaction is in the TRANS_STATE_COMMIT_START state and wait is done once no more external writers exist. This is similar to what we do when using the flushoncommit mount option, but we do it only if the transaction has snapshots to create and only for the roots of the subvolumes to be snapshotted. The bulk of the dealloc is flushed in the snapshot creation ioctl, so the flush work we do inside the transaction is minimized. This issue, involving buffered and direct IO writes with snapshotting, is often triggered by fstest btrfs/078, and got reported by fsck when not using the NO_HOLES features, for example: $ cat results/btrfs/078.full (...) _check_btrfs_filesystem: filesystem on /dev/sdc is inconsistent *** fsck.btrfs output *** [1/7] checking root items [2/7] checking extents [3/7] checking free space cache [4/7] checking fs roots root 258 inode 264 errors 100, file extent discount Found file extent holes: start: 524288, len: 65536 ERROR: errors found in fs roots Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Sasha Levin (Microsoft) commit 61a9e0f4cc865289335d46ac5a46a601c5b4f098 Author: Li RongQing Date: Tue Feb 19 13:10:29 2019 +0800 ieee802154: hwsim: propagate genlmsg_reply return code [ Upstream commit 19b39a25388e71390e059906c979f87be4ef0c71 ] genlmsg_reply can fail, so propagate its return code Signed-off-by: Li RongQing Signed-off-by: Stefan Schmidt Signed-off-by: Sasha Levin (Microsoft) commit 645dc42f97d85f3940275f13831c14c4f93da299 Author: Kangjie Lu Date: Mon Mar 11 02:25:17 2019 -0500 net: ieee802154: fix a potential NULL pointer dereference [ Upstream commit 2795e8c251614ac0784c9d41008551109f665716 ] In case alloc_ordered_workqueue fails, the fix releases sources and returns -ENOMEM to avoid NULL pointer dereference. Signed-off-by: Kangjie Lu Acked-by: Michael Hennerich Signed-off-by: Stefan Schmidt Signed-off-by: Sasha Levin (Microsoft) commit edb6168384083131af64ba77813c3d56cd83c082 Author: Felix Fietkau Date: Sun Mar 3 15:12:14 2019 +0100 mt76: mt76x2: fix 2.4 GHz channel gain settings [ Upstream commit b8cfd87ac24273e36fbd3ecda631f3ba6566d493 ] AGC register 35, 37 override for the low gain setting should only be done on 5 GHz. Also, 2.4 GHz needs a different value for register 35 Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin (Microsoft) commit 63019ec07c615ebb1dc06f4a4bac758a180a0939 Author: Felix Fietkau Date: Sun Mar 3 15:10:00 2019 +0100 mt76: mt76x2: fix external LNA gain settings [ Upstream commit 45a042e3026824a7e910db7a4dd38fef0540b902 ] Devices with external LNA need different values for AGC registers 8 and 9 Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin (Microsoft) commit a495f4c9afbf4dc5da8955ff26035eaeee510e2d Author: Stanislaw Gruszka Date: Thu Feb 28 16:11:06 2019 +0100 mt76x02: fix hdr pointer in write txwi for USB [ Upstream commit 7b25d3b8e485c7721cba9c71b44d1c286e61c8e7 ] Since we add txwi at the begining of skb->data, it no longer point to ieee80211_hdr. This breaks settings TS bit for probe response and beacons. Acked-by: Lorenzo Bianconi Signed-off-by: Stanislaw Gruszka Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin (Microsoft) commit 1d568d7476dac6cf2e312b33b5e68aba2402184c Author: Martin Schwidefsky Date: Mon Mar 4 12:33:28 2019 +0100 s390: limit brk randomization to 32MB [ Upstream commit cd479eccd2e057116d504852814402a1e68ead80 ] For a 64-bit process the randomization of the program break is quite large with 1GB. That is as big as the randomization of the anonymous mapping base, for a test case started with '/lib/ld64.so.1 ' it can happen that the heap is placed after the stack. To avoid this limit the program break randomization to 32MB for 64-bit and keep 8MB for 31-bit. Reported-by: Stefan Liebler Signed-off-by: Martin Schwidefsky Signed-off-by: Sasha Levin (Microsoft) commit 87240adabb460a1ddf205a0cd6e0f3fc731b4654 Author: Helen Koike Date: Mon Mar 4 18:48:37 2019 -0300 ARM: dts: bcm283x: Fix hdmi hpd gpio pull [ Upstream commit 544e784188f1dd7c797c70b213385e67d92005b6 ] Raspberry pi board model B revison 2 have the hot plug detector gpio active high (and not low as it was in the dts). Signed-off-by: Helen Koike Fixes: 49ac67e0c39c ("ARM: bcm2835: Add VC4 to the device tree.") Reviewed-by: Eric Anholt Signed-off-by: Eric Anholt Signed-off-by: Sasha Levin (Microsoft) commit 9979cd3953b972f841eda028e9bf635e9419f658 Author: Takeshi Kihara Date: Thu Feb 21 13:59:38 2019 +0100 arm64: dts: renesas: r8a77990: Fix SCIF5 DMA channels [ Upstream commit e20119f7eaaaf6aad5b44f35155ce500429e17f6 ] According to the R-Car Gen3 Hardware Manual Errata for Rev 1.50 of Feb 12, 2019, the DMA channels for SCIF5 are corrected from 16..47 to 0..15 on R-Car E3. Signed-off-by: Takeshi Kihara Fixes: a5ebe5e49a862e21 ("arm64: dts: renesas: r8a77990: Add SCIF-{0,1,3,4,5} device nodes") Signed-off-by: Geert Uytterhoeven Reviewed-by: Fabrizio Castro Signed-off-by: Simon Horman Signed-off-by: Sasha Levin (Microsoft) commit 27f651142eec95373c7ed6e10a3929fab1733c1a Author: Matthew Wilcox Date: Fri Apr 5 14:02:10 2019 -0700 fs: prevent page refcount overflow in pipe_buf_get commit 15fab63e1e57be9fdb5eec1bbc5916e9825e9acb upstream. Change pipe_buf_get() to return a bool indicating whether it succeeded in raising the refcount of the page (if the thing in the pipe is a page). This removes another mechanism for overflowing the page refcount. All callers converted to handle a failure. Reported-by: Jann Horn Signed-off-by: Matthew Wilcox Cc: stable@kernel.org Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit ad73e3a199066ad9bf48ea1334ef312e5aa078f4 Author: Linus Torvalds Date: Thu Apr 11 10:49:19 2019 -0700 mm: prevent get_user_pages() from overflowing page refcount commit 8fde12ca79aff9b5ba951fce1a2641901b8d8e64 upstream. If the page refcount wraps around past zero, it will be freed while there are still four billion references to it. One of the possible avenues for an attacker to try to make this happen is by doing direct IO on a page multiple times. This patch makes get_user_pages() refuse to take a new page reference if there are already more than two billion references to the page. Reported-by: Jann Horn Acked-by: Matthew Wilcox Cc: stable@kernel.org Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit bdc8dfd6587378458e248e36ab79a129f24ba8e9 Author: Linus Torvalds Date: Thu Apr 11 10:14:59 2019 -0700 mm: add 'try_get_page()' helper function commit 88b1a17dfc3ed7728316478fae0f5ad508f50397 upstream. This is the same as the traditional 'get_page()' function, but instead of unconditionally incrementing the reference count of the page, it only does so if the count was "safe". It returns whether the reference count was incremented (and is marked __must_check, since the caller obviously has to be aware of it). Also like 'get_page()', you can't use this function unless you already had a reference to the page. The intent is that you can use this exactly like get_page(), but in situations where you want to limit the maximum reference count. The code currently does an unconditional WARN_ON_ONCE() if we ever hit the reference count issues (either zero or negative), as a notification that the conditional non-increment actually happened. NOTE! The count access for the "safety" check is inherently racy, but that doesn't matter since the buffer we use is basically half the range of the reference count (ie we look at the sign of the count). Acked-by: Matthew Wilcox Cc: Jann Horn Cc: stable@kernel.org Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 258fc3baeb4b2da15391735fd806facf4a91b585 Author: Linus Torvalds Date: Thu Apr 11 10:06:20 2019 -0700 mm: make page ref count overflow check tighter and more explicit commit f958d7b528b1b40c44cfda5eabe2d82760d868c3 upstream. We have a VM_BUG_ON() to check that the page reference count doesn't underflow (or get close to overflow) by checking the sign of the count. That's all fine, but we actually want to allow people to use a "get page ref unless it's already very high" helper function, and we want that one to use the sign of the page ref (without triggering this VM_BUG_ON). Change the VM_BUG_ON to only check for small underflows (or _very_ close to overflowing), and ignore overflows which have strayed into negative territory. Acked-by: Matthew Wilcox Cc: Jann Horn Cc: stable@kernel.org Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit cc37cb69fbdc69e6bf3c6d74f4e0a56fafd92e93 Author: Ville Syrjälä Date: Tue Mar 26 16:49:02 2019 +0200 drm/i915: Do not enable FEC without DSC commit 5aae7832d1b4ec614996ea0f4fafc4d9855ec0b0 upstream. Currently we enable FEC even when DSC is no used. While that is theoretically valid supposedly there isn't much of a benefit from this. But more importantly we do not account for the FEC link bandwidth overhead (2.4%) in the non-DSC link bandwidth computations. So the code may think we have enough bandwidth when we in fact do not. Cc: stable@vger.kernel.org Cc: Anusha Srivatsa Cc: Manasi Navare Fixes: 240999cf339f ("i915/dp/fec: Add fec_enable to the crtc state.") Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20190326144903.6617-1-ville.syrjala@linux.intel.com Reviewed-by: Manasi Navare (cherry picked from commit 6fd3134ae3551d4802a04669c0f39f2f5c56f77d) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman commit 742c556944e1ff299e3a2e305145c16876b0ed96 Author: Rafael J. Wysocki Date: Tue Apr 30 11:18:21 2019 +0200 Revert "ACPICA: Clear status of GPEs before enabling them" commit 2c2a2fb1e2a9256714338875bede6b7cbd4b9542 upstream. Revert commit c8b1917c8987 ("ACPICA: Clear status of GPEs before enabling them") that causes problems with Thunderbolt controllers to occur if a dock device is connected at init time (the xhci_hcd and thunderbolt modules crash which prevents peripherals connected through them from working). Commit c8b1917c8987 effectively causes commit ecc1165b8b74 ("ACPICA: Dispatch active GPEs at init time") to get undone, so the problem addressed by commit ecc1165b8b74 appears again as a result of it. Fixes: c8b1917c8987 ("ACPICA: Clear status of GPEs before enabling them") Link: https://lore.kernel.org/lkml/s5hy33siofw.wl-tiwai@suse.de/T/#u Link: https://bugzilla.opensuse.org/show_bug.cgi?id=1132943 Reported-by: Michael Hirmke Reported-by: Takashi Iwai Cc: 4.17+ # 4.17+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 635e82b9bdc8a321a0ac80765304f873049bb814 Author: Paulo Alcantara Date: Sun Feb 24 21:55:28 2019 -0300 selinux: use kernel linux/socket.h for genheaders and mdp commit dfbd199a7cfe3e3cd8531e1353cdbd7175bfbc5e upstream. When compiling genheaders and mdp from a newer host kernel, the following error happens: In file included from scripts/selinux/genheaders/genheaders.c:18: ./security/selinux/include/classmap.h:238:2: error: #error New address family defined, please update secclass_map. #error New address family defined, please update secclass_map. ^~~~~ make[3]: *** [scripts/Makefile.host:107: scripts/selinux/genheaders/genheaders] Error 1 make[2]: *** [scripts/Makefile.build:599: scripts/selinux/genheaders] Error 2 make[1]: *** [scripts/Makefile.build:599: scripts/selinux] Error 2 make[1]: *** Waiting for unfinished jobs.... Instead of relying on the host definition, include linux/socket.h in classmap.h to have PF_MAX. Cc: stable@vger.kernel.org Signed-off-by: Paulo Alcantara Acked-by: Stephen Smalley [PM: manually merge in mdp.c, subject line tweaks] Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman