commit 8df7025920ebbbd8b523fc052e28cc65acb44591 Author: Greg Kroah-Hartman Date: Wed Dec 16 10:58:38 2020 +0100 Linux 5.9.15 Tested-by: Jeffrin Jose T Tested-by: Shuah Khan Tested-by: Linux Kernel Functional Testing Tested-by: Jon Hunter Tested-by: Guenter Roeck Link: https://lore.kernel.org/r/20201214172555.280929671@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit 54ddef488732546219d457830641e6452d8056f9 Author: Arvind Sankar Date: Fri Nov 13 22:51:59 2020 -0800 compiler.h: fix barrier_data() on clang commit 3347acc6fcd4ee71ad18a9ff9d9dac176b517329 upstream. Commit 815f0ddb346c ("include/linux/compiler*.h: make compiler-*.h mutually exclusive") neglected to copy barrier_data() from compiler-gcc.h into compiler-clang.h. The definition in compiler-gcc.h was really to work around clang's more aggressive optimization, so this broke barrier_data() on clang, and consequently memzero_explicit() as well. For example, this results in at least the memzero_explicit() call in lib/crypto/sha256.c:sha256_transform() being optimized away by clang. Fix this by moving the definition of barrier_data() into compiler.h. Also move the gcc/clang definition of barrier() into compiler.h, __memory_barrier() is icc-specific (and barrier() is already defined using it in compiler-intel.h) and doesn't belong in compiler.h. [rdunlap@infradead.org: fix ALPHA builds when SMP is not enabled] Link: https://lkml.kernel.org/r/20201101231835.4589-1-rdunlap@infradead.org Fixes: 815f0ddb346c ("include/linux/compiler*.h: make compiler-*.h mutually exclusive") Signed-off-by: Arvind Sankar Signed-off-by: Randy Dunlap Signed-off-by: Andrew Morton Tested-by: Nick Desaulniers Reviewed-by: Nick Desaulniers Reviewed-by: Kees Cook Cc: Link: https://lkml.kernel.org/r/20201014212631.207844-1-nivedita@alum.mit.edu Signed-off-by: Linus Torvalds Signed-off-by: Nick Desaulniers Signed-off-by: Greg Kroah-Hartman commit d4f949439d2748209b004b4003e21285e580909d Author: Masami Hiramatsu Date: Fri Dec 11 16:04:17 2020 +0900 x86/kprobes: Fix optprobe to detect INT3 padding correctly commit 0d07c0ec4381f630c801539c79ad8dcc627f6e4a upstream. Commit 7705dc855797 ("x86/vmlinux: Use INT3 instead of NOP for linker fill bytes") changed the padding bytes between functions from NOP to INT3. However, when optprobe decodes a target function it finds INT3 and gives up the jump optimization. Instead of giving up any INT3 detection, check whether the rest of the bytes to the end of the function are INT3. If all of them are INT3, those come from the linker. In that case, continue the optprobe jump optimization. [ bp: Massage commit message. ] Fixes: 7705dc855797 ("x86/vmlinux: Use INT3 instead of NOP for linker fill bytes") Reported-by: Adam Zabrocki Signed-off-by: Masami Hiramatsu Signed-off-by: Borislav Petkov Reviewed-by: Steven Rostedt (VMware) Reviewed-by: Kees Cook Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/160767025681.3880685.16021570341428835411.stgit@devnote2 Signed-off-by: Greg Kroah-Hartman commit 6c12baff9e1e6b60d693448a5111f2e66241982e Author: Thomas Gleixner Date: Thu Dec 10 21:18:22 2020 +0100 x86/apic/vector: Fix ordering in vector assignment commit 190113b4c6531c8e09b31d5235f9b5175cbb0f72 upstream. Prarit reported that depending on the affinity setting the ' irq $N: Affinity broken due to vector space exhaustion.' message is showing up in dmesg, but the vector space on the CPUs in the affinity mask is definitely not exhausted. Shung-Hsi provided traces and analysis which pinpoints the problem: The ordering of trying to assign an interrupt vector in assign_irq_vector_any_locked() is simply wrong if the interrupt data has a valid node assigned. It does: 1) Try the intersection of affinity mask and node mask 2) Try the node mask 3) Try the full affinity mask 4) Try the full online mask Obviously #2 and #3 are in the wrong order as the requested affinity mask has to take precedence. In the observed cases #1 failed because the affinity mask did not contain CPUs from node 0. That made it allocate a vector from node 0, thereby breaking affinity and emitting the misleading message. Revert the order of #2 and #3 so the full affinity mask without the node intersection is tried before actually affinity is broken. If no node is assigned then only the full affinity mask and if that fails the full online mask is tried. Fixes: d6ffc6ac83b1 ("x86/vector: Respect affinity mask in irq descriptor") Reported-by: Prarit Bhargava Reported-by: Shung-Hsi Yu Signed-off-by: Thomas Gleixner Tested-by: Shung-Hsi Yu Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/87ft4djtyp.fsf@nanos.tec.linutronix.de Signed-off-by: Greg Kroah-Hartman commit f114de3c03bd1406c0c110a5dee589365dc88a68 Author: Andy Lutomirski Date: Thu Dec 3 21:07:03 2020 -0800 x86/membarrier: Get rid of a dubious optimization commit a493d1ca1a03b532871f1da27f8dbda2b28b04c4 upstream. sync_core_before_usermode() had an incorrect optimization. If the kernel returns from an interrupt, it can get to usermode without IRET. It just has to schedule to a different task in the same mm and do SYSRET. Fortunately, there were no callers of sync_core_before_usermode() that could have had in_irq() or in_nmi() equal to true, because it's only ever called from the scheduler. While at it, clarify a related comment. Fixes: 70216e18e519 ("membarrier: Provide core serializing command, *_SYNC_CORE") Signed-off-by: Andy Lutomirski Signed-off-by: Thomas Gleixner Reviewed-by: Mathieu Desnoyers Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/5afc7632be1422f91eaf7611aaaa1b5b8580a086.1607058304.git.luto@kernel.org Signed-off-by: Greg Kroah-Hartman commit c31a444c48981106aab63ca4297d285e47d260cf Author: Arvind Sankar Date: Wed Nov 11 11:09:45 2020 -0500 x86/mm/mem_encrypt: Fix definition of PMD_FLAGS_DEC_WP commit 29ac40cbed2bc06fa218ca25d7f5e280d3d08a25 upstream. The PAT bit is in different locations for 4k and 2M/1G page table entries. Add a definition for _PAGE_LARGE_CACHE_MASK to represent the three caching bits (PWT, PCD, PAT), similar to _PAGE_CACHE_MASK for 4k pages, and use it in the definition of PMD_FLAGS_DEC_WP to get the correct PAT index for write-protected pages. Fixes: 6ebcb060713f ("x86/mm: Add support to encrypt the kernel in-place") Signed-off-by: Arvind Sankar Signed-off-by: Borislav Petkov Tested-by: Tom Lendacky Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20201111160946.147341-1-nivedita@alum.mit.edu Signed-off-by: Greg Kroah-Hartman commit 7882c999402d508c9f5719def5aef35fb5c68a94 Author: Dan Carpenter Date: Thu Dec 3 15:18:26 2020 +0300 scsi: be2iscsi: Revert "Fix a theoretical leak in beiscsi_create_eqs()" commit eeaf06af6f87e1dba371fbe42674e6f963220b9c upstream. My patch caused kernel Oopses and delays in boot. Revert it. The problem was that I moved the "mem->dma = paddr;" before the call to be_fill_queue(). But the first thing that the be_fill_queue() function does is memset the whole struct to zero which overwrites the assignment. Link: https://lore.kernel.org/r/X8jXkt6eThjyVP1v@mwanda Fixes: 38b2db564d9a ("scsi: be2iscsi: Fix a theoretical leak in beiscsi_create_eqs()") Cc: stable Reported-by: Thomas Lamprecht Signed-off-by: Dan Carpenter Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 6134dd87124ebf68b8e7397260a1a9ab28d3b919 Author: Damien Le Moal Date: Wed Dec 9 20:16:10 2020 +0900 zonefs: fix page reference and BIO leak commit 6bea0225a4bf14a58af71cb9677a756921469e46 upstream. In zonefs_file_dio_append(), the pages obtained using bio_iov_iter_get_pages() are not released on completion of the REQ_OP_APPEND BIO, nor when bio_iov_iter_get_pages() fails. Furthermore, a call to bio_put() is missing when bio_iov_iter_get_pages() fails. Fix these resource leaks by adding BIO resource release code (bio_put()i and bio_release_pages()) at the end of the function after the BIO execution and add a jump to this resource cleanup code in case of bio_iov_iter_get_pages() failure. While at it, also fix the call to task_io_account_write() to be passed the correct BIO size instead of bio_iov_iter_get_pages() return value. Reported-by: Christoph Hellwig Fixes: 02ef12a663c7 ("zonefs: use REQ_OP_ZONE_APPEND for sync DIO") Cc: stable@vger.kernel.org Signed-off-by: Damien Le Moal Reviewed-by: Chaitanya Kulkarni Reviewed-by: Christoph Hellwig Signed-off-by: Greg Kroah-Hartman commit f422f9c6479c5a05db490eca2f960bbbc47daf15 Author: Gerald Schaefer Date: Fri Dec 11 13:36:53 2020 -0800 mm/hugetlb: clear compound_nr before freeing gigantic pages commit ba9c1201beaa86a773e83be5654602a0667e4a4d upstream. Commit 1378a5ee451a ("mm: store compound_nr as well as compound_order") added compound_nr counter to first tail struct page, overlaying with page->mapping. The overlay itself is fine, but while freeing gigantic hugepages via free_contig_range(), a "bad page" check will trigger for non-NULL page->mapping on the first tail page: BUG: Bad page state in process bash pfn:380001 page:00000000c35f0856 refcount:0 mapcount:0 mapping:00000000126b68aa index:0x0 pfn:0x380001 aops:0x0 flags: 0x3ffff00000000000() raw: 3ffff00000000000 0000000000000100 0000000000000122 0000000100000000 raw: 0000000000000000 0000000000000000 ffffffff00000000 0000000000000000 page dumped because: non-NULL mapping Modules linked in: CPU: 6 PID: 616 Comm: bash Not tainted 5.10.0-rc7-next-20201208 #1 Hardware name: IBM 3906 M03 703 (LPAR) Call Trace: show_stack+0x6e/0xe8 dump_stack+0x90/0xc8 bad_page+0xd6/0x130 free_pcppages_bulk+0x26a/0x800 free_unref_page+0x6e/0x90 free_contig_range+0x94/0xe8 update_and_free_page+0x1c4/0x2c8 free_pool_huge_page+0x11e/0x138 set_max_huge_pages+0x228/0x300 nr_hugepages_store_common+0xb8/0x130 kernfs_fop_write+0xd2/0x218 vfs_write+0xb0/0x2b8 ksys_write+0xac/0xe0 system_call+0xe6/0x288 Disabling lock debugging due to kernel taint This is because only the compound_order is cleared in destroy_compound_gigantic_page(), and compound_nr is set to 1U << order == 1 for order 0 in set_compound_order(page, 0). Fix this by explicitly clearing compound_nr for first tail page after calling set_compound_order(page, 0). Link: https://lkml.kernel.org/r/20201208182813.66391-2-gerald.schaefer@linux.ibm.com Fixes: 1378a5ee451a ("mm: store compound_nr as well as compound_order") Signed-off-by: Gerald Schaefer Reviewed-by: Matthew Wilcox (Oracle) Cc: Heiko Carstens Cc: Mike Kravetz Cc: Christian Borntraeger Cc: [5.9+] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 974780e134da906a555b2b78be2dea1fa154ad49 Author: Miles Chen Date: Fri Dec 11 13:36:31 2020 -0800 proc: use untagged_addr() for pagemap_read addresses commit 40d6366e9d86d9a67b5642040e76082fdb5bdcf9 upstream. When we try to visit the pagemap of a tagged userspace pointer, we find that the start_vaddr is not correct because of the tag. To fix it, we should untag the userspace pointers in pagemap_read(). I tested with 5.10-rc4 and the issue remains. Explanation from Catalin in [1]: "Arguably, that's a user-space bug since tagged file offsets were never supported. In this case it's not even a tag at bit 56 as per the arm64 tagged address ABI but rather down to bit 47. You could say that the problem is caused by the C library (malloc()) or whoever created the tagged vaddr and passed it to this function. It's not a kernel regression as we've never supported it. Now, pagemap is a special case where the offset is usually not generated as a classic file offset but rather derived by shifting a user virtual address. I guess we can make a concession for pagemap (only) and allow such offset with the tag at bit (56 - PAGE_SHIFT + 3)" My test code is based on [2]: A userspace pointer which has been tagged by 0xb4: 0xb400007662f541c8 userspace program: uint64 OsLayer::VirtualToPhysical(void *vaddr) { uint64 frame, paddr, pfnmask, pagemask; int pagesize = sysconf(_SC_PAGESIZE); off64_t off = ((uintptr_t)vaddr) / pagesize * 8; // off = 0xb400007662f541c8 / pagesize * 8 = 0x5a00003b317aa0 int fd = open(kPagemapPath, O_RDONLY); ... if (lseek64(fd, off, SEEK_SET) != off || read(fd, &frame, 8) != 8) { int err = errno; string errtxt = ErrorString(err); if (fd >= 0) close(fd); return 0; } ... } kernel fs/proc/task_mmu.c: static ssize_t pagemap_read(struct file *file, char __user *buf, size_t count, loff_t *ppos) { ... src = *ppos; svpfn = src / PM_ENTRY_BYTES; // svpfn == 0xb400007662f54 start_vaddr = svpfn << PAGE_SHIFT; // start_vaddr == 0xb400007662f54000 end_vaddr = mm->task_size; /* watch out for wraparound */ // svpfn == 0xb400007662f54 // (mm->task_size >> PAGE) == 0x8000000 if (svpfn > mm->task_size >> PAGE_SHIFT) // the condition is true because of the tag 0xb4 start_vaddr = end_vaddr; ret = 0; while (count && (start_vaddr < end_vaddr)) { // we cannot visit correct entry because start_vaddr is set to end_vaddr int len; unsigned long end; ... } ... } [1] https://lore.kernel.org/patchwork/patch/1343258/ [2] https://github.com/stressapptest/stressapptest/blob/master/src/os.cc#L158 Link: https://lkml.kernel.org/r/20201204024347.8295-1-miles.chen@mediatek.com Signed-off-by: Miles Chen Reviewed-by: Vincenzo Frascino Reviewed-by: Catalin Marinas Cc: Alexey Dobriyan Cc: Andrey Konovalov Cc: Alexander Potapenko Cc: Vincenzo Frascino Cc: Andrey Ryabinin Cc: Catalin Marinas Cc: Dmitry Vyukov Cc: Marco Elver Cc: Will Deacon Cc: Eric W. Biederman Cc: Song Bao Hua (Barry Song) Cc: [5.4-] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit d673586ec6282c30f6525c341f1a98e2fa92b532 Author: Arnd Bergmann Date: Fri Dec 11 13:36:38 2020 -0800 kbuild: avoid static_assert for genksyms commit 14dc3983b5dff513a90bd5a8cc90acaf7867c3d0 upstream. genksyms does not know or care about the _Static_assert() built-in, and sometimes falls back to ignoring the later symbols, which causes undefined behavior such as WARNING: modpost: EXPORT symbol "ethtool_set_ethtool_phy_ops" [vmlinux] version generation failed, symbol will not be versioned. ld: net/ethtool/common.o: relocation R_AARCH64_ABS32 against `__crc_ethtool_set_ethtool_phy_ops' can not be used when making a shared object net/ethtool/common.o:(_ftrace_annotated_branch+0x0): dangerous relocation: unsupported relocation Redefine static_assert for genksyms to avoid that. Link: https://lkml.kernel.org/r/20201203230955.1482058-1-arnd@kernel.org Signed-off-by: Arnd Bergmann Suggested-by: Ard Biesheuvel Cc: Masahiro Yamada Cc: Michal Marek Cc: Kees Cook Cc: Rikard Falkeborn Cc: Marco Elver Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 4724f74c419c8e00d7ce17724e472a946a5f115b Author: Stanley.Yang Date: Mon Dec 7 14:38:33 2020 +0800 drm/amdgpu: fix sdma instance fw version and feature version init commit 6896887b8676d8fb445c85ea56333b9661a6a8aa upstream. each sdma instance fw_version and feature_version should be set right value when asic type isn't between SIENNA_CICHILD and CHIP_DIMGREY_CAVEFISH Signed-off-by: Stanley.Yang Reviewed-by: Tao Zhou Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 43013b6eb92458c5e2f68e90e08dfd75a3f3d9d0 Author: Chris Wilson Date: Fri Dec 4 15:12:32 2020 +0000 drm/i915/gt: Cancel the preemption timeout on responding to it commit 0fe8bf4d3edce7aad6c14b9d5d92ff54dc19f0ba upstream. We currently presume that the engine reset is successful, cancelling the expired preemption timer in the process. However, engine resets can fail, leaving the timeout still pending and we will then respond to the timeout again next time the tasklet fires. What we want is for the failed engine reset to be promoted to a full device reset, which is kicked by the heartbeat once the engine stops processing events. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1168 Fixes: 3a7a92aba8fb ("drm/i915/execlists: Force preemption") Signed-off-by: Chris Wilson Cc: # v5.5+ Reviewed-by: Mika Kuoppala Link: https://patchwork.freedesktop.org/patch/msgid/20201204151234.19729-2-chris@chris-wilson.co.uk (cherry picked from commit d997e240ceecb4f732611985d3a939ad1bfc1893) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman commit b20eb804cf6187ed96be15b59612449f42b404c9 Author: Chris Wilson Date: Fri Dec 4 15:12:31 2020 +0000 drm/i915/gt: Ignore repeated attempts to suspend request flow across reset commit 5419d93ffd774127b195b8543b063b2b4fa5aea9 upstream. Before reseting the engine, we suspend the execution of the guilty request, so that we can continue execution with a new context while we slowly compress the captured error state for the guilty context. However, if the reset fails, we will promptly attempt to reset the same request again, and discover the ongoing capture. Ignore the second attempt to suspend and capture the same request. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1168 Fixes: 32ff621fd744 ("drm/i915/gt: Allow temporary suspension of inflight requests") Signed-off-by: Chris Wilson Cc: # v5.7+ Reviewed-by: Mika Kuoppala Link: https://patchwork.freedesktop.org/patch/msgid/20201204151234.19729-1-chris@chris-wilson.co.uk (cherry picked from commit b969540500bce60cf1cdfff5464388af32b9a553) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman commit a62810c0e624036a98102505dad06ad8bfcf09e0 Author: Chris Wilson Date: Fri Nov 27 10:25:40 2020 +0000 drm/i915/gt: Declare gen9 has 64 mocs entries! commit 7c5c15dffe1e3c42f44735ce9552afb7207f1584 upstream. We checked the table size against a hardcoded number of entries, and that number was excluding the special mocs registers at the end. Fixes: 777a7717d60c ("drm/i915/gt: Program mocs:63 for cache eviction on gen9") Signed-off-by: Chris Wilson Cc: # v4.3+ Reviewed-by: Tvrtko Ursulin Link: https://patchwork.freedesktop.org/patch/msgid/20201127102540.13117-1-chris@chris-wilson.co.uk (cherry picked from commit 444fbf5d7058099447c5366ba8bb60d610aeb44b) Signed-off-by: Rodrigo Vivi [backported and updated the Fixes sha] Signed-off-by: Greg Kroah-Hartman commit 471ae7835e5f25955a2f81409508594918f75201 Author: Manasi Navare Date: Fri Dec 4 12:58:04 2020 -0800 drm/i915/display/dp: Compute the correct slice count for VDSC on DP commit f6cbe49be65ed800863ac5ba695555057363f9c2 upstream. This patch fixes the slice count computation algorithm for calculating the slice count based on Peak pixel rate and the max slice width allowed on the DSC engines. We need to ensure slice count > min slice count req as per DP spec based on peak pixel rate and that it is greater than min slice count based on the max slice width advertised by DPCD. So use max of these two. In the prev patch we were using min of these 2 causing it to violate the max slice width limitation causing a blank screen on 8K@60. Fixes: d9218c8f6cf4 ("drm/i915/dp: Add helpers for Compressed BPP and Slice Count for DSC") Cc: Ankit Nautiyal Cc: Jani Nikula Cc: # v5.0+ Signed-off-by: Manasi Navare Reviewed-by: Ankit Nautiyal Link: https://patchwork.freedesktop.org/patch/msgid/20201204205804.25225-1-manasi.d.navare@intel.com (cherry picked from commit d371d6ea92ad2a47f42bbcaa786ee5f6069c9c14) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman commit dcfeb303a2b57b97187cd8220e347f5ee861a633 Author: Chris Wilson Date: Thu Dec 3 10:34:32 2020 +0000 drm/i915/gem: Propagate error from cancelled submit due to context closure commit 0e124e19ce52d20b28ee9f1d5cdb22e2106bfd29 upstream. In the course of discovering and closing many races with context closure and execbuf submission, since commit 61231f6bd056 ("drm/i915/gem: Check that the context wasn't closed during setup") we started checking that the context was not closed by another userspace thread during the execbuf ioctl. In doing so we cancelled the inflight request (by telling it to be skipped), but kept reporting success since we do submit a request, albeit one that doesn't execute. As the error is known before we return from the ioctl, we can report the error we detect immediately, rather than leave it on the fence status. With the immediate propagation of the error, it is easier for userspace to handle. Fixes: 61231f6bd056 ("drm/i915/gem: Check that the context wasn't closed during setup") Testcase: igt/gem_ctx_exec/basic-close-race Signed-off-by: Chris Wilson Cc: # v5.7+ Reviewed-by: Tvrtko Ursulin Link: https://patchwork.freedesktop.org/patch/msgid/20201203103432.31526-1-chris@chris-wilson.co.uk (cherry picked from commit ba38b79eaeaeed29d2383f122d5c711ebf5ed3d1) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman commit a170b3e9c5b891f64284e032a376177fda20937f Author: Alex Deucher Date: Thu Dec 3 16:06:26 2020 -0500 drm/amdgpu/disply: set num_crtc earlier commit 578b6c487899179fed730e710ffec0b069917971 upstream. To avoid a recently added warning: Bogus possible_crtcs: [ENCODER:65:TMDS-65] possible_crtcs=0xf (full crtc mask=0x7) WARNING: CPU: 3 PID: 439 at drivers/gpu/drm/drm_mode_config.c:617 drm_mode_config_validate+0x178/0x200 [drm] In this case the warning is harmless, but confusing to users. Fixes: 0df108237433 ("drm: Validate encoder->possible_crtcs") Bug: https://bugzilla.kernel.org/show_bug.cgi?id=209123 Reviewed-by: Daniel Vetter Reviewed-by: Nicholas Kazlauskas Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit cf61c60b5116bf205c9f152e44e19a169d9e2e39 Author: Bean Huo Date: Wed Dec 2 21:23:20 2020 +0100 mmc: block: Fixup condition for CMD13 polling for RPMB requests commit 6246d7c9d15aaff0bc3863f67900c6a6e6be921b upstream. The CMD13 polling is needed for commands with R1B responses. In commit a0d4c7eb71dd ("mmc: block: Add CMD13 polling for MMC IOCTLS with R1B response"), the intent was to introduce this for requests targeted to the RPMB partition. However, the condition to trigger the polling loop became wrong, leading to unnecessary polling. Let's fix the condition to avoid this. Fixes: a0d4c7eb71dd ("mmc: block: Add CMD13 polling for MMC IOCTLS with R1B response") Cc: stable@vger.kernel.org Reported-by: Zhan Liu Signed-off-by: Zhan Liu Signed-off-by: Bean Huo Link: https://lore.kernel.org/r/20201202202320.22165-1-huobean@gmail.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 58b6dd4f9318a3f6d599d8095249c05a5e18ac72 Author: Muhammad Husaini Zulkifli Date: Wed Nov 18 20:01:20 2020 +0800 mmc: sdhci-of-arasan: Fix clock registration error for Keem Bay SOC commit a42a7ec9bb99a17869c3b9f3d365aaf2bdb1a554 upstream. The commit 16ada730a759 ("mmc: sdhci-of-arasan: Modify clock operations handling") introduced support for platform specific clock operations. Around the same point in time the commit 36c6aadaae86 ("mmc: sdhci-of-arasan: Add support for Intel Keem Bay") was also merged. Unfortunate it was not really tested on top of the previously mentioned commit, which causes clock registration failures for Keem Bay SOC devices. Let's fix this, by properly declaring the clock operation for Keem Bay SOC devices. Fixes: 36c6aadaae86 ("mmc: sdhci-of-arasan: Add support for Intel Keem Bay") Signed-off-by: Muhammad Husaini Zulkifli Reviewed-by: Adrian Hunter Link: https://lore.kernel.org/r/20201118120120.24908-2-muhammad.husaini.zulkifli@intel.com Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 7ade82bd734b641a4e654c4e4f834ea304eaa42b Author: Coiby Xu Date: Wed Nov 25 21:03:19 2020 +0800 pinctrl: amd: remove debounce filter setting in IRQ type setting commit 47a0001436352c9853d72bf2071e85b316d688a2 upstream. Debounce filter setting should be independent from IRQ type setting because according to the ACPI specs, there are separate arguments for specifying debounce timeout and IRQ type in GpioIo() and GpioInt(). Together with commit 06abe8291bc31839950f7d0362d9979edc88a666 ("pinctrl: amd: fix incorrect way to disable debounce filter") and Andy's patch "gpiolib: acpi: Take into account debounce settings" [1], this will fix broken touchpads for laptops whose BIOS set the debounce timeout to a relatively large value. For example, the BIOS of Lenovo AMD gaming laptops including Legion-5 15ARH05 (R7000), Legion-5P (R7000P) and IdeaPad Gaming 3 15ARH05, set the debounce timeout to 124.8ms. This led to the kernel receiving only ~7 HID reports per second from the Synaptics touchpad (MSFT0001:00 06CB:7F28). Existing touchpads like [2][3] are not troubled by this bug because the debounce timeout has been set to 0 by the BIOS before enabling the debounce filter in setting IRQ type. [1] https://lore.kernel.org/linux-gpio/20201111222008.39993-11-andriy.shevchenko@linux.intel.com/ 8dcb7a15a585 ("gpiolib: acpi: Take into account debounce settings") [2] https://github.com/Syniurge/i2c-amd-mp2/issues/11#issuecomment-721331582 [3] https://forum.manjaro.org/t/random-short-touchpad-freezes/30832/28 Signed-off-by: Coiby Xu Reviewed-by: Andy Shevchenko Cc: Hans de Goede Cc: Andy Shevchenko Cc: Benjamin Tissoires Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-gpio/CAHp75VcwiGREBUJ0A06EEw-SyabqYsp%2Bdqs2DpSrhaY-2GVdAA%40mail.gmail.com/ BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1887190 Link: https://lore.kernel.org/r/20201125130320.311059-1-coiby.xu@gmail.com Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit d100b8d66ca7f49d28c4de8ae603ce44d676b19f Author: Evan Green Date: Wed Nov 11 15:17:28 2020 -0800 pinctrl: jasperlake: Fix HOSTSW_OWN offset commit cdd8fc2dd64e3f1b22a6636e242d0eff49c4ba22 upstream. GPIOs that attempt to use interrupts get thwarted with a message like: "pin 161 cannot be used as IRQ" (for instance with SD_CD). This is because the HOSTSW_OWN offset is incorrect, so every GPIO looks like it's owned by ACPI. Fixes: e278dcb7048b1 ("pinctrl: intel: Add Intel Jasper Lake pin controller support") Cc: stable@vger.kernel.org Signed-off-by: Evan Green Acked-by: Mika Westerberg Signed-off-by: Andy Shevchenko Signed-off-by: Greg Kroah-Hartman commit ac1e8e8b33c827d2756bd1783c2dcf8500bbb80e Author: Chris Chiu Date: Wed Dec 9 20:24:47 2020 -0800 Input: i8042 - add Acer laptops to the i8042 reset list commit ce6520b0eafad5962ffc21dc47cd7bd3250e9045 upstream. The touchpad operates in Basic Mode by default in the Acer BIOS setup, but some Aspire/TravelMate models require the i8042 to be reset in order to be correctly detected. Signed-off-by: Chris Chiu Link: https://lore.kernel.org/r/20201207071250.15021-1-chiu@endlessos.org Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit ab85a0cb38abf6a65e6c6a69dd440db6591efbf0 Author: Dmitry Torokhov Date: Wed Dec 9 20:13:24 2020 -0800 Input: cm109 - do not stomp on control URB commit 82e06090473289ce63e23fdeb8737aad59b10645 upstream. We need to make sure we are not stomping on the control URB that was issued when opening the device when attempting to toggle buzzer. To do that we need to mark it as pending in cm109_open(). Reported-and-tested-by: syzbot+150f793ac5bc18eee150@syzkaller.appspotmail.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 531c3e652ede771012894808da0da7d204cb5575 Author: Juergen Gross Date: Mon Dec 7 09:36:14 2020 +0100 xen: don't use page->lru for ZONE_DEVICE memory commit ee32f32335e8c7f6154bf397f4ac9b6175b488a8 upstream. Commit 9e2369c06c8a18 ("xen: add helpers to allocate unpopulated memory") introduced usage of ZONE_DEVICE memory for foreign memory mappings. Unfortunately this collides with using page->lru for Xen backend private page caches. Fix that by using page->zone_device_data instead. Cc: # 5.9 Fixes: 9e2369c06c8a18 ("xen: add helpers to allocate unpopulated memory") Signed-off-by: Juergen Gross Reviewed-by: Boris Ostrovsky Reviewed-by: Jason Andryuk Signed-off-by: Juergen Gross Signed-off-by: Greg Kroah-Hartman commit 5050b59f89dc5c8ab5ea2089d398ca57ed35cd3b Author: Juergen Gross Date: Mon Dec 7 08:31:22 2020 +0100 xen: add helpers for caching grant mapping pages commit ca33479cc7be2c9b5f8be078c8bf3ac26b7d6186 upstream. Instead of having similar helpers in multiple backend drivers use common helpers for caching pages allocated via gnttab_alloc_pages(). Make use of those helpers in blkback and scsiback. Cc: # 5.9 Signed-off-by: Juergen Gross Reviewed-by: Boris Ostrovsky Signed-off-by: Juergen Gross Signed-off-by: Greg Kroah-Hartman commit c301c2bbeacd0db3495dc1e9b84d096483239e4a Author: Libo Chen Date: Fri Nov 20 18:12:43 2020 -0800 ktest.pl: Fix incorrect reboot for grub2bls commit 271e0c9dce1b02a825b3cc1a7aa1fab7c381d44b upstream. This issue was first noticed when I was testing different kernels on Oracle Linux 8 which as Fedora 30+ adopts BLS as default. Even though a kernel entry was added successfully and the index of that kernel entry was retrieved correctly, ktest still wouldn't reboot the system into user-specified kernel. The bug was spotted in subroutine reboot_to where the if-statement never checks for REBOOT_TYPE "grub2bls", therefore the desired entry will not be set for the next boot. Add a check for "grub2bls" so that $grub_reboot $grub_number can be run before a reboot if REBOOT_TYPE is "grub2bls" then we can boot to the correct kernel. Link: https://lkml.kernel.org/r/20201121021243.1532477-1-libo.chen@oracle.com Cc: stable@vger.kernel.org Fixes: ac2466456eaa ("ktest: introduce grub2bls REBOOT_TYPE option") Signed-off-by: Libo Chen Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 5abd108508110f11adfa2c9da69e32143acc726a Author: yong mao Date: Thu Nov 19 11:02:37 2020 +0800 mmc: mediatek: Extend recheck_sdio_irq fix to more variants commit 903a72eca4abf241293dcc1385896fd428e15fe9 upstream. The SDIO recheck fix is required for more of the supported variants. Let's add it to those that needs it. Reported-by: Fabien Parent Reported-by: Mattijs Korpershoek Signed-off-by: Yong Mao Link: https://lore.kernel.org/r/20201119030237.9414-1-yong.mao@mediatek.com Fixes: 9e2582e57407 ("mmc: mediatek: fix SDIO irq issue") Cc: stable@vger.kernel.org [Ulf: Clarified commitmsg ] Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 034192ca3e753e74c0488eb281a512e7c65a8c1f Author: Wenbin Mei Date: Wed Nov 18 14:34:05 2020 +0800 mmc: mediatek: Fix system suspend/resume support for CQHCI commit c0a2074ac575fff2848c8ef804bdc8590466c36c upstream. Before we got these errors on MT8192 platform: [ 59.153891] Restarting tasks ... [ 59.154540] done. [ 59.159175] PM: suspend exit [ 59.218724] mtk-msdc 11f60000.mmc: phase: [map:fffffffe] [maxlen:31] [final:16] [ 119.776083] mmc0: cqhci: timeout for tag 9 [ 119.780196] mmc0: cqhci: ============ CQHCI REGISTER DUMP =========== [ 119.786709] mmc0: cqhci: Caps: 0x100020b6 | Version: 0x00000510 [ 119.793225] mmc0: cqhci: Config: 0x00000101 | Control: 0x00000000 [ 119.799706] mmc0: cqhci: Int stat: 0x00000000 | Int enab: 0x00000000 [ 119.806177] mmc0: cqhci: Int sig: 0x00000000 | Int Coal: 0x00000000 [ 119.812670] mmc0: cqhci: TDL base: 0x00000000 | TDL up32: 0x00000000 [ 119.819149] mmc0: cqhci: Doorbell: 0x003ffc00 | TCN: 0x00000200 [ 119.825656] mmc0: cqhci: Dev queue: 0x00000000 | Dev Pend: 0x00000000 [ 119.832155] mmc0: cqhci: Task clr: 0x00000000 | SSC1: 0x00001000 [ 119.838627] mmc0: cqhci: SSC2: 0x00000000 | DCMD rsp: 0x00000000 [ 119.845174] mmc0: cqhci: RED mask: 0xfdf9a080 | TERRI: 0x0000891c [ 119.851654] mmc0: cqhci: Resp idx: 0x00000000 | Resp arg: 0x00000000 [ 119.865773] mmc0: cqhci: : =========================================== [ 119.872358] mmc0: running CQE recovery From these logs, we found TDL base was back to the default value. After suspend, the mmc host is powered off by HW, and bring CQE register to the default value, so we add system suspend/resume interface, then bring CQE to deactivated state before suspend, it will be enabled by CQE first request after resume. Signed-off-by: Wenbin Mei Link: https://lore.kernel.org/r/20201118063405.24906-1-wenbin.mei@mediatek.com Fixes: 88bd652b3c74 ("mmc: mediatek: command queue support") Cc: stable@vger.kernel.org [Ulf: Renamed functions] Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit dd85f53cf0e0737e5cd9c970676c00b17db2fbee Author: Hans Verkuil Date: Fri Nov 27 12:52:30 2020 +0100 media: pulse8-cec: add support for FW v10 and up commit 45ba1c0ba3e589ad3ef0d0603c822eb27ea16563 upstream. Starting with firmware version 10 the GET/SET_HDMI_VERSION message was removed and GET/SET_AUTO_POWER_ON was added. The removal of GET/SET_HDMI_VERSION caused the probe of the Pulse-Eight to fail. Add a version check to handle this gracefully. Also show (but do not set) the Auto Power On value. Signed-off-by: Hans Verkuil Reported-by: Maxime Ripard Tested-by: Maxime Ripard Cc: Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 985a670004bead2eb982cf196d9f55003adb5a52 Author: Hans Verkuil Date: Fri Nov 27 10:36:32 2020 +0100 media: pulse8-cec: fix duplicate free at disconnect or probe error commit 024e01dead12c2b9fbe31216f2099401ebb78a4a upstream. Commit 601282d65b96 ("media: pulse8-cec: use adap_free callback") used the adap_free callback to clean up on disconnect. What I forgot was that in the probe it will call cec_delete_adapter() followed by kfree(pulse8) if an error occurs. But by using the adap_free callback, cec_delete_adapter() is already freeing the pulse8 struct. This wasn't noticed since normally the probe works fine, but Pulse-Eight published a new firmware version that caused a probe error, so now it hits this bug. This affects firmware version 12, but probably any version >= 10. Commit aa9eda76129c ("media: pulse8-cec: close serio in disconnect, not adap_free") made this worse by adding the line 'pulse8->serio = NULL' right after the call to cec_unregister_adapter in the disconnect() function. Unfortunately, cec_unregister_adapter will typically call cec_delete_adapter (unless a filehandle to the cec device is still open), which frees the pulse8 struct. So now it will also crash on a simple unplug of the Pulse-Eight device. With this fix both the unplug issue and a probe() error situation are handled correctly again. It will still fail to probe() with a v12 firmware, that's something to look at separately. Signed-off-by: Hans Verkuil Reported-by: Maxime Ripard Tested-by: Maxime Ripard Fixes: aa9eda76129c ("media: pulse8-cec: close serio in disconnect, not adap_free") Fixes: 601282d65b96 ("media: pulse8-cec: use adap_free callback") Cc: Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit eda58515dee71b15451b60e183c7f64ebced1404 Author: Peter Zijlstra Date: Mon Nov 30 12:54:34 2020 +0100 intel_idle: Build fix [ Upstream commit 4d916140bf28ff027997144ea1bb4299e1536f87 ] Because CONFIG_ soup. Fixes: 6e1d2bc675bd ("intel_idle: Fix intel_idle() vs tracing") Reported-by: Randy Dunlap Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20201130115402.GO3040@hirez.programming.kicks-ass.net Signed-off-by: Sasha Levin commit d00ee4dc1cd9dba5c5f9b67bb00c1d5c98b791ad Author: Heiko Carstens Date: Wed Dec 2 11:46:01 2020 +0100 s390: fix irq state tracing [ Upstream commit b1cae1f84a0f609a34ebcaa087fbecef32f69882 ] With commit 58c644ba512c ("sched/idle: Fix arch_cpu_idle() vs tracing") common code calls arch_cpu_idle() with a lockdep state that tells irqs are on. This doesn't work very well for s390: psw_idle() will enable interrupts to wait for an interrupt. As soon as an interrupt occurs the interrupt handler will verify if the old context was psw_idle(). If that is the case the interrupt enablement bits in the old program status word will be cleared. A subsequent test in both the external as well as the io interrupt handler checks if in the old context interrupts were enabled. Due to the above patching of the old program status word it is assumed the old context had interrupts disabled, and therefore a call to TRACE_IRQS_OFF (aka trace_hardirqs_off_caller) is skipped. Which in turn makes lockdep incorrectly "think" that interrupts are enabled within the interrupt handler. Fix this by unconditionally calling TRACE_IRQS_OFF when entering interrupt handlers. Also call unconditionally TRACE_IRQS_ON when leaving interrupts handlers. This leaves the special psw_idle() case, which now returns with interrupts disabled, but has an "irqs on" lockdep state. So callers of psw_idle() must adjust the state on their own, if required. This is currently only __udelay_disabled(). Fixes: 58c644ba512c ("sched/idle: Fix arch_cpu_idle() vs tracing") Acked-by: Peter Zijlstra (Intel) Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin commit 64fec73663a9ee15b57c205db0bd734ecb8d7272 Author: Pankaj Sharma Date: Thu Nov 26 10:21:42 2020 +0530 can: m_can: m_can_dev_setup(): add support for bosch mcan version 3.3.0 [ Upstream commit 5c7d55bded77da6db7c5d249610e3a2eed730b3c ] Add support for mcan bit timing and control mode according to bosch mcan IP version 3.3.0. The mcan version read from the Core Release field of CREL register would be 33. Accordingly the properties are to be set for mcan v3.3.0 Signed-off-by: Pankaj Sharma Link: https://lore.kernel.org/r/1606366302-5520-1-git-send-email-pankj.sharma@samsung.com Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit ade5961701d6b3cbbf0583f67709d69583eac439 Author: Hans de Goede Date: Tue Nov 24 12:04:54 2020 +0100 platform/x86: touchscreen_dmi: Add info for the Irbis TW118 tablet [ Upstream commit c9aa128080cbce92f8715a9328f88d8ca3134279 ] Add touchscreen info for the Irbis TW118 tablet. Reported-and-tested-by: russianneuromancer Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20201124110454.114286-1-hdegoede@redhat.com Signed-off-by: Sasha Levin commit a4cdf449607d7dd34d6e66156ea67a9a93945157 Author: Hans de Goede Date: Thu Oct 15 21:49:49 2020 +0200 platform/x86: touchscreen_dmi: Add info for the Predia Basic tablet [ Upstream commit 0f511edc6ac12f1ccf1c6c2d4412f5ed7ba426a6 ] Add touchscreen info for the Predia Basic tablet. Signed-off-by: Hans de Goede Acked-by: Andy Shevchenko Link: https://lore.kernel.org/r/20201015194949.50566-1-hdegoede@redhat.com Signed-off-by: Sasha Levin commit ffdcf2fd85461e4be047cd0aced8f3a35edc0326 Author: Max Verevkin Date: Tue Nov 24 15:16:52 2020 +0200 platform/x86: intel-vbtn: Support for tablet mode on HP Pavilion 13 x360 PC [ Upstream commit 8b205d3e1bf52ab31cdd5c55f87c87a227793d84 ] The Pavilion 13 x360 PC has a chassis-type which does not indicate it is a convertible, while it is actually a convertible. Add it to the dmi_switches_allow_list. Signed-off-by: Max Verevkin Link: https://lore.kernel.org/r/20201124131652.11165-1-me@maxverevkin.tk Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin commit 22e2d0a22bf5e975d9838d200c797d86c4ed4c53 Author: Timo Witte Date: Tue Aug 4 02:14:23 2020 +0200 platform/x86: acer-wmi: add automatic keyboard background light toggle key as KEY_LIGHTS_TOGGLE [ Upstream commit 9e7a005ad56aa7d6ea5830c5ffcc60bf35de380b ] Got a dmesg message on my AMD Renoir based Acer laptop: "acer_wmi: Unknown key number - 0x84" when toggling keyboard background light Signed-off-by: Timo Witte Reviewed-by: "Lee, Chun-Yi" Link: https://lore.kernel.org/r/20200804001423.36778-1-timo.witte@gmail.com Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin commit 43ac621924aae1abd7be24b06ce4a04fbd1d4f7d Author: Matthias Maier Date: Wed Nov 25 18:04:16 2020 -0600 platform/x86: thinkpad_acpi: Whitelist P15 firmware for dual fan control [ Upstream commit 80a8c3185f5047dc7438ed226b72385bf93b4071 ] This commit enables dual fan control for the following new Lenovo models: P15, P15v. Signed-off-by: Matthias Maier Link: https://lore.kernel.org/r/20201126000416.2459645-2-tamiko-ibm-acpi-devel@43-1.org Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin commit e1dee70bb9777e5a7dd695784aacd643e8fbc452 Author: Hans de Goede Date: Mon Nov 9 11:35:50 2020 +0100 platform/x86: thinkpad_acpi: Add BAT1 is primary battery quirk for Thinkpad Yoga 11e 4th gen [ Upstream commit c986a7024916c92a775fc8d853fba3cae1d5fde4 ] The Thinkpad Yoga 11e 4th gen with the N3450 / Celeron CPU only has one battery which is named BAT1 instead of the expected BAT0, add a quirk for this. This fixes not being able to set the charging tresholds on this model; and this alsoe fixes the following errors in dmesg: ACPI: \_SB_.PCI0.LPCB.EC__.HKEY: BCTG evaluated but flagged as error thinkpad_acpi: Error probing battery 2 battery: extension failed to load: ThinkPad Battery Extension battery: extension unregistered: ThinkPad Battery Extension Note that the added quirk is for the "R0K" BIOS versions which are used on the Thinkpad Yoga 11e 4th gen's with a Celeron CPU, there is a separate "R0L" BIOS for the i3/i5 based versions. This may also need the same quirk, but if that really is necessary is unknown. Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20201109103550.16265-1-hdegoede@redhat.com Signed-off-by: Sasha Levin commit 69990496b0c0476ef31bfa1bf0467165f9b5afa5 Author: Hans de Goede Date: Fri Nov 6 15:01:30 2020 +0100 platform/x86: thinkpad_acpi: Do not report SW_TABLET_MODE on Yoga 11e [ Upstream commit f2eae1888cf22590c38764b8fa3c989c0283870e ] The Yoga 11e series has 2 accelerometers described by a BOSC0200 ACPI node. This setup relies on a Windows service which reads both accelerometers and then calculates the angle between the 2 halves to determine laptop / tent / tablet mode and then reports the calculated mode back to the EC by calling special ACPI methods on the BOSC0200 node. The bmc150 iio driver does not support this (it involves double calculations requiring sqrt and arccos so this really needs to be done in userspace), as a result of this on the Yoga 11e the thinkpad_acpi code always reports SW_TABLET_MODE=0, starting with GNOME 3.38 reporting SW_TABLET_MODE=0 causes GNOME to: 1. Not show the onscreen keyboard when a text-input field is focussed with the touchscreen. 2. Disable accelerometer based auto display-rotation. This makes sense when in laptop-mode but not when in tablet-mode. But since for the Yoga 11e the thinkpad_acpi code always reports SW_TABLET_MODE=0, GNOME does not know when the device is in tablet-mode. Stop reporting the broken (always 0) SW_TABLET_MODE on Yoga 11e models to fix this. Note there are plans for userspace to support 360 degree hinges style 2-in-1s with 2 accelerometers and figure out the mode by itself, see: https://gitlab.freedesktop.org/hadess/iio-sensor-proxy/-/issues/216 Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20201106140130.46820-1-hdegoede@redhat.com Signed-off-by: Sasha Levin commit 60434a3ba1a65d3024206c377cdadc93fa945017 Author: Iakov 'Jake' Kirilenko Date: Thu Nov 5 18:25:56 2020 +0300 platform/x86: thinkpad_acpi: add P1 gen3 second fan support [ Upstream commit 15d89c9f6f4a186ade7aefbe77e7ede9746b6c47 ] Tested on my P1 gen3, works fine with `thinkfan`. Since thinkpad_acpi fan control is off by default, it is safe to add 2nd fan control for brave overclockers Signed-off-by: Iakov 'Jake' Kirilenko Link: https://lore.kernel.org/r/20201105152556.34073-1-jake.kirilenko@gmail.com Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin commit ee982a0abaf320620c07e895561914a10e359945 Author: Jon Hunter Date: Mon Nov 16 16:20:26 2020 +0000 arm64: tegra: Disable the ACONNECT for Jetson TX2 [ Upstream commit fb319496935b7475a863a00c76895e8bb3216704 ] Commit ff4c371d2bc0 ("arm64: defconfig: Build ADMA and ACONNECT driver") enable the Tegra ADMA and ACONNECT drivers and this is causing resume from system suspend to fail on Jetson TX2. Resume is failing because the ACONNECT driver is being resumed before the BPMP driver, and the ACONNECT driver is attempting to power on a power-domain that is provided by the BPMP. While a proper fix for the resume sequencing problem is identified, disable the ACONNECT for Jetson TX2 temporarily to avoid breaking system suspend. Please note that ACONNECT driver is used by the Audio Processing Engine (APE) on Tegra, but because there is no mainline support for APE on Jetson TX2 currently, disabling the ACONNECT does not disable any useful feature at the moment. Signed-off-by: Jon Hunter Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 13158f6fab09eddced10ca607d7c91bd09fa8342 Author: Peter Zijlstra Date: Fri Nov 20 11:28:35 2020 +0100 intel_idle: Fix intel_idle() vs tracing [ Upstream commit 6e1d2bc675bd57640f5658a4a657ae488db4c204 ] cpuidle->enter() callbacks should not call into tracing because RCU has already been disabled. Instead of doing the broadcast thing itself, simply advertise to the cpuidle core that those states stop the timer. Signed-off-by: Peter Zijlstra (Intel) Acked-by: Rafael J. Wysocki Link: https://lkml.kernel.org/r/20201123143510.GR3021@hirez.programming.kicks-ass.net Signed-off-by: Sasha Levin commit fb82d3ac7ec1ffb5f4758b025bfdcd1b82eeddd5 Author: Peter Zijlstra Date: Fri Nov 20 11:50:35 2020 +0100 sched/idle: Fix arch_cpu_idle() vs tracing [ Upstream commit 58c644ba512cfbc2e39b758dd979edd1d6d00e27 ] We call arch_cpu_idle() with RCU disabled, but then use local_irq_{en,dis}able(), which invokes tracing, which relies on RCU. Switch all arch_cpu_idle() implementations to use raw_local_irq_{en,dis}able() and carefully manage the lockdep,rcu,tracing state like we do in entry. (XXX: we really should change arch_cpu_idle() to not return with interrupts enabled) Reported-by: Sven Schnelle Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Mark Rutland Tested-by: Mark Rutland Link: https://lkml.kernel.org/r/20201120114925.594122626@infradead.org Signed-off-by: Sasha Levin commit c51f65d693603ff1acebea1eae04cb20b6af8bcb Author: Hao Si Date: Tue Oct 20 10:18:32 2020 +0800 soc: fsl: dpio: Get the cpumask through cpumask_of(cpu) [ Upstream commit 2663b3388551230cbc4606a40fabf3331ceb59e4 ] The local variable 'cpumask_t mask' is in the stack memory, and its address is assigned to 'desc->affinity' in 'irq_set_affinity_hint()'. But the memory area where this variable is located is at risk of being modified. During LTP testing, the following error was generated: Unable to handle kernel paging request at virtual address ffff000012e9b790 Mem abort info: ESR = 0x96000007 Exception class = DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000007 CM = 0, WnR = 0 swapper pgtable: 4k pages, 48-bit VAs, pgdp = 0000000075ac5e07 [ffff000012e9b790] pgd=00000027dbffe003, pud=00000027dbffd003, pmd=00000027b6d61003, pte=0000000000000000 Internal error: Oops: 96000007 [#1] PREEMPT SMP Modules linked in: xt_conntrack Process read_all (pid: 20171, stack limit = 0x0000000044ea4095) CPU: 14 PID: 20171 Comm: read_all Tainted: G B W Hardware name: NXP Layerscape LX2160ARDB (DT) pstate: 80000085 (Nzcv daIf -PAN -UAO) pc : irq_affinity_hint_proc_show+0x54/0xb0 lr : irq_affinity_hint_proc_show+0x4c/0xb0 sp : ffff00001138bc10 x29: ffff00001138bc10 x28: 0000ffffd131d1e0 x27: 00000000007000c0 x26: ffff8025b9480dc0 x25: ffff8025b9480da8 x24: 00000000000003ff x23: ffff8027334f8300 x22: ffff80272e97d000 x21: ffff80272e97d0b0 x20: ffff8025b9480d80 x19: ffff000009a49000 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000040 x11: 0000000000000000 x10: ffff802735b79b88 x9 : 0000000000000000 x8 : 0000000000000000 x7 : ffff000009a49848 x6 : 0000000000000003 x5 : 0000000000000000 x4 : ffff000008157d6c x3 : ffff00001138bc10 x2 : ffff000012e9b790 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: irq_affinity_hint_proc_show+0x54/0xb0 seq_read+0x1b0/0x440 proc_reg_read+0x80/0xd8 __vfs_read+0x60/0x178 vfs_read+0x94/0x150 ksys_read+0x74/0xf0 __arm64_sys_read+0x24/0x30 el0_svc_common.constprop.0+0xd8/0x1a0 el0_svc_handler+0x34/0x88 el0_svc+0x10/0x14 Code: f9001bbf 943e0732 f94066c2 b4000062 (f9400041) ---[ end trace b495bdcb0b3b732b ]--- Kernel panic - not syncing: Fatal exception SMP: stopping secondary CPUs SMP: failed to stop secondary CPUs 0,2-4,6,8,11,13-15 Kernel Offset: disabled CPU features: 0x0,21006008 Memory Limit: none ---[ end Kernel panic - not syncing: Fatal exception ]--- Fix it by using 'cpumask_of(cpu)' to get the cpumask. Signed-off-by: Hao Si Signed-off-by: Lin Chen Signed-off-by: Yi Wang Signed-off-by: Li Yang Signed-off-by: Sasha Levin commit fa6f3ae455b00e31312618cdb91a22f9cf58cf13 Author: Filipe Manana Date: Mon Nov 23 18:31:02 2020 +0000 btrfs: fix lockdep splat when enabling and disabling qgroups [ Upstream commit a855fbe69229078cd8aecd8974fb996a5ca651e6 ] When running test case btrfs/017 from fstests, lockdep reported the following splat: [ 1297.067385] ====================================================== [ 1297.067708] WARNING: possible circular locking dependency detected [ 1297.068022] 5.10.0-rc4-btrfs-next-73 #1 Not tainted [ 1297.068322] ------------------------------------------------------ [ 1297.068629] btrfs/189080 is trying to acquire lock: [ 1297.068929] ffff9f2725731690 (sb_internal#2){.+.+}-{0:0}, at: btrfs_quota_enable+0xaf/0xa70 [btrfs] [ 1297.069274] but task is already holding lock: [ 1297.069868] ffff9f2702b61a08 (&fs_info->qgroup_ioctl_lock){+.+.}-{3:3}, at: btrfs_quota_enable+0x3b/0xa70 [btrfs] [ 1297.070219] which lock already depends on the new lock. [ 1297.071131] the existing dependency chain (in reverse order) is: [ 1297.071721] -> #1 (&fs_info->qgroup_ioctl_lock){+.+.}-{3:3}: [ 1297.072375] lock_acquire+0xd8/0x490 [ 1297.072710] __mutex_lock+0xa3/0xb30 [ 1297.073061] btrfs_qgroup_inherit+0x59/0x6a0 [btrfs] [ 1297.073421] create_subvol+0x194/0x990 [btrfs] [ 1297.073780] btrfs_mksubvol+0x3fb/0x4a0 [btrfs] [ 1297.074133] __btrfs_ioctl_snap_create+0x119/0x1a0 [btrfs] [ 1297.074498] btrfs_ioctl_snap_create+0x58/0x80 [btrfs] [ 1297.074872] btrfs_ioctl+0x1a90/0x36f0 [btrfs] [ 1297.075245] __x64_sys_ioctl+0x83/0xb0 [ 1297.075617] do_syscall_64+0x33/0x80 [ 1297.075993] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 1297.076380] -> #0 (sb_internal#2){.+.+}-{0:0}: [ 1297.077166] check_prev_add+0x91/0xc60 [ 1297.077572] __lock_acquire+0x1740/0x3110 [ 1297.077984] lock_acquire+0xd8/0x490 [ 1297.078411] start_transaction+0x3c5/0x760 [btrfs] [ 1297.078853] btrfs_quota_enable+0xaf/0xa70 [btrfs] [ 1297.079323] btrfs_ioctl+0x2c60/0x36f0 [btrfs] [ 1297.079789] __x64_sys_ioctl+0x83/0xb0 [ 1297.080232] do_syscall_64+0x33/0x80 [ 1297.080680] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 1297.081139] other info that might help us debug this: [ 1297.082536] Possible unsafe locking scenario: [ 1297.083510] CPU0 CPU1 [ 1297.084005] ---- ---- [ 1297.084500] lock(&fs_info->qgroup_ioctl_lock); [ 1297.084994] lock(sb_internal#2); [ 1297.085485] lock(&fs_info->qgroup_ioctl_lock); [ 1297.085974] lock(sb_internal#2); [ 1297.086454] *** DEADLOCK *** [ 1297.087880] 3 locks held by btrfs/189080: [ 1297.088324] #0: ffff9f2725731470 (sb_writers#14){.+.+}-{0:0}, at: btrfs_ioctl+0xa73/0x36f0 [btrfs] [ 1297.088799] #1: ffff9f2702b60cc0 (&fs_info->subvol_sem){++++}-{3:3}, at: btrfs_ioctl+0x1f4d/0x36f0 [btrfs] [ 1297.089284] #2: ffff9f2702b61a08 (&fs_info->qgroup_ioctl_lock){+.+.}-{3:3}, at: btrfs_quota_enable+0x3b/0xa70 [btrfs] [ 1297.089771] stack backtrace: [ 1297.090662] CPU: 5 PID: 189080 Comm: btrfs Not tainted 5.10.0-rc4-btrfs-next-73 #1 [ 1297.091132] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 [ 1297.092123] Call Trace: [ 1297.092629] dump_stack+0x8d/0xb5 [ 1297.093115] check_noncircular+0xff/0x110 [ 1297.093596] check_prev_add+0x91/0xc60 [ 1297.094076] ? kvm_clock_read+0x14/0x30 [ 1297.094553] ? kvm_sched_clock_read+0x5/0x10 [ 1297.095029] __lock_acquire+0x1740/0x3110 [ 1297.095510] lock_acquire+0xd8/0x490 [ 1297.095993] ? btrfs_quota_enable+0xaf/0xa70 [btrfs] [ 1297.096476] start_transaction+0x3c5/0x760 [btrfs] [ 1297.096962] ? btrfs_quota_enable+0xaf/0xa70 [btrfs] [ 1297.097451] btrfs_quota_enable+0xaf/0xa70 [btrfs] [ 1297.097941] ? btrfs_ioctl+0x1f4d/0x36f0 [btrfs] [ 1297.098429] btrfs_ioctl+0x2c60/0x36f0 [btrfs] [ 1297.098904] ? do_user_addr_fault+0x20c/0x430 [ 1297.099382] ? kvm_clock_read+0x14/0x30 [ 1297.099854] ? kvm_sched_clock_read+0x5/0x10 [ 1297.100328] ? sched_clock+0x5/0x10 [ 1297.100801] ? sched_clock_cpu+0x12/0x180 [ 1297.101272] ? __x64_sys_ioctl+0x83/0xb0 [ 1297.101739] __x64_sys_ioctl+0x83/0xb0 [ 1297.102207] do_syscall_64+0x33/0x80 [ 1297.102673] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 1297.103148] RIP: 0033:0x7f773ff65d87 This is because during the quota enable ioctl we lock first the mutex qgroup_ioctl_lock and then start a transaction, and starting a transaction acquires a fs freeze semaphore (at the VFS level). However, every other code path, except for the quota disable ioctl path, we do the opposite: we start a transaction and then lock the mutex. So fix this by making the quota enable and disable paths to start the transaction without having the mutex locked, and then, after starting the transaction, lock the mutex and check if some other task already enabled or disabled the quotas, bailing with success if that was the case. Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit a70b249621fa0586620ad419cd4d8d15ccd1d126 Author: Filipe Manana Date: Mon Nov 23 18:30:54 2020 +0000 btrfs: do nofs allocations when adding and removing qgroup relations [ Upstream commit 7aa6d359845a9dbf7ad90b0b1b6347ef4764621f ] When adding or removing a qgroup relation we are doing a GFP_KERNEL allocation which is not safe because we are holding a transaction handle open and that can make us deadlock if the allocator needs to recurse into the filesystem. So just surround those calls with a nofs context. Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 6d9b478ef5a8a2be0e2682222471c7db7b43e096 Author: Oded Gabbay Date: Sat Nov 21 14:35:35 2020 +0200 habanalabs/gaudi: fix missing code in ECC handling [ Upstream commit 652b44453ea953d3157f02a7f17e18e329952649 ] There is missing statement and missing "break;" in the ECC handling code in gaudi.c This will cause a wrong behavior upon certain ECC interrupts. Signed-off-by: Oded Gabbay Signed-off-by: Sasha Levin commit dad08d96b1d13cba282902cbeef0bfee497ce88c Author: John Stultz Date: Thu Nov 12 22:05:19 2020 +0000 arm-smmu-qcom: Ensure the qcom_scm driver has finished probing [ Upstream commit 72b55c96f3a5ae6e486c20b5dacf5114060ed042 ] Robin Murphy pointed out that if the arm-smmu driver probes before the qcom_scm driver, we may call qcom_scm_qsmmu500_wait_safe_toggle() before the __scm is initialized. Now, getting this to happen is a bit contrived, as in my efforts it required enabling asynchronous probing for both drivers, moving the firmware dts node to the end of the dtsi file, as well as forcing a long delay in the qcom_scm_probe function. With those tweaks we ran into the following crash: [ 2.631040] arm-smmu 15000000.iommu: Stage-1: 48-bit VA -> 48-bit IPA [ 2.633372] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 ... [ 2.633402] [0000000000000000] user address but active_mm is swapper [ 2.633409] Internal error: Oops: 96000005 [#1] PREEMPT SMP [ 2.633415] Modules linked in: [ 2.633427] CPU: 5 PID: 117 Comm: kworker/u16:2 Tainted: G W 5.10.0-rc1-mainline-00025-g272a618fc36-dirty #3971 [ 2.633430] Hardware name: Thundercomm Dragonboard 845c (DT) [ 2.633448] Workqueue: events_unbound async_run_entry_fn [ 2.633456] pstate: 80c00005 (Nzcv daif +PAN +UAO -TCO BTYPE=--) [ 2.633465] pc : qcom_scm_qsmmu500_wait_safe_toggle+0x78/0xb0 [ 2.633473] lr : qcom_smmu500_reset+0x58/0x78 [ 2.633476] sp : ffffffc0105a3b60 ... [ 2.633567] Call trace: [ 2.633572] qcom_scm_qsmmu500_wait_safe_toggle+0x78/0xb0 [ 2.633576] qcom_smmu500_reset+0x58/0x78 [ 2.633581] arm_smmu_device_reset+0x194/0x270 [ 2.633585] arm_smmu_device_probe+0xc94/0xeb8 [ 2.633592] platform_drv_probe+0x58/0xa8 [ 2.633597] really_probe+0xec/0x398 [ 2.633601] driver_probe_device+0x5c/0xb8 [ 2.633606] __driver_attach_async_helper+0x64/0x88 [ 2.633610] async_run_entry_fn+0x4c/0x118 [ 2.633617] process_one_work+0x20c/0x4b0 [ 2.633621] worker_thread+0x48/0x460 [ 2.633628] kthread+0x14c/0x158 [ 2.633634] ret_from_fork+0x10/0x18 [ 2.633642] Code: a9034fa0 d0007f73 29107fa0 91342273 (f9400020) To avoid this, this patch adds a check on qcom_scm_is_available() in the qcom_smmu_impl_init() function, returning -EPROBE_DEFER if its not ready. This allows the driver to try to probe again later after qcom_scm has finished probing. Reported-by: Robin Murphy Signed-off-by: John Stultz Reviewed-by: Robin Murphy Cc: Robin Murphy Cc: Will Deacon Cc: Andy Gross Cc: Maulik Shah Cc: Bjorn Andersson Cc: Saravana Kannan Cc: Marc Zyngier Cc: Lina Iyer Cc: iommu@lists.linux-foundation.org Cc: linux-arm-msm Link: https://lore.kernel.org/r/20201112220520.48159-1-john.stultz@linaro.org Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 6acb0cf4bf048312ee320270acb2f698a35e9469 Author: Ran Wang Date: Mon Nov 23 10:57:15 2020 +0800 spi: spi-nxp-fspi: fix fspi panic by unexpected interrupts [ Upstream commit 71d80563b0760a411cd90a3680536f5d887fff6b ] Given the case that bootloader(such as UEFI)'s FSPI driver might not handle all interrupts before loading kernel, those legacy interrupts would assert immidiately once kernel's FSPI driver enable them. Further, if it was FSPI_INTR_IPCMDDONE, the irq handler nxp_fspi_irq_handler() would call complete(&f->c) to notify others. However, f->c might not be initialized yet at that time, then cause kernel panic. Of cause, we should fix this issue within bootloader. But it would be better to have this pacth to make dirver more robust (by clearing all interrupt status bits before enabling interrupts). Suggested-by: Han Xu Signed-off-by: Ran Wang Link: https://lore.kernel.org/r/20201123025715.14635-1-ran.wang_1@nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 3067d221bcd215e53d7332d59c669caf55da96c4 Author: Krzysztof Kozlowski Date: Mon Nov 16 18:53:00 2020 +0100 drm/exynos: depend on COMMON_CLK to fix compile tests [ Upstream commit e2d3d2e904ad3d381753798dcd5cae03e3c47242 ] The Exynos DRM uses Common Clock Framework thus it cannot be built on platforms without it (e.g. compile test on MIPS with RALINK and SOC_RT305X): /usr/bin/mips-linux-gnu-ld: drivers/gpu/drm/exynos/exynos_mixer.o: in function `mixer_bind': exynos_mixer.c:(.text+0x958): undefined reference to `clk_set_parent' Reported-by: kernel test robot Signed-off-by: Krzysztof Kozlowski Signed-off-by: Inki Dae Signed-off-by: Sasha Levin commit 64f88613405f49fb6023b963368a30d456bb07fb Author: Xu Qiang Date: Sat Nov 7 10:42:26 2020 +0000 irqchip/gic-v3-its: Unconditionally save/restore the ITS state on suspend [ Upstream commit 74cde1a53368aed4f2b4b54bf7030437f64a534b ] On systems without HW-based collections (i.e. anything except GIC-500), we rely on firmware to perform the ITS save/restore. This doesn't really work, as although FW can properly save everything, it cannot fully restore the state of the command queue (the read-side is reset to the head of the queue). This results in the ITS consuming previously processed commands, potentially corrupting the state. Instead, let's always save the ITS state on suspend, disabling it in the process, and restore the full state on resume. This saves us from broken FW as long as it doesn't enable the ITS by itself (for which we can't do anything). This amounts to simply dropping the ITS_FLAGS_SAVE_SUSPEND_STATE. Signed-off-by: Xu Qiang [maz: added warning on resume, rewrote commit message] Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20201107104226.14282-1-xuqiang36@huawei.com Signed-off-by: Sasha Levin commit 517e062126755f7bfc599d68392ccedfbf665f43 Author: Lijun Pan Date: Fri Nov 20 16:40:13 2020 -0600 ibmvnic: skip tx timeout reset while in resetting [ Upstream commit 855a631a4c11458a9cef1ab79c1530436aa95fae ] Sometimes it takes longer than 5 seconds (watchdog timeout) to complete failover, migration, and other resets. In stead of scheduling another timeout reset, we wait for the current one to complete. Suggested-by: Brian King Signed-off-by: Lijun Pan Reviewed-by: Dany Madden Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 16aef8b4d8086e3cdd56865ec081907198eea62c Author: Georgi Djakov Date: Wed Nov 18 13:10:44 2020 +0200 interconnect: qcom: qcs404: Remove GPU and display RPM IDs [ Upstream commit 7ab1e9117607485df977bb6e271be5c5ad649a4c ] The following errors are noticed during boot on a QCS404 board: [ 2.926647] qcom_icc_rpm_smd_send mas 6 error -6 [ 2.934573] qcom_icc_rpm_smd_send mas 8 error -6 These errors show when we try to configure the GPU and display nodes. Since these particular nodes aren't supported on RPM and are purely local, we should just change their mas_rpm_id to -1 to avoid any requests being sent for these master IDs. Reviewed-by: Mike Tipton Reviewed-by: Bjorn Andersson Link: https://lore.kernel.org/r/20201118111044.26056-1-georgi.djakov@linaro.org Signed-off-by: Georgi Djakov Signed-off-by: Sasha Levin commit 8774a897a330b0370204e652db4e83ceb5e4d380 Author: Georgi Djakov Date: Thu Nov 12 12:51:40 2020 +0200 interconnect: qcom: msm8916: Remove rpm-ids from non-RPM nodes [ Upstream commit c497f9322af947204c28292be6f20dd2d97483dd ] Some nodes are incorrectly marked as RPM-controlled (they have RPM master and slave ids assigned), but are actually controlled by the application CPU instead. The RPM complains when we send requests for resources that it can't control. Let's fix this by replacing the IDs, with the default "-1" in which case no requests are sent. Reviewed-by: Mike Tipton Link: https://lore.kernel.org/r/20201112105140.10092-1-georgi.djakov@linaro.org Signed-off-by: Georgi Djakov Signed-off-by: Sasha Levin commit 5855a711029ee956b0f9443416969e6e67dd8294 Author: Can Guo Date: Tue Sep 22 00:09:04 2020 -0700 scsi: ufs: Make sure clk scaling happens only when HBA is runtime ACTIVE [ Upstream commit 73cc291c270248567245f084dcdf5078069af6b5 ] If someone plays with the UFS clk scaling devfreq governor through sysfs, ufshcd_devfreq_scale may be called even when HBA is not runtime ACTIVE. This can lead to unexpected error. We cannot just protect it by calling pm_runtime_get_sync() because that may cause a race condition since HBA runtime suspend ops need to suspend clk scaling. To fix this call pm_runtime_get_noresume() and check HBA's runtime status. Only proceed if HBA is runtime ACTIVE, otherwise just bail. governor_store devfreq_performance_handler update_devfreq devfreq_set_target ufshcd_devfreq_target ufshcd_devfreq_scale Link: https://lore.kernel.org/r/1600758548-28576-1-git-send-email-cang@codeaurora.org Reviewed-by: Stanley Chu Signed-off-by: Can Guo Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit f17c5a3adf66ad59c23580c912a21d22ba2152f2 Author: Can Guo Date: Wed Oct 21 22:59:00 2020 -0700 scsi: ufs: Fix unexpected values from ufshcd_read_desc_param() [ Upstream commit 1699f980d87fb678a669490462cf0b9517c1fb47 ] WB-related sysfs entries can be accessed even when an UFS device does not support the feature. The descriptors which are not supported by the UFS device may be wrongly reported when they are accessed from their corrsponding sysfs entries. Fix it by adding a sanity check of parameter offset against the actual decriptor length. Link: https://lore.kernel.org/r/1603346348-14149-1-git-send-email-cang@codeaurora.org Reviewed-by: Asutosh Das Acked-by: Daejun Park Signed-off-by: Can Guo Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 8b92c5da06131e15535800ff7907dbec0942e0c9 Author: Vineet Gupta Date: Fri Nov 6 16:59:27 2020 -0800 ARC: stack unwinding: don't assume non-current task is sleeping [ Upstream commit e42404fa10fd11fe72d0a0e149a321d10e577715 ] To start stack unwinding (SP, PC and BLINK) are needed. When the explicit execution context (pt_regs etc) is not available, unwinder assumes the task is sleeping (in __switch_to()) and fetches SP and BLINK from kernel mode stack. But this assumption is not true, specially in a SMP system, when top runs on 1 core, there may be active running processes on all cores. So when unwinding non courrent tasks, ensure they are NOT running. And while at it, handle the self unwinding case explicitly. This came out of investigation of a customer reported hang with rcutorture+top Link: https://github.com/foss-for-synopsys-dwc-arc-processors/linux/issues/31 Signed-off-by: Vineet Gupta Signed-off-by: Sasha Levin commit 414935075cd84205c7d0d1b11463b2d388f9b1b9 Author: Zhen Lei Date: Fri Oct 16 17:08:32 2020 +0800 arm64: dts: broadcom: clear the warnings caused by empty dma-ranges [ Upstream commit 2013a4b684b6eb614ee5c9a3c07b0ae6f5ca96d9 ] The scripts/dtc/checks.c requires that the node have empty "dma-ranges" property must have the same "#address-cells" and "#size-cells" values as the parent node. Otherwise, the following warnings is reported: arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning \ (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but \ its #address-cells (1) differs from / (2) arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning \ (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but \ its #size-cells (1) differs from / (2) Arnd Bergmann figured out why it's necessary: Also note that the #address-cells=<1> means that any device under this bus is assumed to only support 32-bit addressing, and DMA will have to go through a slow swiotlb in the absence of an IOMMU. Suggested-by: Arnd Bergmann Signed-off-by: Zhen Lei Link: https://lore.kernel.org/r/20201016090833.1892-2-thunder.leizhen@huawei.com' Acked-by: Florian Fainelli Signed-off-by: Arnd Bergmann Signed-off-by: Sasha Levin commit 6cad602451aedbcd5a80f5b5e7782d59630be51a Author: Michael Ellerman Date: Mon Nov 16 23:09:13 2020 +1100 powerpc: Drop -me200 addition to build flags [ Upstream commit e02152ba2810f7c88cb54e71cda096268dfa9241 ] Currently a build with CONFIG_E200=y will fail with: Error: invalid switch -me200 Error: unrecognized option -me200 Upstream binutils has never supported an -me200 option. Presumably it was supported at some point by either a fork or Freescale internal binutils. We can't support code that we can't even build test, so drop the addition of -me200 to the build flags, so we can at least build with CONFIG_E200=y. Reported-by: Németh Márton Reported-by: kernel test robot Signed-off-by: Michael Ellerman Reviewed-by: Nick Desaulniers Acked-by: Scott Wood Link: https://lore.kernel.org/r/20201116120913.165317-1-mpe@ellerman.id.au Signed-off-by: Sasha Levin commit 81b0105efafe14aecdc4ee12c35b23f66454cafa Author: Sara Sharon Date: Sat Nov 7 10:50:11 2020 +0200 iwlwifi: mvm: fix kernel panic in case of assert during CSA [ Upstream commit fe56d05ee6c87f6a1a8c7267affd92c9438249cc ] During CSA, we briefly nullify the phy context, in __iwl_mvm_unassign_vif_chanctx. In case we have a FW assert right after it, it remains NULL though. We end up running into endless loop due to mac80211 trying repeatedly to move us to ASSOC state, and we keep returning -EINVAL. Later down the road we hit a kernel panic. Detect and avoid this endless loop. Signed-off-by: Sara Sharon Signed-off-by: Luca Coelho Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/iwlwifi.20201107104557.d64de2c17bff.Iedd0d2afa20a2aacba5259a5cae31cb3a119a4eb@changeid Signed-off-by: Sasha Levin commit c918e4af11da8770fac2b78bab6dde38eb2c2705 Author: Johannes Berg Date: Sat Nov 7 10:50:10 2020 +0200 iwlwifi: pcie: set LTR to avoid completion timeout [ Upstream commit edb625208d84aef179e3f16590c1c582fc5fdae6 ] On some platforms, the preset values aren't correct and then we may get a completion timeout in the firmware. Change the LTR configuration to avoid that. The firmware will do some more complex reinit of this later, but for the boot process we use ~250usec. Signed-off-by: Johannes Berg Signed-off-by: Luca Coelho Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/iwlwifi.20201107104557.d83d591c05ba.I42885c9fb500bc08b9a4c07c4ff3d436cc7a3c84@changeid Signed-off-by: Sasha Levin commit e0ad0bedc35e501539c87779b1acb0c3aa56207d Author: Mordechay Goodstein Date: Sat Nov 7 10:50:06 2020 +0200 iwlwifi: sta: set max HE max A-MPDU according to HE capa [ Upstream commit c8a2e7a29702fe4626b7aa81149b7b7164e20606 ] Currently, our max tpt is limited to max HT A-MPDU for LB, and max VHT A-MPDU for HB. Configure HE exponent value correctly to achieve HE max A-MPDU, both on LB and HB. Signed-off-by: Mordechay Goodstein Signed-off-by: Luca Coelho Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/iwlwifi.20201107104557.4486852ebb56.I9eb0d028e31f183597fb90120e7d4ca87e0dd6cb@changeid Signed-off-by: Sasha Levin commit 243d3ba0d5640addf0481642b25108e7c3bd957a Author: Markus Reichl Date: Wed Nov 4 20:29:31 2020 +0100 arm64: dts: rockchip: Reorder LED triggers from mmc devices on rk3399-roc-pc. [ Upstream commit 7327c8b98e2e14c47021eea14d1ab268086a6408 ] After patch [1] SD-card becomes mmc1 and eMMC becomes mmc2. Correct trigger of LEDs accordingly. [1] https://patchwork.kernel.org/patch/11881427 Signed-off-by: Markus Reichl Link: https://lore.kernel.org/r/20201104192933.1001-1-m.reichl@fivetechno.de Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 88e2fbf640fc798dc276077a895d6eda67f1b174 Author: Markus Reichl Date: Wed Nov 4 17:23:55 2020 +0100 arm64: dts: rockchip: Assign a fixed index to mmc devices on rk3399 boards. [ Upstream commit 0011c6d182774fc781fb9e115ebe8baa356029ae ] Recently introduced async probe on mmc devices can shuffle block IDs. Pin them to fixed values to ease booting in environments where UUIDs are not practical. Use newly introduced aliases for mmcblk devices from [1]. [1] https://patchwork.kernel.org/patch/11747669/ Signed-off-by: Markus Reichl Reviewed-by: Douglas Anderson Link: https://lore.kernel.org/r/20201104162356.1251-1-m.reichl@fivetechno.de Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit df6bfa783c794fd4ca0c20366e43700874a4cf15 Author: Johannes Berg Date: Thu Oct 22 16:51:03 2020 +0300 iwlwifi: pcie: limit memory read spin time [ Upstream commit 04516706bb99889986ddfa3a769ed50d2dc7ac13 ] When we read device memory, we lock a spinlock, write the address we want to read from the device and then spin in a loop reading the data in 32-bit quantities from another register. As the description makes clear, this is rather inefficient, incurring a PCIe bus transaction for every read. In a typical device today, we want to read 786k SMEM if it crashes, leading to 192k register reads. Occasionally, we've seen the whole loop take over 20 seconds and then triggering the soft lockup detector. Clearly, it is unreasonable to spin here for such extended periods of time. To fix this, break the loop down into an outer and an inner loop, and break out of the inner loop if more than half a second elapsed. To avoid too much overhead, check for that only every 128 reads, though there's no particular reason for that number. Then, unlock and relock to obtain NIC access again, reprogram the start address and continue. This will keep (interrupt) latencies on the CPU down to a reasonable time. Signed-off-by: Johannes Berg Signed-off-by: Mordechay Goodstein Signed-off-by: Luca Coelho Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/iwlwifi.20201022165103.45878a7e49aa.I3b9b9c5a10002915072312ce75b68ed5b3dc6e14@changeid Signed-off-by: Sasha Levin commit 6d2a9cbba26df92e0483c2c9e8b5f3fe9b5fe511 Author: Maciej Matuszczyk Date: Fri Oct 23 20:16:29 2020 +0200 arm64: dts: rockchip: Remove system-power-controller from pmic on Odroid Go Advance [ Upstream commit 01fe332800d0d2f94337b45c1973f4cf28ae6195 ] This fixes a poweroff issue when this is supposed to happen via PSCI. Signed-off-by: Maciej Matuszczyk Link: https://lore.kernel.org/r/20201023181629.119727-1-maccraft123mc@gmail.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit be9a0b6883fa6d37563c401732309382da5caa15 Author: Al Cooper Date: Fri Oct 2 15:01:15 2020 -0400 phy: usb: Fix incorrect clearing of tca_drv_sel bit in SETUP reg for 7211 [ Upstream commit 209c805835b29495cf66cc705b206da8f4a68e6e ] The 7211a0 has a tca_drv_sel bit in the USB SETUP register that should never be enabled. This feature is only used if there is a USB Type-C PHY, and the 7211 does not have one. If the bit is enabled, the VBUS signal will never be asserted. In the 7211a0, the bit was incorrectly defaulted to on so the driver had to clear the bit. In the 7211c0 the state was inverted so the driver should no longer clear the bit. This hasn't been a problem because all current 7211 boards don't use the VBUS signal, but there are some future customer boards that may use it. Signed-off-by: Al Cooper Acked-by: Florian Fainelli Link: https://lore.kernel.org/r/20201002190115.48017-1-alcooperx@gmail.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit dd81cf1cd50021b8dd65ae0cef0ec80c86b11d3e Author: Liu Zixian Date: Sat Dec 5 22:15:15 2020 -0800 mm/mmap.c: fix mmap return value when vma is merged after call_mmap() [ Upstream commit 309d08d9b3a3659ab3f239d27d4e38b670b08fc9 ] On success, mmap should return the begin address of newly mapped area, but patch "mm: mmap: merge vma after call_mmap() if possible" set vm_start of newly merged vma to return value addr. Users of mmap will get wrong address if vma is merged after call_mmap(). We fix this by moving the assignment to addr before merging vma. We have a driver which changes vm_flags, and this bug is found by our testcases. Fixes: d70cec898324 ("mm: mmap: merge vma after call_mmap() if possible") Signed-off-by: Liu Zixian Signed-off-by: Andrew Morton Reviewed-by: Jason Gunthorpe Reviewed-by: David Hildenbrand Cc: Miaohe Lin Cc: Hongxiang Lou Cc: Hu Shiyuan Cc: Matthew Wilcox Link: https://lkml.kernel.org/r/20201203085350.22624-1-liuzixian4@huawei.com Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit cd8c84007bdc82e8fc0559a6523062abf6daae5f Author: Randy Dunlap Date: Sat Dec 5 22:14:38 2020 -0800 zlib: export S390 symbols for zlib modules [ Upstream commit 11fb479ff5d9872ddff02dd533c16d60372c86b2 ] Fix build errors when ZLIB_INFLATE=m and ZLIB_DEFLATE=m and ZLIB_DFLTCC=y by exporting the 2 needed symbols in dfltcc_inflate.c. Fixes these build errors: ERROR: modpost: "dfltcc_inflate" [lib/zlib_inflate/zlib_inflate.ko] undefined! ERROR: modpost: "dfltcc_can_inflate" [lib/zlib_inflate/zlib_inflate.ko] undefined! Fixes: 126196100063 ("lib/zlib: add s390 hardware support for kernel zlib_inflate") Reported-by: kernel test robot Signed-off-by: Randy Dunlap Signed-off-by: Andrew Morton Acked-by: Ilya Leoshkevich Cc: Mikhail Zaslonko Cc: Heiko Carstens Cc: Vasily Gorbik Cc: Christian Borntraeger Link: https://lkml.kernel.org/r/20201123191712.4882-1-rdunlap@infradead.org Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 8cceb4c12ea7263e347f85af0e1e905a1aa6dc28 Author: Linus Walleij Date: Mon Nov 30 09:30:33 2020 +0100 usb: ohci-omap: Fix descriptor conversion [ Upstream commit 45c5775460f32ed8cdb7c16986ae1a2c254346b3 ] There were a bunch of issues with the patch converting the OMAP1 OSK board to use descriptors for controlling the USB host: - The chip label was incorrect - The GPIO offset was off-by-one - The code should use sleeping accessors This patch tries to fix all issues at the same time. Cc: Aaro Koskinen Reported-by: Aaro Koskinen Fixes: 15d157e87443 ("usb: ohci-omap: Convert to use GPIO descriptors") Signed-off-by: Linus Walleij Link: https://lore.kernel.org/r/20201130083033.29435-1-linus.walleij@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 3a88ba2a67e47de7014199b8a4583e2fe45fff9c Author: Namhyung Kim Date: Thu Nov 26 20:09:21 2020 +0900 perf/x86/intel: Fix a warning on x86_pmu_stop() with large PEBS [ Upstream commit 5debf02131227d39988e44adf5090fb796fa8466 ] The commit 3966c3feca3f ("x86/perf/amd: Remove need to check "running" bit in NMI handler") introduced this. It seems x86_pmu_stop can be called recursively (like when it losts some samples) like below: x86_pmu_stop intel_pmu_disable_event (x86_pmu_disable) intel_pmu_pebs_disable intel_pmu_drain_pebs_nhm (x86_pmu_drain_pebs_buffer) x86_pmu_stop While commit 35d1ce6bec13 ("perf/x86/intel/ds: Fix x86_pmu_stop warning for large PEBS") fixed it for the normal cases, there's another path to call x86_pmu_stop() recursively when a PEBS error was detected (like two or more counters overflowed at the same time). Like in the Kan's previous fix, we can skip the interrupt accounting for large PEBS, so check the iregs which is set for PMI only. Fixes: 3966c3feca3f ("x86/perf/amd: Remove need to check "running" bit in NMI handler") Reported-by: John Sperbeck Suggested-by: Peter Zijlstra Signed-off-by: Namhyung Kim Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20201126110922.317681-1-namhyung@kernel.org Signed-off-by: Sasha Levin commit 83714d5200e604757e03e36d619cd5add0fe33a4 Author: Luca Coelho Date: Wed Dec 2 14:41:50 2020 +0200 iwlwifi: pcie: invert values of NO_160 device config entries [ Upstream commit 568d3434178b00274615190a19d29c3d235b4e6d ] The NO_160 flag specifies if the device doesn't have 160 MHz support, but we errorneously assumed the opposite. If the flag was set, we were considering that 160 MHz was supported, but it's actually the opposite. Fix it by inverting the bits, i.e. NO_160 is 0x1 and 160 is 0x0. Fixes: d6f2134a3831 ("iwlwifi: add mac/rf types and 160MHz to the device tables") Signed-off-by: Luca Coelho Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/iwlwifi.20201202143859.375bec857ccb.I83884286b688965293e9810381808039bd7eedae@changeid Signed-off-by: Sasha Levin commit 956b7d56949d8a937ee409cbc58144270965bccd Author: Randy Dunlap Date: Sat Nov 28 13:39:05 2020 -0800 vdpa: mlx5: fix vdpa/vhost dependencies [ Upstream commit 98701a2a861fa87a5055cf2809758e8725e8b146 ] drivers/vdpa/mlx5/ uses vhost_iotlb*() interfaces, so select VHOST_IOTLB to make them be built. However, if VHOST_IOTLB is the only VHOST symbol that is set/enabled, the object file still won't be built because drivers/Makefile won't descend into drivers/vhost/ to build it, so make drivers/Makefile build the needed binary whenever VHOST_IOTLB is set, like it does for VHOST_RING. Fixes these build errors: ERROR: modpost: "vhost_iotlb_itree_next" [drivers/vdpa/mlx5/mlx5_vdpa.ko] undefined! ERROR: modpost: "vhost_iotlb_itree_first" [drivers/vdpa/mlx5/mlx5_vdpa.ko] undefined! Fixes: 29064bfdabd5 ("vdpa/mlx5: Add support library for mlx5 VDPA implementation") Fixes: aff90770e54c ("vdpa/mlx5: Fix dependency on MLX5_CORE") Reported-by: kernel test robot Signed-off-by: Randy Dunlap Cc: Eli Cohen Cc: Parav Pandit Cc: "Michael S. Tsirkin" Cc: Jason Wang Cc: virtualization@lists.linux-foundation.org Cc: Saeed Mahameed Cc: Leon Romanovsky Cc: netdev@vger.kernel.org Link: https://lore.kernel.org/r/20201128213905.27409-1-rdunlap@infradead.org Signed-off-by: Michael S. Tsirkin Acked-by: Jason Wang Signed-off-by: Sasha Levin commit d0bad28fbddd3f9f6e2eda64ab2b1a775a8ad6a4 Author: Randy Dunlap Date: Sat Nov 28 23:08:43 2020 -0800 net: broadcom CNIC: requires MMU [ Upstream commit 14483cbf040fcb38113497161088a1ce8ce5d713 ] The CNIC kconfig symbol selects UIO and UIO depends on MMU. Since 'select' does not follow dependency chains, add the same MMU dependency to CNIC. Quietens this kconfig warning: WARNING: unmet direct dependencies detected for UIO Depends on [n]: MMU [=n] Selected by [m]: - CNIC [=m] && NETDEVICES [=y] && ETHERNET [=y] && NET_VENDOR_BROADCOM [=y] && PCI [=y] && (IPV6 [=m] || IPV6 [=m]=n) Fixes: adfc5217e9db ("broadcom: Move the Broadcom drivers") Signed-off-by: Randy Dunlap Cc: Jeff Kirsher Cc: Rasesh Mody Cc: GR-Linux-NIC-Dev@marvell.com Cc: "David S. Miller" Cc: Jakub Kicinski Cc: netdev@vger.kernel.org Link: https://lore.kernel.org/r/20201129070843.3859-1-rdunlap@infradead.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2b562f0211a87cf9852854a23bb68c70d1310c3d Author: Jing Xiangfeng Date: Fri Nov 27 11:02:06 2020 +0800 scsi: storvsc: Fix error return in storvsc_probe() [ Upstream commit 6112ff4e8f393e7e297dff04eff0987f94d37fa1 ] Return -ENOMEM from the error handling case instead of 0. Link: https://lore.kernel.org/r/20201127030206.104616-1-jingxiangfeng@huawei.com Fixes: 436ad9413353 ("scsi: storvsc: Allow only one remove lun work item to be issued per lun") Reviewed-by: Michael Kelley Signed-off-by: Jing Xiangfeng Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 58e9eb41784f4fb165764fd0333b2b491f28ed16 Author: Sami Tolvanen Date: Fri Nov 13 10:34:14 2020 -0800 samples/ftrace: Mark my_tramp[12]? global [ Upstream commit 983df5f2699f83f78643b19d3399b160d1e64f5b ] my_tramp[12]? are declared as global functions in C, but they are not marked global in the inline assembly definition. This mismatch confuses Clang's Control-Flow Integrity checking. Fix the definitions by adding .globl. Link: https://lkml.kernel.org/r/20201113183414.1446671-1-samitolvanen@google.com Fixes: 9d907f1ae80b8 ("ftrace/samples: Add a sample module that implements modify_ftrace_direct()") Reviewed-by: Kees Cook Signed-off-by: Sami Tolvanen Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit 8516786f9a87107e4f1044e1a817700fe8c4323d Author: Zhang Qilong Date: Sat Nov 28 21:39:22 2020 +0800 can: kvaser_pciefd: kvaser_pciefd_open(): fix error handling [ Upstream commit 13a84cf37a4cf1155a41684236c2314eb40cd65c ] If kvaser_pciefd_bus_on() failed, we should call close_candev() to avoid reference leak. Fixes: 26ad340e582d3 ("can: kvaser_pciefd: Add driver for Kvaser PCIEcan devices") Signed-off-by: Zhang Qilong Link: https://lore.kernel.org/r/20201128133922.3276973-3-zhangqilong3@huawei.com Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit ba3f951a6a0dd2c90f3d50276bf186822328f3dc Author: Zhang Qilong Date: Sat Nov 28 21:39:21 2020 +0800 can: c_can: c_can_power_up(): fix error handling [ Upstream commit 44cef0c0ffbd8d61143712ce874be68a273b7884 ] In the error handling in c_can_power_up(), there are two bugs: 1) c_can_pm_runtime_get_sync() will increase usage counter if device is not empty. Forgetting to call c_can_pm_runtime_put_sync() will result in a reference leak here. 2) c_can_reset_ram() operation will set start bit when enable is true. We should clear it in the error handling. We fix it by adding c_can_pm_runtime_put_sync() for 1), and c_can_reset_ram(enable is false) for 2) in the error handling. Fixes: 8212003260c60 ("can: c_can: Add d_can suspend resume support") Fixes: 52cde85acc23f ("can: c_can: Add d_can raminit support") Signed-off-by: Zhang Qilong Link: https://lore.kernel.org/r/20201128133922.3276973-2-zhangqilong3@huawei.com [mkl: return "0" instead of "ret"] Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 50982ba118e4cd961ae1d0bfaa16a2b5032614f2 Author: Jeroen Hofstee Date: Fri Nov 27 10:59:38 2020 +0100 can: sun4i_can: sun4i_can_err(): don't count arbitration lose as an error [ Upstream commit c2d095eff797813461a426b97242e3ffc50e4134 ] Losing arbitration is normal in a CAN-bus network, it means that a higher priority frame is being send and the pending message will be retried later. Hence most driver only increment arbitration_lost, but the sun4i driver also incremeants tx_error, causing errors to be reported on a normal functioning CAN-bus. So stop counting them as errors. Fixes: 0738eff14d81 ("can: Allwinner A10/A20 CAN Controller support - Kernel module") Signed-off-by: Jeroen Hofstee Link: https://lore.kernel.org/r/20201127095941.21609-1-jhofstee@victronenergy.com [mkl: split into two seperate patches] Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 89a9f7dd637bf7acee6879d62221cbc68a98aafb Author: Jeroen Hofstee Date: Fri Nov 27 10:59:38 2020 +0100 can: sja1000: sja1000_err(): don't count arbitration lose as an error [ Upstream commit bd0ccb92efb09c7da5b55162b283b42a93539ed7 ] Losing arbitration is normal in a CAN-bus network, it means that a higher priority frame is being send and the pending message will be retried later. Hence most driver only increment arbitration_lost, but the sja1000 driver also incremeants tx_error, causing errors to be reported on a normal functioning CAN-bus. So stop counting them as errors. Fixes: 8935f57e68c4 ("can: sja1000: fix network statistics update") Signed-off-by: Jeroen Hofstee Link: https://lore.kernel.org/r/20201127095941.21609-1-jhofstee@victronenergy.com [mkl: split into two seperate patches] Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 4301de8773b662e7596e933ec7512cc7c5e10b58 Author: Marc Kleine-Budde Date: Fri Nov 27 16:17:11 2020 +0100 can: m_can: tcan4x5x_can_probe(): fix error path: remove erroneous clk_disable_unprepare() [ Upstream commit ad1f5e826d91d6c27ecd36a607ad7c7f4d0b0733 ] The clocks mcan_class->cclk and mcan_class->hclk are not prepared by any call during tcan4x5x_can_probe(), so remove erroneous clk_disable_unprepare() on them. Fixes: 5443c226ba91 ("can: tcan4x5x: Add tcan4x5x driver to the kernel") Link: http://lore.kernel.org/r/20201130114252.215334-1-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 4f69c7d62aaa160c9e951328c139cc286c636e25 Author: Sebastian Reichel Date: Fri Nov 27 21:04:29 2020 +0100 drm/panel: sony-acx565akm: Fix race condition in probe [ Upstream commit 7c4bada12d320d8648ba3ede6f9b6f9e10f1126a ] The probe routine acquires the reset GPIO using GPIOD_OUT_LOW. Directly afterwards it calls acx565akm_detect(), which sets the GPIO value to HIGH. If the bootloader initialized the GPIO to HIGH before the probe routine was called, there is only a very short time period of a few instructions where the reset signal is LOW. Exact time depends on compiler optimizations, kernel configuration and alignment of the stars, but I expect it to be always way less than 10us. There are no public datasheets for the panel, but acx565akm_power_on() has a comment with timings and reset period should be at least 10us. So this potentially brings the panel into a half-reset state. The result is, that panel may not work after boot and can get into a working state by re-enabling it (e.g. by blanking + unblanking), since that does a clean reset cycle. This bug has recently been hit by Ivaylo Dimitrov, but there are some older reports which are probably the same bug. At least Tony Lindgren, Peter Ujfalusi and Jarkko Nikula have experienced it in 2017 describing the blank/unblank procedure as possible workaround. Note, that the bug really goes back in time. It has originally been introduced in the predecessor of the omapfb driver in commit 3c45d05be382 ("OMAPDSS: acx565akm panel: handle gpios in panel driver") in 2012. That driver eventually got replaced by a newer one, which had the bug from the beginning in commit 84192742d9c2 ("OMAPDSS: Add Sony ACX565AKM panel driver") and still exists in fbdev world. That driver has later been copied to omapdrm and then was used as a basis for this driver. Last but not least the omapdrm specific driver has been removed in commit 45f16c82db7e ("drm/omap: displays: Remove unused panel drivers"). Reported-by: Jarkko Nikula Reported-by: Peter Ujfalusi Reported-by: Tony Lindgren Reported-by: Aaro Koskinen Reported-by: Ivaylo Dimitrov Cc: Merlijn Wajer Cc: Laurent Pinchart Cc: Tomi Valkeinen Fixes: 1c8fc3f0c5d2 ("drm/panel: Add driver for the Sony ACX565AKM panel") Signed-off-by: Sebastian Reichel Tested-by: Ivaylo Dimitrov Tested-by: Aaro Koskinen Tested-by: Jarkko Nikula Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20201127200429.129868-1-sebastian.reichel@collabora.com Signed-off-by: Sasha Levin commit ddfe8fbf9b635b6277715c7040c8ce393bf3a39c Author: Paul Kocialkowski Date: Tue Nov 10 21:04:30 2020 +0100 drm/rockchip: Avoid uninitialized use of endpoint id in LVDS [ Upstream commit aec9fe892812ed10d0bffcf309d2a8fc380d8ce6 ] In the Rockchip DRM LVDS component driver, the endpoint id provided to drm_of_find_panel_or_bridge is grabbed from the endpoint's reg property. However, the property may be missing in the case of a single endpoint. Initialize the endpoint_id variable to 0 to avoid using an uninitialized variable in that case. Fixes: 34cc0aa25456 ("drm/rockchip: Add support for Rockchip Soc LVDS") Signed-off-by: Paul Kocialkowski Signed-off-by: Heiko Stuebner Link: https://patchwork.freedesktop.org/patch/msgid/20201110200430.1713467-1-paul.kocialkowski@bootlin.com Signed-off-by: Sasha Levin commit 5e3328abfd3d9a57f1ab27574630b69be5585cf1 Author: Dany Madden Date: Wed Nov 25 18:04:32 2020 -0600 ibmvnic: reduce wait for completion time [ Upstream commit 98c41f04a67abf5e7f7191d55d286e905d1430ef ] Reduce the wait time for Command Response Queue response from 30 seconds to 20 seconds, as recommended by VIOS and Power Hypervisor teams. Fixes: bd0b672313941 ("ibmvnic: Move login and queue negotiation into ibmvnic_open") Fixes: 53da09e92910f ("ibmvnic: Add set_link_state routine for setting adapter link state") Signed-off-by: Dany Madden Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0d111ed75df2dc5fdc3ff78876655473013f5f73 Author: Dany Madden Date: Wed Nov 25 18:04:30 2020 -0600 ibmvnic: send_login should check for crq errors [ Upstream commit c98d9cc4170da7e16a1012563d0f9fbe1c7cfe27 ] send_login() does not check for the result of ibmvnic_send_crq() of the login request. This results in the driver needlessly retrying the login 10 times even when CRQ is no longer active. Check the return code and give up in case of errors in sending the CRQ. The only time we want to retry is if we get a PARITALSUCCESS response from the partner. Fixes: 032c5e82847a2 ("Driver for IBM System i/p VNIC protocol") Signed-off-by: Dany Madden Signed-off-by: Sukadev Bhattiprolu Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9b76cafbf27a5024f160367fa4492846336906ed Author: Sukadev Bhattiprolu Date: Wed Nov 25 18:04:29 2020 -0600 ibmvnic: track pending login [ Upstream commit 76cdc5c5d99ce4856ad0ac38facc33b52fa64f77 ] If after ibmvnic sends a LOGIN it gets a FAILOVER, it is possible that the worker thread will start reset process and free the login response buffer before it gets a (now stale) LOGIN_RSP. The ibmvnic tasklet will then try to access the login response buffer and crash. Have ibmvnic track pending logins and discard any stale login responses. Fixes: 032c5e82847a ("Driver for IBM System i/p VNIC protocol") Signed-off-by: Sukadev Bhattiprolu Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e68f59be3e68fca421079577031c9ffce3834d9b Author: Sukadev Bhattiprolu Date: Wed Nov 25 18:04:28 2020 -0600 ibmvnic: delay next reset if hard reset fails [ Upstream commit f15fde9d47b887b406f5e76490d601cfc26643c9 ] If auto-priority failover is enabled, the backing device needs time to settle if hard resetting fails for any reason. Add a delay of 60 seconds before retrying the hard-reset. Fixes: 2770a7984db5 ("ibmvnic: Introduce hard reset recovery") Signed-off-by: Sukadev Bhattiprolu Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0b0d64b126225c07a58619a7c92ea0d5e8617052 Author: Dany Madden Date: Wed Nov 25 18:04:26 2020 -0600 ibmvnic: avoid memset null scrq msgs [ Upstream commit 9281cf2d584083a450fd65fd27cc5f0e692f6e30 ] scrq->msgs could be NULL during device reset, causing Linux to crash. So, check before memset scrq->msgs. Fixes: c8b2ad0a4a901 ("ibmvnic: Sanitize entire SCRQ buffer on reset") Signed-off-by: Dany Madden Signed-off-by: Lijun Pan Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit cbacbc3b4605c172b3c7383b238f1ecb36d92c1a Author: Dany Madden Date: Wed Nov 25 18:04:25 2020 -0600 ibmvnic: stop free_all_rwi on failed reset [ Upstream commit 18f141bf97d42f65abfdf17fd93fb3a0dac100e7 ] When ibmvnic fails to reset, it breaks out of the reset loop and frees all of the remaining resets from the workqueue. Doing so prevents the adapter from recovering if no reset is scheduled after that. Instead, have the driver continue to process resets on the workqueue. Remove the no longer need free_all_rwi(). Fixes: ed651a10875f1 ("ibmvnic: Updated reset handling") Signed-off-by: Dany Madden Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1b56fed756bf633b64b7abf6978cc259693e011c Author: Dany Madden Date: Wed Nov 25 18:04:24 2020 -0600 ibmvnic: handle inconsistent login with reset [ Upstream commit 31d6b4036098f6b59bcfa20375626b500c7d7417 ] Inconsistent login with the vnicserver is causing the device to be removed. This does not give the device a chance to recover from error state. This patch schedules a FATAL reset instead to bring the adapter up. Fixes: 032c5e82847a2 ("Driver for IBM System i/p VNIC protocol") Signed-off-by: Dany Madden Signed-off-by: Lijun Pan Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0fc63f124c1c279a6d30dc00a86e51fd7b1264a7 Author: Wang Hai Date: Tue Nov 24 16:07:49 2020 +0800 ipvs: fix possible memory leak in ip_vs_control_net_init [ Upstream commit 4bc3c8dc9f5f1eff0d3bfa59491383ac11308b6b ] kmemleak report a memory leak as follows: BUG: memory leak unreferenced object 0xffff8880759ea000 (size 256): backtrace: [<00000000c0bf2deb>] kmem_cache_zalloc include/linux/slab.h:656 [inline] [<00000000c0bf2deb>] __proc_create+0x23d/0x7d0 fs/proc/generic.c:421 [<000000009d718d02>] proc_create_reg+0x8e/0x140 fs/proc/generic.c:535 [<0000000097bbfc4f>] proc_create_net_data+0x8c/0x1b0 fs/proc/proc_net.c:126 [<00000000652480fc>] ip_vs_control_net_init+0x308/0x13a0 net/netfilter/ipvs/ip_vs_ctl.c:4169 [<000000004c927ebe>] __ip_vs_init+0x211/0x400 net/netfilter/ipvs/ip_vs_core.c:2429 [<00000000aa6b72d9>] ops_init+0xa8/0x3c0 net/core/net_namespace.c:151 [<00000000153fd114>] setup_net+0x2de/0x7e0 net/core/net_namespace.c:341 [<00000000be4e4f07>] copy_net_ns+0x27d/0x530 net/core/net_namespace.c:482 [<00000000f1c23ec9>] create_new_namespaces+0x382/0xa30 kernel/nsproxy.c:110 [<00000000098a5757>] copy_namespaces+0x2e6/0x3b0 kernel/nsproxy.c:179 [<0000000026ce39e9>] copy_process+0x220a/0x5f00 kernel/fork.c:2072 [<00000000b71f4efe>] _do_fork+0xc7/0xda0 kernel/fork.c:2428 [<000000002974ee96>] __do_sys_clone3+0x18a/0x280 kernel/fork.c:2703 [<0000000062ac0a4d>] do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 [<0000000093f1ce2c>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 In the error path of ip_vs_control_net_init(), remove_proc_entry() needs to be called to remove the added proc entry, otherwise a memory leak will occur. Also, add some '#ifdef CONFIG_PROC_FS' because proc_create_net* return NULL when PROC is not used. Fixes: b17fc9963f83 ("IPVS: netns, ip_vs_stats and its procfs") Fixes: 61b1ab4583e2 ("IPVS: netns, add basic init per netns.") Reported-by: Hulk Robot Signed-off-by: Wang Hai Acked-by: Julian Anastasov Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 8b37451dd7f97f7e9cee9957e57f43cd71690bf0 Author: Sven Eckelmann Date: Thu Nov 26 18:24:49 2020 +0100 batman-adv: Don't always reallocate the fragmentation skb head [ Upstream commit 992b03b88e36254e26e9a4977ab948683e21bd9f ] When a packet is fragmented by batman-adv, the original batman-adv header is not modified. Only a new fragmentation is inserted between the original one and the ethernet header. The code must therefore make sure that it has a writable region of this size in the skbuff head. But it is not useful to always reallocate the skbuff by this size even when there would be more than enough headroom still in the skb. The reallocation is just to costly during in this codepath. Fixes: ee75ed88879a ("batman-adv: Fragment and send skbs larger than mtu") Signed-off-by: Sven Eckelmann Signed-off-by: Simon Wunderlich Signed-off-by: Sasha Levin commit 26eec9496130d4d51f2d19ffc872afc578cd364a Author: Sven Eckelmann Date: Wed Nov 25 13:16:43 2020 +0100 batman-adv: Reserve needed_*room for fragments [ Upstream commit c5cbfc87558168ef4c3c27ce36eba6b83391db19 ] The batadv net_device is trying to propagate the needed_headroom and needed_tailroom from the lower devices. This is needed to avoid cost intensive reallocations using pskb_expand_head during the transmission. But the fragmentation code split the skb's without adding extra room at the end/beginning of the various fragments. This reduced the performance of transmissions over complex scenarios (batadv on vxlan on wireguard) because the lower devices had to perform the reallocations at least once. Fixes: ee75ed88879a ("batman-adv: Fragment and send skbs larger than mtu") Signed-off-by: Sven Eckelmann Signed-off-by: Simon Wunderlich Signed-off-by: Sasha Levin commit cd77950da8ca28ae4909856542327f6f118785e8 Author: Sven Eckelmann Date: Thu Nov 26 18:15:06 2020 +0100 batman-adv: Consider fragmentation for needed_headroom [ Upstream commit 4ca23e2c2074465bff55ea14221175fecdf63c5f ] If a batman-adv packets has to be fragmented, then the original batman-adv packet header is not stripped away. Instead, only a new header is added in front of the packet after it was split. This size must be considered to avoid cost intensive reallocations during the transmission through the various device layers. Fixes: 7bca68c7844b ("batman-adv: Add lower layer needed_(head|tail)room to own ones") Reported-by: Linus Lüssing Signed-off-by: Sven Eckelmann Signed-off-by: Simon Wunderlich Signed-off-by: Sasha Levin commit ead8e63a2cf0405a78a05837c506c907848a4dc4 Author: Nicholas Piggin Date: Thu Nov 26 20:25:27 2020 +1000 powerpc/64s: Fix hash ISA v3.0 TLBIEL instruction generation [ Upstream commit 5844cc25fd121074de7895181a2fa1ce100a0fdd ] A typo has the R field of the instruction assigned by lucky dip a la register allocator. Fixes: d4748276ae14c ("powerpc/64s: Improve local TLB flush for boot and MCE on POWER9") Signed-off-by: Nicholas Piggin Reviewed-by: Aneesh Kumar K.V Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20201126102530.691335-2-npiggin@gmail.com Signed-off-by: Sasha Levin commit 0d3cf1602ef0aa0177c94bf94e27759f5502c818 Author: Si-Wei Liu Date: Thu Nov 5 18:26:33 2020 -0500 vhost-vdpa: fix page pinning leakage in error path (rework) [ Upstream commit ad89653f79f1882d55d9df76c9b2b94f008c4e27 ] Pinned pages are not properly accounted particularly when mapping error occurs on IOTLB update. Clean up dangling pinned pages for the error path. The memory usage for bookkeeping pinned pages is reverted to what it was before: only one single free page is needed. This helps reduce the host memory demand for VM with a large amount of memory, or in the situation where host is running short of free memory. Fixes: 4c8cf31885f6 ("vhost: introduce vDPA-based backend") Signed-off-by: Si-Wei Liu Link: https://lore.kernel.org/r/1604618793-4681-1-git-send-email-si-wei.liu@oracle.com Signed-off-by: Michael S. Tsirkin Acked-by: Jason Wang Signed-off-by: Sasha Levin commit c709cffb95e9416496a61699e369a115a35136ff Author: Zhen Lei Date: Tue Nov 24 18:41:00 2020 +0800 bpftool: Fix error return value in build_btf_type_table [ Upstream commit 68878a5c5b852d17f5827ce8a0f6fbd8b4cdfada ] An appropriate return value should be set on the failed path. Fixes: 4d374ba0bf30 ("tools: bpftool: implement "bpftool btf show|list"") Reported-by: Hulk Robot Signed-off-by: Zhen Lei Signed-off-by: Daniel Borkmann Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20201124104100.491-1-thunder.leizhen@huawei.com Signed-off-by: Sasha Levin commit 5d06e9cb82f042f3b4af7cab5d9b3a1e16ae82f7 Author: Björn Töpel Date: Mon Nov 23 18:56:00 2020 +0100 net, xsk: Avoid taking multiple skbuff references [ Upstream commit 36ccdf85829a7dd6936dba5d02fa50138471f0d3 ] Commit 642e450b6b59 ("xsk: Do not discard packet when NETDEV_TX_BUSY") addressed the problem that packets were discarded from the Tx AF_XDP ring, when the driver returned NETDEV_TX_BUSY. Part of the fix was bumping the skbuff reference count, so that the buffer would not be freed by dev_direct_xmit(). A reference count larger than one means that the skbuff is "shared", which is not the case. If the "shared" skbuff is sent to the generic XDP receive path, netif_receive_generic_xdp(), and pskb_expand_head() is entered the BUG_ON(skb_shared(skb)) will trigger. This patch adds a variant to dev_direct_xmit(), __dev_direct_xmit(), where a user can select the skbuff free policy. This allows AF_XDP to avoid bumping the reference count, but still keep the NETDEV_TX_BUSY behavior. Fixes: 642e450b6b59 ("xsk: Do not discard packet when NETDEV_TX_BUSY") Reported-by: Yonghong Song Signed-off-by: Björn Töpel Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20201123175600.146255-1-bjorn.topel@gmail.com Signed-off-by: Sasha Levin commit 346054e16f109434c6bd16e9e9c4050b74298101 Author: Masami Hiramatsu Date: Thu Nov 19 14:53:31 2020 +0900 tools/bootconfig: Fix to check the write failure correctly [ Upstream commit a995e6bc0524450adfd6181dfdcd9d0520cfaba5 ] Fix to check the write(2) failure including partial write correctly and try to rollback the partial write, because if there is no BOOTCONFIG_MAGIC string, we can not remove it. Link: https://lkml.kernel.org/r/160576521135.320071.3883101436675969998.stgit@devnote2 Fixes: 85c46b78da58 ("bootconfig: Add bootconfig magic word for indicating bootconfig explicitly") Suggested-by: Linus Torvalds Signed-off-by: Masami Hiramatsu Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit d829847a9c05999086a45e7085afe52bf5b1c5be Author: Hans de Goede Date: Wed Nov 18 13:15:15 2020 +0100 ASoC: Intel: bytcr_rt5640: Fix HP Pavilion x2 Detachable quirks [ Upstream commit fbdae7d6d04d2db36c687723920f612e93b2cbda ] The HP Pavilion x2 Detachable line comes in many variants: 1. Bay Trail SoC + AXP288 PMIC, Micro-USB charging (10-k010nz, ...) DMI_SYS_VENDOR: "Hewlett-Packard" DMI_PRODUCT_NAME: "HP Pavilion x2 Detachable PC 10" DMI_BOARD_NAME: "8021" 2. Bay Trail SoC + AXP288 PMIC, Type-C charging (10-n000nd, 10-n010nl, ...) DMI_SYS_VENDOR: "Hewlett-Packard" DMI_PRODUCT_NAME: "HP Pavilion x2 Detachable" DMI_BOARD_NAME: "815D" 3. Cherry Trail SoC + AXP288 PMIC, Type-C charging (10-n101ng, ...) DMI_SYS_VENDOR: "HP" DMI_PRODUCT_NAME: "HP Pavilion x2 Detachable" DMI_BOARD_NAME: "813E" 4. Cherry Trail SoC + TI PMIC, Type-C charging (10-p002nd, 10-p018wm, ...) DMI_SYS_VENDOR: "HP" DMI_PRODUCT_NAME: "HP x2 Detachable 10-p0XX" DMI_BOARD_NAME: "827C" 5. Cherry Trail SoC + TI PMIC, Type-C charging (x2-210-g2, ...) DMI_SYS_VENDOR: "HP" DMI_PRODUCT_NAME: "HP x2 210 G2" DMI_BOARD_NAME: "82F4" Variant 1 needs the exact same quirk as variant 2, so relax the DMI check for the existing quirk a bit so that it matches both variant 1 and 2 (note the other variants will still not match). Variant 2 already has an existing quirk (which now also matches variant 1) Variant 3 uses a cx2072x codec, so is not applicable here. Variant 4 almost works with the defaults, but it also needs a quirk to fix jack-detection, add a new quirk for this. Variant 5 does use a RT5640 codec (based on old dmesg output), but was otherwise not tested, keep using the defaults for this variant. Fixes: ec8e8418ff7d ("ASoC: Intel: bytcr_rt5640: Add quirks for various devices") Signed-off-by: Hans de Goede Acked-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20201118121515.11441-1-hdegoede@redhat.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 65e536ebc63257774d2d0f07139c4a33ff8d3f86 Author: Steven Rostedt (VMware) Date: Fri Dec 11 00:31:09 2020 +0900 kprobes: Tell lockdep about kprobe nesting commit 645f224e7ba2f4200bf163153d384ceb0de5462e upstream. Since the kprobe handlers have protection that prohibits other handlers from executing in other contexts (like if an NMI comes in while processing a kprobe, and executes the same kprobe, it will get fail with a "busy" return). Lockdep is unaware of this protection. Use lockdep's nesting api to differentiate between locks taken in INT3 context and other context to suppress the false warnings. Link: https://lore.kernel.org/r/20201102160234.fa0ae70915ad9e2b21c08b85@kernel.org Cc: stable@vger.kernel.org # 5.9.x Cc: Peter Zijlstra Acked-by: Masami Hiramatsu Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit e501d3d4152016995c8d01fdeed519c3e8a9afdc Author: Masami Hiramatsu Date: Fri Dec 11 00:30:58 2020 +0900 kprobes: Remove NMI context check commit e03b4a084ea6b0a18b0e874baec439e69090c168 upstream. The in_nmi() check in pre_handler_kretprobe() is meant to avoid recursion, and blindly assumes that anything NMI is recursive. However, since commit: 9b38cc704e84 ("kretprobe: Prevent triggering kretprobe from within kprobe_flush_task") there is a better way to detect and avoid actual recursion. By setting a dummy kprobe, any actual exceptions will terminate early (by trying to handle the dummy kprobe), and recursion will not happen. Employ this to avoid the kretprobe_table_lock() recursion, replacing the over-eager in_nmi() check. Cc: stable@vger.kernel.org # 5.9.x Signed-off-by: Masami Hiramatsu Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Link: https://lkml.kernel.org/r/159870615628.1229682.6087311596892125907.stgit@devnote2 Signed-off-by: Greg Kroah-Hartman commit 762da2bc76b6af7fed5ceb14f241941883e6cb6a Author: Minchan Kim Date: Sat Dec 5 22:14:51 2020 -0800 mm/zsmalloc.c: drop ZSMALLOC_PGTABLE_MAPPING commit e91d8d78237de8d7120c320b3645b7100848f24d upstream. While I was doing zram testing, I found sometimes decompression failed since the compression buffer was corrupted. With investigation, I found below commit calls cond_resched unconditionally so it could make a problem in atomic context if the task is reschedule. BUG: sleeping function called from invalid context at mm/vmalloc.c:108 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 946, name: memhog 3 locks held by memhog/946: #0: ffff9d01d4b193e8 (&mm->mmap_lock#2){++++}-{4:4}, at: __mm_populate+0x103/0x160 #1: ffffffffa3d53de0 (fs_reclaim){+.+.}-{0:0}, at: __alloc_pages_slowpath.constprop.0+0xa98/0x1160 #2: ffff9d01d56b8110 (&zspage->lock){.+.+}-{3:3}, at: zs_map_object+0x8e/0x1f0 CPU: 0 PID: 946 Comm: memhog Not tainted 5.9.3-00011-gc5bfc0287345-dirty #316 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1 04/01/2014 Call Trace: unmap_kernel_range_noflush+0x2eb/0x350 unmap_kernel_range+0x14/0x30 zs_unmap_object+0xd5/0xe0 zram_bvec_rw.isra.0+0x38c/0x8e0 zram_rw_page+0x90/0x101 bdev_write_page+0x92/0xe0 __swap_writepage+0x94/0x4a0 pageout+0xe3/0x3a0 shrink_page_list+0xb94/0xd60 shrink_inactive_list+0x158/0x460 We can fix this by removing the ZSMALLOC_PGTABLE_MAPPING feature (which contains the offending calling code) from zsmalloc. Even though this option showed some amount improvement(e.g., 30%) in some arm32 platforms, it has been headache to maintain since it have abused APIs[1](e.g., unmap_kernel_range in atomic context). Since we are approaching to deprecate 32bit machines and already made the config option available for only builtin build since v5.8, lastly it has been not default option in zsmalloc, it's time to drop the option for better maintenance. [1] http://lore.kernel.org/linux-mm/20201105170249.387069-1-minchan@kernel.org Fixes: e47110e90584 ("mm/vunmap: add cond_resched() in vunmap_pmd_range") Signed-off-by: Minchan Kim Signed-off-by: Andrew Morton Reviewed-by: Sergey Senozhatsky Cc: Tony Lindgren Cc: Christoph Hellwig Cc: Harish Sriram Cc: Uladzislau Rezki Cc: Link: https://lkml.kernel.org/r/20201117202916.GA3856507@google.com Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 1fcaa002e3ca7137379c96f63452612bdb5a1e88 Author: Nick Desaulniers Date: Mon Nov 9 10:35:28 2020 -0800 Kbuild: do not emit debug info for assembly with LLVM_IAS=1 commit b8a9092330da2030496ff357272f342eb970d51b upstream. Clang's integrated assembler produces the warning for assembly files: warning: DWARF2 only supports one section per compilation unit If -Wa,-gdwarf-* is unspecified, then debug info is not emitted for assembly sources (it is still emitted for C sources). This will be re-enabled for newer DWARF versions in a follow up patch. Enables defconfig+CONFIG_DEBUG_INFO to build cleanly with LLVM=1 LLVM_IAS=1 for x86_64 and arm64. Cc: Link: https://github.com/ClangBuiltLinux/linux/issues/716 Reported-by: Dmitry Golovin Reported-by: Nathan Chancellor Suggested-by: Dmitry Golovin Suggested-by: Nathan Chancellor Suggested-by: Sedat Dilek Reviewed-by: Fangrui Song Reviewed-by: Nathan Chancellor Signed-off-by: Nick Desaulniers Signed-off-by: Masahiro Yamada [nd: backport to avoid conflicts from: commit 695afd3d7d58 ("kbuild: Simplify DEBUG_INFO Kconfig handling")] Signed-off-by: Greg Kroah-Hartman