commit b72c392fa3e5d09466cbc8fbf5068b807374ca40 Author: Greg Kroah-Hartman Date: Sat Sep 5 11:24:04 2020 +0200 Linux 5.8.7 Tested-by: Shuah Khan Tested-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 839ab6a84a9b4a5dde371278bb9fa4ce9a8a81f4 Author: Bodo Stroesser Date: Thu Jun 18 15:16:31 2020 +0200 scsi: target: tcmu: Optimize use of flush_dcache_page commit 3c58f737231e2c8cbf543a09d84d8c8e80e05e43 upstream. (scatter|gather)_data_area() need to flush dcache after writing data to or before reading data from a page in uio data area. The two routines are able to handle data transfer to/from such a page in fragments and flush the cache after each fragment was copied by calling the wrapper tcmu_flush_dcache_range(). That means: 1) flush_dcache_page() can be called multiple times for the same page. 2) Calling flush_dcache_page() indirectly using the wrapper does not make sense, because each call of the wrapper is for one single page only and the calling routine already has the correct page pointer. Change (scatter|gather)_data_area() such that, instead of calling tcmu_flush_dcache_range() before/after each memcpy, it now calls flush_dcache_page() before unmapping a page (when writing is complete for that page) or after mapping a page (when starting to read the page). After this change only calls to tcmu_flush_dcache_range() for addresses in vmalloc'ed command ring are left over. The patch was tested on ARM with kernel 4.19.118 and 5.7.2 Link: https://lore.kernel.org/r/20200618131632.32748-2-bstroesser@ts.fujitsu.com Tested-by: JiangYu Tested-by: Daniel Meyerholt Acked-by: Mike Christie Signed-off-by: Bodo Stroesser Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit ba1bc48691d47f56c950c2e048d59e7595c1ca19 Author: Johannes Berg Date: Wed Aug 5 15:35:18 2020 +0200 nl80211: fix NL80211_ATTR_HE_6GHZ_CAPABILITY usage commit fce2ff728f95b8894db14f51c9274dc56c37616f upstream. In nl80211_set_station(), we check NL80211_ATTR_HE_6GHZ_CAPABILITY and then use NL80211_ATTR_HE_CAPABILITY, which is clearly wrong. Fix this to use NL80211_ATTR_HE_6GHZ_CAPABILITY as well. Cc: stable@vger.kernel.org Fixes: 43e64bf301fd ("cfg80211: handle 6 GHz capability of new station") Link: https://lore.kernel.org/r/20200805153516.310cef625955.I0abc04dc8abb2c7c005c88ef8fa2d0e3c9fb95c4@changeid Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 3def2670934b0f98211106eb1b58637336c1d428 Author: Sowjanya Komatineni Date: Thu Aug 27 10:20:56 2020 -0700 sdhci: tegra: Remove SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK for Tegra186 commit 391d89dba8c290859a3e29430d0b9e32c358bb0d upstream. commit 4346b7c7941d ("mmc: tegra: Add Tegra186 support") SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK is set for Tegra186 from the beginning of its support in driver. Tegra186 SDMMC hardware by default uses timeout clock (TMCLK) instead of SDCLK and this quirk should not be set. So, this patch remove this quirk for Tegra186. Fixes: 4346b7c7941d ("mmc: tegra: Add Tegra186 support") Cc: stable # 5.4 Tested-by: Jon Hunter Reviewed-by: Jon Hunter Acked-by: Adrian Hunter Signed-off-by: Sowjanya Komatineni Link: https://lore.kernel.org/r/1598548861-32373-3-git-send-email-skomatineni@nvidia.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 4710fc20adac1392dae68b6568e11b27dda76bdb Author: Sowjanya Komatineni Date: Thu Aug 27 10:20:55 2020 -0700 sdhci: tegra: Remove SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK for Tegra210 commit e33588adcaa925c18ee2ea253161fb0317fa2329 upstream. commit b5a84ecf025a ("mmc: tegra: Add Tegra210 support") SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK is set for Tegra210 from the beginning of Tegra210 support in the driver. Tegra210 SDMMC hardware by default uses timeout clock (TMCLK) instead of SDCLK and this quirk should not be set. So, this patch remove this quirk for Tegra210. Fixes: b5a84ecf025a ("mmc: tegra: Add Tegra210 support") Cc: stable # 5.4 Tested-by: Jon Hunter Reviewed-by: Jon Hunter Acked-by: Adrian Hunter Signed-off-by: Sowjanya Komatineni Link: https://lore.kernel.org/r/1598548861-32373-2-git-send-email-skomatineni@nvidia.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit bb8d1ed450eac81364aea213ddfab32f0be0c134 Author: Sowjanya Komatineni Date: Thu Aug 27 10:20:58 2020 -0700 arm64: tegra: Add missing timeout clock to Tegra210 SDMMC commit 679f71fa0db2d777f39c7a5af7f7c0689fc713fa upstream. commit 742af7e7a0a1 ("arm64: tegra: Add Tegra210 support") Tegra210 uses separate SDMMC_LEGACY_TM clock for data timeout and this clock is not enabled currently which is not recommended. Tegra SDMMC advertises 12Mhz as timeout clock frequency in host capability register. So, this clock should be kept enabled by SDMMC driver. Fixes: 742af7e7a0a1 ("arm64: tegra: Add Tegra210 support") Cc: stable # 5.4 Tested-by: Jon Hunter Reviewed-by: Jon Hunter Signed-off-by: Sowjanya Komatineni Link: https://lore.kernel.org/r/1598548861-32373-5-git-send-email-skomatineni@nvidia.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit eac502d07d498153f115d6f35c2b18b3ec572751 Author: Sowjanya Komatineni Date: Thu Aug 27 10:20:59 2020 -0700 arm64: tegra: Add missing timeout clock to Tegra186 SDMMC nodes commit baba217d2c4446b6eef309d81d8776cb5c68cb55 upstream. commit 39cb62cb8973 ("arm64: tegra: Add Tegra186 support") Tegra186 uses separate SDMMC_LEGACY_TM clock for data timeout and this clock is not enabled currently which is not recommended. Tegra186 SDMMC advertises 12Mhz as timeout clock frequency in host capability register and uses it by default. So, this clock should be kept enabled by the SDMMC driver. Fixes: 39cb62cb8973 ("arm64: tegra: Add Tegra186 support") Cc: stable # 5.4 Tested-by: Jon Hunter Reviewed-by: Jon Hunter Signed-off-by: Sowjanya Komatineni Link: https://lore.kernel.org/r/1598548861-32373-6-git-send-email-skomatineni@nvidia.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit da2d25c3543507aef96b81832e951e1643085210 Author: Sowjanya Komatineni Date: Thu Aug 27 10:21:00 2020 -0700 arm64: tegra: Add missing timeout clock to Tegra194 SDMMC nodes commit c956c0cd4f6f4aac4f095621b1c4e1c5ee1df877 upstream. commit 5425fb15d8ee ("arm64: tegra: Add Tegra194 chip device tree") Tegra194 uses separate SDMMC_LEGACY_TM clock for data timeout and this clock is not enabled currently which is not recommended. Tegra194 SDMMC advertises 12Mhz as timeout clock frequency in host capability register. So, this clock should be kept enabled by SDMMC driver. Fixes: 5425fb15d8ee ("arm64: tegra: Add Tegra194 chip device tree") Cc: stable # 5.4 Tested-by: Jon Hunter Reviewed-by: Jon Hunter Signed-off-by: Sowjanya Komatineni Link: https://lore.kernel.org/r/1598548861-32373-7-git-send-email-skomatineni@nvidia.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 991b02edd133b44fb27c261b52b16795dddf5ae5 Author: Sowjanya Komatineni Date: Thu Aug 27 10:20:57 2020 -0700 dt-bindings: mmc: tegra: Add tmclk for Tegra210 and later commit f7f86e8ac0ad7cd6792a80137f5a550924966916 upstream. commit b5a84ecf025a ("mmc: tegra: Add Tegra210 support") Tegra210 and later uses separate SDMMC_LEGACY_TM clock for data timeout. So, this patch adds "tmclk" to Tegra sdhci clock property in the device tree binding. Fixes: b5a84ecf025a ("mmc: tegra: Add Tegra210 support") Cc: stable # 5.4 Reviewed-by: Jon Hunter Signed-off-by: Sowjanya Komatineni Link: https://lore.kernel.org/r/1598548861-32373-4-git-send-email-skomatineni@nvidia.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 495b506743a1642ac80e9faada2b5ac9ce25294b Author: James Morse Date: Fri Aug 21 15:07:06 2020 +0100 KVM: arm64: Survive synchronous exceptions caused by AT instructions commit 88a84ccccb3966bcc3f309cdb76092a9892c0260 upstream. KVM doesn't expect any synchronous exceptions when executing, any such exception leads to a panic(). AT instructions access the guest page tables, and can cause a synchronous external abort to be taken. The arm-arm is unclear on what should happen if the guest has configured the hardware update of the access-flag, and a memory type in TCR_EL1 that does not support atomic operations. B2.2.6 "Possible implementation restrictions on using atomic instructions" from DDI0487F.a lists synchronous external abort as a possible behaviour of atomic instructions that target memory that isn't writeback cacheable, but the page table walker may behave differently. Make KVM robust to synchronous exceptions caused by AT instructions. Add a get_user() style helper for AT instructions that returns -EFAULT if an exception was generated. While KVM's version of the exception table mixes synchronous and asynchronous exceptions, only one of these can occur at each location. Re-enter the guest when the AT instructions take an exception on the assumption the guest will take the same exception. This isn't guaranteed to make forward progress, as the AT instructions may always walk the page tables, but guest execution may use the translation cached in the TLB. This isn't a problem, as since commit 5dcd0fdbb492 ("KVM: arm64: Defer guest entry when an asynchronous exception is pending"), KVM will return to the host to process IRQs allowing the rest of the system to keep running. Cc: stable@vger.kernel.org # Reviewed-by: Marc Zyngier Signed-off-by: Catalin Marinas Signed-off-by: Andre Przywara Signed-off-by: Greg Kroah-Hartman commit 71e9e3ce6a2cec09652911b62fba40e6ad474ca6 Author: James Morse Date: Fri Aug 21 15:07:05 2020 +0100 KVM: arm64: Add kvm_extable for vaxorcism code commit e9ee186bb735bfc17fa81dbc9aebf268aee5b41e upstream. KVM has a one instruction window where it will allow an SError exception to be consumed by the hypervisor without treating it as a hypervisor bug. This is used to consume asynchronous external abort that were caused by the guest. As we are about to add another location that survives unexpected exceptions, generalise this code to make it behave like the host's extable. KVM's version has to be mapped to EL2 to be accessible on nVHE systems. The SError vaxorcism code is a one instruction window, so has two entries in the extable. Because the KVM code is copied for VHE and nVHE, we end up with four entries, half of which correspond with code that isn't mapped. Signed-off-by: James Morse Reviewed-by: Marc Zyngier Signed-off-by: Catalin Marinas Signed-off-by: Andre Przywara Signed-off-by: Greg Kroah-Hartman commit 5b1c0ed9ff3c706ba49efd32eac466ed34825c23 Author: Peilin Ye Date: Mon Jul 27 10:00:02 2020 +0200 media: media/v4l2-core: Fix kernel-infoleak in video_put_user() commit 4ffb879ea648c2b42da4ca992ed3db87e564af69 upstream. video_put_user() is copying uninitialized stack memory to userspace due to the compiler not initializing holes in the structures declared on the stack. Fix it by initializing `ev32` and `vb32` using memset(). Reported-and-tested-by: syzbot+79d751604cb6f29fbf59@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?extid=79d751604cb6f29fbf59 Cc: stable@vger.kernel.org Fixes: 1a6c0b36dd19 ("media: v4l2-core: fix VIDIOC_DQEVENT for time64 ABI") Fixes: 577c89b0ce72 ("media: v4l2-core: fix v4l2_buffer handling for time64 ABI") Reviewed-by: Laurent Pinchart Reviewed-by: Arnd Bergmann Signed-off-by: Peilin Ye Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit ff95152b14f2aaaf410d1f0cfe645f84d1d59e66 Author: Kim Phillips Date: Tue Sep 1 16:58:53 2020 -0500 perf record/stat: Explicitly call out event modifiers in the documentation commit e48a73a312ebf19cc3d72aa74985db25c30757c1 upstream. Event modifiers are not mentioned in the perf record or perf stat manpages. Add them to orient new users more effectively by pointing them to the perf list manpage for details. Fixes: 2055fdaf8703 ("perf list: Document precise event sampling for AMD IBS") Signed-off-by: Kim Phillips Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Alexey Budankov Cc: Ian Rogers Cc: Jin Yao Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Paul Clarke Cc: Peter Zijlstra Cc: Stephane Eranian Cc: Tony Jones Cc: stable@vger.kernel.org Link: http://lore.kernel.org/lkml/20200901215853.276234-1-kim.phillips@amd.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 20257b70d5f154a480b542150720d6f54fad2ca5 Author: Andy Lutomirski Date: Thu Sep 3 13:40:30 2020 -0700 selftests/x86/test_vsyscall: Improve the process_vm_readv() test commit 8891adc61dce2a8a41fc0c23262b681c3ec4b73a upstream. The existing code accepted process_vm_readv() success or failure as long as it didn't return garbage. This is too weak: if the vsyscall page is readable, then process_vm_readv() should succeed and, if the page is not readable, then it should fail. Signed-off-by: Andy Lutomirski Signed-off-by: Dave Hansen Cc: x86@kernel.org Cc: Peter Zijlstra Cc: Andy Lutomirski Cc: Jann Horn Cc: John Hubbard Cc: Andrew Morton Cc: Kirill A. Shutemov Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit e80a7602b405dfac44aa4e81eec6d51d9e9fad8e Author: Dave Hansen Date: Thu Sep 3 13:40:28 2020 -0700 mm: fix pin vs. gup mismatch with gate pages commit 9fa2dd946743ae6f30dc4830da19147bf100a7f2 upstream. Gate pages were missed when converting from get to pin_user_pages(). This can lead to refcount imbalances. This is reliably and quickly reproducible running the x86 selftests when vsyscall=emulate is enabled (the default). Fix by using try_grab_page() with appropriate flags passed. The long story: Today, pin_user_pages() and get_user_pages() are similar interfaces for manipulating page reference counts. However, "pins" use a "bias" value and manipulate the actual reference count by 1024 instead of 1 used by plain "gets". That means that pin_user_pages() must be matched with unpin_user_pages() and can't be mixed with a plain put_user_pages() or put_page(). Enter gate pages, like the vsyscall page. They are pages usually in the kernel image, but which are mapped to userspace. Userspace is allowed access to them, including interfaces using get/pin_user_pages(). The refcount of these kernel pages is manipulated just like a normal user page on the get/pin side so that the put/unpin side can work the same for normal user pages or gate pages. get_gate_page() uses try_get_page() which only bumps the refcount by 1, not 1024, even if called in the pin_user_pages() path. If someone pins a gate page, this happens: pin_user_pages() get_gate_page() try_get_page() // bump refcount +1 ... some time later unpin_user_pages() page_ref_sub_and_test(page, 1024)) ... and boom, we get a refcount off by 1023. This is reliably and quickly reproducible running the x86 selftests when booted with vsyscall=emulate (the default). The selftests use ptrace(), but I suspect anything using pin_user_pages() on gate pages could hit this. To fix it, simply use try_grab_page() instead of try_get_page(), and pass 'gup_flags' in so that FOLL_PIN can be respected. This bug traces back to the very beginning of the FOLL_PIN support in commit 3faa52c03f44 ("mm/gup: track FOLL_PIN pages"), which showed up in the 5.7 release. Signed-off-by: Dave Hansen Fixes: 3faa52c03f44 ("mm/gup: track FOLL_PIN pages") Reported-by: Peter Zijlstra Reviewed-by: John Hubbard Acked-by: Andy Lutomirski Cc: x86@kernel.org Cc: Jann Horn Cc: Andrew Morton Cc: Kirill A. Shutemov Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 331524770431a9138451483cd92c4e0e07f9c71c Author: Stefano Brivio Date: Wed Aug 19 23:59:14 2020 +0200 netfilter: nft_set_rbtree: Handle outcomes of tree rotations in overlap detection commit 226a88de473e475cb9f993682a1c7d0c2b451ad8 upstream. Checks for partial overlaps on insertion assume that end elements are always descendant nodes of their corresponding start, because they are inserted later. However, this is not the case if a previous delete operation caused a tree rotation as part of rebalancing. Taking the issue reported by Andreas Fischer as an example, if we omit delete operations, the existing procedure works because, equivalently, we are inserting a start item with value 40 in the this region of the red-black tree with single-sized intervals: overlap flag 10 (start) / \ false 20 (start) / \ false 30 (start) / \ false 60 (start) / \ false 50 (end) / \ false 20 (end) / \ false 40 (start) if we now delete interval 30 - 30, the tree can be rearranged in a way similar to this (note the rotation involving 50 - 50): overlap flag 10 (start) / \ false 20 (start) / \ false 25 (start) / \ false 70 (start) / \ false 50 (end) / \ true (from rule a1.) 50 (start) / \ true 40 (start) and we traverse interval 50 - 50 from the opposite direction compared to what was expected. To deal with those cases, add a start-before-start rule, b4., that covers traversal of existing intervals from the right. We now need to restrict start-after-end rule b3. to cases where there are no occurring nodes between existing start and end elements, because addition of rule b4. isn't sufficient to ensure that the pre-existing end element we encounter while descending the tree corresponds to a start element of an interval that we already traversed entirely. Different types of overlap detection on trees with rotations resulting from re-balancing will be covered by nft test case sets/0044interval_overlap_1. Reported-by: Andreas Fischer Bugzilla: https://bugzilla.netfilter.org/show_bug.cgi?id=1449 Cc: # 5.6.x Fixes: 7c84d41416d8 ("netfilter: nft_set_rbtree: Detect partial overlaps on insertion") Signed-off-by: Stefano Brivio Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit e771e63c0cdca5f127dbe1bed80f928da7f51673 Author: Marc Zyngier Date: Tue Sep 1 10:52:33 2020 +0100 HID: core: Sanitize event code and type when mapping input commit 35556bed836f8dc07ac55f69c8d17dce3e7f0e25 upstream. When calling into hid_map_usage(), the passed event code is blindly stored as is, even if it doesn't fit in the associated bitmap. This event code can come from a variety of sources, including devices masquerading as input devices, only a bit more "programmable". Instead of taking the event code at face value, check that it actually fits the corresponding bitmap, and if it doesn't: - spit out a warning so that we know which device is acting up - NULLify the bitmap pointer so that we catch unexpected uses Code paths that can make use of untrusted inputs can now check that the mapping was indeed correct and bail out if not. Cc: stable@vger.kernel.org Signed-off-by: Marc Zyngier Signed-off-by: Benjamin Tissoires Signed-off-by: Greg Kroah-Hartman commit b070b1e2076809ea192d4f3344833afcfdaf146d Author: Marc Zyngier Date: Sat Aug 29 12:26:01 2020 +0100 HID: core: Correctly handle ReportSize being zero commit bce1305c0ece3dc549663605e567655dd701752c upstream. It appears that a ReportSize value of zero is legal, even if a bit non-sensical. Most of the HID code seems to handle that gracefully, except when computing the total size in bytes. When fed as input to memset, this leads to some funky outcomes. Detect the corner case and correctly compute the size. Cc: stable@vger.kernel.org Signed-off-by: Marc Zyngier Signed-off-by: Benjamin Tissoires Signed-off-by: Greg Kroah-Hartman