commit 753f4447e2cd4ebfde2c45b633a7ffb971e7103f Author: Alexandre Frade Date: Sat Jul 3 20:46:48 2021 +0000 Linux 5.10.47-rt45-xanmod1 Signed-off-by: Alexandre Frade commit e4a9360f4045d629db0b8f55ea2b88d121978ff2 Author: Alexandre Frade Date: Fri Jun 18 19:10:55 2021 +0000 XANMOD: Makefile: Turn off loop vectorization for GCC -O3 optimization level Signed-off-by: Alexandre Frade commit ebb0bb6da829c440e06d09f7464fb2e24fbbe8cf Author: Arjan van de Ven Date: Thu Jun 2 23:36:32 2016 -0500 drivers: initialize ata before graphics ATA init is the long pole in the boot process, and its asynchronous. move the graphics init after it so that ata and graphics initialize in parallel commit a3b90bcd4aa4fbed0573b53772c550c6683ba11b Merge: 1e5515fad109 4c057b136b69 Author: Alexandre Frade Date: Sat Jul 3 20:37:03 2021 +0000 Merge tag 'v5.10.47-rt45' into 5.10-rt Linux 5.10.47-rt45 commit 4c057b136b69269dbcd4318dd18ff93ddef1a29b Author: Steven Rostedt (VMware) Date: Fri Jul 2 16:37:21 2021 -0400 Linux 5.10.47-rt45 commit b5bcb42fbade43a3b4a0a587a31dec08c076e464 Merge: a9da55f34865 4357ae26d4cd Author: Steven Rostedt (VMware) Date: Fri Jul 2 10:42:23 2021 -0400 Merge tag 'v5.10.47' into v5.10-rt Linux 5.10.47 commit a9da55f34865b0f648739027cdd781ca3c9b63b7 Author: Steven Rostedt (VMware) Date: Fri Jul 2 10:39:53 2021 -0400 Linux 5.10.44-rt44 commit 35017372ac6b376a804841cab9c4fd5764131a47 Merge: 462cf4638cbe f2b1fc360fa1 Author: Steven Rostedt (VMware) Date: Fri Jul 2 10:39:19 2021 -0400 Merge tag 'v5.10.44' into v5.10-rt This is the 5.10.44 stable release Conflicts: kernel/trace/trace.c Signed-off-by: Steven Rostedt (VMware) commit 462cf4638cbe5efd57befb805a4ad24801168455 Author: Steven Rostedt (VMware) Date: Fri Jul 2 10:36:27 2021 -0400 Linux 5.10.42-rt43 commit a5d573c7cae2add6b39dfdbdbcc2a6d26e5daf5d Merge: c7395ea35c92 65859eca4dff Author: Steven Rostedt (VMware) Date: Fri Jul 2 10:35:36 2021 -0400 Merge tag 'v5.10.42' into v5.10-rt This is the 5.10.42 stable release Conflicts: include/net/sch_generic.h Signed-off-by: Steven Rostedt (VMware) commit 4357ae26d4cd133a86982f23cb6b321304faac50 Author: Sasha Levin Date: Wed Jun 30 09:04:24 2021 -0400 Linux 5.10.47 Tested-by: Fox Chen Tested-by: Linux Kernel Functional Testing Tested-by: Sudip Mukherjee Tested-by: Guenter Roeck Tested-by: Hulk Robot Signed-off-by: Sasha Levin commit 1573d595e2395c4d2742d2217d86f6241ca47b9f Author: Eric Snowberg Date: Fri Jan 22 13:10:54 2021 -0500 integrity: Load mokx variables into the blacklist keyring [ Upstream commit ebd9c2ae369a45bdd9f8615484db09be58fc242b ] During boot the Secure Boot Forbidden Signature Database, dbx, is loaded into the blacklist keyring. Systems booted with shim have an equivalent Forbidden Signature Database called mokx. Currently mokx is only used by shim and grub, the contents are ignored by the kernel. Add the ability to load mokx into the blacklist keyring during boot. Signed-off-by: Eric Snowberg Suggested-by: James Bottomley Signed-off-by: David Howells Reviewed-by: Jarkko Sakkinen cc: keyrings@vger.kernel.org Link: https://lore.kernel.org/r/c33c8e3839a41e9654f41cc92c7231104931b1d7.camel@HansenPartnership.com/ Link: https://lore.kernel.org/r/20210122181054.32635-5-eric.snowberg@oracle.com/ # v5 Link: https://lore.kernel.org/r/161428674320.677100.12637282414018170743.stgit@warthog.procyon.org.uk/ Link: https://lore.kernel.org/r/161433313205.902181.2502803393898221637.stgit@warthog.procyon.org.uk/ # v2 Link: https://lore.kernel.org/r/161529607422.163428.13530426573612578854.stgit@warthog.procyon.org.uk/ # v3 Signed-off-by: Sasha Levin commit c6ae6f89fc4f7820d0ce6e8c1340d660b358e791 Author: Eric Snowberg Date: Fri Jan 22 13:10:53 2021 -0500 certs: Add ability to preload revocation certs [ Upstream commit d1f044103dad70c1cec0a8f3abdf00834fec8b98 ] Add a new Kconfig option called SYSTEM_REVOCATION_KEYS. If set, this option should be the filename of a PEM-formated file containing X.509 certificates to be included in the default blacklist keyring. DH Changes: - Make the new Kconfig option depend on SYSTEM_REVOCATION_LIST. - Fix SYSTEM_REVOCATION_KEYS=n, but CONFIG_SYSTEM_REVOCATION_LIST=y[1][2]. - Use CONFIG_SYSTEM_REVOCATION_LIST for extract-cert[3]. - Use CONFIG_SYSTEM_REVOCATION_LIST for revocation_certificates.o[3]. Signed-off-by: Eric Snowberg Acked-by: Jarkko Sakkinen Signed-off-by: David Howells cc: Randy Dunlap cc: keyrings@vger.kernel.org Link: https://lore.kernel.org/r/e1c15c74-82ce-3a69-44de-a33af9b320ea@infradead.org/ [1] Link: https://lore.kernel.org/r/20210303034418.106762-1-eric.snowberg@oracle.com/ [2] Link: https://lore.kernel.org/r/20210304175030.184131-1-eric.snowberg@oracle.com/ [3] Link: https://lore.kernel.org/r/20200930201508.35113-3-eric.snowberg@oracle.com/ Link: https://lore.kernel.org/r/20210122181054.32635-4-eric.snowberg@oracle.com/ # v5 Link: https://lore.kernel.org/r/161428673564.677100.4112098280028451629.stgit@warthog.procyon.org.uk/ Link: https://lore.kernel.org/r/161433312452.902181.4146169951896577982.stgit@warthog.procyon.org.uk/ # v2 Link: https://lore.kernel.org/r/161529606657.163428.3340689182456495390.stgit@warthog.procyon.org.uk/ # v3 Signed-off-by: Sasha Levin commit 72d6f5d982f0e823eaa01b9439db23af85fb0ee0 Author: Eric Snowberg Date: Fri Jan 22 13:10:52 2021 -0500 certs: Move load_system_certificate_list to a common function [ Upstream commit 2565ca7f5ec1a98d51eea8860c4ab923f1ca2c85 ] Move functionality within load_system_certificate_list to a common function, so it can be reused in the future. DH Changes: - Added inclusion of common.h to common.c (Eric [1]). Signed-off-by: Eric Snowberg Acked-by: Jarkko Sakkinen Signed-off-by: David Howells cc: keyrings@vger.kernel.org Link: https://lore.kernel.org/r/EDA280F9-F72D-4181-93C7-CDBE95976FF7@oracle.com/ [1] Link: https://lore.kernel.org/r/20200930201508.35113-2-eric.snowberg@oracle.com/ Link: https://lore.kernel.org/r/20210122181054.32635-3-eric.snowberg@oracle.com/ # v5 Link: https://lore.kernel.org/r/161428672825.677100.7545516389752262918.stgit@warthog.procyon.org.uk/ Link: https://lore.kernel.org/r/161433311696.902181.3599366124784670368.stgit@warthog.procyon.org.uk/ # v2 Link: https://lore.kernel.org/r/161529605850.163428.7786675680201528556.stgit@warthog.procyon.org.uk/ # v3 Signed-off-by: Sasha Levin commit 45109066f686597116467a53eaf4330450702a96 Author: Eric Snowberg Date: Fri Jan 22 13:10:51 2021 -0500 certs: Add EFI_CERT_X509_GUID support for dbx entries [ Upstream commit 56c5812623f95313f6a46fbf0beee7fa17c68bbf ] This fixes CVE-2020-26541. The Secure Boot Forbidden Signature Database, dbx, contains a list of now revoked signatures and keys previously approved to boot with UEFI Secure Boot enabled. The dbx is capable of containing any number of EFI_CERT_X509_SHA256_GUID, EFI_CERT_SHA256_GUID, and EFI_CERT_X509_GUID entries. Currently when EFI_CERT_X509_GUID are contained in the dbx, the entries are skipped. Add support for EFI_CERT_X509_GUID dbx entries. When a EFI_CERT_X509_GUID is found, it is added as an asymmetrical key to the .blacklist keyring. Anytime the .platform keyring is used, the keys in the .blacklist keyring are referenced, if a matching key is found, the key will be rejected. [DH: Made the following changes: - Added to have a config option to enable the facility. This allows a Kconfig solution to make sure that pkcs7_validate_trust() is enabled.[1][2] - Moved the functions out from the middle of the blacklist functions. - Added kerneldoc comments.] Signed-off-by: Eric Snowberg Signed-off-by: David Howells Reviewed-by: Jarkko Sakkinen cc: Randy Dunlap cc: Mickaël Salaün cc: Arnd Bergmann cc: keyrings@vger.kernel.org Link: https://lore.kernel.org/r/20200901165143.10295-1-eric.snowberg@oracle.com/ # rfc Link: https://lore.kernel.org/r/20200909172736.73003-1-eric.snowberg@oracle.com/ # v2 Link: https://lore.kernel.org/r/20200911182230.62266-1-eric.snowberg@oracle.com/ # v3 Link: https://lore.kernel.org/r/20200916004927.64276-1-eric.snowberg@oracle.com/ # v4 Link: https://lore.kernel.org/r/20210122181054.32635-2-eric.snowberg@oracle.com/ # v5 Link: https://lore.kernel.org/r/161428672051.677100.11064981943343605138.stgit@warthog.procyon.org.uk/ Link: https://lore.kernel.org/r/161433310942.902181.4901864302675874242.stgit@warthog.procyon.org.uk/ # v2 Link: https://lore.kernel.org/r/161529605075.163428.14625520893961300757.stgit@warthog.procyon.org.uk/ # v3 Link: https://lore.kernel.org/r/bc2c24e3-ed68-2521-0bf4-a1f6be4a895d@infradead.org/ [1] Link: https://lore.kernel.org/r/20210225125638.1841436-1-arnd@kernel.org/ [2] Signed-off-by: Sasha Levin commit 0ba128fa68a4abfdfc8928f0ed67b5eb80962254 Author: Daniel Vetter Date: Tue Jun 22 09:54:09 2021 +0200 Revert "drm: add a locked version of drm_is_current_master" commit f54b3ca7ea1e5e02f481cf4ca54568e57bd66086 upstream. This reverts commit 1815d9c86e3090477fbde066ff314a7e9721ee0f. Unfortunately this inverts the locking hierarchy, so back to the drawing board. Full lockdep splat below: ====================================================== WARNING: possible circular locking dependency detected 5.13.0-rc7-CI-CI_DRM_10254+ #1 Not tainted ------------------------------------------------------ kms_frontbuffer/1087 is trying to acquire lock: ffff88810dcd01a8 (&dev->master_mutex){+.+.}-{3:3}, at: drm_is_current_master+0x1b/0x40 but task is already holding lock: ffff88810dcd0488 (&dev->mode_config.mutex){+.+.}-{3:3}, at: drm_mode_getconnector+0x1c6/0x4a0 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&dev->mode_config.mutex){+.+.}-{3:3}: __mutex_lock+0xab/0x970 drm_client_modeset_probe+0x22e/0xca0 __drm_fb_helper_initial_config_and_unlock+0x42/0x540 intel_fbdev_initial_config+0xf/0x20 [i915] async_run_entry_fn+0x28/0x130 process_one_work+0x26d/0x5c0 worker_thread+0x37/0x380 kthread+0x144/0x170 ret_from_fork+0x1f/0x30 -> #1 (&client->modeset_mutex){+.+.}-{3:3}: __mutex_lock+0xab/0x970 drm_client_modeset_commit_locked+0x1c/0x180 drm_client_modeset_commit+0x1c/0x40 __drm_fb_helper_restore_fbdev_mode_unlocked+0x88/0xb0 drm_fb_helper_set_par+0x34/0x40 intel_fbdev_set_par+0x11/0x40 [i915] fbcon_init+0x270/0x4f0 visual_init+0xc6/0x130 do_bind_con_driver+0x1e5/0x2d0 do_take_over_console+0x10e/0x180 do_fbcon_takeover+0x53/0xb0 register_framebuffer+0x22d/0x310 __drm_fb_helper_initial_config_and_unlock+0x36c/0x540 intel_fbdev_initial_config+0xf/0x20 [i915] async_run_entry_fn+0x28/0x130 process_one_work+0x26d/0x5c0 worker_thread+0x37/0x380 kthread+0x144/0x170 ret_from_fork+0x1f/0x30 -> #0 (&dev->master_mutex){+.+.}-{3:3}: __lock_acquire+0x151e/0x2590 lock_acquire+0xd1/0x3d0 __mutex_lock+0xab/0x970 drm_is_current_master+0x1b/0x40 drm_mode_getconnector+0x37e/0x4a0 drm_ioctl_kernel+0xa8/0xf0 drm_ioctl+0x1e8/0x390 __x64_sys_ioctl+0x6a/0xa0 do_syscall_64+0x39/0xb0 entry_SYSCALL_64_after_hwframe+0x44/0xae other info that might help us debug this: Chain exists of: &dev->master_mutex --> &client->modeset_mutex --> &dev->mode_config.mutex Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&dev->mode_config.mutex); lock(&client->modeset_mutex); lock(&dev->mode_config.mutex); lock(&dev->master_mutex); commit 0463b49e0239bb04f6ca5d7b697645e1122c30f8 Author: Jeff Layton Date: Sun Jun 13 19:33:45 2021 -0400 netfs: fix test for whether we can skip read when writing beyond EOF commit 827a746f405d25f79560c7868474aec5aee174e1 upstream. It's not sufficient to skip reading when the pos is beyond the EOF. There may be data at the head of the page that we need to fill in before the write. Add a new helper function that corrects and clarifies the logic of when we can skip reads, and have it only zero out the part of the page that won't have data copied in for the write. Finally, don't set the page Uptodate after zeroing. It's not up to date since the write data won't have been copied in yet. [DH made the following changes: - Prefixed the new function with "netfs_". - Don't call zero_user_segments() for a full-page write. - Altered the beyond-last-page check to avoid a DIV instruction and got rid of then-redundant zero-length file check. ] [ Note: this fix is commit 827a746f405d in mainline kernels. The original bug was in ceph, but got lifted into the fs/netfs library for v5.13. This backport should apply to stable kernels v5.10 though v5.12. ] Fixes: e1b1240c1ff5f ("netfs: Add write_begin helper") Reported-by: Andrew W Elble Signed-off-by: Jeff Layton Signed-off-by: David Howells Reviewed-by: Matthew Wilcox (Oracle) cc: ceph-devel@vger.kernel.org Link: https://lore.kernel.org/r/20210613233345.113565-1-jlayton@kernel.org/ Link: https://lore.kernel.org/r/162367683365.460125.4467036947364047314.stgit@warthog.procyon.org.uk/ # v1 Link: https://lore.kernel.org/r/162391826758.1173366.11794946719301590013.stgit@warthog.procyon.org.uk/ # v2 Signed-off-by: Greg Kroah-Hartman commit e6108147dd91b94d1979b110f265710c254c99d5 Author: Bumyong Lee Date: Mon May 10 18:10:04 2021 +0900 swiotlb: manipulate orig_addr when tlb_addr has offset commit 5f89468e2f060031cd89fd4287298e0eaf246bf6 upstream. in case of driver wants to sync part of ranges with offset, swiotlb_tbl_sync_single() copies from orig_addr base to tlb_addr with offset and ends up with data mismatch. It was removed from "swiotlb: don't modify orig_addr in swiotlb_tbl_sync_single", but said logic has to be added back in. From Linus's email: "That commit which the removed the offset calculation entirely, because the old (unsigned long)tlb_addr & (IO_TLB_SIZE - 1) was wrong, but instead of removing it, I think it should have just fixed it to be (tlb_addr - mem->start) & (IO_TLB_SIZE - 1); instead. That way the slot offset always matches the slot index calculation." (Unfortunatly that broke NVMe). The use-case that drivers are hitting is as follow: 1. Get dma_addr_t from dma_map_single() dma_addr_t tlb_addr = dma_map_single(dev, vaddr, vsize, DMA_TO_DEVICE); |<---------------vsize------------->| +-----------------------------------+ | | original buffer +-----------------------------------+ vaddr swiotlb_align_offset |<----->|<---------------vsize------------->| +-------+-----------------------------------+ | | | swiotlb buffer +-------+-----------------------------------+ tlb_addr 2. Do something 3. Sync dma_addr_t through dma_sync_single_for_device(..) dma_sync_single_for_device(dev, tlb_addr + offset, size, DMA_TO_DEVICE); Error case. Copy data to original buffer but it is from base addr (instead of base addr + offset) in original buffer: swiotlb_align_offset |<----->|<- offset ->|<- size ->| +-------+-----------------------------------+ | | |##########| | swiotlb buffer +-------+-----------------------------------+ tlb_addr |<- size ->| +-----------------------------------+ |##########| | original buffer +-----------------------------------+ vaddr The fix is to copy the data to the original buffer and take into account the offset, like so: swiotlb_align_offset |<----->|<- offset ->|<- size ->| +-------+-----------------------------------+ | | |##########| | swiotlb buffer +-------+-----------------------------------+ tlb_addr |<- offset ->|<- size ->| +-----------------------------------+ | |##########| | original buffer +-----------------------------------+ vaddr [One fix which was Linus's that made more sense to as it created a symmetry would break NVMe. The reason for that is the: unsigned int offset = (tlb_addr - mem->start) & (IO_TLB_SIZE - 1); would come up with the proper offset, but it would lose the alignment (which this patch contains).] Fixes: 16fc3cef33a0 ("swiotlb: don't modify orig_addr in swiotlb_tbl_sync_single") Signed-off-by: Bumyong Lee Signed-off-by: Chanho Park Reviewed-by: Christoph Hellwig Reported-by: Dominique MARTINET Reported-by: Horia Geantă Tested-by: Horia Geantă CC: stable@vger.kernel.org Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman commit 7570a8b5dd493eebda5c0c826f3a87e2e6117791 Author: Alper Gun Date: Thu Jun 10 17:46:04 2021 +0000 KVM: SVM: Call SEV Guest Decommission if ASID binding fails commit 934002cd660b035b926438244b4294e647507e13 upstream. Send SEV_CMD_DECOMMISSION command to PSP firmware if ASID binding fails. If a failure happens after a successful LAUNCH_START command, a decommission command should be executed. Otherwise, guest context will be unfreed inside the AMD SP. After the firmware will not have memory to allocate more SEV guest context, LAUNCH_START command will begin to fail with SEV_RET_RESOURCE_LIMIT error. The existing code calls decommission inside sev_unbind_asid, but it is not called if a failure happens before guest activation succeeds. If sev_bind_asid fails, decommission is never called. PSP firmware has a limit for the number of guests. If sev_asid_binding fails many times, PSP firmware will not have resources to create another guest context. Cc: stable@vger.kernel.org Fixes: 59414c989220 ("KVM: SVM: Add support for KVM_SEV_LAUNCH_START command") Reported-by: Peter Gonda Signed-off-by: Alper Gun Reviewed-by: Marc Orr Signed-off-by: Paolo Bonzini Message-Id: <20210610174604.2554090-1-alpergun@google.com> Signed-off-by: Greg Kroah-Hartman commit 377a796e7a7102e543b4d1ccce473ed2df09f0d7 Author: Hugh Dickins Date: Thu Jun 24 18:39:52 2021 -0700 mm, futex: fix shared futex pgoff on shmem huge page commit fe19bd3dae3d15d2fbfdb3de8839a6ea0fe94264 upstream. If more than one futex is placed on a shmem huge page, it can happen that waking the second wakes the first instead, and leaves the second waiting: the key's shared.pgoff is wrong. When 3.11 commit 13d60f4b6ab5 ("futex: Take hugepages into account when generating futex_key"), the only shared huge pages came from hugetlbfs, and the code added to deal with its exceptional page->index was put into hugetlb source. Then that was missed when 4.8 added shmem huge pages. page_to_pgoff() is what others use for this nowadays: except that, as currently written, it gives the right answer on hugetlbfs head, but nonsense on hugetlbfs tails. Fix that by calling hugetlbfs-specific hugetlb_basepage_index() on PageHuge tails as well as on head. Yes, it's unconventional to declare hugetlb_basepage_index() there in pagemap.h, rather than in hugetlb.h; but I do not expect anything but page_to_pgoff() ever to need it. [akpm@linux-foundation.org: give hugetlb_basepage_index() prototype the correct scope] Link: https://lkml.kernel.org/r/b17d946b-d09-326e-b42a-52884c36df32@google.com Fixes: 800d8c63b2e9 ("shmem: add huge pages support") Reported-by: Neel Natu Signed-off-by: Hugh Dickins Reviewed-by: Matthew Wilcox (Oracle) Acked-by: Thomas Gleixner Cc: "Kirill A. Shutemov" Cc: Zhang Yi Cc: Mel Gorman Cc: Mike Kravetz Cc: Ingo Molnar Cc: Peter Zijlstra Cc: Darren Hart Cc: Davidlohr Bueso Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit ab9d178167eae80b623baaedc1b5e3142fe480ce Author: Hugh Dickins Date: Thu Jun 24 18:39:30 2021 -0700 mm/thp: another PVMW_SYNC fix in page_vma_mapped_walk() commit a7a69d8ba88d8dcee7ef00e91d413a4bd003a814 upstream. Aha! Shouldn't that quick scan over pte_none()s make sure that it holds ptlock in the PVMW_SYNC case? That too might have been responsible for BUGs or WARNs in split_huge_page_to_list() or its unmap_page(), though I've never seen any. Link: https://lkml.kernel.org/r/1bdf384c-8137-a149-2a1e-475a4791c3c@google.com Link: https://lore.kernel.org/linux-mm/20210412180659.B9E3.409509F4@e16-tech.com/ Fixes: ace71a19cec5 ("mm: introduce page_vma_mapped_walk()") Signed-off-by: Hugh Dickins Acked-by: Kirill A. Shutemov Tested-by: Wang Yugui Cc: Alistair Popple Cc: Matthew Wilcox Cc: Peter Xu Cc: Ralph Campbell Cc: Will Deacon Cc: Yang Shi Cc: Zi Yan Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 915c3a262c49fcd1caa7dff192289bdfdaa9438c Author: Hugh Dickins Date: Thu Jun 24 18:39:26 2021 -0700 mm/thp: fix page_vma_mapped_walk() if THP mapped by ptes commit a9a7504d9beaf395481faa91e70e2fd08f7a3dde upstream. Running certain tests with a DEBUG_VM kernel would crash within hours, on the total_mapcount BUG() in split_huge_page_to_list(), while trying to free up some memory by punching a hole in a shmem huge page: split's try_to_unmap() was unable to find all the mappings of the page (which, on a !DEBUG_VM kernel, would then keep the huge page pinned in memory). Crash dumps showed two tail pages of a shmem huge page remained mapped by pte: ptes in a non-huge-aligned vma of a gVisor process, at the end of a long unmapped range; and no page table had yet been allocated for the head of the huge page to be mapped into. Although designed to handle these odd misaligned huge-page-mapped-by-pte cases, page_vma_mapped_walk() falls short by returning false prematurely when !pmd_present or !pud_present or !p4d_present or !pgd_present: there are cases when a huge page may span the boundary, with ptes present in the next. Restructure page_vma_mapped_walk() as a loop to continue in these cases, while keeping its layout much as before. Add a step_forward() helper to advance pvmw->address across those boundaries: originally I tried to use mm's standard p?d_addr_end() macros, but hit the same crash 512 times less often: because of the way redundant levels are folded together, but folded differently in different configurations, it was just too difficult to use them correctly; and step_forward() is simpler anyway. Link: https://lkml.kernel.org/r/fedb8632-1798-de42-f39e-873551d5bc81@google.com Fixes: ace71a19cec5 ("mm: introduce page_vma_mapped_walk()") Signed-off-by: Hugh Dickins Acked-by: Kirill A. Shutemov Cc: Alistair Popple Cc: Matthew Wilcox Cc: Peter Xu Cc: Ralph Campbell Cc: Wang Yugui Cc: Will Deacon Cc: Yang Shi Cc: Zi Yan Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 90073aecc3ccabb7b8ee9fc968c6b9e3f03ebaed Author: Hugh Dickins Date: Thu Jun 24 18:39:23 2021 -0700 mm: page_vma_mapped_walk(): get vma_address_end() earlier commit a765c417d876cc635f628365ec9aa6f09470069a upstream. page_vma_mapped_walk() cleanup: get THP's vma_address_end() at the start, rather than later at next_pte. It's a little unnecessary overhead on the first call, but makes for a simpler loop in the following commit. Link: https://lkml.kernel.org/r/4542b34d-862f-7cb4-bb22-e0df6ce830a2@google.com Signed-off-by: Hugh Dickins Acked-by: Kirill A. Shutemov Cc: Alistair Popple Cc: Matthew Wilcox Cc: Peter Xu Cc: Ralph Campbell Cc: Wang Yugui Cc: Will Deacon Cc: Yang Shi Cc: Zi Yan Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit bf60fc2314b98fc57b8ef20a7a3a5642513ef6d1 Author: Hugh Dickins Date: Thu Jun 24 18:39:20 2021 -0700 mm: page_vma_mapped_walk(): use goto instead of while (1) commit 474466301dfd8b39a10c01db740645f3f7ae9a28 upstream. page_vma_mapped_walk() cleanup: add a label this_pte, matching next_pte, and use "goto this_pte", in place of the "while (1)" loop at the end. Link: https://lkml.kernel.org/r/a52b234a-851-3616-2525-f42736e8934@google.com Signed-off-by: Hugh Dickins Acked-by: Kirill A. Shutemov Cc: Alistair Popple Cc: Matthew Wilcox Cc: Peter Xu Cc: Ralph Campbell Cc: Wang Yugui Cc: Will Deacon Cc: Yang Shi Cc: Zi Yan Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 9f85dcaf1533a20d0ba8443a214af19a8a732f64 Author: Hugh Dickins Date: Thu Jun 24 18:39:17 2021 -0700 mm: page_vma_mapped_walk(): add a level of indentation commit b3807a91aca7d21c05d5790612e49969117a72b9 upstream. page_vma_mapped_walk() cleanup: add a level of indentation to much of the body, making no functional change in this commit, but reducing the later diff when this is all converted to a loop. [hughd@google.com: : page_vma_mapped_walk(): add a level of indentation fix] Link: https://lkml.kernel.org/r/7f817555-3ce1-c785-e438-87d8efdcaf26@google.com Link: https://lkml.kernel.org/r/efde211-f3e2-fe54-977-ef481419e7f3@google.com Signed-off-by: Hugh Dickins Acked-by: Kirill A. Shutemov Cc: Alistair Popple Cc: Matthew Wilcox Cc: Peter Xu Cc: Ralph Campbell Cc: Wang Yugui Cc: Will Deacon Cc: Yang Shi Cc: Zi Yan Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit e56bdb397663ede28465891026757376018d2c3d Author: Hugh Dickins Date: Thu Jun 24 18:39:14 2021 -0700 mm: page_vma_mapped_walk(): crossing page table boundary commit 448282487483d6fa5b2eeeafaa0acc681e544a9c upstream. page_vma_mapped_walk() cleanup: adjust the test for crossing page table boundary - I believe pvmw->address is always page-aligned, but nothing else here assumed that; and remember to reset pvmw->pte to NULL after unmapping the page table, though I never saw any bug from that. Link: https://lkml.kernel.org/r/799b3f9c-2a9e-dfef-5d89-26e9f76fd97@google.com Signed-off-by: Hugh Dickins Acked-by: Kirill A. Shutemov Cc: Alistair Popple Cc: Matthew Wilcox Cc: Peter Xu Cc: Ralph Campbell Cc: Wang Yugui Cc: Will Deacon Cc: Yang Shi Cc: Zi Yan Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 8dc191ed9c5f7af7f6cd1ebea3f281db353fe442 Author: Hugh Dickins Date: Thu Jun 24 18:39:10 2021 -0700 mm: page_vma_mapped_walk(): prettify PVMW_MIGRATION block commit e2e1d4076c77b3671cf8ce702535ae7dee3acf89 upstream. page_vma_mapped_walk() cleanup: rearrange the !pmd_present() block to follow the same "return not_found, return not_found, return true" pattern as the block above it (note: returning not_found there is never premature, since existence or prior existence of huge pmd guarantees good alignment). Link: https://lkml.kernel.org/r/378c8650-1488-2edf-9647-32a53cf2e21@google.com Signed-off-by: Hugh Dickins Acked-by: Kirill A. Shutemov Reviewed-by: Peter Xu Cc: Alistair Popple Cc: Matthew Wilcox Cc: Ralph Campbell Cc: Wang Yugui Cc: Will Deacon Cc: Yang Shi Cc: Zi Yan Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 7b55a4bcfccf839d5b65fbfba82f8edcf1bef423 Author: Hugh Dickins Date: Thu Jun 24 18:39:07 2021 -0700 mm: page_vma_mapped_walk(): use pmde for *pvmw->pmd commit 3306d3119ceacc43ea8b141a73e21fea68eec30c upstream. page_vma_mapped_walk() cleanup: re-evaluate pmde after taking lock, then use it in subsequent tests, instead of repeatedly dereferencing pointer. Link: https://lkml.kernel.org/r/53fbc9d-891e-46b2-cb4b-468c3b19238e@google.com Signed-off-by: Hugh Dickins Acked-by: Kirill A. Shutemov Reviewed-by: Peter Xu Cc: Alistair Popple Cc: Matthew Wilcox Cc: Ralph Campbell Cc: Wang Yugui Cc: Will Deacon Cc: Yang Shi Cc: Zi Yan Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 1cb0b9059f9ef46e113fd90ed50accbc877cc013 Author: Hugh Dickins Date: Thu Jun 24 18:39:04 2021 -0700 mm: page_vma_mapped_walk(): settle PageHuge on entry commit 6d0fd5987657cb0c9756ce684e3a74c0f6351728 upstream. page_vma_mapped_walk() cleanup: get the hugetlbfs PageHuge case out of the way at the start, so no need to worry about it later. Link: https://lkml.kernel.org/r/e31a483c-6d73-a6bb-26c5-43c3b880a2@google.com Signed-off-by: Hugh Dickins Acked-by: Kirill A. Shutemov Reviewed-by: Peter Xu Cc: Alistair Popple Cc: "Kirill A. Shutemov" Cc: Matthew Wilcox Cc: Ralph Campbell Cc: Wang Yugui Cc: Will Deacon Cc: Yang Shi Cc: Zi Yan Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 65febb41b4d653edb4300c538fda80f383db7e41 Author: Hugh Dickins Date: Thu Jun 24 18:39:01 2021 -0700 mm: page_vma_mapped_walk(): use page for pvmw->page commit f003c03bd29e6f46fef1b9a8e8d636ac732286d5 upstream. Patch series "mm: page_vma_mapped_walk() cleanup and THP fixes". I've marked all of these for stable: many are merely cleanups, but I think they are much better before the main fix than after. This patch (of 11): page_vma_mapped_walk() cleanup: sometimes the local copy of pvwm->page was used, sometimes pvmw->page itself: use the local copy "page" throughout. Link: https://lkml.kernel.org/r/589b358c-febc-c88e-d4c2-7834b37fa7bf@google.com Link: https://lkml.kernel.org/r/88e67645-f467-c279-bf5e-af4b5c6b13eb@google.com Signed-off-by: Hugh Dickins Reviewed-by: Alistair Popple Acked-by: Kirill A. Shutemov Reviewed-by: Peter Xu Cc: Yang Shi Cc: Wang Yugui Cc: Matthew Wilcox Cc: Ralph Campbell Cc: Zi Yan Cc: Will Deacon Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 825c28052b4d15bd0e05d9a06f23c5bd17459735 Author: Yang Shi Date: Tue Jun 15 18:24:07 2021 -0700 mm: thp: replace DEBUG_VM BUG with VM_WARN when unmap fails for split [ Upstream commit 504e070dc08f757bccaed6d05c0f53ecbfac8a23 ] When debugging the bug reported by Wang Yugui [1], try_to_unmap() may fail, but the first VM_BUG_ON_PAGE() just checks page_mapcount() however it may miss the failure when head page is unmapped but other subpage is mapped. Then the second DEBUG_VM BUG() that check total mapcount would catch it. This may incur some confusion. As this is not a fatal issue, so consolidate the two DEBUG_VM checks into one VM_WARN_ON_ONCE_PAGE(). [1] https://lore.kernel.org/linux-mm/20210412180659.B9E3.409509F4@e16-tech.com/ Link: https://lkml.kernel.org/r/d0f0db68-98b8-ebfb-16dc-f29df24cf012@google.com Signed-off-by: Yang Shi Reviewed-by: Zi Yan Acked-by: Kirill A. Shutemov Signed-off-by: Hugh Dickins Cc: Alistair Popple Cc: Jan Kara Cc: Jue Wang Cc: "Matthew Wilcox (Oracle)" Cc: Miaohe Lin Cc: Minchan Kim Cc: Naoya Horiguchi Cc: Oscar Salvador Cc: Peter Xu Cc: Ralph Campbell Cc: Shakeel Butt Cc: Wang Yugui Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Note on stable backport: fixed up variables in split_huge_page_to_list(). Signed-off-by: Hugh Dickins Signed-off-by: Greg Kroah-Hartman commit 0010275ca243e6260893207d41843bb8dc3846e4 Author: Hugh Dickins Date: Tue Jun 15 18:24:03 2021 -0700 mm/thp: unmap_mapping_page() to fix THP truncate_cleanup_page() [ Upstream commit 22061a1ffabdb9c3385de159c5db7aac3a4df1cc ] There is a race between THP unmapping and truncation, when truncate sees pmd_none() and skips the entry, after munmap's zap_huge_pmd() cleared it, but before its page_remove_rmap() gets to decrement compound_mapcount: generating false "BUG: Bad page cache" reports that the page is still mapped when deleted. This commit fixes that, but not in the way I hoped. The first attempt used try_to_unmap(page, TTU_SYNC|TTU_IGNORE_MLOCK) instead of unmap_mapping_range() in truncate_cleanup_page(): it has often been an annoyance that we usually call unmap_mapping_range() with no pages locked, but there apply it to a single locked page. try_to_unmap() looks more suitable for a single locked page. However, try_to_unmap_one() contains a VM_BUG_ON_PAGE(!pvmw.pte,page): it is used to insert THP migration entries, but not used to unmap THPs. Copy zap_huge_pmd() and add THP handling now? Perhaps, but their TLB needs are different, I'm too ignorant of the DAX cases, and couldn't decide how far to go for anon+swap. Set that aside. The second attempt took a different tack: make no change in truncate.c, but modify zap_huge_pmd() to insert an invalidated huge pmd instead of clearing it initially, then pmd_clear() between page_remove_rmap() and unlocking at the end. Nice. But powerpc blows that approach out of the water, with its serialize_against_pte_lookup(), and interesting pgtable usage. It would need serious help to get working on powerpc (with a minor optimization issue on s390 too). Set that aside. Just add an "if (page_mapped(page)) synchronize_rcu();" or other such delay, after unmapping in truncate_cleanup_page()? Perhaps, but though that's likely to reduce or eliminate the number of incidents, it would give less assurance of whether we had identified the problem correctly. This successful iteration introduces "unmap_mapping_page(page)" instead of try_to_unmap(), and goes the usual unmap_mapping_range_tree() route, with an addition to details. Then zap_pmd_range() watches for this case, and does spin_unlock(pmd_lock) if so - just like page_vma_mapped_walk() now does in the PVMW_SYNC case. Not pretty, but safe. Note that unmap_mapping_page() is doing a VM_BUG_ON(!PageLocked) to assert its interface; but currently that's only used to make sure that page->mapping is stable, and zap_pmd_range() doesn't care if the page is locked or not. Along these lines, in invalidate_inode_pages2_range() move the initial unmap_mapping_range() out from under page lock, before then calling unmap_mapping_page() under page lock if still mapped. Link: https://lkml.kernel.org/r/a2a4a148-cdd8-942c-4ef8-51b77f643dbe@google.com Fixes: fc127da085c2 ("truncate: handle file thp") Signed-off-by: Hugh Dickins Acked-by: Kirill A. Shutemov Reviewed-by: Yang Shi Cc: Alistair Popple Cc: Jan Kara Cc: Jue Wang Cc: "Matthew Wilcox (Oracle)" Cc: Miaohe Lin Cc: Minchan Kim Cc: Naoya Horiguchi Cc: Oscar Salvador Cc: Peter Xu Cc: Ralph Campbell Cc: Shakeel Butt Cc: Wang Yugui Cc: Zi Yan Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Note on stable backport: fixed up call to truncate_cleanup_page() in truncate_inode_pages_range(). Signed-off-by: Hugh Dickins Signed-off-by: Greg Kroah-Hartman commit 38cda6b5ab83dcb3e2bdc6c1e6474488e089e4a6 Author: Jue Wang Date: Tue Jun 15 18:24:00 2021 -0700 mm/thp: fix page_address_in_vma() on file THP tails commit 31657170deaf1d8d2f6a1955fbc6fa9d228be036 upstream. Anon THP tails were already supported, but memory-failure may need to use page_address_in_vma() on file THP tails, which its page->mapping check did not permit: fix it. hughd adds: no current usage is known to hit the issue, but this does fix a subtle trap in a general helper: best fixed in stable sooner than later. Link: https://lkml.kernel.org/r/a0d9b53-bf5d-8bab-ac5-759dc61819c1@google.com Fixes: 800d8c63b2e9 ("shmem: add huge pages support") Signed-off-by: Jue Wang Signed-off-by: Hugh Dickins Reviewed-by: Matthew Wilcox (Oracle) Reviewed-by: Yang Shi Acked-by: Kirill A. Shutemov Cc: Alistair Popple Cc: Jan Kara Cc: Miaohe Lin Cc: Minchan Kim Cc: Naoya Horiguchi Cc: Oscar Salvador Cc: Peter Xu Cc: Ralph Campbell Cc: Shakeel Butt Cc: Wang Yugui Cc: Zi Yan Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 37ffe9f4d7ff60f9f8919d4c702c948dcbb200f3 Author: Hugh Dickins Date: Tue Jun 15 18:23:56 2021 -0700 mm/thp: fix vma_address() if virtual address below file offset commit 494334e43c16d63b878536a26505397fce6ff3a2 upstream. Running certain tests with a DEBUG_VM kernel would crash within hours, on the total_mapcount BUG() in split_huge_page_to_list(), while trying to free up some memory by punching a hole in a shmem huge page: split's try_to_unmap() was unable to find all the mappings of the page (which, on a !DEBUG_VM kernel, would then keep the huge page pinned in memory). When that BUG() was changed to a WARN(), it would later crash on the VM_BUG_ON_VMA(end < vma->vm_start || start >= vma->vm_end, vma) in mm/internal.h:vma_address(), used by rmap_walk_file() for try_to_unmap(). vma_address() is usually correct, but there's a wraparound case when the vm_start address is unusually low, but vm_pgoff not so low: vma_address() chooses max(start, vma->vm_start), but that decides on the wrong address, because start has become almost ULONG_MAX. Rewrite vma_address() to be more careful about vm_pgoff; move the VM_BUG_ON_VMA() out of it, returning -EFAULT for errors, so that it can be safely used from page_mapped_in_vma() and page_address_in_vma() too. Add vma_address_end() to apply similar care to end address calculation, in page_vma_mapped_walk() and page_mkclean_one() and try_to_unmap_one(); though it raises a question of whether callers would do better to supply pvmw->end to page_vma_mapped_walk() - I chose not, for a smaller patch. An irritation is that their apparent generality breaks down on KSM pages, which cannot be located by the page->index that page_to_pgoff() uses: as commit 4b0ece6fa016 ("mm: migrate: fix remove_migration_pte() for ksm pages") once discovered. I dithered over the best thing to do about that, and have ended up with a VM_BUG_ON_PAGE(PageKsm) in both vma_address() and vma_address_end(); though the only place in danger of using it on them was try_to_unmap_one(). Sidenote: vma_address() and vma_address_end() now use compound_nr() on a head page, instead of thp_size(): to make the right calculation on a hugetlbfs page, whether or not THPs are configured. try_to_unmap() is used on hugetlbfs pages, but perhaps the wrong calculation never mattered. Link: https://lkml.kernel.org/r/caf1c1a3-7cfb-7f8f-1beb-ba816e932825@google.com Fixes: a8fa41ad2f6f ("mm, rmap: check all VMAs that PTE-mapped THP can be part of") Signed-off-by: Hugh Dickins Acked-by: Kirill A. Shutemov Cc: Alistair Popple Cc: Jan Kara Cc: Jue Wang Cc: "Matthew Wilcox (Oracle)" Cc: Miaohe Lin Cc: Minchan Kim Cc: Naoya Horiguchi Cc: Oscar Salvador Cc: Peter Xu Cc: Ralph Campbell Cc: Shakeel Butt Cc: Wang Yugui Cc: Yang Shi Cc: Zi Yan Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 66be14a9260913d5700b95fb327fc2d3300809b7 Author: Hugh Dickins Date: Tue Jun 15 18:23:53 2021 -0700 mm/thp: try_to_unmap() use TTU_SYNC for safe splitting commit 732ed55823fc3ad998d43b86bf771887bcc5ec67 upstream. Stressing huge tmpfs often crashed on unmap_page()'s VM_BUG_ON_PAGE (!unmap_success): with dump_page() showing mapcount:1, but then its raw struct page output showing _mapcount ffffffff i.e. mapcount 0. And even if that particular VM_BUG_ON_PAGE(!unmap_success) is removed, it is immediately followed by a VM_BUG_ON_PAGE(compound_mapcount(head)), and further down an IS_ENABLED(CONFIG_DEBUG_VM) total_mapcount BUG(): all indicative of some mapcount difficulty in development here perhaps. But the !CONFIG_DEBUG_VM path handles the failures correctly and silently. I believe the problem is that once a racing unmap has cleared pte or pmd, try_to_unmap_one() may skip taking the page table lock, and emerge from try_to_unmap() before the racing task has reached decrementing mapcount. Instead of abandoning the unsafe VM_BUG_ON_PAGE(), and the ones that follow, use PVMW_SYNC in try_to_unmap_one() in this case: adding TTU_SYNC to the options, and passing that from unmap_page(). When CONFIG_DEBUG_VM, or for non-debug too? Consensus is to do the same for both: the slight overhead added should rarely matter, except perhaps if splitting sparsely-populated multiply-mapped shmem. Once confident that bugs are fixed, TTU_SYNC here can be removed, and the race tolerated. Link: https://lkml.kernel.org/r/c1e95853-8bcd-d8fd-55fa-e7f2488e78f@google.com Fixes: fec89c109f3a ("thp: rewrite freeze_page()/unfreeze_page() with generic rmap walkers") Signed-off-by: Hugh Dickins Cc: Alistair Popple Cc: Jan Kara Cc: Jue Wang Cc: Kirill A. Shutemov Cc: "Matthew Wilcox (Oracle)" Cc: Miaohe Lin Cc: Minchan Kim Cc: Naoya Horiguchi Cc: Oscar Salvador Cc: Peter Xu Cc: Ralph Campbell Cc: Shakeel Butt Cc: Wang Yugui Cc: Yang Shi Cc: Zi Yan Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 6527d8ef68c3ca3c455e38ae2a37cd7810caec73 Author: Hugh Dickins Date: Tue Jun 15 18:23:49 2021 -0700 mm/thp: make is_huge_zero_pmd() safe and quicker commit 3b77e8c8cde581dadab9a0f1543a347e24315f11 upstream. Most callers of is_huge_zero_pmd() supply a pmd already verified present; but a few (notably zap_huge_pmd()) do not - it might be a pmd migration entry, in which the pfn is encoded differently from a present pmd: which might pass the is_huge_zero_pmd() test (though not on x86, since L1TF forced us to protect against that); or perhaps even crash in pmd_page() applied to a swap-like entry. Make it safe by adding pmd_present() check into is_huge_zero_pmd() itself; and make it quicker by saving huge_zero_pfn, so that is_huge_zero_pmd() will not need to do that pmd_page() lookup each time. __split_huge_pmd_locked() checked pmd_trans_huge() before: that worked, but is unnecessary now that is_huge_zero_pmd() checks present. Link: https://lkml.kernel.org/r/21ea9ca-a1f5-8b90-5e88-95fb1c49bbfa@google.com Fixes: e71769ae5260 ("mm: enable thp migration for shmem thp") Signed-off-by: Hugh Dickins Acked-by: Kirill A. Shutemov Reviewed-by: Yang Shi Cc: Alistair Popple Cc: Jan Kara Cc: Jue Wang Cc: "Matthew Wilcox (Oracle)" Cc: Miaohe Lin Cc: Minchan Kim Cc: Naoya Horiguchi Cc: Oscar Salvador Cc: Peter Xu Cc: Ralph Campbell Cc: Shakeel Butt Cc: Wang Yugui Cc: Zi Yan Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit a8f4ea1d38ac6ed0ada7a876f39f29a24e3ff070 Author: Hugh Dickins Date: Tue Jun 15 18:23:45 2021 -0700 mm/thp: fix __split_huge_pmd_locked() on shmem migration entry [ Upstream commit 99fa8a48203d62b3743d866fc48ef6abaee682be ] Patch series "mm/thp: fix THP splitting unmap BUGs and related", v10. Here is v2 batch of long-standing THP bug fixes that I had not got around to sending before, but prompted now by Wang Yugui's report https://lore.kernel.org/linux-mm/20210412180659.B9E3.409509F4@e16-tech.com/ Wang Yugui has tested a rollup of these fixes applied to 5.10.39, and they have done no harm, but have *not* fixed that issue: something more is needed and I have no idea of what. This patch (of 7): Stressing huge tmpfs page migration racing hole punch often crashed on the VM_BUG_ON(!pmd_present) in pmdp_huge_clear_flush(), with DEBUG_VM=y kernel; or shortly afterwards, on a bad dereference in __split_huge_pmd_locked() when DEBUG_VM=n. They forgot to allow for pmd migration entries in the non-anonymous case. Full disclosure: those particular experiments were on a kernel with more relaxed mmap_lock and i_mmap_rwsem locking, and were not repeated on the vanilla kernel: it is conceivable that stricter locking happens to avoid those cases, or makes them less likely; but __split_huge_pmd_locked() already allowed for pmd migration entries when handling anonymous THPs, so this commit brings the shmem and file THP handling into line. And while there: use old_pmd rather than _pmd, as in the following blocks; and make it clearer to the eye that the !vma_is_anonymous() block is self-contained, making an early return after accounting for unmapping. Link: https://lkml.kernel.org/r/af88612-1473-2eaa-903-8d1a448b26@google.com Link: https://lkml.kernel.org/r/dd221a99-efb3-cd1d-6256-7e646af29314@google.com Fixes: e71769ae5260 ("mm: enable thp migration for shmem thp") Signed-off-by: Hugh Dickins Cc: Kirill A. Shutemov Cc: Yang Shi Cc: Wang Yugui Cc: "Matthew Wilcox (Oracle)" Cc: Naoya Horiguchi Cc: Alistair Popple Cc: Ralph Campbell Cc: Zi Yan Cc: Miaohe Lin Cc: Minchan Kim Cc: Jue Wang Cc: Peter Xu Cc: Jan Kara Cc: Shakeel Butt Cc: Oscar Salvador Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Note on stable backport: this commit made intervening cleanups in pmdp_huge_clear_flush() redundant: here it's rediffed to skip them. Signed-off-by: Hugh Dickins Signed-off-by: Greg Kroah-Hartman commit 32f954e961caf658bc7b5c83e7d213169595e15d Author: Xu Yu Date: Tue Jun 15 18:23:42 2021 -0700 mm, thp: use head page in __migration_entry_wait() commit ffc90cbb2970ab88b66ea51dd580469eede57b67 upstream. We notice that hung task happens in a corner but practical scenario when CONFIG_PREEMPT_NONE is enabled, as follows. Process 0 Process 1 Process 2..Inf split_huge_page_to_list unmap_page split_huge_pmd_address __migration_entry_wait(head) __migration_entry_wait(tail) remap_page (roll back) remove_migration_ptes rmap_walk_anon cond_resched Where __migration_entry_wait(tail) is occurred in kernel space, e.g., copy_to_user in fstat, which will immediately fault again without rescheduling, and thus occupy the cpu fully. When there are too many processes performing __migration_entry_wait on tail page, remap_page will never be done after cond_resched. This makes __migration_entry_wait operate on the compound head page, thus waits for remap_page to complete, whether the THP is split successfully or roll back. Note that put_and_wait_on_page_locked helps to drop the page reference acquired with get_page_unless_zero, as soon as the page is on the wait queue, before actually waiting. So splitting the THP is only prevented for a brief interval. Link: https://lkml.kernel.org/r/b9836c1dd522e903891760af9f0c86a2cce987eb.1623144009.git.xuyu@linux.alibaba.com Fixes: ba98828088ad ("thp: add option to setup migration entries during PMD split") Suggested-by: Hugh Dickins Signed-off-by: Gang Deng Signed-off-by: Xu Yu Acked-by: Kirill A. Shutemov Acked-by: Hugh Dickins Cc: Matthew Wilcox Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit bfd90b56d7f6cb225d6c31d2620cecc1a75d6142 Author: Miaohe Lin Date: Thu Feb 25 17:18:03 2021 -0800 mm/rmap: use page_not_mapped in try_to_unmap() [ Upstream commit b7e188ec98b1644ff70a6d3624ea16aadc39f5e0 ] page_mapcount_is_zero() calculates accurately how many mappings a hugepage has in order to check against 0 only. This is a waste of cpu time. We can do this via page_not_mapped() to save some possible atomic_read cycles. Remove the function page_mapcount_is_zero() as it's not used anymore and move page_not_mapped() above try_to_unmap() to avoid identifier undeclared compilation error. Link: https://lkml.kernel.org/r/20210130084904.35307-1-linmiaohe@huawei.com Signed-off-by: Miaohe Lin Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit ff81af8259bbfd3969f2c0dd1e36ccd0b404dc66 Author: Miaohe Lin Date: Thu Feb 25 17:17:56 2021 -0800 mm/rmap: remove unneeded semicolon in page_not_mapped() [ Upstream commit e0af87ff7afcde2660be44302836d2d5618185af ] Remove extra semicolon without any functional change intended. Link: https://lkml.kernel.org/r/20210127093425.39640-1-linmiaohe@huawei.com Signed-off-by: Miaohe Lin Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit a0ad7ea018e7390ceaa8ef3e01cde0301b9ff6bb Author: Alex Shi Date: Fri Dec 18 14:01:31 2020 -0800 mm: add VM_WARN_ON_ONCE_PAGE() macro [ Upstream commit a4055888629bc0467d12d912cd7c90acdf3d9b12 part ] Add VM_WARN_ON_ONCE_PAGE() macro. Link: https://lkml.kernel.org/r/1604283436-18880-3-git-send-email-alex.shi@linux.alibaba.com Signed-off-by: Alex Shi Acked-by: Michal Hocko Acked-by: Hugh Dickins Acked-by: Johannes Weiner Cc: Vladimir Davydov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Note on stable backport: original commit was titled mm/memcg: warning on !memcg after readahead page charged which included uses of this macro in mm/memcontrol.c: here omitted. Signed-off-by: Hugh Dickins Signed-off-by: Greg Kroah-Hartman commit 130a1d76ee0b206f96d885cefca5282fd2b7c44a Author: Thomas Gleixner Date: Fri Jun 18 16:18:25 2021 +0200 x86/fpu: Make init_fpstate correct with optimized XSAVE commit f9dfb5e390fab2df9f7944bb91e7705aba14cd26 upstream. The XSAVE init code initializes all enabled and supported components with XRSTOR(S) to init state. Then it XSAVEs the state of the components back into init_fpstate which is used in several places to fill in the init state of components. This works correctly with XSAVE, but not with XSAVEOPT and XSAVES because those use the init optimization and skip writing state of components which are in init state. So init_fpstate.xsave still contains all zeroes after this operation. There are two ways to solve that: 1) Use XSAVE unconditionally, but that requires to reshuffle the buffer when XSAVES is enabled because XSAVES uses compacted format. 2) Save the components which are known to have a non-zero init state by other means. Looking deeper, #2 is the right thing to do because all components the kernel supports have all-zeroes init state except the legacy features (FP, SSE). Those cannot be hard coded because the states are not identical on all CPUs, but they can be saved with FXSAVE which avoids all conditionals. Use FXSAVE to save the legacy FP/SSE components in init_fpstate along with a BUILD_BUG_ON() which reminds developers to validate that a newly added component has all zeroes init state. As a bonus remove the now unused copy_xregs_to_kernel_booting() crutch. The XSAVE and reshuffle method can still be implemented in the unlikely case that components are added which have a non-zero init state and no other means to save them. For now, FXSAVE is just simple and good enough. [ bp: Fix a typo or two in the text. ] Fixes: 6bad06b76892 ("x86, xsave: Use xsaveopt in context-switch path when supported") Signed-off-by: Thomas Gleixner Signed-off-by: Borislav Petkov Reviewed-by: Borislav Petkov Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20210618143444.587311343@linutronix.de Signed-off-by: Greg Kroah-Hartman commit 51d8011782ed751b5982914f18776be9eb9be062 Author: Thomas Gleixner Date: Fri Jun 18 16:18:24 2021 +0200 x86/fpu: Preserve supervisor states in sanitize_restored_user_xstate() commit 9301982c424a003c0095bf157154a85bf5322bd0 upstream. sanitize_restored_user_xstate() preserves the supervisor states only when the fx_only argument is zero, which allows unprivileged user space to put supervisor states back into init state. Preserve them unconditionally. [ bp: Fix a typo or two in the text. ] Fixes: 5d6b6a6f9b5c ("x86/fpu/xstate: Update sanitize_restored_xstate() for supervisor xstates") Signed-off-by: Thomas Gleixner Signed-off-by: Borislav Petkov Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20210618143444.438635017@linutronix.de Signed-off-by: Greg Kroah-Hartman commit 2b35a4eaaaae26f3f22bfb1a8b7ca1e994bae063 Author: Petr Mladek Date: Thu Jun 24 18:39:48 2021 -0700 kthread: prevent deadlock when kthread_mod_delayed_work() races with kthread_cancel_delayed_work_sync() commit 5fa54346caf67b4b1b10b1f390316ae466da4d53 upstream. The system might hang with the following backtrace: schedule+0x80/0x100 schedule_timeout+0x48/0x138 wait_for_common+0xa4/0x134 wait_for_completion+0x1c/0x2c kthread_flush_work+0x114/0x1cc kthread_cancel_work_sync.llvm.16514401384283632983+0xe8/0x144 kthread_cancel_delayed_work_sync+0x18/0x2c xxxx_pm_notify+0xb0/0xd8 blocking_notifier_call_chain_robust+0x80/0x194 pm_notifier_call_chain_robust+0x28/0x4c suspend_prepare+0x40/0x260 enter_state+0x80/0x3f4 pm_suspend+0x60/0xdc state_store+0x108/0x144 kobj_attr_store+0x38/0x88 sysfs_kf_write+0x64/0xc0 kernfs_fop_write_iter+0x108/0x1d0 vfs_write+0x2f4/0x368 ksys_write+0x7c/0xec It is caused by the following race between kthread_mod_delayed_work() and kthread_cancel_delayed_work_sync(): CPU0 CPU1 Context: Thread A Context: Thread B kthread_mod_delayed_work() spin_lock() __kthread_cancel_work() spin_unlock() del_timer_sync() kthread_cancel_delayed_work_sync() spin_lock() __kthread_cancel_work() spin_unlock() del_timer_sync() spin_lock() work->canceling++ spin_unlock spin_lock() queue_delayed_work() // dwork is put into the worker->delayed_work_list spin_unlock() kthread_flush_work() // flush_work is put at the tail of the dwork wait_for_completion() Context: IRQ kthread_delayed_work_timer_fn() spin_lock() list_del_init(&work->node); spin_unlock() BANG: flush_work is not longer linked and will never get proceed. The problem is that kthread_mod_delayed_work() checks work->canceling flag before canceling the timer. A simple solution is to (re)check work->canceling after __kthread_cancel_work(). But then it is not clear what should be returned when __kthread_cancel_work() removed the work from the queue (list) and it can't queue it again with the new @delay. The return value might be used for reference counting. The caller has to know whether a new work has been queued or an existing one was replaced. The proper solution is that kthread_mod_delayed_work() will remove the work from the queue (list) _only_ when work->canceling is not set. The flag must be checked after the timer is stopped and the remaining operations can be done under worker->lock. Note that kthread_mod_delayed_work() could remove the timer and then bail out. It is fine. The other canceling caller needs to cancel the timer as well. The important thing is that the queue (list) manipulation is done atomically under worker->lock. Link: https://lkml.kernel.org/r/20210610133051.15337-3-pmladek@suse.com Fixes: 9a6b06c8d9a220860468a ("kthread: allow to modify delayed kthread work") Signed-off-by: Petr Mladek Reported-by: Martin Liu Cc: Cc: Minchan Kim Cc: Nathan Chancellor Cc: Nick Desaulniers Cc: Oleg Nesterov Cc: Tejun Heo Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit bfe28af78a2021cfa93f26634a9bbd3a56577745 Author: Petr Mladek Date: Thu Jun 24 18:39:45 2021 -0700 kthread_worker: split code for canceling the delayed work timer commit 34b3d5344719d14fd2185b2d9459b3abcb8cf9d8 upstream. Patch series "kthread_worker: Fix race between kthread_mod_delayed_work() and kthread_cancel_delayed_work_sync()". This patchset fixes the race between kthread_mod_delayed_work() and kthread_cancel_delayed_work_sync() including proper return value handling. This patch (of 2): Simple code refactoring as a preparation step for fixing a race between kthread_mod_delayed_work() and kthread_cancel_delayed_work_sync(). It does not modify the existing behavior. Link: https://lkml.kernel.org/r/20210610133051.15337-2-pmladek@suse.com Signed-off-by: Petr Mladek Cc: Cc: Martin Liu Cc: Minchan Kim Cc: Nathan Chancellor Cc: Nick Desaulniers Cc: Oleg Nesterov Cc: Tejun Heo Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 02c303f3b9fbc5ad9c1f50f971304ef86b69f29b Author: Jeff Layton Date: Tue Jun 1 09:40:25 2021 -0400 ceph: must hold snap_rwsem when filling inode for async create commit 27171ae6a0fdc75571e5bf3d0961631a1e4fb765 upstream. ...and add a lockdep assertion for it to ceph_fill_inode(). Cc: stable@vger.kernel.org # v5.7+ Fixes: 9a8d03ca2e2c3 ("ceph: attempt to do async create when possible") Signed-off-by: Jeff Layton Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit de0af2651daac89dac3eab73bcd1bfd653ccd36f Author: Johan Hovold Date: Mon May 24 11:09:12 2021 +0200 i2c: robotfuzz-osif: fix control-request directions commit 4ca070ef0dd885616ef294d269a9bf8e3b258e1a upstream. The direction of the pipe argument must match the request-type direction bit or control requests may fail depending on the host-controller-driver implementation. Control transfers without a data stage are treated as OUT requests by the USB stack and should be using usb_sndctrlpipe(). Failing to do so will now trigger a warning. Fix the OSIFI2C_SET_BIT_RATE and OSIFI2C_STOP requests which erroneously used the osif_usb_read() helper and set the IN direction bit. Reported-by: syzbot+9d7dadd15b8819d73f41@syzkaller.appspotmail.com Fixes: 83e53a8f120f ("i2c: Add bus driver for for OSIF USB i2c device.") Cc: stable@vger.kernel.org # 3.14 Signed-off-by: Johan Hovold Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit dd8ed6c9bc2224c1ace5292d01089d3feb7ebbc3 Author: Nicholas Piggin Date: Thu Jun 24 08:29:04 2021 -0400 KVM: do not allow mapping valid but non-reference-counted pages commit f8be156be163a052a067306417cd0ff679068c97 upstream. It's possible to create a region which maps valid but non-refcounted pages (e.g., tail pages of non-compound higher order allocations). These host pages can then be returned by gfn_to_page, gfn_to_pfn, etc., family of APIs, which take a reference to the page, which takes it from 0 to 1. When the reference is dropped, this will free the page incorrectly. Fix this by only taking a reference on valid pages if it was non-zero, which indicates it is participating in normal refcounting (and can be released with put_page). This addresses CVE-2021-22543. Signed-off-by: Nicholas Piggin Tested-by: Paolo Bonzini Cc: stable@vger.kernel.org Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 5fd0c2cf7b11c23aebbbc512cfed08485f0a422a Author: Heiko Carstens Date: Fri Jun 18 16:58:47 2021 +0200 s390/stack: fix possible register corruption with stack switch helper commit 67147e96a332b56c7206238162771d82467f86c0 upstream. The CALL_ON_STACK macro is used to call a C function from inline assembly, and therefore must consider the C ABI, which says that only registers 6-13, and 15 are non-volatile (restored by the called function). The inline assembly incorrectly marks all registers used to pass parameters to the called function as read-only input operands, instead of operands that are read and written to. This might result in register corruption depending on usage, compiler, and compile options. Fix this by marking all operands used to pass parameters as read/write operands. To keep the code simple even register 6, if used, is marked as read-write operand. Fixes: ff340d2472ec ("s390: add stack switch helper") Cc: # 4.20 Reviewed-by: Vasily Gorbik Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit ab5bef9780386be0e54f98a40eeedb8295cd450b Author: Pavel Skripkin Date: Thu Jun 24 18:39:33 2021 -0700 nilfs2: fix memory leak in nilfs_sysfs_delete_device_group [ Upstream commit 8fd0c1b0647a6bda4067ee0cd61e8395954b6f28 ] My local syzbot instance hit memory leak in nilfs2. The problem was in missing kobject_put() in nilfs_sysfs_delete_device_group(). kobject_del() does not call kobject_cleanup() for passed kobject and it leads to leaking duped kobject name if kobject_put() was not called. Fail log: BUG: memory leak unreferenced object 0xffff8880596171e0 (size 8): comm "syz-executor379", pid 8381, jiffies 4294980258 (age 21.100s) hex dump (first 8 bytes): 6c 6f 6f 70 30 00 00 00 loop0... backtrace: kstrdup+0x36/0x70 mm/util.c:60 kstrdup_const+0x53/0x80 mm/util.c:83 kvasprintf_const+0x108/0x190 lib/kasprintf.c:48 kobject_set_name_vargs+0x56/0x150 lib/kobject.c:289 kobject_add_varg lib/kobject.c:384 [inline] kobject_init_and_add+0xc9/0x160 lib/kobject.c:473 nilfs_sysfs_create_device_group+0x150/0x800 fs/nilfs2/sysfs.c:999 init_nilfs+0xe26/0x12b0 fs/nilfs2/the_nilfs.c:637 Link: https://lkml.kernel.org/r/20210612140559.20022-1-paskripkin@gmail.com Fixes: da7141fb78db ("nilfs2: add /sys/fs/nilfs2/ group") Signed-off-by: Pavel Skripkin Acked-by: Ryusuke Konishi Cc: Michael L. Semon Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit ace31c91fd59a56a04c1cd56ba2852c66fe10cb5 Author: Christoph Hellwig Date: Thu Jun 17 13:55:04 2021 +0200 scsi: sd: Call sd_revalidate_disk() for ioctl(BLKRRPART) [ Upstream commit d1b7f92035c6fb42529ada531e2cbf3534544c82 ] While the disk state has nothing to do with partitions, BLKRRPART is used to force a full revalidate after things like a disk format for historical reasons. Restore that behavior. Link: https://lore.kernel.org/r/20210617115504.1732350-1-hch@lst.de Fixes: 471bd0af544b ("sd: use bdev_check_media_change") Reported-by: Xiang Chen Tested-by: Xiang Chen Signed-off-by: Christoph Hellwig Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit b9e6c20d4c9d337742d5944aec6cee1e2c277d8c Author: Gabriel Knezek Date: Mon Jun 21 15:28:59 2021 -0700 gpiolib: cdev: zero padding during conversion to gpioline_info_changed [ Upstream commit cb8f63b8cbf39845244f3ccae43bb7e63bd70543 ] When userspace requests a GPIO v1 line info changed event, lineinfo_watch_read() populates and returns the gpioline_info_changed structure. It contains 5 words of padding at the end which are not initialized before being returned to userspace. Zero the structure in gpio_v2_line_info_change_to_v1() before populating its contents. Fixes: aad955842d1c ("gpiolib: cdev: support GPIO_V2_GET_LINEINFO_IOCTL and GPIO_V2_GET_LINEINFO_WATCH_IOCTL") Signed-off-by: Gabriel Knezek Reviewed-by: Kent Gibson Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 0221a5a4db46bcfd797edd92036028db2879c06c Author: Heiner Kallweit Date: Sun Jun 6 15:55:55 2021 +0200 i2c: i801: Ensure that SMBHSTSTS_INUSE_STS is cleared when leaving i801_access [ Upstream commit 065b6211a87746e196b56759a70c7851418dd741 ] As explained in [0] currently we may leave SMBHSTSTS_INUSE_STS set, thus potentially breaking ACPI/BIOS usage of the SMBUS device. Seems patch [0] needs a little bit more of review effort, therefore I'd suggest to apply a part of it as quick win. Just clearing SMBHSTSTS_INUSE_STS when leaving i801_access() should fix the referenced issue and leaves more time for discussing a more sophisticated locking handling. [0] https://www.spinics.net/lists/linux-i2c/msg51558.html Fixes: 01590f361e94 ("i2c: i801: Instantiate SPD EEPROMs automatically") Suggested-by: Hector Martin Signed-off-by: Heiner Kallweit Reviewed-by: Hector Martin Reviewed-by: Jean Delvare Tested-by: Jean Delvare Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 018d03fcf77a7e6a37503397f871095f7fd909ec Author: Fabien Dessenne Date: Thu Jun 17 16:46:29 2021 +0200 pinctrl: stm32: fix the reported number of GPIO lines per bank [ Upstream commit 67e2996f72c71ebe4ac2fcbcf77e54479bb7aa11 ] Each GPIO bank supports a variable number of lines which is usually 16, but is less in some cases : this is specified by the last argument of the "gpio-ranges" bank node property. Report to the framework, the actual number of lines, so the libgpiod gpioinfo command lists the actually existing GPIO lines. Fixes: 1dc9d289154b ("pinctrl: stm32: add possibility to use gpio-ranges to declare bank range") Signed-off-by: Fabien Dessenne Link: https://lore.kernel.org/r/20210617144629.2557693-1-fabien.dessenne@foss.st.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit df654cd3d3001917ba18c0e5445a9ab8e9240f1e Author: Kan Liang Date: Mon Apr 12 07:30:43 2021 -0700 perf/x86: Track pmu in per-CPU cpu_hw_events [ Upstream commit 61e76d53c39bb768ad264d379837cfc56b9e35b4 ] Some platforms, e.g. Alder Lake, have hybrid architecture. In the same package, there may be more than one type of CPU. The PMU capabilities are different among different types of CPU. Perf will register a dedicated PMU for each type of CPU. Add a 'pmu' variable in the struct cpu_hw_events to track the dedicated PMU of the current CPU. Current x86_get_pmu() use the global 'pmu', which will be broken on a hybrid platform. Modify it to apply the 'pmu' of the specific CPU. Initialize the per-CPU 'pmu' variable with the global 'pmu'. There is nothing changed for the non-hybrid platforms. The is_x86_event() will be updated in the later patch ("perf/x86: Register hybrid PMUs") for hybrid platforms. For the non-hybrid platforms, nothing is changed here. Suggested-by: Peter Zijlstra (Intel) Signed-off-by: Kan Liang Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/1618237865-33448-4-git-send-email-kan.liang@linux.intel.com Signed-off-by: Sasha Levin commit f9e73b2967f6082376183d2850d30d9497cdbd62 Author: Esben Haabendal Date: Fri Jun 18 12:52:38 2021 +0200 net: ll_temac: Avoid ndo_start_xmit returning NETDEV_TX_BUSY [ Upstream commit f6396341194234e9b01cd7538bc2c6ac4501ab14 ] As documented in Documentation/networking/driver.rst, the ndo_start_xmit method must not return NETDEV_TX_BUSY under any normal circumstances, and as recommended, we simply stop the tx queue in advance, when there is a risk that the next xmit would cause a NETDEV_TX_BUSY return. Signed-off-by: Esben Haabendal Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 1c9cf96f5652ca3120190a991a04bf74cf5897e0 Author: Esben Haabendal Date: Fri Jun 18 12:52:28 2021 +0200 net: ll_temac: Add memory-barriers for TX BD access [ Upstream commit 28d9fab458b16bcd83f9dd07ede3d585c3e1a69e ] Add a couple of memory-barriers to ensure correct ordering of read/write access to TX BDs. In xmit_done, we should ensure that reading the additional BD fields are only done after STS_CTRL_APP0_CMPLT bit is set. When xmit_done marks the BD as free by setting APP0=0, we need to ensure that the other BD fields are reset first, so we avoid racing with the xmit path, which writes to the same fields. Finally, making sure to read APP0 of next BD after the current BD, ensures that we see all available buffers. Signed-off-by: Esben Haabendal Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit bafb6cdd4f7030621ed567d3de7f7e06da85eca5 Author: Mikel Rychliski Date: Fri Jun 11 17:48:23 2021 -0400 PCI: Add AMD RS690 quirk to enable 64-bit DMA [ Upstream commit cacf994a91d3a55c0c2f853d6429cd7b86113915 ] Although the AMD RS690 chipset has 64-bit DMA support, BIOS implementations sometimes fail to configure the memory limit registers correctly. The Acer F690GVM mainboard uses this chipset and a Marvell 88E8056 NIC. The sky2 driver programs the NIC to use 64-bit DMA, which will not work: sky2 0000:02:00.0: error interrupt status=0x8 sky2 0000:02:00.0 eth0: tx timeout sky2 0000:02:00.0 eth0: transmit ring 0 .. 22 report=0 done=0 Other drivers required by this mainboard either don't support 64-bit DMA, or have it disabled using driver specific quirks. For example, the ahci driver has quirks to enable or disable 64-bit DMA depending on the BIOS version (see ahci_sb600_enable_64bit() in ahci.c). This ahci quirk matches against the SB600 SATA controller, but the real issue is almost certainly with the RS690 PCI host that it was commonly attached to. To avoid this issue in all drivers with 64-bit DMA support, fix the configuration of the PCI host. If the kernel is aware of physical memory above 4GB, but the BIOS never configured the PCI host with this information, update the registers with our values. [bhelgaas: drop PCI_DEVICE_ID_ATI_RS690 definition] Link: https://lore.kernel.org/r/20210611214823.4898-1-mikel@mikelr.com Signed-off-by: Mikel Rychliski Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit d91c50e6a67800bee69f681ee78c3b767e9a0c2e Author: Peter Zijlstra Date: Wed Jun 16 23:41:26 2021 +0800 recordmcount: Correct st_shndx handling [ Upstream commit fb780761e7bd9f2e94f5b9a296ead6b35b944206 ] One should only use st_shndx when >SHN_UNDEF and = SHN_LORESERVE && st_shndx != SHN_XINDEX. Link: https://lore.kernel.org/lkml/20210607023839.26387-1-mark-pk.tsai@mediatek.com/ Link: https://lkml.kernel.org/r/20210616154126.2794-1-mark-pk.tsai@mediatek.com Reported-by: Mark-PK Tsai Tested-by: Mark-PK Tsai Signed-off-by: Peter Zijlstra (Intel) [handle endianness of sym->st_shndx] Signed-off-by: Mark-PK Tsai Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit fb71d81ccd69c3d607c44a8562f7abf606ae74e8 Author: Johannes Berg Date: Fri Jun 18 13:41:45 2021 +0300 mac80211: handle various extensible elements correctly [ Upstream commit 652e8363bbc7d149fa194a5cbf30b1001c0274b0 ] Various elements are parsed with a requirement to have an exact size, when really we should only check that they have the minimum size that we need. Check only that and therefore ignore any additional data that they might carry. Signed-off-by: Johannes Berg Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/iwlwifi.20210618133832.cd101f8040a4.Iadf0e9b37b100c6c6e79c7b298cc657c2be9151a@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 676a7cb1a96bfa8e8cb38a9fcdd69f3d91a0abda Author: Johannes Berg Date: Fri Jun 18 13:41:49 2021 +0300 mac80211: reset profile_periodicity/ema_ap [ Upstream commit bbc6f03ff26e7b71d6135a7b78ce40e7dee3d86a ] Apparently we never clear these values, so they'll remain set since the setting of them is conditional. Clear the values in the relevant other cases. Signed-off-by: Johannes Berg Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/iwlwifi.20210618133832.316e32d136a9.I2a12e51814258e1e1b526103894f4b9f19a91c8d@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit ca0e1fefbb534cc86296d9e5d116b0bf49084112 Author: Kees Cook Date: Thu Jun 17 10:09:53 2021 -0700 net: qed: Fix memcpy() overflow of qed_dcbx_params() [ Upstream commit 1c200f832e14420fa770193f9871f4ce2df00d07 ] The source (&dcbx_info->operational.params) and dest (&p_hwfn->p_dcbx_info->set.config.params) are both struct qed_dcbx_params (560 bytes), not struct qed_dcbx_admin_params (564 bytes), which is used as the memcpy() size. However it seems that struct qed_dcbx_operational_params (dcbx_info->operational)'s layout matches struct qed_dcbx_admin_params (p_hwfn->p_dcbx_info->set.config)'s 4 byte difference (3 padding, 1 byte for "valid"). On the assumption that the size is wrong (rather than the source structure type), adjust the memcpy() size argument to be 4 bytes smaller and add a BUILD_BUG_ON() to validate any changes to the structure sizes. Signed-off-by: Kees Cook Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4658a8d3079137d8d407892bdc95b390a419c261 Author: Fuad Tabba Date: Tue Jun 15 16:04:43 2021 +0100 KVM: selftests: Fix kvm_check_cap() assertion [ Upstream commit d8ac05ea13d789d5491a5920d70a05659015441d ] KVM_CHECK_EXTENSION ioctl can return any negative value on error, and not necessarily -1. Change the assertion to reflect that. Signed-off-by: Fuad Tabba Message-Id: <20210615150443.1183365-1-tabba@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit e83e3c5d85a70f9f6b52ede2aa9ed55b57879656 Author: Kees Cook Date: Wed Jun 16 12:53:59 2021 -0700 r8169: Avoid memcpy() over-reading of ETH_SS_STATS [ Upstream commit da5ac772cfe2a03058b0accfac03fad60c46c24d ] In preparation for FORTIFY_SOURCE performing compile-time and run-time field bounds checking for memcpy(), memmove(), and memset(), avoid intentionally reading across neighboring array fields. The memcpy() is copying the entire structure, not just the first array. Adjust the source argument so the compiler can do appropriate bounds checking. Signed-off-by: Kees Cook Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 992b105abf57d49d4b695318dd50fae19cd36a5c Author: Kees Cook Date: Wed Jun 16 12:53:33 2021 -0700 sh_eth: Avoid memcpy() over-reading of ETH_SS_STATS [ Upstream commit 224004fbb033600715dbd626bceec10bfd9c58bc ] In preparation for FORTIFY_SOURCE performing compile-time and run-time field bounds checking for memcpy(), memmove(), and memset(), avoid intentionally reading across neighboring array fields. The memcpy() is copying the entire structure, not just the first array. Adjust the source argument so the compiler can do appropriate bounds checking. Signed-off-by: Kees Cook Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit a10856ea6066872a01a59007fa108026ef58c24d Author: Kees Cook Date: Wed Jun 16 12:53:03 2021 -0700 r8152: Avoid memcpy() over-reading of ETH_SS_STATS [ Upstream commit 99718abdc00e86e4f286dd836408e2834886c16e ] In preparation for FORTIFY_SOURCE performing compile-time and run-time field bounds checking for memcpy(), memmove(), and memset(), avoid intentionally reading across neighboring array fields. The memcpy() is copying the entire structure, not just the first array. Adjust the source argument so the compiler can do appropriate bounds checking. Signed-off-by: Kees Cook Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 196b22ef6cd1cdd87a85811d27ec8936fd71f346 Author: Eric Dumazet Date: Wed Jun 16 06:42:02 2021 -0700 net/packet: annotate accesses to po->ifindex [ Upstream commit e032f7c9c7cefffcfb79b9fc16c53011d2d9d11f ] Like prior patch, we need to annotate lockless accesses to po->ifindex For instance, packet_getname() is reading po->ifindex (twice) while another thread is able to change po->ifindex. KCSAN reported: BUG: KCSAN: data-race in packet_do_bind / packet_getname write to 0xffff888143ce3cbc of 4 bytes by task 25573 on cpu 1: packet_do_bind+0x420/0x7e0 net/packet/af_packet.c:3191 packet_bind+0xc3/0xd0 net/packet/af_packet.c:3255 __sys_bind+0x200/0x290 net/socket.c:1637 __do_sys_bind net/socket.c:1648 [inline] __se_sys_bind net/socket.c:1646 [inline] __x64_sys_bind+0x3d/0x50 net/socket.c:1646 do_syscall_64+0x4a/0x90 arch/x86/entry/common.c:47 entry_SYSCALL_64_after_hwframe+0x44/0xae read to 0xffff888143ce3cbc of 4 bytes by task 25578 on cpu 0: packet_getname+0x5b/0x1a0 net/packet/af_packet.c:3525 __sys_getsockname+0x10e/0x1a0 net/socket.c:1887 __do_sys_getsockname net/socket.c:1902 [inline] __se_sys_getsockname net/socket.c:1899 [inline] __x64_sys_getsockname+0x3e/0x50 net/socket.c:1899 do_syscall_64+0x4a/0x90 arch/x86/entry/common.c:47 entry_SYSCALL_64_after_hwframe+0x44/0xae value changed: 0x00000000 -> 0x00000001 Reported by Kernel Concurrency Sanitizer on: CPU: 0 PID: 25578 Comm: syz-executor.5 Not tainted 5.13.0-rc6-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Signed-off-by: Eric Dumazet Reported-by: syzbot Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit da8b3aeff4ad7f8f777dd4b4d1929150849c9f46 Author: Eric Dumazet Date: Wed Jun 16 06:42:01 2021 -0700 net/packet: annotate accesses to po->bind [ Upstream commit c7d2ef5dd4b03ed0ee1d13bc0c55f9cf62d49bd6 ] tpacket_snd(), packet_snd(), packet_getname() and packet_seq_show() can read po->num without holding a lock. This means other threads can change po->num at the same time. KCSAN complained about this known fact [1] Add READ_ONCE()/WRITE_ONCE() to address the issue. [1] BUG: KCSAN: data-race in packet_do_bind / packet_sendmsg write to 0xffff888131a0dcc0 of 2 bytes by task 24714 on cpu 0: packet_do_bind+0x3ab/0x7e0 net/packet/af_packet.c:3181 packet_bind+0xc3/0xd0 net/packet/af_packet.c:3255 __sys_bind+0x200/0x290 net/socket.c:1637 __do_sys_bind net/socket.c:1648 [inline] __se_sys_bind net/socket.c:1646 [inline] __x64_sys_bind+0x3d/0x50 net/socket.c:1646 do_syscall_64+0x4a/0x90 arch/x86/entry/common.c:47 entry_SYSCALL_64_after_hwframe+0x44/0xae read to 0xffff888131a0dcc0 of 2 bytes by task 24719 on cpu 1: packet_snd net/packet/af_packet.c:2899 [inline] packet_sendmsg+0x317/0x3570 net/packet/af_packet.c:3040 sock_sendmsg_nosec net/socket.c:654 [inline] sock_sendmsg net/socket.c:674 [inline] ____sys_sendmsg+0x360/0x4d0 net/socket.c:2350 ___sys_sendmsg net/socket.c:2404 [inline] __sys_sendmsg+0x1ed/0x270 net/socket.c:2433 __do_sys_sendmsg net/socket.c:2442 [inline] __se_sys_sendmsg net/socket.c:2440 [inline] __x64_sys_sendmsg+0x42/0x50 net/socket.c:2440 do_syscall_64+0x4a/0x90 arch/x86/entry/common.c:47 entry_SYSCALL_64_after_hwframe+0x44/0xae value changed: 0x0000 -> 0x1200 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 24719 Comm: syz-executor.5 Not tainted 5.13.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Signed-off-by: Eric Dumazet Reported-by: syzbot Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 18ed1789bbce54f34367877344e35d9bb877f8f4 Author: Pavel Skripkin Date: Sat Jun 12 17:51:22 2021 +0300 net: caif: fix memory leak in ldisc_open [ Upstream commit 58af3d3d54e87bfc1f936e16c04ade3369d34011 ] Syzbot reported memory leak in tty_init_dev(). The problem was in unputted tty in ldisc_open() static int ldisc_open(struct tty_struct *tty) { ... ser->tty = tty_kref_get(tty); ... result = register_netdevice(dev); if (result) { rtnl_unlock(); free_netdev(dev); return -ENODEV; } ... } Ser pointer is netdev private_data, so after free_netdev() this pointer goes away with unputted tty reference. So, fix it by adding tty_kref_put() before freeing netdev. Reported-and-tested-by: syzbot+f303e045423e617d2cad@syzkaller.appspotmail.com Signed-off-by: Pavel Skripkin Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit edcd7594ada9204744f7208176c690ba36d13b07 Author: Khem Raj Date: Sun Jun 6 15:09:40 2021 -0700 riscv32: Use medany C model for modules [ Upstream commit 5d2388dbf84adebeb6d9742164be8d32728e4269 ] When CONFIG_CMODEL_MEDLOW is used it ends up generating riscv_hi20_rela relocations in modules which are not resolved during runtime and following errors would be seen [ 4.802714] virtio_input: target 00000000c1539090 can not be addressed by the 32-bit offset from PC = 39148b7b [ 4.854800] virtio_input: target 00000000c1539090 can not be addressed by the 32-bit offset from PC = 9774456d Signed-off-by: Khem Raj Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin commit 47c07f919fabb6fc8b3c27ad985f24648f5fd6df Author: Praneeth Bajjuri Date: Wed Jun 9 19:43:42 2021 -0500 net: phy: dp83867: perform soft reset and retain established link [ Upstream commit da9ef50f545f86ffe6ff786174d26500c4db737a ] Current logic is performing hard reset and causing the programmed registers to be wiped out. as per datasheet: https://www.ti.com/lit/ds/symlink/dp83867cr.pdf 8.6.26 Control Register (CTRL) do SW_RESTART to perform a reset not including the registers, If performed when link is already present, it will drop the link and trigger re-auto negotiation. Signed-off-by: Praneeth Bajjuri Signed-off-by: Geet Modi Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f57132a887ea4be3d7d813b5003d56716ba33448 Author: Eric Dumazet Date: Thu Jun 10 09:00:12 2021 -0700 net/packet: annotate data race in packet_sendmsg() [ Upstream commit d1b5bee4c8be01585033be9b3a8878789285285f ] There is a known race in packet_sendmsg(), addressed in commit 32d3182cd2cd ("net/packet: fix race in tpacket_snd()") Now we have data_race(), we can use it to avoid a future KCSAN warning, as syzbot loves stressing af_packet sockets :) Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 9707960ecfdc27d1d57c83ab47472f79f3a4c3f8 Author: Eric Dumazet Date: Thu Jun 10 07:44:11 2021 -0700 inet: annotate date races around sk->sk_txhash [ Upstream commit b71eaed8c04f72a919a9c44e83e4ee254e69e7f3 ] UDP sendmsg() path can be lockless, it is possible for another thread to re-connect an change sk->sk_txhash under us. There is no serious impact, but we can use READ_ONCE()/WRITE_ONCE() pair to document the race. BUG: KCSAN: data-race in __ip4_datagram_connect / skb_set_owner_w write to 0xffff88813397920c of 4 bytes by task 30997 on cpu 1: sk_set_txhash include/net/sock.h:1937 [inline] __ip4_datagram_connect+0x69e/0x710 net/ipv4/datagram.c:75 __ip6_datagram_connect+0x551/0x840 net/ipv6/datagram.c:189 ip6_datagram_connect+0x2a/0x40 net/ipv6/datagram.c:272 inet_dgram_connect+0xfd/0x180 net/ipv4/af_inet.c:580 __sys_connect_file net/socket.c:1837 [inline] __sys_connect+0x245/0x280 net/socket.c:1854 __do_sys_connect net/socket.c:1864 [inline] __se_sys_connect net/socket.c:1861 [inline] __x64_sys_connect+0x3d/0x50 net/socket.c:1861 do_syscall_64+0x4a/0x90 arch/x86/entry/common.c:47 entry_SYSCALL_64_after_hwframe+0x44/0xae read to 0xffff88813397920c of 4 bytes by task 31039 on cpu 0: skb_set_hash_from_sk include/net/sock.h:2211 [inline] skb_set_owner_w+0x118/0x220 net/core/sock.c:2101 sock_alloc_send_pskb+0x452/0x4e0 net/core/sock.c:2359 sock_alloc_send_skb+0x2d/0x40 net/core/sock.c:2373 __ip6_append_data+0x1743/0x21a0 net/ipv6/ip6_output.c:1621 ip6_make_skb+0x258/0x420 net/ipv6/ip6_output.c:1983 udpv6_sendmsg+0x160a/0x16b0 net/ipv6/udp.c:1527 inet6_sendmsg+0x5f/0x80 net/ipv6/af_inet6.c:642 sock_sendmsg_nosec net/socket.c:654 [inline] sock_sendmsg net/socket.c:674 [inline] ____sys_sendmsg+0x360/0x4d0 net/socket.c:2350 ___sys_sendmsg net/socket.c:2404 [inline] __sys_sendmmsg+0x315/0x4b0 net/socket.c:2490 __do_sys_sendmmsg net/socket.c:2519 [inline] __se_sys_sendmmsg net/socket.c:2516 [inline] __x64_sys_sendmmsg+0x53/0x60 net/socket.c:2516 do_syscall_64+0x4a/0x90 arch/x86/entry/common.c:47 entry_SYSCALL_64_after_hwframe+0x44/0xae value changed: 0xbca3c43d -> 0xfdb309e0 Reported by Kernel Concurrency Sanitizer on: CPU: 0 PID: 31039 Comm: syz-executor.2 Not tainted 5.13.0-rc3-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Signed-off-by: Eric Dumazet Reported-by: syzbot Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7293f63b7b620e888b6ab08127e91c579b825fb1 Author: Eric Dumazet Date: Thu Jun 10 07:27:37 2021 -0700 net: annotate data race in sock_error() [ Upstream commit f13ef10059ccf5f4ed201cd050176df62ec25bb8 ] sock_error() is known to be racy. The code avoids an atomic operation is sk_err is zero, and this field could be changed under us, this is fine. Sysbot reported: BUG: KCSAN: data-race in sock_alloc_send_pskb / unix_release_sock write to 0xffff888131855630 of 4 bytes by task 9365 on cpu 1: unix_release_sock+0x2e9/0x6e0 net/unix/af_unix.c:550 unix_release+0x2f/0x50 net/unix/af_unix.c:859 __sock_release net/socket.c:599 [inline] sock_close+0x6c/0x150 net/socket.c:1258 __fput+0x25b/0x4e0 fs/file_table.c:280 ____fput+0x11/0x20 fs/file_table.c:313 task_work_run+0xae/0x130 kernel/task_work.c:164 tracehook_notify_resume include/linux/tracehook.h:189 [inline] exit_to_user_mode_loop kernel/entry/common.c:174 [inline] exit_to_user_mode_prepare+0x156/0x190 kernel/entry/common.c:208 __syscall_exit_to_user_mode_work kernel/entry/common.c:290 [inline] syscall_exit_to_user_mode+0x20/0x40 kernel/entry/common.c:301 do_syscall_64+0x56/0x90 arch/x86/entry/common.c:57 entry_SYSCALL_64_after_hwframe+0x44/0xae read to 0xffff888131855630 of 4 bytes by task 9385 on cpu 0: sock_error include/net/sock.h:2269 [inline] sock_alloc_send_pskb+0xe4/0x4e0 net/core/sock.c:2336 unix_dgram_sendmsg+0x478/0x1610 net/unix/af_unix.c:1671 unix_seqpacket_sendmsg+0xc2/0x100 net/unix/af_unix.c:2055 sock_sendmsg_nosec net/socket.c:654 [inline] sock_sendmsg net/socket.c:674 [inline] ____sys_sendmsg+0x360/0x4d0 net/socket.c:2350 __sys_sendmsg_sock+0x25/0x30 net/socket.c:2416 io_sendmsg fs/io_uring.c:4367 [inline] io_issue_sqe+0x231a/0x6750 fs/io_uring.c:6135 __io_queue_sqe+0xe9/0x360 fs/io_uring.c:6414 __io_req_task_submit fs/io_uring.c:2039 [inline] io_async_task_func+0x312/0x590 fs/io_uring.c:5074 __tctx_task_work fs/io_uring.c:1910 [inline] tctx_task_work+0x1d4/0x3d0 fs/io_uring.c:1924 task_work_run+0xae/0x130 kernel/task_work.c:164 tracehook_notify_signal include/linux/tracehook.h:212 [inline] handle_signal_work kernel/entry/common.c:145 [inline] exit_to_user_mode_loop kernel/entry/common.c:171 [inline] exit_to_user_mode_prepare+0xf8/0x190 kernel/entry/common.c:208 __syscall_exit_to_user_mode_work kernel/entry/common.c:290 [inline] syscall_exit_to_user_mode+0x20/0x40 kernel/entry/common.c:301 do_syscall_64+0x56/0x90 arch/x86/entry/common.c:57 entry_SYSCALL_64_after_hwframe+0x44/0xae value changed: 0x00000000 -> 0x00000068 Reported by Kernel Concurrency Sanitizer on: CPU: 0 PID: 9385 Comm: syz-executor.3 Not tainted 5.13.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Signed-off-by: Eric Dumazet Reported-by: syzbot Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 61b132f67c0d69ff367a8b52f42f0ececffc89e4 Author: Zheng Yongjun Date: Thu Jun 10 09:41:36 2021 +0800 ping: Check return value of function 'ping_queue_rcv_skb' [ Upstream commit 9d44fa3e50cc91691896934d106c86e4027e61ca ] Function 'ping_queue_rcv_skb' not always return success, which will also return fail. If not check the wrong return value of it, lead to function `ping_rcv` return success. Signed-off-by: Zheng Yongjun Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 08c389de6d53ce6055573e4edd4e2010d1789f05 Author: Eric Dumazet Date: Wed Jun 9 00:59:45 2021 -0700 inet: annotate data race in inet_send_prepare() and inet_dgram_connect() [ Upstream commit dcd01eeac14486b56a790f5cce9b823440ba5b34 ] Both functions are known to be racy when reading inet_num as we do not want to grab locks for the common case the socket has been bound already. The race is resolved in inet_autobind() by reading again inet_num under the socket lock. syzbot reported: BUG: KCSAN: data-race in inet_send_prepare / udp_lib_get_port write to 0xffff88812cba150e of 2 bytes by task 24135 on cpu 0: udp_lib_get_port+0x4b2/0xe20 net/ipv4/udp.c:308 udp_v6_get_port+0x5e/0x70 net/ipv6/udp.c:89 inet_autobind net/ipv4/af_inet.c:183 [inline] inet_send_prepare+0xd0/0x210 net/ipv4/af_inet.c:807 inet6_sendmsg+0x29/0x80 net/ipv6/af_inet6.c:639 sock_sendmsg_nosec net/socket.c:654 [inline] sock_sendmsg net/socket.c:674 [inline] ____sys_sendmsg+0x360/0x4d0 net/socket.c:2350 ___sys_sendmsg net/socket.c:2404 [inline] __sys_sendmmsg+0x315/0x4b0 net/socket.c:2490 __do_sys_sendmmsg net/socket.c:2519 [inline] __se_sys_sendmmsg net/socket.c:2516 [inline] __x64_sys_sendmmsg+0x53/0x60 net/socket.c:2516 do_syscall_64+0x4a/0x90 arch/x86/entry/common.c:47 entry_SYSCALL_64_after_hwframe+0x44/0xae read to 0xffff88812cba150e of 2 bytes by task 24132 on cpu 1: inet_send_prepare+0x21/0x210 net/ipv4/af_inet.c:806 inet6_sendmsg+0x29/0x80 net/ipv6/af_inet6.c:639 sock_sendmsg_nosec net/socket.c:654 [inline] sock_sendmsg net/socket.c:674 [inline] ____sys_sendmsg+0x360/0x4d0 net/socket.c:2350 ___sys_sendmsg net/socket.c:2404 [inline] __sys_sendmmsg+0x315/0x4b0 net/socket.c:2490 __do_sys_sendmmsg net/socket.c:2519 [inline] __se_sys_sendmmsg net/socket.c:2516 [inline] __x64_sys_sendmmsg+0x53/0x60 net/socket.c:2516 do_syscall_64+0x4a/0x90 arch/x86/entry/common.c:47 entry_SYSCALL_64_after_hwframe+0x44/0xae value changed: 0x0000 -> 0x9db4 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 24132 Comm: syz-executor.2 Not tainted 5.13.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Signed-off-by: Eric Dumazet Reported-by: syzbot Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit c2311fd6de7815187fc31fe79fe6c969bc8a0b4c Author: Austin Kim Date: Wed Jun 9 03:34:25 2021 +0100 net: ethtool: clear heap allocations for ethtool function [ Upstream commit 80ec82e3d2c1fab42eeb730aaa7985494a963d3f ] Several ethtool functions leave heap uncleared (potentially) by drivers. This will leave the unused portion of heap unchanged and might copy the full contents back to userspace. Signed-off-by: Austin Kim Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit c2813d1966ba45ec205e57e94c53cd07805be2e1 Author: Johannes Berg Date: Wed Jun 9 16:13:06 2021 +0200 mac80211: drop multicast fragments [ Upstream commit a9799541ca34652d9996e45f80e8e03144c12949 ] These are not permitted by the spec, just drop them. Link: https://lore.kernel.org/r/20210609161305.23def022b750.Ibd6dd3cdce573dae262fcdc47f8ac52b883a9c50@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit fedc4d4f548ce538d18ec87a63d5a618dc730117 Author: Zheng Yongjun Date: Tue Jun 8 09:53:15 2021 +0800 net: ipv4: Remove unneed BUG() function [ Upstream commit 5ac6b198d7e312bd10ebe7d58c64690dc59cc49a ] When 'nla_parse_nested_deprecated' failed, it's no need to BUG() here, return -EINVAL is ok. Signed-off-by: Zheng Yongjun Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 93c2aac13b0856fa7e8bf7bd59476650963292fa Author: Guillaume Ranquet Date: Thu May 13 21:26:42 2021 +0200 dmaengine: mediatek: use GFP_NOWAIT instead of GFP_ATOMIC in prep_dma [ Upstream commit 9041575348b21ade1fb74d790f1aac85d68198c7 ] As recommended by the doc in: Documentation/drivers-api/dmaengine/provider.rst Use GFP_NOWAIT to not deplete the emergency pool. Signed-off-by: Guillaume Ranquet Link: https://lore.kernel.org/r/20210513192642.29446-4-granquet@baylibre.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 0f48f927718252cde6ca55a67efcd9ba4ed6ca21 Author: Guillaume Ranquet Date: Thu May 13 21:26:41 2021 +0200 dmaengine: mediatek: do not issue a new desc if one is still current [ Upstream commit 2537b40b0a4f61d2c83900744fe89b09076be9c6 ] Avoid issuing a new desc if one is still being processed as this can lead to some desc never being marked as completed. Signed-off-by: Guillaume Ranquet Link: https://lore.kernel.org/r/20210513192642.29446-3-granquet@baylibre.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 63fa5b2d4b55ebf4d12e7b4d536ae3e63117cd1a Author: Guillaume Ranquet Date: Thu May 13 21:26:40 2021 +0200 dmaengine: mediatek: free the proper desc in desc_free handler [ Upstream commit 0a2ff58f9f8f95526ecb0ccd7517fefceb96f661 ] The desc_free handler assumed that the desc we want to free was always the current one associated with the channel. This is seldom the case and this is causing use after free crashes in multiple places (tx/rx/terminate...). BUG: KASAN: use-after-free in mtk_uart_apdma_rx_handler+0x120/0x304 Call trace: dump_backtrace+0x0/0x1b0 show_stack+0x24/0x34 dump_stack+0xe0/0x150 print_address_description+0x8c/0x55c __kasan_report+0x1b8/0x218 kasan_report+0x14/0x20 __asan_load4+0x98/0x9c mtk_uart_apdma_rx_handler+0x120/0x304 mtk_uart_apdma_irq_handler+0x50/0x80 __handle_irq_event_percpu+0xe0/0x210 handle_irq_event+0x8c/0x184 handle_fasteoi_irq+0x1d8/0x3ac __handle_domain_irq+0xb0/0x110 gic_handle_irq+0x50/0xb8 el0_irq_naked+0x60/0x6c Allocated by task 3541: __kasan_kmalloc+0xf0/0x1b0 kasan_kmalloc+0x10/0x1c kmem_cache_alloc_trace+0x90/0x2dc mtk_uart_apdma_prep_slave_sg+0x6c/0x1a0 mtk8250_dma_rx_complete+0x220/0x2e4 vchan_complete+0x290/0x340 tasklet_action_common+0x220/0x298 tasklet_action+0x28/0x34 __do_softirq+0x158/0x35c Freed by task 3541: __kasan_slab_free+0x154/0x224 kasan_slab_free+0x14/0x24 slab_free_freelist_hook+0xf8/0x15c kfree+0xb4/0x278 mtk_uart_apdma_desc_free+0x34/0x44 vchan_complete+0x1bc/0x340 tasklet_action_common+0x220/0x298 tasklet_action+0x28/0x34 __do_softirq+0x158/0x35c The buggy address belongs to the object at ffff000063606800 which belongs to the cache kmalloc-256 of size 256 The buggy address is located 176 bytes inside of 256-byte region [ffff000063606800, ffff000063606900) The buggy address belongs to the page: page:fffffe00016d8180 refcount:1 mapcount:0 mapping:ffff00000302f600 index:0x0 compound_mapcount: 0 flags: 0xffff00000010200(slab|head) raw: 0ffff00000010200 dead000000000100 dead000000000122 ffff00000302f600 raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Signed-off-by: Guillaume Ranquet Link: https://lore.kernel.org/r/20210513192642.29446-2-granquet@baylibre.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 78fa0f707d73c21621454ffd78cdfa1e2c7003c0 Author: Zou Wei Date: Mon May 31 14:36:03 2021 +0800 dmaengine: rcar-dmac: Fix PM reference leak in rcar_dmac_probe() [ Upstream commit dea8464ddf553803382efb753b6727dbf3931d06 ] pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to putting operation will result in reference leak here. Fix it by replacing it with pm_runtime_resume_and_get to keep usage counter balanced. Reported-by: Hulk Robot Signed-off-by: Zou Wei Reviewed-by: Laurent Pinchart Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/1622442963-54095-1-git-send-email-zou_wei@huawei.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 6a07cf36064afb14849d8e038fcca3538fe94bd4 Author: Du Cheng Date: Wed Apr 28 14:39:41 2021 +0800 cfg80211: call cfg80211_leave_ocb when switching away from OCB [ Upstream commit a64b6a25dd9f984ed05fade603a00e2eae787d2f ] If the userland switches back-and-forth between NL80211_IFTYPE_OCB and NL80211_IFTYPE_ADHOC via send_msg(NL80211_CMD_SET_INTERFACE), there is a chance where the cleanup cfg80211_leave_ocb() is not called. This leads to initialization of in-use memory (e.g. init u.ibss while in-use by u.ocb) due to a shared struct/union within ieee80211_sub_if_data: struct ieee80211_sub_if_data { ... union { struct ieee80211_if_ap ap; struct ieee80211_if_vlan vlan; struct ieee80211_if_managed mgd; struct ieee80211_if_ibss ibss; // <- shares address struct ieee80211_if_mesh mesh; struct ieee80211_if_ocb ocb; // <- shares address struct ieee80211_if_mntr mntr; struct ieee80211_if_nan nan; } u; ... } Therefore add handling of otype == NL80211_IFTYPE_OCB, during cfg80211_change_iface() to perform cleanup when leaving OCB mode. link to syzkaller bug: https://syzkaller.appspot.com/bug?id=0612dbfa595bf4b9b680ff7b4948257b8e3732d5 Reported-by: syzbot+105896fac213f26056f9@syzkaller.appspotmail.com Signed-off-by: Du Cheng Link: https://lore.kernel.org/r/20210428063941.105161-1-ducheng2@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit a9028333001f793b2724e8be42fce3336de2cf1c Author: Johannes Berg Date: Mon May 17 17:04:31 2021 +0200 mac80211_hwsim: drop pending frames on stop [ Upstream commit bd18de517923903a177508fc8813f44e717b1c00 ] Syzbot reports that we may be able to get into a situation where mac80211 has pending ACK frames on shutdown with hwsim. It appears that the reason for this is that syzbot uses the wmediumd hooks to intercept/injection frames, and may shut down hwsim, removing the radio(s), while frames are pending in the air simulation. Clean out the pending queue when the interface is stopped, after this the frames can't be reported back to mac80211 properly anyway. Reported-by: syzbot+a063bbf0b15737362592@syzkaller.appspotmail.com Link: https://lore.kernel.org/r/20210517170429.b0f85ab0eda1.Ie42a6ec6b940c971f3441286aeaaae2fe368e29a@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 8cfe765afd5a8d127770780f45fd971a28897484 Author: Johannes Berg Date: Mon May 17 16:47:17 2021 +0200 mac80211: remove warning in ieee80211_get_sband() [ Upstream commit 0ee4d55534f82a0624701d0bb9fc2304d4529086 ] Syzbot reports that it's possible to hit this from userspace, by trying to add a station before any other connection setup has been done. Instead of trying to catch this in some other way simply remove the warning, that will appropriately reject the call from userspace. Reported-by: syzbot+7716dbc401d9a437890d@syzkaller.appspotmail.com Link: https://lore.kernel.org/r/20210517164715.f537da276d17.Id05f40ec8761d6a8cc2df87f1aa09c651988a586@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit b671b98169821836f12d646c85aafd6968a331a3 Author: Laurent Pinchart Date: Thu May 20 18:24:20 2021 +0300 dmaengine: xilinx: dpdma: Limit descriptor IDs to 16 bits [ Upstream commit 9f007e7b6643799e2a6538a5fe04f51c371c6657 ] While the descriptor ID is stored in a 32-bit field in the hardware descriptor, only 16 bits are used by the hardware and are reported through the XILINX_DPDMA_CH_DESC_ID register. Failure to handle the wrap-around results in a descriptor ID mismatch after 65536 frames. Fix it. Signed-off-by: Laurent Pinchart Tested-by: Jianqiang Chen Reviewed-by: Jianqiang Chen Link: https://lore.kernel.org/r/20210520152420.23986-5-laurent.pinchart@ideasonboard.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 524f70b30ef811ca82ebf36fd148bf2796454314 Author: Laurent Pinchart Date: Thu May 20 18:24:17 2021 +0300 dmaengine: xilinx: dpdma: Add missing dependencies to Kconfig [ Upstream commit 32828b82fb875b06511918b139d3a3cd93d34262 ] The driver depends on both OF and IOMEM support, express those dependencies in Kconfig. This fixes a build failure on S390 reported by the 0day bot. Reported-by: kernel test robot Signed-off-by: Laurent Pinchart Tested-by: Jianqiang Chen Reviewed-by: Jianqiang Chen Link: https://lore.kernel.org/r/20210520152420.23986-2-laurent.pinchart@ideasonboard.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 13b245a7bd59359abb6e328254b7536265448b29 Author: Yu Kuai Date: Mon May 17 16:18:24 2021 +0800 dmaengine: stm32-mdma: fix PM reference leak in stm32_mdma_alloc_chan_resourc() [ Upstream commit 83eb4868d325b86e18509d0874e911497667cb54 ] pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to putting operation will result in reference leak here. Fix it by replacing it with pm_runtime_resume_and_get to keep usage counter balanced. Reported-by: Hulk Robot Signed-off-by: Yu Kuai Link: https://lore.kernel.org/r/20210517081826.1564698-2-yukuai3@huawei.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 86f3e72dcb721675216a8a6fa5a3d669ba79c6a0 Author: Yu Kuai Date: Mon May 17 16:18:26 2021 +0800 dmaengine: zynqmp_dma: Fix PM reference leak in zynqmp_dma_alloc_chan_resourc() [ Upstream commit 8982d48af36d2562c0f904736b0fc80efc9f2532 ] pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to putting operation will result in reference leak here. Fix it by replacing it with pm_runtime_resume_and_get to keep usage counter balanced. Reported-by: Hulk Robot Signed-off-by: Yu Kuai Link: https://lore.kernel.org/r/20210517081826.1564698-4-yukuai3@huawei.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 4df9ed0edb9f6f60afcf1fd70640cebc7eceb3c7 Author: Thomas Gleixner Date: Fri Jun 11 15:03:16 2021 +0200 perf/x86/intel/lbr: Zero the xstate buffer on allocation [ Upstream commit 7f049fbdd57f6ea71dc741d903c19c73b2f70950 ] XRSTORS requires a valid xstate buffer to work correctly. XSAVES does not guarantee to write a fully valid buffer according to the SDM: "XSAVES does not write to any parts of the XSAVE header other than the XSTATE_BV and XCOMP_BV fields." XRSTORS triggers a #GP: "If bytes 63:16 of the XSAVE header are not all zero." It's dubious at best how this can work at all when the buffer is not zeroed before use. Allocate the buffers with __GFP_ZERO to prevent XRSTORS failure. Fixes: ce711ea3cab9 ("perf/x86/intel/lbr: Support XSAVES/XRSTORS for LBR context switch") Signed-off-by: Thomas Gleixner Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/87wnr0wo2z.ffs@nanos.tec.linutronix.de Signed-off-by: Sasha Levin commit 56bc20e5fc64d55c194475692ee60893a3f452a5 Author: Like Xu Date: Fri Apr 30 13:22:47 2021 +0800 perf/x86/lbr: Remove cpuc->lbr_xsave allocation from atomic context [ Upstream commit 488e13a489e9707a7e81e1991fdd1f20c0f04689 ] If the kernel is compiled with the CONFIG_LOCKDEP option, the conditional might_sleep_if() deep in kmem_cache_alloc() will generate the following trace, and potentially cause a deadlock when another LBR event is added: [] BUG: sleeping function called from invalid context at include/linux/sched/mm.h:196 [] Call Trace: [] kmem_cache_alloc+0x36/0x250 [] intel_pmu_lbr_add+0x152/0x170 [] x86_pmu_add+0x83/0xd0 Make it symmetric with the release_lbr_buffers() call and mirror the existing DS buffers. Fixes: c085fb8774 ("perf/x86/intel/lbr: Support XSAVES for arch LBR read") Signed-off-by: Like Xu [peterz: simplified] Signed-off-by: Peter Zijlstra (Intel) Tested-by: Kan Liang Link: https://lkml.kernel.org/r/20210430052247.3079672-2-like.xu@linux.intel.com Signed-off-by: Sasha Levin commit ca2acbd5483ff03a1c1ea0268d7a4acf0b3a13ee Author: Peter Zijlstra Date: Mon Jun 21 13:12:38 2021 +0200 locking/lockdep: Improve noinstr vs errors [ Upstream commit 49faa77759b211fff344898edc23bb780707fff5 ] Better handle the failure paths. vmlinux.o: warning: objtool: debug_locks_off()+0x23: call to console_verbose() leaves .noinstr.text section vmlinux.o: warning: objtool: debug_locks_off()+0x19: call to __kasan_check_write() leaves .noinstr.text section debug_locks_off+0x19/0x40: instrument_atomic_write at include/linux/instrumented.h:86 (inlined by) __debug_locks_off at include/linux/debug_locks.h:17 (inlined by) debug_locks_off at lib/debug_locks.c:41 Fixes: 6eebad1ad303 ("lockdep: __always_inline more for noinstr") Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20210621120120.784404944@infradead.org Signed-off-by: Sasha Levin commit 59aa5c91f86336b9bfdb10c1ab23fb08bb291e53 Author: Peter Zijlstra Date: Mon Jun 21 13:12:36 2021 +0200 x86/xen: Fix noinstr fail in exc_xen_unknown_trap() [ Upstream commit 4c9c26f1e67648f41f28f8c997c5c9467a3dbbe4 ] Fix: vmlinux.o: warning: objtool: exc_xen_unknown_trap()+0x7: call to printk() leaves .noinstr.text section Fixes: 2e92493637a0 ("x86/xen: avoid warning in Xen pv guest with CONFIG_AMD_MEM_ENCRYPT enabled") Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20210621120120.606560778@infradead.org Signed-off-by: Sasha Levin commit cb83c99cf675f3d48a343f8a17d0b953996660cb Author: Peter Zijlstra Date: Mon Jun 21 13:12:34 2021 +0200 x86/entry: Fix noinstr fail in __do_fast_syscall_32() [ Upstream commit 240001d4e3041832e8a2654adc3ccf1683132b92 ] Fix: vmlinux.o: warning: objtool: __do_fast_syscall_32()+0xf5: call to trace_hardirqs_off() leaves .noinstr.text section Fixes: 5d5675df792f ("x86/entry: Fix entry/exit mismatch on failed fast 32-bit syscalls") Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20210621120120.467898710@infradead.org Signed-off-by: Sasha Levin commit cf593548759465bb3c40cedfe0913a150ca6bda8 Author: Maxime Ripard Date: Tue May 25 11:10:59 2021 +0200 drm/vc4: hdmi: Make sure the controller is powered in detect [ Upstream commit 9984d6664ce9dcbbc713962539eaf7636ea246c2 ] If the HPD GPIO is not available and drm_probe_ddc fails, we end up reading the HDMI_HOTPLUG register, but the controller might be powered off resulting in a CPU hang. Make sure we have the power domain and the HSM clock powered during the detect cycle to prevent the hang from happening. Fixes: 4f6e3d66ac52 ("drm/vc4: Add runtime PM support to the HDMI encoder driver") Signed-off-by: Maxime Ripard Reviewed-by: Dave Stevenson Link: https://patchwork.freedesktop.org/patch/msgid/20210525091059.234116-4-maxime@cerno.tech Signed-off-by: Sasha Levin commit f73aca83fd83ab6270ce170e3ac8268b90e48fec Author: Maxime Ripard Date: Tue May 25 11:10:58 2021 +0200 drm/vc4: hdmi: Move the HSM clock enable to runtime_pm [ Upstream commit 411efa18e4b03840553ff58ad9b4621b82a30c04 ] In order to access the HDMI controller, we need to make sure the HSM clock is enabled. If we were to access it with the clock disabled, the CPU would completely hang, resulting in an hard crash. Since we have different code path that would require it, let's move that clock enable / disable to runtime_pm that will take care of the reference counting for us. Fixes: 4f6e3d66ac52 ("drm/vc4: Add runtime PM support to the HDMI encoder driver") Signed-off-by: Maxime Ripard Reviewed-by: Dave Stevenson Link: https://patchwork.freedesktop.org/patch/msgid/20210525091059.234116-3-maxime@cerno.tech Signed-off-by: Sasha Levin commit f11f9ff8a7c97b2a3990c7322304627d9b58d362 Author: Rafael J. Wysocki Date: Tue Jun 22 17:35:18 2021 +0200 Revert "PCI: PM: Do not read power state in pci_enable_device_flags()" [ Upstream commit 4d6035f9bf4ea12776322746a216e856dfe46698 ] Revert commit 4514d991d992 ("PCI: PM: Do not read power state in pci_enable_device_flags()") that is reported to cause PCI device initialization issues on some systems. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=213481 Link: https://lore.kernel.org/linux-acpi/YNDoGICcg0V8HhpQ@eldamar.lan Reported-by: Michael Reported-by: Salvatore Bonaccorso Fixes: 4514d991d992 ("PCI: PM: Do not read power state in pci_enable_device_flags()") Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 4b06ebab4a828c03e9a1ba9bbced505560f8aab6 Author: Haibo Chen Date: Thu Jun 10 17:24:33 2021 +0800 spi: spi-nxp-fspi: move the register operation after the clock enable [ Upstream commit f422316c8e9d3c4aff3c56549dfb44a677d02f14 ] Move the register operation after the clock enable, otherwise system will stuck when this driver probe. Fixes: 71d80563b076 ("spi: spi-nxp-fspi: fix fspi panic by unexpected interrupts") Signed-off-by: Haibo Chen Link: https://lore.kernel.org/r/1623317073-25158-1-git-send-email-haibo.chen@nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 50a1312a29d178000b48f34aa4ffbb11636ed5dc Author: Catalin Marinas Date: Thu Nov 19 17:55:56 2020 +0000 arm64: Force NO_BLOCK_MAPPINGS if crashkernel reservation is required commit 2687275a5843d1089687f08fc64eb3f3b026a169 upstream. mem_init() currently relies on knowing the boundaries of the crashkernel reservation to map such region with page granularity for later unmapping via set_memory_valid(..., 0). If the crashkernel reservation is deferred, such boundaries are not known when the linear mapping is created. Simply parse the command line for "crashkernel" and, if found, create the linear map with NO_BLOCK_MAPPINGS. Signed-off-by: Catalin Marinas Tested-by: Nicolas Saenz Julienne Reviewed-by: Nicolas Saenz Julienne Acked-by: James Morse Cc: James Morse Cc: Nicolas Saenz Julienne Link: https://lore.kernel.org/r/20201119175556.18681-1-catalin.marinas@arm.com Signed-off-by: Catalin Marinas Cc: Kefeng Wang Signed-off-by: Greg Kroah-Hartman commit bd5d4df4dcc1f2d1ceac7b167df1e699a7f6deb7 Author: Catalin Marinas Date: Wed Nov 18 18:58:09 2020 +0000 arm64: Ignore any DMA offsets in the max_zone_phys() calculation commit 791ab8b2e3db0c6e4295467d10398800ec29144c upstream. Currently, the kernel assumes that if RAM starts above 32-bit (or zone_bits), there is still a ZONE_DMA/DMA32 at the bottom of the RAM and such constrained devices have a hardwired DMA offset. In practice, we haven't noticed any such hardware so let's assume that we can expand ZONE_DMA32 to the available memory if no RAM below 4GB. Similarly, ZONE_DMA is expanded to the 4GB limit if no RAM addressable by zone_bits. Signed-off-by: Catalin Marinas Tested-by: Nicolas Saenz Julienne Reviewed-by: Nicolas Saenz Julienne Cc: Nicolas Saenz Julienne Cc: Robin Murphy Link: https://lore.kernel.org/r/20201118185809.1078362-1-catalin.marinas@arm.com Signed-off-by: Catalin Marinas Cc: Kefeng Wang Signed-off-by: Greg Kroah-Hartman commit 3bbdf5a6fcd2467a8e4854c6dba320369713bd0c Author: Nathan Chancellor Date: Fri Apr 9 12:21:28 2021 -0700 MIPS: generic: Update node names to avoid unit addresses commit e607ff630c6053ecc67502677c0e50053d7892d4 upstream. With the latest mkimage from U-Boot 2021.04, the generic defconfigs no longer build, failing with: /usr/bin/mkimage: verify_header failed for FIT Image support with exit code 1 This is expected after the linked U-Boot commits because '@' is forbidden in the node names due to the way that libfdt treats nodes with the same prefix but different unit addresses. Switch the '@' in the node name to '-'. Drop the unit addresses from the hash and kernel child nodes because there is only one node so they do not need to have a number to differentiate them. Cc: stable@vger.kernel.org Link: https://source.denx.de/u-boot/u-boot/-/commit/79af75f7776fc20b0d7eb6afe1e27c00fdb4b9b4 Link: https://source.denx.de/u-boot/u-boot/-/commit/3f04db891a353f4b127ed57279279f851c6b4917 Suggested-by: Simon Glass Signed-off-by: Nathan Chancellor Reviewed-by: Tom Rini Signed-off-by: Thomas Bogendoerfer [nathan: Backport to 5.10, only apply to .its.S files that exist] Signed-off-by: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman commit 03096a46019e733db2f438dc6c1eec64293174f5 Author: Neil Armstrong Date: Wed Jun 9 17:02:30 2021 +0200 mmc: meson-gx: use memcpy_to/fromio for dram-access-quirk commit 103a5348c22c3fca8b96c735a9e353b8a0801842 upstream. It has been reported that usage of memcpy() to/from an iomem mapping is invalid, and a recent arm64 memcpy update [1] triggers a memory abort when dram-access-quirk is used on the G12A/G12B platforms. This adds a local sg_copy_to_buffer which makes usage of io versions of memcpy when dram-access-quirk is enabled. [1] 285133040e6c ("arm64: Import latest memcpy()/memmove() implementation") Fixes: acdc8e71d9bb ("mmc: meson-gx: add dram-access-quirk") Reported-by: Marek Szyprowski Suggested-by: Mark Rutland Signed-off-by: Neil Armstrong Tested-by: Marek Szyprowski Link: https://lore.kernel.org/r/20210609150230.9291-1-narmstrong@baylibre.com Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit b8fd230ae085747a556f0e4fddd8507a168edc1e Author: Arnd Bergmann Date: Fri May 14 11:26:37 2021 +0100 ARM: 9081/1: fix gcc-10 thumb2-kernel regression commit dad7b9896a5dbac5da8275d5a6147c65c81fb5f2 upstream. When building the kernel wtih gcc-10 or higher using the CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE=y flag, the compiler picks a slightly different set of registers for the inline assembly in cpu_init() that subsequently results in a corrupt kernel stack as well as remaining in FIQ mode. If a banked register is used for the last argument, the wrong version of that register gets loaded into CPSR_c. When building in Arm mode, the arguments are passed as immediate values and the bug cannot happen. This got introduced when Daniel reworked the FIQ handling and was technically always broken, but happened to work with both clang and gcc before gcc-10 as long as they picked one of the lower registers. This is probably an indication that still very few people build the kernel in Thumb2 mode. Marek pointed out the problem on IRC, Arnd narrowed it down to this inline assembly and Russell pinpointed the exact bug. Change the constraints to force the final mode switch to use a non-banked register for the argument to ensure that the correct constant gets loaded. Another alternative would be to always use registers for the constant arguments to avoid the #ifdef that has now become more complex. Cc: # v3.18+ Cc: Daniel Thompson Reported-by: Marek Vasut Acked-by: Ard Biesheuvel Fixes: c0e7f7ee717e ("ARM: 8150/3: fiq: Replace default FIQ handler") Signed-off-by: Arnd Bergmann Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit 3d6c4f78ec6165dd89e0799dd26987b9d9c07ccd Author: Christian König Date: Mon Jun 21 14:29:14 2021 +0200 drm/amdgpu: wait for moving fence after pinning commit 8ddf5b9bb479570a3825d70fecfb9399bc15700c upstream. We actually need to wait for the moving fence after pinning the BO to make sure that the pin is completed. Signed-off-by: Christian König Reviewed-by: Daniel Vetter References: https://lore.kernel.org/dri-devel/20210621151758.2347474-1-daniel.vetter@ffwll.ch/ CC: stable@kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20210622114506.106349-3-christian.koenig@amd.com Signed-off-by: Greg Kroah-Hartman commit 694bb36aa75da5fa433ab0601989d58d71cf7f10 Author: Christian König Date: Mon Jun 21 13:43:05 2021 +0200 drm/radeon: wait for moving fence after pinning commit 4b41726aae563273bb4b4a9462ba51ce4d372f78 upstream. We actually need to wait for the moving fence after pinning the BO to make sure that the pin is completed. Signed-off-by: Christian König Reviewed-by: Daniel Vetter References: https://lore.kernel.org/dri-devel/20210621151758.2347474-1-daniel.vetter@ffwll.ch/ CC: stable@kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20210622114506.106349-2-christian.koenig@amd.com Signed-off-by: Greg Kroah-Hartman commit bcfea2412f4b3fa38ae91dd1640b7c63b3a8295e Author: Christian König Date: Mon Jun 21 13:36:35 2021 +0200 drm/nouveau: wait for moving fence after pinning v2 commit 17b11f71795abdce46f62a808f906857e525cea8 upstream. We actually need to wait for the moving fence after pinning the BO to make sure that the pin is completed. v2: grab the lock while waiting Signed-off-by: Christian König Reviewed-by: Daniel Vetter References: https://lore.kernel.org/dri-devel/20210621151758.2347474-1-daniel.vetter@ffwll.ch/ CC: stable@kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20210622114506.106349-1-christian.koenig@amd.com Signed-off-by: Greg Kroah-Hartman commit 3ef0ca0ec995fe5012d70a31f01826e12f323d0e Author: Desmond Cheong Zhi Xi Date: Sun Jun 20 19:03:26 2021 +0800 drm: add a locked version of drm_is_current_master commit 1815d9c86e3090477fbde066ff314a7e9721ee0f upstream. While checking the master status of the DRM file in drm_is_current_master(), the device's master mutex should be held. Without the mutex, the pointer fpriv->master may be freed concurrently by another process calling drm_setmaster_ioctl(). This could lead to use-after-free errors when the pointer is subsequently dereferenced in drm_lease_owner(). The callers of drm_is_current_master() from drm_auth.c hold the device's master mutex, but external callers do not. Hence, we implement drm_is_current_master_locked() to be used within drm_auth.c, and modify drm_is_current_master() to grab the device's master mutex before checking the master status. Reported-by: Daniel Vetter Signed-off-by: Desmond Cheong Zhi Xi Reviewed-by: Emil Velikov Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20210620110327.4964-2-desmondcheongzx@gmail.com Signed-off-by: Greg Kroah-Hartman commit fea853aca3210c21dfcf07bb82d501b7fd1900a7 Author: Yifan Zhang Date: Sat Jun 19 11:39:43 2021 +0800 Revert "drm/amdgpu/gfx10: enlarge CP_MEC_DOORBELL_RANGE_UPPER to cover full doorbell." commit baacf52a473b24e10322b67757ddb92ab8d86717 upstream. This reverts commit 1c0b0efd148d5b24c4932ddb3fa03c8edd6097b3. Reason for revert: Side effect of enlarging CP_MEC_DOORBELL_RANGE may cause some APUs fail to enter gfxoff in certain user cases. Signed-off-by: Yifan Zhang Acked-by: Alex Deucher Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 1bd81429d53ded4e111616c755a64fad80849354 Author: Yifan Zhang Date: Sat Jun 19 11:40:54 2021 +0800 Revert "drm/amdgpu/gfx9: fix the doorbell missing when in CGPG issue." commit ee5468b9f1d3bf48082eed351dace14598e8ca39 upstream. This reverts commit 4cbbe34807938e6e494e535a68d5ff64edac3f20. Reason for revert: side effect of enlarging CP_MEC_DOORBELL_RANGE may cause some APUs fail to enter gfxoff in certain user cases. Signed-off-by: Yifan Zhang Acked-by: Alex Deucher Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 3051f230f19feb02dfe5b36794f8c883b576e184 Author: Mimi Zohar Date: Tue Jun 22 13:36:41 2021 +0200 module: limit enabling module.sig_enforce [ Upstream commit 0c18f29aae7ce3dadd26d8ee3505d07cc982df75 ] Irrespective as to whether CONFIG_MODULE_SIG is configured, specifying "module.sig_enforce=1" on the boot command line sets "sig_enforce". Only allow "sig_enforce" to be set when CONFIG_MODULE_SIG is configured. This patch makes the presence of /sys/module/module/parameters/sig_enforce dependent on CONFIG_MODULE_SIG=y. Fixes: fda784e50aac ("module: export module signature enforcement status") Reported-by: Nayna Jain Tested-by: Mimi Zohar Tested-by: Jessica Yu Signed-off-by: Mimi Zohar Signed-off-by: Jessica Yu Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 3de043c6851d7c604e0cabdf8e2aca7797952aa9 Author: Greg Kroah-Hartman Date: Wed Jun 23 14:42:55 2021 +0200 Linux 5.10.46 Link: https://lore.kernel.org/r/20210621154911.244649123@linuxfoundation.org Tested-by: Florian Fainelli Tested-by: Jason Self Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Jon Hunter Tested-by: Sudip Mukherjee Tested-by: Salvatore Bonaccorso Tested-by: Guenter Roeck Tested-by: Shuah Khan Tested-by: Hulk Robot Tested-by: Rudi Heitbaum Signed-off-by: Greg Kroah-Hartman commit 174c27583b3807ac96228c442735b02622d8d1c3 Author: Peter Chen Date: Tue Jun 8 18:56:56 2021 +0800 usb: dwc3: core: fix kernel panic when do reboot commit 4bf584a03eec674975ee9fe36c8583d9d470dab1 upstream. When do system reboot, it calls dwc3_shutdown and the whole debugfs for dwc3 has removed first, when the gadget tries to do deinit, and remove debugfs for its endpoints, it meets NULL pointer dereference issue when call debugfs_lookup. Fix it by removing the whole dwc3 debugfs later than dwc3_drd_exit. [ 2924.958838] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000002 .... [ 2925.030994] pstate: 60000005 (nZCv daif -PAN -UAO -TCO BTYPE=--) [ 2925.037005] pc : inode_permission+0x2c/0x198 [ 2925.041281] lr : lookup_one_len_common+0xb0/0xf8 [ 2925.045903] sp : ffff80001276ba70 [ 2925.049218] x29: ffff80001276ba70 x28: ffff0000c01f0000 x27: 0000000000000000 [ 2925.056364] x26: ffff800011791e70 x25: 0000000000000008 x24: dead000000000100 [ 2925.063510] x23: dead000000000122 x22: 0000000000000000 x21: 0000000000000001 [ 2925.070652] x20: ffff8000122c6188 x19: 0000000000000000 x18: 0000000000000000 [ 2925.077797] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000004 [ 2925.084943] x14: ffffffffffffffff x13: 0000000000000000 x12: 0000000000000030 [ 2925.092087] x11: 0101010101010101 x10: 7f7f7f7f7f7f7f7f x9 : ffff8000102b2420 [ 2925.099232] x8 : 7f7f7f7f7f7f7f7f x7 : feff73746e2f6f64 x6 : 0000000000008080 [ 2925.106378] x5 : 61c8864680b583eb x4 : 209e6ec2d263dbb7 x3 : 000074756f307065 [ 2925.113523] x2 : 0000000000000001 x1 : 0000000000000000 x0 : ffff8000122c6188 [ 2925.120671] Call trace: [ 2925.123119] inode_permission+0x2c/0x198 [ 2925.127042] lookup_one_len_common+0xb0/0xf8 [ 2925.131315] lookup_one_len_unlocked+0x34/0xb0 [ 2925.135764] lookup_positive_unlocked+0x14/0x50 [ 2925.140296] debugfs_lookup+0x68/0xa0 [ 2925.143964] dwc3_gadget_free_endpoints+0x84/0xb0 [ 2925.148675] dwc3_gadget_exit+0x28/0x78 [ 2925.152518] dwc3_drd_exit+0x100/0x1f8 [ 2925.156267] dwc3_remove+0x11c/0x120 [ 2925.159851] dwc3_shutdown+0x14/0x20 [ 2925.163432] platform_shutdown+0x28/0x38 [ 2925.167360] device_shutdown+0x15c/0x378 [ 2925.171291] kernel_restart_prepare+0x3c/0x48 [ 2925.175650] kernel_restart+0x1c/0x68 [ 2925.179316] __do_sys_reboot+0x218/0x240 [ 2925.183247] __arm64_sys_reboot+0x28/0x30 [ 2925.187262] invoke_syscall+0x48/0x100 [ 2925.191017] el0_svc_common.constprop.0+0x48/0xc8 [ 2925.195726] do_el0_svc+0x28/0x88 [ 2925.199045] el0_svc+0x20/0x30 [ 2925.202104] el0_sync_handler+0xa8/0xb0 [ 2925.205942] el0_sync+0x148/0x180 [ 2925.209270] Code: a9025bf5 2a0203f5 121f0056 370802b5 (79400660) [ 2925.215372] ---[ end trace 124254d8e485a58b ]--- [ 2925.220012] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b [ 2925.227676] Kernel Offset: disabled [ 2925.231164] CPU features: 0x00001001,20000846 [ 2925.235521] Memory Limit: none [ 2925.238580] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]--- Fixes: 8d396bb0a5b6 ("usb: dwc3: debugfs: Add and remove endpoint dirs dynamically") Cc: Jack Pham Tested-by: Jack Pham Signed-off-by: Peter Chen Link: https://lore.kernel.org/r/20210608105656.10795-1-peter.chen@kernel.org (cherry picked from commit 2a042767814bd0edf2619f06fecd374e266ea068) Link: https://lore.kernel.org/r/20210615080847.GA10432@jackp-linux.qualcomm.com Signed-off-by: Greg Kroah-Hartman commit e52d43c82f2f6556f0b7a790c19c072c1e99a95f Author: Jack Pham Date: Sat May 29 12:29:32 2021 -0700 usb: dwc3: debugfs: Add and remove endpoint dirs dynamically commit 8d396bb0a5b62b326f6be7594d8bd46b088296bd upstream. The DWC3 DebugFS directory and files are currently created once during probe. This includes creation of subdirectories for each of the gadget's endpoints. This works fine for peripheral-only controllers, as dwc3_core_init_mode() calls dwc3_gadget_init() just prior to calling dwc3_debugfs_init(). However, for dual-role controllers, dwc3_core_init_mode() will instead call dwc3_drd_init() which is problematic in a few ways. First, the initial state must be determined, then dwc3_set_mode() will have to schedule drd_work and by then dwc3_debugfs_init() could have already been invoked. Even if the initial mode is peripheral, dwc3_gadget_init() happens after the DebugFS files are created, and worse so if the initial state is host and the controller switches to peripheral much later. And secondly, even if the gadget endpoints' debug entries were successfully created, if the controller exits peripheral mode, its dwc3_eps are freed so the debug files would now hold stale references. So it is best if the DebugFS endpoint entries are created and removed dynamically at the same time the underlying dwc3_eps are. Do this by calling dwc3_debugfs_create_endpoint_dir() as each endpoint is created, and conversely remove the DebugFS entry when the endpoint is freed. Fixes: 41ce1456e1db ("usb: dwc3: core: make dwc3_set_mode() work properly") Cc: stable Reviewed-by: Peter Chen Signed-off-by: Jack Pham Link: https://lore.kernel.org/r/20210529192932.22912-1-jackp@codeaurora.org Signed-off-by: Greg Kroah-Hartman commit 1b5fbb66182f5cab525be163327ce1a1fdbb9f15 Author: Arnaldo Carvalho de Melo Date: Sat Jun 19 10:09:08 2021 -0300 perf beauty: Update copy of linux/socket.h with the kernel sources commit ef83f9efe8461b8fd71eb60b53dbb6a5dd7b39e9 upstream. To pick the changes in: ea6932d70e223e02 ("net: make get_net_ns return error if NET_NS is disabled") That don't result in any changes in the tables generated from that header. This silences this perf build warning: Warning: Kernel ABI header at 'tools/perf/trace/beauty/include/linux/socket.h' differs from latest version at 'include/linux/socket.h' diff -u tools/perf/trace/beauty/include/linux/socket.h include/linux/socket.h Cc: Changbin Du Cc: David S. Miller Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 69371e0482ea3a39484642e8d29c3d51fb26a915 Author: Arnaldo Carvalho de Melo Date: Sat Jun 19 10:15:22 2021 -0300 tools headers UAPI: Sync linux/in.h copy with the kernel sources commit 1792a59eab9593de2eae36c40c5a22d70f52c026 upstream. To pick the changes in: 321827477360934d ("icmp: don't send out ICMP messages with a source address of 0.0.0.0") That don't result in any change in tooling, as INADDR_ are not used to generate id->string tables used by 'perf trace'. This addresses this build warning: Warning: Kernel ABI header at 'tools/include/uapi/linux/in.h' differs from latest version at 'include/uapi/linux/in.h' diff -u tools/include/uapi/linux/in.h include/uapi/linux/in.h Cc: David S. Miller Cc: Toke Høiland-Jørgensen Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 4f6e7098f19b8554470f6ad28030d1550c0bd983 Author: Fugang Duan Date: Wed Jun 16 17:14:25 2021 +0800 net: fec_ptp: add clock rate zero check commit cb3cefe3f3f8af27c6076ef7d1f00350f502055d upstream. Add clock rate zero check to fix coverity issue of "divide by 0". Fixes: commit 85bd1798b24a ("net: fec: fix spin_lock dead lock") Signed-off-by: Fugang Duan Signed-off-by: Joakim Zhang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 1af3a8e91f1accd45f69bd430f92c3a5698cdb56 Author: Joakim Zhang Date: Wed Jun 16 17:10:24 2021 +0800 net: stmmac: disable clocks in stmmac_remove_config_dt() commit 8f269102baf788aecfcbbc6313b6bceb54c9b990 upstream. Platform drivers may call stmmac_probe_config_dt() to parse dt, could call stmmac_remove_config_dt() in error handing after dt parsed, so need disable clocks in stmmac_remove_config_dt(). Go through all platforms drivers which use stmmac_probe_config_dt(), none of them disable clocks manually, so it's safe to disable them in stmmac_remove_config_dt(). Fixes: commit d2ed0a7755fe ("net: ethernet: stmmac: fix of-node and fixed-link-phydev leaks") Signed-off-by: Joakim Zhang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit f71ca814c2860861750668044a18e6d7d74cc2d5 Author: Andrew Morton Date: Tue Jun 15 18:23:39 2021 -0700 mm/slub.c: include swab.h commit 1b3865d016815cbd69a1879ca1c8a8901fda1072 upstream. Fixes build with CONFIG_SLAB_FREELIST_HARDENED=y. Hopefully. But it's the right thing to do anwyay. Fixes: 1ad53d9fa3f61 ("slub: improve bit diffusion for freelist ptr obfuscation") Link: https://bugzilla.kernel.org/show_bug.cgi?id=213417 Reported-by: Acked-by: Kees Cook Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit f6ed2357541612a13a5841b3af4dc32ed984a25f Author: Kees Cook Date: Tue Jun 15 18:23:26 2021 -0700 mm/slub: actually fix freelist pointer vs redzoning commit e41a49fadbc80b60b48d3c095d9e2ee7ef7c9a8e upstream. It turns out that SLUB redzoning ("slub_debug=Z") checks from s->object_size rather than from s->inuse (which is normally bumped to make room for the freelist pointer), so a cache created with an object size less than 24 would have the freelist pointer written beyond s->object_size, causing the redzone to be corrupted by the freelist pointer. This was very visible with "slub_debug=ZF": BUG test (Tainted: G B ): Right Redzone overwritten ----------------------------------------------------------------------------- INFO: 0xffff957ead1c05de-0xffff957ead1c05df @offset=1502. First byte 0x1a instead of 0xbb INFO: Slab 0xffffef3950b47000 objects=170 used=170 fp=0x0000000000000000 flags=0x8000000000000200 INFO: Object 0xffff957ead1c05d8 @offset=1496 fp=0xffff957ead1c0620 Redzone (____ptrval____): bb bb bb bb bb bb bb bb ........ Object (____ptrval____): 00 00 00 00 00 f6 f4 a5 ........ Redzone (____ptrval____): 40 1d e8 1a aa @.... Padding (____ptrval____): 00 00 00 00 00 00 00 00 ........ Adjust the offset to stay within s->object_size. (Note that no caches of in this size range are known to exist in the kernel currently.) Link: https://lkml.kernel.org/r/20210608183955.280836-4-keescook@chromium.org Link: https://lore.kernel.org/linux-mm/20200807160627.GA1420741@elver.google.com/ Link: https://lore.kernel.org/lkml/0f7dd7b2-7496-5e2d-9488-2ec9f8e90441@suse.cz/Fixes: 89b83f282d8b (slub: avoid redzone when choosing freepointer location) Link: https://lore.kernel.org/lkml/CANpmjNOwZ5VpKQn+SYWovTkFB4VsT-RPwyENBmaK0dLcpqStkA@mail.gmail.com Signed-off-by: Kees Cook Reported-by: Marco Elver Reported-by: "Lin, Zhenpeng" Tested-by: Marco Elver Acked-by: Vlastimil Babka Cc: Christoph Lameter Cc: David Rientjes Cc: Joonsoo Kim Cc: Pekka Enberg Cc: Roman Gushchin Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 4314c8c63bfdd56ac34d10955023dc10886eafd3 Author: Kees Cook Date: Tue Jun 15 18:23:22 2021 -0700 mm/slub: fix redzoning for small allocations commit 74c1d3e081533825f2611e46edea1fcdc0701985 upstream. The redzone area for SLUB exists between s->object_size and s->inuse (which is at least the word-aligned object_size). If a cache were created with an object_size smaller than sizeof(void *), the in-object stored freelist pointer would overwrite the redzone (e.g. with boot param "slub_debug=ZF"): BUG test (Tainted: G B ): Right Redzone overwritten ----------------------------------------------------------------------------- INFO: 0xffff957ead1c05de-0xffff957ead1c05df @offset=1502. First byte 0x1a instead of 0xbb INFO: Slab 0xffffef3950b47000 objects=170 used=170 fp=0x0000000000000000 flags=0x8000000000000200 INFO: Object 0xffff957ead1c05d8 @offset=1496 fp=0xffff957ead1c0620 Redzone (____ptrval____): bb bb bb bb bb bb bb bb ........ Object (____ptrval____): f6 f4 a5 40 1d e8 ...@.. Redzone (____ptrval____): 1a aa .. Padding (____ptrval____): 00 00 00 00 00 00 00 00 ........ Store the freelist pointer out of line when object_size is smaller than sizeof(void *) and redzoning is enabled. Additionally remove the "smaller than sizeof(void *)" check under CONFIG_DEBUG_VM in kmem_cache_sanity_check() as it is now redundant: SLAB and SLOB both handle small sizes. (Note that no caches within this size range are known to exist in the kernel currently.) Link: https://lkml.kernel.org/r/20210608183955.280836-3-keescook@chromium.org Fixes: 81819f0fc828 ("SLUB core") Signed-off-by: Kees Cook Acked-by: Vlastimil Babka Cc: Christoph Lameter Cc: David Rientjes Cc: Joonsoo Kim Cc: "Lin, Zhenpeng" Cc: Marco Elver Cc: Pekka Enberg Cc: Roman Gushchin Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 4a36fda16b1bb52acfd419574832dded8cbdef57 Author: Kees Cook Date: Tue Jun 15 18:23:19 2021 -0700 mm/slub: clarify verification reporting commit 8669dbab2ae56085c128894b181c2aa50f97e368 upstream. Patch series "Actually fix freelist pointer vs redzoning", v4. This fixes redzoning vs the freelist pointer (both for middle-position and very small caches). Both are "theoretical" fixes, in that I see no evidence of such small-sized caches actually be used in the kernel, but that's no reason to let the bugs continue to exist, especially since people doing local development keep tripping over it. :) This patch (of 3): Instead of repeating "Redzone" and "Poison", clarify which sides of those zones got tripped. Additionally fix column alignment in the trailer. Before: BUG test (Tainted: G B ): Redzone overwritten ... Redzone (____ptrval____): bb bb bb bb bb bb bb bb ........ Object (____ptrval____): f6 f4 a5 40 1d e8 ...@.. Redzone (____ptrval____): 1a aa .. Padding (____ptrval____): 00 00 00 00 00 00 00 00 ........ After: BUG test (Tainted: G B ): Right Redzone overwritten ... Redzone (____ptrval____): bb bb bb bb bb bb bb bb ........ Object (____ptrval____): f6 f4 a5 40 1d e8 ...@.. Redzone (____ptrval____): 1a aa .. Padding (____ptrval____): 00 00 00 00 00 00 00 00 ........ The earlier commits that slowly resulted in the "Before" reporting were: d86bd1bece6f ("mm/slub: support left redzone") ffc79d288000 ("slub: use print_hex_dump") 2492268472e7 ("SLUB: change error reporting format to follow lockdep loosely") Link: https://lkml.kernel.org/r/20210608183955.280836-1-keescook@chromium.org Link: https://lkml.kernel.org/r/20210608183955.280836-2-keescook@chromium.org Link: https://lore.kernel.org/lkml/cfdb11d7-fb8e-e578-c939-f7f5fb69a6bd@suse.cz/ Signed-off-by: Kees Cook Acked-by: Vlastimil Babka Cc: Marco Elver Cc: "Lin, Zhenpeng" Cc: Christoph Lameter Cc: Pekka Enberg Cc: David Rientjes Cc: Joonsoo Kim Cc: Roman Gushchin Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 12eb3c2c1a4f6e7c30de2aa0a09cb1b9e19fa9c0 Author: Peter Xu Date: Tue Jun 15 18:23:16 2021 -0700 mm/swap: fix pte_same_as_swp() not removing uffd-wp bit when compare commit 099dd6878b9b12d6bbfa6bf29ce0c8ddd38f6901 upstream. I found it by pure code review, that pte_same_as_swp() of unuse_vma() didn't take uffd-wp bit into account when comparing ptes. pte_same_as_swp() returning false negative could cause failure to swapoff swap ptes that was wr-protected by userfaultfd. Link: https://lkml.kernel.org/r/20210603180546.9083-1-peterx@redhat.com Fixes: f45ec5ff16a7 ("userfaultfd: wp: support swap and page migration") Signed-off-by: Peter Xu Acked-by: Hugh Dickins Cc: Andrea Arcangeli Cc: [5.7+] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit fc7fdd8c5c2ad2fe3e297698be9d4dbe4a4e0579 Author: Nikolay Aleksandrov Date: Thu Jun 10 15:04:11 2021 +0300 net: bridge: fix vlan tunnel dst refcnt when egressing commit cfc579f9d89af4ada58c69b03bcaa4887840f3b3 upstream. The egress tunnel code uses dst_clone() and directly sets the result which is wrong because the entry might have 0 refcnt or be already deleted, causing number of problems. It also triggers the WARN_ON() in dst_hold()[1] when a refcnt couldn't be taken. Fix it by using dst_hold_safe() and checking if a reference was actually taken before setting the dst. [1] dmesg WARN_ON log and following refcnt errors WARNING: CPU: 5 PID: 38 at include/net/dst.h:230 br_handle_egress_vlan_tunnel+0x10b/0x134 [bridge] Modules linked in: 8021q garp mrp bridge stp llc bonding ipv6 virtio_net CPU: 5 PID: 38 Comm: ksoftirqd/5 Kdump: loaded Tainted: G W 5.13.0-rc3+ #360 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014 RIP: 0010:br_handle_egress_vlan_tunnel+0x10b/0x134 [bridge] Code: e8 85 bc 01 e1 45 84 f6 74 90 45 31 f6 85 db 48 c7 c7 a0 02 19 a0 41 0f 94 c6 31 c9 31 d2 44 89 f6 e8 64 bc 01 e1 85 db 75 02 <0f> 0b 31 c9 31 d2 44 89 f6 48 c7 c7 70 02 19 a0 e8 4b bc 01 e1 49 RSP: 0018:ffff8881003d39e8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffffffa01902a0 RBP: ffff8881040c6700 R08: 0000000000000000 R09: 0000000000000001 R10: 2ce93d0054fe0d00 R11: 54fe0d00000e0000 R12: ffff888109515000 R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000401 FS: 0000000000000000(0000) GS:ffff88822bf40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f42ba70f030 CR3: 0000000109926000 CR4: 00000000000006e0 Call Trace: br_handle_vlan+0xbc/0xca [bridge] __br_forward+0x23/0x164 [bridge] deliver_clone+0x41/0x48 [bridge] br_handle_frame_finish+0x36f/0x3aa [bridge] ? skb_dst+0x2e/0x38 [bridge] ? br_handle_ingress_vlan_tunnel+0x3e/0x1c8 [bridge] ? br_handle_frame_finish+0x3aa/0x3aa [bridge] br_handle_frame+0x2c3/0x377 [bridge] ? __skb_pull+0x33/0x51 ? vlan_do_receive+0x4f/0x36a ? br_handle_frame_finish+0x3aa/0x3aa [bridge] __netif_receive_skb_core+0x539/0x7c6 ? __list_del_entry_valid+0x16e/0x1c2 __netif_receive_skb_list_core+0x6d/0xd6 netif_receive_skb_list_internal+0x1d9/0x1fa gro_normal_list+0x22/0x3e dev_gro_receive+0x55b/0x600 ? detach_buf_split+0x58/0x140 napi_gro_receive+0x94/0x12e virtnet_poll+0x15d/0x315 [virtio_net] __napi_poll+0x2c/0x1c9 net_rx_action+0xe6/0x1fb __do_softirq+0x115/0x2d8 run_ksoftirqd+0x18/0x20 smpboot_thread_fn+0x183/0x19c ? smpboot_unregister_percpu_thread+0x66/0x66 kthread+0x10a/0x10f ? kthread_mod_delayed_work+0xb6/0xb6 ret_from_fork+0x22/0x30 ---[ end trace 49f61b07f775fd2b ]--- dst_release: dst:00000000c02d677a refcnt:-1 dst_release underflow Cc: stable@vger.kernel.org Fixes: 11538d039ac6 ("bridge: vlan dst_metadata hooks in ingress and egress paths") Signed-off-by: Nikolay Aleksandrov Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit fe0448a3fad365a747283a00a1d1ad5e8d6675b7 Author: Nikolay Aleksandrov Date: Thu Jun 10 15:04:10 2021 +0300 net: bridge: fix vlan tunnel dst null pointer dereference commit 58e2071742e38f29f051b709a5cca014ba51166f upstream. This patch fixes a tunnel_dst null pointer dereference due to lockless access in the tunnel egress path. When deleting a vlan tunnel the tunnel_dst pointer is set to NULL without waiting a grace period (i.e. while it's still usable) and packets egressing are dereferencing it without checking. Use READ/WRITE_ONCE to annotate the lockless use of tunnel_id, use RCU for accessing tunnel_dst and make sure it is read only once and checked in the egress path. The dst is already properly RCU protected so we don't need to do anything fancy than to make sure tunnel_id and tunnel_dst are read only once and checked in the egress path. Cc: stable@vger.kernel.org Fixes: 11538d039ac6 ("bridge: vlan dst_metadata hooks in ingress and egress paths") Signed-off-by: Nikolay Aleksandrov Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit cfe403f209b11fad123a882100f0822a52a7630f Author: Esben Haabendal Date: Fri Jun 18 12:52:33 2021 +0200 net: ll_temac: Fix TX BD buffer overwrite commit c364df2489b8ef2f5e3159b1dff1ff1fdb16040d upstream. Just as the initial check, we need to ensure num_frag+1 buffers available, as that is the number of buffers we are going to use. This fixes a buffer overflow, which might be seen during heavy network load. Complete lockup of TEMAC was reproducible within about 10 minutes of a particular load. Fixes: 84823ff80f74 ("net: ll_temac: Fix race condition causing TX hang") Cc: stable@vger.kernel.org # v5.4+ Signed-off-by: Esben Haabendal Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 019ab7d044d0ebf97e1236bb8935b7809be92358 Author: Esben Haabendal Date: Fri Jun 18 12:52:23 2021 +0200 net: ll_temac: Make sure to free skb when it is completely used commit 6aa32217a9a446275440ee8724b1ecaf1838df47 upstream. With the skb pointer piggy-backed on the TX BD, we have a simple and efficient way to free the skb buffer when the frame has been transmitted. But in order to avoid freeing the skb while there are still fragments from the skb in use, we need to piggy-back on the TX BD of the skb, not the first. Without this, we are doing use-after-free on the DMA side, when the first BD of a multi TX BD packet is seen as completed in xmit_done, and the remaining BDs are still being processed. Cc: stable@vger.kernel.org # v5.4+ Signed-off-by: Esben Haabendal Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 41984d4fbe21d7e0638212c42fdeaead76f5513d Author: Yifan Zhang Date: Thu Jun 10 09:55:01 2021 +0800 drm/amdgpu/gfx9: fix the doorbell missing when in CGPG issue. commit 4cbbe34807938e6e494e535a68d5ff64edac3f20 upstream. If GC has entered CGPG, ringing doorbell > first page doesn't wakeup GC. Enlarge CP_MEC_DOORBELL_RANGE_UPPER to workaround this issue. Signed-off-by: Yifan Zhang Reviewed-by: Felix Kuehling Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit bc58ec307ce93a0bcb14f4cdcd8e18ac7b4ebf10 Author: Yifan Zhang Date: Thu Jun 10 10:10:07 2021 +0800 drm/amdgpu/gfx10: enlarge CP_MEC_DOORBELL_RANGE_UPPER to cover full doorbell. commit 1c0b0efd148d5b24c4932ddb3fa03c8edd6097b3 upstream. If GC has entered CGPG, ringing doorbell > first page doesn't wakeup GC. Enlarge CP_MEC_DOORBELL_RANGE_UPPER to workaround this issue. Signed-off-by: Yifan Zhang Reviewed-by: Felix Kuehling Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 96b4126f8c371b64b39a2faab8cb4d39dd777411 Author: Avraham Stern Date: Fri Jun 18 13:41:31 2021 +0300 cfg80211: avoid double free of PMSR request commit 0288e5e16a2e18f0b7e61a2b70d9037fc6e4abeb upstream. If cfg80211_pmsr_process_abort() moves all the PMSR requests that need to be freed into a local list before aborting and freeing them. As a result, it is possible that cfg80211_pmsr_complete() will run in parallel and free the same PMSR request. Fix it by freeing the request in cfg80211_pmsr_complete() only if it is still in the original pmsr list. Cc: stable@vger.kernel.org Fixes: 9bb7e0f24e7e ("cfg80211: add peer measurement with FTM initiator API") Signed-off-by: Avraham Stern Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/iwlwifi.20210618133832.1fbef57e269a.I00294bebdb0680b892f8d1d5c871fd9dbe785a5e@changeid Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 5493b0c2a784ffa4c80c6a6e2c933824bfaba9b1 Author: Johannes Berg Date: Fri Jun 18 13:41:29 2021 +0300 cfg80211: make certificate generation more robust commit b5642479b0f7168fe16d156913533fe65ab4f8d5 upstream. If all net/wireless/certs/*.hex files are deleted, the build will hang at this point since the 'cat' command will have no arguments. Do "echo | cat - ..." so that even if the "..." part is empty, the whole thing won't hang. Cc: stable@vger.kernel.org Signed-off-by: Johannes Berg Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/iwlwifi.20210618133832.c989056c3664.Ic3b77531d00b30b26dcd69c64e55ae2f60c3f31e@changeid Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit f74df6e086083dc435f7500bdbc86b05277d17af Author: Mathy Vanhoef Date: Sun May 30 15:32:26 2021 +0200 mac80211: Fix NULL ptr deref for injected rate info commit bddc0c411a45d3718ac535a070f349be8eca8d48 upstream. The commit cb17ed29a7a5 ("mac80211: parse radiotap header when selecting Tx queue") moved the code to validate the radiotap header from ieee80211_monitor_start_xmit to ieee80211_parse_tx_radiotap. This made is possible to share more code with the new Tx queue selection code for injected frames. But at the same time, it now required the call of ieee80211_parse_tx_radiotap at the beginning of functions which wanted to handle the radiotap header. And this broke the rate parser for radiotap header parser. The radiotap parser for rates is operating most of the time only on the data in the actual radiotap header. But for the 802.11a/b/g rates, it must also know the selected band from the chandef information. But this information is only written to the ieee80211_tx_info at the end of the ieee80211_monitor_start_xmit - long after ieee80211_parse_tx_radiotap was already called. The info->band information was therefore always 0 (NL80211_BAND_2GHZ) when the parser code tried to access it. For a 5GHz only device, injecting a frame with 802.11a rates would cause a NULL pointer dereference because local->hw.wiphy->bands[NL80211_BAND_2GHZ] would most likely have been NULL when the radiotap parser searched for the correct rate index of the driver. Cc: stable@vger.kernel.org Reported-by: Ben Greear Fixes: cb17ed29a7a5 ("mac80211: parse radiotap header when selecting Tx queue") Signed-off-by: Mathy Vanhoef [sven@narfation.org: added commit message] Signed-off-by: Sven Eckelmann Link: https://lore.kernel.org/r/20210530133226.40587-1-sven@narfation.org Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit df203c1fdaaf6db8781fcf41237b8c2ea16b69a8 Author: Bumyong Lee Date: Fri May 7 15:36:47 2021 +0900 dmaengine: pl330: fix wrong usage of spinlock flags in dma_cyclc commit 4ad5dd2d7876d79507a20f026507d1a93b8fff10 upstream. flags varible which is the input parameter of pl330_prep_dma_cyclic() should not be used by spinlock_irq[save/restore] function. Signed-off-by: Jongho Park Signed-off-by: Bumyong Lee Signed-off-by: Chanho Park Link: https://lore.kernel.org/r/20210507063647.111209-1-chanho61.park@samsung.com Fixes: f6f2421c0a1c ("dmaengine: pl330: Merge dma_pl330_dmac and pl330_dmac structs") Cc: stable@vger.kernel.org Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit b842b568a584645cf9fcaf5b62fd875d1ef5d275 Author: Pingfan Liu Date: Tue Jun 15 18:23:36 2021 -0700 crash_core, vmcoreinfo: append 'SECTION_SIZE_BITS' to vmcoreinfo commit 4f5aecdff25f59fb5ea456d5152a913906ecf287 upstream. As mentioned in kernel commit 1d50e5d0c505 ("crash_core, vmcoreinfo: Append 'MAX_PHYSMEM_BITS' to vmcoreinfo"), SECTION_SIZE_BITS in the formula: #define SECTIONS_SHIFT (MAX_PHYSMEM_BITS - SECTION_SIZE_BITS) Besides SECTIONS_SHIFT, SECTION_SIZE_BITS is also used to calculate PAGES_PER_SECTION in makedumpfile just like kernel. Unfortunately, this arch-dependent macro SECTION_SIZE_BITS changes, e.g. recently in kernel commit f0b13ee23241 ("arm64/sparsemem: reduce SECTION_SIZE_BITS"). But user space wants a stable interface to get this info. Such info is impossible to be deduced from a crashdump vmcore. Hence append SECTION_SIZE_BITS to vmcoreinfo. Link: https://lkml.kernel.org/r/20210608103359.84907-1-kernelfans@gmail.com Link: http://lists.infradead.org/pipermail/kexec/2021-June/022676.html Signed-off-by: Pingfan Liu Acked-by: Baoquan He Cc: Bhupesh Sharma Cc: Kazuhito Hagio Cc: Dave Young Cc: Boris Petkov Cc: Ingo Molnar Cc: Thomas Gleixner Cc: James Morse Cc: Mark Rutland Cc: Will Deacon Cc: Catalin Marinas Cc: Michael Ellerman Cc: Paul Mackerras Cc: Benjamin Herrenschmidt Cc: Dave Anderson Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 63ba83563e71d5785f642e7ed2dc503acf48a092 Author: Thomas Gleixner Date: Wed Jun 9 21:18:00 2021 +0200 x86/fpu: Reset state for all signal restore failures commit efa165504943f2128d50f63de0c02faf6dcceb0d upstream. If access_ok() or fpregs_soft_set() fails in __fpu__restore_sig() then the function just returns but does not clear the FPU state as it does for all other fatal failures. Clear the FPU state for these failures as well. Fixes: 72a671ced66d ("x86, fpu: Unify signal handling code paths for x86 and x86_64 kernels") Signed-off-by: Thomas Gleixner Signed-off-by: Borislav Petkov Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/87mtryyhhz.ffs@nanos.tec.linutronix.de Signed-off-by: Greg Kroah-Hartman commit a7748e021b9fb7739e3cb88449296539de0b6817 Author: Andy Lutomirski Date: Tue Jun 8 16:36:19 2021 +0200 x86/fpu: Invalidate FPU state after a failed XRSTOR from a user buffer commit d8778e393afa421f1f117471144f8ce6deb6953a upstream. Both Intel and AMD consider it to be architecturally valid for XRSTOR to fail with #PF but nonetheless change the register state. The actual conditions under which this might occur are unclear [1], but it seems plausible that this might be triggered if one sibling thread unmaps a page and invalidates the shared TLB while another sibling thread is executing XRSTOR on the page in question. __fpu__restore_sig() can execute XRSTOR while the hardware registers are preserved on behalf of a different victim task (using the fpu_fpregs_owner_ctx mechanism), and, in theory, XRSTOR could fail but modify the registers. If this happens, then there is a window in which __fpu__restore_sig() could schedule out and the victim task could schedule back in without reloading its own FPU registers. This would result in part of the FPU state that __fpu__restore_sig() was attempting to load leaking into the victim task's user-visible state. Invalidate preserved FPU registers on XRSTOR failure to prevent this situation from corrupting any state. [1] Frequent readers of the errata lists might imagine "complex microarchitectural conditions". Fixes: 1d731e731c4c ("x86/fpu: Add a fastpath to __fpu__restore_sig()") Signed-off-by: Andy Lutomirski Signed-off-by: Thomas Gleixner Signed-off-by: Borislav Petkov Acked-by: Dave Hansen Acked-by: Rik van Riel Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20210608144345.758116583@linutronix.de Signed-off-by: Greg Kroah-Hartman commit 076f732b16a5bf842686e1b43ab6021a2d98233e Author: Thomas Gleixner Date: Tue Jun 8 16:36:18 2021 +0200 x86/fpu: Prevent state corruption in __fpu__restore_sig() commit 484cea4f362e1eeb5c869abbfb5f90eae6421b38 upstream. The non-compacted slowpath uses __copy_from_user() and copies the entire user buffer into the kernel buffer, verbatim. This means that the kernel buffer may now contain entirely invalid state on which XRSTOR will #GP. validate_user_xstate_header() can detect some of that corruption, but that leaves the onus on callers to clear the buffer. Prior to XSAVES support, it was possible just to reinitialize the buffer, completely, but with supervisor states that is not longer possible as the buffer clearing code split got it backwards. Fixing that is possible but not corrupting the state in the first place is more robust. Avoid corruption of the kernel XSAVE buffer by using copy_user_to_xstate() which validates the XSAVE header contents before copying the actual states to the kernel. copy_user_to_xstate() was previously only called for compacted-format kernel buffers, but it works for both compacted and non-compacted forms. Using it for the non-compacted form is slower because of multiple __copy_from_user() operations, but that cost is less important than robust code in an already slow path. [ Changelog polished by Dave Hansen ] Fixes: b860eb8dce59 ("x86/fpu/xstate: Define new functions for clearing fpregs and xstates") Reported-by: syzbot+2067e764dbcd10721e2e@syzkaller.appspotmail.com Signed-off-by: Thomas Gleixner Signed-off-by: Borislav Petkov Reviewed-by: Borislav Petkov Acked-by: Dave Hansen Acked-by: Rik van Riel Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20210608144345.611833074@linutronix.de Signed-off-by: Greg Kroah-Hartman commit abc790bdbbc5c538e9be62cde9b5ae4e4c562833 Author: Thomas Gleixner Date: Tue Jun 8 16:36:21 2021 +0200 x86/pkru: Write hardware init value to PKRU when xstate is init commit 510b80a6a0f1a0d114c6e33bcea64747d127973c upstream. When user space brings PKRU into init state, then the kernel handling is broken: T1 user space xsave(state) state.header.xfeatures &= ~XFEATURE_MASK_PKRU; xrstor(state) T1 -> kernel schedule() XSAVE(S) -> T1->xsave.header.xfeatures[PKRU] == 0 T1->flags |= TIF_NEED_FPU_LOAD; wrpkru(); schedule() ... pk = get_xsave_addr(&T1->fpu->state.xsave, XFEATURE_PKRU); if (pk) wrpkru(pk->pkru); else wrpkru(DEFAULT_PKRU); Because the xfeatures bit is 0 and therefore the value in the xsave storage is not valid, get_xsave_addr() returns NULL and switch_to() writes the default PKRU. -> FAIL #1! So that wrecks any copy_to/from_user() on the way back to user space which hits memory which is protected by the default PKRU value. Assumed that this does not fail (pure luck) then T1 goes back to user space and because TIF_NEED_FPU_LOAD is set it ends up in switch_fpu_return() __fpregs_load_activate() if (!fpregs_state_valid()) { load_XSTATE_from_task(); } But if nothing touched the FPU between T1 scheduling out and back in, then the fpregs_state is still valid which means switch_fpu_return() does nothing and just clears TIF_NEED_FPU_LOAD. Back to user space with DEFAULT_PKRU loaded. -> FAIL #2! The fix is simple: if get_xsave_addr() returns NULL then set the PKRU value to 0 instead of the restrictive default PKRU value in init_pkru_value. [ bp: Massage in minor nitpicks from folks. ] Fixes: 0cecca9d03c9 ("x86/fpu: Eager switch PKRU state") Signed-off-by: Thomas Gleixner Signed-off-by: Borislav Petkov Acked-by: Dave Hansen Acked-by: Rik van Riel Tested-by: Babu Moger Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20210608144346.045616965@linutronix.de Signed-off-by: Greg Kroah-Hartman commit 208bb686e7fa7fff16e8fa78ff0db34aa9acdbd7 Author: Tom Lendacky Date: Tue Jun 8 11:54:33 2021 +0200 x86/ioremap: Map EFI-reserved memory as encrypted for SEV commit 8d651ee9c71bb12fc0c8eb2786b66cbe5aa3e43b upstream. Some drivers require memory that is marked as EFI boot services data. In order for this memory to not be re-used by the kernel after ExitBootServices(), efi_mem_reserve() is used to preserve it by inserting a new EFI memory descriptor and marking it with the EFI_MEMORY_RUNTIME attribute. Under SEV, memory marked with the EFI_MEMORY_RUNTIME attribute needs to be mapped encrypted by Linux, otherwise the kernel might crash at boot like below: EFI Variables Facility v0.08 2004-May-17 general protection fault, probably for non-canonical address 0x3597688770a868b2: 0000 [#1] SMP NOPTI CPU: 13 PID: 1 Comm: swapper/0 Not tainted 5.12.4-2-default #1 openSUSE Tumbleweed Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:efi_mokvar_entry_next [...] Call Trace: efi_mokvar_sysfs_init ? efi_mokvar_table_init do_one_initcall ? __kmalloc kernel_init_freeable ? rest_init kernel_init ret_from_fork Expand the __ioremap_check_other() function to additionally check for this other type of boot data reserved at runtime and indicate that it should be mapped encrypted for an SEV guest. [ bp: Massage commit message. ] Fixes: 58c909022a5a ("efi: Support for MOK variable config table") Reported-by: Joerg Roedel Signed-off-by: Tom Lendacky Signed-off-by: Joerg Roedel Signed-off-by: Borislav Petkov Tested-by: Joerg Roedel Cc: # 5.10+ Link: https://lkml.kernel.org/r/20210608095439.12668-2-joro@8bytes.org Signed-off-by: Greg Kroah-Hartman commit 75a55bc2e5e64cfdcf839e06b37cbb0cb8b69459 Author: Thomas Gleixner Date: Tue Jun 8 16:36:20 2021 +0200 x86/process: Check PF_KTHREAD and not current->mm for kernel threads commit 12f7764ac61200e32c916f038bdc08f884b0b604 upstream. switch_fpu_finish() checks current->mm as indicator for kernel threads. That's wrong because kernel threads can temporarily use a mm of a user process via kthread_use_mm(). Check the task flags for PF_KTHREAD instead. Fixes: 0cecca9d03c9 ("x86/fpu: Eager switch PKRU state") Signed-off-by: Thomas Gleixner Signed-off-by: Borislav Petkov Acked-by: Dave Hansen Acked-by: Rik van Riel Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20210608144345.912645927@linutronix.de Signed-off-by: Greg Kroah-Hartman commit ddaaf38e1923760de1bc6f5e4e02e42db327ab6e Author: Fan Du Date: Thu Jun 17 12:46:57 2021 -0700 x86/mm: Avoid truncating memblocks for SGX memory commit 28e5e44aa3f4e0e0370864ed008fb5e2d85f4dc8 upstream. tl;dr: Several SGX users reported seeing the following message on NUMA systems: sgx: [Firmware Bug]: Unable to map EPC section to online node. Fallback to the NUMA node 0. This turned out to be the memblock code mistakenly throwing away SGX memory. === Full Changelog === The 'max_pfn' variable represents the highest known RAM address. It can be used, for instance, to quickly determine for which physical addresses there is mem_map[] space allocated. The numa_meminfo code makes an effort to throw out ("trim") all memory blocks which are above 'max_pfn'. SGX memory is not considered RAM (it is marked as "Reserved" in the e820) and is not taken into account by max_pfn. Despite this, SGX memory areas have NUMA affinity and are enumerated in the ACPI SRAT table. The existing SGX code uses the numa_meminfo mechanism to look up the NUMA affinity for its memory areas. In cases where SGX memory was above max_pfn (usually just the one EPC section in the last highest NUMA node), the numa_memblock is truncated at 'max_pfn', which is below the SGX memory. When the SGX code tries to look up the affinity of this memory, it fails and produces an error message: sgx: [Firmware Bug]: Unable to map EPC section to online node. Fallback to the NUMA node 0. and assigns the memory to NUMA node 0. Instead of silently truncating the memory block at 'max_pfn' and dropping the SGX memory, add the truncated portion to 'numa_reserved_meminfo'. This allows the SGX code to later determine the NUMA affinity of its 'Reserved' area. Before, numa_meminfo looked like this (from 'crash'): blk = { start = 0x0, end = 0x2080000000, nid = 0x0 } { start = 0x2080000000, end = 0x4000000000, nid = 0x1 } numa_reserved_meminfo is empty. With this, numa_meminfo looks like this: blk = { start = 0x0, end = 0x2080000000, nid = 0x0 } { start = 0x2080000000, end = 0x4000000000, nid = 0x1 } and numa_reserved_meminfo has an entry for node 1's SGX memory: blk = { start = 0x4000000000, end = 0x4080000000, nid = 0x1 } [ daveh: completely rewrote/reworked changelog ] Fixes: 5d30f92e7631 ("x86/NUMA: Provide a range-to-target_node lookup facility") Reported-by: Reinette Chatre Signed-off-by: Fan Du Signed-off-by: Dave Hansen Signed-off-by: Borislav Petkov Reviewed-by: Jarkko Sakkinen Reviewed-by: Dan Williams Reviewed-by: Dave Hansen Cc: Link: https://lkml.kernel.org/r/20210617194657.0A99CB22@viggo.jf.intel.com Signed-off-by: Greg Kroah-Hartman commit f6bcb1a6281d4ea03b98e26501b88439baa007c6 Author: Vineet Gupta Date: Tue Jun 8 19:39:25 2021 -0700 ARCv2: save ABI registers across signal handling commit 96f1b00138cb8f04c742c82d0a7c460b2202e887 upstream. ARCv2 has some configuration dependent registers (r30, r58, r59) which could be targetted by the compiler. To keep the ABI stable, these were unconditionally part of the glibc ABI (sysdeps/unix/sysv/linux/arc/sys/ucontext.h:mcontext_t) however we missed populating them (by saving/restoring them across signal handling). This patch fixes the issue by - adding arcv2 ABI regs to kernel struct sigcontext - populating them during signal handling Change to struct sigcontext might seem like a glibc ABI change (although it primarily uses ucontext_t:mcontext_t) but the fact is - it has only been extended (existing fields are not touched) - the old sigcontext was ABI incomplete to begin with anyways Fixes: https://github.com/foss-for-synopsys-dwc-arc-processors/linux/issues/53 Cc: Tested-by: kernel test robot Reported-by: Vladimir Isaev Signed-off-by: Vineet Gupta Signed-off-by: Greg Kroah-Hartman commit b516daed991359ba0433dff31862ae4df30b4150 Author: Harald Freudenberger Date: Tue Jun 1 08:27:29 2021 +0200 s390/ap: Fix hanging ioctl caused by wrong msg counter commit e73a99f3287a740a07d6618e9470f4d6cb217da8 upstream. When a AP queue is switched to soft offline, all pending requests are purged out of the pending requests list and 'received' by the upper layer like zcrypt device drivers. This is also done for requests which are already enqueued into the firmware queue. A request in a firmware queue may eventually produce an response message, but there is no waiting process any more. However, the response was counted with the queue_counter and as this counter was reset to 0 with the offline switch, the pending response caused the queue_counter to get negative. The next request increased this counter to 0 (instead of 1) which caused the ap code to assume there is nothing to receive and so the response for this valid request was never tried to fetch from the firmware queue. This all caused a queue to not work properly after a switch offline/online and in the end processes to hang forever when trying to send a crypto request after an queue offline/online switch cicle. Fixed by a) making sure the counter does not drop below 0 and b) on a successful enqueue of a message has at least a value of 1. Additionally a warning is emitted, when a reply can't get assigned to a waiting process. This may be normal operation (process had timeout or has been killed) but may give a hint that something unexpected happened (like this odd behavior described above). Signed-off-by: Harald Freudenberger Cc: stable@vger.kernel.org Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit 7c003dab436db33aac674ad66eed49add83b595b Author: Alexander Gordeev Date: Mon May 17 08:18:11 2021 +0200 s390/mcck: fix calculation of SIE critical section size commit 5bcbe3285fb614c49db6b238253f7daff7e66312 upstream. The size of SIE critical section is calculated wrongly as result of a missed subtraction in commit 0b0ed657fe00 ("s390: remove critical section cleanup from entry.S") Fixes: 0b0ed657fe00 ("s390: remove critical section cleanup from entry.S") Cc: Signed-off-by: Alexander Gordeev Reviewed-by: Christian Borntraeger Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit 3a9934d6b8dd8a91d61ed2d0d538fa27cb9192a3 Author: Wanpeng Li Date: Thu Jun 10 21:59:33 2021 -0700 KVM: X86: Fix x86_emulator slab cache leak commit dfdc0a714d241bfbf951886c373cd1ae463fcc25 upstream. Commit c9b8b07cded58 (KVM: x86: Dynamically allocate per-vCPU emulation context) tries to allocate per-vCPU emulation context dynamically, however, the x86_emulator slab cache is still exiting after the kvm module is unload as below after destroying the VM and unloading the kvm module. grep x86_emulator /proc/slabinfo x86_emulator 36 36 2672 12 8 : tunables 0 0 0 : slabdata 3 3 0 This patch fixes this slab cache leak by destroying the x86_emulator slab cache when the kvm module is unloaded. Fixes: c9b8b07cded58 (KVM: x86: Dynamically allocate per-vCPU emulation context) Cc: stable@vger.kernel.org Signed-off-by: Wanpeng Li Message-Id: <1623387573-5969-1-git-send-email-wanpengli@tencent.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 18eca69f88f2e3f1421d57f1dc4219a68de5891d Author: Sean Christopherson Date: Thu Jun 10 15:00:26 2021 -0700 KVM: x86/mmu: Calculate and check "full" mmu_role for nested MMU commit 654430efde27248be563df9a88631204b5fe2df2 upstream. Calculate and check the full mmu_role when initializing the MMU context for the nested MMU, where "full" means the bits and pieces of the role that aren't handled by kvm_calc_mmu_role_common(). While the nested MMU isn't used for shadow paging, things like the number of levels in the guest's page tables are surprisingly important when walking the guest page tables. Failure to reinitialize the nested MMU context if L2's paging mode changes can result in unexpected and/or missed page faults, and likely other explosions. E.g. if an L1 vCPU is running both a 32-bit PAE L2 and a 64-bit L2, the "common" role calculation will yield the same role for both L2s. If the 64-bit L2 is run after the 32-bit PAE L2, L0 will fail to reinitialize the nested MMU context, ultimately resulting in a bad walk of L2's page tables as the MMU will still have a guest root_level of PT32E_ROOT_LEVEL. WARNING: CPU: 4 PID: 167334 at arch/x86/kvm/vmx/vmx.c:3075 ept_save_pdptrs+0x15/0xe0 [kvm_intel] Modules linked in: kvm_intel] CPU: 4 PID: 167334 Comm: CPU 3/KVM Not tainted 5.13.0-rc1-d849817d5673-reqs #185 Hardware name: ASUS Q87M-E/Q87M-E, BIOS 1102 03/03/2014 RIP: 0010:ept_save_pdptrs+0x15/0xe0 [kvm_intel] Code: <0f> 0b c3 f6 87 d8 02 00f RSP: 0018:ffffbba702dbba00 EFLAGS: 00010202 RAX: 0000000000000011 RBX: 0000000000000002 RCX: ffffffff810a2c08 RDX: ffff91d7bc30acc0 RSI: 0000000000000011 RDI: ffff91d7bc30a600 RBP: ffff91d7bc30a600 R08: 0000000000000010 R09: 0000000000000007 R10: 0000000000000000 R11: 0000000000000000 R12: ffff91d7bc30a600 R13: ffff91d7bc30acc0 R14: ffff91d67c123460 R15: 0000000115d7e005 FS: 00007fe8e9ffb700(0000) GS:ffff91d90fb00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000029f15a001 CR4: 00000000001726e0 Call Trace: kvm_pdptr_read+0x3a/0x40 [kvm] paging64_walk_addr_generic+0x327/0x6a0 [kvm] paging64_gva_to_gpa_nested+0x3f/0xb0 [kvm] kvm_fetch_guest_virt+0x4c/0xb0 [kvm] __do_insn_fetch_bytes+0x11a/0x1f0 [kvm] x86_decode_insn+0x787/0x1490 [kvm] x86_decode_emulated_instruction+0x58/0x1e0 [kvm] x86_emulate_instruction+0x122/0x4f0 [kvm] vmx_handle_exit+0x120/0x660 [kvm_intel] kvm_arch_vcpu_ioctl_run+0xe25/0x1cb0 [kvm] kvm_vcpu_ioctl+0x211/0x5a0 [kvm] __x64_sys_ioctl+0x83/0xb0 do_syscall_64+0x40/0xb0 entry_SYSCALL_64_after_hwframe+0x44/0xae Cc: Vitaly Kuznetsov Cc: stable@vger.kernel.org Fixes: bf627a928837 ("x86/kvm/mmu: check if MMU reconfiguration is needed in init_kvm_nested_mmu()") Signed-off-by: Sean Christopherson Message-Id: <20210610220026.1364486-1-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 669a8866e468fd020d34eb00e08cb41d3774b71b Author: Sean Christopherson Date: Wed Jun 9 11:56:11 2021 -0700 KVM: x86: Immediately reset the MMU context when the SMM flag is cleared commit 78fcb2c91adfec8ce3a2ba6b4d0dda89f2f4a7c6 upstream. Immediately reset the MMU context when the vCPU's SMM flag is cleared so that the SMM flag in the MMU role is always synchronized with the vCPU's flag. If RSM fails (which isn't correctly emulated), KVM will bail without calling post_leave_smm() and leave the MMU in a bad state. The bad MMU role can lead to a NULL pointer dereference when grabbing a shadow page's rmap for a page fault as the initial lookups for the gfn will happen with the vCPU's SMM flag (=0), whereas the rmap lookup will use the shadow page's SMM flag, which comes from the MMU (=1). SMM has an entirely different set of memslots, and so the initial lookup can find a memslot (SMM=0) and then explode on the rmap memslot lookup (SMM=1). general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 PID: 8410 Comm: syz-executor382 Not tainted 5.13.0-rc5-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__gfn_to_rmap arch/x86/kvm/mmu/mmu.c:935 [inline] RIP: 0010:gfn_to_rmap+0x2b0/0x4d0 arch/x86/kvm/mmu/mmu.c:947 Code: <42> 80 3c 20 00 74 08 4c 89 ff e8 f1 79 a9 00 4c 89 fb 4d 8b 37 44 RSP: 0018:ffffc90000ffef98 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff888015b9f414 RCX: ffff888019669c40 RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001 RBP: 0000000000000001 R08: ffffffff811d9cdb R09: ffffed10065a6002 R10: ffffed10065a6002 R11: 0000000000000000 R12: dffffc0000000000 R13: 0000000000000003 R14: 0000000000000001 R15: 0000000000000000 FS: 000000000124b300(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000000028e31000 CR4: 00000000001526e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: rmap_add arch/x86/kvm/mmu/mmu.c:965 [inline] mmu_set_spte+0x862/0xe60 arch/x86/kvm/mmu/mmu.c:2604 __direct_map arch/x86/kvm/mmu/mmu.c:2862 [inline] direct_page_fault+0x1f74/0x2b70 arch/x86/kvm/mmu/mmu.c:3769 kvm_mmu_do_page_fault arch/x86/kvm/mmu.h:124 [inline] kvm_mmu_page_fault+0x199/0x1440 arch/x86/kvm/mmu/mmu.c:5065 vmx_handle_exit+0x26/0x160 arch/x86/kvm/vmx/vmx.c:6122 vcpu_enter_guest+0x3bdd/0x9630 arch/x86/kvm/x86.c:9428 vcpu_run+0x416/0xc20 arch/x86/kvm/x86.c:9494 kvm_arch_vcpu_ioctl_run+0x4e8/0xa40 arch/x86/kvm/x86.c:9722 kvm_vcpu_ioctl+0x70f/0xbb0 arch/x86/kvm/../../../virt/kvm/kvm_main.c:3460 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:1069 [inline] __se_sys_ioctl+0xfb/0x170 fs/ioctl.c:1055 do_syscall_64+0x3f/0xb0 arch/x86/entry/common.c:47 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x440ce9 Cc: stable@vger.kernel.org Reported-by: syzbot+fb0b6a7e8713aeb0319c@syzkaller.appspotmail.com Fixes: 9ec19493fb86 ("KVM: x86: clear SMM flags before loading state while leaving SMM") Signed-off-by: Sean Christopherson Message-Id: <20210609185619.992058-2-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 077cb8946f55909896dfd5572bdc58434ac9af5d Author: Chiqijun Date: Mon May 24 17:44:07 2021 -0500 PCI: Work around Huawei Intelligent NIC VF FLR erratum commit ce00322c2365e1f7b0312f2f493539c833465d97 upstream. pcie_flr() starts a Function Level Reset (FLR), waits 100ms (the maximum time allowed for FLR completion by PCIe r5.0, sec 6.6.2), and waits for the FLR to complete. It assumes the FLR is complete when a config read returns valid data. When we do an FLR on several Huawei Intelligent NIC VFs at the same time, firmware on the NIC processes them serially. The VF may respond to config reads before the firmware has completed its reset processing. If we bind a driver to the VF (e.g., by assigning the VF to a virtual machine) in the interval between the successful config read and completion of the firmware reset processing, the NIC VF driver may fail to load. Prevent this driver failure by waiting for the NIC firmware to complete its reset processing. Not all NIC firmware supports this feature. [bhelgaas: commit log] Link: https://support.huawei.com/enterprise/en/doc/EDOC1100063073/87950645/vm-oss-occasionally-fail-to-load-the-in200-driver-when-the-vf-performs-flr Link: https://lore.kernel.org/r/20210414132301.1793-1-chiqijun@huawei.com Signed-off-by: Chiqijun Signed-off-by: Bjorn Helgaas Reviewed-by: Alex Williamson Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit ee1a9cfed28ac447e4eace36bd462e44a27acfb9 Author: Sriharsha Basavapatna Date: Fri May 21 21:13:17 2021 -0400 PCI: Add ACS quirk for Broadcom BCM57414 NIC commit db2f77e2bd99dbd2fb23ddde58f0fae392fe3338 upstream. The Broadcom BCM57414 NIC may be a multi-function device. While it does not advertise an ACS capability, peer-to-peer transactions are not possible between the individual functions, so it is safe to treat them as fully isolated. Add an ACS quirk for this device so the functions can be in independent IOMMU groups and attached individually to userspace applications using VFIO. [bhelgaas: commit log] Link: https://lore.kernel.org/r/1621645997-16251-1-git-send-email-michael.chan@broadcom.com Signed-off-by: Sriharsha Basavapatna Signed-off-by: Michael Chan Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 1a1dbc4473974867fe8c5f195c17b341c8e82867 Author: Pali Rohár Date: Tue Jun 8 22:36:55 2021 +0200 PCI: aardvark: Fix kernel panic during PIO transfer commit f18139966d072dab8e4398c95ce955a9742e04f7 upstream. Trying to start a new PIO transfer by writing value 0 in PIO_START register when previous transfer has not yet completed (which is indicated by value 1 in PIO_START) causes an External Abort on CPU, which results in kernel panic: SError Interrupt on CPU0, code 0xbf000002 -- SError Kernel panic - not syncing: Asynchronous SError Interrupt To prevent kernel panic, it is required to reject a new PIO transfer when previous one has not finished yet. If previous PIO transfer is not finished yet, the kernel may issue a new PIO request only if the previous PIO transfer timed out. In the past the root cause of this issue was incorrectly identified (as it often happens during link retraining or after link down event) and special hack was implemented in Trusted Firmware to catch all SError events in EL3, to ignore errors with code 0xbf000002 and not forwarding any other errors to kernel and instead throw panic from EL3 Trusted Firmware handler. Links to discussion and patches about this issue: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=3c7dcdac5c50 https://lore.kernel.org/linux-pci/20190316161243.29517-1-repk@triplefau.lt/ https://lore.kernel.org/linux-pci/971be151d24312cc533989a64bd454b4@www.loen.fr/ https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1541 But the real cause was the fact that during link retraining or after link down event the PIO transfer may take longer time, up to the 1.44s until it times out. This increased probability that a new PIO transfer would be issued by kernel while previous one has not finished yet. After applying this change into the kernel, it is possible to revert the mentioned TF-A hack and SError events do not have to be caught in TF-A EL3. Link: https://lore.kernel.org/r/20210608203655.31228-1-pali@kernel.org Signed-off-by: Pali Rohár Signed-off-by: Lorenzo Pieralisi Signed-off-by: Bjorn Helgaas Reviewed-by: Marek Behún Cc: stable@vger.kernel.org # 7fbcb5da811b ("PCI: aardvark: Don't rely on jiffies while holding spinlock") Signed-off-by: Greg Kroah-Hartman commit dac77a14fa2740d7d4d9df16164689a8dc3ce175 Author: Shanker Donthineni Date: Tue Jun 8 11:18:56 2021 +0530 PCI: Mark some NVIDIA GPUs to avoid bus reset commit 4c207e7121fa92b66bf1896bf8ccb9edfb0f9731 upstream. Some NVIDIA GPU devices do not work with SBR. Triggering SBR leaves the device inoperable for the current system boot. It requires a system hard-reboot to get the GPU device back to normal operating condition post-SBR. For the affected devices, enable NO_BUS_RESET quirk to avoid the issue. This issue will be fixed in the next generation of hardware. Link: https://lore.kernel.org/r/20210608054857.18963-8-ameynarkhede03@gmail.com Signed-off-by: Shanker Donthineni Signed-off-by: Bjorn Helgaas Reviewed-by: Sinan Kaya Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 1e460ddf5be1dae1f2b4c46b5a16b0f32bec4e1d Author: Antti Järvinen Date: Mon Mar 15 10:26:06 2021 +0000 PCI: Mark TI C667X to avoid bus reset commit b5cf198e74a91073d12839a3e2db99994a39995d upstream. Some TI KeyStone C667X devices do not support bus/hot reset. The PCIESS automatically disables LTSSM when Secondary Bus Reset is received and device stops working. Prevent bus reset for these devices. With this change, the device can be assigned to VMs with VFIO, but it will leak state between VMs. Reference: https://e2e.ti.com/support/processors/f/791/t/954382 Link: https://lore.kernel.org/r/20210315102606.17153-1-antti.jarvinen@gmail.com Signed-off-by: Antti Järvinen Signed-off-by: Bjorn Helgaas Reviewed-by: Kishon Vijay Abraham I Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit c9fd0ab39f0ae4143f6d57ed8a6c3416d772e408 Author: Steven Rostedt (VMware) Date: Thu Jun 17 17:12:35 2021 -0400 tracing: Do no increment trace_clock_global() by one commit 89529d8b8f8daf92d9979382b8d2eb39966846ea upstream. The trace_clock_global() tries to make sure the events between CPUs is somewhat in order. A global value is used and updated by the latest read of a clock. If one CPU is ahead by a little, and is read by another CPU, a lock is taken, and if the timestamp of the other CPU is behind, it will simply use the other CPUs timestamp. The lock is also only taken with a "trylock" due to tracing, and strange recursions can happen. The lock is not taken at all in NMI context. In the case where the lock is not able to be taken, the non synced timestamp is returned. But it will not be less than the saved global timestamp. The problem arises because when the time goes "backwards" the time returned is the saved timestamp plus 1. If the lock is not taken, and the plus one to the timestamp is returned, there's a small race that can cause the time to go backwards! CPU0 CPU1 ---- ---- trace_clock_global() { ts = clock() [ 1000 ] trylock(clock_lock) [ success ] global_ts = ts; [ 1000 ] trace_clock_global() { ts = clock() [ 999 ] if (ts < global_ts) ts = global_ts + 1 [ 1001 ] trylock(clock_lock) [ fail ] return ts [ 1001] } unlock(clock_lock); return ts; [ 1000 ] } trace_clock_global() { ts = clock() [ 1000 ] if (ts < global_ts) [ false 1000 == 1000 ] trylock(clock_lock) [ success ] global_ts = ts; [ 1000 ] unlock(clock_lock) return ts; [ 1000 ] } The above case shows to reads of trace_clock_global() on the same CPU, but the second read returns one less than the first read. That is, time when backwards, and this is not what is allowed by trace_clock_global(). This was triggered by heavy tracing and the ring buffer checker that tests for the clock going backwards: Ring buffer clock went backwards: 20613921464 -> 20613921463 ------------[ cut here ]------------ WARNING: CPU: 2 PID: 0 at kernel/trace/ring_buffer.c:3412 check_buffer+0x1b9/0x1c0 Modules linked in: [..] [CPU: 2]TIME DOES NOT MATCH expected:20620711698 actual:20620711697 delta:6790234 before:20613921463 after:20613921463 [20613915818] PAGE TIME STAMP [20613915818] delta:0 [20613915819] delta:1 [20613916035] delta:216 [20613916465] delta:430 [20613916575] delta:110 [20613916749] delta:174 [20613917248] delta:499 [20613917333] delta:85 [20613917775] delta:442 [20613917921] delta:146 [20613918321] delta:400 [20613918568] delta:247 [20613918768] delta:200 [20613919306] delta:538 [20613919353] delta:47 [20613919980] delta:627 [20613920296] delta:316 [20613920571] delta:275 [20613920862] delta:291 [20613921152] delta:290 [20613921464] delta:312 [20613921464] delta:0 TIME EXTEND [20613921464] delta:0 This happened more than once, and always for an off by one result. It also started happening after commit aafe104aa9096 was added. Cc: stable@vger.kernel.org Fixes: aafe104aa9096 ("tracing: Restructure trace_clock_global() to never block") Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit b313bd944ddd419f69a3c32ccac77c1883dc4aa7 Author: Steven Rostedt (VMware) Date: Thu Jun 17 14:32:34 2021 -0400 tracing: Do not stop recording comms if the trace file is being read commit 4fdd595e4f9a1ff6d93ec702eaecae451cfc6591 upstream. A while ago, when the "trace" file was opened, tracing was stopped, and code was added to stop recording the comms to saved_cmdlines, for mapping of the pids to the task name. Code has been added that only records the comm if a trace event occurred, and there's no reason to not trace it if the trace file is opened. Cc: stable@vger.kernel.org Fixes: 7ffbd48d5cab2 ("tracing: Cache comms only after an event occurred") Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit adb3849ed8d52af288ea3d384ec3fd00163a94e7 Author: Steven Rostedt (VMware) Date: Thu Jun 17 13:47:25 2021 -0400 tracing: Do not stop recording cmdlines when tracing is off commit 85550c83da421fb12dc1816c45012e1e638d2b38 upstream. The saved_cmdlines is used to map pids to the task name, such that the output of the tracing does not just show pids, but also gives a human readable name for the task. If the name is not mapped, the output looks like this: <...>-1316 [005] ...2 132.044039: ... Instead of this: gnome-shell-1316 [005] ...2 132.044039: ... The names are updated when tracing is running, but are skipped if tracing is stopped. Unfortunately, this stops the recording of the names if the top level tracer is stopped, and not if there's other tracers active. The recording of a name only happens when a new event is written into a ring buffer, so there is no need to test if tracing is on or not. If tracing is off, then no event is written and no need to test if tracing is off or not. Remove the check, as it hides the names of tasks for events in the instance buffers. Cc: stable@vger.kernel.org Fixes: 7ffbd48d5cab2 ("tracing: Cache comms only after an event occurred") Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 1a91fafa3edcda7f05ffe60aa1ef7fb4f05f406b Author: Breno Lima Date: Mon Jun 14 13:50:13 2021 -0400 usb: chipidea: imx: Fix Battery Charger 1.2 CDP detection commit c6d580d96f140596d69220f60ce0cfbea4ee5c0f upstream. i.MX8MM cannot detect certain CDP USB HUBs. usbmisc_imx.c driver is not following CDP timing requirements defined by USB BC 1.2 specification and section 3.2.4 Detection Timing CDP. During Primary Detection the i.MX device should turn on VDP_SRC and IDM_SINK for a minimum of 40ms (TVDPSRC_ON). After a time of TVDPSRC_ON, the i.MX is allowed to check the status of the D- line. Current implementation is waiting between 1ms and 2ms, and certain BC 1.2 complaint USB HUBs cannot be detected. Increase delay to 40ms allowing enough time for primary detection. During secondary detection the i.MX is required to disable VDP_SRC and IDM_SNK, and enable VDM_SRC and IDP_SINK for at least 40ms (TVDMSRC_ON). Current implementation is not disabling VDP_SRC and IDM_SNK, introduce disable sequence in imx7d_charger_secondary_detection() function. VDM_SRC and IDP_SINK should be enabled for at least 40ms (TVDMSRC_ON). Increase delay allowing enough time for detection. Cc: Fixes: 746f316b753a ("usb: chipidea: introduce imx7d USB charger detection") Signed-off-by: Breno Lima Signed-off-by: Jun Li Link: https://lore.kernel.org/r/20210614175013.495808-1-breno.lima@nxp.com Signed-off-by: Peter Chen Signed-off-by: Greg Kroah-Hartman commit 576996b64e4d2d47865a1cf1efcdb02802aebd96 Author: Andrew Lunn Date: Mon Jun 14 17:55:23 2021 +0200 usb: core: hub: Disable autosuspend for Cypress CY7C65632 commit a7d8d1c7a7f73e780aa9ae74926ae5985b2f895f upstream. The Cypress CY7C65632 appears to have an issue with auto suspend and detecting devices, not too dissimilar to the SMSC 5534B hub. It is easiest to reproduce by connecting multiple mass storage devices to the hub at the same time. On a Lenovo Yoga, around 1 in 3 attempts result in the devices not being detected. It is however possible to make them appear using lsusb -v. Disabling autosuspend for this hub resolves the issue. Fixes: 1208f9e1d758 ("USB: hub: Fix the broken detection of USB3 device in SMSC hub") Cc: stable@vger.kernel.org Signed-off-by: Andrew Lunn Link: https://lore.kernel.org/r/20210614155524.2228800-1-andrew@lunn.ch Signed-off-by: Greg Kroah-Hartman commit 6bd3d80d1f019cefa7011056c54b323f1d8b8e83 Author: Pavel Skripkin Date: Thu Jun 10 00:58:33 2021 +0300 can: mcba_usb: fix memory leak in mcba_usb commit 91c02557174be7f72e46ed7311e3bea1939840b0 upstream. Syzbot reported memory leak in SocketCAN driver for Microchip CAN BUS Analyzer Tool. The problem was in unfreed usb_coherent. In mcba_usb_start() 20 coherent buffers are allocated and there is nothing, that frees them: 1) In callback function the urb is resubmitted and that's all 2) In disconnect function urbs are simply killed, but URB_FREE_BUFFER is not set (see mcba_usb_start) and this flag cannot be used with coherent buffers. Fail log: | [ 1354.053291][ T8413] mcba_usb 1-1:0.0 can0: device disconnected | [ 1367.059384][ T8420] kmemleak: 20 new suspected memory leaks (see /sys/kernel/debug/kmem) So, all allocated buffers should be freed with usb_free_coherent() explicitly NOTE: The same pattern for allocating and freeing coherent buffers is used in drivers/net/can/usb/kvaser_usb/kvaser_usb_core.c Fixes: 51f3baad7de9 ("can: mcba_usb: Add support for Microchip CAN BUS Analyzer") Link: https://lore.kernel.org/r/20210609215833.30393-1-paskripkin@gmail.com Cc: linux-stable Reported-and-tested-by: syzbot+57281c762a3922e14dfe@syzkaller.appspotmail.com Signed-off-by: Pavel Skripkin Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 509ab6bfdd0c76daebbad0f0af07da712116de22 Author: Oleksij Rempel Date: Fri May 21 13:57:20 2021 +0200 can: j1939: fix Use-after-Free, hold skb ref while in use commit 2030043e616cab40f510299f09b636285e0a3678 upstream. This patch fixes a Use-after-Free found by the syzbot. The problem is that a skb is taken from the per-session skb queue, without incrementing the ref count. This leads to a Use-after-Free if the skb is taken concurrently from the session queue due to a CTS. Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol") Link: https://lore.kernel.org/r/20210521115720.7533-1-o.rempel@pengutronix.de Cc: Hillf Danton Cc: linux-stable Reported-by: syzbot+220c1a29987a9a490903@syzkaller.appspotmail.com Reported-by: syzbot+45199c1b73b4013525cf@syzkaller.appspotmail.com Signed-off-by: Oleksij Rempel Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 0cf4b377907f4b768f128a133dc88dc015f6155a Author: Tetsuo Handa Date: Sat Jun 5 19:26:35 2021 +0900 can: bcm/raw/isotp: use per module netdevice notifier commit 8d0caedb759683041d9db82069937525999ada53 upstream. syzbot is reporting hung task at register_netdevice_notifier() [1] and unregister_netdevice_notifier() [2], for cleanup_net() might perform time consuming operations while CAN driver's raw/bcm/isotp modules are calling {register,unregister}_netdevice_notifier() on each socket. Change raw/bcm/isotp modules to call register_netdevice_notifier() from module's __init function and call unregister_netdevice_notifier() from module's __exit function, as with gw/j1939 modules are doing. Link: https://syzkaller.appspot.com/bug?id=391b9498827788b3cc6830226d4ff5be87107c30 [1] Link: https://syzkaller.appspot.com/bug?id=1724d278c83ca6e6df100a2e320c10d991cf2bce [2] Link: https://lore.kernel.org/r/54a5f451-05ed-f977-8534-79e7aa2bcc8f@i-love.sakura.ne.jp Cc: linux-stable Reported-by: syzbot Reported-by: syzbot Reviewed-by: Kirill Tkhai Tested-by: syzbot Tested-by: Oliver Hartkopp Signed-off-by: Tetsuo Handa Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit acb755be1f7adb204dcedc4d3b204ef098628623 Author: Norbert Slusarek Date: Sat Jun 12 22:18:54 2021 +0200 can: bcm: fix infoleak in struct bcm_msg_head commit 5e87ddbe3942e27e939bdc02deb8579b0cbd8ecc upstream. On 64-bit systems, struct bcm_msg_head has an added padding of 4 bytes between struct members count and ival1. Even though all struct members are initialized, the 4-byte hole will contain data from the kernel stack. This patch zeroes out struct bcm_msg_head before usage, preventing infoleaks to userspace. Fixes: ffd980f976e7 ("[CAN]: Add broadcast manager (bcm) protocol") Link: https://lore.kernel.org/r/trinity-7c1b2e82-e34f-4885-8060-2cd7a13769ce-1623532166177@3c-app-gmx-bs52 Cc: linux-stable Signed-off-by: Norbert Slusarek Acked-by: Oliver Hartkopp Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 8c82c52d1de931532200b447df8b4fc92129cfd9 Author: Daniel Borkmann Date: Fri May 28 13:47:27 2021 +0000 bpf: Do not mark insn as seen under speculative path verification [ Upstream commit fe9a5ca7e370e613a9a75a13008a3845ea759d6e ] ... in such circumstances, we do not want to mark the instruction as seen given the goal is still to jmp-1 rewrite/sanitize dead code, if it is not reachable from the non-speculative path verification. We do however want to verify it for safety regardless. With the patch as-is all the insns that have been marked as seen before the patch will also be marked as seen after the patch (just with a potentially different non-zero count). An upcoming patch will also verify paths that are unreachable in the non-speculative domain, hence this extension is needed. Signed-off-by: Daniel Borkmann Reviewed-by: John Fastabend Reviewed-by: Benedict Schlueter Reviewed-by: Piotr Krysiuk Acked-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit e9d271731d21647f8f9e9a261582cf47b868589a Author: Daniel Borkmann Date: Fri May 28 13:03:30 2021 +0000 bpf: Inherit expanded/patched seen count from old aux data [ Upstream commit d203b0fd863a2261e5d00b97f3d060c4c2a6db71 ] Instead of relying on current env->pass_cnt, use the seen count from the old aux data in adjust_insn_aux_data(), and expand it to the new range of patched instructions. This change is valid given we always expand 1:n with n>=1, so what applies to the old/original instruction needs to apply for the replacement as well. Not relying on env->pass_cnt is a prerequisite for a later change where we want to avoid marking an instruction seen when verified under speculative execution path. Signed-off-by: Daniel Borkmann Reviewed-by: John Fastabend Reviewed-by: Benedict Schlueter Reviewed-by: Piotr Krysiuk Acked-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit ed423d80bb9a19a80620d758ace6a28f69a0f1e0 Author: Marc Zyngier Date: Thu Jun 10 15:13:46 2021 +0100 irqchip/gic-v3: Workaround inconsistent PMR setting on NMI entry [ Upstream commit 382e6e177bc1c02473e56591fe5083ae1e4904f6 ] The arm64 entry code suffers from an annoying issue on taking a NMI, as it sets PMR to a value that actually allows IRQs to be acknowledged. This is done for consistency with other parts of the code, and is in the process of being fixed. This shouldn't be a problem, as we are not enabling interrupts whilst in NMI context. However, in the infortunate scenario that we took a spurious NMI (retired before the read of IAR) *and* that there is an IRQ pending at the same time, we'll ack the IRQ in NMI context. Too bad. In order to avoid deadlocks while running something like perf, teach the GICv3 driver about this situation: if we were in a context where no interrupt should have fired, transiently set PMR to a value that only allows NMIs before acking the pending interrupt, and restore the original value after that. This papers over the core issue for the time being, and makes NMIs great again. Sort of. Fixes: 4d6a38da8e79e94c ("arm64: entry: always set GIC_PRIO_PSR_I_SET during entry") Co-developed-by: Mark Rutland Signed-off-by: Mark Rutland Signed-off-by: Marc Zyngier Reviewed-by: Mark Rutland Link: https://lore.kernel.org/lkml/20210610145731.1350460-1-maz@kernel.org Signed-off-by: Sasha Levin commit 103c4a08baec6723cf2d4999c873a1634f8d6bc0 Author: Feng Tang Date: Fri Jun 11 09:54:42 2021 +0800 mm: relocate 'write_protect_seq' in struct mm_struct [ Upstream commit 2e3025434a6ba090c85871a1d4080ff784109e1f ] 0day robot reported a 9.2% regression for will-it-scale mmap1 test case[1], caused by commit 57efa1fe5957 ("mm/gup: prevent gup_fast from racing with COW during fork"). Further debug shows the regression is due to that commit changes the offset of hot fields 'mmap_lock' inside structure 'mm_struct', thus some cache alignment changes. From the perf data, the contention for 'mmap_lock' is very severe and takes around 95% cpu cycles, and it is a rw_semaphore struct rw_semaphore { atomic_long_t count; /* 8 bytes */ atomic_long_t owner; /* 8 bytes */ struct optimistic_spin_queue osq; /* spinner MCS lock */ ... Before commit 57efa1fe5957 adds the 'write_protect_seq', it happens to have a very optimal cache alignment layout, as Linus explained: "and before the addition of the 'write_protect_seq' field, the mmap_sem was at offset 120 in 'struct mm_struct'. Which meant that count and owner were in two different cachelines, and then when you have contention and spend time in rwsem_down_write_slowpath(), this is probably *exactly* the kind of layout you want. Because first the rwsem_write_trylock() will do a cmpxchg on the first cacheline (for the optimistic fast-path), and then in the case of contention, rwsem_down_write_slowpath() will just access the second cacheline. Which is probably just optimal for a load that spends a lot of time contended - new waiters touch that first cacheline, and then they queue themselves up on the second cacheline." After the commit, the rw_semaphore is at offset 128, which means the 'count' and 'owner' fields are now in the same cacheline, and causes more cache bouncing. Currently there are 3 "#ifdef CONFIG_XXX" before 'mmap_lock' which will affect its offset: CONFIG_MMU CONFIG_MEMBARRIER CONFIG_HAVE_ARCH_COMPAT_MMAP_BASES The layout above is on 64 bits system with 0day's default kernel config (similar to RHEL-8.3's config), in which all these 3 options are 'y'. And the layout can vary with different kernel configs. Relayouting a structure is usually a double-edged sword, as sometimes it can helps one case, but hurt other cases. For this case, one solution is, as the newly added 'write_protect_seq' is a 4 bytes long seqcount_t (when CONFIG_DEBUG_LOCK_ALLOC=n), placing it into an existing 4 bytes hole in 'mm_struct' will not change other fields' alignment, while restoring the regression. Link: https://lore.kernel.org/lkml/20210525031636.GB7744@xsang-OptiPlex-9020/ [1] Reported-by: kernel test robot Signed-off-by: Feng Tang Reviewed-by: John Hubbard Reviewed-by: Jason Gunthorpe Cc: Peter Xu Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit a87abba03a7a9a4aa282d6b5fe796ffac431255a Author: Riwen Lu Date: Fri Jun 4 11:09:59 2021 +0800 hwmon: (scpi-hwmon) shows the negative temperature properly [ Upstream commit 78d13552346289bad4a9bf8eabb5eec5e5a321a5 ] The scpi hwmon shows the sub-zero temperature in an unsigned integer, which would confuse the users when the machine works in low temperature environment. This shows the sub-zero temperature in an signed value and users can get it properly from sensors. Signed-off-by: Riwen Lu Tested-by: Xin Chen Link: https://lore.kernel.org/r/20210604030959.736379-1-luriwen@kylinos.cn Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 57b21ef118acfc76dd1a73c1240b3bc7a17c8786 Author: Chen Li Date: Fri Jun 4 16:43:02 2021 +0800 radeon: use memcpy_to/fromio for UVD fw upload [ Upstream commit ab8363d3875a83f4901eb1cc00ce8afd24de6c85 ] I met a gpu addr bug recently and the kernel log tells me the pc is memcpy/memset and link register is radeon_uvd_resume. As we know, in some architectures, optimized memcpy/memset may not work well on device memory. Trival memcpy_toio/memset_io can fix this problem. BTW, amdgpu has already done it in: commit ba0b2275a678 ("drm/amdgpu: use memcpy_to/fromio for UVD fw upload"), that's why it has no this issue on the same gpu and platform. Signed-off-by: Chen Li Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 3e4b0fbb72939bb45246642f86c24d3b9cce99b1 Author: Srinivasa Rao Mandadapu Date: Fri Jun 4 23:45:45 2021 +0800 ASoC: qcom: lpass-cpu: Fix pop noise during audio capture begin [ Upstream commit c8a4556d98510ca05bad8d02265a4918b03a8c0b ] This patch fixes PoP noise of around 15ms observed during audio capture begin. Enables BCLK and LRCLK in snd_soc_dai_ops prepare call for introducing some delay before capture start. (am from https://patchwork.kernel.org/patch/12276369/) (also found at https://lore.kernel.org/r/20210524142114.18676-1-srivasam@codeaurora.org) Co-developed-by: Judy Hsiao Signed-off-by: Judy Hsiao Signed-off-by: Srinivasa Rao Mandadapu Reviewed-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20210604154545.1198337-1-judyhsiao@chromium.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 360609fc8b06e8b1d5925ec4d99d752bbbd2d9dd Author: Saravana Kannan Date: Mon Jun 7 10:58:36 2021 +0200 drm/sun4i: dw-hdmi: Make HDMI PHY into a platform device [ Upstream commit 9bf3797796f570b34438235a6a537df85832bdad ] On sunxi boards that use HDMI output, HDMI device probe keeps being avoided indefinitely with these repeated messages in dmesg: platform 1ee0000.hdmi: probe deferral - supplier 1ef0000.hdmi-phy not ready There's a fwnode_link being created with fw_devlink=on between hdmi and hdmi-phy nodes, because both nodes have 'compatible' property set. Fw_devlink code assumes that nodes that have compatible property set will also have a device associated with them by some driver eventually. This is not the case with the current sun8i-hdmi driver. This commit makes sun8i-hdmi-phy into a proper platform device and fixes the display pipeline probe on sunxi boards that use HDMI. More context: https://lkml.org/lkml/2021/5/16/203 Signed-off-by: Saravana Kannan Signed-off-by: Ondrej Jirman Tested-by: Andre Przywara Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20210607085836.2827429-1-megous@megous.com Signed-off-by: Sasha Levin commit 5bd6bcb3532d91396f770584428d2b88945f671e Author: Sergio Paracuellos Date: Fri Jun 4 07:53:37 2021 +0200 pinctrl: ralink: rt2880: avoid to error in calls is pin is already enabled [ Upstream commit eb367d875f94a228c17c8538e3f2efcf2eb07ead ] In 'rt2880_pmx_group_enable' driver is printing an error and returning -EBUSY if a pin has been already enabled. This begets anoying messages in the caller when this happens like the following: rt2880-pinmux pinctrl: pcie is already enabled mt7621-pci 1e140000.pcie: Error applying setting, reverse things back To avoid this just print the already enabled message in the pinctrl driver and return 0 instead to not confuse the user with a real bad problem. Signed-off-by: Sergio Paracuellos Link: https://lore.kernel.org/r/20210604055337.20407-1-sergio.paracuellos@gmail.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 6d0dc1b34c0235c069055ee7bc808870e5815346 Author: Oder Chiou Date: Fri Jun 4 14:31:50 2021 +0800 ASoC: rt5682: Fix the fast discharge for headset unplugging in soundwire mode [ Upstream commit 49783c6f4a4f49836b5a109ae0daf2f90b0d7713 ] Based on ("5a15cd7fce20b1fd4aece6a0240e2b58cd6a225d"), the setting also should be set in soundwire mode. Signed-off-by: Oder Chiou Link: https://lore.kernel.org/r/20210604063150.29925-1-oder_chiou@realtek.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit ba8a26a7ce8617f9f3d6230de34b2302df086b41 Author: Axel Lin Date: Thu Jun 3 17:49:44 2021 +0800 regulator: rt4801: Fix NULL pointer dereference if priv->enable_gpios is NULL [ Upstream commit cb2381cbecb81a8893b2d1e1af29bc2e5531df27 ] devm_gpiod_get_array_optional may return NULL if no GPIO was assigned. Signed-off-by: Axel Lin Link: https://lore.kernel.org/r/20210603094944.1114156-1-axel.lin@ingics.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 2f8f0e97cebb6c2b7cffd5b7c08331535680ae40 Author: Patrice Chotard Date: Thu Jun 3 09:34:21 2021 +0200 spi: stm32-qspi: Always wait BUSY bit to be cleared in stm32_qspi_wait_cmd() [ Upstream commit d38fa9a155b2829b7e2cfcf8a4171b6dd3672808 ] In U-boot side, an issue has been encountered when QSPI source clock is running at low frequency (24 MHz for example), waiting for TCF bit to be set didn't ensure that all data has been send out the FIFO, we should also wait that BUSY bit is cleared. To prevent similar issue in kernel driver, we implement similar behavior by always waiting BUSY bit to be cleared. Signed-off-by: Patrice Chotard Link: https://lore.kernel.org/r/20210603073421.8441-1-patrice.chotard@foss.st.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit e03c8b35161b2e8b30aeb50fa659fc3cfeee419c Author: Richard Weinberger Date: Sun May 30 22:34:46 2021 +0200 ASoC: tas2562: Fix TDM_CFG0_SAMPRATE values [ Upstream commit 8bef925e37bdc9b6554b85eda16ced9a8e3c135f ] TAS2562_TDM_CFG0_SAMPRATE_MASK starts at bit 1, not 0. So all values need to be left shifted by 1. Signed-off-by: Richard Weinberger Link: https://lore.kernel.org/r/20210530203446.19022-1-richard@nod.at Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 813ff24f1d08cb4b4605fe222bb104a8dbdfd7f5 Author: Vincent Guittot Date: Tue Jun 1 10:58:32 2021 +0200 sched/pelt: Ensure that *_sum is always synced with *_avg [ Upstream commit fcf6631f3736985ec89bdd76392d3c7bfb60119f ] Rounding in PELT calculation happening when entities are attached/detached of a cfs_rq can result into situations where util/runnable_avg is not null but util/runnable_sum is. This is normally not possible so we need to ensure that util/runnable_sum stays synced with util/runnable_avg. detach_entity_load_avg() is the last place where we don't sync util/runnable_sum with util/runnbale_avg when moving some sched_entities Signed-off-by: Vincent Guittot Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20210601085832.12626-1-vincent.guittot@linaro.org Signed-off-by: Sasha Levin commit f6d28f0e36e93570f2843abef9969681860c38e7 Author: zpershuai Date: Thu May 27 18:20:57 2021 +0800 spi: spi-zynq-qspi: Fix some wrong goto jumps & missing error code [ Upstream commit f131767eefc47de2f8afb7950cdea78397997d66 ] In zynq_qspi_probe function, when enable the device clock is done, the return of all the functions should goto the clk_dis_all label. If num_cs is not right then this should return a negative error code but currently it returns success. Signed-off-by: zpershuai Link: https://lore.kernel.org/r/1622110857-21812-1-git-send-email-zpershuai@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 0ea21221dd5a914205f206835e0d43f8ca23d494 Author: ChiYuan Huang Date: Tue Jun 1 18:09:15 2021 +0800 regulator: rtmv20: Fix to make regcache value first reading back from HW [ Upstream commit 46639a5e684edd0b80ae9dff220f193feb356277 ] - Fix to make regcache value first reading back from HW. Signed-off-by: ChiYuan Huang Link: https://lore.kernel.org/r/1622542155-6373-1-git-send-email-u0084500@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 3c5064cd297976e5ba555854c5dea8a272ec6544 Author: Nicolas Cavallari Date: Thu May 27 18:34:09 2021 +0200 ASoC: fsl-asoc-card: Set .owner attribute when registering card. [ Upstream commit a8437f05384cb472518ec21bf4fffbe8f0a47378 ] Otherwise, when compiled as module, a WARN_ON is triggered: WARNING: CPU: 0 PID: 5 at sound/core/init.c:208 snd_card_new+0x310/0x39c [snd] [...] CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.10.39 #1 Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) Workqueue: events deferred_probe_work_func [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [] (show_stack) from [] (dump_stack+0xdc/0x104) [] (dump_stack) from [] (__warn+0xd8/0x114) [] (__warn) from [] (warn_slowpath_fmt+0x5c/0xc4) [] (warn_slowpath_fmt) from [] (snd_card_new+0x310/0x39c [snd]) [] (snd_card_new [snd]) from [] (snd_soc_bind_card+0x334/0x9c4 [snd_soc_core]) [] (snd_soc_bind_card [snd_soc_core]) from [] (devm_snd_soc_register_card+0x30/0x6c [snd_soc_core]) [] (devm_snd_soc_register_card [snd_soc_core]) from [] (fsl_asoc_card_probe+0x550/0xcc8 [snd_soc_fsl_asoc_card]) [] (fsl_asoc_card_probe [snd_soc_fsl_asoc_card]) from [] (platform_drv_probe+0x48/0x98) [...] Signed-off-by: Nicolas Cavallari Acked-by: Shengjiu Wang Link: https://lore.kernel.org/r/20210527163409.22049-1-nicolas.cavallari@green-communications.fr Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 9a17907946232d01aa2ec109da5f93b8d31dd425 Author: Tiezhu Yang Date: Wed May 19 18:37:39 2021 +0800 phy: phy-mtk-tphy: Fix some resource leaks in mtk_phy_init() [ Upstream commit aaac9a1bd370338ce372669eb9a6059d16b929aa ] Use clk_disable_unprepare() in the error path of mtk_phy_init() to fix some resource leaks. Reported-by: kernel test robot Reported-by: Dan Carpenter Signed-off-by: Tiezhu Yang Reviewed-by: Chunfeng Yun Link: https://lore.kernel.org/r/1621420659-15858-1-git-send-email-yangtiezhu@loongson.cn Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 02e245574887333959ece0d718cb70425045f6ff Author: Jack Yu Date: Thu May 27 01:06:51 2021 +0000 ASoC: rt5659: Fix the lost powers for the HDA header [ Upstream commit 6308c44ed6eeadf65c0a7ba68d609773ed860fbb ] The power of "LDO2", "MICBIAS1" and "Mic Det Power" were powered off after the DAPM widgets were added, and these powers were set by the JD settings "RT5659_JD_HDA_HEADER" in the probe function. In the codec probe function, these powers were ignored to prevent them controlled by DAPM. Signed-off-by: Oder Chiou Signed-off-by: Jack Yu Message-Id: <15fced51977b458798ca4eebf03dafb9@realtek.com> Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 3fb6c6acc1a77e9516c0514bf74767dfa982bf99 Author: Til Jasper Ullrich Date: Tue May 25 17:09:52 2021 +0200 platform/x86: thinkpad_acpi: Add X1 Carbon Gen 9 second fan support [ Upstream commit c0e0436cb4f6627146acdae8c77828f18db01151 ] The X1 Carbon Gen 9 uses two fans instead of one like the previous generation. This adds support for the second fan. It has been tested on my X1 Carbon Gen 9 (20XXS00100) and works fine. Signed-off-by: Til Jasper Ullrich Link: https://lore.kernel.org/r/20210525150950.14805-1-tju@tju.me Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin commit 0609c36696e7668d265c29ee88bad079201f700f Author: Axel Lin Date: Sun May 23 15:10:44 2021 +0800 regulator: bd70528: Fix off-by-one for buck123 .n_voltages setting [ Upstream commit 0514582a1a5b4ac1a3fd64792826d392d7ae9ddc ] The valid selectors for bd70528 bucks are 0 ~ 0xf, so the .n_voltages should be 16 (0x10). Use 0x10 to make it consistent with BD70528_LDO_VOLTS. Also remove redundant defines for BD70528_BUCK_VOLTS. Signed-off-by: Axel Lin Acked-by: Matti Vaittinen Link: https://lore.kernel.org/r/20210523071045.2168904-1-axel.lin@ingics.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 0ea923519a3fdd81ce9c69ddcbd60809657deb88 Author: Axel Lin Date: Wed May 12 15:58:24 2021 +0800 regulator: cros-ec: Fix error code in dev_err message [ Upstream commit 3d681804efcb6e5d8089a433402e19179347d7ae ] Show proper error code instead of 0. Signed-off-by: Axel Lin Link: https://lore.kernel.org/r/20210512075824.620580-1-axel.lin@ingics.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 95deeb29d831e2fae608439e243e7a520611e7ea Author: Pavel Skripkin Date: Fri Jun 18 16:49:02 2021 +0300 net: ethernet: fix potential use-after-free in ec_bhf_remove [ Upstream commit 9cca0c2d70149160407bda9a9446ce0c29b6e6c6 ] static void ec_bhf_remove(struct pci_dev *dev) { ... struct ec_bhf_priv *priv = netdev_priv(net_dev); unregister_netdev(net_dev); free_netdev(net_dev); pci_iounmap(dev, priv->dma_io); pci_iounmap(dev, priv->io); ... } priv is netdev private data, but it is used after free_netdev(). It can cause use-after-free when accessing priv pointer. So, fix it by moving free_netdev() after pci_iounmap() calls. Fixes: 6af55ff52b02 ("Driver for Beckhoff CX5020 EtherCAT master module.") Signed-off-by: Pavel Skripkin Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8c0c2d97ad283680d871fd222e97a3c60eae44c1 Author: Toke Høiland-Jørgensen Date: Fri Jun 18 13:04:35 2021 +0200 icmp: don't send out ICMP messages with a source address of 0.0.0.0 [ Upstream commit 321827477360934dc040e9d3c626bf1de6c3ab3c ] When constructing ICMP response messages, the kernel will try to pick a suitable source address for the outgoing packet. However, if no IPv4 addresses are configured on the system at all, this will fail and we end up producing an ICMP message with a source address of 0.0.0.0. This can happen on a box routing IPv4 traffic via v6 nexthops, for instance. Since 0.0.0.0 is not generally routable on the internet, there's a good chance that such ICMP messages will never make it back to the sender of the original packet that the ICMP message was sent in response to. This, in turn, can create connectivity and PMTUd problems for senders. Fortunately, RFC7600 reserves a dummy address to be used as a source for ICMP messages (192.0.0.8/32), so let's teach the kernel to substitute that address as a last resort if the regular source address selection procedure fails. Below is a quick example reproducing this issue with network namespaces: ip netns add ns0 ip l add type veth peer netns ns0 ip l set dev veth0 up ip a add 10.0.0.1/24 dev veth0 ip a add fc00:dead:cafe:42::1/64 dev veth0 ip r add 10.1.0.0/24 via inet6 fc00:dead:cafe:42::2 ip -n ns0 l set dev veth0 up ip -n ns0 a add fc00:dead:cafe:42::2/64 dev veth0 ip -n ns0 r add 10.0.0.0/24 via inet6 fc00:dead:cafe:42::1 ip netns exec ns0 sysctl -w net.ipv4.icmp_ratelimit=0 ip netns exec ns0 sysctl -w net.ipv4.ip_forward=1 tcpdump -tpni veth0 -c 2 icmp & ping -w 1 10.1.0.1 > /dev/null tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on veth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes IP 10.0.0.1 > 10.1.0.1: ICMP echo request, id 29, seq 1, length 64 IP 0.0.0.0 > 10.0.0.1: ICMP net 10.1.0.1 unreachable, length 92 2 packets captured 2 packets received by filter 0 packets dropped by kernel With this patch the above capture changes to: IP 10.0.0.1 > 10.1.0.1: ICMP echo request, id 31127, seq 1, length 64 IP 192.0.0.8 > 10.0.0.1: ICMP net 10.1.0.1 unreachable, length 92 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Juliusz Chroboczek Reviewed-by: David Ahern Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit c5d70dbc4d0b1dac909a7cb5a26b7c51fceacebe Author: Somnath Kotur Date: Fri Jun 18 02:07:27 2021 -0400 bnxt_en: Call bnxt_ethtool_free() in bnxt_init_one() error path [ Upstream commit 03400aaa69f916a376e11526cf591901a96a3a5c ] bnxt_ethtool_init() may have allocated some memory and we need to call bnxt_ethtool_free() to properly unwind if bnxt_init_one() fails. Fixes: 7c3809181468 ("bnxt_en: Refactor bnxt_init_one() and turn on TPA support on 57500 chips.") Signed-off-by: Somnath Kotur Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f8774be4dc117881c6145e446dc86ac2b7b5a6f5 Author: Rukhsana Ansari Date: Fri Jun 18 02:07:26 2021 -0400 bnxt_en: Fix TQM fastpath ring backing store computation [ Upstream commit c12e1643d2738bcd4e26252ce531878841dd3f38 ] TQM fastpath ring needs to be sized to store both the requester and responder side of RoCE QPs in TQM for supporting bi-directional tests. Fix bnxt_alloc_ctx_mem() to multiply the RoCE QPs by a factor of 2 when computing the number of entries for TQM fastpath ring. This fixes an RX pipeline stall issue when running bi-directional max RoCE QP tests. Fixes: c7dd7ab4b204 ("bnxt_en: Improve TQM ring context memory sizing formulas.") Signed-off-by: Rukhsana Ansari Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit acc9175541bf49c9048e2c7dd44eb7e11e5a250e Author: Michael Chan Date: Fri Jun 18 02:07:25 2021 -0400 bnxt_en: Rediscover PHY capabilities after firmware reset [ Upstream commit 0afd6a4e8028cc487c240b6cfe04094e45a306e4 ] There is a missing bnxt_probe_phy() call in bnxt_fw_init_one() to rediscover the PHY capabilities after a firmware reset. This can cause some PHY related functionalities to fail after a firmware reset. For example, in multi-host, the ability for any host to configure the PHY settings may be lost after a firmware reset. Fixes: ec5d31e3c15d ("bnxt_en: Handle firmware reset status during IF_UP.") Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit acc3589959757ed9d30bba38aa18161764ff4430 Author: Pavel Machek Date: Fri Jun 18 11:29:48 2021 +0200 cxgb4: fix wrong shift. [ Upstream commit 39eb028183bc7378bb6187067e20bf6d8c836407 ] While fixing coverity warning, commit dd2c79677375 introduced typo in shift value. Fix that. Signed-off-by: Pavel Machek (CIP) Fixes: dd2c79677375 ("cxgb4: Fix unintentional sign extension issues") Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 05b2b9f7d24b5663d9b47427fe1555bdafd3ea02 Author: Linyu Yuan Date: Thu Jun 17 07:32:32 2021 +0800 net: cdc_eem: fix tx fixup skb leak [ Upstream commit c3b26fdf1b32f91c7a3bc743384b4a298ab53ad7 ] when usbnet transmit a skb, eem fixup it in eem_tx_fixup(), if skb_copy_expand() failed, it return NULL, usbnet_start_xmit() will have no chance to free original skb. fix it by free orginal skb in eem_tx_fixup() first, then check skb clone status, if failed, return NULL to usbnet. Fixes: 9f722c0978b0 ("usbnet: CDC EEM support (v5)") Signed-off-by: Linyu Yuan Reviewed-by: Greg Kroah-Hartman Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 290b0b6432e2599021db0b8d6046f756d931c29f Author: Pavel Skripkin Date: Wed Jun 16 22:09:06 2021 +0300 net: hamradio: fix memory leak in mkiss_close [ Upstream commit 7edcc682301492380fbdd604b4516af5ae667a13 ] My local syzbot instance hit memory leak in mkiss_open()[1]. The problem was in missing free_netdev() in mkiss_close(). In mkiss_open() netdevice is allocated and then registered, but in mkiss_close() netdevice was only unregistered, but not freed. Fail log: BUG: memory leak unreferenced object 0xffff8880281ba000 (size 4096): comm "syz-executor.1", pid 11443, jiffies 4295046091 (age 17.660s) hex dump (first 32 bytes): 61 78 30 00 00 00 00 00 00 00 00 00 00 00 00 00 ax0............. 00 27 fa 2a 80 88 ff ff 00 00 00 00 00 00 00 00 .'.*............ backtrace: [] kvmalloc_node+0x61/0xf0 [] alloc_netdev_mqs+0x98/0xe80 [] mkiss_open+0xb2/0x6f0 [1] [] tty_ldisc_open+0x9b/0x110 [] tty_set_ldisc+0x2e8/0x670 [] tty_ioctl+0xda3/0x1440 [] __x64_sys_ioctl+0x193/0x200 [] do_syscall_64+0x3a/0xb0 [] entry_SYSCALL_64_after_hwframe+0x44/0xae BUG: memory leak unreferenced object 0xffff8880141a9a00 (size 96): comm "syz-executor.1", pid 11443, jiffies 4295046091 (age 17.660s) hex dump (first 32 bytes): e8 a2 1b 28 80 88 ff ff e8 a2 1b 28 80 88 ff ff ...(.......(.... 98 92 9c aa b0 40 02 00 00 00 00 00 00 00 00 00 .....@.......... backtrace: [] __hw_addr_create_ex+0x5b/0x310 [] __hw_addr_add_ex+0x1f8/0x2b0 [] dev_addr_init+0x10b/0x1f0 [] alloc_netdev_mqs+0x13b/0xe80 [] mkiss_open+0xb2/0x6f0 [1] [] tty_ldisc_open+0x9b/0x110 [] tty_set_ldisc+0x2e8/0x670 [] tty_ioctl+0xda3/0x1440 [] __x64_sys_ioctl+0x193/0x200 [] do_syscall_64+0x3a/0xb0 [] entry_SYSCALL_64_after_hwframe+0x44/0xae BUG: memory leak unreferenced object 0xffff8880219bfc00 (size 512): comm "syz-executor.1", pid 11443, jiffies 4295046091 (age 17.660s) hex dump (first 32 bytes): 00 a0 1b 28 80 88 ff ff 80 8f b1 8d ff ff ff ff ...(............ 80 8f b1 8d ff ff ff ff 00 00 00 00 00 00 00 00 ................ backtrace: [] kvmalloc_node+0x61/0xf0 [] alloc_netdev_mqs+0x777/0xe80 [] mkiss_open+0xb2/0x6f0 [1] [] tty_ldisc_open+0x9b/0x110 [] tty_set_ldisc+0x2e8/0x670 [] tty_ioctl+0xda3/0x1440 [] __x64_sys_ioctl+0x193/0x200 [] do_syscall_64+0x3a/0xb0 [] entry_SYSCALL_64_after_hwframe+0x44/0xae BUG: memory leak unreferenced object 0xffff888029b2b200 (size 256): comm "syz-executor.1", pid 11443, jiffies 4295046091 (age 17.660s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [] kvmalloc_node+0x61/0xf0 [] alloc_netdev_mqs+0x912/0xe80 [] mkiss_open+0xb2/0x6f0 [1] [] tty_ldisc_open+0x9b/0x110 [] tty_set_ldisc+0x2e8/0x670 [] tty_ioctl+0xda3/0x1440 [] __x64_sys_ioctl+0x193/0x200 [] do_syscall_64+0x3a/0xb0 [] entry_SYSCALL_64_after_hwframe+0x44/0xae Fixes: 815f62bf7427 ("[PATCH] SMP rewrite of mkiss") Signed-off-by: Pavel Skripkin Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 45bf43d8685ffce899493ced32176dee089edf01 Author: Christophe JAILLET Date: Wed Jun 16 20:43:37 2021 +0200 be2net: Fix an error handling path in 'be_probe()' [ Upstream commit c19c8c0e666f9259e2fc4d2fa4b9ff8e3b40ee5d ] If an error occurs after a 'pci_enable_pcie_error_reporting()' call, it must be undone by a corresponding 'pci_disable_pcie_error_reporting()' call, as already done in the remove function. Fixes: d6b6d9877878 ("be2net: use PCIe AER capability") Signed-off-by: Christophe JAILLET Acked-by: Somnath Kotur Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 327e626c39f3e152b0306b41708a51a5d471c165 Author: Aya Levin Date: Thu Jun 10 14:20:28 2021 +0300 net/mlx5: Reset mkey index on creation [ Upstream commit 0232fc2ddcf4ffe01069fd1aa07922652120f44a ] Reset only the index part of the mkey and keep the variant part. On devlink reload, driver recreates mkeys, so the mkey index may change. Trying to preserve the variant part of the mkey, driver mistakenly merged the mkey index with current value. In case of a devlink reload, current value of index part is dirty, so the index may be corrupted. Fixes: 54c62e13ad76 ("{IB,net}/mlx5: Setup mkey variant before mr create command invocation") Signed-off-by: Aya Levin Signed-off-by: Amir Tzin Reviewed-by: Tariq Toukan Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 38aafe678caa5b5a6444057291bad51b6bce1ac1 Author: Parav Pandit Date: Tue Jun 8 19:03:24 2021 +0300 net/mlx5: E-Switch, Allow setting GUID for host PF vport [ Upstream commit ca36fc4d77b35b8d142cf1ed0eae5ec2e071dc3c ] E-switch should be able to set the GUID of host PF vport. Currently it returns an error. This results in below error when user attempts to configure MAC address of the PF of an external controller. $ devlink port function set pci/0000:03:00.0/196608 \ hw_addr 00:00:00:11:22:33 mlx5_core 0000:03:00.0: mlx5_esw_set_vport_mac_locked:1876:(pid 6715):\ "Failed to set vport 0 node guid, err = -22. RDMA_CM will not function properly for this VF." Check for zero vport is no longer needed. Fixes: 330077d14de1 ("net/mlx5: E-switch, Supporting setting devlink port function mac address") Signed-off-by: Yuval Avnery Signed-off-by: Parav Pandit Reviewed-by: Bodong Wang Reviewed-by: Alaa Hleihel Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 601be24dba48dfa53bf2a3b8fd73f6af81cfa1f5 Author: Parav Pandit Date: Tue Jun 8 19:14:08 2021 +0300 net/mlx5: E-Switch, Read PF mac address [ Upstream commit bbc8222dc49db8d49add0f27bcac33f4b92193dc ] External controller PF's MAC address is not read from the device during vport setup. Fail to read this results in showing all zeros to user while the factory programmed MAC is a valid value. $ devlink port show eth1 -jp { "port": { "pci/0000:03:00.0/196608": { "type": "eth", "netdev": "eth1", "flavour": "pcipf", "controller": 1, "pfnum": 0, "splittable": false, "function": { "hw_addr": "00:00:00:00:00:00" } } } } Hence, read it when enabling a vport. After the fix, $ devlink port show eth1 -jp { "port": { "pci/0000:03:00.0/196608": { "type": "eth", "netdev": "eth1", "flavour": "pcipf", "controller": 1, "pfnum": 0, "splittable": false, "function": { "hw_addr": "98:03:9b:a0:60:11" } } } } Fixes: f099fde16db3 ("net/mlx5: E-switch, Support querying port function mac address") Signed-off-by: Bodong Wang Signed-off-by: Parav Pandit Reviewed-by: Alaa Hleihel Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 5f2ccc58a3529ee8ec798d5bbd867deb611f9d75 Author: Eric Dumazet Date: Wed Jun 16 07:47:15 2021 -0700 net/af_unix: fix a data-race in unix_dgram_sendmsg / unix_release_sock [ Upstream commit a494bd642d9120648b06bb7d28ce6d05f55a7819 ] While unix_may_send(sk, osk) is called while osk is locked, it appears unix_release_sock() can overwrite unix_peer() after this lock has been released, making KCSAN unhappy. Changing unix_release_sock() to access/change unix_peer() before lock is released should fix this issue. BUG: KCSAN: data-race in unix_dgram_sendmsg / unix_release_sock write to 0xffff88810465a338 of 8 bytes by task 20852 on cpu 1: unix_release_sock+0x4ed/0x6e0 net/unix/af_unix.c:558 unix_release+0x2f/0x50 net/unix/af_unix.c:859 __sock_release net/socket.c:599 [inline] sock_close+0x6c/0x150 net/socket.c:1258 __fput+0x25b/0x4e0 fs/file_table.c:280 ____fput+0x11/0x20 fs/file_table.c:313 task_work_run+0xae/0x130 kernel/task_work.c:164 tracehook_notify_resume include/linux/tracehook.h:189 [inline] exit_to_user_mode_loop kernel/entry/common.c:175 [inline] exit_to_user_mode_prepare+0x156/0x190 kernel/entry/common.c:209 __syscall_exit_to_user_mode_work kernel/entry/common.c:291 [inline] syscall_exit_to_user_mode+0x20/0x40 kernel/entry/common.c:302 do_syscall_64+0x56/0x90 arch/x86/entry/common.c:57 entry_SYSCALL_64_after_hwframe+0x44/0xae read to 0xffff88810465a338 of 8 bytes by task 20888 on cpu 0: unix_may_send net/unix/af_unix.c:189 [inline] unix_dgram_sendmsg+0x923/0x1610 net/unix/af_unix.c:1712 sock_sendmsg_nosec net/socket.c:654 [inline] sock_sendmsg net/socket.c:674 [inline] ____sys_sendmsg+0x360/0x4d0 net/socket.c:2350 ___sys_sendmsg net/socket.c:2404 [inline] __sys_sendmmsg+0x315/0x4b0 net/socket.c:2490 __do_sys_sendmmsg net/socket.c:2519 [inline] __se_sys_sendmmsg net/socket.c:2516 [inline] __x64_sys_sendmmsg+0x53/0x60 net/socket.c:2516 do_syscall_64+0x4a/0x90 arch/x86/entry/common.c:47 entry_SYSCALL_64_after_hwframe+0x44/0xae value changed: 0xffff888167905400 -> 0x0000000000000000 Reported by Kernel Concurrency Sanitizer on: CPU: 0 PID: 20888 Comm: syz-executor.0 Not tainted 5.13.0-rc5-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Eric Dumazet Reported-by: syzbot Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit ac31cc837cafb57a271babad8ccffbf733caa076 Author: Chengyang Fan Date: Wed Jun 16 17:59:25 2021 +0800 net: ipv4: fix memory leak in ip_mc_add1_src [ Upstream commit d8e2973029b8b2ce477b564824431f3385c77083 ] BUG: memory leak unreferenced object 0xffff888101bc4c00 (size 32): comm "syz-executor527", pid 360, jiffies 4294807421 (age 19.329s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 01 00 00 00 00 00 00 00 ac 14 14 bb 00 00 02 00 ................ backtrace: [<00000000f17c5244>] kmalloc include/linux/slab.h:558 [inline] [<00000000f17c5244>] kzalloc include/linux/slab.h:688 [inline] [<00000000f17c5244>] ip_mc_add1_src net/ipv4/igmp.c:1971 [inline] [<00000000f17c5244>] ip_mc_add_src+0x95f/0xdb0 net/ipv4/igmp.c:2095 [<000000001cb99709>] ip_mc_source+0x84c/0xea0 net/ipv4/igmp.c:2416 [<0000000052cf19ed>] do_ip_setsockopt net/ipv4/ip_sockglue.c:1294 [inline] [<0000000052cf19ed>] ip_setsockopt+0x114b/0x30c0 net/ipv4/ip_sockglue.c:1423 [<00000000477edfbc>] raw_setsockopt+0x13d/0x170 net/ipv4/raw.c:857 [<00000000e75ca9bb>] __sys_setsockopt+0x158/0x270 net/socket.c:2117 [<00000000bdb993a8>] __do_sys_setsockopt net/socket.c:2128 [inline] [<00000000bdb993a8>] __se_sys_setsockopt net/socket.c:2125 [inline] [<00000000bdb993a8>] __x64_sys_setsockopt+0xba/0x150 net/socket.c:2125 [<000000006a1ffdbd>] do_syscall_64+0x40/0x80 arch/x86/entry/common.c:47 [<00000000b11467c4>] entry_SYSCALL_64_after_hwframe+0x44/0xae In commit 24803f38a5c0 ("igmp: do not remove igmp souce list info when set link down"), the ip_mc_clear_src() in ip_mc_destroy_dev() was removed, because it was also called in igmpv3_clear_delrec(). Rough callgraph: inetdev_destroy -> ip_mc_destroy_dev -> igmpv3_clear_delrec -> ip_mc_clear_src -> RCU_INIT_POINTER(dev->ip_ptr, NULL) However, ip_mc_clear_src() called in igmpv3_clear_delrec() doesn't release in_dev->mc_list->sources. And RCU_INIT_POINTER() assigns the NULL to dev->ip_ptr. As a result, in_dev cannot be obtained through inetdev_by_index() and then in_dev->mc_list->sources cannot be released by ip_mc_del1_src() in the sock_close. Rough call sequence goes like: sock_close -> __sock_release -> inet_release -> ip_mc_drop_socket -> inetdev_by_index -> ip_mc_leave_src -> ip_mc_del_src -> ip_mc_del1_src So we still need to call ip_mc_clear_src() in ip_mc_destroy_dev() to free in_dev->mc_list->sources. Fixes: 24803f38a5c0 ("igmp: do not remove igmp souce list info ...") Reported-by: Hulk Robot Signed-off-by: Chengyang Fan Acked-by: Hangbin Liu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d08f726cd5b854cc9c96a314708ea69330e714c4 Author: Joakim Zhang Date: Wed Jun 16 17:14:26 2021 +0800 net: fec_ptp: fix issue caused by refactor the fec_devtype [ Upstream commit d23765646e71b43ed2b809930411ba5c0aadee7b ] Commit da722186f654 ("net: fec: set GPR bit on suspend by DT configuration.") refactor the fec_devtype, need adjust ptp driver accordingly. Fixes: da722186f654 ("net: fec: set GPR bit on suspend by DT configuration.") Signed-off-by: Joakim Zhang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 570a52cf3e01d19f7fd1a251dfc52b0cd86c13cb Author: Dongliang Mu Date: Wed Jun 16 10:48:33 2021 +0800 net: usb: fix possible use-after-free in smsc75xx_bind [ Upstream commit 56b786d86694e079d8aad9b314e015cd4ac02a3d ] The commit 46a8b29c6306 ("net: usb: fix memory leak in smsc75xx_bind") fails to clean up the work scheduled in smsc75xx_reset-> smsc75xx_set_multicast, which leads to use-after-free if the work is scheduled to start after the deallocation. In addition, this patch also removes a dangling pointer - dev->data[0]. This patch calls cancel_work_sync to cancel the scheduled work and set the dangling pointer to NULL. Fixes: 46a8b29c6306 ("net: usb: fix memory leak in smsc75xx_bind") Signed-off-by: Dongliang Mu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 70c8418469fb22a679fe5015ebe60fe15011ea43 Author: Aleksander Jan Bajkowski Date: Tue Jun 15 22:42:57 2021 +0200 lantiq: net: fix duplicated skb in rx descriptor ring [ Upstream commit 7ea6cd16f1599c1eac6018751eadbc5fc736b99a ] The previous commit didn't fix the bug properly. By mistake, it replaces the pointer of the next skb in the descriptor ring instead of the current one. As a result, the two descriptors are assigned the same SKB. The error is seen during the iperf test when skb_put tries to insert a second packet and exceeds the available buffer. Fixes: c7718ee96dbc ("net: lantiq: fix memory corruption in RX ring ") Signed-off-by: Aleksander Jan Bajkowski Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 11fac7e9127078fe3275642742cf5e2336fa934a Author: Maciej Żenczykowski Date: Tue Jun 15 01:05:49 2021 -0700 net: cdc_ncm: switch to eth%d interface naming [ Upstream commit c1a3d4067309451e68c33dbd356032549cc0bd8e ] This is meant to make the host side cdc_ncm interface consistently named just like the older CDC protocols: cdc_ether & cdc_ecm (and even rndis_host), which all use 'FLAG_ETHER | FLAG_POINTTOPOINT'. include/linux/usb/usbnet.h: #define FLAG_ETHER 0x0020 /* maybe use "eth%d" names */ #define FLAG_WLAN 0x0080 /* use "wlan%d" names */ #define FLAG_WWAN 0x0400 /* use "wwan%d" names */ #define FLAG_POINTTOPOINT 0x1000 /* possibly use "usb%d" names */ drivers/net/usb/usbnet.c @ line 1711: strcpy (net->name, "usb%d"); ... // heuristic: "usb%d" for links we know are two-host, // else "eth%d" when there's reasonable doubt. userspace // can rename the link if it knows better. if ((dev->driver_info->flags & FLAG_ETHER) != 0 && ((dev->driver_info->flags & FLAG_POINTTOPOINT) == 0 || (net->dev_addr [0] & 0x02) == 0)) strcpy (net->name, "eth%d"); /* WLAN devices should always be named "wlan%d" */ if ((dev->driver_info->flags & FLAG_WLAN) != 0) strcpy(net->name, "wlan%d"); /* WWAN devices should always be named "wwan%d" */ if ((dev->driver_info->flags & FLAG_WWAN) != 0) strcpy(net->name, "wwan%d"); So by using ETHER | POINTTOPOINT the interface naming is either usb%d or eth%d based on the global uniqueness of the mac address of the device. Without this 2.5gbps ethernet dongles which all seem to use the cdc_ncm driver end up being called usb%d instead of eth%d even though they're definitely not two-host. (All 1gbps & 5gbps ethernet usb dongles I've tested don't hit this problem due to use of different drivers, primarily r8152 and aqc111) Fixes tag is based purely on git blame, and is really just here to make sure this hits LTS branches newer than v4.5. Cc: Lorenzo Colitti Fixes: 4d06dd537f95 ("cdc_ncm: do not call usbnet_link_change from cdc_ncm_bind") Signed-off-by: Maciej Żenczykowski Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 9a479495629246c5dcfec55f7f425f5149f29ac0 Author: Jakub Kicinski Date: Mon Jun 14 15:24:05 2021 -0700 ptp: improve max_adj check against unreasonable values [ Upstream commit 475b92f932168a78da8109acd10bfb7578b8f2bb ] Scaled PPM conversion to PPB may (on 64bit systems) result in a value larger than s32 can hold (freq/scaled_ppm is a long). This means the kernel will not correctly reject unreasonably high ->freq values (e.g. > 4294967295ppb, 281474976645 scaled PPM). The conversion is equivalent to a division by ~66 (65.536), so the value of ppb is always smaller than ppm, but not small enough to assume narrowing the type from long -> s32 is okay. Note that reasonable user space (e.g. ptp4l) will not use such high values, anyway, 4289046510ppb ~= 4.3x, so the fix is somewhat pedantic. Fixes: d39a743511cd ("ptp: validate the requested frequency adjustment.") Fixes: d94ba80ebbea ("ptp: Added a brand new class driver for ptp clocks.") Signed-off-by: Jakub Kicinski Acked-by: Richard Cochran Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5fc6ed1831ca5a30fb0ceefd5e33c7c689e7627b Author: Daniel Borkmann Date: Fri May 28 15:47:32 2021 +0000 bpf: Fix leakage under speculation on mispredicted branches [ Upstream commit 9183671af6dbf60a1219371d4ed73e23f43b49db ] The verifier only enumerates valid control-flow paths and skips paths that are unreachable in the non-speculative domain. And so it can miss issues under speculative execution on mispredicted branches. For example, a type confusion has been demonstrated with the following crafted program: // r0 = pointer to a map array entry // r6 = pointer to readable stack slot // r9 = scalar controlled by attacker 1: r0 = *(u64 *)(r0) // cache miss 2: if r0 != 0x0 goto line 4 3: r6 = r9 4: if r0 != 0x1 goto line 6 5: r9 = *(u8 *)(r6) 6: // leak r9 Since line 3 runs iff r0 == 0 and line 5 runs iff r0 == 1, the verifier concludes that the pointer dereference on line 5 is safe. But: if the attacker trains both the branches to fall-through, such that the following is speculatively executed ... r6 = r9 r9 = *(u8 *)(r6) // leak r9 ... then the program will dereference an attacker-controlled value and could leak its content under speculative execution via side-channel. This requires to mistrain the branch predictor, which can be rather tricky, because the branches are mutually exclusive. However such training can be done at congruent addresses in user space using different branches that are not mutually exclusive. That is, by training branches in user space ... A: if r0 != 0x0 goto line C B: ... C: if r0 != 0x0 goto line D D: ... ... such that addresses A and C collide to the same CPU branch prediction entries in the PHT (pattern history table) as those of the BPF program's lines 2 and 4, respectively. A non-privileged attacker could simply brute force such collisions in the PHT until observing the attack succeeding. Alternative methods to mistrain the branch predictor are also possible that avoid brute forcing the collisions in the PHT. A reliable attack has been demonstrated, for example, using the following crafted program: // r0 = pointer to a [control] map array entry // r7 = *(u64 *)(r0 + 0), training/attack phase // r8 = *(u64 *)(r0 + 8), oob address // [...] // r0 = pointer to a [data] map array entry 1: if r7 == 0x3 goto line 3 2: r8 = r0 // crafted sequence of conditional jumps to separate the conditional // branch in line 193 from the current execution flow 3: if r0 != 0x0 goto line 5 4: if r0 == 0x0 goto exit 5: if r0 != 0x0 goto line 7 6: if r0 == 0x0 goto exit [...] 187: if r0 != 0x0 goto line 189 188: if r0 == 0x0 goto exit // load any slowly-loaded value (due to cache miss in phase 3) ... 189: r3 = *(u64 *)(r0 + 0x1200) // ... and turn it into known zero for verifier, while preserving slowly- // loaded dependency when executing: 190: r3 &= 1 191: r3 &= 2 // speculatively bypassed phase dependency 192: r7 += r3 193: if r7 == 0x3 goto exit 194: r4 = *(u8 *)(r8 + 0) // leak r4 As can be seen, in training phase (phase != 0x3), the condition in line 1 turns into false and therefore r8 with the oob address is overridden with the valid map value address, which in line 194 we can read out without issues. However, in attack phase, line 2 is skipped, and due to the cache miss in line 189 where the map value is (zeroed and later) added to the phase register, the condition in line 193 takes the fall-through path due to prior branch predictor training, where under speculation, it'll load the byte at oob address r8 (unknown scalar type at that point) which could then be leaked via side-channel. One way to mitigate these is to 'branch off' an unreachable path, meaning, the current verification path keeps following the is_branch_taken() path and we push the other branch to the verification stack. Given this is unreachable from the non-speculative domain, this branch's vstate is explicitly marked as speculative. This is needed for two reasons: i) if this path is solely seen from speculative execution, then we later on still want the dead code elimination to kick in in order to sanitize these instructions with jmp-1s, and ii) to ensure that paths walked in the non-speculative domain are not pruned from earlier walks of paths walked in the speculative domain. Additionally, for robustness, we mark the registers which have been part of the conditional as unknown in the speculative path given there should be no assumptions made on their content. The fix in here mitigates type confusion attacks described earlier due to i) all code paths in the BPF program being explored and ii) existing verifier logic already ensuring that given memory access instruction references one specific data structure. An alternative to this fix that has also been looked at in this scope was to mark aux->alu_state at the jump instruction with a BPF_JMP_TAKEN state as well as direction encoding (always-goto, always-fallthrough, unknown), such that mixing of different always-* directions themselves as well as mixing of always-* with unknown directions would cause a program rejection by the verifier, e.g. programs with constructs like 'if ([...]) { x = 0; } else { x = 1; }' with subsequent 'if (x == 1) { [...] }'. For unprivileged, this would result in only single direction always-* taken paths, and unknown taken paths being allowed, such that the former could be patched from a conditional jump to an unconditional jump (ja). Compared to this approach here, it would have two downsides: i) valid programs that otherwise are not performing any pointer arithmetic, etc, would potentially be rejected/broken, and ii) we are required to turn off path pruning for unprivileged, where both can be avoided in this work through pushing the invalid branch to the verification stack. The issue was originally discovered by Adam and Ofek, and later independently discovered and reported as a result of Benedict and Piotr's research work. Fixes: b2157399cc98 ("bpf: prevent out-of-bounds speculation") Reported-by: Adam Morrison Reported-by: Ofek Kirzner Reported-by: Benedict Schlueter Reported-by: Piotr Krysiuk Signed-off-by: Daniel Borkmann Reviewed-by: John Fastabend Reviewed-by: Benedict Schlueter Reviewed-by: Piotr Krysiuk Acked-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 960b08dd36de1e341e3eb43d1c547513e338f4f8 Author: Pavel Skripkin Date: Mon Jun 14 15:06:50 2021 +0300 net: qrtr: fix OOB Read in qrtr_endpoint_post [ Upstream commit ad9d24c9429e2159d1e279dc3a83191ccb4daf1d ] Syzbot reported slab-out-of-bounds Read in qrtr_endpoint_post. The problem was in wrong _size_ type: if (len != ALIGN(size, 4) + hdrlen) goto err; If size from qrtr_hdr is 4294967293 (0xfffffffd), the result of ALIGN(size, 4) will be 0. In case of len == hdrlen and size == 4294967293 in header this check won't fail and skb_put_data(skb, data + hdrlen, size); will read out of bound from data, which is hdrlen allocated block. Fixes: 194ccc88297a ("net: qrtr: Support decoding incoming v2 packets") Reported-and-tested-by: syzbot+1917d778024161609247@syzkaller.appspotmail.com Signed-off-by: Pavel Skripkin Reviewed-by: Bjorn Andersson Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 0239c439cedcc13c57f6d6e47c36904cdf1da7ca Author: David Ahern Date: Sat Jun 12 18:24:59 2021 -0600 ipv4: Fix device used for dst_alloc with local routes [ Upstream commit b87b04f5019e821c8c6c7761f258402e43500a1f ] Oliver reported a use case where deleting a VRF device can hang waiting for the refcnt to drop to 0. The root cause is that the dst is allocated against the VRF device but cached on the loopback device. The use case (added to the selftests) has an implicit VRF crossing due to the ordering of the FIB rules (lookup local is before the l3mdev rule, but the problem occurs even if the FIB rules are re-ordered with local after l3mdev because the VRF table does not have a default route to terminate the lookup). The end result is is that the FIB lookup returns the loopback device as the nexthop, but the ingress device is in a VRF. The mismatch causes the dst alloc against the VRF device but then cached on the loopback. The fix is to bring the trick used for IPv6 (see ip6_rt_get_dev_rcu): pick the dst alloc device based the fib lookup result but with checks that the result has a nexthop device (e.g., not an unreachable or prohibit entry). Fixes: f5a0aab84b74 ("net: ipv4: dst for local input routes should use l3mdev if relevant") Reported-by: Oliver Herms Signed-off-by: David Ahern Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4b5ad4b5aefdca18ab93bd08f14b3f26105e66fd Author: Rahul Lakkireddy Date: Sat Jun 12 19:20:44 2021 +0530 cxgb4: fix wrong ethtool n-tuple rule lookup [ Upstream commit 09427c1915f754ebe7d3d8e54e79bbee48afe916 ] The TID returned during successful filter creation is relative to the region in which the filter is created. Using it directly always returns Hi Prio/Normal filter region's entry for the first couple of entries, even though the rule is actually inserted in Hash region. Fix by analyzing in which region the filter has been inserted and save the absolute TID to be used for lookup later. Fixes: db43b30cd89c ("cxgb4: add ethtool n-tuple filter deletion") Signed-off-by: Rahul Lakkireddy Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d708e5efdd3135ac9770ac35f15be820ce87b7fc Author: Christophe JAILLET Date: Sat Jun 12 14:53:12 2021 +0200 netxen_nic: Fix an error handling path in 'netxen_nic_probe()' [ Upstream commit 49a10c7b176295f8fafb338911cf028e97f65f4d ] If an error occurs after a 'pci_enable_pcie_error_reporting()' call, it must be undone by a corresponding 'pci_disable_pcie_error_reporting()' call, as already done in the remove function. Fixes: e87ad5539343 ("netxen: support pci error handlers") Signed-off-by: Christophe JAILLET Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 70513cdb936e92473d7a55ba16c53f3b5c157e86 Author: Christophe JAILLET Date: Sat Jun 12 14:37:46 2021 +0200 qlcnic: Fix an error handling path in 'qlcnic_probe()' [ Upstream commit cb3376604a676e0302258b01893911bdd7aa5278 ] If an error occurs after a 'pci_enable_pcie_error_reporting()' call, it must be undone by a corresponding 'pci_disable_pcie_error_reporting()' call, as already done in the remove function. Fixes: 451724c821c1 ("qlcnic: aer support") Signed-off-by: Christophe JAILLET Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit fb3a948143688e14e2cfd2a2812877923d0e5e92 Author: Jakub Kicinski Date: Fri Jun 11 18:49:48 2021 -0700 ethtool: strset: fix message length calculation [ Upstream commit e175aef902697826d344ce3a12189329848fe898 ] Outer nest for ETHTOOL_A_STRSET_STRINGSETS is not accounted for. This may result in ETHTOOL_MSG_STRSET_GET producing a warning like: calculated message payload length (684) not sufficient WARNING: CPU: 0 PID: 30967 at net/ethtool/netlink.c:369 ethnl_default_doit+0x87a/0xa20 and a splat. As usually with such warnings three conditions must be met for the warning to trigger: - there must be no skb size rounding up (e.g. reply_size of 684); - string set must be per-device (so that the header gets populated); - the device name must be at least 12 characters long. all in all with current user space it looks like reading priv flags is the only place this could potentially happen. Or with syzbot :) Reported-by: syzbot+59aa77b92d06cd5a54f2@syzkaller.appspotmail.com Fixes: 71921690f974 ("ethtool: provide string sets with STRSET_GET request") Signed-off-by: Jakub Kicinski Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 0e185a7b285d2a84341a9d29ac935408ac5b662d Author: Alex Elder Date: Fri Jun 11 13:26:00 2021 -0500 net: qualcomm: rmnet: don't over-count statistics [ Upstream commit 994c393bb6886d6d94d628475b274a8cb3fc67a4 ] The purpose of the loop using u64_stats_fetch_*_irq() is to ensure statistics on a given CPU are collected atomically. If one of the statistics values gets updated within the begin/retry window, the loop will run again. Currently the statistics totals are updated inside that window. This means that if the loop ever retries, the statistics for the CPU will be counted more than once. Fix this by taking a snapshot of a CPU's statistics inside the protected window, and then updating the counters with the snapshot values after exiting the loop. (Also add a newline at the end of this file...) Fixes: 192c4b5d48f2a ("net: qualcomm: rmnet: Add support for 64 bit stats") Signed-off-by: Alex Elder Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit e3577776d6064c0633fdbc533019cb5c6092079d Author: Subash Abhinov Kasiviswanathan Date: Wed Dec 9 22:51:46 2020 -0700 net: qualcomm: rmnet: Update rmnet device MTU based on real device [ Upstream commit b7f5eb6ba21b0b54b04918fc9df13309ff3c67b8 ] Packets sent by rmnet to the real device have variable MAP header lengths based on the data format configured. This patch adds checks to ensure that the real device MTU is sufficient to transmit the MAP packet comprising of the MAP header and the IP packet. This check is enforced when rmnet devices are created and updated and during MTU updates of both the rmnet and real device. Additionally, rmnet devices now have a default MTU configured which accounts for the real device MTU and the headroom based on the data format. Signed-off-by: Sean Tranchetti Signed-off-by: Subash Abhinov Kasiviswanathan Tested-by: Loic Poulain Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4abfd597fe60bfa677bfe177e3a6a551e3a3f792 Author: Changbin Du Date: Fri Jun 11 22:29:59 2021 +0800 net: make get_net_ns return error if NET_NS is disabled [ Upstream commit ea6932d70e223e02fea3ae20a4feff05d7c1ea9a ] There is a panic in socket ioctl cmd SIOCGSKNS when NET_NS is not enabled. The reason is that nsfs tries to access ns->ops but the proc_ns_operations is not implemented in this case. [7.670023] Unable to handle kernel NULL pointer dereference at virtual address 00000010 [7.670268] pgd = 32b54000 [7.670544] [00000010] *pgd=00000000 [7.671861] Internal error: Oops: 5 [#1] SMP ARM [7.672315] Modules linked in: [7.672918] CPU: 0 PID: 1 Comm: systemd Not tainted 5.13.0-rc3-00375-g6799d4f2da49 #16 [7.673309] Hardware name: Generic DT based system [7.673642] PC is at nsfs_evict+0x24/0x30 [7.674486] LR is at clear_inode+0x20/0x9c The same to tun SIOCGSKNS command. To fix this problem, we make get_net_ns() return -EINVAL when NET_NS is disabled. Meanwhile move it to right place net/core/net_namespace.c. Signed-off-by: Changbin Du Fixes: c62cce2caee5 ("net: add an ioctl to get a socket network namespace") Cc: Cong Wang Cc: Jakub Kicinski Cc: David Laight Cc: Christian Brauner Suggested-by: Jakub Kicinski Acked-by: Christian Brauner Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 6a4b39944e2fb18b70c66dd435210bc5c53c89bd Author: Jisheng Zhang Date: Fri Jun 11 15:16:11 2021 +0800 net: stmmac: dwmac1000: Fix extended MAC address registers definition [ Upstream commit 1adb20f0d496b2c61e9aa1f4761b8d71f93d258e ] The register starts from 0x800 is the 16th MAC address register rather than the first one. Fixes: cffb13f4d6fb ("stmmac: extend mac addr reg and fix perfect filering") Signed-off-by: Jisheng Zhang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 6392ed82ad0831811cf76e986229583c5b6d44ab Author: Rahul Lakkireddy Date: Fri Jun 11 12:17:47 2021 +0530 cxgb4: halt chip before flashing PHY firmware image [ Upstream commit 6d297540f75d759489054e8b07932208fc4db2cb ] When using firmware-assisted PHY firmware image write to flash, halt the chip before beginning the flash write operation to allow the running firmware to store the image persistently. Otherwise, the running firmware will only store the PHY image in local on-chip RAM, which will be lost after next reset. Fixes: 4ee339e1e92a ("cxgb4: add support to flash PHY image") Signed-off-by: Rahul Lakkireddy Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b38ec782d004eda623e40ea5bc92c9e2ce7c15c1 Author: Rahul Lakkireddy Date: Fri Jun 11 12:17:46 2021 +0530 cxgb4: fix sleep in atomic when flashing PHY firmware [ Upstream commit f046bd0ae15d8a0bbe57d4647da182420f720c3d ] Before writing new PHY firmware to on-chip memory, driver queries firmware for current running PHY firmware version, which can result in sleep waiting for reply. So, move spinlock closer to the actual on-chip memory write operation, instead of taking it at the callers. Fixes: 5fff701c838e ("cxgb4: always sync access when flashing PHY firmware") Signed-off-by: Rahul Lakkireddy Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 3d60457d74d9cc7b36f78f9cb74f29bc6182c1e8 Author: Rahul Lakkireddy Date: Fri Jun 11 12:17:45 2021 +0530 cxgb4: fix endianness when flashing boot image [ Upstream commit 42a2039753a7f758ba5c85cb199fcf10dc2111eb ] Boot images are copied to memory and updated with current underlying device ID before flashing them to adapter. Ensure the updated images are always flashed in Big Endian to allow the firmware to read the new images during boot properly. Fixes: 550883558f17 ("cxgb4: add support to flash boot image") Signed-off-by: Rahul Lakkireddy Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5bf940fe91f8bf91f8d67aa213e36546f9eedc63 Author: Christophe JAILLET Date: Fri Jun 11 08:13:39 2021 +0200 alx: Fix an error handling path in 'alx_probe()' [ Upstream commit 33e381448cf7a05d76ac0b47d4a6531ecd0e5c53 ] If an error occurs after a 'pci_enable_pcie_error_reporting()' call, it must be undone by a corresponding 'pci_disable_pcie_error_reporting()' call, as already done in the remove function. Fixes: ab69bde6b2e9 ("alx: add a simple AR816x/AR817x device driver") Signed-off-by: Christophe JAILLET Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 0adf32c033a5ff3273295655a3e7cb3f698cbb9b Author: Paolo Abeni Date: Thu Jun 10 15:59:43 2021 -0700 selftests: mptcp: enable syncookie only in absence of reorders [ Upstream commit 2395da0e17935ce9158cdfae433962bdb6cbfa67 ] Syncookie validation may fail for OoO packets, causing spurious resets and self-tests failures, so let's force syncookie only for tests iteration with no OoO. Fixes: fed61c4b584c ("selftests: mptcp: make 2nd net namespace use tcp syn cookies unconditionally") Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/198 Signed-off-by: Paolo Abeni Signed-off-by: Mat Martineau Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit eab06f7504daeb829681c1e535b47802b0e150be Author: Paolo Abeni Date: Thu Jun 10 15:59:42 2021 -0700 mptcp: do not warn on bad input from the network [ Upstream commit 61e710227e97172355d5f150d5c78c64175d9fb2 ] warn_bad_map() produces a kernel WARN on bad input coming from the network. Use pr_debug() to avoid spamming the system log. Additionally, when the right bound check fails, warn_bad_map() reports the wrong ssn value, let's fix it. Fixes: 648ef4b88673 ("mptcp: Implement MPTCP receive path") Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/107 Signed-off-by: Paolo Abeni Signed-off-by: Mat Martineau Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 222ebeda1702646e2141b91fa095158501190c0b Author: Paolo Abeni Date: Thu Jun 10 15:59:40 2021 -0700 mptcp: try harder to borrow memory from subflow under pressure [ Upstream commit 72f961320d5d15bfcb26dbe3edaa3f7d25fd2c8a ] If the host is under sever memory pressure, and RX forward memory allocation for the msk fails, we try to borrow the required memory from the ingress subflow. The current attempt is a bit flaky: if skb->truesize is less than SK_MEM_QUANTUM, the ssk will not release any memory, and the next schedule will fail again. Instead, directly move the required amount of pages from the ssk to the msk, if available Fixes: 9c3f94e1681b ("mptcp: add missing memory scheduling in the rx path") Signed-off-by: Paolo Abeni Signed-off-by: Mat Martineau Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 3b491dd593d582ceeb27aa617600712a6bd14246 Author: Maxim Mikityanskiy Date: Thu Jun 10 19:40:31 2021 +0300 sch_cake: Fix out of bounds when parsing TCP options and header [ Upstream commit ba91c49dedbde758ba0b72f57ac90b06ddf8e548 ] The TCP option parser in cake qdisc (cake_get_tcpopt and cake_tcph_may_drop) could read one byte out of bounds. When the length is 1, the execution flow gets into the loop, reads one byte of the opcode, and if the opcode is neither TCPOPT_EOL nor TCPOPT_NOP, it reads one more byte, which exceeds the length of 1. This fix is inspired by commit 9609dad263f8 ("ipv4: tcp_input: fix stack out of bounds when parsing TCP options."). v2 changes: Added doff validation in cake_get_tcphdr to avoid parsing garbage as TCP header. Although it wasn't strictly an out-of-bounds access (memory was allocated), garbage values could be read where CAKE expected the TCP header if doff was smaller than 5. Cc: Young Xiao <92siuyang@gmail.com> Fixes: 8b7138814f29 ("sch_cake: Add optional ACK filter") Signed-off-by: Maxim Mikityanskiy Acked-by: Toke Høiland-Jørgensen Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 73eeba71dc9932970befa009e68272a3d5ec4a58 Author: Maxim Mikityanskiy Date: Thu Jun 10 19:40:30 2021 +0300 mptcp: Fix out of bounds when parsing TCP options [ Upstream commit 07718be265680dcf496347d475ce1a5442f55ad7 ] The TCP option parser in mptcp (mptcp_get_options) could read one byte out of bounds. When the length is 1, the execution flow gets into the loop, reads one byte of the opcode, and if the opcode is neither TCPOPT_EOL nor TCPOPT_NOP, it reads one more byte, which exceeds the length of 1. This fix is inspired by commit 9609dad263f8 ("ipv4: tcp_input: fix stack out of bounds when parsing TCP options."). Cc: Young Xiao <92siuyang@gmail.com> Fixes: cec37a6e41aa ("mptcp: Handle MP_CAPABLE options for outgoing connections") Signed-off-by: Maxim Mikityanskiy Reviewed-by: Mat Martineau Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 9cdf299ba4e153b5e56187648420de22c6216f02 Author: Maxim Mikityanskiy Date: Thu Jun 10 19:40:29 2021 +0300 netfilter: synproxy: Fix out of bounds when parsing TCP options [ Upstream commit 5fc177ab759418c9537433e63301096e733fb915 ] The TCP option parser in synproxy (synproxy_parse_options) could read one byte out of bounds. When the length is 1, the execution flow gets into the loop, reads one byte of the opcode, and if the opcode is neither TCPOPT_EOL nor TCPOPT_NOP, it reads one more byte, which exceeds the length of 1. This fix is inspired by commit 9609dad263f8 ("ipv4: tcp_input: fix stack out of bounds when parsing TCP options."). v2 changes: Added an early return when length < 0 to avoid calling skb_header_pointer with negative length. Cc: Young Xiao <92siuyang@gmail.com> Fixes: 48b1de4c110a ("netfilter: add SYNPROXY core/target") Signed-off-by: Maxim Mikityanskiy Reviewed-by: Florian Westphal Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit a336dc6fdd5668211e846378da0cd6b40a96a1cc Author: Aya Levin Date: Mon May 10 14:34:58 2021 +0300 net/mlx5e: Block offload of outer header csum for UDP tunnels [ Upstream commit 6d6727dddc7f93fcc155cb8d0c49c29ae0e71122 ] The device is able to offload either the outer header csum or inner header csum. The driver utilizes the inner csum offload. Hence, block setting of tx-udp_tnl-csum-segmentation and set it to off[fixed]. Fixes: b49663c8fb49 ("net/mlx5e: Add support for UDP tunnel segmentation with outer checksum offload") Signed-off-by: Aya Levin Reviewed-by: Tariq Toukan Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 34ff3770bff809d071d5b0a84ebb539a93dc16c6 Author: Maor Gottlieb Date: Sun Jun 6 11:23:41 2021 +0300 net/mlx5: DR, Don't use SW steering when RoCE is not supported [ Upstream commit 4aaf96ac8b45d8e2e019b6b53cce65a73c4ace2c ] SW steering uses RC QP to write/read to/from ICM, hence it's not supported when RoCE is not supported as well. Fixes: 70605ea545e8 ("net/mlx5: DR, Expose APIs for direct rule managing") Signed-off-by: Maor Gottlieb Reviewed-by: Alex Vesker Reviewed-by: Yevgeny Kliteynik Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 3623bfcab3bfa2cbc498784b336fa6d03cb81b7d Author: Yevgeny Kliteynik Date: Mon Jan 25 02:26:45 2021 +0200 net/mlx5: DR, Allow SW steering for sw_owner_v2 devices [ Upstream commit 64f45c0fc4c71f577506c5a7a7956ae3bc3388ea ] Allow sw_owner_v2 based on sw_format_version. Signed-off-by: Alex Vesker Signed-off-by: Yevgeny Kliteynik Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 792f16e083b5fdf6bd82c76a73d59d9f23c86a40 Author: Maor Gottlieb Date: Sun Jun 6 11:20:46 2021 +0300 net/mlx5: Consider RoCE cap before init RDMA resources [ Upstream commit c189716b2a7c1d2d8658e269735273caa1c38b54 ] Check if RoCE is supported by the device before enable it in the vport context and create all the RDMA steering objects. Fixes: 80f09dfc237f ("net/mlx5: Eswitch, enable RoCE loopback traffic") Signed-off-by: Maor Gottlieb Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit be7f3f401d224e1efe8112b2fa8b837eeb8c5e52 Author: Dima Chumak Date: Wed May 26 13:45:10 2021 +0300 net/mlx5e: Fix page reclaim for dead peer hairpin [ Upstream commit a3e5fd9314dfc4314a9567cde96e1aef83a7458a ] When adding a hairpin flow, a firmware-side send queue is created for the peer net device, which claims some host memory pages for its internal ring buffer. If the peer net device is removed/unbound before the hairpin flow is deleted, then the send queue is not destroyed which leads to a stack trace on pci device remove: [ 748.005230] mlx5_core 0000:08:00.2: wait_func:1094:(pid 12985): MANAGE_PAGES(0x108) timeout. Will cause a leak of a command resource [ 748.005231] mlx5_core 0000:08:00.2: reclaim_pages:514:(pid 12985): failed reclaiming pages: err -110 [ 748.001835] mlx5_core 0000:08:00.2: mlx5_reclaim_root_pages:653:(pid 12985): failed reclaiming pages (-110) for func id 0x0 [ 748.002171] ------------[ cut here ]------------ [ 748.001177] FW pages counter is 4 after reclaiming all pages [ 748.001186] WARNING: CPU: 1 PID: 12985 at drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c:685 mlx5_reclaim_startup_pages+0x34b/0x460 [mlx5_core] [ +0.002771] Modules linked in: cls_flower mlx5_ib mlx5_core ptp pps_core act_mirred sch_ingress openvswitch nsh xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi rdma_cm ib_umad ib_ipoib iw_cm ib_cm ib_uverbs ib_core overlay fuse [last unloaded: pps_core] [ 748.007225] CPU: 1 PID: 12985 Comm: tee Not tainted 5.12.0+ #1 [ 748.001376] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 [ 748.002315] RIP: 0010:mlx5_reclaim_startup_pages+0x34b/0x460 [mlx5_core] [ 748.001679] Code: 28 00 00 00 0f 85 22 01 00 00 48 81 c4 b0 00 00 00 31 c0 5b 5d 41 5c 41 5d 41 5e 41 5f c3 48 c7 c7 40 cc 19 a1 e8 9f 71 0e e2 <0f> 0b e9 30 ff ff ff 48 c7 c7 a0 cc 19 a1 e8 8c 71 0e e2 0f 0b e9 [ 748.003781] RSP: 0018:ffff88815220faf8 EFLAGS: 00010286 [ 748.001149] RAX: 0000000000000000 RBX: ffff8881b4900280 RCX: 0000000000000000 [ 748.001445] RDX: 0000000000000027 RSI: 0000000000000004 RDI: ffffed102a441f51 [ 748.001614] RBP: 00000000000032b9 R08: 0000000000000001 R09: ffffed1054a15ee8 [ 748.001446] R10: ffff8882a50af73b R11: ffffed1054a15ee7 R12: fffffbfff07c1e30 [ 748.001447] R13: dffffc0000000000 R14: ffff8881b492cba8 R15: 0000000000000000 [ 748.001429] FS: 00007f58bd08b580(0000) GS:ffff8882a5080000(0000) knlGS:0000000000000000 [ 748.001695] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 748.001309] CR2: 000055a026351740 CR3: 00000001d3b48006 CR4: 0000000000370ea0 [ 748.001506] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 748.001483] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 748.001654] Call Trace: [ 748.000576] ? mlx5_satisfy_startup_pages+0x290/0x290 [mlx5_core] [ 748.001416] ? mlx5_cmd_teardown_hca+0xa2/0xd0 [mlx5_core] [ 748.001354] ? mlx5_cmd_init_hca+0x280/0x280 [mlx5_core] [ 748.001203] mlx5_function_teardown+0x30/0x60 [mlx5_core] [ 748.001275] mlx5_uninit_one+0xa7/0xc0 [mlx5_core] [ 748.001200] remove_one+0x5f/0xc0 [mlx5_core] [ 748.001075] pci_device_remove+0x9f/0x1d0 [ 748.000833] device_release_driver_internal+0x1e0/0x490 [ 748.001207] unbind_store+0x19f/0x200 [ 748.000942] ? sysfs_file_ops+0x170/0x170 [ 748.001000] kernfs_fop_write_iter+0x2bc/0x450 [ 748.000970] new_sync_write+0x373/0x610 [ 748.001124] ? new_sync_read+0x600/0x600 [ 748.001057] ? lock_acquire+0x4d6/0x700 [ 748.000908] ? lockdep_hardirqs_on_prepare+0x400/0x400 [ 748.001126] ? fd_install+0x1c9/0x4d0 [ 748.000951] vfs_write+0x4d0/0x800 [ 748.000804] ksys_write+0xf9/0x1d0 [ 748.000868] ? __x64_sys_read+0xb0/0xb0 [ 748.000811] ? filp_open+0x50/0x50 [ 748.000919] ? syscall_enter_from_user_mode+0x1d/0x50 [ 748.001223] do_syscall_64+0x3f/0x80 [ 748.000892] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 748.001026] RIP: 0033:0x7f58bcfb22f7 [ 748.000944] Code: 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24 [ 748.003925] RSP: 002b:00007fffd7f2aaa8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 748.001732] RAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007f58bcfb22f7 [ 748.001426] RDX: 000000000000000d RSI: 00007fffd7f2abc0 RDI: 0000000000000003 [ 748.001746] RBP: 00007fffd7f2abc0 R08: 0000000000000000 R09: 0000000000000001 [ 748.001631] R10: 00000000000001b6 R11: 0000000000000246 R12: 000000000000000d [ 748.001537] R13: 00005597ac2c24a0 R14: 000000000000000d R15: 00007f58bd084700 [ 748.001564] irq event stamp: 0 [ 748.000787] hardirqs last enabled at (0): [<0000000000000000>] 0x0 [ 748.001399] hardirqs last disabled at (0): [] copy_process+0x146f/0x5eb0 [ 748.001854] softirqs last enabled at (0): [] copy_process+0x14ae/0x5eb0 [ 748.013431] softirqs last disabled at (0): [<0000000000000000>] 0x0 [ 748.001492] ---[ end trace a6fabd773d1c51ae ]--- Fix by destroying the send queue of a hairpin peer net device that is being removed/unbound, which returns the allocated ring buffer pages to the host. Fixes: 4d8fcf216c90 ("net/mlx5e: Avoid unbounded peer devices when unpairing TC hairpin rules") Signed-off-by: Dima Chumak Reviewed-by: Roi Dayan Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 02c55a257046f573af3d0d4e0da2d9f2d1f7263d Author: Huy Nguyen Date: Fri May 28 13:20:32 2021 -0500 net/mlx5e: Remove dependency in IPsec initialization flows [ Upstream commit 8ad893e516a77209a1818a2072d2027d87db809f ] Currently, IPsec feature is disabled because mlx5e_build_nic_netdev is required to be called after mlx5e_ipsec_init. This requirement is invalid as mlx5e_build_nic_netdev and mlx5e_ipsec_init initialize independent resources. Remove ipsec pointer check in mlx5e_build_nic_netdev so that the two functions can be called at any order. Fixes: 547eede070eb ("net/mlx5e: IPSec, Innova IPSec offload infrastructure") Signed-off-by: Huy Nguyen Reviewed-by: Raed Salem Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 4733b73709a255a9af90582867f014887482445f Author: Marcelo Ricardo Leitner Date: Wed Jun 9 11:23:56 2021 -0300 net/sched: act_ct: handle DNAT tuple collision [ Upstream commit 13c62f5371e3eb4fc3400cfa26e64ca75f888008 ] This this the counterpart of 8aa7b526dc0b ("openvswitch: handle DNAT tuple collision") for act_ct. From that commit changelog: """ With multiple DNAT rules it's possible that after destination translation the resulting tuples collide. ... Netfilter handles this case by allocating a null binding for SNAT at egress by default. Perform the same operation in openvswitch for DNAT if no explicit SNAT is requested by the user and allocate a null binding for SNAT for packets in the "original" direction. """ Fixes: 95219afbb980 ("act_ct: support asymmetric conntrack") Signed-off-by: Marcelo Ricardo Leitner Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit c8f1437c0145e2750fb9543c552ccc5a47636491 Author: Ido Schimmel Date: Wed Jun 9 14:17:53 2021 +0300 rtnetlink: Fix regression in bridge VLAN configuration [ Upstream commit d2e381c4963663bca6f30c3b996fa4dbafe8fcb5 ] Cited commit started returning errors when notification info is not filled by the bridge driver, resulting in the following regression: # ip link add name br1 type bridge vlan_filtering 1 # bridge vlan add dev br1 vid 555 self pvid untagged RTNETLINK answers: Invalid argument As long as the bridge driver does not fill notification info for the bridge device itself, an empty notification should not be considered as an error. This is explained in commit 59ccaaaa49b5 ("bridge: dont send notification when skb->len == 0 in rtnl_bridge_notify"). Fix by removing the error and add a comment to avoid future bugs. Fixes: a8db57c1d285 ("rtnetlink: Fix missing error code in rtnl_bridge_notify()") Signed-off-by: Ido Schimmel Reviewed-by: Nikolay Aleksandrov Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8729ec8a2238152a4afc212a331a6cd2c61aeeac Author: Paolo Abeni Date: Wed Jun 9 11:49:01 2021 +0200 udp: fix race between close() and udp_abort() [ Upstream commit a8b897c7bcd47f4147d066e22cc01d1026d7640e ] Kaustubh reported and diagnosed a panic in udp_lib_lookup(). The root cause is udp_abort() racing with close(). Both racing functions acquire the socket lock, but udp{v6}_destroy_sock() release it before performing destructive actions. We can't easily extend the socket lock scope to avoid the race, instead use the SOCK_DEAD flag to prevent udp_abort from doing any action when the critical race happens. Diagnosed-and-tested-by: Kaustubh Pandey Fixes: 5d77dca82839 ("net: diag: support SOCK_DESTROY for UDP sockets") Signed-off-by: Paolo Abeni Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7dd7b1e4d929a42116e6e75413d07ceb7a60c7ab Author: Maciej Fijalkowski Date: Thu May 20 08:35:00 2021 +0200 ice: parameterize functions responsible for Tx ring management [ Upstream commit 2e84f6b3773f43263124c76499c0c4ec3f40aa9b ] Commit ae15e0ba1b33 ("ice: Change number of XDP Tx queues to match number of Rx queues") tried to address the incorrect setting of XDP queue count that was based on the Tx queue count, whereas in theory we should provide the XDP queue per Rx queue. However, the routines that setup and destroy the set of Tx resources are still based on the vsi->num_txq. Ice supports the asynchronous Tx/Rx queue count, so for a setup where vsi->num_txq > vsi->num_rxq, ice_vsi_stop_tx_rings and ice_vsi_cfg_txqs will be accessing the vsi->xdp_rings out of the bounds. Parameterize two mentioned functions so they get the size of Tx resources array as the input. Fixes: ae15e0ba1b33 ("ice: Change number of XDP Tx queues to match number of Rx queues") Signed-off-by: Maciej Fijalkowski Tested-by: Kiran Bhandare Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 805ae44fc0a86f234a1a84eea16e42ef68a80535 Author: Maciej Fijalkowski Date: Thu May 20 08:34:59 2021 +0200 ice: add ndo_bpf callback for safe mode netdev ops [ Upstream commit ebc5399ea1dfcddac31974091086a3379141899b ] ice driver requires a programmable pipeline firmware package in order to have a support for advanced features. Otherwise, driver falls back to so called 'safe mode'. For that mode, ndo_bpf callback is not exposed and when user tries to load XDP program, the following happens: $ sudo ./xdp1 enp179s0f1 libbpf: Kernel error message: Underlying driver does not support XDP in native mode link set xdp fd failed which is sort of confusing, as there is a native XDP support, but not in the current mode. Improve the user experience by providing the specific ndo_bpf callback dedicated for safe mode which will make use of extack to explicitly let the user know that the DDP package is missing and that's the reason that the XDP can't be loaded onto interface currently. Cc: Jamal Hadi Salim Fixes: efc2214b6047 ("ice: Add support for XDP") Signed-off-by: Maciej Fijalkowski Tested-by: Kiran Bhandare Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 27e3d7da654d7fc3ca94efd19610ca18a2dea90d Author: Florian Westphal Date: Tue Jun 8 13:48:18 2021 +0200 netfilter: nft_fib_ipv6: skip ipv6 packets from any to link-local [ Upstream commit 12f36e9bf678a81d030ca1b693dcda62b55af7c5 ] The ip6tables rpfilter match has an extra check to skip packets with "::" source address. Extend this to ipv6 fib expression. Else ipv6 duplicate address detection packets will fail rpf route check -- lookup returns -ENETUNREACH. While at it, extend the prerouting check to also cover the ingress hook. Closes: https://bugzilla.netfilter.org/show_bug.cgi?id=1543 Fixes: f6d0cbcf09c5 ("netfilter: nf_tables: add fib expression") Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 5cea03aef609d84c5ac023e366c6629e66b405cf Author: Aleksander Jan Bajkowski Date: Tue Jun 8 23:21:07 2021 +0200 net: lantiq: disable interrupt before sheduling NAPI [ Upstream commit f2386cf7c5f4ff5d7b584f5d92014edd7df6c676 ] This patch fixes TX hangs with threaded NAPI enabled. The scheduled NAPI seems to be executed in parallel with the interrupt on second thread. Sometimes it happens that ltq_dma_disable_irq() is executed after xrx200_tx_housekeeping(). The symptom is that TX interrupts are disabled in the DMA controller. As a result, the TX hangs after a few seconds of the iperf test. Scheduling NAPI after disabling interrupts fixes this issue. Tested on Lantiq xRX200 (BT Home Hub 5A). Fixes: 9423361da523 ("net: lantiq: Disable IRQs only if NAPI gets scheduled ") Signed-off-by: Aleksander Jan Bajkowski Acked-by: Hauke Mehrtens Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit db5f4adc93bd028f2ccfbd6fc4fe67d1bc15c113 Author: Vladimir Oltean Date: Tue Jun 8 14:15:35 2021 +0300 net: dsa: felix: re-enable TX flow control in ocelot_port_flush() [ Upstream commit 1650bdb1c516c248fb06f6d076559ff6437a5853 ] Because flow control is set up statically in ocelot_init_port(), and not in phylink_mac_link_up(), what happens is that after the blamed commit, the flow control remains disabled after the port flushing procedure. Fixes: eb4733d7cffc ("net: dsa: felix: implement port flushing on .phylink_mac_link_down") Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5946fbf48355f5a8caeff72580c7658da5966b86 Author: Pavel Skripkin Date: Tue Jun 8 11:06:41 2021 +0300 net: rds: fix memory leak in rds_recvmsg [ Upstream commit 49bfcbfd989a8f1f23e705759a6bb099de2cff9f ] Syzbot reported memory leak in rds. The problem was in unputted refcount in case of error. int rds_recvmsg(struct socket *sock, struct msghdr *msg, size_t size, int msg_flags) { ... if (!rds_next_incoming(rs, &inc)) { ... } After this "if" inc refcount incremented and if (rds_cmsg_recv(inc, msg, rs)) { ret = -EFAULT; goto out; } ... out: return ret; } in case of rds_cmsg_recv() fail the refcount won't be decremented. And it's easy to see from ftrace log, that rds_inc_addref() don't have rds_inc_put() pair in rds_recvmsg() after rds_cmsg_recv() 1) | rds_recvmsg() { 1) 3.721 us | rds_inc_addref(); 1) 3.853 us | rds_message_inc_copy_to_user(); 1) + 10.395 us | rds_cmsg_recv(); 1) + 34.260 us | } Fixes: bdbe6fbc6a2f ("RDS: recv.c") Reported-and-tested-by: syzbot+5134cdf021c4ed5aaa5f@syzkaller.appspotmail.com Signed-off-by: Pavel Skripkin Reviewed-by: Håkon Bugge Acked-by: Santosh Shilimkar Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit aba26b38388e69c12c588f952c77d491c60afec6 Author: Nicolas Dichtel Date: Tue Jun 8 16:59:51 2021 +0200 vrf: fix maximum MTU [ Upstream commit 9bb392f62447d73cc7dd7562413a2cd9104c82f8 ] My initial goal was to fix the default MTU, which is set to 65536, ie above the maximum defined in the driver: 65535 (ETH_MAX_MTU). In fact, it's seems more consistent, wrt min_mtu, to set the max_mtu to IP6_MAX_MTU (65535 + sizeof(struct ipv6hdr)) and use it by default. Let's also, for consistency, set the mtu in vrf_setup(). This function calls ether_setup(), which set the mtu to 1500. Thus, the whole mtu config is done in the same function. Before the patch: $ ip link add blue type vrf table 1234 $ ip link list blue 9: blue: mtu 65536 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether fa:f5:27:70:24:2a brd ff:ff:ff:ff:ff:ff $ ip link set dev blue mtu 65535 $ ip link set dev blue mtu 65536 Error: mtu greater than device maximum. Fixes: 5055376a3b44 ("net: vrf: Fix ping failed when vrf mtu is set to 0") CC: Miaohe Lin Signed-off-by: Nicolas Dichtel Reviewed-by: David Ahern Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit deeeb65c6ee404f2d1fb80b38b2730645c0f4663 Author: Nanyong Sun Date: Tue Jun 8 09:51:58 2021 +0800 net: ipv4: fix memory leak in netlbl_cipsov4_add_std [ Upstream commit d612c3f3fae221e7ea736d196581c2217304bbbc ] Reported by syzkaller: BUG: memory leak unreferenced object 0xffff888105df7000 (size 64): comm "syz-executor842", pid 360, jiffies 4294824824 (age 22.546s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000e67ed558>] kmalloc include/linux/slab.h:590 [inline] [<00000000e67ed558>] kzalloc include/linux/slab.h:720 [inline] [<00000000e67ed558>] netlbl_cipsov4_add_std net/netlabel/netlabel_cipso_v4.c:145 [inline] [<00000000e67ed558>] netlbl_cipsov4_add+0x390/0x2340 net/netlabel/netlabel_cipso_v4.c:416 [<0000000006040154>] genl_family_rcv_msg_doit.isra.0+0x20e/0x320 net/netlink/genetlink.c:739 [<00000000204d7a1c>] genl_family_rcv_msg net/netlink/genetlink.c:783 [inline] [<00000000204d7a1c>] genl_rcv_msg+0x2bf/0x4f0 net/netlink/genetlink.c:800 [<00000000c0d6a995>] netlink_rcv_skb+0x134/0x3d0 net/netlink/af_netlink.c:2504 [<00000000d78b9d2c>] genl_rcv+0x24/0x40 net/netlink/genetlink.c:811 [<000000009733081b>] netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline] [<000000009733081b>] netlink_unicast+0x4a0/0x6a0 net/netlink/af_netlink.c:1340 [<00000000d5fd43b8>] netlink_sendmsg+0x789/0xc70 net/netlink/af_netlink.c:1929 [<000000000a2d1e40>] sock_sendmsg_nosec net/socket.c:654 [inline] [<000000000a2d1e40>] sock_sendmsg+0x139/0x170 net/socket.c:674 [<00000000321d1969>] ____sys_sendmsg+0x658/0x7d0 net/socket.c:2350 [<00000000964e16bc>] ___sys_sendmsg+0xf8/0x170 net/socket.c:2404 [<000000001615e288>] __sys_sendmsg+0xd3/0x190 net/socket.c:2433 [<000000004ee8b6a5>] do_syscall_64+0x37/0x90 arch/x86/entry/common.c:47 [<00000000171c7cee>] entry_SYSCALL_64_after_hwframe+0x44/0xae The memory of doi_def->map.std pointing is allocated in netlbl_cipsov4_add_std, but no place has freed it. It should be freed in cipso_v4_doi_free which frees the cipso DOI resource. Fixes: 96cb8e3313c7a ("[NetLabel]: CIPSOv4 and Unlabeled packet integration") Reported-by: Hulk Robot Signed-off-by: Nanyong Sun Acked-by: Paul Moore Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 2088824ac90b550221ea7f10cb76b8ca2699f5c1 Author: Kev Jackson Date: Mon Jun 7 14:08:35 2021 +0100 libbpf: Fixes incorrect rx_ring_setup_done [ Upstream commit 11fc79fc9f2e395aa39fa5baccae62767c5d8280 ] When calling xsk_socket__create_shared(), the logic at line 1097 marks a boolean flag true within the xsk_umem structure to track setup progress in order to support multiple calls to the function. However, instead of marking umem->tx_ring_setup_done, the code incorrectly sets umem->rx_ring_setup_done. This leads to improper behaviour when creating and destroying xsk and umem structures. Multiple calls to this function is documented as supported. Fixes: ca7a83e2487a ("libbpf: Only create rx and tx XDP rings when necessary") Signed-off-by: Kev Jackson Signed-off-by: Andrii Nakryiko Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/YL4aU4f3Aaik7CN0@linux-dev Signed-off-by: Sasha Levin commit 195585ddb76721a62890d82bc9815ad1ffef7f9e Author: Mykola Kostenok Date: Sun Jun 6 11:24:32 2021 +0300 mlxsw: core: Set thermal zone polling delay argument to real value at init [ Upstream commit 2fd8d84ce3095e8a7b5fe96532c91b1b9e07339c ] Thermal polling delay argument for modules and gearboxes thermal zones used to be initialized with zero value, while actual delay was used to be set by mlxsw_thermal_set_mode() by thermal operation callback set_mode(). After operations set_mode()/get_mode() have been removed by cited commits, modules and gearboxes thermal zones always have polling time set to zero and do not perform temperature monitoring. Set non-zero "polling_delay" in thermal_zone_device_register() routine, thus, the relevant thermal zones will perform thermal monitoring. Cc: Andrzej Pietrasiewicz Fixes: 5d7bd8aa7c35 ("thermal: Simplify or eliminate unnecessary set_mode() methods") Fixes: 1ee14820fd8e ("thermal: remove get_mode() operation of drivers") Signed-off-by: Mykola Kostenok Acked-by: Vadim Pasternak Reviewed-by: Jiri Pirko Signed-off-by: Ido Schimmel Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit e95848e9b52cbcd412cb5edb1ca9a050e099f471 Author: Petr Machata Date: Sun Jun 6 11:24:30 2021 +0300 mlxsw: reg: Spectrum-3: Enforce lowest max-shaper burst size of 11 [ Upstream commit 306b9228c097b4101c150ccd262372ded8348644 ] A max-shaper is the HW component responsible for delaying egress traffic above a configured transmission rate. Burst size is the amount of traffic that is allowed to pass without accounting. The burst size value needs to be such that it can be expressed as 2^BS * 512 bits, where BS lies in a certain ASIC-dependent range. mlxsw enforces that this holds before attempting to configure the shaper. The assumption for Spectrum-3 was that the lower limit of BS would be 5, like for Spectrum-1. But as of now, the limit is still 11. Therefore fix the driver accordingly, so that incorrect values are rejected early with a proper message. Fixes: 23effa2479ba ("mlxsw: reg: Add max_shaper_bs to QoS ETS Element Configuration") Reported-by: Maksym Yaremchuk Signed-off-by: Petr Machata Signed-off-by: Ido Schimmel Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5a1cd67a801cf5ef989c4783e07b86a25b143126 Author: Du Cheng Date: Mon May 10 12:16:49 2021 +0800 mac80211: fix skb length check in ieee80211_scan_rx() [ Upstream commit e298aa358f0ca658406d524b6639fe389cb6e11e ] Replace hard-coded compile-time constants for header length check with dynamic determination based on the frame type. Otherwise, we hit a validation WARN_ON in cfg80211 later. Fixes: cd418ba63f0c ("mac80211: convert S1G beacon to scan results") Reported-by: syzbot+405843667e93b9790fc1@syzkaller.appspotmail.com Signed-off-by: Du Cheng Link: https://lore.kernel.org/r/20210510041649.589754-1-ducheng2@gmail.com [style fixes, reword commit message] Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 282baa8104af44e04c4af3e7f933b44267c7f86f Author: Sven Eckelmann Date: Tue May 18 21:00:27 2021 +0200 batman-adv: Avoid WARN_ON timing related checks [ Upstream commit 9f460ae31c4435fd022c443a6029352217a16ac1 ] The soft/batadv interface for a queued OGM can be changed during the time the OGM was queued for transmission and when the OGM is actually transmitted by the worker. But WARN_ON must be used to denote kernel bugs and not to print simple warnings. A warning can simply be printed using pr_warn. Reported-by: Tetsuo Handa Reported-by: syzbot+c0b807de416427ff3dd1@syzkaller.appspotmail.com Fixes: ef0a937f7a14 ("batman-adv: consider outgoing interface in OGM sending") Signed-off-by: Sven Eckelmann Signed-off-by: Simon Wunderlich Signed-off-by: Sasha Levin commit ae1d3b989d19e4d8d4fee612a4d24ef992fcd25f Author: Matthew Bobrowski Date: Fri Jun 11 13:32:06 2021 +1000 fanotify: fix copy_event_to_user() fid error clean up [ Upstream commit f644bc449b37cc32d3ce7b36a88073873aa21bd5 ] Ensure that clean up is performed on the allocated file descriptor and struct file object in the event that an error is encountered while copying fid info objects. Currently, we return directly to the caller when an error is experienced in the fid info copying helper, which isn't ideal given that the listener process could be left with a dangling file descriptor in their fdtable. Fixes: 5e469c830fdb ("fanotify: copy event fid info to user") Fixes: 44d705b0370b ("fanotify: report name info for FAN_DIR_MODIFY event") Link: https://lore.kernel.org/linux-fsdevel/YMKv1U7tNPK955ho@google.com/T/#m15361cd6399dad4396aad650de25dbf6b312288e Link: https://lore.kernel.org/r/1ef8ae9100101eb1a91763c516c2e9a3a3b112bd.1623376346.git.repnop@google.com Signed-off-by: Matthew Bobrowski Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit 018685461a5b9a9a70e664ac77aef0d7415a3fd5 Author: Jim Mattson Date: Wed Jun 2 13:52:24 2021 -0700 kvm: LAPIC: Restore guard to prevent illegal APIC register access [ Upstream commit 218bf772bddd221489c38dde6ef8e917131161f6 ] Per the SDM, "any access that touches bytes 4 through 15 of an APIC register may cause undefined behavior and must not be executed." Worse, such an access in kvm_lapic_reg_read can result in a leak of kernel stack contents. Prior to commit 01402cf81051 ("kvm: LAPIC: write down valid APIC registers"), such an access was explicitly disallowed. Restore the guard that was removed in that commit. Fixes: 01402cf81051 ("kvm: LAPIC: write down valid APIC registers") Signed-off-by: Jim Mattson Reported-by: syzbot Message-Id: <20210602205224.3189316-1-jmattson@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 9e379da727a7a031be9b877cde7b9c34a0fb8306 Author: yangerkun Date: Tue Jun 15 18:23:32 2021 -0700 mm/memory-failure: make sure wait for page writeback in memory_failure [ Upstream commit e8675d291ac007e1c636870db880f837a9ea112a ] Our syzkaller trigger the "BUG_ON(!list_empty(&inode->i_wb_list))" in clear_inode: kernel BUG at fs/inode.c:519! Internal error: Oops - BUG: 0 [#1] SMP Modules linked in: Process syz-executor.0 (pid: 249, stack limit = 0x00000000a12409d7) CPU: 1 PID: 249 Comm: syz-executor.0 Not tainted 4.19.95 Hardware name: linux,dummy-virt (DT) pstate: 80000005 (Nzcv daif -PAN -UAO) pc : clear_inode+0x280/0x2a8 lr : clear_inode+0x280/0x2a8 Call trace: clear_inode+0x280/0x2a8 ext4_clear_inode+0x38/0xe8 ext4_free_inode+0x130/0xc68 ext4_evict_inode+0xb20/0xcb8 evict+0x1a8/0x3c0 iput+0x344/0x460 do_unlinkat+0x260/0x410 __arm64_sys_unlinkat+0x6c/0xc0 el0_svc_common+0xdc/0x3b0 el0_svc_handler+0xf8/0x160 el0_svc+0x10/0x218 Kernel panic - not syncing: Fatal exception A crash dump of this problem show that someone called __munlock_pagevec to clear page LRU without lock_page: do_mmap -> mmap_region -> do_munmap -> munlock_vma_pages_range -> __munlock_pagevec. As a result memory_failure will call identify_page_state without wait_on_page_writeback. And after truncate_error_page clear the mapping of this page. end_page_writeback won't call sb_clear_inode_writeback to clear inode->i_wb_list. That will trigger BUG_ON in clear_inode! Fix it by checking PageWriteback too to help determine should we skip wait_on_page_writeback. Link: https://lkml.kernel.org/r/20210604084705.3729204-1-yangerkun@huawei.com Fixes: 0bc1f8b0682c ("hwpoison: fix the handling path of the victimized page frame that belong to non-LRU") Signed-off-by: yangerkun Acked-by: Naoya Horiguchi Cc: Jan Kara Cc: Theodore Ts'o Cc: Oscar Salvador Cc: Yu Kuai Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 090b1bb928a91c6c402ebb067fb32a14f41f6951 Author: Dan Carpenter Date: Tue Jun 15 08:39:52 2021 +0100 afs: Fix an IS_ERR() vs NULL check [ Upstream commit a33d62662d275cee22888fa7760fe09d5b9cd1f9 ] The proc_symlink() function returns NULL on error, it doesn't return error pointers. Fixes: 5b86d4ff5dce ("afs: Implement network namespacing") Signed-off-by: Dan Carpenter Signed-off-by: David Howells cc: linux-afs@lists.infradead.org Link: https://lore.kernel.org/r/YLjMRKX40pTrJvgf@mwanda/ Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 5efb0b3886c3f9fa965e35b3d132c5c108df7bef Author: Yang Yingliang Date: Tue May 18 22:11:08 2021 +0800 dmaengine: stedma40: add missing iounmap() on error in d40_probe() [ Upstream commit fffdaba402cea79b8d219355487d342ec23f91c6 ] Add the missing iounmap() before return from d40_probe() in the error handling case. Fixes: 8d318a50b3d7 ("DMAENGINE: Support for ST-Ericssons DMA40 block v3") Reported-by: Hulk Robot Signed-off-by: Yang Yingliang Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/20210518141108.1324127-1-yangyingliang@huawei.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit ff864fa71aa03fe73b9c74a9df30951cd85bcf23 Author: Randy Dunlap Date: Fri May 21 19:13:12 2021 -0700 dmaengine: SF_PDMA depends on HAS_IOMEM [ Upstream commit 8e2e4f3c58528c6040b5762b666734f8cceba568 ] When CONFIG_HAS_IOMEM is not set/enabled, certain iomap() family functions [including ioremap(), devm_ioremap(), etc.] are not available. Drivers that use these functions should depend on HAS_IOMEM so that they do not cause build errors. Mends this build error: s390-linux-ld: drivers/dma/sf-pdma/sf-pdma.o: in function `sf_pdma_probe': sf-pdma.c:(.text+0x1668): undefined reference to `devm_ioremap_resource' Fixes: 6973886ad58e ("dmaengine: sf-pdma: add platform DMA support for HiFive Unleashed A00") Signed-off-by: Randy Dunlap Reported-by: kernel test robot Cc: Green Wan Cc: Vinod Koul Cc: dmaengine@vger.kernel.org Link: https://lore.kernel.org/r/20210522021313.16405-4-rdunlap@infradead.org Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit c0090b0169d608bfc8c47ebfc6158b04fcdc0a07 Author: Randy Dunlap Date: Fri May 21 19:13:11 2021 -0700 dmaengine: QCOM_HIDMA_MGMT depends on HAS_IOMEM [ Upstream commit 0cfbb589d67f16fa55b26ae02b69c31b52e344b1 ] When CONFIG_HAS_IOMEM is not set/enabled, certain iomap() family functions [including ioremap(), devm_ioremap(), etc.] are not available. Drivers that use these functions should depend on HAS_IOMEM so that they do not cause build errors. Rectifies these build errors: s390-linux-ld: drivers/dma/qcom/hidma_mgmt.o: in function `hidma_mgmt_probe': hidma_mgmt.c:(.text+0x780): undefined reference to `devm_ioremap_resource' s390-linux-ld: drivers/dma/qcom/hidma_mgmt.o: in function `hidma_mgmt_init': hidma_mgmt.c:(.init.text+0x126): undefined reference to `of_address_to_resource' s390-linux-ld: hidma_mgmt.c:(.init.text+0x16e): undefined reference to `of_address_to_resource' Fixes: 67a2003e0607 ("dmaengine: add Qualcomm Technologies HIDMA channel driver") Signed-off-by: Randy Dunlap Reported-by: kernel test robot Cc: Sinan Kaya Cc: Vinod Koul Cc: dmaengine@vger.kernel.org Link: https://lore.kernel.org/r/20210522021313.16405-3-rdunlap@infradead.org Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit f984fa006b8b6d94e6c819f72a0376713e39526f Author: Randy Dunlap Date: Fri May 21 19:13:10 2021 -0700 dmaengine: ALTERA_MSGDMA depends on HAS_IOMEM [ Upstream commit 253697b93c2a1c237d34d3ae326e394aeb0ca7b3 ] When CONFIG_HAS_IOMEM is not set/enabled, certain iomap() family functions [including ioremap(), devm_ioremap(), etc.] are not available. Drivers that use these functions should depend on HAS_IOMEM so that they do not cause build errors. Repairs this build error: s390-linux-ld: drivers/dma/altera-msgdma.o: in function `request_and_map': altera-msgdma.c:(.text+0x14b0): undefined reference to `devm_ioremap' Fixes: a85c6f1b2921 ("dmaengine: Add driver for Altera / Intel mSGDMA IP core") Signed-off-by: Randy Dunlap Reported-by: kernel test robot Cc: Stefan Roese Cc: Vinod Koul Cc: dmaengine@vger.kernel.org Reviewed-by: Stefan Roese Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: sr@denx.de Link: https://lore.kernel.org/r/20210522021313.16405-2-rdunlap@infradead.org Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit be4789636f72e3651d0d3a00a347b277c70ab5f9 Author: Quanyang Wang Date: Fri Apr 30 14:40:41 2021 +0800 dmaengine: xilinx: dpdma: initialize registers before request_irq [ Upstream commit 538ea65a9fd1194352a41313bff876b74b5d90c5 ] In some scenarios (kdump), dpdma hardware irqs has been enabled when calling request_irq in probe function, and then the dpdma irq handler xilinx_dpdma_irq_handler is invoked to access xdev->chan[i]. But at this moment xdev->chan[i] hasn't been initialized. We should ensure the dpdma controller to be in a consistent and clean state before further initialization. So add dpdma_hw_init() to do this. Furthermore, in xilinx_dpdma_disable_irq, disable all interrupts instead of error interrupts. This patch is to fix the kdump kernel crash as below: [ 3.696128] Unable to handle kernel NULL pointer dereference at virtual address 000000000000012c [ 3.696710] xilinx-zynqmp-dpdma fd4c0000.dma-controller: Xilinx DPDMA engine is probed [ 3.704900] Mem abort info: [ 3.704902] ESR = 0x96000005 [ 3.704905] EC = 0x25: DABT (current EL), IL = 32 bits [ 3.704907] SET = 0, FnV = 0 [ 3.704912] EA = 0, S1PTW = 0 [ 3.713800] ahci-ceva fd0c0000.ahci: supply ahci not found, using dummy regulator [ 3.715585] Data abort info: [ 3.715587] ISV = 0, ISS = 0x00000005 [ 3.715589] CM = 0, WnR = 0 [ 3.715592] [000000000000012c] user address but active_mm is swapper [ 3.715596] Internal error: Oops: 96000005 [#1] SMP [ 3.715599] Modules linked in: [ 3.715608] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.0-12170-g60894882155f-dirty #77 [ 3.723937] Hardware name: ZynqMP ZCU102 Rev1.0 (DT) [ 3.723942] pstate: 80000085 (Nzcv daIf -PAN -UAO -TCO BTYPE=--) [ 3.723956] pc : xilinx_dpdma_irq_handler+0x418/0x560 [ 3.793049] lr : xilinx_dpdma_irq_handler+0x3d8/0x560 [ 3.798089] sp : ffffffc01186bdf0 [ 3.801388] x29: ffffffc01186bdf0 x28: ffffffc011836f28 [ 3.806692] x27: ffffff8023e0ac80 x26: 0000000000000080 [ 3.811996] x25: 0000000008000408 x24: 0000000000000003 [ 3.817300] x23: ffffffc01186be70 x22: ffffffc011291740 [ 3.822604] x21: 0000000000000000 x20: 0000000008000408 [ 3.827908] x19: 0000000000000000 x18: 0000000000000010 [ 3.833212] x17: 0000000000000000 x16: 0000000000000000 [ 3.838516] x15: 0000000000000000 x14: ffffffc011291740 [ 3.843820] x13: ffffffc02eb4d000 x12: 0000000034d4d91d [ 3.849124] x11: 0000000000000040 x10: ffffffc0112d2d48 [ 3.854428] x9 : ffffffc0112d2d40 x8 : ffffff8021c00268 [ 3.859732] x7 : 0000000000000000 x6 : ffffffc011836000 [ 3.865036] x5 : 0000000000000003 x4 : 0000000000000000 [ 3.870340] x3 : 0000000000000001 x2 : 0000000000000000 [ 3.875644] x1 : 0000000000000000 x0 : 000000000000012c [ 3.880948] Call trace: [ 3.883382] xilinx_dpdma_irq_handler+0x418/0x560 [ 3.888079] __handle_irq_event_percpu+0x5c/0x178 [ 3.892774] handle_irq_event_percpu+0x34/0x98 [ 3.897210] handle_irq_event+0x44/0xb8 [ 3.901030] handle_fasteoi_irq+0xd0/0x190 [ 3.905117] generic_handle_irq+0x30/0x48 [ 3.909111] __handle_domain_irq+0x64/0xc0 [ 3.913192] gic_handle_irq+0x78/0xa0 [ 3.916846] el1_irq+0xc4/0x180 [ 3.919982] cpuidle_enter_state+0x134/0x2f8 [ 3.924243] cpuidle_enter+0x38/0x50 [ 3.927810] call_cpuidle+0x1c/0x40 [ 3.931290] do_idle+0x20c/0x270 [ 3.934502] cpu_startup_entry+0x28/0x58 [ 3.938410] rest_init+0xbc/0xcc [ 3.941631] arch_call_rest_init+0x10/0x1c [ 3.945718] start_kernel+0x51c/0x558 Fixes: 7cbb0c63de3f ("dmaengine: xilinx: dpdma: Add the Xilinx DisplayPort DMA engine driver") Signed-off-by: Quanyang Wang Link: https://lore.kernel.org/r/20210430064041.4058180-1-quanyang.wang@windriver.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit edd60afc3fc338c859b8a50fdc4b6e3bef0d2cec Author: Zhen Lei Date: Sat May 8 11:00:56 2021 +0800 dmaengine: fsl-dpaa2-qdma: Fix error return code in two functions [ Upstream commit 17866bc6b2ae1c3075c9fe7bcbeb8ea50eb4c3fc ] Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in the function where it is. Fixes: 7fdf9b05c73b ("dmaengine: fsl-dpaa2-qdma: Add NXP dpaa2 qDMA controller driver for Layerscape SoCs") Reported-by: Hulk Robot Signed-off-by: Zhen Lei Link: https://lore.kernel.org/r/20210508030056.2027-1-thunder.leizhen@huawei.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 4d74c980232885df11f972c0c816f516016240dd Author: Dave Jiang Date: Mon Apr 26 16:32:24 2021 -0700 dmaengine: idxd: add missing dsa driver unregister [ Upstream commit 077cdb355b3d8ee0f258856962e6dac06e744401 ] The idxd_unregister_driver() has never been called for the idxd driver upon removal. Add fix to call unregister driver on module removal. Fixes: c52ca478233c ("dmaengine: idxd: add configuration component of driver") Signed-off-by: Dave Jiang Link: https://lore.kernel.org/r/161947994449.1053102.13189942817915448216.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 037a447b7a0baa71593cb9a57ac7bdb7b9303c01 Author: Greg Kroah-Hartman Date: Fri Jun 18 10:00:06 2021 +0200 Linux 5.10.45 Link: https://lore.kernel.org/r/20210616152835.407925718@linuxfoundation.org Tested-by: Jon Hunter Tested-by: Fox Chen Tested-by: Florian Fainelli Tested-by: Pavel Machek (CIP) Tested-by: Linux Kernel Functional Testing Tested-by: Hulk Robot Tested-by: Sudip Mukherjee Tested-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 808fcc1e707c21a2a6492c8bec65a7cc6eb8b94e Author: Zheng Yongjun Date: Wed Jun 2 22:06:58 2021 +0800 fib: Return the correct errno code [ Upstream commit 59607863c54e9eb3f69afc5257dfe71c38bb751e ] When kalloc or kmemdup failed, should return ENOMEM rather than ENOBUF. Signed-off-by: Zheng Yongjun Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d8b2e3e17c33ab4874a7431d6c314c4939145160 Author: Zheng Yongjun Date: Wed Jun 2 22:06:40 2021 +0800 net: Return the correct errno code [ Upstream commit 49251cd00228a3c983651f6bb2f33f6a0b8f152e ] When kalloc or kmemdup failed, should return ENOMEM rather than ENOBUF. Signed-off-by: Zheng Yongjun Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 04c1556bfc79734ae91af632aff2f754a501c36c Author: Zheng Yongjun Date: Wed Jun 2 22:06:30 2021 +0800 net/x25: Return the correct errno code [ Upstream commit d7736958668c4facc15f421e622ffd718f5be80a ] When kalloc or kmemdup failed, should return ENOMEM rather than ENOBUF. Signed-off-by: Zheng Yongjun Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 0aa356950800e18a96c78633cadaf1d1c6c33d7d Author: Jiapeng Chong Date: Wed Jun 2 18:15:04 2021 +0800 rtnetlink: Fix missing error code in rtnl_bridge_notify() [ Upstream commit a8db57c1d285c758adc7fb43d6e2bad2554106e1 ] The error code is missing in this code scenario, add the error code '-EINVAL' to the return value 'err'. Eliminate the follow smatch warning: net/core/rtnetlink.c:4834 rtnl_bridge_notify() warn: missing error code 'err'. Reported-by: Abaci Robot Signed-off-by: Jiapeng Chong Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 9250f97fd59416448299f923fba2c69c1a308a07 Author: Victor Zhao Date: Thu Mar 18 13:44:35 2021 +0800 drm/amd/amdgpu:save psp ring wptr to avoid attack [ Upstream commit 2370eba9f552eaae3d8aa1f70b8e9eec5c560f9e ] [Why] When some tools performing psp mailbox attack, the readback value of register can be a random value which may break psp. [How] Use a psp wptr cache machanism to aovid the change made by attack. v2: unify change and add detailed reason Signed-off-by: Victor Zhao Signed-off-by: Jingwen Chen Reviewed-by: Monk Liu Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 9e8c2af010463197315fa54a6c17e74988b5259c Author: Roman Li Date: Mon May 10 11:58:54 2021 -0400 drm/amd/display: Fix potential memory leak in DMUB hw_init [ Upstream commit c5699e2d863f58221044efdc3fa712dd32d55cde ] [Why] On resume we perform DMUB hw_init which allocates memory: dm_resume->dm_dmub_hw_init->dc_dmub_srv_create->kzalloc That results in memory leak in suspend/resume scenarios. [How] Allocate memory for the DC wrapper to DMUB only if it was not allocated before. No need to reallocate it on suspend/resume. Signed-off-by: Lang Yu Signed-off-by: Roman Li Reviewed-by: Nicholas Kazlauskas Acked-by: Qingqing Zhuo Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 75fa7fbef1325ab56404b0afcd5822d11b844664 Author: Jiansong Chen Date: Tue May 25 14:14:58 2021 +0800 drm/amdgpu: refine amdgpu_fru_get_product_info [ Upstream commit 5cfc912582e13b05d71fb7acc4ec69ddfa9af320 ] 1. eliminate potential array index out of bounds. 2. return meaningful value for failure. Signed-off-by: Jiansong Chen Reviewed-by: Jack Gui Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 34fe4ccb1fe52b5c58d3730c6732e6971dc3564b Author: Bindu Ramamurthy Date: Thu May 20 10:06:04 2021 -0400 drm/amd/display: Allow bandwidth validation for 0 streams. [ Upstream commit ba8e59773ae59818695d1e20b8939282da80ec8c ] [Why] Bandwidth calculations are triggered for non zero streams, and in case of 0 streams, these calculations were skipped with pstate status not being updated. [How] As the pstate status is applicable for non zero streams, check added for allowing 0 streams inline with dcn internal bandwidth validations. Signed-off-by: Bindu Ramamurthy Reviewed-by: Roman Li Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit ecd26536ec5b2490ac3089413cd7013b3890b6d6 Author: Josh Triplett Date: Tue Jun 1 18:38:41 2021 -0700 net: ipconfig: Don't override command-line hostnames or domains [ Upstream commit b508d5fb69c2211a1b860fc058aafbefc3b3c3cd ] If the user specifies a hostname or domain name as part of the ip= command-line option, preserve it and don't overwrite it with one supplied by DHCP/BOOTP. For instance, ip=::::myhostname::dhcp will use "myhostname" rather than ignoring and overwriting it. Fix the comment on ic_bootp_string that suggests it only copies a string "if not already set"; it doesn't have any such logic. Signed-off-by: Josh Triplett Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 511a01029115e94226e52bad6052ef1f5da8cb6f Author: Hannes Reinecke Date: Wed May 26 17:23:18 2021 +0200 nvme-loop: do not warn for deleted controllers during reset [ Upstream commit 6622f9acd29cd4f6272720e827e6406f5a970cb0 ] During concurrent reset and delete calls the reset workqueue is flushed, causing nvme_loop_reset_ctrl_work() to be executed when the controller is in state DELETING or DELETING_NOIO. But this is expected, so we shouldn't issue a WARN_ON here. Signed-off-by: Hannes Reinecke Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 155c2fea4b31fc0ca5b3028c1ceea03c49ec8884 Author: Hannes Reinecke Date: Wed May 26 17:23:17 2021 +0200 nvme-loop: check for NVME_LOOP_Q_LIVE in nvme_loop_destroy_admin_queue() [ Upstream commit 4237de2f73a669e4f89ac0aa2b44fb1a1d9ec583 ] We need to check the NVME_LOOP_Q_LIVE flag in nvme_loop_destroy_admin_queue() to protect against duplicate invocations eg during concurrent reset and remove calls. Signed-off-by: Hannes Reinecke Reviewed-by: Chaitanya Kulkarni Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 620424df29a0bf8fe0da7b9c96692e61bba704cf Author: Hannes Reinecke Date: Wed May 26 17:23:16 2021 +0200 nvme-loop: clear NVME_LOOP_Q_LIVE when nvme_loop_configure_admin_queue() fails [ Upstream commit 1c5f8e882a05de5c011e8c3fbeceb0d1c590eb53 ] When the call to nvme_enable_ctrl() in nvme_loop_configure_admin_queue() fails the NVME_LOOP_Q_LIVE flag is not cleared. Signed-off-by: Hannes Reinecke Reviewed-by: Chaitanya Kulkarni Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 1c80ca596cab61ee03f20b591eea8c51a2c85b4d Author: Hannes Reinecke Date: Wed May 26 17:23:15 2021 +0200 nvme-loop: reset queue count to 1 in nvme_loop_destroy_io_queues() [ Upstream commit a6c144f3d2e230f2b3ac5ed8c51e0f0391556197 ] The queue count is increased in nvme_loop_init_io_queues(), so we need to reset it to 1 at the end of nvme_loop_destroy_io_queues(). Otherwise the function is not re-entrant safe, and crash will happen during concurrent reset and remove calls. Signed-off-by: Hannes Reinecke Reviewed-by: Chaitanya Kulkarni Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit b8fdea0695fd7ac382a35fe958a9e7c8f1f71685 Author: Ewan D. Milne Date: Tue Jun 1 13:52:14 2021 -0400 scsi: scsi_devinfo: Add blacklist entry for HPE OPEN-V [ Upstream commit e57f5cd99ca60cddf40201b0f4ced9f1938e299c ] Apparently some arrays are now returning "HPE" as the vendor. Link: https://lore.kernel.org/r/20210601175214.25719-1-emilne@redhat.com Signed-off-by: Ewan D. Milne Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit f8ac1bd5270b9d51d474cc39617a2e97b8e30275 Author: Larry Finger Date: Tue Jun 1 14:04:18 2021 -0500 Bluetooth: Add a new USB ID for RTL8822CE [ Upstream commit 4d96d3b0efee6416ef0d61b76aaac6f4a2e15b12 ] Some models of the RTL8822ce utilize a different USB ID. Add this new one to the Bluetooth driver. Signed-off-by: Larry Finger Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 5491d97078fe173b1b16966d2c4ec78f14e07eef Author: Daniel Wagner Date: Fri May 21 16:34:40 2021 +0200 scsi: qedf: Do not put host in qedf_vport_create() unconditionally [ Upstream commit 79c932cd6af9829432888c4a0001d01793a09f12 ] Do not drop reference count on vn_port->host in qedf_vport_create() unconditionally. Instead drop the reference count in qedf_vport_destroy(). Link: https://lore.kernel.org/r/20210521143440.84816-1-dwagner@suse.de Reported-by: Javed Hasan Signed-off-by: Daniel Wagner Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 609b56e9791c27d9b07a30a811b6868453950d4c Author: Jiapeng Chong Date: Tue Jun 1 19:04:51 2021 +0800 ethernet: myri10ge: Fix missing error code in myri10ge_probe() [ Upstream commit f336d0b93ae978f12c5e27199f828da89b91e56a ] The error code is missing in this code scenario, add the error code '-EINVAL' to the return value 'status'. Eliminate the follow smatch warning: drivers/net/ethernet/myricom/myri10ge/myri10ge.c:3818 myri10ge_probe() warn: missing error code 'status'. Reported-by: Abaci Robot Signed-off-by: Jiapeng Chong Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5d5f0d945d475b01e0d81894345f0b36acaf4d02 Author: Maurizio Lombardi Date: Mon May 31 14:13:26 2021 +0200 scsi: target: core: Fix warning on realtime kernels [ Upstream commit 515da6f4295c2c42b8c54572cce3d2dd1167c41e ] On realtime kernels, spin_lock_irq*(spinlock_t) do not disable the interrupts, a call to irqs_disabled() will return false thus firing a warning in __transport_wait_for_tasks(). Remove the warning and also replace assert_spin_locked() with lockdep_assert_held() Link: https://lore.kernel.org/r/20210531121326.3649-1-mlombard@redhat.com Reviewed-by: Bart Van Assche Signed-off-by: Maurizio Lombardi Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit a61156314b66456ab6a291ed5deba1ebd002ab3c Author: Hillf Danton Date: Tue May 18 16:46:25 2021 +0800 gfs2: Fix use-after-free in gfs2_glock_shrink_scan [ Upstream commit 1ab19c5de4c537ec0d9b21020395a5b5a6c059b2 ] The GLF_LRU flag is checked under lru_lock in gfs2_glock_remove_from_lru() to remove the glock from the lru list in __gfs2_glock_put(). On the shrink scan path, the same flag is cleared under lru_lock but because of cond_resched_lock(&lru_lock) in gfs2_dispose_glock_lru(), progress on the put side can be made without deleting the glock from the lru list. Keep GLF_LRU across the race window opened by cond_resched_lock(&lru_lock) to ensure correct behavior on both sides - clear GLF_LRU after list_del under lru_lock. Reported-by: syzbot Signed-off-by: Hillf Danton Signed-off-by: Andreas Gruenbacher Signed-off-by: Sasha Levin commit bb73f2f789695028a4cc8baf9d6a8df03fb5ae14 Author: Khem Raj Date: Fri May 14 14:37:41 2021 -0700 riscv: Use -mno-relax when using lld linker [ Upstream commit ec3a5cb61146c91f0f7dcec8b7e7157a4879a9ee ] lld does not implement the RISCV relaxation optimizations like GNU ld therefore disable it when building with lld, Also pass it to assembler when using external GNU assembler ( LLVM_IAS != 1 ), this ensures that relevant assembler option is also enabled along. if these options are not used then we see following relocations in objects 0000000000000000 R_RISCV_ALIGN *ABS*+0x0000000000000002 These are then rejected by lld ld.lld: error: capability.c:(.fixup+0x0): relocation R_RISCV_ALIGN requires unimplemented linker relaxation; recompile with -mno-relax but the .o is already compiled with -mno-relax Signed-off-by: Khem Raj Reviewed-by: Nathan Chancellor Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin commit 35277c1a6669033823d983daa9a1df66e366b688 Author: Bixuan Cui Date: Sat May 8 11:14:48 2021 +0800 HID: gt683r: add missing MODULE_DEVICE_TABLE [ Upstream commit a4b494099ad657f1cb85436d333cf38870ee95bc ] This patch adds missing MODULE_DEVICE_TABLE definition which generates correct modalias for automatic loading of this driver when it is built as an external module. Reported-by: Hulk Robot Signed-off-by: Bixuan Cui Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 7a557de07917600a12bcb9867acad771e4b29837 Author: Bob Peterson Date: Tue May 18 09:14:31 2021 -0400 gfs2: fix a deadlock on withdraw-during-mount [ Upstream commit 865cc3e9cc0b1d4b81c10d53174bced76decf888 ] Before this patch, gfs2 would deadlock because of the following sequence during mount: mount gfs2_fill_super gfs2_make_fs_rw <--- Detects IO error with glock kthread_stop(sdp->sd_quotad_process); <--- Blocked waiting for quotad to finish logd Detects IO error and the need to withdraw calls gfs2_withdraw gfs2_make_fs_ro kthread_stop(sdp->sd_quotad_process); <--- Blocked waiting for quotad to finish gfs2_quotad gfs2_statfs_sync gfs2_glock_wait <---- Blocked waiting for statfs glock to be granted glock_work_func do_xmote <---Detects IO error, can't release glock: blocked on withdraw glops->go_inval glock_blocked_by_withdraw requeue glock work & exit <--- work requeued, blocked by withdraw This patch makes a special exception for the statfs system inode glock, which allows the statfs glock UNLOCK to proceed normally. That allows the quotad daemon to exit during the withdraw, which allows the logd daemon to exit during the withdraw, which allows the mount to exit. Signed-off-by: Bob Peterson Signed-off-by: Andreas Gruenbacher Signed-off-by: Sasha Levin commit c3e9ea16adc1ce378e7c1416dace0c93631e2fcc Author: Andreas Gruenbacher Date: Mon May 10 12:25:59 2021 +0200 gfs2: Prevent direct-I/O write fallback errors from getting lost [ Upstream commit 43a511c44e58e357a687d61a20cf5ef1dc9e5a7c ] When a direct I/O write falls entirely and falls back to buffered I/O and the buffered I/O fails, the write failed with return value 0 instead of the error number reported by the buffered I/O. Fix that. Signed-off-by: Andreas Gruenbacher Signed-off-by: Sasha Levin commit 864b5a8d5390765ddb8e82b86b111de86868d65f Author: Yongqiang Liu Date: Thu Apr 1 13:15:33 2021 +0000 ARM: OMAP2+: Fix build warning when mmc_omap is not built [ Upstream commit 040ab72ee10ea88e1883ad143b3e2b77596abc31 ] GCC reports the following warning with W=1: arch/arm/mach-omap2/board-n8x0.c:325:19: warning: variable 'index' set but not used [-Wunused-but-set-variable] 325 | int bit, *openp, index; | ^~~~~ Fix this by moving CONFIG_MMC_OMAP to cover the rest codes in the n8x0_mmc_callback(). Signed-off-by: Yongqiang Liu Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit 247ec8ee0bf2d89b7075c11d9d40563d2fb0a92c Author: Maciej Falkowski Date: Thu Apr 1 18:11:27 2021 +0200 ARM: OMAP1: Fix use of possibly uninitialized irq variable [ Upstream commit 3c4e0147c269738a19c7d70cd32395600bcc0714 ] The current control flow of IRQ number assignment to `irq` variable allows a request of IRQ of unspecified value, generating a warning under Clang compilation with omap1_defconfig on linux-next: arch/arm/mach-omap1/pm.c:656:11: warning: variable 'irq' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized] else if (cpu_is_omap16xx()) ^~~~~~~~~~~~~~~~~ ./arch/arm/mach-omap1/include/mach/soc.h:123:30: note: expanded from macro 'cpu_is_omap16xx' ^~~~~~~~~~~~~ arch/arm/mach-omap1/pm.c:658:18: note: uninitialized use occurs here if (request_irq(irq, omap_wakeup_interrupt, 0, "peripheral wakeup", ^~~ arch/arm/mach-omap1/pm.c:656:7: note: remove the 'if' if its condition is always true else if (cpu_is_omap16xx()) ^~~~~~~~~~~~~~~~~~~~~~ arch/arm/mach-omap1/pm.c:611:9: note: initialize the variable 'irq' to silence this warning int irq; ^ = 0 1 warning generated. The patch provides a default value to the `irq` variable along with a validity check. Signed-off-by: Maciej Falkowski Link: https://github.com/ClangBuiltLinux/linux/issues/1324 Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit 3c0ad70cba1f103e829bd4f233f9f4a63d30f5bb Author: Thierry Reding Date: Thu Apr 1 17:41:05 2021 +0200 drm/tegra: sor: Fully initialize SOR before registration [ Upstream commit 5dea42759bcef74b0802ea64b904409bc37f9045 ] Before registering the SOR host1x client, make sure that it is fully initialized. This avoids a potential race condition between the SOR's probe and the host1x device initialization in cases where the SOR is the final sub-device to register to a host1x instance. Reported-by: Jonathan Hunter Signed-off-by: Thierry Reding Tested-by: Jon Hunter Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 9c1d492baa9128b970524b9baa4b9baa7dc01c64 Author: Thierry Reding Date: Thu Apr 1 17:41:04 2021 +0200 gpu: host1x: Split up client initalization and registration [ Upstream commit 0cfe5a6e758fb20be8ad3e8f10cb087cc8033eeb ] In some cases we may need to initialize the host1x client first before registering it. This commit adds a new helper that will do nothing but the initialization of the data structure. At the same time, the initialization is removed from the registration function. Note, however, that for simplicity we explicitly initialize the client when the host1x_client_register() function is called, as opposed to the low-level __host1x_client_register() function. This allows existing callers to remain unchanged. Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 570b3e4020f2aa7ab6908042e7f3a41ab24ce261 Author: Pavel Machek (CIP) Date: Tue Apr 6 13:54:14 2021 +0200 drm/tegra: sor: Do not leak runtime PM reference [ Upstream commit 73a395c46704304b96bc5e2ee19be31124025c0c ] It's theoretically possible for the runtime PM reference to leak if the code fails anywhere between the pm_runtime_resume_and_get() and pm_runtime_put() calls, so make sure to release the runtime PM reference in that case. Practically this will never happen because none of the functions will fail on Tegra, but it's better for the code to be pedantic in case these assumptions will ever become wrong. Signed-off-by: Pavel Machek (CIP) [treding@nvidia.com: add commit message] Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit b1e3596416d74ce95cc0b7b38472329a3818f8a9 Author: Anirudh Rayabharam Date: Sun Apr 25 23:03:53 2021 +0530 HID: usbhid: fix info leak in hid_submit_ctrl [ Upstream commit 6be388f4a35d2ce5ef7dbf635a8964a5da7f799f ] In hid_submit_ctrl(), the way of calculating the report length doesn't take into account that report->size can be zero. When running the syzkaller reproducer, a report of size 0 causes hid_submit_ctrl) to calculate transfer_buffer_length as 16384. When this urb is passed to the usb core layer, KMSAN reports an info leak of 16384 bytes. To fix this, first modify hid_report_len() to account for the zero report size case by using DIV_ROUND_UP for the division. Then, call it from hid_submit_ctrl(). Reported-by: syzbot+7c2bb71996f95a82524c@syzkaller.appspotmail.com Signed-off-by: Anirudh Rayabharam Acked-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 1dfd9f18ca64475d9d34e2b03955b6308b2282b1 Author: Mark Bolhuis Date: Mon May 3 17:39:38 2021 +0100 HID: Add BUS_VIRTUAL to hid_connect logging [ Upstream commit 48e33befe61a7d407753c53d1a06fc8d6b5dab80 ] Add BUS_VIRTUAL to hid_connect logging since it's a valid hid bus type and it should not print Signed-off-by: Mark Bolhuis Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 258d3fdbb15e73d40f498b2f9632a99e980c24a9 Author: Ahelenia Ziemiańska Date: Mon Mar 8 18:42:08 2021 +0100 HID: multitouch: set Stylus suffix for Stylus-application devices, too [ Upstream commit bc8b796f618c3ccb0a2a8ed1e96c00a1a7849415 ] This re-adds the suffix to Win8 stylus-on-touchscreen devices, now that they aren't erroneously marked as MT Signed-off-by: Ahelenia Ziemiańska Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 6a142ea61074b9268fc03f0cb2de93972450de0a Author: Saeed Mirzamohammadi Date: Thu Apr 29 11:50:39 2021 -0700 HID: quirks: Add quirk for Lenovo optical mouse [ Upstream commit 3b2520076822f15621509a6da3bc4a8636cd33b4 ] The Lenovo optical mouse with vendor id of 0x17ef and product id of 0x600e experiences disconnecting issues every 55 seconds: [38565.706242] usb 1-1.4: Product: Lenovo Optical Mouse [38565.728603] input: Lenovo Optical Mouse as /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.4/1-1.4:1.0/0003:17EF:600E.029A/input/input665 [38565.755949] hid-generic 0003:17EF:600E.029A: input,hidraw1: USB HID v1.11 Mouse [Lenovo Optical Mouse] on usb-0000:01:00.0-1.4/input0 [38619.360692] usb 1-1.4: USB disconnect, device number 48 [38620.864990] usb 1-1.4: new low-speed USB device number 49 using xhci_hcd [38620.984011] usb 1-1.4: New USB device found, idVendor=17ef,idProduct=600e, bcdDevice= 1.00 [38620.998117] usb 1-1.4: New USB device strings: Mfr=0, Product=2,SerialNumber=0 This adds HID_QUIRK_ALWAYS_POLL for this device in order to work properly. Signed-off-by: Saeed Mirzamohammadi Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 716a087adc22db5b2c4dc869fae85b1eeedd28ad Author: Srinivas Pandruvada Date: Thu Apr 15 11:52:31 2021 -0700 HID: hid-sensor-hub: Return error for hid_set_field() failure [ Upstream commit edb032033da0dc850f6e7740fa1023c73195bc89 ] In the function sensor_hub_set_feature(), return error when hid_set_field() fails. Signed-off-by: Srinivas Pandruvada Acked-by: Jonathan Cameron Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 0bd8a4b46cdb46541044b784a515a0f6613002ee Author: Dmitry Torokhov Date: Sat Apr 10 19:56:05 2021 -0700 HID: hid-input: add mapping for emoji picker key [ Upstream commit 7b229b13d78d112e2c5d4a60a3c6f602289959fa ] HUTRR101 added a new usage code for a key that is supposed to invoke and dismiss an emoji picker widget to assist users to locate and enter emojis. This patch adds a new key definition KEY_EMOJI_PICKER and maps 0x0c/0x0d9 usage code to this new keycode. Additionally hid-debug is adjusted to recognize this new usage code as well. Signed-off-by: Dmitry Torokhov Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit b3c5bfc43c5efc0ba6fec752bf5f5e852a1ef913 Author: Mateusz Jończyk Date: Tue Apr 6 20:25:38 2021 +0200 HID: a4tech: use A4_2WHEEL_MOUSE_HACK_B8 for A4TECH NB-95 [ Upstream commit 9858c74c29e12be5886280725e781cb735b2aca6 ] This mouse has a horizontal wheel that requires special handling. Without this patch, the horizontal wheel acts like a vertical wheel. In the output of `hidrd-convert` for this mouse, there is a `Usage (B8h)` field. It corresponds to a byte in packets sent by the device that specifies which wheel generated an input event. The name "A4TECH" is spelled in all capitals on the company website. Signed-off-by: Mateusz Jończyk Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit be6c9887920560b59b9d7d38261ebccdb876c470 Author: Nirenjan Krishnan Date: Mon Mar 29 09:10:02 2021 -0700 HID: quirks: Set INCREMENT_USAGE_ON_DUPLICATE for Saitek X65 [ Upstream commit 25bdbfbb2d8331a67824dd03d0087e9c98835f3a ] The Saitek X65 joystick has a pair of axes that were used as mouse pointer controls by the Windows driver. The corresponding usage page is the Game Controls page, which is not recognized by the generic HID driver, and therefore, both axes get mapped to ABS_MISC. The quirk makes the second axis get mapped to ABS_MISC+1, and therefore made available separately. Signed-off-by: Nirenjan Krishnan Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit c7836de2cadd88bc2f20f2c5a3d4ef4c73aef627 Author: Dan Robertson Date: Fri Apr 23 00:02:13 2021 -0400 net: ieee802154: fix null deref in parse dev addr [ Upstream commit 9fdd04918a452980631ecc499317881c1d120b70 ] Fix a logic error that could result in a null deref if the user sets the mode incorrectly for the given addr type. Signed-off-by: Dan Robertson Acked-by: Alexander Aring Link: https://lore.kernel.org/r/20210423040214.15438-2-dan@dlrobertson.com Signed-off-by: Stefan Schmidt Signed-off-by: Sasha Levin commit f2b1fc360fa1283b61359f232c6965f4170260f0 Author: Greg Kroah-Hartman Date: Wed Jun 16 12:01:47 2021 +0200 Linux 5.10.44 Link: https://lore.kernel.org/r/20210614102652.964395392@linuxfoundation.org Tested-by: Fox Chen Tested-by: Jon Hunter Tested-by: Florian Fainelli Tested-by: Pavel Machek (CIP) Tested-by: Hulk Robot Link: https://lore.kernel.org/r/20210614161424.091266895@linuxfoundation.org Tested-by: Jon Hunter Tested-by: Fox Chen Tested-by: Pavel Machek (CIP) Tested-by: Florian Fainelli Tested-by: Salvatore Bonaccorso Tested-by: Shuah Khan Tested-by: Jason Self Tested-by: Hulk Robot Tested-by: Sudip Mukherjee Tested-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit ef9a0d224bafc0f4f8f85d0eb69fc59a6fbd1318 Author: Linus Torvalds Date: Tue Jun 15 09:26:19 2021 -0700 proc: only require mm_struct for writing commit 94f0b2d4a1d0c52035aef425da5e022bd2cb1c71 upstream. Commit 591a22c14d3f ("proc: Track /proc/$pid/attr/ opener mm_struct") we started using __mem_open() to track the mm_struct at open-time, so that we could then check it for writes. But that also ended up making the permission checks at open time much stricter - and not just for writes, but for reads too. And that in turn caused a regression for at least Fedora 29, where NIC interfaces fail to start when using NetworkManager. Since only the write side wanted the mm_struct test, ignore any failures by __mem_open() at open time, leaving reads unaffected. The write() time verification of the mm_struct pointer will then catch the failure case because a NULL pointer will not match a valid 'current->mm'. Link: https://lore.kernel.org/netdev/YMjTlp2FSJYvoyFa@unreal/ Fixes: 591a22c14d3f ("proc: Track /proc/$pid/attr/ opener mm_struct") Reported-and-tested-by: Leon Romanovsky Cc: Kees Cook Cc: Christian Brauner Cc: Andrea Righi Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 43c32c22254b9328d7abb1c2b0f689dc67838e60 Author: Liangyan Date: Mon Jun 7 20:57:34 2021 +0800 tracing: Correct the length check which causes memory corruption commit 3e08a9f9760f4a70d633c328a76408e62d6f80a3 upstream. We've suffered from severe kernel crashes due to memory corruption on our production environment, like, Call Trace: [1640542.554277] general protection fault: 0000 [#1] SMP PTI [1640542.554856] CPU: 17 PID: 26996 Comm: python Kdump: loaded Tainted:G [1640542.556629] RIP: 0010:kmem_cache_alloc+0x90/0x190 [1640542.559074] RSP: 0018:ffffb16faa597df8 EFLAGS: 00010286 [1640542.559587] RAX: 0000000000000000 RBX: 0000000000400200 RCX: 0000000006e931bf [1640542.560323] RDX: 0000000006e931be RSI: 0000000000400200 RDI: ffff9a45ff004300 [1640542.560996] RBP: 0000000000400200 R08: 0000000000023420 R09: 0000000000000000 [1640542.561670] R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff9a20608d [1640542.562366] R13: ffff9a45ff004300 R14: ffff9a45ff004300 R15: 696c662f65636976 [1640542.563128] FS: 00007f45d7c6f740(0000) GS:ffff9a45ff840000(0000) knlGS:0000000000000000 [1640542.563937] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [1640542.564557] CR2: 00007f45d71311a0 CR3: 000000189d63e004 CR4: 00000000003606e0 [1640542.565279] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [1640542.566069] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [1640542.566742] Call Trace: [1640542.567009] anon_vma_clone+0x5d/0x170 [1640542.567417] __split_vma+0x91/0x1a0 [1640542.567777] do_munmap+0x2c6/0x320 [1640542.568128] vm_munmap+0x54/0x70 [1640542.569990] __x64_sys_munmap+0x22/0x30 [1640542.572005] do_syscall_64+0x5b/0x1b0 [1640542.573724] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [1640542.575642] RIP: 0033:0x7f45d6e61e27 James Wang has reproduced it stably on the latest 4.19 LTS. After some debugging, we finally proved that it's due to ftrace buffer out-of-bound access using a debug tool as follows: [ 86.775200] BUG: Out-of-bounds write at addr 0xffff88aefe8b7000 [ 86.780806] no_context+0xdf/0x3c0 [ 86.784327] __do_page_fault+0x252/0x470 [ 86.788367] do_page_fault+0x32/0x140 [ 86.792145] page_fault+0x1e/0x30 [ 86.795576] strncpy_from_unsafe+0x66/0xb0 [ 86.799789] fetch_memory_string+0x25/0x40 [ 86.804002] fetch_deref_string+0x51/0x60 [ 86.808134] kprobe_trace_func+0x32d/0x3a0 [ 86.812347] kprobe_dispatcher+0x45/0x50 [ 86.816385] kprobe_ftrace_handler+0x90/0xf0 [ 86.820779] ftrace_ops_assist_func+0xa1/0x140 [ 86.825340] 0xffffffffc00750bf [ 86.828603] do_sys_open+0x5/0x1f0 [ 86.832124] do_syscall_64+0x5b/0x1b0 [ 86.835900] entry_SYSCALL_64_after_hwframe+0x44/0xa9 commit b220c049d519 ("tracing: Check length before giving out the filter buffer") adds length check to protect trace data overflow introduced in 0fc1b09ff1ff, seems that this fix can't prevent overflow entirely, the length check should also take the sizeof entry->array[0] into account, since this array[0] is filled the length of trace data and occupy addtional space and risk overflow. Link: https://lkml.kernel.org/r/20210607125734.1770447-1-liangyan.peng@linux.alibaba.com Cc: stable@vger.kernel.org Cc: Ingo Molnar Cc: Xunlei Pang Cc: Greg Kroah-Hartman Fixes: b220c049d519 ("tracing: Check length before giving out the filter buffer") Reviewed-by: Xunlei Pang Reviewed-by: yinbinbin Reviewed-by: Wetp Zhang Tested-by: James Wang Signed-off-by: Liangyan Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 5b537408f2733d510060e72596befa44c3435cb6 Author: Ming Lei Date: Wed Jun 2 21:30:29 2021 +0800 scsi: core: Only put parent device if host state differs from SHOST_CREATED commit 1e0d4e6225996f05271de1ebcb1a7c9381af0b27 upstream. get_device(shost->shost_gendev.parent) is called after host state has switched to SHOST_RUNNING. scsi_host_dev_release() shouldn't release the parent device if host state is still SHOST_CREATED. Link: https://lore.kernel.org/r/20210602133029.2864069-5-ming.lei@redhat.com Cc: Bart Van Assche Cc: John Garry Cc: Hannes Reinecke Tested-by: John Garry Reviewed-by: John Garry Signed-off-by: Ming Lei Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 0a31d1237aafc305ade0f886977450f6021b2d0c Author: Ming Lei Date: Wed Jun 2 21:30:28 2021 +0800 scsi: core: Put .shost_dev in failure path if host state changes to RUNNING commit 11714026c02d613c30a149c3f4c4a15047744529 upstream. scsi_host_dev_release() only frees dev_name when host state is SHOST_CREATED. After host state has changed to SHOST_RUNNING, scsi_host_dev_release() no longer cleans up. Fix this by doing a put_device(&shost->shost_dev) in the failure path when host state is SHOST_RUNNING. Move get_device(&shost->shost_gendev) before device_add(&shost->shost_dev) so that scsi_host_cls_release() can do a put on this reference. Link: https://lore.kernel.org/r/20210602133029.2864069-4-ming.lei@redhat.com Cc: Bart Van Assche Cc: Hannes Reinecke Reported-by: John Garry Tested-by: John Garry Reviewed-by: John Garry Reviewed-by: Hannes Reinecke Signed-off-by: Ming Lei Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 146446a43b3dbaa3a58364ef99fd606b3f324832 Author: Ming Lei Date: Wed Jun 2 21:30:27 2021 +0800 scsi: core: Fix failure handling of scsi_add_host_with_dma() commit 3719f4ff047e20062b8314c23ec3cab84d74c908 upstream. When scsi_add_host_with_dma() returns failure, the caller will call scsi_host_put(shost) to release everything allocated for this host instance. Consequently we can't also free allocated stuff in scsi_add_host_with_dma(), otherwise we will end up with a double free. Strictly speaking, host resource allocations should have been done in scsi_host_alloc(). However, the allocations may need information which is not yet provided by the driver when that function is called. So leave the allocations where they are but rely on host device's release handler to free resources. Link: https://lore.kernel.org/r/20210602133029.2864069-3-ming.lei@redhat.com Cc: Bart Van Assche Cc: John Garry Cc: Hannes Reinecke Tested-by: John Garry Reviewed-by: Bart Van Assche Reviewed-by: John Garry Reviewed-by: Hannes Reinecke Signed-off-by: Ming Lei Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 7a696ce1d5d16a33a6cd6400bbcc0339b2460e11 Author: Ming Lei Date: Wed Jun 2 21:30:26 2021 +0800 scsi: core: Fix error handling of scsi_host_alloc() commit 66a834d092930cf41d809c0e989b13cd6f9ca006 upstream. After device is initialized via device_initialize(), or its name is set via dev_set_name(), the device has to be freed via put_device(). Otherwise device name will be leaked because it is allocated dynamically in dev_set_name(). Fix the leak by replacing kfree() with put_device(). Since scsi_host_dev_release() properly handles IDA and kthread removal, remove special-casing these from the error handling as well. Link: https://lore.kernel.org/r/20210602133029.2864069-2-ming.lei@redhat.com Cc: Bart Van Assche Cc: John Garry Cc: Hannes Reinecke Tested-by: John Garry Reviewed-by: Bart Van Assche Reviewed-by: John Garry Reviewed-by: Hannes Reinecke Signed-off-by: Ming Lei Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 6e13b9bc66f0e34238aa7b9486a0575177fb7955 Author: Dai Ngo Date: Wed May 19 17:15:10 2021 -0400 NFSv4: nfs4_proc_set_acl needs to restore NFS_CAP_UIDGID_NOMAP on error. commit f8849e206ef52b584cd9227255f4724f0cc900bb upstream. Currently if __nfs4_proc_set_acl fails with NFS4ERR_BADOWNER it re-enables the idmapper by clearing NFS_CAP_UIDGID_NOMAP before retrying again. The NFS_CAP_UIDGID_NOMAP remains cleared even if the retry fails. This causes problem for subsequent setattr requests for v4 server that does not have idmapping configured. This patch modifies nfs4_proc_set_acl to detect NFS4ERR_BADOWNER and NFS4ERR_BADNAME and skips the retry, since the kernel isn't involved in encoding the ACEs, and return -EINVAL. Steps to reproduce the problem: # mount -o vers=4.1,sec=sys server:/export/test /tmp/mnt # touch /tmp/mnt/file1 # chown 99 /tmp/mnt/file1 # nfs4_setfacl -a A::unknown.user@xyz.com:wrtncy /tmp/mnt/file1 Failed setxattr operation: Invalid argument # chown 99 /tmp/mnt/file1 chown: changing ownership of ‘/tmp/mnt/file1’: Invalid argument # umount /tmp/mnt # mount -o vers=4.1,sec=sys server:/export/test /tmp/mnt # chown 99 /tmp/mnt/file1 # v2: detect NFS4ERR_BADOWNER and NFS4ERR_BADNAME and skip retry in nfs4_proc_set_acl. Signed-off-by: Dai Ngo Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit d973bd0d6e7f9b4ea976cc619e8d6e0d235b9056 Author: Trond Myklebust Date: Tue Jun 1 11:35:56 2021 -0400 NFSv4: Fix second deadlock in nfs4_evict_inode() commit c3aba897c6e67fa464ec02b1f17911577d619713 upstream. If the inode is being evicted but has to return a layout first, then that too can cause a deadlock in the corner case where the server reboots. Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit c3b6cf64dfe4ef96e7341508d50d6998da7062c7 Author: Anna Schumaker Date: Wed Jun 2 14:31:20 2021 -0400 NFS: Fix use-after-free in nfs4_init_client() commit 476bdb04c501fc64bf3b8464ffddefc8dbe01577 upstream. KASAN reports a use-after-free when attempting to mount two different exports through two different NICs that belong to the same server. Olga was able to hit this with kernels starting somewhere between 5.7 and 5.10, but I traced the patch that introduced the clear_bit() call to 4.13. So something must have changed in the refcounting of the clp pointer to make this call to nfs_put_client() the very last one. Fixes: 8dcbec6d20 ("NFSv41: Handle EXCHID4_FLAG_CONFIRMED_R during NFSv4.1 migration") Cc: stable@vger.kernel.org # 4.13+ Signed-off-by: Anna Schumaker Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 9064c9d544b906a63e359db5f908594bc07580e6 Author: Paolo Bonzini Date: Wed Jun 9 01:49:13 2021 -0400 kvm: fix previous commit for 32-bit builds commit 4422829e8053068e0225e4d0ef42dc41ea7c9ef5 upstream. array_index_nospec does not work for uint64_t on 32-bit builds. However, the size of a memory slot must be less than 20 bits wide on those system, since the memory slot must fit in the user address space. So just store it in an unsigned long. Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 351075bcfea996ce15b546c2cb80986736b917f4 Author: Leo Yan Date: Sat Jun 5 13:29:57 2021 +0800 perf session: Correct buffer copying when peeking events [ Upstream commit 197eecb6ecae0b04bd694432f640ff75597fed9c ] When peeking an event, it has a short path and a long path. The short path uses the session pointer "one_mmap_addr" to directly fetch the event; and the long path needs to read out the event header and the following event data from file and fill into the buffer pointer passed through the argument "buf". The issue is in the long path that it copies the event header and event data into the same destination address which pointer "buf", this means the event header is overwritten. We are just lucky to run into the short path in most cases, so we don't hit the issue in the long path. This patch adds the offset "hdr_sz" to the pointer "buf" when copying the event data, so that it can reserve the event header which can be used properly by its caller. Fixes: 5a52f33adf02 ("perf session: Add perf_session__peek_event()") Signed-off-by: Leo Yan Acked-by: Adrian Hunter Acked-by: Jiri Olsa Cc: Alexander Shishkin Cc: Kan Liang Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lore.kernel.org/lkml/20210605052957.1070720-1-leo.yan@linaro.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit b4651cea43afd4fa3f0091bfed5ab4b5030d0425 Author: Trond Myklebust Date: Tue Jun 1 11:10:05 2021 -0400 NFSv4: Fix deadlock between nfs4_evict_inode() and nfs4_opendata_get_inode() [ Upstream commit dfe1fe75e00e4c724ede7b9e593f6f680e446c5f ] If the inode is being evicted, but has to return a delegation first, then it can cause a deadlock in the corner case where the server reboots before the delegreturn completes, but while the call to iget5_locked() in nfs4_opendata_get_inode() is waiting for the inode free to complete. Since the open call still holds a session slot, the reboot recovery cannot proceed. In order to break the logjam, we can turn the delegation return into a privileged operation for the case where we're evicting the inode. We know that in that case, there can be no other state recovery operation that conflicts. Reported-by: zhangxiaoxu (A) Fixes: 5fcdfacc01f3 ("NFSv4: Return delegations synchronously in evict_inode") Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 279ad78a00f8b9c5ff24171a59297187a3bd44b7 Author: Dan Carpenter Date: Thu Jun 3 15:37:53 2021 +0300 NFS: Fix a potential NULL dereference in nfs_get_client() [ Upstream commit 09226e8303beeec10f2ff844d2e46d1371dc58e0 ] None of the callers are expecting NULL returns from nfs_get_client() so this code will lead to an Oops. It's better to return an error pointer. I expect that this is dead code so hopefully no one is affected. Fixes: 31434f496abb ("nfs: check hostname in nfs_get_client") Signed-off-by: Dan Carpenter Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 91f7fdc4cc10542ca1045c06aad23365f0d067e0 Author: Alaa Hleihel Date: Thu Jun 10 10:34:27 2021 +0300 IB/mlx5: Fix initializing CQ fragments buffer commit 2ba0aa2feebda680ecfc3c552e867cf4d1b05a3a upstream. The function init_cq_frag_buf() can be called to initialize the current CQ fragments buffer cq->buf, or the temporary cq->resize_buf that is filled during CQ resize operation. However, the offending commit started to use function get_cqe() for getting the CQEs, the issue with this change is that get_cqe() always returns CQEs from cq->buf, which leads us to initialize the wrong buffer, and in case of enlarging the CQ we try to access elements beyond the size of the current cq->buf and eventually hit a kernel panic. [exception RIP: init_cq_frag_buf+103] [ffff9f799ddcbcd8] mlx5_ib_resize_cq at ffffffffc0835d60 [mlx5_ib] [ffff9f799ddcbdb0] ib_resize_cq at ffffffffc05270df [ib_core] [ffff9f799ddcbdc0] llt_rdma_setup_qp at ffffffffc0a6a712 [llt] [ffff9f799ddcbe10] llt_rdma_cc_event_action at ffffffffc0a6b411 [llt] [ffff9f799ddcbe98] llt_rdma_client_conn_thread at ffffffffc0a6bb75 [llt] [ffff9f799ddcbec8] kthread at ffffffffa66c5da1 [ffff9f799ddcbf50] ret_from_fork_nospec_begin at ffffffffa6d95ddd Fix it by getting the needed CQE by calling mlx5_frag_buf_get_wqe() that takes the correct source buffer as a parameter. Fixes: 388ca8be0037 ("IB/mlx5: Implement fragmented completion queue (CQ)") Link: https://lore.kernel.org/r/90a0e8c924093cfa50a482880ad7e7edb73dc19a.1623309971.git.leonro@nvidia.com Signed-off-by: Alaa Hleihel Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit d046f724bbd725a24007b7e52b2d675249870888 Author: Sean Christopherson Date: Mon Jun 7 10:57:48 2021 -0700 KVM: x86: Ensure liveliness of nested VM-Enter fail tracepoint message commit f31500b0d437a2464ca5972d8f5439e156b74960 upstream. Use the __string() machinery provided by the tracing subystem to make a copy of the string literals consumed by the "nested VM-Enter failed" tracepoint. A complete copy is necessary to ensure that the tracepoint can't outlive the data/memory it consumes and deference stale memory. Because the tracepoint itself is defined by kvm, if kvm-intel and/or kvm-amd are built as modules, the memory holding the string literals defined by the vendor modules will be freed when the module is unloaded, whereas the tracepoint and its data in the ring buffer will live until kvm is unloaded (or "indefinitely" if kvm is built-in). This bug has existed since the tracepoint was added, but was recently exposed by a new check in tracing to detect exactly this type of bug. fmt: '%s%s ' current_buffer: ' vmx_dirty_log_t-140127 [003] .... kvm_nested_vmenter_failed: ' WARNING: CPU: 3 PID: 140134 at kernel/trace/trace.c:3759 trace_check_vprintf+0x3be/0x3e0 CPU: 3 PID: 140134 Comm: less Not tainted 5.13.0-rc1-ce2e73ce600a-req #184 Hardware name: ASUS Q87M-E/Q87M-E, BIOS 1102 03/03/2014 RIP: 0010:trace_check_vprintf+0x3be/0x3e0 Code: <0f> 0b 44 8b 4c 24 1c e9 a9 fe ff ff c6 44 02 ff 00 49 8b 97 b0 20 RSP: 0018:ffffa895cc37bcb0 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffa895cc37bd08 RCX: 0000000000000027 RDX: 0000000000000027 RSI: 00000000ffffdfff RDI: ffff9766cfad74f8 RBP: ffffffffc0a041d4 R08: ffff9766cfad74f0 R09: ffffa895cc37bad8 R10: 0000000000000001 R11: 0000000000000001 R12: ffffffffc0a041d4 R13: ffffffffc0f4dba8 R14: 0000000000000000 R15: ffff976409f2c000 FS: 00007f92fa200740(0000) GS:ffff9766cfac0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000559bd11b0000 CR3: 000000019fbaa002 CR4: 00000000001726e0 Call Trace: trace_event_printf+0x5e/0x80 trace_raw_output_kvm_nested_vmenter_failed+0x3a/0x60 [kvm] print_trace_line+0x1dd/0x4e0 s_show+0x45/0x150 seq_read_iter+0x2d5/0x4c0 seq_read+0x106/0x150 vfs_read+0x98/0x180 ksys_read+0x5f/0xe0 do_syscall_64+0x40/0xb0 entry_SYSCALL_64_after_hwframe+0x44/0xae Cc: Steven Rostedt Fixes: 380e0055bc7e ("KVM: nVMX: trace nested VM-Enter failures detected by H/W") Signed-off-by: Sean Christopherson Reviewed-by: Steven Rostedt (VMware) Message-Id: <20210607175748.674002-1-seanjc@google.com> Signed-off-by: Greg Kroah-Hartman commit 4921feb0e5be99873e1b4246672563aacd34e8cf Author: CodyYao-oc Date: Mon Jun 7 10:53:35 2021 +0800 x86/nmi_watchdog: Fix old-style NMI watchdog regression on old Intel CPUs commit a8383dfb2138742a1bb77b481ada047aededa2ba upstream. The following commit: 3a4ac121c2ca ("x86/perf: Add hardware performance events support for Zhaoxin CPU.") Got the old-style NMI watchdog logic wrong and broke it for basically every Intel CPU where it was active. Which is only truly old CPUs, so few people noticed. On CPUs with perf events support we turn off the old-style NMI watchdog, so it was pretty pointless to add the logic for X86_VENDOR_ZHAOXIN to begin with ... :-/ Anyway, the fix is to restore the old logic and add a 'break'. [ mingo: Wrote a new changelog. ] Fixes: 3a4ac121c2ca ("x86/perf: Add hardware performance events support for Zhaoxin CPU.") Signed-off-by: CodyYao-oc Signed-off-by: Ingo Molnar Signed-off-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/r/20210607025335.9643-1-CodyYao-oc@zhaoxin.com Signed-off-by: Greg Kroah-Hartman commit 190a7f908993cc7f5e8bbe67aa88eeb0bdbbbaa5 Author: Dietmar Eggemann Date: Wed Jun 2 16:58:08 2021 +0200 sched/fair: Fix util_est UTIL_AVG_UNCHANGED handling commit 68d7a190682aa4eb02db477328088ebad15acc83 upstream. The util_est internal UTIL_AVG_UNCHANGED flag which is used to prevent unnecessary util_est updates uses the LSB of util_est.enqueued. It is exposed via _task_util_est() (and task_util_est()). Commit 92a801e5d5b7 ("sched/fair: Mask UTIL_AVG_UNCHANGED usages") mentions that the LSB is lost for util_est resolution but find_energy_efficient_cpu() checks if task_util_est() returns 0 to return prev_cpu early. _task_util_est() returns the max value of util_est.ewma and util_est.enqueued or'ed w/ UTIL_AVG_UNCHANGED. So task_util_est() returning the max of task_util() and _task_util_est() will never return 0 under the default SCHED_FEAT(UTIL_EST, true). To fix this use the MSB of util_est.enqueued instead and keep the flag util_est internal, i.e. don't export it via _task_util_est(). The maximal possible util_avg value for a task is 1024 so the MSB of 'unsigned int util_est.enqueued' isn't used to store a util value. As a caveat the code behind the util_est_se trace point has to filter UTIL_AVG_UNCHANGED to see the real util_est.enqueued value which should be easy to do. This also fixes an issue report by Xuewen Yan that util_est_update() only used UTIL_AVG_UNCHANGED for the subtrahend of the equation: last_enqueued_diff = ue.enqueued - (task_util() | UTIL_AVG_UNCHANGED) Fixes: b89997aa88f0b sched/pelt: Fix task util_est update filtering Signed-off-by: Dietmar Eggemann Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Xuewen Yan Reviewed-by: Vincent Donnefort Reviewed-by: Vincent Guittot Link: https://lore.kernel.org/r/20210602145808.1562603-1-dietmar.eggemann@arm.com Signed-off-by: Greg Kroah-Hartman commit 32e22db8b25ea165bd9e446c7f92b089c8568eaf Author: Vincent Guittot Date: Thu May 27 14:29:16 2021 +0200 sched/fair: Make sure to update tg contrib for blocked load commit 02da26ad5ed6ea8680e5d01f20661439611ed776 upstream. During the update of fair blocked load (__update_blocked_fair()), we update the contribution of the cfs in tg->load_avg if cfs_rq's pelt has decayed. Nevertheless, the pelt values of a cfs_rq could have been recently updated while propagating the change of a child. In this case, cfs_rq's pelt will not decayed because it has already been updated and we don't update tg->load_avg. __update_blocked_fair ... for_each_leaf_cfs_rq_safe: child cfs_rq update cfs_rq_load_avg() for child cfs_rq ... update_load_avg(cfs_rq_of(se), se, 0) ... update cfs_rq_load_avg() for parent cfs_rq -propagation of child's load makes parent cfs_rq->load_sum becoming null -UPDATE_TG is not set so it doesn't update parent cfs_rq->tg_load_avg_contrib .. for_each_leaf_cfs_rq_safe: parent cfs_rq update cfs_rq_load_avg() for parent cfs_rq - nothing to do because parent cfs_rq has already been updated recently so cfs_rq->tg_load_avg_contrib is not updated ... parent cfs_rq is decayed list_del_leaf_cfs_rq parent cfs_rq - but it still contibutes to tg->load_avg we must set UPDATE_TG flags when propagting pending load to the parent Fixes: 039ae8bcf7a5 ("sched/fair: Fix O(nr_cgroups) in the load balancing path") Reported-by: Odin Ugedal Signed-off-by: Vincent Guittot Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Odin Ugedal Link: https://lkml.kernel.org/r/20210527122916.27683-3-vincent.guittot@linaro.org Signed-off-by: Greg Kroah-Hartman commit 4c37b062edae8ad3e1f279ecc084f254bc8161ae Author: Vincent Guittot Date: Thu May 27 14:29:15 2021 +0200 sched/fair: Keep load_avg and load_sum synced commit 7c7ad626d9a0ff0a36c1e2a3cfbbc6a13828d5eb upstream. when removing a cfs_rq from the list we only check _sum value so we must ensure that _avg and _sum stay synced so load_sum can't be null whereas load_avg is not after propagating load in the cgroup hierarchy. Use load_avg to compute load_sum similarly to what is done for util_sum and runnable_sum. Fixes: 0e2d2aaaae52 ("sched/fair: Rewrite PELT migration propagation") Reported-by: Odin Ugedal Signed-off-by: Vincent Guittot Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Odin Ugedal Link: https://lkml.kernel.org/r/20210527122916.27683-2-vincent.guittot@linaro.org Signed-off-by: Greg Kroah-Hartman commit c64a3be39fa9fe473dd85cf1e6a4a7b27c0d935f Author: Marco Elver Date: Thu May 27 12:47:11 2021 +0200 perf: Fix data race between pin_count increment/decrement commit 6c605f8371159432ec61cbb1488dcf7ad24ad19a upstream. KCSAN reports a data race between increment and decrement of pin_count: write to 0xffff888237c2d4e0 of 4 bytes by task 15740 on cpu 1: find_get_context kernel/events/core.c:4617 __do_sys_perf_event_open kernel/events/core.c:12097 [inline] __se_sys_perf_event_open kernel/events/core.c:11933 ... read to 0xffff888237c2d4e0 of 4 bytes by task 15743 on cpu 0: perf_unpin_context kernel/events/core.c:1525 [inline] __do_sys_perf_event_open kernel/events/core.c:12328 [inline] __se_sys_perf_event_open kernel/events/core.c:11933 ... Because neither read-modify-write here is atomic, this can lead to one of the operations being lost, resulting in an inconsistent pin_count. Fix it by adding the missing locking in the CPU-event case. Fixes: fe4b04fa31a6 ("perf: Cure task_oncpu_function_call() races") Reported-by: syzbot+142c9018f5962db69c7e@syzkaller.appspotmail.com Signed-off-by: Marco Elver Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20210527104711.2671610-1-elver@google.com Signed-off-by: Greg Kroah-Hartman commit e0b518a2eb44d8a74c19e50f79a8ed393e96d634 Author: Srinivas Kandagatla Date: Tue May 25 17:55:39 2021 +0100 gpio: wcd934x: Fix shift-out-of-bounds error commit dbec64b11c65d74f31427e2b9d5746fbf17bf840 upstream. bit-mask for pins 0 to 4 is BIT(0) to BIT(4) however we ended up with BIT(n - 1) which is not right, and this was caught by below usban check UBSAN: shift-out-of-bounds in drivers/gpio/gpio-wcd934x.c:34:14 Fixes: 59c324683400 ("gpio: wcd934x: Add support to wcd934x gpio controller") Signed-off-by: Srinivas Kandagatla Reviewed-by: Andy Shevchenko Reviewed-by: Bjorn Andersson Signed-off-by: Bartosz Golaszewski Signed-off-by: Greg Kroah-Hartman commit 56a388a9cc1e246a4447a575a8ba29984758bb50 Author: Yang Li Date: Tue May 25 18:50:32 2021 +0800 phy: ti: Fix an error code in wiz_probe() commit b8203ec7f58ae925e10fadd3d136073ae7503a6e upstream. When the code execute this if statement, the value of ret is 0. However, we can see from the dev_err() log that the value of ret should be -EINVAL. Clean up smatch warning: drivers/phy/ti/phy-j721e-wiz.c:1216 wiz_probe() warn: missing error code 'ret' Reported-by: Abaci Robot Fixes: c9f9eba06629 ("phy: ti: j721e-wiz: Manage typec-gpio-dir") Signed-off-by: Yang Li Link: https://lore.kernel.org/r/1621939832-65535-1-git-send-email-yang.lee@linux.alibaba.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 62d891861f83ac12e1b00b304211faf3d1e24857 Author: Jerome Brunet Date: Mon May 24 11:34:48 2021 +0200 ASoC: meson: gx-card: fix sound-dai dt schema commit d031d99b02eaf7363c33f5b27b38086cc8104082 upstream. There is a fair amount of warnings when running 'make dtbs_check' with amlogic,gx-sound-card.yaml. Ex: arch/arm64/boot/dts/amlogic/meson-gxm-q200.dt.yaml: sound: dai-link-0:sound-dai:0:1: missing phandle tag in 0 arch/arm64/boot/dts/amlogic/meson-gxm-q200.dt.yaml: sound: dai-link-0:sound-dai:0:2: missing phandle tag in 0 arch/arm64/boot/dts/amlogic/meson-gxm-q200.dt.yaml: sound: dai-link-0:sound-dai:0: [66, 0, 0] is too long The reason is that the sound-dai phandle provided has cells, and in such case the schema should use 'phandle-array' instead of 'phandle'. Fixes: fd00366b8e41 ("ASoC: meson: gx: add sound card dt-binding documentation") Signed-off-by: Jerome Brunet Link: https://lore.kernel.org/r/20210524093448.357140-1-jbrunet@baylibre.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 0e2c9aeb00289f279b8181fbd4c20765127d8943 Author: Kefeng Wang Date: Mon May 24 10:49:41 2021 +0800 ASoC: core: Fix Null-point-dereference in fmt_single_name() commit 41daf6ba594d55f201c50280ebcd430590441da1 upstream. Check the return value of devm_kstrdup() in case of Null-point-dereference. Fixes: 45dd9943fce0 ("ASoC: core: remove artificial component and DAI name constraint") Cc: Dmitry Baryshkov Reported-by: Hulk Robot Signed-off-by: Kefeng Wang Link: https://lore.kernel.org/r/20210524024941.159952-1-wangkefeng.wang@huawei.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit d83075c25a28e6e8f02e531c8dd4b4e0b58c3ef5 Author: Wang Wensheng Date: Mon May 17 01:57:49 2021 +0000 phy: cadence: Sierra: Fix error return code in cdns_sierra_phy_probe() commit 6411e386db0a477217607015e7d2910d02f75426 upstream. Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Fixes: a43f72ae136a ("phy: cadence: Sierra: Change MAX_LANES of Sierra to 16") Reported-by: Hulk Robot Signed-off-by: Wang Wensheng Link: https://lore.kernel.org/r/20210517015749.127799-1-wangwensheng4@huawei.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit c9cb5837e92ee3052e0e46e3cd1eb1f7a903411d Author: Zhen Lei Date: Sat May 8 11:42:16 2021 +0800 tools/bootconfig: Fix error return code in apply_xbc() commit e8ba0b2b64126381643bb50df3556b139a60545a upstream. Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Link: https://lkml.kernel.org/r/20210508034216.2277-1-thunder.leizhen@huawei.com Fixes: a995e6bc0524 ("tools/bootconfig: Fix to check the write failure correctly") Reported-by: Hulk Robot Acked-by: Masami Hiramatsu Signed-off-by: Zhen Lei Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 16ccdcdfe668896587b3d4cb2fd6dd512b308dea Author: Nathan Chancellor Date: Wed May 5 17:14:11 2021 -0700 vmlinux.lds.h: Avoid orphan section with !SMP commit d4c6399900364facd84c9e35ce1540b6046c345f upstream. With x86_64_defconfig and the following configs, there is an orphan section warning: CONFIG_SMP=n CONFIG_AMD_MEM_ENCRYPT=y CONFIG_HYPERVISOR_GUEST=y CONFIG_KVM=y CONFIG_PARAVIRT=y ld: warning: orphan section `.data..decrypted' from `arch/x86/kernel/cpu/vmware.o' being placed in section `.data..decrypted' ld: warning: orphan section `.data..decrypted' from `arch/x86/kernel/kvm.o' being placed in section `.data..decrypted' These sections are created with DEFINE_PER_CPU_DECRYPTED, which ultimately turns into __PCPU_ATTRS, which in turn has a section attribute with a value of PER_CPU_BASE_SECTION + the section name. When CONFIG_SMP is not set, the base section is .data and that is not currently handled in any linker script. Add .data..decrypted to PERCPU_DECRYPTED_SECTION, which is included in PERCPU_INPUT -> PERCPU_SECTION, which is include in the x86 linker script when either CONFIG_X86_64 or CONFIG_SMP is unset, taking care of the warning. Fixes: ac26963a1175 ("percpu: Introduce DEFINE_PER_CPU_DECRYPTED") Link: https://github.com/ClangBuiltLinux/linux/issues/1360 Reported-by: kernel test robot Signed-off-by: Nathan Chancellor Tested-by: Nick Desaulniers # build Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20210506001410.1026691-1-nathan@kernel.org Signed-off-by: Greg Kroah-Hartman commit c25ec6386a81d6d6bebd1dae320f6f7bee0167e6 Author: Arnd Bergmann Date: Wed Dec 30 16:54:56 2020 +0100 ARM: cpuidle: Avoid orphan section warning commit d94b93a9101573eb75b819dee94b1417acff631b upstream. Since commit 83109d5d5fba ("x86/build: Warn on orphan section placement"), we get a warning for objects in orphan sections. The cpuidle implementation for OMAP causes this when CONFIG_CPU_IDLE is disabled: arm-linux-gnueabi-ld: warning: orphan section `__cpuidle_method_of_table' from `arch/arm/mach-omap2/pm33xx-core.o' being placed in section `__cpuidle_method_of_table' arm-linux-gnueabi-ld: warning: orphan section `__cpuidle_method_of_table' from `arch/arm/mach-omap2/pm33xx-core.o' being placed in section `__cpuidle_method_of_table' arm-linux-gnueabi-ld: warning: orphan section `__cpuidle_method_of_table' from `arch/arm/mach-omap2/pm33xx-core.o' being placed in section `__cpuidle_method_of_table' Change the definition of CPUIDLE_METHOD_OF_DECLARE() to silently drop the table and all code referenced from it when CONFIG_CPU_IDLE is disabled. Fixes: 06ee7a950b6a ("ARM: OMAP2+: pm33xx-core: Add cpuidle_ops for am335x/am437x") Signed-off-by: Arnd Bergmann Reviewed-by: Miguel Ojeda Reviewed-by: Nick Desaulniers Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20201230155506.1085689-1-arnd@kernel.org Signed-off-by: Greg Kroah-Hartman commit cb1aa1da04882d1860f733e24aeebdbbc85724d7 Author: Shay Drory Date: Thu Jun 3 16:19:39 2021 +0300 RDMA/mlx4: Do not map the core_clock page to user space unless enabled commit 404e5a12691fe797486475fe28cc0b80cb8bef2c upstream. Currently when mlx4 maps the hca_core_clock page to the user space there are read-modifiable registers, one of which is semaphore, on this page as well as the clock counter. If user reads the wrong offset, it can modify the semaphore and hang the device. Do not map the hca_core_clock page to the user space unless the device has been put in a backwards compatibility mode to support this feature. After this patch, mlx4 core_clock won't be mapped to user space on the majority of existing devices and the uverbs device time feature in ibv_query_rt_values_ex() will be disabled. Fixes: 52033cfb5aab ("IB/mlx4: Add mmap call to map the hardware clock") Link: https://lore.kernel.org/r/9632304e0d6790af84b3b706d8c18732bc0d5e27.1622726305.git.leonro@nvidia.com Signed-off-by: Shay Drory Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 67cf4e447b5e5e9e94996cb6812ae2828e0e0e27 Author: Kamal Heib Date: Tue May 25 18:01:34 2021 +0300 RDMA/ipoib: Fix warning caused by destroying non-initial netns commit a3e74fb9247cd530dca246699d5eb5a691884d32 upstream. After the commit 5ce2dced8e95 ("RDMA/ipoib: Set rtnl_link_ops for ipoib interfaces"), if the IPoIB device is moved to non-initial netns, destroying that netns lets the device vanish instead of moving it back to the initial netns, This is happening because default_device_exit() skips the interfaces due to having rtnl_link_ops set. Steps to reporoduce: ip netns add foo ip link set mlx5_ib0 netns foo ip netns delete foo WARNING: CPU: 1 PID: 704 at net/core/dev.c:11435 netdev_exit+0x3f/0x50 Modules linked in: xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 nft_compat nft_counter nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfnetlink tun d fuse CPU: 1 PID: 704 Comm: kworker/u64:3 Tainted: G S W 5.13.0-rc1+ #1 Hardware name: Dell Inc. PowerEdge R630/02C2CP, BIOS 2.1.5 04/11/2016 Workqueue: netns cleanup_net RIP: 0010:netdev_exit+0x3f/0x50 Code: 48 8b bb 30 01 00 00 e8 ef 81 b1 ff 48 81 fb c0 3a 54 a1 74 13 48 8b 83 90 00 00 00 48 81 c3 90 00 00 00 48 39 d8 75 02 5b c3 <0f> 0b 5b c3 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 0f 1f 44 00 RSP: 0018:ffffb297079d7e08 EFLAGS: 00010206 RAX: ffff8eb542c00040 RBX: ffff8eb541333150 RCX: 000000008010000d RDX: 000000008010000e RSI: 000000008010000d RDI: ffff8eb440042c00 RBP: ffffb297079d7e48 R08: 0000000000000001 R09: ffffffff9fdeac00 R10: ffff8eb5003be000 R11: 0000000000000001 R12: ffffffffa1545620 R13: ffffffffa1545628 R14: 0000000000000000 R15: ffffffffa1543b20 FS: 0000000000000000(0000) GS:ffff8ed37fa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005601b5f4c2e8 CR3: 0000001fc8c10002 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ops_exit_list.isra.9+0x36/0x70 cleanup_net+0x234/0x390 process_one_work+0x1cb/0x360 ? process_one_work+0x360/0x360 worker_thread+0x30/0x370 ? process_one_work+0x360/0x360 kthread+0x116/0x130 ? kthread_park+0x80/0x80 ret_from_fork+0x22/0x30 To avoid the above warning and later on the kernel panic that could happen on shutdown due to a NULL pointer dereference, make sure to set the netns_refund flag that was introduced by commit 3a5ca857079e ("can: dev: Move device back to init netns on owning netns delete") to properly restore the IPoIB interfaces to the initial netns. Fixes: 5ce2dced8e95 ("RDMA/ipoib: Set rtnl_link_ops for ipoib interfaces") Link: https://lore.kernel.org/r/20210525150134.139342-1-kamalheib1@gmail.com Signed-off-by: Kamal Heib Reviewed-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit fd681a8c7ac8f649a0718f6cbf2fe75d0587c9a2 Author: Jonathan Marek Date: Thu May 13 13:14:00 2021 -0400 drm/msm/a6xx: avoid shadow NULL reference in failure path commit ce86c239e4d218ae6040bec18e6d19a58edb8b7c upstream. If a6xx_hw_init() fails before creating the shadow_bo, the a6xx_pm_suspend code referencing it will crash. Change the condition to one that avoids this problem (note: creation of shadow_bo is behind this same condition) Fixes: e8b0b994c3a5 ("drm/msm/a6xx: Clear shadow on suspend") Signed-off-by: Jonathan Marek Reviewed-by: Akhil P Oommen Link: https://lore.kernel.org/r/20210513171431.18632-6-jonathan@marek.ca Signed-off-by: Rob Clark Signed-off-by: Greg Kroah-Hartman commit 0bc79f4b7ac60f9fd4dfd1c65ad17e5a2369e2ca Author: Jonathan Marek Date: Thu May 13 13:13:59 2021 -0400 drm/msm/a6xx: update/fix CP_PROTECT initialization commit 408434036958699a7f50ddec984f7ba33e11a8f5 upstream. Update CP_PROTECT register programming based on downstream. A6XX_PROTECT_RW is renamed to A6XX_PROTECT_NORDWR to make things aligned and also be more clear about what it does. Note that this required switching to use the CP_ALWAYS_ON_COUNTER as the GMU counter is not accessible from the cmdstream. Which also means using the CPU counter for the msm_gpu_submit_flush() tracepoint (as catapult depends on being able to compare this to the start/end values captured in cmdstream). This may need to be revisited when IFPC is enabled. Also, compared to downstream, this opens up CP_PERFCTR_CP_SEL as the userspace performance tooling (fdperf and pps-producer) expect to be able to configure the CP counters. Fixes: 4b565ca5a2cb ("drm/msm: Add A6XX device support") Signed-off-by: Jonathan Marek Reviewed-by: Akhil P Oommen Link: https://lore.kernel.org/r/20210513171431.18632-5-jonathan@marek.ca [switch to CP_ALWAYS_ON_COUNTER, open up CP_PERFCNTR_CP_SEL, and spiff up commit msg] Signed-off-by: Rob Clark Signed-off-by: Greg Kroah-Hartman commit 5b7dc8329d7a51bab34452d132230fd76330a22b Author: Jonathan Marek Date: Thu May 13 13:13:58 2021 -0400 drm/msm/a6xx: fix incorrectly set uavflagprd_inv field for A650 commit b4387eaf3821a4c4241ac3a556e13244eb1fdaa5 upstream. Value was shifted in the wrong direction, resulting in the field always being zero, which is incorrect for A650. Fixes: d0bac4e9cd66 ("drm/msm/a6xx: set ubwc config for A640 and A650") Signed-off-by: Jonathan Marek Reviewed-by: Akhil P Oommen Link: https://lore.kernel.org/r/20210513171431.18632-4-jonathan@marek.ca Signed-off-by: Rob Clark Signed-off-by: Greg Kroah-Hartman commit 5a61f69da3b8d735b01dddee72fee4671510d907 Author: Linus Walleij Date: Tue Jun 8 23:33:18 2021 +0200 drm/mcde: Fix off by 10^3 in calculation commit c8a570443943304cac2e4186dbce6989b6c2b8b5 upstream. The calclulation of how many bytes we stuff into the DSI pipeline for video mode panels is off by three orders of magnitude because we did not account for the fact that the DRM mode clock is in kilohertz rather than hertz. This used to be: drm_mode_vrefresh(mode) * mode->htotal * mode->vtotal which would become for example for s6e63m0: 60 x 514 x 831 = 25628040 Hz, but mode->clock is 25628 as it is in kHz. This affects only the Samsung GT-I8190 "Golden" phone right now since it is the only MCDE device with a video mode display. Curiously some specimen work with this code and wild settings in the EOL and empty packets at the end of the display, but I have noticed an eeire flicker until now. Others were not so lucky and got black screens. Cc: Ville Syrjälä Reported-by: Stephan Gerhold Fixes: 920dd1b1425b ("drm/mcde: Use mode->clock instead of reverse calculating it from the vrefresh") Signed-off-by: Linus Walleij Tested-by: Stephan Gerhold Reviewed-by: Stephan Gerhold Link: https://patchwork.freedesktop.org/patch/msgid/20210608213318.3897858-1-linus.walleij@linaro.org Signed-off-by: Greg Kroah-Hartman commit d6888929802921a3e9b38164b3ee7a464e16f820 Author: Bjorn Andersson Date: Wed Jun 9 17:21:32 2021 -0700 usb: typec: mux: Fix copy-paste mistake in typec_mux_match commit 142d0b24c1b17139f1aaaacae7542a38aa85640f upstream. Fix the copy-paste mistake in the return path of typec_mux_match(), where dev is considered a member of struct typec_switch rather than struct typec_mux. The two structs are identical in regards to having the struct device as the first entry, so this provides no functional change. Fixes: 3370db35193b ("usb: typec: Registering real device entries for the muxes") Reviewed-by: Heikki Krogerus Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20210610002132.3088083-1-bjorn.andersson@linaro.org Signed-off-by: Greg Kroah-Hartman commit 9e0677c2e39052ac20efae4474bb20614d9a88c9 Author: Wesley Cheng Date: Thu May 20 21:23:57 2021 -0700 usb: dwc3: gadget: Disable gadget IRQ during pullup disable commit 8212937305f84ef73ea81036dafb80c557583d4b upstream. Current sequence utilizes dwc3_gadget_disable_irq() alongside synchronize_irq() to ensure that no further DWC3 events are generated. However, the dwc3_gadget_disable_irq() API only disables device specific events. Endpoint events can still be generated. Briefly disable the interrupt line, so that the cleanup code can run to prevent device and endpoint events. (i.e. __dwc3_gadget_stop() and dwc3_stop_active_transfers() respectively) Without doing so, it can lead to both the interrupt handler and the pullup disable routine both writing to the GEVNTCOUNT register, which will cause an incorrect count being read from future interrupts. Fixes: ae7e86108b12 ("usb: dwc3: Stop active transfers before halting the controller") Signed-off-by: Wesley Cheng Link: https://lore.kernel.org/r/1621571037-1424-1-git-send-email-wcheng@codeaurora.org Signed-off-by: Greg Kroah-Hartman commit cc440da4aad9dc9f2a9a9ebd9ddf3c23f36ff2fc Author: Chen Li Date: Tue Apr 27 15:17:45 2021 +0800 phy: usb: Fix misuse of IS_ENABLED commit 7c2fc79250cafa1a29befeb60163028ec4720814 upstream. While IS_ENABLED() is perfectly fine for CONFIG_* symbols, it is not for other symbols such as __BIG_ENDIAN that is provided directly by the compiler. Switch to use CONFIG_CPU_BIG_ENDIAN instead of __BIG_ENDIAN. Signed-off-by: Chen Li Reviewed-by: Al Cooper Acked-by: Florian Fainelli Fixes: 94583a41047e ("phy: usb: Restructure in preparation for adding 7216 USB support") Link: https://lore.kernel.org/r/87czuggpra.wl-chenli@uniontech.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit aafc51fddfa87178eb599e68526620ac0c02dc5a Author: Axel Lin Date: Sun May 30 20:41:00 2021 +0800 regulator: rtmv20: Fix .set_current_limit/.get_current_limit callbacks commit 86ab21cc39e6b99b7065ab9008c90bec5dec535a upstream. Current code does not set .curr_table and .n_linear_ranges settings, so it cannot use the regulator_get/set_current_limit_regmap helpers. If we setup the curr_table, it will has 200 entries. Implement customized .set_current_limit/.get_current_limit callbacks instead. Fixes: b8c054a5eaf0 ("regulator: rtmv20: Adds support for Richtek RTMV20 load switch regulator") Signed-off-by: Axel Lin Reviewed-by: ChiYuan Huang Link: https://lore.kernel.org/r/20210530124101.477727-1-axel.lin@ingics.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 4579f65176792a54e842d28605330ef0f4916df2 Author: Axel Lin Date: Sun May 23 15:10:45 2021 +0800 regulator: bd71828: Fix .n_voltages settings commit 4c668630bf8ea90a041fc69c9984486e0f56682d upstream. Current .n_voltages settings do not cover the latest 2 valid selectors, so it fails to set voltage for the hightest voltage support. The latest linear range has step_uV = 0, so it does not matter if we count the .n_voltages to maximum selector + 1 or the first selector of latest linear range + 1. To simplify calculating the n_voltages, let's just set the .n_voltages to maximum selector + 1. Fixes: 522498f8cb8c ("regulator: bd71828: Basic support for ROHM bd71828 PMIC regulators") Signed-off-by: Axel Lin Reviewed-by: Matti Vaittinen Link: https://lore.kernel.org/r/20210523071045.2168904-2-axel.lin@ingics.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 5a5f5cfb5f0996d65eae3cc034513d90f4be6783 Author: Axel Lin Date: Mon May 17 18:53:24 2021 +0800 regulator: fan53880: Fix missing n_voltages setting commit 34991ee96fd8477479dd15adadceb6b28b30d9b0 upstream. Fixes: e6dea51e2d41 ("regulator: fan53880: Add initial support") Signed-off-by: Axel Lin Acked-by: Christoph Fritz Link: https://lore.kernel.org/r/20210517105325.1227393-1-axel.lin@ingics.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit c365ff97617cbea8b31aa340507c7dc4395da89a Author: Matti Vaittinen Date: Wed Jun 2 08:45:58 2021 +0300 regulator: bd718x7: Fix the BUCK7 voltage setting on BD71837 commit bc537e65b09a05923f98a31920d1ab170e648dba upstream. Changing the BD71837 voltages for other regulators except the first 4 BUCKs should be forbidden when the regulator is enabled. There may be out-of-spec voltage spikes if the voltage of these "non DVS" bucks is changed when enabled. This restriction was accidentally removed when the LDO voltage change was allowed for BD71847. (It was not noticed that the BD71837 BUCK7 used same voltage setting function as LDOs). Additionally this bug causes incorrect voltage monitoring register access. The voltage change function accidentally used for bd71837 BUCK7 is intended to only handle LDO voltage changes. A BD71847 LDO specific voltage monitoring disabling code gets executed on BD71837 and register offsets are wrongly calculated as regulator is assumed to be an LDO. Prevent the BD71837 BUCK7 voltage change when BUCK7 is enabled by using the correct voltage setting operation. Fixes: 9bcbabafa19b ("regulator: bd718x7: remove voltage change restriction from BD71847 LDOs") Signed-off-by: Matti Vaittinen Link: https://lore.kernel.org/r/bd8c00931421fafa57e3fdf46557a83075b7cc17.1622610103.git.matti.vaittinen@fi.rohmeurope.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit e3a502abf506e5c054b61a7c524caaa48e8e8537 Author: Dmitry Osipenko Date: Mon May 24 01:42:42 2021 +0300 regulator: max77620: Use device_set_of_node_from_dev() commit 6f55c5dd1118b3076d11d9cb17f5c5f4bc3a1162 upstream. The MAX77620 driver fails to re-probe on deferred probe because driver core tries to claim resources that are already claimed by the PINCTRL device. Use device_set_of_node_from_dev() helper which marks OF node as reused, skipping erroneous execution of pinctrl_bind_pins() for the PMIC device on the re-probe. Fixes: aea6cb99703e ("regulator: resolve supply after creating regulator") Signed-off-by: Dmitry Osipenko Link: https://lore.kernel.org/r/20210523224243.13219-2-digetx@gmail.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 06653ebc0ad2e0b7d799cd71a5c2933ed2fb7a66 Author: Dmitry Baryshkov Date: Thu May 20 01:12:23 2021 +0300 regulator: core: resolve supply for boot-on/always-on regulators commit 98e48cd9283dbac0e1445ee780889f10b3d1db6a upstream. For the boot-on/always-on regulators the set_machine_constrainst() is called before resolving rdev->supply. Thus the code would try to enable rdev before enabling supplying regulator. Enforce resolving supply regulator before enabling rdev. Fixes: aea6cb99703e ("regulator: resolve supply after creating regulator") Signed-off-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20210519221224.2868496-1-dmitry.baryshkov@linaro.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 7dcdfa28e1fef6641fb3edfb4581580179a9f7ed Author: Li Jun Date: Wed Jun 2 17:57:08 2021 +0800 usb: typec: tcpm: cancel frs hrtimer when unregister tcpm port commit 7ade4805e296c8d1e40c842395bbe478c7210555 upstream. Like the state_machine_timer, we should also cancel possible pending frs hrtimer when unregister tcpm port. Fixes: 8dc4bd073663 ("usb: typec: tcpm: Add support for Sink Fast Role SWAP(FRS)") Cc: stable Reviewed-by: Guenter Roeck Signed-off-by: Li Jun Link: https://lore.kernel.org/r/1622627829-11070-2-git-send-email-jun.li@nxp.com Signed-off-by: Greg Kroah-Hartman commit 18eaf0de50eadeeb395b83310b259b21ad8ed0a6 Author: Li Jun Date: Wed Jun 2 17:57:07 2021 +0800 usb: typec: tcpm: cancel vdm and state machine hrtimer when unregister tcpm port commit 3a13ff7ef4349d70d1d18378d661117dd5af8efe upstream. A pending hrtimer may expire after the kthread_worker of tcpm port is destroyed, see below kernel dump when do module unload, fix it by cancel the 2 hrtimers. [ 111.517018] Unable to handle kernel paging request at virtual address ffff8000118cb880 [ 111.518786] blk_update_request: I/O error, dev sda, sector 60061185 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0 [ 111.526594] Mem abort info: [ 111.526597] ESR = 0x96000047 [ 111.526600] EC = 0x25: DABT (current EL), IL = 32 bits [ 111.526604] SET = 0, FnV = 0 [ 111.526607] EA = 0, S1PTW = 0 [ 111.526610] Data abort info: [ 111.526612] ISV = 0, ISS = 0x00000047 [ 111.526615] CM = 0, WnR = 1 [ 111.526619] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000041d75000 [ 111.526623] [ffff8000118cb880] pgd=10000001bffff003, p4d=10000001bffff003, pud=10000001bfffe003, pmd=10000001bfffa003, pte=0000000000000000 [ 111.526642] Internal error: Oops: 96000047 [#1] PREEMPT SMP [ 111.526647] Modules linked in: dwc3_imx8mp dwc3 phy_fsl_imx8mq_usb [last unloaded: tcpci] [ 111.526663] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.13.0-rc4-00927-gebbe9dbd802c-dirty #36 [ 111.526670] Hardware name: NXP i.MX8MPlus EVK board (DT) [ 111.526674] pstate: 800000c5 (Nzcv daIF -PAN -UAO -TCO BTYPE=--) [ 111.526681] pc : queued_spin_lock_slowpath+0x1a0/0x390 [ 111.526695] lr : _raw_spin_lock_irqsave+0x88/0xb4 [ 111.526703] sp : ffff800010003e20 [ 111.526706] x29: ffff800010003e20 x28: ffff00017f380180 [ 111.537156] buffer_io_error: 6 callbacks suppressed [ 111.537162] Buffer I/O error on dev sda1, logical block 60040704, async page read [ 111.539932] x27: ffff00017f3801c0 [ 111.539938] x26: ffff800010ba2490 x25: 0000000000000000 x24: 0000000000000001 [ 111.543025] blk_update_request: I/O error, dev sda, sector 60061186 op 0x0:(READ) flags 0x0 phys_seg 7 prio class 0 [ 111.548304] [ 111.548306] x23: 00000000000000c0 x22: ffff0000c2a9f184 x21: ffff00017f380180 [ 111.551374] Buffer I/O error on dev sda1, logical block 60040705, async page read [ 111.554499] [ 111.554503] x20: ffff0000c5f14210 x19: 00000000000000c0 x18: 0000000000000000 [ 111.557391] Buffer I/O error on dev sda1, logical block 60040706, async page read [ 111.561218] [ 111.561222] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 111.564205] Buffer I/O error on dev sda1, logical block 60040707, async page read [ 111.570887] x14: 00000000000000f5 x13: 0000000000000001 x12: 0000000000000040 [ 111.570902] x11: ffff0000c05ac6d8 [ 111.583420] Buffer I/O error on dev sda1, logical block 60040708, async page read [ 111.588978] x10: 0000000000000000 x9 : 0000000000040000 [ 111.588988] x8 : 0000000000000000 [ 111.597173] Buffer I/O error on dev sda1, logical block 60040709, async page read [ 111.605766] x7 : ffff00017f384880 x6 : ffff8000118cb880 [ 111.605777] x5 : ffff00017f384880 [ 111.611094] Buffer I/O error on dev sda1, logical block 60040710, async page read [ 111.617086] x4 : 0000000000000000 x3 : ffff0000c2a9f184 [ 111.617096] x2 : ffff8000118cb880 [ 111.622242] Buffer I/O error on dev sda1, logical block 60040711, async page read [ 111.626927] x1 : ffff8000118cb880 x0 : ffff00017f384888 [ 111.626938] Call trace: [ 111.626942] queued_spin_lock_slowpath+0x1a0/0x390 [ 111.795809] kthread_queue_work+0x30/0xc0 [ 111.799828] state_machine_timer_handler+0x20/0x30 [ 111.804624] __hrtimer_run_queues+0x140/0x1e0 [ 111.808990] hrtimer_interrupt+0xec/0x2c0 [ 111.813004] arch_timer_handler_phys+0x38/0x50 [ 111.817456] handle_percpu_devid_irq+0x88/0x150 [ 111.821991] __handle_domain_irq+0x80/0xe0 [ 111.826093] gic_handle_irq+0xc0/0x140 [ 111.829848] el1_irq+0xbc/0x154 [ 111.832991] arch_cpu_idle+0x1c/0x2c [ 111.836572] default_idle_call+0x24/0x6c [ 111.840497] do_idle+0x238/0x2ac [ 111.843729] cpu_startup_entry+0x2c/0x70 [ 111.847657] rest_init+0xdc/0xec [ 111.850890] arch_call_rest_init+0x14/0x20 [ 111.854988] start_kernel+0x508/0x540 [ 111.858659] Code: 910020e0 8b0200c2 f861d884 aa0203e1 (f8246827) [ 111.864760] ---[ end trace 308b9a4a3dcb73ac ]--- [ 111.869381] Kernel panic - not syncing: Oops: Fatal exception in interrupt [ 111.876258] SMP: stopping secondary CPUs [ 111.880185] Kernel Offset: disabled [ 111.883673] CPU features: 0x00001001,20000846 [ 111.888031] Memory Limit: none [ 111.891090] ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]--- Fixes: 3ed8e1c2ac99 ("usb: typec: tcpm: Migrate workqueue to RT priority for processing events") Cc: stable Reviewed-by: Guenter Roeck Signed-off-by: Li Jun Link: https://lore.kernel.org/r/1622627829-11070-1-git-send-email-jun.li@nxp.com Signed-off-by: Greg Kroah-Hartman commit b972eff874637402ddc4a7dd11fb22538a0b6d28 Author: Maciej Żenczykowski Date: Tue Jun 8 19:44:59 2021 -0700 usb: fix various gadget panics on 10gbps cabling commit 032e288097a553db5653af552dd8035cd2a0ba96 upstream. usb_assign_descriptors() is called with 5 parameters, the last 4 of which are the usb_descriptor_header for: full-speed (USB1.1 - 12Mbps [including USB1.0 low-speed @ 1.5Mbps), high-speed (USB2.0 - 480Mbps), super-speed (USB3.0 - 5Gbps), super-speed-plus (USB3.1 - 10Gbps). The differences between full/high/super-speed descriptors are usually substantial (due to changes in the maximum usb block size from 64 to 512 to 1024 bytes and other differences in the specs), while the difference between 5 and 10Gbps descriptors may be as little as nothing (in many cases the same tuning is simply good enough). However if a gadget driver calls usb_assign_descriptors() with a NULL descriptor for super-speed-plus and is then used on a max 10gbps configuration, the kernel will crash with a null pointer dereference, when a 10gbps capable device port + cable + host port combination shows up. (This wouldn't happen if the gadget max-speed was set to 5gbps, but it of course defaults to the maximum, and there's no real reason to artificially limit it) The fix is to simply use the 5gbps descriptor as the 10gbps descriptor, if a 10gbps descriptor wasn't provided. Obviously this won't fix the problem if the 5gbps descriptor is also NULL, but such cases can't be so trivially solved (and any such gadgets are unlikely to be used with USB3 ports any way). Cc: Felipe Balbi Cc: Greg Kroah-Hartman Signed-off-by: Maciej Żenczykowski Cc: stable Link: https://lore.kernel.org/r/20210609024459.1126080-1-zenczykowski@gmail.com Signed-off-by: Greg Kroah-Hartman commit 4b289a0f3033f465b4fd51ba995251a7867a2aa2 Author: Maciej Żenczykowski Date: Mon Jun 7 21:41:41 2021 -0700 usb: fix various gadgets null ptr deref on 10gbps cabling. commit 90c4d05780d47e14a50e11a7f17373104cd47d25 upstream. This avoids a null pointer dereference in f_{ecm,eem,hid,loopback,printer,rndis,serial,sourcesink,subset,tcm} by simply reusing the 5gbps config for 10gbps. Fixes: eaef50c76057 ("usb: gadget: Update usb_assign_descriptors for SuperSpeedPlus") Cc: Christophe JAILLET Cc: Felipe Balbi Cc: Gustavo A. R. Silva Cc: Lorenzo Colitti Cc: Martin K. Petersen Cc: Michael R Sweet Cc: Mike Christie Cc: Pawel Laszczak Cc: Peter Chen Cc: Sudhakar Panneerselvam Cc: Wei Ming Chen Cc: Will McVicker Cc: Zqiang Reviewed-By: Lorenzo Colitti Cc: stable Signed-off-by: Maciej Żenczykowski Link: https://lore.kernel.org/r/20210608044141.3898496-1-zenczykowski@gmail.com Signed-off-by: Greg Kroah-Hartman commit 6bf8ff7d05204f0ec1842016280fedc00dd6b4d1 Author: Linyu Yuan Date: Wed Jun 9 07:35:47 2021 +0800 usb: gadget: eem: fix wrong eem header operation commit 305f670846a31a261462577dd0b967c4fa796871 upstream. when skb_clone() or skb_copy_expand() fail, it should pull skb with lengh indicated by header, or not it will read network data and check it as header. Cc: Signed-off-by: Linyu Yuan Link: https://lore.kernel.org/r/20210608233547.3767-1-linyyuan@codeaurora.org Signed-off-by: Greg Kroah-Hartman commit 21bee94fb9e4ace33f5fef5645b8a134efa35043 Author: Stefan Agner Date: Fri May 28 22:39:31 2021 +0200 USB: serial: cp210x: fix alternate function for CP2102N QFN20 commit 6f7ec77cc8b64ff5037c1945e4650c65c458037d upstream. The QFN20 part has a different GPIO/port function assignment. The configuration struct bit field ordered as TX/RX/RS485/WAKEUP/CLK which exactly matches GPIO0-3 for QFN24/28. However, QFN20 has a different GPIO to primary function assignment. Special case QFN20 to follow to properly detect which GPIOs are available. Signed-off-by: Stefan Agner Link: https://lore.kernel.org/r/51830b2b24118eb0f77c5c9ac64ffb2f519dbb1d.1622218300.git.stefan@agner.ch Fixes: c8acfe0aadbe ("USB: serial: cp210x: implement GPIO support for CP2102N") Cc: stable@vger.kernel.org # 4.19 Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 4fa815beeaf04f46a92897898e9175d7cc6057bc Author: Johan Hovold Date: Mon May 24 11:17:05 2021 +0200 USB: serial: quatech2: fix control-request directions commit eb8dbe80326c3d44c1e38ee4f40e0d8d3e06f2d0 upstream. The direction of the pipe argument must match the request-type direction bit or control requests may fail depending on the host-controller-driver implementation. Fix the three requests which erroneously used usb_rcvctrlpipe(). Fixes: f7a33e608d9a ("USB: serial: add quatech2 usb to serial driver") Cc: stable@vger.kernel.org # 3.5 Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit ef91a6bd946937c4db1e0a62b2c026811e3934a2 Author: Alexandre GRIVEAUX Date: Sun May 23 18:35:21 2021 +0200 USB: serial: omninet: add device id for Zyxel Omni 56K Plus commit fc0b3dc9a11771c3919eaaaf9d649138b095aa0f upstream. Add device id for Zyxel Omni 56K Plus modem, this modem include: USB chip: NetChip NET2888 Main chip: 901041A F721501APGF Another modem using the same chips is the Zyxel Omni 56K DUO/NEO, could be added with the right USB ID. Signed-off-by: Alexandre GRIVEAUX Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 1e2d41c17f437c0814a9624153c94e533055279e Author: George McCollister Date: Thu Jun 3 19:32:08 2021 -0500 USB: serial: ftdi_sio: add NovaTech OrionMX product ID commit bc96c72df33ee81b24d87eab953c73f7bcc04f29 upstream. Add PID for the NovaTech OrionMX so it can be automatically detected. Signed-off-by: George McCollister Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 5cead896962d8b25dee8a8efc85b076572732b86 Author: Wesley Cheng Date: Fri May 21 17:44:21 2021 -0700 usb: gadget: f_fs: Ensure io_completion_wq is idle during unbind commit 6fc1db5e6211e30fbb1cee8d7925d79d4ed2ae14 upstream. During unbind, ffs_func_eps_disable() will be executed, resulting in completion callbacks for any pending USB requests. When using AIO, irrespective of the completion status, io_data work is queued to io_completion_wq to evaluate and handle the completed requests. Since work runs asynchronously to the unbind() routine, there can be a scenario where the work runs after the USB gadget has been fully removed, resulting in accessing of a resource which has been already freed. (i.e. usb_ep_free_request() accessing the USB ep structure) Explicitly drain the io_completion_wq, instead of relying on the destroy_workqueue() (in ffs_data_put()) to make sure no pending completion work items are running. Signed-off-by: Wesley Cheng Cc: stable Link: https://lore.kernel.org/r/1621644261-1236-1-git-send-email-wcheng@codeaurora.org Signed-off-by: Greg Kroah-Hartman commit 0b3bb7950e73e46e7a697f35f893d115c55760ec Author: Andy Shevchenko Date: Mon Jun 7 23:50:06 2021 +0300 usb: typec: intel_pmc_mux: Add missed error check for devm_ioremap_resource() commit 843fabdd7623271330af07f1b7fbd7fabe33c8de upstream. devm_ioremap_resource() can return an error, add missed check for it. Fixes: 43d596e32276 ("usb: typec: intel_pmc_mux: Check the port status before connect") Reviewed-by: Heikki Krogerus Signed-off-by: Andy Shevchenko Cc: stable Link: https://lore.kernel.org/r/20210607205007.71458-2-andy.shevchenko@gmail.com Signed-off-by: Greg Kroah-Hartman commit 6900ef1b1095e2ffa6538895017a5408e4706e34 Author: Andy Shevchenko Date: Mon Jun 7 23:50:05 2021 +0300 usb: typec: intel_pmc_mux: Put fwnode in error case during ->probe() commit 1a85b350a7741776a406005b943e3dec02c424ed upstream. device_get_next_child_node() bumps a reference counting of a returned variable. We have to balance it whenever we return to the caller. Fixes: 6701adfa9693 ("usb: typec: driver for Intel PMC mux control") Cc: Heikki Krogerus Reviewed-by: Heikki Krogerus Signed-off-by: Andy Shevchenko Cc: stable Link: https://lore.kernel.org/r/20210607205007.71458-1-andy.shevchenko@gmail.com Signed-off-by: Greg Kroah-Hartman commit 572de10087a9f1a3475bede9ca54326d41c9523c Author: Mayank Rana Date: Wed Jun 9 00:35:35 2021 -0700 usb: typec: ucsi: Clear PPM capability data in ucsi_init() error path commit f247f0a82a4f8c3bfed178d8fd9e069d1424ee4e upstream. If ucsi_init() fails for some reason (e.g. ucsi_register_port() fails or general communication failure to the PPM), particularly at any point after the GET_CAPABILITY command had been issued, this results in unwinding the initialization and returning an error. However the ucsi structure's ucsi_capability member retains its current value, including likely a non-zero num_connectors. And because ucsi_init() itself is done in a workqueue a UCSI interface driver will be unaware that it failed and may think the ucsi_register() call was completely successful. Later, if ucsi_unregister() is called, due to this stale ucsi->cap value it would try to access the items in the ucsi->connector array which might not be in a proper state or not even allocated at all and results in NULL or invalid pointer dereference. Fix this by clearing the ucsi->cap value to 0 during the error path of ucsi_init() in order to prevent a later ucsi_unregister() from entering the connector cleanup loop. Fixes: c1b0bc2dabfa ("usb: typec: Add support for UCSI interface") Cc: stable@vger.kernel.org Acked-by: Heikki Krogerus Signed-off-by: Mayank Rana Signed-off-by: Jack Pham Link: https://lore.kernel.org/r/20210609073535.5094-1-jackp@codeaurora.org Signed-off-by: Greg Kroah-Hartman commit 7cee4344cbb30f07281b920b4b7bd9bee2c21c9d Author: Andy Shevchenko Date: Wed Jun 9 20:22:02 2021 +0300 usb: typec: wcove: Use LE to CPU conversion when accessing msg->header commit d5ab95da2a41567440097c277c5771ad13928dad upstream. As LKP noticed the Sparse is not happy about strict type handling: .../typec/tcpm/wcove.c:380:50: sparse: expected unsigned short [usertype] header .../typec/tcpm/wcove.c:380:50: sparse: got restricted __le16 const [usertype] header Fix this by switching to use pd_header_cnt_le() instead of pd_header_cnt() in the affected code. Fixes: ae8a2ca8a221 ("usb: typec: Group all TCPCI/TCPM code together") Fixes: 3c4fb9f16921 ("usb: typec: wcove: start using tcpm for USB PD support") Reported-by: kernel test robot Reviewed-by: Heikki Krogerus Reviewed-by: Guenter Roeck Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210609172202.83377-1-andriy.shevchenko@linux.intel.com Cc: stable Signed-off-by: Greg Kroah-Hartman commit 199af8a06de291d9f345f26a4e5fe2bc98cce262 Author: Thomas Petazzoni Date: Fri May 28 16:04:46 2021 +0200 usb: musb: fix MUSB_QUIRK_B_DISCONNECT_99 handling commit b65ba0c362be665192381cc59e3ac3ef6f0dd1e1 upstream. In commit 92af4fc6ec33 ("usb: musb: Fix suspend with devices connected for a64"), the logic to support the MUSB_QUIRK_B_DISCONNECT_99 quirk was modified to only conditionally schedule the musb->irq_work delayed work. This commit badly breaks ECM Gadget on AM335X. Indeed, with this commit, one can observe massive packet loss: $ ping 192.168.0.100 ... 15 packets transmitted, 3 received, 80% packet loss, time 14316ms Reverting this commit brings back a properly functioning ECM Gadget. An analysis of the commit seems to indicate that a mistake was made: the previous code was not falling through into the MUSB_QUIRK_B_INVALID_VBUS_91, but now it is, unless the condition is taken. Changing the logic to be as it was before the problematic commit *and* only conditionally scheduling musb->irq_work resolves the regression: $ ping 192.168.0.100 ... 64 packets transmitted, 64 received, 0% packet loss, time 64475ms Fixes: 92af4fc6ec33 ("usb: musb: Fix suspend with devices connected for a64") Cc: stable@vger.kernel.org Tested-by: Alexandre Belloni Tested-by: Drew Fustini Acked-by: Tony Lindgren Signed-off-by: Thomas Petazzoni Link: https://lore.kernel.org/r/20210528140446.278076-1-thomas.petazzoni@bootlin.com Signed-off-by: Greg Kroah-Hartman commit 470403639114895e2697c766fbe17be8d0e9b67a Author: Marian-Cristian Rotariu Date: Tue Jun 8 19:26:50 2021 +0300 usb: dwc3: ep0: fix NULL pointer exception commit d00889080ab60051627dab1d85831cd9db750e2a upstream. There is no validation of the index from dwc3_wIndex_to_dep() and we might be referring a non-existing ep and trigger a NULL pointer exception. In certain configurations we might use fewer eps and the index might wrongly indicate a larger ep index than existing. By adding this validation from the patch we can actually report a wrong index back to the caller. In our usecase we are using a composite device on an older kernel, but upstream might use this fix also. Unfortunately, I cannot describe the hardware for others to reproduce the issue as it is a proprietary implementation. [ 82.958261] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a4 [ 82.966891] Mem abort info: [ 82.969663] ESR = 0x96000006 [ 82.972703] Exception class = DABT (current EL), IL = 32 bits [ 82.978603] SET = 0, FnV = 0 [ 82.981642] EA = 0, S1PTW = 0 [ 82.984765] Data abort info: [ 82.987631] ISV = 0, ISS = 0x00000006 [ 82.991449] CM = 0, WnR = 0 [ 82.994409] user pgtable: 4k pages, 39-bit VAs, pgdp = 00000000c6210ccc [ 83.000999] [00000000000000a4] pgd=0000000053aa5003, pud=0000000053aa5003, pmd=0000000000000000 [ 83.009685] Internal error: Oops: 96000006 [#1] PREEMPT SMP [ 83.026433] Process irq/62-dwc3 (pid: 303, stack limit = 0x000000003985154c) [ 83.033470] CPU: 0 PID: 303 Comm: irq/62-dwc3 Not tainted 4.19.124 #1 [ 83.044836] pstate: 60000085 (nZCv daIf -PAN -UAO) [ 83.049628] pc : dwc3_ep0_handle_feature+0x414/0x43c [ 83.054558] lr : dwc3_ep0_interrupt+0x3b4/0xc94 ... [ 83.141788] Call trace: [ 83.144227] dwc3_ep0_handle_feature+0x414/0x43c [ 83.148823] dwc3_ep0_interrupt+0x3b4/0xc94 [ 83.181546] ---[ end trace aac6b5267d84c32f ]--- Signed-off-by: Marian-Cristian Rotariu Cc: stable Link: https://lore.kernel.org/r/20210608162650.58426-1-marian.c.rotariu@gmail.com Signed-off-by: Greg Kroah-Hartman commit 851dee5a5da56564a70290713aee665403bb0b24 Author: Jack Pham Date: Fri May 28 09:04:05 2021 -0700 usb: dwc3: gadget: Bail from dwc3_gadget_exit() if dwc->gadget is NULL commit 03715ea2e3dbbc56947137ce3b4ac18a726b2f87 upstream. There exists a possible scenario in which dwc3_gadget_init() can fail: during during host -> peripheral mode switch in dwc3_set_mode(), and a pending gadget driver fails to bind. Then, if the DRD undergoes another mode switch from peripheral->host the resulting dwc3_gadget_exit() will attempt to reference an invalid and dangling dwc->gadget pointer as well as call dma_free_coherent() on unmapped DMA pointers. The exact scenario can be reproduced as follows: - Start DWC3 in peripheral mode - Configure ConfigFS gadget with FunctionFS instance (or use g_ffs) - Run FunctionFS userspace application (open EPs, write descriptors, etc) - Bind gadget driver to DWC3's UDC - Switch DWC3 to host mode => dwc3_gadget_exit() is called. usb_del_gadget() will put the ConfigFS driver instance on the gadget_driver_pending_list - Stop FunctionFS application (closes the ep files) - Switch DWC3 to peripheral mode => dwc3_gadget_init() fails as usb_add_gadget() calls check_pending_gadget_drivers() and attempts to rebind the UDC to the ConfigFS gadget but fails with -19 (-ENODEV) because the FFS instance is not in FFS_ACTIVE state (userspace has not re-opened and written the descriptors yet, i.e. desc_ready!=0). - Switch DWC3 back to host mode => dwc3_gadget_exit() is called again, but this time dwc->gadget is invalid. Although it can be argued that userspace should take responsibility for ensuring that the FunctionFS application be ready prior to allowing the composite driver bind to the UDC, failure to do so should not result in a panic from the kernel driver. Fix this by setting dwc->gadget to NULL in the failure path of dwc3_gadget_init() and add a check to dwc3_gadget_exit() to bail out unless the gadget pointer is valid. Fixes: e81a7018d93a ("usb: dwc3: allocate gadget structure dynamically") Cc: Reviewed-by: Peter Chen Signed-off-by: Jack Pham Link: https://lore.kernel.org/r/20210528160405.17550-1-jackp@codeaurora.org Signed-off-by: Greg Kroah-Hartman commit 2af93b437a61e80df55aa2d321e931d124a93ef7 Author: Christophe JAILLET Date: Fri May 21 18:55:50 2021 +0200 usb: dwc3: meson-g12a: Disable the regulator in the error handling path of the probe commit 1d0d3d818eafe1963ec1eaf302175cd14938188e upstream. If an error occurs after a successful 'regulator_enable()' call, 'regulator_disable()' must be called. Fix the error handling path of the probe accordingly. The remove function doesn't need to be fixed, because the 'regulator_disable()' call is already hidden in 'dwc3_meson_g12a_suspend()' which is called via 'pm_runtime_set_suspended()' in the remove function. Fixes: c99993376f72 ("usb: dwc3: Add Amlogic G12A DWC3 glue") Reviewed-by: Martin Blumenstingl Acked-by: Neil Armstrong Signed-off-by: Christophe JAILLET Link: https://lore.kernel.org/r/79df054046224bbb0716a8c5c2082650290eec86.1621616013.git.christophe.jaillet@wanadoo.fr Cc: stable Signed-off-by: Greg Kroah-Hartman commit 750a0d75564293be3ed50f13ef7f38ab75106421 Author: Neil Armstrong Date: Tue Jun 1 10:48:30 2021 +0200 usb: dwc3-meson-g12a: fix usb2 PHY glue init when phy0 is disabled commit 4d2aa178d2ad2fb156711113790dde13e9aa2376 upstream. When only PHY1 is used (for example on Odroid-HC4), the regmap init code uses the usb2 ports when doesn't initialize the PHY1 regmap entry. This fixes: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 ... pc : regmap_update_bits_base+0x40/0xa0 lr : dwc3_meson_g12a_usb2_init_phy+0x4c/0xf8 ... Call trace: regmap_update_bits_base+0x40/0xa0 dwc3_meson_g12a_usb2_init_phy+0x4c/0xf8 dwc3_meson_g12a_usb2_init+0x7c/0xc8 dwc3_meson_g12a_usb_init+0x28/0x48 dwc3_meson_g12a_probe+0x298/0x540 platform_probe+0x70/0xe0 really_probe+0xf0/0x4d8 driver_probe_device+0xfc/0x168 ... Fixes: 013af227f58a97 ("usb: dwc3: meson-g12a: handle the phy and glue registers separately") Reviewed-by: Martin Blumenstingl Signed-off-by: Neil Armstrong Cc: stable Link: https://lore.kernel.org/r/20210601084830.260196-1-narmstrong@baylibre.com Signed-off-by: Greg Kroah-Hartman commit b452e8bb7c525fbecc69aef44b0721d2ece032bc Author: Kyle Tso Date: Fri May 28 16:16:13 2021 +0800 usb: pd: Set PD_T_SINK_WAIT_CAP to 310ms commit 6490fa565534fa83593278267785a694fd378a2b upstream. Current timer PD_T_SINK_WAIT_CAP is set to 240ms which will violate the SinkWaitCapTimer (tTypeCSinkWaitCap 310 - 620 ms) defined in the PD Spec if the port is faster enough when running the state machine. Set it to the lower bound 310ms to ensure the timeout is in Spec. Fixes: f0690a25a140 ("staging: typec: USB Type-C Port Manager (tcpm)") Cc: stable Reviewed-by: Guenter Roeck Signed-off-by: Kyle Tso Link: https://lore.kernel.org/r/20210528081613.730661-1-kyletso@google.com Signed-off-by: Greg Kroah-Hartman commit 0ff5f83ae147e63c297e0a5515c9c271b7448f6f Author: Maciej Żenczykowski Date: Tue Jun 8 01:54:38 2021 -0700 usb: f_ncm: only first packet of aggregate needs to start timer commit 1958ff5ad2d4908b44a72bcf564dfe67c981e7fe upstream. The reasoning for this change is that if we already had a packet pending, then we also already had a pending timer, and as such there is no need to reschedule it. This also prevents packets getting delayed 60 ms worst case under a tiny packet every 290us transmit load, by keeping the timeout always relative to the first queued up packet. (300us delay * 16KB max aggregation / 80 byte packet =~ 60 ms) As such the first packet is now at most delayed by 300us. Under low transmit load, this will simply result in us sending a shorter aggregate, as originally intended. This patch has the benefit of greatly reducing (by ~10 factor with 1500 byte frames aggregated into 16 kiB) the number of (potentially pretty costly) updates to the hrtimer. Cc: Brooke Basile Cc: Bryan O'Donoghue Cc: Felipe Balbi Cc: Lorenzo Colitti Signed-off-by: Maciej Żenczykowski Link: https://lore.kernel.org/r/20210608085438.813960-1-zenczykowski@gmail.com Cc: stable Signed-off-by: Greg Kroah-Hartman commit 0f5a20b1fd9da3ac9f7c6edcad522712ca694d5c Author: Maciej Żenczykowski Date: Mon Jun 7 17:53:44 2021 -0700 USB: f_ncm: ncm_bitrate (speed) is unsigned commit 3370139745853f7826895293e8ac3aec1430508e upstream. [ 190.544755] configfs-gadget gadget: notify speed -44967296 This is because 4250000000 - 2**32 is -44967296. Fixes: 9f6ce4240a2b ("usb: gadget: f_ncm.c added") Cc: Brooke Basile Cc: Bryan O'Donoghue Cc: Felipe Balbi Cc: Lorenzo Colitti Cc: Yauheni Kaliuta Cc: Linux USB Mailing List Acked-By: Lorenzo Colitti Signed-off-by: Maciej Żenczykowski Cc: stable Link: https://lore.kernel.org/r/20210608005344.3762668-1-zenczykowski@gmail.com Signed-off-by: Greg Kroah-Hartman commit 1bf2c28ab2684a05c0c6b0be70682a44312b4785 Author: Geert Uytterhoeven Date: Fri Jun 4 14:59:43 2021 +0200 mmc: renesas_sdhi: Fix HS400 on R-Car M3-W+ commit 6687cd72aa9112a454a4646986e0402dd1b07d0e upstream. R-Car M3-W ES3.0 is marketed as R-Car M3-W+ (R8A77961), and has its own compatible value "renesas,r8a77961". Hence using soc_device_match() with soc_id = "r8a7796" and revision = "ES3.*" does not actually match running on an R-Car M3-W+ SoC. Fix this by matching with soc_id = "r8a77961" instead. Fixes: a38c078fea0b1393 ("mmc: renesas_sdhi: Avoid bad TAP in HS400") Signed-off-by: Geert Uytterhoeven Reviewed-by: Wolfram Sang Reviewed-by: Niklas Söderlund Reviewed-by: Yoshihiro Shimoda Link: https://lore.kernel.org/r/ee8af5d631f5331139ffea714539030d97352e93.1622811525.git.geert+renesas@glider.be Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 67aca230caf346ddf608ee69469777cd52929493 Author: Wolfram Sang Date: Wed Jun 2 09:34:35 2021 +0200 mmc: renesas_sdhi: abort tuning when timeout detected commit 2c9017d0b5d3fbf17e69577a42d9e610ca122810 upstream. We have to bring the eMMC from sending-data state back to transfer state once we detected a CRC error (timeout) during tuning. So, send a stop command via mmc_abort_tuning(). Fixes: 4f11997773b6 ("mmc: tmio: Add tuning support") Reported-by Yoshihiro Shimoda Signed-off-by: Wolfram Sang Reviewed-by: Niklas Söderlund Reviewed-by: Yoshihiro Shimoda Tested-by: Yoshihiro Shimoda Link: https://lore.kernel.org/r/20210602073435.5955-1-wsa+renesas@sang-engineering.com Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 97524384762c1fb9b3ded931498dd2047bd0de81 Author: Steven Rostedt (VMware) Date: Mon Jun 7 21:39:08 2021 -0400 ftrace: Do not blindly read the ip address in ftrace_bug() commit 6c14133d2d3f768e0a35128faac8aa6ed4815051 upstream. It was reported that a bug on arm64 caused a bad ip address to be used for updating into a nop in ftrace_init(), but the error path (rightfully) returned -EINVAL and not -EFAULT, as the bug caused more than one error to occur. But because -EINVAL was returned, the ftrace_bug() tried to report what was at the location of the ip address, and read it directly. This caused the machine to panic, as the ip was not pointing to a valid memory address. Instead, read the ip address with copy_from_kernel_nofault() to safely access the memory, and if it faults, report that the address faulted, otherwise report what was in that location. Link: https://lore.kernel.org/lkml/20210607032329.28671-1-mark-pk.tsai@mediatek.com/ Cc: stable@vger.kernel.org Fixes: 05736a427f7e1 ("ftrace: warn on failure to disable mcount callers") Reported-by: Mark-PK Tsai Tested-by: Mark-PK Tsai Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 74d3b20b1b206a76f2cbccc5e09106adf6b5775c Author: Alexander Kuznetsov Date: Wed Jun 9 10:17:19 2021 +0300 cgroup1: don't allow '\n' in renaming commit b7e24eb1caa5f8da20d405d262dba67943aedc42 upstream. cgroup_mkdir() have restriction on newline usage in names: $ mkdir $'/sys/fs/cgroup/cpu/test\ntest2' mkdir: cannot create directory '/sys/fs/cgroup/cpu/test\ntest2': Invalid argument But in cgroup1_rename() such check is missed. This allows us to make /proc//cgroup unparsable: $ mkdir /sys/fs/cgroup/cpu/test $ mv /sys/fs/cgroup/cpu/test $'/sys/fs/cgroup/cpu/test\ntest2' $ echo $$ > $'/sys/fs/cgroup/cpu/test\ntest2' $ cat /proc/self/cgroup 11:pids:/ 10:freezer:/ 9:hugetlb:/ 8:cpuset:/ 7:blkio:/user.slice 6:memory:/user.slice 5:net_cls,net_prio:/ 4:perf_event:/ 3:devices:/user.slice 2:cpu,cpuacct:/test test2 1:name=systemd:/ 0::/ Signed-off-by: Alexander Kuznetsov Reported-by: Andrey Krasichkov Acked-by: Dmitry Yakunin Cc: stable@vger.kernel.org Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 31fe243a6376e81f69ffab3853c35a6c4f3be5fc Author: Nikolay Borisov Date: Mon May 31 12:26:01 2021 +0300 btrfs: promote debugging asserts to full-fledged checks in validate_super commit aefd7f7065567a4666f42c0fc8cdb379d2e036bf upstream. Syzbot managed to trigger this assert while performing its fuzzing. Turns out it's better to have those asserts turned into full-fledged checks so that in case buggy btrfs images are mounted the users gets an error and mounting is stopped. Alternatively with CONFIG_BTRFS_ASSERT disabled such image would have been erroneously allowed to be mounted. Reported-by: syzbot+a6bf271c02e4fe66b4e4@syzkaller.appspotmail.com CC: stable@vger.kernel.org # 5.4+ Reviewed-by: Johannes Thumshirn Reviewed-by: Qu Wenruo Signed-off-by: Nikolay Borisov Reviewed-by: David Sterba [ add uuids to the messages ] Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit ca69dc891b2875e73cf55defaf06bad27c44573c Author: Ritesh Harjani Date: Sun May 30 20:24:05 2021 +0530 btrfs: return value from btrfs_mark_extent_written() in case of error commit e7b2ec3d3d4ebeb4cff7ae45cf430182fa6a49fb upstream. We always return 0 even in case of an error in btrfs_mark_extent_written(). Fix it to return proper error value in case of a failure. All callers handle it. CC: stable@vger.kernel.org # 4.4+ Signed-off-by: Ritesh Harjani Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit bf240fee5b341fbc68615f04892af274e7abf8b3 Author: Xiao Ni Date: Fri May 28 14:16:38 2021 +0800 async_xor: check src_offs is not NULL before updating it commit 9be148e408df7d361ec5afd6299b7736ff3928b0 upstream. When PAGE_SIZE is greater than 4kB, multiple stripes may share the same page. Thus, src_offs is added to async_xor_offs() with array of offsets. However, async_xor() passes NULL src_offs to async_xor_offs(). In such case, src_offs should not be updated. Add a check before the update. Fixes: ceaf2966ab08(async_xor: increase src_offs when dropping destination page) Cc: stable@vger.kernel.org # v5.10+ Reported-by: Oleksandr Shchirskyi Tested-by: Oleksandr Shchirskyi Signed-off-by: Xiao Ni Signed-off-by: Song Liu Signed-off-by: Greg Kroah-Hartman commit 8d5c0f6b7a784f5ff71fb463ecad58cf042cfccb Author: Wenli Looi Date: Mon Jun 7 23:46:20 2021 -0700 staging: rtl8723bs: Fix uninitialized variables commit 43c85d770db80cb135f576f8fde6ff1a08e707a4 upstream. The sinfo.pertid and sinfo.generation variables are not initialized and it causes a crash when we use this as a wireless access point. [ 456.873025] ------------[ cut here ]------------ [ 456.878198] kernel BUG at mm/slub.c:3968! [ 456.882680] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM [ snip ] [ 457.271004] Backtrace: [ 457.273733] [] (kfree) from [] (nl80211_send_station+0x954/0xfc4) [ 457.282481] r9:eccca0c0 r8:e8edfec0 r7:00000000 r6:00000011 r5:e80a9480 r4:e8edfe00 [ 457.291132] [] (nl80211_send_station) from [] (cfg80211_new_sta+0x90/0x1cc) [ 457.300850] r10:e80a9480 r9:e8edfe00 r8:ea678cca r7:00000a20 r6:00000000 r5:ec46d000 [ 457.309586] r4:ec46d9e0 [ 457.312433] [] (cfg80211_new_sta) from [] (rtw_cfg80211_indicate_sta_assoc+0x80/0x9c [r8723bs]) [ 457.324095] r10:00009930 r9:e85b9d80 r8:bf091050 r7:00000000 r6:00000000 r5:0000001c [ 457.332831] r4:c1606788 [ 457.335692] [] (rtw_cfg80211_indicate_sta_assoc [r8723bs]) from [] (rtw_stassoc_event_callback+0x1c8/0x1d4 [r8723bs]) [ 457.349489] r7:ea678cc0 r6:000000a1 r5:f1225f84 r4:f086b000 [ 457.355845] [] (rtw_stassoc_event_callback [r8723bs]) from [] (mlme_evt_hdl+0x8c/0xb4 [r8723bs]) [ 457.367601] r7:c1604900 r6:f086c4b8 r5:00000000 r4:f086c000 [ 457.373959] [] (mlme_evt_hdl [r8723bs]) from [] (rtw_cmd_thread+0x198/0x3d8 [r8723bs]) [ 457.384744] r5:f086e000 r4:f086c000 [ 457.388754] [] (rtw_cmd_thread [r8723bs]) from [] (kthread+0x170/0x174) [ 457.398083] r10:ed7a57e8 r9:bf0367a4 r8:f086b000 r7:e8ede000 r6:00000000 r5:e9975200 [ 457.406828] r4:e8369900 [ 457.409653] [] (kthread) from [] (ret_from_fork+0x14/0x2c) [ 457.417718] Exception stack(0xe8edffb0 to 0xe8edfff8) [ 457.423356] ffa0: 00000000 00000000 00000000 00000000 [ 457.432492] ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 457.441618] ffe0: 00000000 00000000 00000000 00000000 00000013 00000000 [ 457.449006] r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c014a0a4 [ 457.457750] r4:e9975200 [ 457.460574] Code: 1a000003 e5953004 e3130001 1a000000 (e7f001f2) [ 457.467381] ---[ end trace 4acbc8c15e9e6aa7 ]--- Link: https://forum.armbian.com/topic/14727-wifi-ap-kernel-bug-in-kernel-5444/ Fixes: 8689c051a201 ("cfg80211: dynamically allocate per-tid stats for station info") Fixes: f5ea9120be2e ("nl80211: add generation number to all dumps") Signed-off-by: Wenli Looi Reviewed-by: Dan Carpenter Cc: stable Link: https://lore.kernel.org/r/20210608064620.74059-1-wlooi@ucalgary.ca Signed-off-by: Greg Kroah-Hartman commit 7af299b97734c7e7f465b42a2139ce4d77246975 Author: Paolo Bonzini Date: Tue Jun 8 15:31:42 2021 -0400 kvm: avoid speculation-based attacks from out-of-range memslot accesses commit da27a83fd6cc7780fea190e1f5c19e87019da65c upstream. KVM's mechanism for accessing guest memory translates a guest physical address (gpa) to a host virtual address using the right-shifted gpa (also known as gfn) and a struct kvm_memory_slot. The translation is performed in __gfn_to_hva_memslot using the following formula: hva = slot->userspace_addr + (gfn - slot->base_gfn) * PAGE_SIZE It is expected that gfn falls within the boundaries of the guest's physical memory. However, a guest can access invalid physical addresses in such a way that the gfn is invalid. __gfn_to_hva_memslot is called from kvm_vcpu_gfn_to_hva_prot, which first retrieves a memslot through __gfn_to_memslot. While __gfn_to_memslot does check that the gfn falls within the boundaries of the guest's physical memory or not, a CPU can speculate the result of the check and continue execution speculatively using an illegal gfn. The speculation can result in calculating an out-of-bounds hva. If the resulting host virtual address is used to load another guest physical address, this is effectively a Spectre gadget consisting of two consecutive reads, the second of which is data dependent on the first. Right now it's not clear if there are any cases in which this is exploitable. One interesting case was reported by the original author of this patch, and involves visiting guest page tables on x86. Right now these are not vulnerable because the hva read goes through get_user(), which contains an LFENCE speculation barrier. However, there are patches in progress for x86 uaccess.h to mask kernel addresses instead of using LFENCE; once these land, a guest could use speculation to read from the VMM's ring 3 address space. Other architectures such as ARM already use the address masking method, and would be susceptible to this same kind of data-dependent access gadgets. Therefore, this patch proactively protects from these attacks by masking out-of-bounds gfns in __gfn_to_hva_memslot, which blocks speculation of invalid hvas. Sean Christopherson noted that this patch does not cover kvm_read_guest_offset_cached. This however is limited to a few bytes past the end of the cache, and therefore it is unlikely to be useful in the context of building a chain of data dependent accesses. Reported-by: Artemiy Margaritov Co-developed-by: Artemiy Margaritov Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 6b6ff4d1f349cb35a7c7d2057819af1b14f80437 Author: Lai Jiangshan Date: Thu Jun 3 13:24:55 2021 +0800 KVM: X86: MMU: Use the correct inherited permissions to get shadow page commit b1bd5cba3306691c771d558e94baa73e8b0b96b7 upstream. When computing the access permissions of a shadow page, use the effective permissions of the walk up to that point, i.e. the logic AND of its parents' permissions. Two guest PxE entries that point at the same table gfn need to be shadowed with different shadow pages if their parents' permissions are different. KVM currently uses the effective permissions of the last non-leaf entry for all non-leaf entries. Because all non-leaf SPTEs have full ("uwx") permissions, and the effective permissions are recorded only in role.access and merged into the leaves, this can lead to incorrect reuse of a shadow page and eventually to a missing guest protection page fault. For example, here is a shared pagetable: pgd[] pud[] pmd[] virtual address pointers /->pmd1(u--)->pte1(uw-)->page1 <- ptr1 (u--) /->pud1(uw-)--->pmd2(uw-)->pte2(uw-)->page2 <- ptr2 (uw-) pgd-| (shared pmd[] as above) \->pud2(u--)--->pmd1(u--)->pte1(uw-)->page1 <- ptr3 (u--) \->pmd2(uw-)->pte2(uw-)->page2 <- ptr4 (u--) pud1 and pud2 point to the same pmd table, so: - ptr1 and ptr3 points to the same page. - ptr2 and ptr4 points to the same page. (pud1 and pud2 here are pud entries, while pmd1 and pmd2 here are pmd entries) - First, the guest reads from ptr1 first and KVM prepares a shadow page table with role.access=u--, from ptr1's pud1 and ptr1's pmd1. "u--" comes from the effective permissions of pgd, pud1 and pmd1, which are stored in pt->access. "u--" is used also to get the pagetable for pud1, instead of "uw-". - Then the guest writes to ptr2 and KVM reuses pud1 which is present. The hypervisor set up a shadow page for ptr2 with pt->access is "uw-" even though the pud1 pmd (because of the incorrect argument to kvm_mmu_get_page in the previous step) has role.access="u--". - Then the guest reads from ptr3. The hypervisor reuses pud1's shadow pmd for pud2, because both use "u--" for their permissions. Thus, the shadow pmd already includes entries for both pmd1 and pmd2. - At last, the guest writes to ptr4. This causes no vmexit or pagefault, because pud1's shadow page structures included an "uw-" page even though its role.access was "u--". Any kind of shared pagetable might have the similar problem when in virtual machine without TDP enabled if the permissions are different from different ancestors. In order to fix the problem, we change pt->access to be an array, and any access in it will not include permissions ANDed from child ptes. The test code is: https://lore.kernel.org/kvm/20210603050537.19605-1-jiangshanlai@gmail.com/ Remember to test it with TDP disabled. The problem had existed long before the commit 41074d07c78b ("KVM: MMU: Fix inherited permissions for emulated guest pte updates"), and it is hard to find which is the culprit. So there is no fixes tag here. Signed-off-by: Lai Jiangshan Message-Id: <20210603052455.21023-1-jiangshanlai@gmail.com> Cc: stable@vger.kernel.org Fixes: cea0f0e7ea54 ("[PATCH] KVM: MMU: Shadow page table caching") Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 14831b79560b3408e0ea5d4ba37a465a04b70a11 Author: Kan Liang Date: Tue Jun 1 06:09:03 2021 -0700 perf/x86/intel/uncore: Fix M2M event umask for Ice Lake server commit 848ff3768684701a4ce73a2ec0e5d438d4e2b0da upstream. Perf tool errors out with the latest event list for the Ice Lake server. event syntax error: 'unc_m2m_imc_reads.to_pmm' \___ value too big for format, maximum is 255 The same as the Snow Ridge server, the M2M uncore unit in the Ice Lake server has the unit mask extension field as well. Fixes: 2b3b76b5ec67 ("perf/x86/intel/uncore: Add Ice Lake server uncore support") Reported-by: Jin Yao Signed-off-by: Kan Liang Signed-off-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/1622552943-119174-1-git-send-email-kan.liang@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit aa8591a58cbd2986090709e4202881f18e8ae30e Author: Desmond Cheong Zhi Xi Date: Wed Jun 9 17:21:19 2021 +0800 drm: Lock pointer access in drm_master_release() commit c336a5ee984708db4826ef9e47d184e638e29717 upstream. This patch eliminates the following smatch warning: drivers/gpu/drm/drm_auth.c:320 drm_master_release() warn: unlocked access 'master' (line 318) expected lock '&dev->master_mutex' The 'file_priv->master' field should be protected by the mutex lock to '&dev->master_mutex'. This is because other processes can concurrently modify this field and free the current 'file_priv->master' pointer. This could result in a use-after-free error when 'master' is dereferenced in subsequent function calls to 'drm_legacy_lock_master_cleanup()' or to 'drm_lease_revoke()'. An example of a scenario that would produce this error can be seen from a similar bug in 'drm_getunique()' that was reported by Syzbot: https://syzkaller.appspot.com/bug?id=148d2f1dfac64af52ffd27b661981a540724f803 In the Syzbot report, another process concurrently acquired the device's master mutex in 'drm_setmaster_ioctl()', then overwrote 'fpriv->master' in 'drm_new_set_master()'. The old value of 'fpriv->master' was subsequently freed before the mutex was unlocked. Reported-by: Dan Carpenter Signed-off-by: Desmond Cheong Zhi Xi Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20210609092119.173590-1-desmondcheongzx@gmail.com Signed-off-by: Greg Kroah-Hartman commit 491d52e0078860b33b6c14f0a7ac74ca1b603bd6 Author: Desmond Cheong Zhi Xi Date: Tue Jun 8 19:04:36 2021 +0800 drm: Fix use-after-free read in drm_getunique() commit b436acd1cf7fac0ba987abd22955d98025c80c2b upstream. There is a time-of-check-to-time-of-use error in drm_getunique() due to retrieving file_priv->master prior to locking the device's master mutex. An example can be seen in the crash report of the use-after-free error found by Syzbot: https://syzkaller.appspot.com/bug?id=148d2f1dfac64af52ffd27b661981a540724f803 In the report, the master pointer was used after being freed. This is because another process had acquired the device's master mutex in drm_setmaster_ioctl(), then overwrote fpriv->master in drm_new_set_master(). The old value of fpriv->master was subsequently freed before the mutex was unlocked. To fix this, we lock the device's master mutex before retrieving the pointer from from fpriv->master. This patch passes the Syzbot reproducer test. Reported-by: syzbot+c3a706cec1ea99e1c693@syzkaller.appspotmail.com Signed-off-by: Desmond Cheong Zhi Xi Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20210608110436.239583-1-desmondcheongzx@gmail.com Signed-off-by: Greg Kroah-Hartman commit afd87792db355282c4608356b98bb2dd650a6885 Author: Zhang Rui Date: Thu Jun 3 10:34:14 2021 +0800 Revert "ACPI: sleep: Put the FACS table after using it" commit f1ffa9d4cccc8fdf6c03fb1b3429154d22037988 upstream. Commit 95722237cb2a ("ACPI: sleep: Put the FACS table after using it") puts the FACS table during initialization. But the hardware signature bits in the FACS table need to be accessed, after every hibernation, to compare with the original hardware signature. So there is no reason to release the FACS table mapping after initialization. This reverts commit 95722237cb2ae4f7b73471058cdb19e8f4057c93. An alternative solution is to use acpi_gbl_FACS variable instead, which is mapped by the ACPICA core and never released. Link: https://bugzilla.kernel.org/show_bug.cgi?id=212277 Reported-by: Stephan Hohe Signed-off-by: Zhang Rui Cc: 5.8+ # 5.8+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 82a8ffba54d31e97582051cb56ba1f988018681e Author: Lukas Wunner Date: Sat May 22 19:49:50 2021 +0200 spi: bcm2835: Fix out-of-bounds access with more than 4 slaves commit 13817d466eb8713a1ffd254f537402f091d48444 upstream. Commit 571e31fa60b3 ("spi: bcm2835: Cache CS register value for ->prepare_message()") limited the number of slaves to 3 at compile-time. The limitation was necessitated by a statically-sized array prepare_cs[] in the driver private data which contains a per-slave register value. The commit sought to enforce the limitation at run-time by setting the controller's num_chipselect to 3: Slaves with a higher chipselect are rejected by spi_add_device(). However the commit neglected that num_chipselect only limits the number of *native* chipselects. If GPIO chipselects are specified in the device tree for more than 3 slaves, num_chipselect is silently raised by of_spi_get_gpio_numbers() and the result are out-of-bounds accesses to the statically-sized array prepare_cs[]. As a bandaid fix which is backportable to stable, raise the number of allowed slaves to 24 (which "ought to be enough for anybody"), enforce the limitation on slave ->setup and revert num_chipselect to 3 (which is the number of native chipselects supported by the controller). An upcoming for-next commit will allow an arbitrary number of slaves. Fixes: 571e31fa60b3 ("spi: bcm2835: Cache CS register value for ->prepare_message()") Reported-by: Joe Burmeister Signed-off-by: Lukas Wunner Cc: stable@vger.kernel.org # v5.4+ Cc: Phil Elwell Link: https://lore.kernel.org/r/75854affc1923309fde05e47494263bde73e5592.1621703210.git.lukas@wunner.de Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 05e6b715947592c5103ebdf13182fcacf522a8ed Author: Jeremy Szu Date: Tue Jun 8 19:47:48 2021 +0800 ALSA: hda/realtek: fix mute/micmute LEDs for HP ZBook Power G8 commit 600dd2a7e8b62170d177381cc1303861f48f9780 upstream. The HP ZBook Power G8 using ALC236 codec which using 0x02 to control mute LED and 0x01 to control micmute LED. Therefore, add a quirk to make it works. Signed-off-by: Jeremy Szu Cc: Link: https://lore.kernel.org/r/20210608114750.32009-1-jeremy.szu@canonical.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit d62d55f3941b99a88384ce764f70bc5865d42c06 Author: Jeremy Szu Date: Sat Jun 5 16:25:38 2021 +0800 ALSA: hda/realtek: fix mute/micmute LEDs for HP EliteBook 840 Aero G8 commit dfb06401b4cdfc71e2fc3e19b877ab845cc9f7f7 upstream. The HP EliteBook 840 Aero G8 using ALC285 codec which using 0x04 to control mute LED and 0x01 to control micmute LED. In the other hand, there is no output from right channel of speaker. Therefore, add a quirk to make it works. Signed-off-by: Jeremy Szu Cc: Link: https://lore.kernel.org/r/20210605082539.41797-3-jeremy.szu@canonical.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 557306806777762f8faa57a1a43cd427aa0ebd93 Author: Jeremy Szu Date: Sat Jun 5 16:25:37 2021 +0800 ALSA: hda/realtek: fix mute/micmute LEDs and speaker for HP EliteBook x360 1040 G8 commit 61d3e87468fad82dc8e8cb6de7db563ada64b532 upstream. The HP EliteBook x360 1040 G8 using ALC285 codec which using 0x04 to control mute LED and 0x01 to control micmute LED. In the other hand, there is no output from right channel of speaker. Therefore, add a quirk to make it works. Signed-off-by: Jeremy Szu Cc: Link: https://lore.kernel.org/r/20210605082539.41797-2-jeremy.szu@canonical.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit bd0fe358d182de23dd5be92750b5538becba68ef Author: Jeremy Szu Date: Sat Jun 5 16:25:36 2021 +0800 ALSA: hda/realtek: fix mute/micmute LEDs and speaker for HP Elite Dragonfly G2 commit 15d295b560e6dd45f839a53ae69e4f63b54eb32f upstream. The HP Elite Dragonfly G2 using ALC285 codec which using 0x04 to control mute LED and 0x01 to control micmute LED. In the other hand, there is no output from right channel of speaker. Therefore, add a quirk to make it works. Signed-off-by: Jeremy Szu Cc: Link: https://lore.kernel.org/r/20210605082539.41797-1-jeremy.szu@canonical.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 6a81e47788fffcf046db4f3328e74cbe6dc8fbb5 Author: Hui Wang Date: Tue Jun 8 10:46:00 2021 +0800 ALSA: hda/realtek: headphone and mic don't work on an Acer laptop commit 57c9e21a49b1c196cda28f54de9a5d556ac93f20 upstream. There are 2 issues on this machine, the 1st one is mic's plug/unplug can't be detected, that is because the mic is set to manual detecting mode, need to apply ALC255_FIXUP_XIAOMI_HEADSET_MIC to set it to auto detecting mode. The other one is headphone's plug/unplug can't be detected by pulseaudio, that is because the pulseaudio will use ucm2/sof-hda-dsp on this machine, and the ucm2 only handle 'Headphone Jack', but on this machine the headphone's pincfg sets the location to Front, then the alsa mixer name is "Front Headphone Jack" instead of "Headphone Jack", so override the pincfg to change location to Left. BugLink: http://bugs.launchpad.net/bugs/1930188 Cc: Signed-off-by: Hui Wang Link: https://lore.kernel.org/r/20210608024600.6198-1-hui.wang@canonical.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 98f842951f8aa222e8a8453e6dbce6c056e9984f Author: Takashi Sakamoto Date: Sat Jun 5 18:10:54 2021 +0900 ALSA: firewire-lib: fix the context to call snd_pcm_stop_xrun() commit 9981b20a5e3694f4625ab5a1ddc98ce7503f6d12 upstream. In the workqueue to queue wake-up event, isochronous context is not processed, thus it's useless to check context for the workqueue to switch status of runtime for PCM substream to XRUN. On the other hand, in software IRQ context of 1394 OHCI, it's needed. This commit fixes the bug introduced when tasklet was replaced with workqueue. Cc: Fixes: 2b3d2987d800 ("ALSA: firewire: Replace tasklet with work") Signed-off-by: Takashi Sakamoto Link: https://lore.kernel.org/r/20210605091054.68866-1-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit bd7d88b0874f82f7b29d1a53e574cedaf23166ba Author: Takashi Iwai Date: Thu Jun 10 17:20:59 2021 +0200 ALSA: seq: Fix race of snd_seq_timer_open() commit 83e197a8414c0ba545e7e3916ce05f836f349273 upstream. The timer instance per queue is exclusive, and snd_seq_timer_open() should have managed the concurrent accesses. It looks as if it's checking the already existing timer instance at the beginning, but it's not right, because there is no protection, hence any later concurrent call of snd_seq_timer_open() may override the timer instance easily. This may result in UAF, as the leftover timer instance can keep running while the queue itself gets closed, as spotted by syzkaller recently. For avoiding the race, add a proper check at the assignment of tmr->timeri again, and return -EBUSY if it's been already registered. Reported-by: syzbot+ddc1260a83ed1cbf6fb5@syzkaller.appspotmail.com Cc: Link: https://lore.kernel.org/r/000000000000dce34f05c42f110c@google.com Link: https://lore.kernel.org/r/20210610152059.24633-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit fff6af6deae8af944f07eb27dba0236e1a2e95cb Author: Chris Packham Date: Wed May 12 09:20:52 2021 +1200 i2c: mpc: implement erratum A-004447 workaround [ Upstream commit 8f0cdec8b5fd94135d643662506ee94ae9e98785 ] The P2040/P2041 has an erratum where the normal i2c recovery mechanism does not work. Implement the alternative recovery mechanism documented in the P2040 Chip Errata Rev Q. Signed-off-by: Chris Packham Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit d78b76af9f61f384526137d45e53cea0a1020132 Author: Chris Packham Date: Mon Mar 29 14:52:03 2021 +1300 i2c: mpc: Make use of i2c_recover_bus() [ Upstream commit 65171b2df15eb7545431d75c2729b5062da89b43 ] Move the existing calls of mpc_i2c_fixup() to a recovery function registered via bus_recovery_info. This makes it more obvious that recovery is supported and allows for a future where recovery is triggered by the i2c core. Signed-off-by: Chris Packham Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit fa05ba61967ad051f5f2b7c4f39d6c56719c9900 Author: Lukas Wunner Date: Thu May 27 23:10:56 2021 +0200 spi: Cleanup on failure of initial setup [ Upstream commit 2ec6f20b33eb4f62ab90bdcd620436c883ec3af6 ] Commit c7299fea6769 ("spi: Fix spi device unregister flow") changed the SPI core's behavior if the ->setup() hook returns an error upon adding an spi_device: Before, the ->cleanup() hook was invoked to free any allocations that were made by ->setup(). With the commit, that's no longer the case, so the ->setup() hook is expected to free the allocations itself. I've identified 5 drivers which depend on the old behavior and am fixing them up hereinafter: spi-bitbang.c spi-fsl-spi.c spi-omap-uwire.c spi-omap2-mcspi.c spi-pxa2xx.c Importantly, ->setup() is not only invoked on spi_device *addition*: It may subsequently be called to *change* SPI parameters. If changing these SPI parameters fails, freeing memory allocations would be wrong. That should only be done if the spi_device is finally destroyed. I am therefore using a bool "initial_setup" in 4 of the affected drivers to differentiate between the invocation on *adding* the spi_device and any subsequent invocations: spi-bitbang.c spi-fsl-spi.c spi-omap-uwire.c spi-omap2-mcspi.c In spi-pxa2xx.c, it seems the ->setup() hook can only fail on spi_device addition, not any subsequent calls. It therefore doesn't need the bool. It's worth noting that 5 other drivers already perform a cleanup if the ->setup() hook fails. Before c7299fea6769, they caused a double-free if ->setup() failed on spi_device addition. Since the commit, they're fine. These drivers are: spi-mpc512x-psc.c spi-pl022.c spi-s3c64xx.c spi-st-ssc4.c spi-tegra114.c (spi-pxa2xx.c also already performs a cleanup, but only in one of several error paths.) Fixes: c7299fea6769 ("spi: Fix spi device unregister flow") Signed-off-by: Lukas Wunner Cc: Saravana Kannan Acked-by: Andy Shevchenko # pxa2xx Link: https://lore.kernel.org/r/f76a0599469f265b69c371538794101fa37b5536.1622149321.git.lukas@wunner.de Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 0c4d4de2da4dc39168077da2b21dd590523f3975 Author: Saravana Kannan Date: Wed May 5 09:47:34 2021 -0700 spi: Don't have controller clean up spi device before driver unbind [ Upstream commit 27e7db56cf3dffd302bd7ddfacb1d405cf671a2a ] When a spi device is unregistered and triggers a driver unbind, the driver might need to access the spi device. So, don't have the controller clean up the spi device before the driver is unbound. Clean up the spi device after the driver is unbound. Fixes: c7299fea6769 ("spi: Fix spi device unregister flow") Reported-by: Lukas Wunner Signed-off-by: Saravana Kannan Tested-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210505164734.175546-1-saravanak@google.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 3a5b982463f4eda2cd6368a974b6608a9517d50c Author: Chris Packham Date: Wed May 12 09:20:51 2021 +1200 powerpc/fsl: set fsl,i2c-erratum-a004447 flag for P1010 i2c controllers [ Upstream commit 19ae697a1e4edf1d755b413e3aa38da65e2db23b ] The i2c controllers on the P1010 have an erratum where the documented scheme for i2c bus recovery will not work (A-004447). A different mechanism is needed which is documented in the P1010 Chip Errata Rev L. Signed-off-by: Chris Packham Acked-by: Michael Ellerman Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit a7c3c17867b396b40a2076bc9f6b9dd12670600c Author: Chris Packham Date: Wed May 12 09:20:50 2021 +1200 powerpc/fsl: set fsl,i2c-erratum-a004447 flag for P2041 i2c controllers [ Upstream commit 7adc7b225cddcfd0f346d10144fd7a3d3d9f9ea7 ] The i2c controllers on the P2040/P2041 have an erratum where the documented scheme for i2c bus recovery will not work (A-004447). A different mechanism is needed which is documented in the P2040 Chip Errata Rev Q (latest available at the time of writing). Signed-off-by: Chris Packham Acked-by: Michael Ellerman Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 590f718a6473055d9468323802298b5bbddf382c Author: Sagi Grimberg Date: Tue May 25 08:49:05 2021 -0700 nvmet: fix false keep-alive timeout when a controller is torn down [ Upstream commit aaeadd7075dc9e184bc7876e9dd7b3bada771df2 ] Controller teardown flow may take some time in case it has many I/O queues, and the host may not send us keep-alive during this period. Hence reset the traffic based keep-alive timer so we don't trigger a controller teardown as a result of a keep-alive expiration. Reported-by: Yi Zhang Signed-off-by: Sagi Grimberg Reviewed-by: Chaitanya Kulkarni Reviewed-by: Hannes Reinecke Tested-by: Yi Zhang Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 2538f06f946820752fd9b2dfe6c66fe55cbf99ab Author: Sagi Grimberg Date: Fri May 21 14:51:15 2021 -0700 nvme-tcp: remove incorrect Kconfig dep in BLK_DEV_NVME [ Upstream commit 042a3eaad6daeabcfaf163aa44da8ea3cf8b5496 ] We need to select NVME_CORE. Signed-off-by: Sagi Grimberg Reviewed-by: Max Gurtovoy Reviewed-by: Chaitanya Kulkarni Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit b0308804b2e0edb0f8e88f29c5bf6875018fe65c Author: Jiapeng Chong Date: Tue May 25 19:00:12 2021 +0800 bnx2x: Fix missing error code in bnx2x_iov_init_one() [ Upstream commit 65161c35554f7135e6656b3df1ce2c500ca0bdcf ] Eliminate the follow smatch warning: drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c:1227 bnx2x_iov_init_one() warn: missing error code 'err'. Reported-by: Abaci Robot Signed-off-by: Jiapeng Chong Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 90547d5db50bcb2705709e420e0af51535109113 Author: John Keeping Date: Wed May 12 12:14:21 2021 +0100 dm verity: fix require_signatures module_param permissions [ Upstream commit 0c1f3193b1cdd21e7182f97dc9bca7d284d18a15 ] The third parameter of module_param() is permissions for the sysfs node but it looks like it is being used as the initial value of the parameter here. In fact, false here equates to omitting the file from sysfs and does not affect the value of require_signatures. Making the parameter writable is not simple because going from false->true is fine but it should not be possible to remove the requirement to verify a signature. But it can be useful to inspect the value of this parameter from userspace, so change the permissions to make a read-only file in sysfs. Signed-off-by: John Keeping Signed-off-by: Mike Snitzer Signed-off-by: Sasha Levin commit 7519ece673e300b0362572edbde7e030552705ec Author: Tiezhu Yang Date: Sat May 15 19:02:01 2021 +0800 MIPS: Fix kernel hang under FUNCTION_GRAPH_TRACER and PREEMPT_TRACER [ Upstream commit 78cf0eb926cb1abeff2106bae67752e032fe5f3e ] When update the latest mainline kernel with the following three configs, the kernel hangs during startup: (1) CONFIG_FUNCTION_GRAPH_TRACER=y (2) CONFIG_PREEMPT_TRACER=y (3) CONFIG_FTRACE_STARTUP_TEST=y When update the latest mainline kernel with the above two configs (1) and (2), the kernel starts normally, but it still hangs when execute the following command: echo "function_graph" > /sys/kernel/debug/tracing/current_tracer Without CONFIG_PREEMPT_TRACER=y, the above two kinds of kernel hangs disappeared, so it seems that CONFIG_PREEMPT_TRACER has some influences with function_graph tracer at the first glance. I use ejtag to find out the epc address is related with preempt_enable() in the file arch/mips/lib/mips-atomic.c, because function tracing can trace the preempt_{enable,disable} calls that are traced, replace them with preempt_{enable,disable}_notrace to prevent function tracing from going into an infinite loop, and then it can fix the kernel hang issue. By the way, it seems that this commit is a complement and improvement of commit f93a1a00f2bd ("MIPS: Fix crash that occurs when function tracing is enabled"). Signed-off-by: Tiezhu Yang Cc: Steven Rostedt Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit 37a079a6ae1432affa8e10c229eabc1923e7ccd0 Author: Hannes Reinecke Date: Fri May 21 10:23:46 2021 +0200 nvme-fabrics: decode host pathing error for connect [ Upstream commit 4d9442bf263ac45d495bb7ecf75009e59c0622b2 ] Add an additional decoding for 'host pathing error' during connect. Signed-off-by: Hannes Reinecke Reviewed-by: Sagi Grimberg Reviewed-by: Chaitanya Kulkarni Reviewed-by: Himanshu Madhani Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit f42afc0f29024f81a34175e0b24d746a6d24225b Author: George McCollister Date: Mon May 24 15:29:53 2021 -0500 net: dsa: microchip: enable phy errata workaround on 9567 [ Upstream commit 8c42a49738f16af0061f9ae5c2f5a955f268d9e3 ] Also enable phy errata workaround on 9567 since has the same errata as the 9477 according to the manufacture's documentation. Signed-off-by: George McCollister Reviewed-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit ee144b79802849626f8fd83ab5929e7e8118ff6b Author: Saubhik Mukherjee Date: Mon May 24 19:07:12 2021 +0530 net: appletalk: cops: Fix data race in cops_probe1 [ Upstream commit a4dd4fc6105e54393d637450a11d4cddb5fabc4f ] In cops_probe1(), there is a write to dev->base_addr after requesting an interrupt line and registering the interrupt handler cops_interrupt(). The handler might be called in parallel to handle an interrupt. cops_interrupt() tries to read dev->base_addr leading to a potential data race. So write to dev->base_addr before calling request_irq(). Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Saubhik Mukherjee Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit a385cbf31ed0deceb2e09c3950b605f94c9a4f0a Author: Zong Li Date: Sat May 22 17:16:11 2021 +0800 net: macb: ensure the device is available before accessing GEMGXL control registers [ Upstream commit 5eff1461a6dec84f04fafa9128548bad51d96147 ] If runtime power menagement is enabled, the gigabit ethernet PLL would be disabled after macb_probe(). During this period of time, the system would hang up if we try to access GEMGXL control registers. We can't put runtime_pm_get/runtime_pm_put/ there due to the issue of sleep inside atomic section (7fa2955ff70ce453 ("sh_eth: Fix sleeping function called from invalid context"). Add netif_running checking to ensure the device is available before accessing GEMGXL device. Changed in v2: - Use netif_running instead of its own flag Signed-off-by: Zong Li Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit bbb48789b62aa3dfd6ca3d731105efe528d91455 Author: Dmitry Bogdanov Date: Thu Apr 15 23:35:54 2021 +0300 scsi: target: qla2xxx: Wait for stop_phase1 at WWN removal [ Upstream commit 2ef7665dfd88830f15415ba007c7c9a46be7acd8 ] Target de-configuration panics at high CPU load because TPGT and WWPN can be removed on separate threads. TPGT removal requests a reset HBA on a separate thread and waits for reset complete (phase1). Due to high CPU load that HBA reset can be delayed for some time. WWPN removal does qlt_stop_phase2(). There it is believed that phase1 has already completed and thus tgt.tgt_ops is subsequently cleared. However, tgt.tgt_ops is needed to process incoming traffic and therefore this will cause one of the following panics: NIP qlt_reset+0x7c/0x220 [qla2xxx] LR qlt_reset+0x68/0x220 [qla2xxx] Call Trace: 0xc000003ffff63a78 (unreliable) qlt_handle_imm_notify+0x800/0x10c0 [qla2xxx] qlt_24xx_atio_pkt+0x208/0x590 [qla2xxx] qlt_24xx_process_atio_queue+0x33c/0x7a0 [qla2xxx] qla83xx_msix_atio_q+0x54/0x90 [qla2xxx] or NIP qlt_24xx_handle_abts+0xd0/0x2a0 [qla2xxx] LR qlt_24xx_handle_abts+0xb4/0x2a0 [qla2xxx] Call Trace: qlt_24xx_handle_abts+0x90/0x2a0 [qla2xxx] (unreliable) qlt_24xx_process_atio_queue+0x500/0x7a0 [qla2xxx] qla83xx_msix_atio_q+0x54/0x90 [qla2xxx] or NIP qlt_create_sess+0x90/0x4e0 [qla2xxx] LR qla24xx_do_nack_work+0xa8/0x180 [qla2xxx] Call Trace: 0xc0000000348fba30 (unreliable) qla24xx_do_nack_work+0xa8/0x180 [qla2xxx] qla2x00_do_work+0x674/0xbf0 [qla2xxx] qla2x00_iocb_work_fn The patch fixes the issue by serializing qlt_stop_phase1() and qlt_stop_phase2() functions to make WWPN removal wait for phase1 completion. Link: https://lore.kernel.org/r/20210415203554.27890-1-d.bogdanov@yadro.com Reviewed-by: Roman Bolshakov Signed-off-by: Dmitry Bogdanov Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 16763635285cb921c419a5a2dd9ddca2adcd2509 Author: Yang Yingliang Date: Wed May 19 21:05:19 2021 +0800 scsi: hisi_sas: Drop free_irq() of devm_request_irq() allocated irq [ Upstream commit 7907a021e4bbfa29cccacd2ba2dade894d9a7d4c ] irqs allocated with devm_request_irq() should not be freed using free_irq(). Doing so causes a dangling pointer and a subsequent double free. Link: https://lore.kernel.org/r/20210519130519.2661938-1-yangyingliang@huawei.com Reported-by: Hulk Robot Acked-by: John Garry Signed-off-by: Yang Yingliang Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit eac1d159b7a33616666dc8e072ba34300e048834 Author: Matt Wang Date: Wed May 19 09:49:32 2021 +0000 scsi: vmw_pvscsi: Set correct residual data length [ Upstream commit e662502b3a782d479e67736a5a1c169a703d853a ] Some commands (such as INQUIRY) may return less data than the initiator requested. To avoid conducting useless information, set the right residual count to make upper layer aware of this. Before (INQUIRY PAGE 0xB0 with 128B buffer): $ sg_raw -r 128 /dev/sda 12 01 B0 00 80 00 SCSI Status: Good Received 128 bytes of data: 00 00 b0 00 3c 01 00 00 00 00 00 00 00 00 00 00 00 ...<............ 10 00 00 00 00 00 01 00 00 00 00 00 40 00 00 08 00 ...........@.... 20 80 00 00 00 00 00 00 00 00 00 20 00 00 00 00 00 .......... ..... 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ After: $ sg_raw -r 128 /dev/sda 12 01 B0 00 80 00 SCSI Status: Good Received 64 bytes of data: 00 00 b0 00 3c 01 00 00 00 00 00 00 00 00 00 00 00 ...<............ 10 00 00 00 00 00 01 00 00 00 00 00 40 00 00 08 00 ...........@.... 20 80 00 00 00 00 00 00 00 00 00 20 00 00 00 00 00 .......... ..... 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [mkp: clarified description] Link: https://lore.kernel.org/r/03C41093-B62E-43A2-913E-CFC92F1C70C3@vmware.com Signed-off-by: Matt Wang Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 30030c6ff3d447900255647b9b5fc1143313e7eb Author: Javed Hasan Date: Tue May 18 23:14:16 2021 -0700 scsi: bnx2fc: Return failure if io_req is already in ABTS processing [ Upstream commit 122c81c563b0c1c6b15ff76a9159af5ee1f21563 ] Return failure from bnx2fc_eh_abort() if io_req is already in ABTS processing. Link: https://lore.kernel.org/r/20210519061416.19321-1-jhasan@marvell.com Reviewed-by: Himanshu Madhani Signed-off-by: Javed Hasan Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 8d717c9135a3340ae62d1699484850bfb4112b0c Author: Íñigo Huguet Date: Fri May 21 16:38:35 2021 +0200 net:sfc: fix non-freed irq in legacy irq mode [ Upstream commit 8f03eeb6e0a0a0b8d617ee0a4bce729e47130036 ] SFC driver can be configured via modparam to work using MSI-X, MSI or legacy IRQ interrupts. In the last one, the interrupt was not properly released on module remove. It was not freed because the flag irqs_hooked was not set during initialization in the case of using legacy IRQ. Example of (trimmed) trace during module remove without this fix: remove_proc_entry: removing non-empty directory 'irq/125', leaking at least '0000:3b:00.1' WARNING: CPU: 39 PID: 3658 at fs/proc/generic.c:715 remove_proc_entry+0x15c/0x170 ...trimmed... Call Trace: unregister_irq_proc+0xe3/0x100 free_desc+0x29/0x70 irq_free_descs+0x47/0x70 mp_unmap_irq+0x58/0x60 acpi_unregister_gsi_ioapic+0x2a/0x40 acpi_pci_irq_disable+0x78/0xb0 pci_disable_device+0xd1/0x100 efx_pci_remove+0xa1/0x1e0 [sfc] pci_device_remove+0x38/0xa0 __device_release_driver+0x177/0x230 driver_detach+0xcb/0x110 bus_remove_driver+0x58/0xd0 pci_unregister_driver+0x2a/0xb0 efx_exit_module+0x24/0xf40 [sfc] __do_sys_delete_module.constprop.0+0x171/0x280 ? exit_to_user_mode_prepare+0x83/0x1d0 do_syscall_64+0x3d/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f9f9385800b ...trimmed... Signed-off-by: Íñigo Huguet Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit e806df71eed223ab8ca099c61a41f3e9a576733f Author: Rao Shoaib Date: Fri May 21 11:08:06 2021 -0700 RDS tcp loopback connection can hang [ Upstream commit aced3ce57cd37b5ca332bcacd370d01f5a8c5371 ] When TCP is used as transport and a program on the system connects to RDS port 16385, connection is accepted but denied per the rules of RDS. However, RDS connections object is left in the list. Next loopback connection will select that connection object as it is at the head of list. The connection attempt will hang as the connection object is set to connect over TCP which is not allowed The issue can be reproduced easily, use rds-ping to ping a local IP address. After that use any program like ncat to connect to the same IP address and port 16385. This will hang so ctrl-c out. Now try rds-ping, it will hang. To fix the issue this patch adds checks to disallow the connection object creation and destroys the connection object. Signed-off-by: Rao Shoaib Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4353eb42180dbc48fe7a8b69c6d2490d310537bf Author: Zheyu Ma Date: Thu May 20 12:32:36 2021 +0000 net/qla3xxx: fix schedule while atomic in ql_sem_spinlock [ Upstream commit 13a6f3153922391e90036ba2267d34eed63196fc ] When calling the 'ql_sem_spinlock', the driver has already acquired the spin lock, so the driver should not call 'ssleep' in atomic context. This bug can be fixed by using 'mdelay' instead of 'ssleep'. The KASAN's log reveals it: [ 3.238124 ] BUG: scheduling while atomic: swapper/0/1/0x00000002 [ 3.238748 ] 2 locks held by swapper/0/1: [ 3.239151 ] #0: ffff88810177b240 (&dev->mutex){....}-{3:3}, at: __device_driver_lock+0x41/0x60 [ 3.240026 ] #1: ffff888107c60e28 (&qdev->hw_lock){....}-{2:2}, at: ql3xxx_probe+0x2aa/0xea0 [ 3.240873 ] Modules linked in: [ 3.241187 ] irq event stamp: 460854 [ 3.241541 ] hardirqs last enabled at (460853): [] _raw_spin_unlock_irqrestore+0x4f/0x70 [ 3.242245 ] hardirqs last disabled at (460854): [] _raw_spin_lock_irqsave+0x2a/0x70 [ 3.242245 ] softirqs last enabled at (446076): [] __do_softirq+0x2e4/0x4b1 [ 3.242245 ] softirqs last disabled at (446069): [] irq_exit_rcu+0x100/0x110 [ 3.242245 ] Preemption disabled at: [ 3.242245 ] [] ql3xxx_probe+0x2aa/0xea0 [ 3.242245 ] Kernel panic - not syncing: scheduling while atomic [ 3.242245 ] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 5.13.0-rc1-00145 -gee7dc339169-dirty #16 [ 3.242245 ] Call Trace: [ 3.242245 ] dump_stack+0xba/0xf5 [ 3.242245 ] ? ql3xxx_probe+0x1f0/0xea0 [ 3.242245 ] panic+0x15a/0x3f2 [ 3.242245 ] ? vprintk+0x76/0x150 [ 3.242245 ] ? ql3xxx_probe+0x2aa/0xea0 [ 3.242245 ] __schedule_bug+0xae/0xe0 [ 3.242245 ] __schedule+0x72e/0xa00 [ 3.242245 ] schedule+0x43/0xf0 [ 3.242245 ] schedule_timeout+0x28b/0x500 [ 3.242245 ] ? del_timer_sync+0xf0/0xf0 [ 3.242245 ] ? msleep+0x2f/0x70 [ 3.242245 ] msleep+0x59/0x70 [ 3.242245 ] ql3xxx_probe+0x307/0xea0 [ 3.242245 ] ? _raw_spin_unlock_irqrestore+0x3a/0x70 [ 3.242245 ] ? pci_device_remove+0x110/0x110 [ 3.242245 ] local_pci_probe+0x45/0xa0 [ 3.242245 ] pci_device_probe+0x12b/0x1d0 [ 3.242245 ] really_probe+0x2a9/0x610 [ 3.242245 ] driver_probe_device+0x90/0x1d0 [ 3.242245 ] ? mutex_lock_nested+0x1b/0x20 [ 3.242245 ] device_driver_attach+0x68/0x70 [ 3.242245 ] __driver_attach+0x124/0x1b0 [ 3.242245 ] ? device_driver_attach+0x70/0x70 [ 3.242245 ] bus_for_each_dev+0xbb/0x110 [ 3.242245 ] ? rdinit_setup+0x45/0x45 [ 3.242245 ] driver_attach+0x27/0x30 [ 3.242245 ] bus_add_driver+0x1eb/0x2a0 [ 3.242245 ] driver_register+0xa9/0x180 [ 3.242245 ] __pci_register_driver+0x82/0x90 [ 3.242245 ] ? yellowfin_init+0x25/0x25 [ 3.242245 ] ql3xxx_driver_init+0x23/0x25 [ 3.242245 ] do_one_initcall+0x7f/0x3d0 [ 3.242245 ] ? rdinit_setup+0x45/0x45 [ 3.242245 ] ? rcu_read_lock_sched_held+0x4f/0x80 [ 3.242245 ] kernel_init_freeable+0x2aa/0x301 [ 3.242245 ] ? rest_init+0x2c0/0x2c0 [ 3.242245 ] kernel_init+0x18/0x190 [ 3.242245 ] ? rest_init+0x2c0/0x2c0 [ 3.242245 ] ? rest_init+0x2c0/0x2c0 [ 3.242245 ] ret_from_fork+0x1f/0x30 [ 3.242245 ] Dumping ftrace buffer: [ 3.242245 ] (ftrace buffer empty) [ 3.242245 ] Kernel Offset: disabled [ 3.242245 ] Rebooting in 1 seconds. Reported-by: Zheyu Ma Signed-off-by: Zheyu Ma Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit ad241cb1cffbe7f9d121ba728a381416e8540954 Author: Sergey Senozhatsky Date: Thu May 20 19:14:22 2021 +0900 wq: handle VM suspension in stall detection [ Upstream commit 940d71c6462e8151c78f28e4919aa8882ff2054e ] If VCPU is suspended (VM suspend) in wq_watchdog_timer_fn() then once this VCPU resumes it will see the new jiffies value, while it may take a while before IRQ detects PVCLOCK_GUEST_STOPPED on this VCPU and updates all the watchdogs via pvclock_touch_watchdogs(). There is a small chance of misreported WQ stalls in the meantime, because new jiffies is time_after() old 'ts + thresh'. wq_watchdog_timer_fn() { for_each_pool(pool, pi) { if (time_after(jiffies, ts + thresh)) { pr_emerg("BUG: workqueue lockup - pool"); } } } Save jiffies at the beginning of this function and use that value for stall detection. If VM gets suspended then we continue using "old" jiffies value and old WQ touch timestamps. If IRQ at some point restarts the stall detection cycle (pvclock_touch_watchdogs()) then old jiffies will always be before new 'ts + thresh'. Signed-off-by: Sergey Senozhatsky Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 5ca472d40e2daebbfd926701902debcab0bbd15c Author: Shakeel Butt Date: Wed May 12 13:19:46 2021 -0700 cgroup: disable controllers at parse time [ Upstream commit 45e1ba40837ac2f6f4d4716bddb8d44bd7e4a251 ] This patch effectively reverts the commit a3e72739b7a7 ("cgroup: fix too early usage of static_branch_disable()"). The commit 6041186a3258 ("init: initialize jump labels before command line option parsing") has moved the jump_label_init() before parse_args() which has made the commit a3e72739b7a7 unnecessary. On the other hand there are consequences of disabling the controllers later as there are subsystems doing the controller checks for different decisions. One such incident is reported [1] regarding the memory controller and its impact on memory reclaim code. [1] https://lore.kernel.org/linux-mm/921e53f3-4b13-aab8-4a9e-e83ff15371e4@nec.com Signed-off-by: Shakeel Butt Reported-by: NOMURA JUNICHI(野村　淳一) Signed-off-by: Tejun Heo Tested-by: Jun'ichi Nomura Signed-off-by: Sasha Levin commit be23c4af3d8a1b986fe9b43b8966797653a76ca4 Author: Dan Carpenter Date: Mon May 17 12:04:13 2021 +0300 net: mdiobus: get rid of a BUG_ON() [ Upstream commit 1dde47a66d4fb181830d6fa000e5ea86907b639e ] We spotted a bug recently during a review where a driver was unregistering a bus that wasn't registered, which would trigger this BUG_ON(). Let's handle that situation more gracefully, and just print a warning and return. Reported-by: Russell King (Oracle) Signed-off-by: Dan Carpenter Reviewed-by: Russell King (Oracle) Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 1d6d43d4805da9b3fa0f5841e8b1083c89868f35 Author: Johannes Berg Date: Mon May 17 16:38:09 2021 +0200 netlink: disable IRQs for netlink_lock_table() [ Upstream commit 1d482e666b8e74c7555dbdfbfb77205eeed3ff2d ] Syzbot reports that in mac80211 we have a potential deadlock between our "local->stop_queue_reasons_lock" (spinlock) and netlink's nl_table_lock (rwlock). This is because there's at least one situation in which we might try to send a netlink message with this spinlock held while it is also possible to take the spinlock from a hardirq context, resulting in the following deadlock scenario reported by lockdep: CPU0 CPU1 ---- ---- lock(nl_table_lock); local_irq_disable(); lock(&local->queue_stop_reason_lock); lock(nl_table_lock); lock(&local->queue_stop_reason_lock); This seems valid, we can take the queue_stop_reason_lock in any kind of context ("CPU0"), and call ieee80211_report_ack_skb() with the spinlock held and IRQs disabled ("CPU1") in some code path (ieee80211_do_stop() via ieee80211_free_txskb()). Short of disallowing netlink use in scenarios like these (which would be rather complex in mac80211's case due to the deep callchain), it seems the only fix for this is to disable IRQs while nl_table_lock is held to avoid hitting this scenario, this disallows the "CPU0" portion of the reported deadlock. Note that the writer side (netlink_table_grab()) already disables IRQs for this lock. Unfortunately though, this seems like a huge hammer, and maybe the whole netlink table locking should be reworked. Reported-by: syzbot+69ff9dff50dcfe14ddd4@syzkaller.appspotmail.com Signed-off-by: Johannes Berg Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 42e49001380989f757f17045cf352dff9ae124b3 Author: Johannes Berg Date: Mon May 17 16:13:35 2021 +0200 bonding: init notify_work earlier to avoid uninitialized use [ Upstream commit 35d96e631860226d5dc4de0fad0a415362ec2457 ] If bond_kobj_init() or later kzalloc() in bond_alloc_slave() fail, then we call kobject_put() on the slave->kobj. This in turn calls the release function slave_kobj_release() which will always try to cancel_delayed_work_sync(&slave->notify_work), which shouldn't be done on an uninitialized work struct. Always initialize the work struct earlier to avoid problems here. Syzbot bisected this down to a completely pointless commit, some fault injection may have been at work here that caused the alloc failure in the first place, which may interact badly with bisect. Reported-by: syzbot+bfda097c12a00c8cae67@syzkaller.appspotmail.com Signed-off-by: Johannes Berg Acked-by: Jay Vosburgh Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 143fc7220961220eecc04669e5909af8847bf8c8 Author: Zheyu Ma Date: Sun May 16 07:11:40 2021 +0000 isdn: mISDN: netjet: Fix crash in nj_probe: [ Upstream commit 9f6f852550d0e1b7735651228116ae9d300f69b3 ] 'nj_setup' in netjet.c might fail with -EIO and in this case 'card->irq' is initialized and is bigger than zero. A subsequent call to 'nj_release' will free the irq that has not been requested. Fix this bug by deleting the previous assignment to 'card->irq' and just keep the assignment before 'request_irq'. The KASAN's log reveals it: [ 3.354615 ] WARNING: CPU: 0 PID: 1 at kernel/irq/manage.c:1826 free_irq+0x100/0x480 [ 3.355112 ] Modules linked in: [ 3.355310 ] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.13.0-rc1-00144-g25a1298726e #13 [ 3.355816 ] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 [ 3.356552 ] RIP: 0010:free_irq+0x100/0x480 [ 3.356820 ] Code: 6e 08 74 6f 4d 89 f4 e8 5e ac 09 00 4d 8b 74 24 18 4d 85 f6 75 e3 e8 4f ac 09 00 8b 75 c8 48 c7 c7 78 c1 2e 85 e8 e0 cf f5 ff <0f> 0b 48 8b 75 c0 4c 89 ff e8 72 33 0b 03 48 8b 43 40 4c 8b a0 80 [ 3.358012 ] RSP: 0000:ffffc90000017b48 EFLAGS: 00010082 [ 3.358357 ] RAX: 0000000000000000 RBX: ffff888104dc8000 RCX: 0000000000000000 [ 3.358814 ] RDX: ffff8881003c8000 RSI: ffffffff8124a9e6 RDI: 00000000ffffffff [ 3.359272 ] RBP: ffffc90000017b88 R08: 0000000000000000 R09: 0000000000000000 [ 3.359732 ] R10: ffffc900000179f0 R11: 0000000000001d04 R12: 0000000000000000 [ 3.360195 ] R13: ffff888107dc6000 R14: ffff888107dc6928 R15: ffff888104dc80a8 [ 3.360652 ] FS: 0000000000000000(0000) GS:ffff88817bc00000(0000) knlGS:0000000000000000 [ 3.361170 ] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 3.361538 ] CR2: 0000000000000000 CR3: 000000000582e000 CR4: 00000000000006f0 [ 3.362003 ] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 3.362175 ] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 3.362175 ] Call Trace: [ 3.362175 ] nj_release+0x51/0x1e0 [ 3.362175 ] nj_probe+0x450/0x950 [ 3.362175 ] ? pci_device_remove+0x110/0x110 [ 3.362175 ] local_pci_probe+0x45/0xa0 [ 3.362175 ] pci_device_probe+0x12b/0x1d0 [ 3.362175 ] really_probe+0x2a9/0x610 [ 3.362175 ] driver_probe_device+0x90/0x1d0 [ 3.362175 ] ? mutex_lock_nested+0x1b/0x20 [ 3.362175 ] device_driver_attach+0x68/0x70 [ 3.362175 ] __driver_attach+0x124/0x1b0 [ 3.362175 ] ? device_driver_attach+0x70/0x70 [ 3.362175 ] bus_for_each_dev+0xbb/0x110 [ 3.362175 ] ? rdinit_setup+0x45/0x45 [ 3.362175 ] driver_attach+0x27/0x30 [ 3.362175 ] bus_add_driver+0x1eb/0x2a0 [ 3.362175 ] driver_register+0xa9/0x180 [ 3.362175 ] __pci_register_driver+0x82/0x90 [ 3.362175 ] ? w6692_init+0x38/0x38 [ 3.362175 ] nj_init+0x36/0x38 [ 3.362175 ] do_one_initcall+0x7f/0x3d0 [ 3.362175 ] ? rdinit_setup+0x45/0x45 [ 3.362175 ] ? rcu_read_lock_sched_held+0x4f/0x80 [ 3.362175 ] kernel_init_freeable+0x2aa/0x301 [ 3.362175 ] ? rest_init+0x2c0/0x2c0 [ 3.362175 ] kernel_init+0x18/0x190 [ 3.362175 ] ? rest_init+0x2c0/0x2c0 [ 3.362175 ] ? rest_init+0x2c0/0x2c0 [ 3.362175 ] ret_from_fork+0x1f/0x30 [ 3.362175 ] Kernel panic - not syncing: panic_on_warn set ... [ 3.362175 ] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.13.0-rc1-00144-g25a1298726e #13 [ 3.362175 ] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 [ 3.362175 ] Call Trace: [ 3.362175 ] dump_stack+0xba/0xf5 [ 3.362175 ] ? free_irq+0x100/0x480 [ 3.362175 ] panic+0x15a/0x3f2 [ 3.362175 ] ? __warn+0xf2/0x150 [ 3.362175 ] ? free_irq+0x100/0x480 [ 3.362175 ] __warn+0x108/0x150 [ 3.362175 ] ? free_irq+0x100/0x480 [ 3.362175 ] report_bug+0x119/0x1c0 [ 3.362175 ] handle_bug+0x3b/0x80 [ 3.362175 ] exc_invalid_op+0x18/0x70 [ 3.362175 ] asm_exc_invalid_op+0x12/0x20 [ 3.362175 ] RIP: 0010:free_irq+0x100/0x480 [ 3.362175 ] Code: 6e 08 74 6f 4d 89 f4 e8 5e ac 09 00 4d 8b 74 24 18 4d 85 f6 75 e3 e8 4f ac 09 00 8b 75 c8 48 c7 c7 78 c1 2e 85 e8 e0 cf f5 ff <0f> 0b 48 8b 75 c0 4c 89 ff e8 72 33 0b 03 48 8b 43 40 4c 8b a0 80 [ 3.362175 ] RSP: 0000:ffffc90000017b48 EFLAGS: 00010082 [ 3.362175 ] RAX: 0000000000000000 RBX: ffff888104dc8000 RCX: 0000000000000000 [ 3.362175 ] RDX: ffff8881003c8000 RSI: ffffffff8124a9e6 RDI: 00000000ffffffff [ 3.362175 ] RBP: ffffc90000017b88 R08: 0000000000000000 R09: 0000000000000000 [ 3.362175 ] R10: ffffc900000179f0 R11: 0000000000001d04 R12: 0000000000000000 [ 3.362175 ] R13: ffff888107dc6000 R14: ffff888107dc6928 R15: ffff888104dc80a8 [ 3.362175 ] ? vprintk+0x76/0x150 [ 3.362175 ] ? free_irq+0x100/0x480 [ 3.362175 ] nj_release+0x51/0x1e0 [ 3.362175 ] nj_probe+0x450/0x950 [ 3.362175 ] ? pci_device_remove+0x110/0x110 [ 3.362175 ] local_pci_probe+0x45/0xa0 [ 3.362175 ] pci_device_probe+0x12b/0x1d0 [ 3.362175 ] really_probe+0x2a9/0x610 [ 3.362175 ] driver_probe_device+0x90/0x1d0 [ 3.362175 ] ? mutex_lock_nested+0x1b/0x20 [ 3.362175 ] device_driver_attach+0x68/0x70 [ 3.362175 ] __driver_attach+0x124/0x1b0 [ 3.362175 ] ? device_driver_attach+0x70/0x70 [ 3.362175 ] bus_for_each_dev+0xbb/0x110 [ 3.362175 ] ? rdinit_setup+0x45/0x45 [ 3.362175 ] driver_attach+0x27/0x30 [ 3.362175 ] bus_add_driver+0x1eb/0x2a0 [ 3.362175 ] driver_register+0xa9/0x180 [ 3.362175 ] __pci_register_driver+0x82/0x90 [ 3.362175 ] ? w6692_init+0x38/0x38 [ 3.362175 ] nj_init+0x36/0x38 [ 3.362175 ] do_one_initcall+0x7f/0x3d0 [ 3.362175 ] ? rdinit_setup+0x45/0x45 [ 3.362175 ] ? rcu_read_lock_sched_held+0x4f/0x80 [ 3.362175 ] kernel_init_freeable+0x2aa/0x301 [ 3.362175 ] ? rest_init+0x2c0/0x2c0 [ 3.362175 ] kernel_init+0x18/0x190 [ 3.362175 ] ? rest_init+0x2c0/0x2c0 [ 3.362175 ] ? rest_init+0x2c0/0x2c0 [ 3.362175 ] ret_from_fork+0x1f/0x30 [ 3.362175 ] Dumping ftrace buffer: [ 3.362175 ] (ftrace buffer empty) [ 3.362175 ] Kernel Offset: disabled [ 3.362175 ] Rebooting in 1 seconds.. Reported-by: Zheyu Ma Signed-off-by: Zheyu Ma Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 2e2145ccfbcb0dd38d8423681d22b595ca735846 Author: Li Jun Date: Fri May 14 18:59:44 2021 +0800 usb: chipidea: udc: assign interrupt number to USB gadget structure [ Upstream commit 9e3927f6373da54cb17e17f4bd700907e1123d2f ] Chipidea also need sync interrupt before unbind the udc while gadget remove driver, otherwise setup irq handling may happen while unbind, see below dump generated from android function switch stress test: [ 4703.503056] android_work: sent uevent USB_STATE=CONNECTED [ 4703.514642] android_work: sent uevent USB_STATE=DISCONNECTED [ 4703.651339] android_work: sent uevent USB_STATE=CONNECTED [ 4703.661806] init: Control message: Processed ctl.stop for 'adbd' from pid: 561 (system_server) [ 4703.673469] init: processing action (init.svc.adbd=stopped) from (/system/etc/init/hw/init.usb.configfs.rc:14) [ 4703.676451] Unable to handle kernel read from unreadable memory at virtual address 0000000000000090 [ 4703.676454] Mem abort info: [ 4703.676458] ESR = 0x96000004 [ 4703.676461] EC = 0x25: DABT (current EL), IL = 32 bits [ 4703.676464] SET = 0, FnV = 0 [ 4703.676466] EA = 0, S1PTW = 0 [ 4703.676468] Data abort info: [ 4703.676471] ISV = 0, ISS = 0x00000004 [ 4703.676473] CM = 0, WnR = 0 [ 4703.676478] user pgtable: 4k pages, 48-bit VAs, pgdp=000000004a867000 [ 4703.676481] [0000000000000090] pgd=0000000000000000, p4d=0000000000000000 [ 4703.676503] Internal error: Oops: 96000004 [#1] PREEMPT SMP [ 4703.758297] Modules linked in: synaptics_dsx_i2c moal(O) mlan(O) [ 4703.764327] CPU: 0 PID: 235 Comm: lmkd Tainted: G W O 5.10.9-00001-g3f5fd8487c38-dirty #63 [ 4703.773720] Hardware name: NXP i.MX8MNano EVK board (DT) [ 4703.779033] pstate: 60400085 (nZCv daIf +PAN -UAO -TCO BTYPE=--) [ 4703.785046] pc : _raw_write_unlock_bh+0xc0/0x2c8 [ 4703.789667] lr : android_setup+0x4c/0x168 [ 4703.793676] sp : ffff80001256bd80 [ 4703.796989] x29: ffff80001256bd80 x28: 00000000000000a8 [ 4703.802304] x27: ffff800012470000 x26: ffff80006d923000 [ 4703.807616] x25: ffff800012471000 x24: ffff00000b091140 [ 4703.812929] x23: ffff0000077dbd38 x22: ffff0000077da490 [ 4703.818242] x21: ffff80001256be30 x20: 0000000000000000 [ 4703.823554] x19: 0000000000000080 x18: ffff800012561048 [ 4703.828867] x17: 0000000000000000 x16: 0000000000000039 [ 4703.834180] x15: ffff8000106ad258 x14: ffff80001194c277 [ 4703.839493] x13: 0000000000003934 x12: 0000000000000000 [ 4703.844805] x11: 0000000000000000 x10: 0000000000000001 [ 4703.850117] x9 : 0000000000000000 x8 : 0000000000000090 [ 4703.855429] x7 : 6f72646e61203a70 x6 : ffff8000124f2450 [ 4703.860742] x5 : ffffffffffffffff x4 : 0000000000000009 [ 4703.866054] x3 : ffff8000108a290c x2 : ffff00007fb3a9c8 [ 4703.871367] x1 : 0000000000000000 x0 : 0000000000000090 [ 4703.876681] Call trace: [ 4703.879129] _raw_write_unlock_bh+0xc0/0x2c8 [ 4703.883397] android_setup+0x4c/0x168 [ 4703.887059] udc_irq+0x824/0xa9c [ 4703.890287] ci_irq+0x124/0x148 [ 4703.893429] __handle_irq_event_percpu+0x84/0x268 [ 4703.898131] handle_irq_event+0x64/0x14c [ 4703.902054] handle_fasteoi_irq+0x110/0x210 [ 4703.906236] __handle_domain_irq+0x8c/0xd4 [ 4703.910332] gic_handle_irq+0x6c/0x124 [ 4703.914081] el1_irq+0xdc/0x1c0 [ 4703.917221] _raw_spin_unlock_irq+0x20/0x54 [ 4703.921405] finish_task_switch+0x84/0x224 [ 4703.925502] __schedule+0x4a4/0x734 [ 4703.928990] schedule+0xa0/0xe8 [ 4703.932132] do_notify_resume+0x150/0x184 [ 4703.936140] work_pending+0xc/0x40c [ 4703.939633] Code: d5384613 521b0a69 d5184609 f9800111 (885ffd01) [ 4703.945732] ---[ end trace ba5c1875ae49d53c ]--- [ 4703.950350] Kernel panic - not syncing: Oops: Fatal exception in interrupt [ 4703.957223] SMP: stopping secondary CPUs [ 4703.961151] Kernel Offset: disabled [ 4703.964638] CPU features: 0x0240002,2000200c [ 4703.968905] Memory Limit: none [ 4703.971963] Rebooting in 5 seconds.. Tested-by: faqiang.zhu Signed-off-by: Li Jun Link: https://lore.kernel.org/r/1620989984-7653-1-git-send-email-jun.li@nxp.com Signed-off-by: Peter Chen Signed-off-by: Sasha Levin commit 06e84ea1f4573c13a37e22d522a5d4f8f8a9e378 Author: Chunyan Zhang Date: Wed May 12 17:35:34 2021 +0800 spi: sprd: Add missing MODULE_DEVICE_TABLE [ Upstream commit 7907cad7d07e0055789ec0c534452f19dfe1fc80 ] MODULE_DEVICE_TABLE is used to extract the device information out of the driver and builds a table when being compiled. If using this macro, kernel can find the driver if available when the device is plugged in, and then loads that driver and initializes the device. Signed-off-by: Chunyan Zhang Link: https://lore.kernel.org/r/20210512093534.243040-1-zhang.lyra@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 369f3caa4d74380efdbf614a01de067171fa19a1 Author: Zou Wei Date: Wed May 12 11:12:25 2021 +0800 ASoC: sti-sas: add missing MODULE_DEVICE_TABLE [ Upstream commit e072b2671606c77538d6a4dd5dda80b508cb4816 ] This patch adds missing MODULE_DEVICE_TABLE definition which generates correct modalias for automatic loading of this driver when it is built as an external module. Reported-by: Hulk Robot Signed-off-by: Zou Wei Link: https://lore.kernel.org/r/1620789145-14936-1-git-send-email-zou_wei@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 01905f3232fdc0737de5c38e9d817f87a06a1a6d Author: Eric Farman Date: Tue May 11 21:56:31 2021 +0200 vfio-ccw: Serialize FSM IDLE state with I/O completion [ Upstream commit 2af7a834a435460d546f0cf0a8b8e4d259f1d910 ] Today, the stacked call to vfio_ccw_sch_io_todo() does three things: 1) Update a solicited IRB with CP information, and release the CP if the interrupt was the end of a START operation. 2) Copy the IRB data into the io_region, under the protection of the io_mutex 3) Reset the vfio-ccw FSM state to IDLE to acknowledge that vfio-ccw can accept more work. The trouble is that step 3 is (A) invoked for both solicited and unsolicited interrupts, and (B) sitting after the mutex for step 2. This second piece becomes a problem if it processes an interrupt for a CLEAR SUBCHANNEL while another thread initiates a START, thus allowing the CP and FSM states to get out of sync. That is: CPU 1 CPU 2 fsm_do_clear() fsm_irq() fsm_io_request() vfio_ccw_sch_io_todo() fsm_io_helper() Since the FSM state and CP should be kept in sync, let's make a note when the CP is released, and rely on that as an indication that the FSM should also be reset at the end of this routine and open up the device for more work. Signed-off-by: Eric Farman Acked-by: Matthew Rosato Reviewed-by: Cornelia Huck Message-Id: <20210511195631.3995081-4-farman@linux.ibm.com> Signed-off-by: Cornelia Huck Signed-off-by: Sasha Levin commit cad3dc73c0645d00adfe96cebc8d950897cc1227 Author: Eric Farman Date: Tue May 11 21:56:30 2021 +0200 vfio-ccw: Reset FSM state to IDLE inside FSM [ Upstream commit 6c02ac4c9211edabe17bda437ac97e578756f31b ] When an I/O request is made, the fsm_io_request() routine moves the FSM state from IDLE to CP_PROCESSING, and then fsm_io_helper() moves it to CP_PENDING if the START SUBCHANNEL received a cc0. Yet, the error case to go from CP_PROCESSING back to IDLE is done after the FSM call returns. Let's move this up into the FSM proper, to provide some better symmetry when unwinding in this case. Signed-off-by: Eric Farman Reviewed-by: Cornelia Huck Acked-by: Matthew Rosato Message-Id: <20210511195631.3995081-3-farman@linux.ibm.com> Signed-off-by: Cornelia Huck Signed-off-by: Sasha Levin commit 4352209ed0f0d5e1ff48ace27931e9fc43d10c40 Author: Hans de Goede Date: Sat May 8 17:01:46 2021 +0200 ASoC: Intel: bytcr_rt5640: Add quirk for the Lenovo Miix 3-830 tablet [ Upstream commit f0353e1f53f92f7b3da91e6669f5d58ee222ebe8 ] The Lenovo Miix 3-830 tablet has only 1 speaker, has an internal analog mic on IN1 and uses JD2 for jack-detect, add a quirk to automatically apply these settings on Lenovo Miix 3-830 tablets. Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20210508150146.28403-2-hdegoede@redhat.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a5ee8f54d0ab1fd5f953d4a5a161682745461901 Author: Hans de Goede Date: Sat May 8 17:01:45 2021 +0200 ASoC: Intel: bytcr_rt5640: Add quirk for the Glavey TM800A550L tablet [ Upstream commit 28c268d3acdd4cbcd2ac320b85609e77f84e74a7 ] Add a quirk for the Glavey TM800A550L tablet, this BYTCR tablet has no CHAN package in its ACPI tables and uses SSP0-AIF1 rather then SSP0-AIF2 which is the default for BYTCR devices. Signed-off-by: Hans de Goede Acked-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20210508150146.28403-1-hdegoede@redhat.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 2f523cd4a9311cba629facc7d353eabbd492bd5b Author: Dinghao Liu Date: Mon Apr 12 13:49:07 2021 +0800 usb: cdns3: Fix runtime PM imbalance on error [ Upstream commit 07adc0225484fc199e3dc15ec889f75f498c4fca ] When cdns3_gadget_start() fails, a pairing PM usage counter decrement is needed to keep the counter balanced. Signed-off-by: Dinghao Liu Link: https://lore.kernel.org/r/20210412054908.7975-1-dinghao.liu@zju.edu.cn Signed-off-by: Peter Chen Signed-off-by: Sasha Levin commit 1e5cab50208c8fb7351b798cb1d569debfeb994a Author: Jeimon Date: Sat May 8 11:52:30 2021 +0800 net/nfc/rawsock.c: fix a permission check bug [ Upstream commit 8ab78863e9eff11910e1ac8bcf478060c29b379e ] The function rawsock_create() calls a privileged function sk_alloc(), which requires a ns-aware check to check net->user_ns, i.e., ns_capable(). However, the original code checks the init_user_ns using capable(). So we replace the capable() with ns_capable(). Signed-off-by: Jeimon Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 584b2c7ce24450a7c687f976b54333607e14e058 Author: Jiri Olsa Date: Wed May 5 15:25:29 2021 +0200 bpf: Forbid trampoline attach for functions with variable arguments [ Upstream commit 31379397dcc364a59ce764fabb131b645c43e340 ] We can't currently allow to attach functions with variable arguments. The problem is that we should save all the registers for arguments, which is probably doable, but if caller uses more than 6 arguments, we need stack data, which will be wrong, because of the extra stack frame we do in bpf trampoline, so we could crash. Also currently there's malformed trampoline code generated for such functions at the moment as described in: https://lore.kernel.org/bpf/20210429212834.82621-1-jolsa@kernel.org/ Signed-off-by: Jiri Olsa Signed-off-by: Daniel Borkmann Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20210505132529.401047-1-jolsa@kernel.org Signed-off-by: Sasha Levin commit fb91ab403e6ee65ef8e193198dc5f52f723e2b93 Author: Karen Dombroski Date: Wed Apr 28 23:38:02 2021 -0600 spi: spi-zynq-qspi: Fix stack violation bug [ Upstream commit 6d5ff8e632a4f2389c331e5554cd1c2a9a28c7aa ] When the number of bytes for the op is greater than one, the read could run off the end of the function stack and cause a crash. This patch restores the behaviour of safely reading out of the original opcode location. Signed-off-by: Karen Dombroski Signed-off-by: Amit Kumar Mahapatra Link: https://lore.kernel.org/r/20210429053802.17650-3-amit.kumar-mahapatra@xilinx.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 4b8b7bc3a726268e5c15d9bafe27863a85fdfc8e Author: Saravana Kannan Date: Mon Apr 26 16:56:38 2021 -0700 spi: Fix spi device unregister flow [ Upstream commit c7299fea67696db5bd09d924d1f1080d894f92ef ] When an SPI device is unregistered, the spi->controller->cleanup() is called in the device's release callback. That's wrong for a couple of reasons: 1. spi_dev_put() can be called before spi_add_device() is called. And it's spi_add_device() that calls spi_setup(). This will cause clean() to get called without the spi device ever being setup. 2. There's no guarantee that the controller's driver would be present by the time the spi device's release function gets called. 3. It also causes "sleeping in atomic context" stack dump[1] when device link deletion code does a put_device() on the spi device. Fix these issues by simply moving the cleanup from the device release callback to the actual spi_unregister_device() function. [1] - https://lore.kernel.org/lkml/CAHp75Vc=FCGcUyS0v6fnxme2YJ+qD+Y-hQDQLa2JhWNON9VmsQ@mail.gmail.com/ Signed-off-by: Saravana Kannan Link: https://lore.kernel.org/r/20210426235638.1285530-1-saravanak@google.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit cb24d57ad5720714e4f0dd9dcb0c4b325ab54adf Author: Vijendar Mukunda Date: Wed Apr 28 01:53:31 2021 +0530 ASoC: amd: fix for pcm_read() error [ Upstream commit 6879e8e759bf9e05eaee85e32ca1a936e6b46da1 ] Below phython script throwing pcm_read() error. import subprocess p = subprocess.Popen(["aplay -t raw -D plughw:1,0 /dev/zero"], shell=True) subprocess.call(["arecord -Dhw:1,0 --dump-hw-params"], shell=True) subprocess.call(["arecord -Dhw:1,0 -fdat -d1 /dev/null"], shell=True) p.kill() Handling ACP global external interrupt enable register causing this issue. This register got updated wrongly when there is active stream causing interrupts disabled for active stream. Refactored code to handle enabling and disabling external interrupts. Signed-off-by: Vijendar Mukunda Link: https://lore.kernel.org/r/1619555017-29858-1-git-send-email-Vijendar.Mukunda@amd.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 3b89db7468f70dc8dd548acd8568b7afbfeefe6d Author: Marco Felsch Date: Fri Apr 23 15:54:02 2021 +0200 ASoC: max98088: fix ni clock divider calculation [ Upstream commit 6c9762a78c325107dc37d20ee21002b841679209 ] The ni1/ni2 ratio formula [1] uses the pclk which is the prescaled mclk. The max98088 datasheet [2] has no such formula but table-12 equals so we can assume that it is the same for both devices. While on it make use of DIV_ROUND_CLOSEST_ULL(). [1] https://datasheets.maximintegrated.com/en/ds/MAX98089.pdf; page 86 [2] https://datasheets.maximintegrated.com/en/ds/MAX98088.pdf; page 82 Signed-off-by: Marco Felsch Link: https://lore.kernel.org/r/20210423135402.32105-1-m.felsch@pengutronix.de Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f70102cb369cde6ab7551ca58152d00fd3478fec Author: Kees Cook Date: Tue Jun 8 10:12:21 2021 -0700 proc: Track /proc/$pid/attr/ opener mm_struct commit 591a22c14d3f45cc38bd1931c593c221df2f1881 upstream. Commit bfb819ea20ce ("proc: Check /proc/$pid/attr/ writes against file opener") tried to make sure that there could not be a confusion between the opener of a /proc/$pid/attr/ file and the writer. It used struct cred to make sure the privileges didn't change. However, there were existing cases where a more privileged thread was passing the opened fd to a differently privileged thread (during container setup). Instead, use mm_struct to track whether the opener and writer are still the same process. (This is what several other proc files already do, though for different reasons.) Reported-by: Christian Brauner Reported-by: Andrea Righi Tested-by: Andrea Righi Fixes: bfb819ea20ce ("proc: Check /proc/$pid/attr/ writes against file opener") Cc: stable@vger.kernel.org Signed-off-by: Kees Cook Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 951358a824f96be927ae50fad1e72e05bbb57b56 Author: Greg Kroah-Hartman Date: Thu Jun 10 13:39:29 2021 +0200 Linux 5.10.43 Link: https://lore.kernel.org/r/20210608175942.377073879@linuxfoundation.org Tested-by: Shuah Khan Tested-by: Jon Hunter Tested-by: Linux Kernel Functional Testing Tested-by: Jason Self Tested-by: Salvatore Bonaccorso Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Pavel Machek (CIP) Tested-by: Sudip Mukherjee Signed-off-by: Greg Kroah-Hartman commit d17d47da59f726dc4c87caebda3a50333d7e2fd3 Author: David Ahern Date: Mon Jun 7 11:35:30 2021 -0600 neighbour: allow NUD_NOARP entries to be forced GCed commit 7a6b1ab7475fd6478eeaf5c9d1163e7a18125c8f upstream. IFF_POINTOPOINT interfaces use NUD_NOARP entries for IPv6. It's possible to fill up the neighbour table with enough entries that it will overflow for valid connections after that. This behaviour is more prevalent after commit 58956317c8de ("neighbor: Improve garbage collection") is applied, as it prevents removal from entries that are not NUD_FAILED, unless they are more than 5s old. Fixes: 58956317c8de (neighbor: Improve garbage collection) Reported-by: Kasper Dupont Signed-off-by: Thadeu Lima de Souza Cascardo Signed-off-by: David Ahern Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 6b53db8c4c14b4e7256f058d202908b54a7b85b4 Author: Roger Pau Monne Date: Mon Jun 7 15:13:15 2021 +0200 xen-netback: take a reference to the RX task thread commit 107866a8eb0b664675a260f1ba0655010fac1e08 upstream. Do this in order to prevent the task from being freed if the thread returns (which can be triggered by the frontend) before the call to kthread_stop done as part of the backend tear down. Not taking the reference will lead to a use-after-free in that scenario. Such reference was taken before but dropped as part of the rework done in 2ac061ce97f4. Reintroduce the reference taking and add a comment this time explaining why it's needed. This is XSA-374 / CVE-2021-28691. Fixes: 2ac061ce97f4 ('xen/netback: cleanup init and deinit code') Signed-off-by: Roger Pau Monné Cc: stable@vger.kernel.org Reviewed-by: Jan Beulich Reviewed-by: Juergen Gross Signed-off-by: Juergen Gross Signed-off-by: Greg Kroah-Hartman commit 316de9a88c83c672c18d35bd76034d84e3769fe9 Author: Pablo Neira Ayuso Date: Wed May 19 13:32:20 2021 +0200 netfilter: nf_tables: missing error reporting for not selected expressions commit c781471d67a56d7d4c113669a11ede0463b5c719 upstream. Sometimes users forget to turn on nftables extensions from Kconfig that they need. In such case, the error reporting from userspace is misleading: $ sudo nft add rule x y counter Error: Could not process rule: No such file or directory add rule x y counter ^^^^^^^^^^^^^^^^^^^^ Add missing NL_SET_BAD_ATTR() to provide a hint: $ nft add rule x y counter Error: Could not process rule: No such file or directory add rule x y counter ^^^^^^^ Fixes: 83d9dcba06c5 ("netfilter: nf_tables: extended netlink error reporting for expressions") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit eddf2d9f76b01201dd778f2d36d75b8050217cf7 Author: Roja Rani Yarubandi Date: Tue May 25 18:40:51 2021 +0530 i2c: qcom-geni: Suspend and resume the bus during SYSTEM_SLEEP_PM ops commit 57648e860485de39c800a89f849fdd03c2d31d15 upstream. Mark bus as suspended during system suspend to block the future transfers. Implement geni_i2c_resume_noirq() to resume the bus. Fixes: 37692de5d523 ("i2c: i2c-qcom-geni: Add bus driver for the Qualcomm GENI I2C controller") Signed-off-by: Roja Rani Yarubandi Reviewed-by: Stephen Boyd Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit f20eef4d068637dc48ed24887ebc7b1faa860ae5 Author: Gao Xiang Date: Tue Dec 15 20:44:03 2020 -0800 lib/lz4: explicitly support in-place decompression commit 89b158635ad79574bde8e94d45dad33f8cf09549 upstream. LZ4 final literal copy could be overlapped when doing in-place decompression, so it's unsafe to just use memcpy() on an optimized memcpy approach but memmove() instead. Upstream LZ4 has updated this years ago [1] (and the impact is non-sensible [2] plus only a few bytes remain), this commit just synchronizes LZ4 upstream code to the kernel side as well. It can be observed as EROFS in-place decompression failure on specific files when X86_FEATURE_ERMS is unsupported, memcpy() optimization of commit 59daa706fbec ("x86, mem: Optimize memcpy by avoiding memory false dependece") will be enabled then. Currently most modern x86-CPUs support ERMS, these CPUs just use "rep movsb" approach so no problem at all. However, it can still be verified with forcely disabling ERMS feature... arch/x86/lib/memcpy_64.S: ALTERNATIVE_2 "jmp memcpy_orig", "", X86_FEATURE_REP_GOOD, \ - "jmp memcpy_erms", X86_FEATURE_ERMS + "jmp memcpy_orig", X86_FEATURE_ERMS We didn't observe any strange on arm64/arm/x86 platform before since most memcpy() would behave in an increasing address order ("copy upwards" [3]) and it's the correct order of in-place decompression but it really needs an update to memmove() for sure considering it's an undefined behavior according to the standard and some unique optimization already exists in the kernel. [1] https://github.com/lz4/lz4/commit/33cb8518ac385835cc17be9a770b27b40cd0e15b [2] https://github.com/lz4/lz4/pull/717#issuecomment-497818921 [3] https://sourceware.org/bugzilla/show_bug.cgi?id=12518 Link: https://lkml.kernel.org/r/20201122030749.2698994-1-hsiangkao@redhat.com Signed-off-by: Gao Xiang Reviewed-by: Nick Terrell Cc: Yann Collet Cc: Miao Xie Cc: Chao Yu Cc: Li Guifu Cc: Guo Xuenan Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Gao Xiang Signed-off-by: Greg Kroah-Hartman commit 334c59d58de5faf449d9c9feaa8c50dd8b4046a7 Author: Vitaly Kuznetsov Date: Mon May 31 16:05:26 2021 +0200 x86/kvm: Disable all PV features on crash commit 3d6b84132d2a57b5a74100f6923a8feb679ac2ce upstream. Crash shutdown handler only disables kvmclock and steal time, other PV features remain active so we risk corrupting memory or getting some side-effects in kdump kernel. Move crash handler to kvm.c and unify with CPU offline. Signed-off-by: Vitaly Kuznetsov Message-Id: <20210414123544.1060604-5-vkuznets@redhat.com> Signed-off-by: Paolo Bonzini Signed-off-by: Krzysztof Kozlowski Signed-off-by: Greg Kroah-Hartman commit 3b0becf8b1ecf642a9edaf4c9628ffc641e490d6 Author: Vitaly Kuznetsov Date: Mon May 31 16:05:25 2021 +0200 x86/kvm: Disable kvmclock on all CPUs on shutdown commit c02027b5742b5aa804ef08a4a9db433295533046 upstream. Currenly, we disable kvmclock from machine_shutdown() hook and this only happens for boot CPU. We need to disable it for all CPUs to guard against memory corruption e.g. on restore from hibernate. Note, writing '0' to kvmclock MSR doesn't clear memory location, it just prevents hypervisor from updating the location so for the short while after write and while CPU is still alive, the clock remains usable and correct so we don't need to switch to some other clocksource. Signed-off-by: Vitaly Kuznetsov Message-Id: <20210414123544.1060604-4-vkuznets@redhat.com> Signed-off-by: Paolo Bonzini Signed-off-by: Andrea Righi Signed-off-by: Krzysztof Kozlowski Signed-off-by: Greg Kroah-Hartman commit 38b858da1c58ad46519a257764e059e663b59ff2 Author: Vitaly Kuznetsov Date: Mon May 31 16:05:24 2021 +0200 x86/kvm: Teardown PV features on boot CPU as well commit 8b79feffeca28c5459458fe78676b081e87c93a4 upstream. Various PV features (Async PF, PV EOI, steal time) work through memory shared with hypervisor and when we restore from hibernation we must properly teardown all these features to make sure hypervisor doesn't write to stale locations after we jump to the previously hibernated kernel (which can try to place anything there). For secondary CPUs the job is already done by kvm_cpu_down_prepare(), register syscore ops to do the same for boot CPU. Krzysztof: This fixes memory corruption visible after second resume from hibernation: BUG: Bad page state in process dbus-daemon pfn:18b01 page:ffffea000062c040 refcount:0 mapcount:0 mapping:0000000000000000 index:0x1 compound_mapcount: -30591 flags: 0xfffffc0078141(locked|error|workingset|writeback|head|mappedtodisk|reclaim) raw: 000fffffc0078141 dead0000000002d0 dead000000000100 0000000000000000 raw: 0000000000000001 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: PAGE_FLAGS_CHECK_AT_PREP flag set bad because of flags: 0x78141(locked|error|workingset|writeback|head|mappedtodisk|reclaim) Signed-off-by: Vitaly Kuznetsov Message-Id: <20210414123544.1060604-3-vkuznets@redhat.com> Signed-off-by: Paolo Bonzini Signed-off-by: Andrea Righi [krzysztof: Extend the commit message, adjust for v5.10 context] Signed-off-by: Krzysztof Kozlowski Signed-off-by: Greg Kroah-Hartman commit b327c97747595b462a003a11e6728ebd860cd285 Author: Marc Zyngier Date: Fri May 14 09:05:41 2021 +0100 KVM: arm64: Fix debug register indexing commit cb853ded1d25e5b026ce115dbcde69e3d7e2e831 upstream. Commit 03fdfb2690099 ("KVM: arm64: Don't write junk to sysregs on reset") flipped the register number to 0 for all the debug registers in the sysreg table, hereby indicating that these registers live in a separate shadow structure. However, the author of this patch failed to realise that all the accessors are using that particular index instead of the register encoding, resulting in all the registers hitting index 0. Not quite a valid implementation of the architecture... Address the issue by fixing all the accessors to use the CRm field of the encoding, which contains the debug register index. Fixes: 03fdfb2690099 ("KVM: arm64: Don't write junk to sysregs on reset") Reported-by: Ricardo Koller Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit b3ee3f50ab1bf7b60ba4a8346dca05ba3412fead Author: Sean Christopherson Date: Wed Apr 21 19:21:22 2021 -0700 KVM: SVM: Truncate GPR value for DR and CR accesses in !64-bit mode commit 0884335a2e653b8a045083aa1d57ce74269ac81d upstream. Drop bits 63:32 on loads/stores to/from DRs and CRs when the vCPU is not in 64-bit mode. The APM states bits 63:32 are dropped for both DRs and CRs: In 64-bit mode, the operand size is fixed at 64 bits without the need for a REX prefix. In non-64-bit mode, the operand size is fixed at 32 bits and the upper 32 bits of the destination are forced to 0. Fixes: 7ff76d58a9dc ("KVM: SVM: enhance MOV CR intercept handler") Fixes: cae3797a4639 ("KVM: SVM: enhance mov DR intercept handler") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Message-Id: <20210422022128.3464144-4-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sudip Mukherjee Signed-off-by: Greg Kroah-Hartman commit fe910d20e2d8e0736bbea9c1efe6a49535e807ea Author: Anand Jain Date: Fri Apr 30 19:59:51 2021 +0800 btrfs: fix unmountable seed device after fstrim commit 5e753a817b2d5991dfe8a801b7b1e8e79a1c5a20 upstream. The following test case reproduces an issue of wrongly freeing in-use blocks on the readonly seed device when fstrim is called on the rw sprout device. As shown below. Create a seed device and add a sprout device to it: $ mkfs.btrfs -fq -dsingle -msingle /dev/loop0 $ btrfstune -S 1 /dev/loop0 $ mount /dev/loop0 /btrfs $ btrfs dev add -f /dev/loop1 /btrfs BTRFS info (device loop0): relocating block group 290455552 flags system BTRFS info (device loop0): relocating block group 1048576 flags system BTRFS info (device loop0): disk added /dev/loop1 $ umount /btrfs Mount the sprout device and run fstrim: $ mount /dev/loop1 /btrfs $ fstrim /btrfs $ umount /btrfs Now try to mount the seed device, and it fails: $ mount /dev/loop0 /btrfs mount: /btrfs: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error. Block 5292032 is missing on the readonly seed device: $ dmesg -kt | tail BTRFS error (device loop0): bad tree block start, want 5292032 have 0 BTRFS warning (device loop0): couldn't read-tree root BTRFS error (device loop0): open_ctree failed >From the dump-tree of the seed device (taken before the fstrim). Block 5292032 belonged to the block group starting at 5242880: $ btrfs inspect dump-tree -e /dev/loop0 | grep -A1 BLOCK_GROUP item 3 key (5242880 BLOCK_GROUP_ITEM 8388608) itemoff 16169 itemsize 24 block group used 114688 chunk_objectid 256 flags METADATA >From the dump-tree of the sprout device (taken before the fstrim). fstrim used block-group 5242880 to find the related free space to free: $ btrfs inspect dump-tree -e /dev/loop1 | grep -A1 BLOCK_GROUP item 1 key (5242880 BLOCK_GROUP_ITEM 8388608) itemoff 16226 itemsize 24 block group used 32768 chunk_objectid 256 flags METADATA BPF kernel tracing the fstrim command finds the missing block 5292032 within the range of the discarded blocks as below: kprobe:btrfs_discard_extent { printf("freeing start %llu end %llu num_bytes %llu:\n", arg1, arg1+arg2, arg2); } freeing start 5259264 end 5406720 num_bytes 147456 Fix this by avoiding the discard command to the readonly seed device. Reported-by: Chris Murphy CC: stable@vger.kernel.org # 4.4+ Reviewed-by: Filipe Manana Signed-off-by: Anand Jain Signed-off-by: David Sterba Signed-off-by: Sudip Mukherjee Signed-off-by: Greg Kroah-Hartman commit 05e41f6f1c4e8c42edb9715b6629d9ab2af61064 Author: Dmitry Baryshkov Date: Thu Apr 1 05:05:33 2021 +0300 drm/msm/dpu: always use mdp device to scale bandwidth commit a670ff578f1fb855fedc7931fa5bbc06b567af22 upstream. Currently DPU driver scales bandwidth and core clock for sc7180 only, while the rest of chips get static bandwidth votes. Make all chipsets scale bandwidth and clock per composition requirements like sc7180 does. Drop old voting path completely. Tested on RB3 (SDM845) and RB5 (SM8250). Signed-off-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20210401020533.3956787-2-dmitry.baryshkov@linaro.org Signed-off-by: Rob Clark Signed-off-by: Amit Pundir Signed-off-by: Greg Kroah-Hartman commit 2eb4ec9c2c3535b9755c484183cc5c4d90fd37ff Author: Mina Almasry Date: Fri Jun 4 20:01:36 2021 -0700 mm, hugetlb: fix simple resv_huge_pages underflow on UFFDIO_COPY [ Upstream commit d84cf06e3dd8c5c5b547b5d8931015fc536678e5 ] The userfaultfd hugetlb tests cause a resv_huge_pages underflow. This happens when hugetlb_mcopy_atomic_pte() is called with !is_continue on an index for which we already have a page in the cache. When this happens, we allocate a second page, double consuming the reservation, and then fail to insert the page into the cache and return -EEXIST. To fix this, we first check if there is a page in the cache which already consumed the reservation, and return -EEXIST immediately if so. There is still a rare condition where we fail to copy the page contents AND race with a call for hugetlb_no_page() for this index and again we will underflow resv_huge_pages. That is fixed in a more complicated patch not targeted for -stable. Test: Hacked the code locally such that resv_huge_pages underflows produce a warning, then: ./tools/testing/selftests/vm/userfaultfd hugetlb_shared 10 2 /tmp/kokonut_test/huge/userfaultfd_test && echo test success ./tools/testing/selftests/vm/userfaultfd hugetlb 10 2 /tmp/kokonut_test/huge/userfaultfd_test && echo test success Both tests succeed and produce no warnings. After the test runs number of free/resv hugepages is correct. [mike.kravetz@oracle.com: changelog fixes] Link: https://lkml.kernel.org/r/20210528004649.85298-1-almasrymina@google.com Fixes: 8fb5debc5fcd ("userfaultfd: hugetlbfs: add hugetlb_mcopy_atomic_pte for userfaultfd support") Signed-off-by: Mina Almasry Reviewed-by: Mike Kravetz Cc: Axel Rasmussen Cc: Peter Xu Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit baa6763123e2b63b8289943c7211ba0e3220432f Author: Filipe Manana Date: Tue May 25 11:05:28 2021 +0100 btrfs: fix deadlock when cloning inline extents and low on available space commit 76a6d5cd74479e7ec8a7f9a29bce63d5549b6b2e upstream. There are a few cases where cloning an inline extent requires copying data into a page of the destination inode. For these cases we are allocating the required data and metadata space while holding a leaf locked. This can result in a deadlock when we are low on available space because allocating the space may flush delalloc and two deadlock scenarios can happen: 1) When starting writeback for an inode with a very small dirty range that fits in an inline extent, we deadlock during the writeback when trying to insert the inline extent, at cow_file_range_inline(), if the extent is going to be located in the leaf for which we are already holding a read lock; 2) After successfully starting writeback, for non-inline extent cases, the async reclaim thread will hang waiting for an ordered extent to complete if the ordered extent completion needs to modify the leaf for which the clone task is holding a read lock (for adding or replacing file extent items). So the cloning task will wait forever on the async reclaim thread to make progress, which in turn is waiting for the ordered extent completion which in turn is waiting to acquire a write lock on the same leaf. So fix this by making sure we release the path (and therefore the leaf) every time we need to copy the inline extent's data into a page of the destination inode, as by that time we do not need to have the leaf locked. Fixes: 05a5a7621ce66c ("Btrfs: implement full reflink support for inline extents") CC: stable@vger.kernel.org # 5.10+ Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 0df50d47d17401f9f140dfbe752a65e5d72f9932 Author: Josef Bacik Date: Wed May 19 14:04:21 2021 -0400 btrfs: abort in rename_exchange if we fail to insert the second ref commit dc09ef3562726cd520c8338c1640872a60187af5 upstream. Error injection stress uncovered a problem where we'd leave a dangling inode ref if we failed during a rename_exchange. This happens because we insert the inode ref for one side of the rename, and then for the other side. If this second inode ref insert fails we'll leave the first one dangling and leave a corrupt file system behind. Fix this by aborting if we did the insert for the first inode ref. CC: stable@vger.kernel.org # 4.9+ Signed-off-by: Josef Bacik Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 48568f3944ee7357e8fed394804745bd981e978a Author: Josef Bacik Date: Wed May 19 13:13:15 2021 -0400 btrfs: fixup error handling in fixup_inode_link_counts commit 011b28acf940eb61c000059dd9e2cfcbf52ed96b upstream. This function has the following pattern while (1) { ret = whatever(); if (ret) goto out; } ret = 0 out: return ret; However several places in this while loop we simply break; when there's a problem, thus clearing the return value, and in one case we do a return -EIO, and leak the memory for the path. Fix this by re-arranging the loop to deal with ret == 1 coming from btrfs_search_slot, and then simply delete the ret = 0; out: bit so everybody can break if there is an error, which will allow for proper error handling to occur. CC: stable@vger.kernel.org # 4.4+ Signed-off-by: Josef Bacik Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 466d83fdbbe345f3cfd5f7b2633f740ecad67853 Author: Josef Bacik Date: Wed May 19 10:52:46 2021 -0400 btrfs: return errors from btrfs_del_csums in cleanup_ref_head commit 856bd270dc4db209c779ce1e9555c7641ffbc88e upstream. We are unconditionally returning 0 in cleanup_ref_head, despite the fact that btrfs_del_csums could fail. We need to return the error so the transaction gets aborted properly, fix this by returning ret from btrfs_del_csums in cleanup_ref_head. Reviewed-by: Qu Wenruo CC: stable@vger.kernel.org # 4.19+ Signed-off-by: Josef Bacik Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 5a89982fa2bba459b82323655df986945a853bbe Author: Josef Bacik Date: Wed May 19 10:52:45 2021 -0400 btrfs: fix error handling in btrfs_del_csums commit b86652be7c83f70bf406bed18ecf55adb9bfb91b upstream. Error injection stress would sometimes fail with checksums on disk that did not have a corresponding extent. This occurred because the pattern in btrfs_del_csums was while (1) { ret = btrfs_search_slot(); if (ret < 0) break; } ret = 0; out: btrfs_free_path(path); return ret; If we got an error from btrfs_search_slot we'd clear the error because we were breaking instead of goto out. Instead of using goto out, simply handle the cases where we may leave a random value in ret, and get rid of the ret = 0; out: pattern and simply allow break to have the proper error reporting. With this fix we properly abort the transaction and do not commit thinking we successfully deleted the csum. Reviewed-by: Qu Wenruo CC: stable@vger.kernel.org # 4.4+ Signed-off-by: Josef Bacik Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit b547a16b24918edd63042f9d81c0d310212d2e94 Author: Josef Bacik Date: Wed May 19 09:38:27 2021 -0400 btrfs: mark ordered extent and inode with error if we fail to finish commit d61bec08b904cf171835db98168f82bc338e92e4 upstream. While doing error injection testing I saw that sometimes we'd get an abort that wouldn't stop the current transaction commit from completing. This abort was coming from finish ordered IO, but at this point in the transaction commit we should have gotten an error and stopped. It turns out the abort came from finish ordered io while trying to write out the free space cache. It occurred to me that any failure inside of finish_ordered_io isn't actually raised to the person doing the writing, so we could have any number of failures in this path and think the ordered extent completed successfully and the inode was fine. Fix this by marking the ordered extent with BTRFS_ORDERED_IOERR, and marking the mapping of the inode with mapping_set_error, so any callers that simply call fdatawait will also get the error. With this we're seeing the IO error on the free space inode when we fail to do the finish_ordered_io. CC: stable@vger.kernel.org # 4.19+ Signed-off-by: Josef Bacik Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 5e5e63bacbe8f1ef9688e7804275eb88cf0be51a Author: Naveen N. Rao Date: Wed May 19 16:17:17 2021 +0530 powerpc/kprobes: Fix validation of prefixed instructions across page boundary commit 82123a3d1d5a306fdf50c968a474cc60fe43a80f upstream. When checking if the probed instruction is the suffix of a prefixed instruction, we access the instruction at the previous word. If the probed instruction is the very first word of a module, we can end up trying to access an invalid page. Fix this by skipping the check for all instructions at the beginning of a page. Prefixed instructions cannot cross a 64-byte boundary and as such, we don't expect to encounter a suffix as the very first word in a page for kernel text. Even if there are prefixed instructions crossing a page boundary (from a module, for instance), the instruction will be illegal, so preventing probing on the suffix of such prefix instructions isn't worthwhile. Fixes: b4657f7650ba ("powerpc/kprobes: Don't allow breakpoints on suffixes") Cc: stable@vger.kernel.org # v5.8+ Reported-by: Christophe Leroy Signed-off-by: Naveen N. Rao Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/0df9a032a05576a2fa8e97d1b769af2ff0eafbd6.1621416666.git.naveen.n.rao@linux.vnet.ibm.com Signed-off-by: Greg Kroah-Hartman commit 42f75a4381a4ffb1b7488f90c657ea0b5461d3b7 Author: Thomas Gleixner Date: Tue May 25 13:08:41 2021 +0200 x86/apic: Mark _all_ legacy interrupts when IO/APIC is missing commit 7d65f9e80646c595e8c853640a9d0768a33e204c upstream. PIC interrupts do not support affinity setting and they can end up on any online CPU. Therefore, it's required to mark the associated vectors as system-wide reserved. Otherwise, the corresponding irq descriptors are copied to the secondary CPUs but the vectors are not marked as assigned or reserved. This works correctly for the IO/APIC case. When the IO/APIC is disabled via config, kernel command line or lack of enumeration then all legacy interrupts are routed through the PIC, but nothing marks them as system-wide reserved vectors. As a consequence, a subsequent allocation on a secondary CPU can result in allocating one of these vectors, which triggers the BUG() in apic_update_vector() because the interrupt descriptor slot is not empty. Imran tried to work around that by marking those interrupts as allocated when a CPU comes online. But that's wrong in case that the IO/APIC is available and one of the legacy interrupts, e.g. IRQ0, has been switched to PIC mode because then marking them as allocated will fail as they are already marked as system vectors. Stay consistent and update the legacy vectors after attempting IO/APIC initialization and mark them as system vectors in case that no IO/APIC is available. Fixes: 69cde0004a4b ("x86/vector: Use matrix allocator for vector assignment") Reported-by: Imran Khan Signed-off-by: Thomas Gleixner Signed-off-by: Borislav Petkov Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20210519233928.2157496-1-imran.f.khan@oracle.com Signed-off-by: Greg Kroah-Hartman commit 3a6b69221f96f87c680bbc9fba01db3415b18f27 Author: Nirmoy Das Date: Fri May 28 16:54:16 2021 +0200 drm/amdgpu: make sure we unpin the UVD BO commit 07438603a07e52f1c6aa731842bd298d2725b7be upstream. Releasing pinned BOs is illegal now. UVD 6 was missing from: commit 2f40801dc553 ("drm/amdgpu: make sure we unpin the UVD BO") Fixes: 2f40801dc553 ("drm/amdgpu: make sure we unpin the UVD BO") Cc: stable@vger.kernel.org Signed-off-by: Nirmoy Das Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 58da0b509e4b8f4a3a4b1b2e23871d108f81338a Author: Luben Tuikov Date: Wed May 12 12:33:23 2021 -0400 drm/amdgpu: Don't query CE and UE errors commit dce3d8e1d070900e0feeb06787a319ff9379212c upstream. On QUERY2 IOCTL don't query counts of correctable and uncorrectable errors, since when RAS is enabled and supported on Vega20 server boards, this takes insurmountably long time, in O(n^3), which slows the system down to the point of it being unusable when we have GUI up. Fixes: ae363a212b14 ("drm/amdgpu: Add a new flag to AMDGPU_CTX_OP_QUERY_STATE2") Cc: Alexander Deucher Cc: stable@vger.kernel.org Signed-off-by: Luben Tuikov Reviewed-by: Alexander Deucher Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 48ee0db61c8299022ec88c79ad137f290196cac2 Author: Krzysztof Kozlowski Date: Mon May 31 09:21:38 2021 +0200 nfc: fix NULL ptr dereference in llcp_sock_getname() after failed connect commit 4ac06a1e013cf5fdd963317ffd3b968560f33bba upstream. It's possible to trigger NULL pointer dereference by local unprivileged user, when calling getsockname() after failed bind() (e.g. the bind fails because LLCP_SAP_MAX used as SAP): BUG: kernel NULL pointer dereference, address: 0000000000000000 CPU: 1 PID: 426 Comm: llcp_sock_getna Not tainted 5.13.0-rc2-next-20210521+ #9 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1 04/01/2014 Call Trace: llcp_sock_getname+0xb1/0xe0 __sys_getpeername+0x95/0xc0 ? lockdep_hardirqs_on_prepare+0xd5/0x180 ? syscall_enter_from_user_mode+0x1c/0x40 __x64_sys_getpeername+0x11/0x20 do_syscall_64+0x36/0x70 entry_SYSCALL_64_after_hwframe+0x44/0xae This can be reproduced with Syzkaller C repro (bind followed by getpeername): https://syzkaller.appspot.com/x/repro.c?x=14def446e00000 Cc: Fixes: d646960f7986 ("NFC: Initial LLCP support") Reported-by: syzbot+80fb126e7f7d8b1a5914@syzkaller.appspotmail.com Reported-by: butt3rflyh4ck Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20210531072138.5219-1-krzysztof.kozlowski@canonical.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 445477e9274efd08459b7ccf19578a63c3596082 Author: Pu Wen Date: Wed Jun 2 15:02:07 2021 +0800 x86/sev: Check SME/SEV support in CPUID first commit 009767dbf42ac0dbe3cf48c1ee224f6b778aa85a upstream. The first two bits of the CPUID leaf 0x8000001F EAX indicate whether SEV or SME is supported, respectively. It's better to check whether SEV or SME is actually supported before accessing the MSR_AMD64_SEV to check whether SEV or SME is enabled. This is both a bare-metal issue and a guest/VM issue. Since the first generation Hygon Dhyana CPU doesn't support the MSR_AMD64_SEV, reading that MSR results in a #GP - either directly from hardware in the bare-metal case or via the hypervisor (because the RDMSR is actually intercepted) in the guest/VM case, resulting in a failed boot. And since this is very early in the boot phase, rdmsrl_safe()/native_read_msr_safe() can't be used. So check the CPUID bits first, before accessing the MSR. [ tlendacky: Expand and improve commit message. ] [ bp: Massage commit message. ] Fixes: eab696d8e8b9 ("x86/sev: Do not require Hypervisor CPUID bit for SEV guests") Signed-off-by: Pu Wen Signed-off-by: Borislav Petkov Acked-by: Tom Lendacky Cc: # v5.10+ Link: https://lkml.kernel.org/r/20210602070207.2480-1-puwen@hygon.cn Signed-off-by: Greg Kroah-Hartman commit 942c5864de85dc14602ec875e88e0337896db6d9 Author: Thomas Gleixner Date: Sat May 29 11:17:30 2021 +0200 x86/cpufeatures: Force disable X86_FEATURE_ENQCMD and remove update_pasid() commit 9bfecd05833918526cc7357d55e393393440c5fa upstream. While digesting the XSAVE-related horrors which got introduced with the supervisor/user split, the recent addition of ENQCMD-related functionality got on the radar and turned out to be similarly broken. update_pasid(), which is only required when X86_FEATURE_ENQCMD is available, is invoked from two places: 1) From switch_to() for the incoming task 2) Via a SMP function call from the IOMMU/SMV code #1 is half-ways correct as it hacks around the brokenness of get_xsave_addr() by enforcing the state to be 'present', but all the conditionals in that code are completely pointless for that. Also the invocation is just useless overhead because at that point it's guaranteed that TIF_NEED_FPU_LOAD is set on the incoming task and all of this can be handled at return to user space. #2 is broken beyond repair. The comment in the code claims that it is safe to invoke this in an IPI, but that's just wishful thinking. FPU state of a running task is protected by fregs_lock() which is nothing else than a local_bh_disable(). As BH-disabled regions run usually with interrupts enabled the IPI can hit a code section which modifies FPU state and there is absolutely no guarantee that any of the assumptions which are made for the IPI case is true. Also the IPI is sent to all CPUs in mm_cpumask(mm), but the IPI is invoked with a NULL pointer argument, so it can hit a completely unrelated task and unconditionally force an update for nothing. Worse, it can hit a kernel thread which operates on a user space address space and set a random PASID for it. The offending commit does not cleanly revert, but it's sufficient to force disable X86_FEATURE_ENQCMD and to remove the broken update_pasid() code to make this dysfunctional all over the place. Anything more complex would require more surgery and none of the related functions outside of the x86 core code are blatantly wrong, so removing those would be overkill. As nothing enables the PASID bit in the IA32_XSS MSR yet, which is required to make this actually work, this cannot result in a regression except for related out of tree train-wrecks, but they are broken already today. Fixes: 20f0afd1fb3d ("x86/mmu: Allocate/free a PASID") Signed-off-by: Thomas Gleixner Signed-off-by: Borislav Petkov Acked-by: Andy Lutomirski Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/87mtsd6gr9.ffs@nanos.tec.linutronix.de Signed-off-by: Greg Kroah-Hartman commit 68dcd32b326a3cb875ae579b120dae34718451a2 Author: Ding Hui Date: Fri Jun 4 20:01:21 2021 -0700 mm/page_alloc: fix counting of free pages after take off from buddy commit bac9c6fa1f929213bbd0ac9cdf21e8e2f0916828 upstream. Recently we found that there is a lot MemFree left in /proc/meminfo after do a lot of pages soft offline, it's not quite correct. Before Oscar's rework of soft offline for free pages [1], if we soft offline free pages, these pages are left in buddy with HWPoison flag, and NR_FREE_PAGES is not updated immediately. So the difference between NR_FREE_PAGES and real number of available free pages is also even big at the beginning. However, with the workload running, when we catch HWPoison page in any alloc functions subsequently, we will remove it from buddy, meanwhile update the NR_FREE_PAGES and try again, so the NR_FREE_PAGES will get more and more closer to the real number of available free pages. (regardless of unpoison_memory()) Now, for offline free pages, after a successful call take_page_off_buddy(), the page is no longer belong to buddy allocator, and will not be used any more, but we missed accounting NR_FREE_PAGES in this situation, and there is no chance to be updated later. Do update in take_page_off_buddy() like rmqueue() does, but avoid double counting if some one already set_migratetype_isolate() on the page. [1]: commit 06be6ff3d2ec ("mm,hwpoison: rework soft offline for free pages") Link: https://lkml.kernel.org/r/20210526075247.11130-1-dinghui@sangfor.com.cn Fixes: 06be6ff3d2ec ("mm,hwpoison: rework soft offline for free pages") Signed-off-by: Ding Hui Suggested-by: Naoya Horiguchi Reviewed-by: Oscar Salvador Acked-by: David Hildenbrand Acked-by: Naoya Horiguchi Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 5f2e1e818e9fe3df198259cdbc070989d7f01c24 Author: Gerald Schaefer Date: Fri Jun 4 20:01:18 2021 -0700 mm/debug_vm_pgtable: fix alignment for pmd/pud_advanced_tests() commit 04f7ce3f07ce39b1a3ca03a56b238a53acc52cfd upstream. In pmd/pud_advanced_tests(), the vaddr is aligned up to the next pmd/pud entry, and so it does not match the given pmdp/pudp and (aligned down) pfn any more. For s390, this results in memory corruption, because the IDTE instruction used e.g. in xxx_get_and_clear() will take the vaddr for some calculations, in combination with the given pmdp. It will then end up with a wrong table origin, ending on ...ff8, and some of those wrongly set low-order bits will also select a wrong pagetable level for the index addition. IDTE could therefore invalidate (or 0x20) something outside of the page tables, depending on the wrongly picked index, which in turn depends on the random vaddr. As result, we sometimes see "BUG task_struct (Not tainted): Padding overwritten" on s390, where one 0x5a padding value got overwritten with 0x7a. Fix this by aligning down, similar to how the pmd/pud_aligned pfns are calculated. Link: https://lkml.kernel.org/r/20210525130043.186290-2-gerald.schaefer@linux.ibm.com Fixes: a5c3b9ffb0f40 ("mm/debug_vm_pgtable: add tests validating advanced arch page table helpers") Signed-off-by: Gerald Schaefer Reviewed-by: Anshuman Khandual Cc: Vineet Gupta Cc: Palmer Dabbelt Cc: Paul Walmsley Cc: [5.9+] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit c8d5faee46242c3f33b8a71a4d7d52214785bfcc Author: Junxiao Bi Date: Fri Jun 4 20:01:42 2021 -0700 ocfs2: fix data corruption by fallocate commit 6bba4471f0cc1296fe3c2089b9e52442d3074b2e upstream. When fallocate punches holes out of inode size, if original isize is in the middle of last cluster, then the part from isize to the end of the cluster will be zeroed with buffer write, at that time isize is not yet updated to match the new size, if writeback is kicked in, it will invoke ocfs2_writepage()->block_write_full_page() where the pages out of inode size will be dropped. That will cause file corruption. Fix this by zero out eof blocks when extending the inode size. Running the following command with qemu-image 4.2.1 can get a corrupted coverted image file easily. qemu-img convert -p -t none -T none -f qcow2 $qcow_image \ -O qcow2 -o compat=1.1 $qcow_image.conv The usage of fallocate in qemu is like this, it first punches holes out of inode size, then extend the inode size. fallocate(11, FALLOC_FL_KEEP_SIZE|FALLOC_FL_PUNCH_HOLE, 2276196352, 65536) = 0 fallocate(11, 0, 2276196352, 65536) = 0 v1: https://www.spinics.net/lists/linux-fsdevel/msg193999.html v2: https://lore.kernel.org/linux-fsdevel/20210525093034.GB4112@quack2.suse.cz/T/ Link: https://lkml.kernel.org/r/20210528210648.9124-1-junxiao.bi@oracle.com Signed-off-by: Junxiao Bi Reviewed-by: Joseph Qi Cc: Jan Kara Cc: Mark Fasheh Cc: Joel Becker Cc: Changwei Ge Cc: Gang He Cc: Jun Piao Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 7178be006d495ffb741c329012da289b62dddfe6 Author: Mark Rutland Date: Fri Jun 4 20:01:14 2021 -0700 pid: take a reference when initializing `cad_pid` commit 0711f0d7050b9e07c44bc159bbc64ac0a1022c7f upstream. During boot, kernel_init_freeable() initializes `cad_pid` to the init task's struct pid. Later on, we may change `cad_pid` via a sysctl, and when this happens proc_do_cad_pid() will increment the refcount on the new pid via get_pid(), and will decrement the refcount on the old pid via put_pid(). As we never called get_pid() when we initialized `cad_pid`, we decrement a reference we never incremented, can therefore free the init task's struct pid early. As there can be dangling references to the struct pid, we can later encounter a use-after-free (e.g. when delivering signals). This was spotted when fuzzing v5.13-rc3 with Syzkaller, but seems to have been around since the conversion of `cad_pid` to struct pid in commit 9ec52099e4b8 ("[PATCH] replace cad_pid by a struct pid") from the pre-KASAN stone age of v2.6.19. Fix this by getting a reference to the init task's struct pid when we assign it to `cad_pid`. Full KASAN splat below. ================================================================== BUG: KASAN: use-after-free in ns_of_pid include/linux/pid.h:153 [inline] BUG: KASAN: use-after-free in task_active_pid_ns+0xc0/0xc8 kernel/pid.c:509 Read of size 4 at addr ffff23794dda0004 by task syz-executor.0/273 CPU: 1 PID: 273 Comm: syz-executor.0 Not tainted 5.12.0-00001-g9aef892b2d15 #1 Hardware name: linux,dummy-virt (DT) Call trace: ns_of_pid include/linux/pid.h:153 [inline] task_active_pid_ns+0xc0/0xc8 kernel/pid.c:509 do_notify_parent+0x308/0xe60 kernel/signal.c:1950 exit_notify kernel/exit.c:682 [inline] do_exit+0x2334/0x2bd0 kernel/exit.c:845 do_group_exit+0x108/0x2c8 kernel/exit.c:922 get_signal+0x4e4/0x2a88 kernel/signal.c:2781 do_signal arch/arm64/kernel/signal.c:882 [inline] do_notify_resume+0x300/0x970 arch/arm64/kernel/signal.c:936 work_pending+0xc/0x2dc Allocated by task 0: slab_post_alloc_hook+0x50/0x5c0 mm/slab.h:516 slab_alloc_node mm/slub.c:2907 [inline] slab_alloc mm/slub.c:2915 [inline] kmem_cache_alloc+0x1f4/0x4c0 mm/slub.c:2920 alloc_pid+0xdc/0xc00 kernel/pid.c:180 copy_process+0x2794/0x5e18 kernel/fork.c:2129 kernel_clone+0x194/0x13c8 kernel/fork.c:2500 kernel_thread+0xd4/0x110 kernel/fork.c:2552 rest_init+0x44/0x4a0 init/main.c:687 arch_call_rest_init+0x1c/0x28 start_kernel+0x520/0x554 init/main.c:1064 0x0 Freed by task 270: slab_free_hook mm/slub.c:1562 [inline] slab_free_freelist_hook+0x98/0x260 mm/slub.c:1600 slab_free mm/slub.c:3161 [inline] kmem_cache_free+0x224/0x8e0 mm/slub.c:3177 put_pid.part.4+0xe0/0x1a8 kernel/pid.c:114 put_pid+0x30/0x48 kernel/pid.c:109 proc_do_cad_pid+0x190/0x1b0 kernel/sysctl.c:1401 proc_sys_call_handler+0x338/0x4b0 fs/proc/proc_sysctl.c:591 proc_sys_write+0x34/0x48 fs/proc/proc_sysctl.c:617 call_write_iter include/linux/fs.h:1977 [inline] new_sync_write+0x3ac/0x510 fs/read_write.c:518 vfs_write fs/read_write.c:605 [inline] vfs_write+0x9c4/0x1018 fs/read_write.c:585 ksys_write+0x124/0x240 fs/read_write.c:658 __do_sys_write fs/read_write.c:670 [inline] __se_sys_write fs/read_write.c:667 [inline] __arm64_sys_write+0x78/0xb0 fs/read_write.c:667 __invoke_syscall arch/arm64/kernel/syscall.c:37 [inline] invoke_syscall arch/arm64/kernel/syscall.c:49 [inline] el0_svc_common.constprop.1+0x16c/0x388 arch/arm64/kernel/syscall.c:129 do_el0_svc+0xf8/0x150 arch/arm64/kernel/syscall.c:168 el0_svc+0x28/0x38 arch/arm64/kernel/entry-common.c:416 el0_sync_handler+0x134/0x180 arch/arm64/kernel/entry-common.c:432 el0_sync+0x154/0x180 arch/arm64/kernel/entry.S:701 The buggy address belongs to the object at ffff23794dda0000 which belongs to the cache pid of size 224 The buggy address is located 4 bytes inside of 224-byte region [ffff23794dda0000, ffff23794dda00e0) The buggy address belongs to the page: page:(____ptrval____) refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4dda0 head:(____ptrval____) order:1 compound_mapcount:0 flags: 0x3fffc0000010200(slab|head) raw: 03fffc0000010200 dead000000000100 dead000000000122 ffff23794d40d080 raw: 0000000000000000 0000000000190019 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff23794dd9ff00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff23794dd9ff80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff23794dda0000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff23794dda0080: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ffff23794dda0100: fc fc fc fc fc fc fc fc 00 00 00 00 00 00 00 00 ================================================================== Link: https://lkml.kernel.org/r/20210524172230.38715-1-mark.rutland@arm.com Fixes: 9ec52099e4b8678a ("[PATCH] replace cad_pid by a struct pid") Signed-off-by: Mark Rutland Acked-by: Christian Brauner Cc: Cedric Le Goater Cc: Christian Brauner Cc: Eric W. Biederman Cc: Kees Cook Cc: Paul Mackerras Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit a4ed12f5edc41abbfe2bce4a215de2f6ff4993eb Author: Phil Elwell Date: Tue Jun 8 13:00:49 2021 +0100 usb: dwc2: Fix build in periphal-only mode In branches to which 24d209dba5a3 ("usb: dwc2: Fix hibernation between host and device modes.") has been back-ported, the bus_suspended member of struct dwc2_hsotg is only present in builds that support host-mode. To avoid having to pull in several more non-Fix commits in order to get it to compile, wrap the usage of the member in a macro conditional. Fixes: 24d209dba5a3 ("usb: dwc2: Fix hibernation between host and device modes.") Signed-off-by: Phil Elwell Signed-off-by: Greg Kroah-Hartman commit 3b713aafa7c928c53cdc08bc948373566762ce1c Author: Ritesh Harjani Date: Thu Apr 29 16:13:44 2021 +0530 ext4: fix accessing uninit percpu counter variable with fast_commit commit b45f189a19b38e01676628db79cd3eeb1333516e upstream. When running generic/527 with fast_commit configuration, the following issue is seen on Power. With fast_commit, during ext4_fc_replay() (which can be called from ext4_fill_super()), if inode eviction happens then it can access an uninitialized percpu counter variable. This patch adds the check before accessing the counters in ext4_free_inode() path. [ 321.165371] run fstests generic/527 at 2021-04-29 08:38:43 [ 323.027786] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: block_validity. Quota mode: none. [ 323.618772] BUG: Unable to handle kernel data access on read at 0x1fbd80000 [ 323.619767] Faulting instruction address: 0xc000000000bae78c cpu 0x1: Vector: 300 (Data Access) at [c000000010706ef0] pc: c000000000bae78c: percpu_counter_add_batch+0x3c/0x100 lr: c0000000006d0bb0: ext4_free_inode+0x780/0xb90 pid = 5593, comm = mount ext4_free_inode+0x780/0xb90 ext4_evict_inode+0xa8c/0xc60 evict+0xfc/0x1e0 ext4_fc_replay+0xc50/0x20f0 do_one_pass+0xfe0/0x1350 jbd2_journal_recover+0x184/0x2e0 jbd2_journal_load+0x1c0/0x4a0 ext4_fill_super+0x2458/0x4200 mount_bdev+0x1dc/0x290 ext4_mount+0x28/0x40 legacy_get_tree+0x4c/0xa0 vfs_get_tree+0x4c/0x120 path_mount+0xcf8/0xd70 do_mount+0x80/0xd0 sys_mount+0x3fc/0x490 system_call_exception+0x384/0x3d0 system_call_common+0xec/0x278 Cc: stable@kernel.org Fixes: 8016e29f4362 ("ext4: fast commit recovery path") Signed-off-by: Ritesh Harjani Reviewed-by: Harshad Shirwadkar Link: https://lore.kernel.org/r/6cceb9a75c54bef8fa9696c1b08c8df5ff6169e2.1619692410.git.riteshh@linux.ibm.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 2050c6e5b161e5e25ce3c420fef58b24fa388a49 Author: Phillip Potter Date: Mon Apr 12 08:38:37 2021 +0100 ext4: fix memory leak in ext4_mb_init_backend on error path. commit a8867f4e3809050571c98de7a2d465aff5e4daf5 upstream. Fix a memory leak discovered by syzbot when a file system is corrupted with an illegally large s_log_groups_per_flex. Reported-by: syzbot+aa12d6106ea4ca1b6aae@syzkaller.appspotmail.com Signed-off-by: Phillip Potter Cc: stable@kernel.org Link: https://lore.kernel.org/r/20210412073837.1686-1-phil@philpotter.co.uk Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit fb86acc6236934e2b654f50d2a97fa77eac17859 Author: Harshad Shirwadkar Date: Wed May 19 14:59:20 2021 -0700 ext4: fix fast commit alignment issues commit a7ba36bc94f20b6c77f16364b9a23f582ea8faac upstream. Fast commit recovery data on disk may not be aligned. So, when the recovery code reads it, this patch makes sure that fast commit info found on-disk is first memcpy-ed into an aligned variable before accessing it. As a consequence of it, we also remove some macros that could resulted in unaligned accesses. Cc: stable@kernel.org Fixes: 8016e29f4362 ("ext4: fast commit recovery path") Signed-off-by: Harshad Shirwadkar Link: https://lore.kernel.org/r/20210519215920.2037527-1-harshads@google.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit d3b668b96ad3192c0581a248ae2f596cd054792a Author: Ye Bin Date: Thu May 6 22:10:42 2021 +0800 ext4: fix bug on in ext4_es_cache_extent as ext4_split_extent_at failed commit 082cd4ec240b8734a82a89ffb890216ac98fec68 upstream. We got follow bug_on when run fsstress with injecting IO fault: [130747.323114] kernel BUG at fs/ext4/extents_status.c:762! [130747.323117] Internal error: Oops - BUG: 0 [#1] SMP ...... [130747.334329] Call trace: [130747.334553] ext4_es_cache_extent+0x150/0x168 [ext4] [130747.334975] ext4_cache_extents+0x64/0xe8 [ext4] [130747.335368] ext4_find_extent+0x300/0x330 [ext4] [130747.335759] ext4_ext_map_blocks+0x74/0x1178 [ext4] [130747.336179] ext4_map_blocks+0x2f4/0x5f0 [ext4] [130747.336567] ext4_mpage_readpages+0x4a8/0x7a8 [ext4] [130747.336995] ext4_readpage+0x54/0x100 [ext4] [130747.337359] generic_file_buffered_read+0x410/0xae8 [130747.337767] generic_file_read_iter+0x114/0x190 [130747.338152] ext4_file_read_iter+0x5c/0x140 [ext4] [130747.338556] __vfs_read+0x11c/0x188 [130747.338851] vfs_read+0x94/0x150 [130747.339110] ksys_read+0x74/0xf0 This patch's modification is according to Jan Kara's suggestion in: https://patchwork.ozlabs.org/project/linux-ext4/patch/20210428085158.3728201-1-yebin10@huawei.com/ "I see. Now I understand your patch. Honestly, seeing how fragile is trying to fix extent tree after split has failed in the middle, I would probably go even further and make sure we fix the tree properly in case of ENOSPC and EDQUOT (those are easily user triggerable). Anything else indicates a HW problem or fs corruption so I'd rather leave the extent tree as is and don't try to fix it (which also means we will not create overlapping extents)." Cc: stable@kernel.org Signed-off-by: Ye Bin Reviewed-by: Jan Kara Link: https://lore.kernel.org/r/20210506141042.3298679-1-yebin10@huawei.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 01d349a481f0591230300a9171330136f9159bcd Author: Alexey Makhalov Date: Fri May 21 07:55:33 2021 +0000 ext4: fix memory leak in ext4_fill_super commit afd09b617db3786b6ef3dc43e28fe728cfea84df upstream. Buffer head references must be released before calling kill_bdev(); otherwise the buffer head (and its page referenced by b_data) will not be freed by kill_bdev, and subsequently that bh will be leaked. If blocksizes differ, sb_set_blocksize() will kill current buffers and page cache by using kill_bdev(). And then super block will be reread again but using correct blocksize this time. sb_set_blocksize() didn't fully free superblock page and buffer head, and being busy, they were not freed and instead leaked. This can easily be reproduced by calling an infinite loop of: systemctl start .mount, and systemctl stop .mount ... since systemd creates a cgroup for each slice which it mounts, and the bh leak get amplified by a dying memory cgroup that also never gets freed, and memory consumption is much more easily noticed. Fixes: ce40733ce93d ("ext4: Check for return value from sb_set_blocksize") Fixes: ac27a0ec112a ("ext4: initial copy of files from ext3") Link: https://lore.kernel.org/r/20210521075533.95732-1-amakhalov@vmware.com Signed-off-by: Alexey Makhalov Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit b2057d138f1b1141e00fdd9bee364bb8438cf223 Author: Marek Vasut Date: Mon Apr 26 12:23:21 2021 +0200 ARM: dts: imx6q-dhcom: Add PU,VDD1P1,VDD2P5 regulators commit 8967b27a6c1c19251989c7ab33c058d16e4a5f53 upstream. Per schematic, both PU and SOC regulator are supplied from LTC3676 SW1 via VDDSOC_IN rail, add the PU input. Both VDD1P1, VDD2P5 are supplied from LTC3676 SW2 via VDDHIGH_IN rail, add both inputs. While no instability or problems are currently observed, the regulators should be fully described in DT and that description should fully match the hardware, else this might lead to unforseen issues later. Fix this. Fixes: 52c7a088badd ("ARM: dts: imx6q: Add support for the DHCOM iMX6 SoM and PDK2") Reviewed-by: Fabio Estevam Signed-off-by: Marek Vasut Cc: Christoph Niedermaier Cc: Fabio Estevam Cc: Ludwig Zenz Cc: NXP Linux Team Cc: Shawn Guo Cc: stable@vger.kernel.org Reviewed-by: Christoph Niedermaier Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman commit 623603e255aa00642a9d3327a652639407eb0501 Author: Michal Vokáč Date: Tue Apr 13 16:45:57 2021 +0200 ARM: dts: imx6dl-yapp4: Fix RGMII connection to QCA8334 switch commit 0e4a4a08cd78efcaddbc2e4c5ed86b5a5cb8a15e upstream. The FEC does not have a PHY so it should not have a phy-handle. It is connected to the switch at RGMII level so we need a fixed-link sub-node on both ends. This was not a problem until the qca8k.c driver was converted to PHYLINK by commit b3591c2a3661 ("net: dsa: qca8k: Switch to PHYLINK instead of PHYLIB"). That commit revealed the FEC configuration was not correct. Fixes: 87489ec3a77f ("ARM: dts: imx: Add Y Soft IOTA Draco, Hydra and Ursa boards") Cc: stable@vger.kernel.org Signed-off-by: Michal Vokáč Reviewed-by: Andrew Lunn Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman commit 846848c0520f3391a2ef41c90f26ebef858971af Author: Hui Wang Date: Wed Jun 2 22:54:24 2021 +0800 ALSA: hda: update the power_state during the direct-complete commit b8b90c17602689eeaa5b219d104bbc215d1225cc upstream. The patch_realtek.c needs to check if the power_state.event equals PM_EVENT_SUSPEND, after using the direct-complete, the suspend() and resume() will be skipped if the codec is already rt_suspended, in this case, the patch_realtek.c will always get PM_EVENT_ON even the system is really resumed from S3. We could set power_state to PMSG_SUSPEND in the prepare(), if other PM functions are called before complete(), those functions will override power_state; if no other PM functions are called before complete(), we could know the suspend() and resume() are skipped since only S3 pm functions could be skipped by direct-complete, in this case set power_state to PMSG_RESUME in the complete(). This could guarantee the first time of calling hda_codec_runtime_resume() after complete() has the correct power_state. Fixes: 215a22ed31a1 ("ALSA: hda: Refactor codec PM to use direct-complete optimization") Cc: Signed-off-by: Hui Wang Link: https://lore.kernel.org/r/20210602145424.3132-1-hui.wang@canonical.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit cfbb57fcb1808d42a410339d7d81936c91abbbf5 Author: Carlos M Date: Mon May 31 22:20:26 2021 +0200 ALSA: hda: Fix for mute key LED for HP Pavilion 15-CK0xx commit 901be145a46eb79879367d853194346a549e623d upstream. For the HP Pavilion 15-CK0xx, with audio subsystem ID 0x103c:0x841c, adding a line in patch_realtek.c to apply the ALC269_FIXUP_HP_MUTE_LED_MIC3 fix activates the mute key LED. Signed-off-by: Carlos M Cc: Link: https://lore.kernel.org/r/20210531202026.35427-1-carlos.marr.pz@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 029c06103e0ad669e6bec74f26b006198041326d Author: Takashi Iwai Date: Wed Jun 2 13:38:23 2021 +0200 ALSA: timer: Fix master timer notification commit 9c1fe96bded935369f8340c2ac2e9e189f697d5d upstream. snd_timer_notify1() calls the notification to each slave for a master event, but it passes a wrong event number. It should be +10 offset, corresponding to SNDRV_TIMER_EVENT_MXXX, but it's incorrectly with +100 offset. Casually this was spotted by UBSAN check via syzkaller. Reported-by: syzbot+d102fa5b35335a7e544e@syzkaller.appspotmail.com Reviewed-by: Jaroslav Kysela Cc: Link: https://lore.kernel.org/r/000000000000e5560e05c3bd1d63@google.com Link: https://lore.kernel.org/r/20210602113823.23777-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit d11e5b96efde861e6c753c15e694f3ee34e7a513 Author: Bob Peterson Date: Tue May 18 09:12:10 2021 -0400 gfs2: fix scheduling while atomic bug in glocks commit 20265d9a67e40eafd39a8884658ca2e36f05985d upstream. Before this patch, in the unlikely event that gfs2_glock_dq encountered a withdraw, it would do a wait_on_bit to wait for its journal to be recovered, but it never released the glock's spin_lock, which caused a scheduling-while-atomic error. This patch unlocks the lockref spin_lock before waiting for recovery. Fixes: 601ef0d52e96 ("gfs2: Force withdraw to replay journals and wait for it to finish") Cc: stable@vger.kernel.org # v5.7+ Reported-by: Alexander Aring Signed-off-by: Bob Peterson Signed-off-by: Andreas Gruenbacher Signed-off-by: Greg Kroah-Hartman commit 127f25be2ff0fb3706adf4cf91a0e18c43b59885 Author: Ahelenia Ziemiańska Date: Mon Mar 8 18:42:03 2021 +0100 HID: multitouch: require Finger field to mark Win8 reports as MT commit a2353e3b26012ff43bcdf81d37a3eaddd7ecdbf3 upstream. This effectively changes collection_is_mt from contact ID in report->field to (device is Win8 => collection is finger) && contact ID in report->field Some devices erroneously report Pen for fingers, and Win8 stylus-on-touchscreen devices report contact ID, but mark the accompanying touchscreen device's collection correctly Cc: stable@vger.kernel.org Signed-off-by: Ahelenia Ziemiańska Acked-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit b5d013c4c76b276890135b5d32803c4c63924b77 Author: Johan Hovold Date: Mon May 17 12:04:30 2021 +0200 HID: magicmouse: fix NULL-deref on disconnect commit 4b4f6cecca446abcb686c6e6c451d4f1ec1a7497 upstream. Commit 9d7b18668956 ("HID: magicmouse: add support for Apple Magic Trackpad 2") added a sanity check for an Apple trackpad but returned success instead of -ENODEV when the check failed. This means that the remove callback will dereference the never-initialised driver data pointer when the driver is later unbound (e.g. on USB disconnect). Reported-by: syzbot+ee6f6e2e68886ca256a8@syzkaller.appspotmail.com Fixes: 9d7b18668956 ("HID: magicmouse: add support for Apple Magic Trackpad 2") Cc: stable@vger.kernel.org # 4.20 Cc: Claudio Mettler Cc: Marek Wyborski Cc: Sean O'Brien Signed-off-by: Johan Hovold Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit a5e554f789815105ac5866f8fb133ab6a1566286 Author: Johnny Chuang Date: Tue Apr 13 09:20:50 2021 +0800 HID: i2c-hid: Skip ELAN power-on command after reset commit ca66a6770bd9d6d99e469debd1c7363ac455daf9 upstream. For ELAN touchscreen, we found our boot code of IC was not flexible enough to receive and handle this command. Once the FW main code of our controller is crashed for some reason, the controller could not be enumerated successfully to be recognized by the system host. therefore, it lost touch functionality. Add quirk for skip send power-on command after reset. It will impact to ELAN touchscreen and touchpad on HID over I2C projects. Fixes: 43b7029f475e ("HID: i2c-hid: Send power-on command after reset"). Cc: stable@vger.kernel.org Signed-off-by: Johnny Chuang Reviewed-by: Harry Cutts Reviewed-by: Douglas Anderson Tested-by: Douglas Anderson Signed-off-by: Benjamin Tissoires Signed-off-by: Greg Kroah-Hartman commit 46403c1f80b0d3f937ff9c4f5edc63bb64bc5051 Author: Pavel Skripkin Date: Thu Jun 3 19:39:35 2021 +0300 net: caif: fix memory leak in cfusbl_device_notify commit 7f5d86669fa4d485523ddb1d212e0a2d90bd62bb upstream. In case of caif_enroll_dev() fail, allocated link_support won't be assigned to the corresponding structure. So simply free allocated pointer in case of error. Fixes: 7ad65bf68d70 ("caif: Add support for CAIF over CDC NCM USB interface") Cc: stable@vger.kernel.org Signed-off-by: Pavel Skripkin Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit af2806345a37313f01b1c9f15e046745b8ee2daa Author: Pavel Skripkin Date: Thu Jun 3 19:39:11 2021 +0300 net: caif: fix memory leak in caif_device_notify commit b53558a950a89824938e9811eddfc8efcd94e1bb upstream. In case of caif_enroll_dev() fail, allocated link_support won't be assigned to the corresponding structure. So simply free allocated pointer in case of error Fixes: 7c18d2205ea7 ("caif: Restructure how link caif link layer enroll") Cc: stable@vger.kernel.org Reported-and-tested-by: syzbot+7ec324747ce876a29db6@syzkaller.appspotmail.com Signed-off-by: Pavel Skripkin Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit d6db727457dd29938524f04b301c83ac67cccb87 Author: Pavel Skripkin Date: Thu Jun 3 19:38:51 2021 +0300 net: caif: add proper error handling commit a2805dca5107d5603f4bbc027e81e20d93476e96 upstream. caif_enroll_dev() can fail in some cases. Ingnoring these cases can lead to memory leak due to not assigning link_support pointer to anywhere. Fixes: 7c18d2205ea7 ("caif: Restructure how link caif link layer enroll") Cc: stable@vger.kernel.org Signed-off-by: Pavel Skripkin Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit dac53568c6ac4c4678e6c2f4e66314b99ec85f03 Author: Pavel Skripkin Date: Thu Jun 3 19:38:12 2021 +0300 net: caif: added cfserl_release function commit bce130e7f392ddde8cfcb09927808ebd5f9c8669 upstream. Added cfserl_release() function. Cc: stable@vger.kernel.org Signed-off-by: Pavel Skripkin Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit df3b45f6d1ce605120750b983fc4448e3769619a Author: Jason A. Donenfeld Date: Fri Jun 4 17:17:38 2021 +0200 wireguard: allowedips: free empty intermediate nodes when removing single node commit bf7b042dc62a31f66d3a41dd4dfc7806f267b307 upstream. When removing single nodes, it's possible that that node's parent is an empty intermediate node, in which case, it too should be removed. Otherwise the trie fills up and never is fully emptied, leading to gradual memory leaks over time for tries that are modified often. There was originally code to do this, but was removed during refactoring in 2016 and never reworked. Now that we have proper parent pointers from the previous commits, we can implement this properly. In order to reduce branching and expensive comparisons, we want to keep the double pointer for parent assignment (which lets us easily chain up to the root), but we still need to actually get the parent's base address. So encode the bit number into the last two bits of the pointer, and pack and unpack it as needed. This is a little bit clumsy but is the fastest and less memory wasteful of the compromises. Note that we align the root struct here to a minimum of 4, because it's embedded into a larger struct, and we're relying on having the bottom two bits for our flag, which would only be 16-bit aligned on m68k. The existing macro-based helpers were a bit unwieldy for adding the bit packing to, so this commit replaces them with safer and clearer ordinary functions. We add a test to the randomized/fuzzer part of the selftests, to free the randomized tries by-peer, refuzz it, and repeat, until it's supposed to be empty, and then then see if that actually resulted in the whole thing being emptied. That combined with kmemcheck should hopefully make sure this commit is doing what it should. Along the way this resulted in various other cleanups of the tests and fixes for recent graphviz. Fixes: e7096c131e51 ("net: WireGuard secure network tunnel") Cc: stable@vger.kernel.org Signed-off-by: Jason A. Donenfeld Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit c5155c741a484e036e7997420559431a951f2106 Author: Jason A. Donenfeld Date: Fri Jun 4 17:17:37 2021 +0200 wireguard: allowedips: allocate nodes in kmem_cache commit dc680de28ca849dfe589dc15ac56d22505f0ef11 upstream. The previous commit moved from O(n) to O(1) for removal, but in the process introduced an additional pointer member to a struct that increased the size from 60 to 68 bytes, putting nodes in the 128-byte slab. With deployed systems having as many as 2 million nodes, this represents a significant doubling in memory usage (128 MiB -> 256 MiB). Fix this by using our own kmem_cache, that's sized exactly right. This also makes wireguard's memory usage more transparent in tools like slabtop and /proc/slabinfo. Fixes: e7096c131e51 ("net: WireGuard secure network tunnel") Suggested-by: Arnd Bergmann Suggested-by: Matthew Wilcox Cc: stable@vger.kernel.org Signed-off-by: Jason A. Donenfeld Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 70a9a71ab3e55903ca171c22bb5432748dda9e7b Author: Jason A. Donenfeld Date: Fri Jun 4 17:17:36 2021 +0200 wireguard: allowedips: remove nodes in O(1) commit f634f418c227c912e7ea95a3299efdc9b10e4022 upstream. Previously, deleting peers would require traversing the entire trie in order to rebalance nodes and safely free them. This meant that removing 1000 peers from a trie with a half million nodes would take an extremely long time, during which we're holding the rtnl lock. Large-scale users were reporting 200ms latencies added to the networking stack as a whole every time their userspace software would queue up significant removals. That's a serious situation. This commit fixes that by maintaining a double pointer to the parent's bit pointer for each node, and then using the already existing node list belonging to each peer to go directly to the node, fix up its pointers, and free it with RCU. This means removal is O(1) instead of O(n), and we don't use gobs of stack. The removal algorithm has the same downside as the code that it fixes: it won't collapse needlessly long runs of fillers. We can enhance that in the future if it ever becomes a problem. This commit documents that limitation with a TODO comment in code, a small but meaningful improvement over the prior situation. Currently the biggest flaw, which the next commit addresses, is that because this increases the node size on 64-bit machines from 60 bytes to 68 bytes. 60 rounds up to 64, but 68 rounds up to 128. So we wind up using twice as much memory per node, because of power-of-two allocations, which is a big bummer. We'll need to figure something out there. Fixes: e7096c131e51 ("net: WireGuard secure network tunnel") Cc: stable@vger.kernel.org Signed-off-by: Jason A. Donenfeld Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 42a667715b1e118f725de85ac748983ced2ecb5e Author: Jason A. Donenfeld Date: Fri Jun 4 17:17:35 2021 +0200 wireguard: allowedips: initialize list head in selftest commit 46cfe8eee285cde465b420637507884551f5d7ca upstream. The randomized trie tests weren't initializing the dummy peer list head, resulting in a NULL pointer dereference when used. Fix this by initializing it in the randomized trie test, just like we do for the static unit test. While we're at it, all of the other strings like this have the word "self-test", so add it to the missing place here. Fixes: e7096c131e51 ("net: WireGuard secure network tunnel") Cc: stable@vger.kernel.org Signed-off-by: Jason A. Donenfeld Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 842c21d6a0427ed035e544cc49cc3f53b0cb41e0 Author: Jason A. Donenfeld Date: Fri Jun 4 17:17:31 2021 +0200 wireguard: selftests: make sure rp_filter is disabled on vethc commit f8873d11d4121aad35024f9379e431e0c83abead upstream. Some distros may enable strict rp_filter by default, which will prevent vethc from receiving the packets with an unrouteable reverse path address. Reported-by: Hangbin Liu Fixes: e7096c131e51 ("net: WireGuard secure network tunnel") Cc: stable@vger.kernel.org Signed-off-by: Jason A. Donenfeld Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b8d72ac1f2106adb25ef3e178f373b930aee7d8c Author: Jason A. Donenfeld Date: Fri Jun 4 17:17:30 2021 +0200 wireguard: selftests: remove old conntrack kconfig value commit acf2492b51c9a3c4dfb947f4d3477a86d315150f upstream. On recent kernels, this config symbol is no longer used. Reported-by: Rui Salvaterra Fixes: e7096c131e51 ("net: WireGuard secure network tunnel") Cc: stable@vger.kernel.org Signed-off-by: Jason A. Donenfeld Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit f74da2c2546c402cd2fc4165ef54b48cce6e39cc Author: Jason A. Donenfeld Date: Fri Jun 4 17:17:33 2021 +0200 wireguard: use synchronize_net rather than synchronize_rcu commit 24b70eeeb4f46c09487f8155239ebfb1f875774a upstream. Many of the synchronization points are sometimes called under the rtnl lock, which means we should use synchronize_net rather than synchronize_rcu. Under the hood, this expands to using the expedited flavor of function in the event that rtnl is held, in order to not stall other concurrent changes. This fixes some very, very long delays when removing multiple peers at once, which would cause some operations to take several minutes. Fixes: e7096c131e51 ("net: WireGuard secure network tunnel") Cc: stable@vger.kernel.org Signed-off-by: Jason A. Donenfeld Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit d4275889ac9c9f3a4afafc3ec2a13154cdd0b632 Author: Jason A. Donenfeld Date: Fri Jun 4 17:17:34 2021 +0200 wireguard: peer: allocate in kmem_cache commit a4e9f8e3287c9eb6bf70df982870980dd3341863 upstream. With deployments having upwards of 600k peers now, this somewhat heavy structure could benefit from more fine-grained allocations. Specifically, instead of using a 2048-byte slab for a 1544-byte object, we can now use 1544-byte objects directly, thus saving almost 25% per-peer, or with 600k peers, that's a savings of 303 MiB. This also makes wireguard's memory usage more transparent in tools like slabtop and /proc/slabinfo. Fixes: 8b5553ace83c ("wireguard: queueing: get rid of per-peer ring buffers") Suggested-by: Arnd Bergmann Suggested-by: Matthew Wilcox Cc: stable@vger.kernel.org Signed-off-by: Jason A. Donenfeld Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit d64fdbaec09b4143aa1965e92d0ff8c8c84de585 Author: Jason A. Donenfeld Date: Fri Jun 4 17:17:32 2021 +0200 wireguard: do not use -O3 commit cc5060ca0285efe2728bced399a1955a7ce808b2 upstream. Apparently, various versions of gcc have O3-related miscompiles. Looking at the difference between -O2 and -O3 for gcc 11 doesn't indicate miscompiles, but the difference also doesn't seem so significant for performance that it's worth risking. Link: https://lore.kernel.org/lkml/CAHk-=wjuoGyxDhAF8SsrTkN0-YfCx7E6jUN3ikC_tn2AKWTTsA@mail.gmail.com/ Link: https://lore.kernel.org/lkml/CAHmME9otB5Wwxp7H8bR_i2uH2esEMvoBMC8uEXBMH9p0q1s6Bw@mail.gmail.com/ Reported-by: Linus Torvalds Fixes: e7096c131e51 ("net: WireGuard secure network tunnel") Cc: stable@vger.kernel.org Signed-off-by: Jason A. Donenfeld Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 74caf718cc7422a957aac381c73d798c0a999a65 Author: Lin Ma Date: Sun May 30 21:37:43 2021 +0800 Bluetooth: use correct lock to prevent UAF of hdev object commit e305509e678b3a4af2b3cfd410f409f7cdaabb52 upstream. The hci_sock_dev_event() function will cleanup the hdev object for sockets even if this object may still be in used within the hci_sock_bound_ioctl() function, result in UAF vulnerability. This patch replace the BH context lock to serialize these affairs and prevent the race condition. Signed-off-by: Lin Ma Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman commit 3795007c8dfc8bca176529bfeceb17c6f4ef7e44 Author: Lin Ma Date: Tue May 25 14:39:02 2021 +0200 Bluetooth: fix the erroneous flush_work() order commit 6a137caec23aeb9e036cdfd8a46dd8a366460e5d upstream. In the cleanup routine for failed initialization of HCI device, the flush_work(&hdev->rx_work) need to be finished before the flush_work(&hdev->cmd_work). Otherwise, the hci_rx_work() can possibly invoke new cmd_work and cause a bug, like double free, in late processings. This was assigned CVE-2021-3564. This patch reorder the flush_work() to fix this bug. Cc: Marcel Holtmann Cc: Johan Hedberg Cc: Luiz Augusto von Dentz Cc: "David S. Miller" Cc: Jakub Kicinski Cc: linux-bluetooth@vger.kernel.org Cc: netdev@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Lin Ma Signed-off-by: Hao Xiong Cc: stable Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman commit 7fa8ee00b5fab915856d03b50113be8fef1337dc Author: James Zhu Date: Wed May 19 12:08:20 2021 -0400 drm/amdgpu/jpeg3: add cancel_delayed_work_sync before power gate [ Upstream commit 20ebbfd22f8115a1e4f60d3d289f66be4d47f1ec ] Add cancel_delayed_work_sync before set power gating state to avoid race condition issue when power gating. Signed-off-by: James Zhu Reviewed-by: Leo Liu Acked-by: Christian König Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit c12946548001bf1591426ebfec56b5d859de6262 Author: James Zhu Date: Wed May 19 12:04:38 2021 -0400 drm/amdgpu/jpeg2.5: add cancel_delayed_work_sync before power gate [ Upstream commit 23f10a571da5eaa63b7845d16e2f49837e841ab9 ] Add cancel_delayed_work_sync before set power gating state to avoid race condition issue when power gating. Signed-off-by: James Zhu Reviewed-by: Leo Liu Acked-by: Christian König Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 58f4d45d8d4d391f60b6f0db6308df1994a265b3 Author: James Zhu Date: Mon May 17 16:39:17 2021 -0400 drm/amdgpu/vcn3: add cancel_delayed_work_sync before power gate [ Upstream commit 4a62542ae064e3b645d6bbf2295a6c05136956c6 ] Add cancel_delayed_work_sync before set power gating state to avoid race condition issue when power gating. Signed-off-by: James Zhu Reviewed-by: Leo Liu Acked-by: Christian König Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit ec72cb50c1db39816eae7296686449bba8ca0b2e Author: Pavel Begunkov Date: Sun Feb 28 22:35:15 2021 +0000 io_uring: use better types for cflags [ Upstream commit 8c3f9cd1603d0e4af6c50ebc6d974ab7bdd03cf4 ] __io_cqring_fill_event() takes cflags as long to squeeze it into u32 in an CQE, awhile all users pass int or unsigned. Replace it with unsigned int and store it as u32 in struct io_completion to match CQE. Signed-off-by: Pavel Begunkov Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 0b2a990e5d2f76d020cb840c456e6ec5f0c27530 Author: Pavel Begunkov Date: Fri May 7 21:06:38 2021 +0100 io_uring: fix link timeout refs [ Upstream commit a298232ee6b9a1d5d732aa497ff8be0d45b5bd82 ] WARNING: CPU: 0 PID: 10242 at lib/refcount.c:28 refcount_warn_saturate+0x15b/0x1a0 lib/refcount.c:28 RIP: 0010:refcount_warn_saturate+0x15b/0x1a0 lib/refcount.c:28 Call Trace: __refcount_sub_and_test include/linux/refcount.h:283 [inline] __refcount_dec_and_test include/linux/refcount.h:315 [inline] refcount_dec_and_test include/linux/refcount.h:333 [inline] io_put_req fs/io_uring.c:2140 [inline] io_queue_linked_timeout fs/io_uring.c:6300 [inline] __io_queue_sqe+0xbef/0xec0 fs/io_uring.c:6354 io_submit_sqe fs/io_uring.c:6534 [inline] io_submit_sqes+0x2bbd/0x7c50 fs/io_uring.c:6660 __do_sys_io_uring_enter fs/io_uring.c:9240 [inline] __se_sys_io_uring_enter+0x256/0x1d60 fs/io_uring.c:9182 io_link_timeout_fn() should put only one reference of the linked timeout request, however in case of racing with the master request's completion first io_req_complete() puts one and then io_put_req_deferred() is called. Cc: stable@vger.kernel.org # 5.12+ Fixes: 9ae1f8dd372e0 ("io_uring: fix inconsistent lock state") Reported-by: syzbot+a2910119328ce8e7996f@syzkaller.appspotmail.com Signed-off-by: Pavel Begunkov Link: https://lore.kernel.org/r/ff51018ff29de5ffa76f09273ef48cb24c720368.1620417627.git.asml.silence@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 3c23e23c7ad9844a645f4e2bd8ec34a0a2ee5514 Author: Jisheng Zhang Date: Fri Apr 2 21:29:08 2021 +0800 riscv: vdso: fix and clean-up Makefile [ Upstream commit 772d7891e8b3b0baae7bb88a294d61fd07ba6d15 ] Running "make" on an already compiled kernel tree will rebuild the kernel even without any modifications: CALL linux/scripts/checksyscalls.sh CALL linux/scripts/atomic/check-atomics.sh CHK include/generated/compile.h SO2S arch/riscv/kernel/vdso/vdso-syms.S AS arch/riscv/kernel/vdso/vdso-syms.o AR arch/riscv/kernel/vdso/built-in.a AR arch/riscv/kernel/built-in.a AR arch/riscv/built-in.a GEN .version CHK include/generated/compile.h UPD include/generated/compile.h CC init/version.o AR init/built-in.a LD vmlinux.o The reason is "Any target that utilizes if_changed must be listed in $(targets), otherwise the command line check will fail, and the target will always be built" as explained by Documentation/kbuild/makefiles.rst Fix this build bug by adding vdso-syms.S to $(targets) At the same time, there are two trivial clean up modifications: - the vdso-dummy.o is not needed any more after so remove it. - vdso.lds is a generated file, so it should be prefixed with $(obj)/ instead of $(src)/ Fixes: c2c81bb2f691 ("RISC-V: Fix the VDSO symbol generaton for binutils-2.35+") Cc: stable@vger.kernel.org Signed-off-by: Jisheng Zhang Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin commit 282c9eeda6c2c2f6932aef0fb85b352b6210b9e6 Author: Johan Hovold Date: Fri Apr 16 16:05:56 2021 +0200 serial: stm32: fix threaded interrupt handling [ Upstream commit e359b4411c2836cf87c8776682d1b594635570de ] When DMA is enabled the receive handler runs in a threaded handler, but the primary handler up until very recently neither disabled interrupts in the device or used IRQF_ONESHOT. This would lead to a deadlock if an interrupt comes in while the threaded receive handler is running under the port lock. Commit ad7676812437 ("serial: stm32: fix a deadlock condition with wakeup event") claimed to fix an unrelated deadlock, but unfortunately also disabled interrupts in the threaded handler. While this prevents the deadlock mentioned in the previous paragraph it also defeats the purpose of using a threaded handler in the first place. Fix this by making the interrupt one-shot and not disabling interrupts in the threaded handler. Note that (receive) DMA must not be used for a console port as the threaded handler could be interrupted while holding the port lock, something which could lead to a deadlock in case an interrupt handler ends up calling printk. Fixes: ad7676812437 ("serial: stm32: fix a deadlock condition with wakeup event") Fixes: 3489187204eb ("serial: stm32: adding dma support") Cc: stable@vger.kernel.org # 4.9 Cc: Alexandre TORGUE Cc: Gerald Baeza Reviewed-by: Valentin Caron Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20210416140557.25177-3-johan@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit fdf1e5eec3eddef6255cbc149e85877c924458d8 Author: Hoang Le Date: Thu Apr 1 09:30:48 2021 +0700 tipc: fix unique bearer names sanity check [ Upstream commit f20a46c3044c3f75232b3d0e2d09af9b25efaf45 ] When enabling a bearer by name, we don't sanity check its name with higher slot in bearer list. This may have the effect that the name of an already enabled bearer bypasses the check. To fix the above issue, we just perform an extra checking with all existing bearers. Fixes: cb30a63384bc9 ("tipc: refactor function tipc_enable_bearer()") Cc: stable@vger.kernel.org Acked-by: Jon Maloy Signed-off-by: Hoang Le Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit e31ae45ed1d323b4409c3575299f6c203f0b3d2a Author: Hoang Le Date: Thu Mar 25 08:56:41 2021 +0700 tipc: add extack messages for bearer/media failure [ Upstream commit b83e214b2e04204f1fc674574362061492c37245 ] Add extack error messages for -EINVAL errors when enabling bearer, getting/setting properties for a media/bearer Acked-by: Jon Maloy Signed-off-by: Hoang Le Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 0d83aec6e0102e014eafdd453bdbc61b4d193029 Author: Tony Lindgren Date: Tue May 25 09:08:23 2021 +0300 bus: ti-sysc: Fix flakey idling of uarts and stop using swsup_sidle_act [ Upstream commit c8692ad416dcc420ce1b403596a425c8f4c2720b ] Looks like the swsup_sidle_act quirk handling is unreliable for serial ports. The serial ports just eventually stop idling until woken up and re-idled again. As the serial port not idling blocks any deeper SoC idle states, it's adds an annoying random flakeyness for power management. Let's just switch to swsup_sidle quirk instead like we already do for omap3 uarts. This means we manually idle the port instead of trying to use the hardware autoidle features when not in use. For more details on why the serial ports have been using swsup_idle_act, see commit 66dde54e978a ("ARM: OMAP2+: hwmod-data: UART IP needs software control to manage sidle modes"). It seems that the swsup_idle_act quirk handling is not enough though, and for example the TI Android kernel changed to using swsup_sidle with commit 77c34c84e1e0 ("OMAP4: HWMOD: UART1: disable smart-idle."). Fixes: b4a9a7a38917 ("bus: ti-sysc: Handle swsup idle mode quirks") Cc: Carl Philipp Klemm Cc: Ivan Jelincic Cc: Merlijn Wajer Cc: Pavel Machek Cc: Sebastian Reichel Cc: Sicelo A. Mhlongo Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit 5592731e13cc0bdc81ffd839359ce43f5c5e211e Author: Geert Uytterhoeven Date: Fri May 21 09:54:07 2021 +0200 ARM: dts: imx: emcon-avari: Fix nxp,pca8574 #gpio-cells [ Upstream commit b73eb6b3b91ff7d76cff5f8c7ab92fe0c51e3829 ] According to the DT bindings, #gpio-cells must be two. Fixes: 63e71fedc07c4ece ("ARM: dts: Add support for emtrion emCON-MX6 series") Signed-off-by: Geert Uytterhoeven Reviewed-by: Laurent Pinchart Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 67ae12a57b342e6dc5de6fae3fb7cda493abc257 Author: Fabio Estevam Date: Thu May 20 18:42:13 2021 -0300 ARM: dts: imx7d-pico: Fix the 'tuning-step' property [ Upstream commit 0e2fa4959c4f44815ce33e46e4054eeb0f346053 ] According to Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml, the correct name of the property is 'fsl,tuning-step'. Fix it accordingly. Signed-off-by: Fabio Estevam Fixes: f13f571ac8a1 ("ARM: dts: imx7d-pico: Extend peripherals support") Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit a776ea1eca2b7c69d6c036e27a4e78a41bd35517 Author: Fabio Estevam Date: Thu May 20 18:42:12 2021 -0300 ARM: dts: imx7d-meerkat96: Fix the 'tuning-step' property [ Upstream commit 7c8f0338cdacc90fdf6468adafa8e27952987f00 ] According to Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml, the correct name of the property is 'fsl,tuning-step'. Fix it accordingly. Signed-off-by: Fabio Estevam Fixes: ae7b3384b61b ("ARM: dts: Add support for 96Boards Meerkat96 board") Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 8aa4700de52d2ed132bfedc747e59f306c1071a6 Author: Michael Walle Date: Fri May 14 20:55:52 2021 +0200 arm64: dts: freescale: sl28: var4: fix RGMII clock and voltage [ Upstream commit 25201269c6ec3e9398426962ccdd55428261f7d0 ] During hardware validation it was noticed that the clock isn't continuously enabled when there is no link. This is because the 125MHz clock is derived from the internal PLL which seems to go into some kind of power-down mode every once in a while. The LS1028A expects a contiuous clock. Thus enable the PLL all the time. Also, the RGMII pad voltage is wrong. It was configured to 2.5V (that is the VDDH regulator). The correct voltage is 1.8V, i.e. the VDDIO regulator. This fix is for the freescale/fsl-ls1028a-kontron-sl28-var4.dts. Fixes: 815364d0424e ("arm64: dts: freescale: add Kontron sl28 support") Signed-off-by: Michael Walle Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 4f323ce68e75b5fc8d34e408f7033f2a1477ca59 Author: Lucas Stach Date: Fri May 7 21:44:40 2021 +0200 arm64: dts: zii-ultra: fix 12V_MAIN voltage [ Upstream commit ac0cbf9d13dccfd09bebc2f8f5697b6d3ffe27c4 ] As this is a fixed regulator on the board there was no harm in the wrong voltage being specified, apart from a confusing reporting to userspace. Fixes: 4a13b3bec3b4 ("arm64: dts: imx: add Zii Ultra board support") Signed-off-by: Lucas Stach Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit a3716c19330de0f04292ff8dc3eb9af0f1b87164 Author: Michael Walle Date: Thu Apr 8 13:02:18 2021 +0200 arm64: dts: ls1028a: fix memory node [ Upstream commit dabea675faf16e8682aa478ff3ce65dd775620bc ] While enabling EDAC support for the LS1028A it was discovered that the memory node has a wrong endianness setting as well as a wrong interrupt assignment. Fix both. This was tested on a sl28 board. To force ECC errors, you can use the error injection supported by the controller in hardware (with CONFIG_EDAC_DEBUG enabled): # enable error injection $ echo 0x100 > /sys/devices/system/edac/mc/mc0/inject_ctrl # flip lowest bit of the data $ echo 0x1 > /sys/devices/system/edac/mc/mc0/inject_data_lo Fixes: 8897f3255c9c ("arm64: dts: Add support for NXP LS1028A SoC") Signed-off-by: Michael Walle Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit d551b8e857775a6ea48f365d9611fe5c470008a3 Author: Tony Lindgren Date: Tue May 18 09:47:23 2021 +0300 bus: ti-sysc: Fix am335x resume hang for usb otg module [ Upstream commit 4d7b324e231366ea772ab10df46be31273ca39af ] On am335x, suspend and resume only works once, and the system hangs if suspend is attempted again. However, turns out suspend and resume works fine multiple times if the USB OTG driver for musb controller is loaded. The issue is caused my the interconnect target module losing context during suspend, and it needs a restore on resume to be reconfigure again as debugged earlier by Dave Gerlach . There are also other modules that need a restore on resume, like gpmc as noted by Dave. So let's add a common way to restore an interconnect target module based on a quirk flag. For now, let's enable the quirk for am335x otg only to fix the suspend and resume issue. As gpmc is not causing hangs based on tests with BeagleBone, let's patch gpmc separately. For gpmc, we also need a hardware reset done before restore according to Dave. To reinit the modules, we decouple system suspend from PM runtime. We replace calls to pm_runtime_force_suspend() and pm_runtime_force_resume() with direct calls to internal functions and rely on the driver internal state. There no point trying to handle complex system suspend and resume quirks via PM runtime. This is issue should have already been noticed with commit 1819ef2e2d12 ("bus: ti-sysc: Use swsup quirks also for am335x musb") when quirk handling was added for am335x otg for swsup. But the issue went unnoticed as having musb driver loaded hides the issue, and suspend and resume works once without the driver loaded. Fixes: 1819ef2e2d12 ("bus: ti-sysc: Use swsup quirks also for am335x musb") Suggested-by: Dave Gerlach Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit 426ba49ec50b5f1c8c10fdef095b5718b673d121 Author: Jens Wiklander Date: Mon Apr 19 18:46:30 2021 +0200 optee: use export_uuid() to copy client UUID [ Upstream commit 673c7aa2436bfc857b92417f3e590a297c586dde ] Prior to this patch optee_open_session() was making assumptions about the internal format of uuid_t by casting a memory location in a parameter struct to uuid_t *. Fix this using export_uuid() to get a well defined binary representation and also add an octets field in struct optee_msg_param in order to avoid casting. Fixes: c5b4312bea5d ("tee: optee: Add support for session login client UUID generation") Suggested-by: Andy Shevchenko Signed-off-by: Jens Wiklander Signed-off-by: Sasha Levin commit d866a6e61a4de0eb13973eb8a85c780323876711 Author: Vignesh Raghavendra Date: Mon May 10 23:36:01 2021 +0530 arm64: dts: ti: j7200-main: Mark Main NAVSS as dma-coherent [ Upstream commit 52ae30f55a2a40cff549fac95de82f25403bd387 ] Traffic through main NAVSS interconnect is coherent wrt ARM caches on J7200 SoC. Add missing dma-coherent property to main_navss node. Also add dma-ranges to be consistent with mcu_navss node and with AM65/J721e main_navss and mcu_navss nodes. Fixes: d361ed88455fe ("arm64: dts: ti: Add support for J7200 SoC") Signed-off-by: Vignesh Raghavendra Reviewed-by: Peter Ujfalusi Signed-off-by: Nishanth Menon Link: https://lore.kernel.org/r/20210510180601.19458-1-vigneshr@ti.com Signed-off-by: Sasha Levin commit a1bf16616d8351a2e79400d6d19608befb2ce1dd Author: Magnus Karlsson Date: Mon May 10 11:38:51 2021 +0200 ixgbe: add correct exception tracing for XDP [ Upstream commit 8281356b1cab1cccc71412eb4cf28b99d6bb2c19 ] Add missing exception tracing to XDP when a number of different errors can occur. The support was only partial. Several errors where not logged which would confuse the user quite a lot not knowing where and why the packets disappeared. Fixes: 33fdc82f0883 ("ixgbe: add support for XDP_TX action") Fixes: d0bcacd0a130 ("ixgbe: add AF_XDP zero-copy Rx support") Reported-by: Jesper Dangaard Brouer Signed-off-by: Magnus Karlsson Tested-by: Vishakha Jambekar Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit e369db6cde11b77197382d8cea36e8bc976aaac9 Author: Magnus Karlsson Date: Wed Dec 2 16:07:23 2020 +0100 ixgbe: optimize for XDP_REDIRECT in xsk path [ Upstream commit 7d52fe2eaddfa3d7255d43c3e89ebf2748b7ea7a ] Optimize ixgbe_run_xdp_zc() for the XDP program verdict being XDP_REDIRECT in the xsk zero-copy path. This path is only used when having AF_XDP zero-copy on and in that case most packets will be directed to user space. This provides a little under 100k extra packets in throughput on my server when running l2fwd in xdpsock. Signed-off-by: Magnus Karlsson Tested-by: Vishakha Jambekar Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit ad505705bba64cf698f0fcaa26fdd644f400e57c Author: Magnus Karlsson Date: Mon May 10 11:38:50 2021 +0200 ice: add correct exception tracing for XDP [ Upstream commit 89d65df024c59988291f643b4e45d1528c51aef9 ] Add missing exception tracing to XDP when a number of different errors can occur. The support was only partial. Several errors where not logged which would confuse the user quite a lot not knowing where and why the packets disappeared. Fixes: efc2214b6047 ("ice: Add support for XDP") Fixes: 2d4238f55697 ("ice: Add support for AF_XDP") Reported-by: Jesper Dangaard Brouer Signed-off-by: Magnus Karlsson Tested-by: Kiran Bhandare Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 9e1eb428849fab331c73876be4a52bbcf884dbb0 Author: Magnus Karlsson Date: Wed Dec 2 16:07:24 2020 +0100 ice: optimize for XDP_REDIRECT in xsk path [ Upstream commit bb52073645a618ab4d93c8d932fb8faf114c55bc ] Optimize ice_run_xdp_zc() for the XDP program verdict being XDP_REDIRECT in the xsk zero-copy path. This path is only used when having AF_XDP zero-copy on and in that case most packets will be directed to user space. This provides a little over 100k extra packets in throughput on my server when running l2fwd in xdpsock. Signed-off-by: Magnus Karlsson Tested-by: George Kuruvinakunnel Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 7bd82b73d5898a0c8d219740855c823edde5ac00 Author: Maciej Fijalkowski Date: Mon Jan 18 16:13:11 2021 +0100 ice: simplify ice_run_xdp [ Upstream commit 59c97d1b51b119eace6b1e61a6f820701f5a8299 ] There's no need for 'result' variable, we can directly return the internal status based on action returned by xdp prog. Reviewed-by: Björn Töpel Signed-off-by: Maciej Fijalkowski Tested-by: Kiran Bhandare Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 274d6eeaafc7c40b0618c66ec9e0cdf2f51c2f4d Author: Magnus Karlsson Date: Mon May 10 11:38:49 2021 +0200 i40e: add correct exception tracing for XDP [ Upstream commit f6c10b48f8c8da44adaff730d8e700b6272add2b ] Add missing exception tracing to XDP when a number of different errors can occur. The support was only partial. Several errors where not logged which would confuse the user quite a lot not knowing where and why the packets disappeared. Fixes: 74608d17fe29 ("i40e: add support for XDP_TX action") Fixes: 0a714186d3c0 ("i40e: add AF_XDP zero-copy Rx support") Reported-by: Jesper Dangaard Brouer Signed-off-by: Magnus Karlsson Tested-by: Kiran Bhandare Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit fbae1a97ce342470dcf2c3f51e63faf2e8e557f0 Author: Magnus Karlsson Date: Wed Dec 2 16:07:22 2020 +0100 i40e: optimize for XDP_REDIRECT in xsk path [ Upstream commit 346497c78d15cdd5bdc3b642a895009359e5457f ] Optimize i40e_run_xdp_zc() for the XDP program verdict being XDP_REDIRECT in the xsk zero-copy path. This path is only used when having AF_XDP zero-copy on and in that case most packets will be directed to user space. This provides a little over 100k extra packets in throughput on my server when running l2fwd in xdpsock. Signed-off-by: Magnus Karlsson Tested-by: George Kuruvinakunnel Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 1958a31c035dd8981a7313acf8f91ae1886173cc Author: Rahul Lakkireddy Date: Fri Jun 4 16:48:18 2021 +0530 cxgb4: avoid link re-train during TC-MQPRIO configuration [ Upstream commit 3822d0670c9d4342794d73e0d0e615322b40438e ] When configuring TC-MQPRIO offload, only turn off netdev carrier and don't bring physical link down in hardware. Otherwise, when the physical link is brought up again after configuration, it gets re-trained and stalls ongoing traffic. Also, when firmware is no longer accessible or crashed, avoid sending FLOWC and waiting for reply that will never come. Fix following hung_task_timeout_secs trace seen in these cases. INFO: task tc:20807 blocked for more than 122 seconds. Tainted: G S 5.13.0-rc3+ #122 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:tc state:D stack:14768 pid:20807 ppid: 19366 flags:0x00000000 Call Trace: __schedule+0x27b/0x6a0 schedule+0x37/0xa0 schedule_preempt_disabled+0x5/0x10 __mutex_lock.isra.14+0x2a0/0x4a0 ? netlink_lookup+0x120/0x1a0 ? rtnl_fill_ifinfo+0x10f0/0x10f0 __netlink_dump_start+0x70/0x250 rtnetlink_rcv_msg+0x28b/0x380 ? rtnl_fill_ifinfo+0x10f0/0x10f0 ? rtnl_calcit.isra.42+0x120/0x120 netlink_rcv_skb+0x4b/0xf0 netlink_unicast+0x1a0/0x280 netlink_sendmsg+0x216/0x440 sock_sendmsg+0x56/0x60 __sys_sendto+0xe9/0x150 ? handle_mm_fault+0x6d/0x1b0 ? do_user_addr_fault+0x1c5/0x620 __x64_sys_sendto+0x1f/0x30 do_syscall_64+0x3c/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f7f73218321 RSP: 002b:00007ffd19626208 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 000055b7c0a8b240 RCX: 00007f7f73218321 RDX: 0000000000000028 RSI: 00007ffd19626210 RDI: 0000000000000003 RBP: 000055b7c08680ff R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 000055b7c085f5f6 R13: 000055b7c085f60a R14: 00007ffd19636470 R15: 00007ffd196262a0 Fixes: b1396c2bd675 ("cxgb4: parse and configure TC-MQPRIO offload") Signed-off-by: Rahul Lakkireddy Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 21d494d4446b020e69e7b22fa6ed9274db1f175c Author: Roja Rani Yarubandi Date: Tue May 25 18:40:50 2021 +0530 i2c: qcom-geni: Add shutdown callback for i2c [ Upstream commit 9f78c607600ce4f2a952560de26534715236f612 ] If the hardware is still accessing memory after SMMU translation is disabled (as part of smmu shutdown callback), then the IOVAs (I/O virtual address) which it was using will go on the bus as the physical addresses which will result in unknown crashes like NoC/interconnect errors. So, implement shutdown callback for i2c driver to suspend the bus during system "reboot" or "shutdown". Fixes: 37692de5d523 ("i2c: i2c-qcom-geni: Add bus driver for the Qualcomm GENI I2C controller") Signed-off-by: Roja Rani Yarubandi Reviewed-by: Stephen Boyd Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit c4b796f20c9581ed8502e42be3d5bde59469143d Author: Dave Ertman Date: Wed May 5 14:17:59 2021 -0700 ice: Allow all LLDP packets from PF to Tx [ Upstream commit f9f83202b7263ac371d616d6894a2c9ed79158ef ] Currently in the ice driver, the check whether to allow a LLDP packet to egress the interface from the PF_VSI is being based on the SKB's priority field. It checks to see if the packets priority is equal to TC_PRIO_CONTROL. Injected LLDP packets do not always meet this condition. SCAPY defaults to a sk_buff->protocol value of ETH_P_ALL (0x0003) and does not set the priority field. There will be other injection methods (even ones used by end users) that will not correctly configure the socket so that SKB fields are correctly populated. Then ethernet header has to have to correct value for the protocol though. Add a check to also allow packets whose ethhdr->h_proto matches ETH_P_LLDP (0x88CC). Fixes: 0c3a6101ff2d ("ice: Allow egress control packets from PF_VSI") Signed-off-by: Dave Ertman Tested-by: Tony Brelinski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 68db78345f7383dcd3ffd3c20f379f2f8e1b445f Author: Paul Greenwalt Date: Wed May 5 14:17:58 2021 -0700 ice: report supported and advertised autoneg using PHY capabilities [ Upstream commit 5cd349c349d6ec52862e550d3576893d35ab8ac2 ] Ethtool incorrectly reported supported and advertised auto-negotiation settings for a backplane PHY image which did not support auto-negotiation. This can occur when using media or PHY type for reporting ethtool supported and advertised auto-negotiation settings. Remove setting supported and advertised auto-negotiation settings based on PHY type in ice_phy_type_to_ethtool(), and MAC type in ice_get_link_ksettings(). Ethtool supported and advertised auto-negotiation settings should be based on the PHY image using the AQ command get PHY capabilities with media. Add setting supported and advertised auto-negotiation settings based get PHY capabilities with media in ice_get_link_ksettings(). Fixes: 48cb27f2fd18 ("ice: Implement handlers for ethtool PHY/link operations") Signed-off-by: Paul Greenwalt Tested-by: Tony Brelinski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 8726b9e81be7b30d7a9f4f1e3426352b37e6129d Author: Haiyue Wang Date: Fri Feb 26 13:19:31 2021 -0800 ice: handle the VF VSI rebuild failure [ Upstream commit c7ee6ce1cf60b7fcdbdd2354d377d00bae3fa2d2 ] VSI rebuild can be failed for LAN queue config, then the VF's VSI will be NULL, the VF reset should be stopped with the VF entering into the disable state. Fixes: 12bb018c538c ("ice: Refactor VF reset") Signed-off-by: Haiyue Wang Tested-by: Konrad Jankowski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit a79883ce1e9f7ccc1616c7659332db1266a9d434 Author: Brett Creeley Date: Fri Feb 26 13:19:21 2021 -0800 ice: Fix VFR issues for AVF drivers that expect ATQLEN cleared [ Upstream commit 8679f07a9922068b9b6be81b632f52cac45d1b91 ] Some AVF drivers expect the VF_MBX_ATQLEN register to be cleared for any type of VFR/VFLR. Fix this by clearing the VF_MBX_ATQLEN register at the same time as VF_MBX_ARQLEN. Fixes: 82ba01282cf8 ("ice: clear VF ARQLEN register on reset") Signed-off-by: Brett Creeley Tested-by: Konrad Jankowski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit b94580b055b8a3e90f47dc2f8c7192455306d655 Author: Brett Creeley Date: Fri Feb 26 13:19:20 2021 -0800 ice: Fix allowing VF to request more/less queues via virtchnl [ Upstream commit f0457690af56673cb0c47af6e25430389a149225 ] Commit 12bb018c538c ("ice: Refactor VF reset") caused a regression that removes the ability for a VF to request a different amount of queues via VIRTCHNL_OP_REQUEST_QUEUES. This prevents VF drivers to either increase or decrease the number of queue pairs they are allocated. Fix this by using the variable vf->num_req_qs when determining the vf->num_vf_qs during VF VSI creation. Fixes: 12bb018c538c ("ice: Refactor VF reset") Signed-off-by: Brett Creeley Tested-by: Konrad Jankowski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 09870235827451409ff546b073d754a19fd17e2e Author: Coco Li Date: Thu Jun 3 07:32:58 2021 +0000 ipv6: Fix KASAN: slab-out-of-bounds Read in fib6_nh_flush_exceptions [ Upstream commit 821bbf79fe46a8b1d18aa456e8ed0a3c208c3754 ] Reported by syzbot: HEAD commit: 90c911ad Merge tag 'fixes' of git://git.kernel.org/pub/scm.. git tree: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master dashboard link: https://syzkaller.appspot.com/bug?extid=123aa35098fd3c000eb7 compiler: Debian clang version 11.0.1-2 ================================================================== BUG: KASAN: slab-out-of-bounds in fib6_nh_get_excptn_bucket net/ipv6/route.c:1604 [inline] BUG: KASAN: slab-out-of-bounds in fib6_nh_flush_exceptions+0xbd/0x360 net/ipv6/route.c:1732 Read of size 8 at addr ffff8880145c78f8 by task syz-executor.4/17760 CPU: 0 PID: 17760 Comm: syz-executor.4 Not tainted 5.12.0-rc8-syzkaller #0 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x202/0x31e lib/dump_stack.c:120 print_address_description+0x5f/0x3b0 mm/kasan/report.c:232 __kasan_report mm/kasan/report.c:399 [inline] kasan_report+0x15c/0x200 mm/kasan/report.c:416 fib6_nh_get_excptn_bucket net/ipv6/route.c:1604 [inline] fib6_nh_flush_exceptions+0xbd/0x360 net/ipv6/route.c:1732 fib6_nh_release+0x9a/0x430 net/ipv6/route.c:3536 fib6_info_destroy_rcu+0xcb/0x1c0 net/ipv6/ip6_fib.c:174 rcu_do_batch kernel/rcu/tree.c:2559 [inline] rcu_core+0x8f6/0x1450 kernel/rcu/tree.c:2794 __do_softirq+0x372/0x7a6 kernel/softirq.c:345 invoke_softirq kernel/softirq.c:221 [inline] __irq_exit_rcu+0x22c/0x260 kernel/softirq.c:422 irq_exit_rcu+0x5/0x20 kernel/softirq.c:434 sysvec_apic_timer_interrupt+0x91/0xb0 arch/x86/kernel/apic/apic.c:1100 asm_sysvec_apic_timer_interrupt+0x12/0x20 arch/x86/include/asm/idtentry.h:632 RIP: 0010:lock_acquire+0x1f6/0x720 kernel/locking/lockdep.c:5515 Code: f6 84 24 a1 00 00 00 02 0f 85 8d 02 00 00 f7 c3 00 02 00 00 49 bd 00 00 00 00 00 fc ff df 74 01 fb 48 c7 44 24 40 0e 36 e0 45 <4b> c7 44 3d 00 00 00 00 00 4b c7 44 3d 09 00 00 00 00 43 c7 44 3d RSP: 0018:ffffc90009e06560 EFLAGS: 00000206 RAX: 1ffff920013c0cc0 RBX: 0000000000000246 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc90009e066e0 R08: dffffc0000000000 R09: fffffbfff1f992b1 R10: fffffbfff1f992b1 R11: 0000000000000000 R12: 0000000000000000 R13: dffffc0000000000 R14: 0000000000000000 R15: 1ffff920013c0cb4 rcu_lock_acquire+0x2a/0x30 include/linux/rcupdate.h:267 rcu_read_lock include/linux/rcupdate.h:656 [inline] ext4_get_group_info+0xea/0x340 fs/ext4/ext4.h:3231 ext4_mb_prefetch+0x123/0x5d0 fs/ext4/mballoc.c:2212 ext4_mb_regular_allocator+0x8a5/0x28f0 fs/ext4/mballoc.c:2379 ext4_mb_new_blocks+0xc6e/0x24f0 fs/ext4/mballoc.c:4982 ext4_ext_map_blocks+0x2be3/0x7210 fs/ext4/extents.c:4238 ext4_map_blocks+0xab3/0x1cb0 fs/ext4/inode.c:638 ext4_getblk+0x187/0x6c0 fs/ext4/inode.c:848 ext4_bread+0x2a/0x1c0 fs/ext4/inode.c:900 ext4_append+0x1a4/0x360 fs/ext4/namei.c:67 ext4_init_new_dir+0x337/0xa10 fs/ext4/namei.c:2768 ext4_mkdir+0x4b8/0xc00 fs/ext4/namei.c:2814 vfs_mkdir+0x45b/0x640 fs/namei.c:3819 ovl_do_mkdir fs/overlayfs/overlayfs.h:161 [inline] ovl_mkdir_real+0x53/0x1a0 fs/overlayfs/dir.c:146 ovl_create_real+0x280/0x490 fs/overlayfs/dir.c:193 ovl_workdir_create+0x425/0x600 fs/overlayfs/super.c:788 ovl_make_workdir+0xed/0x1140 fs/overlayfs/super.c:1355 ovl_get_workdir fs/overlayfs/super.c:1492 [inline] ovl_fill_super+0x39ee/0x5370 fs/overlayfs/super.c:2035 mount_nodev+0x52/0xe0 fs/super.c:1413 legacy_get_tree+0xea/0x180 fs/fs_context.c:592 vfs_get_tree+0x86/0x270 fs/super.c:1497 do_new_mount fs/namespace.c:2903 [inline] path_mount+0x196f/0x2be0 fs/namespace.c:3233 do_mount fs/namespace.c:3246 [inline] __do_sys_mount fs/namespace.c:3454 [inline] __se_sys_mount+0x2f9/0x3b0 fs/namespace.c:3431 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x4665f9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f68f2b87188 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5 RAX: ffffffffffffffda RBX: 000000000056bf60 RCX: 00000000004665f9 RDX: 00000000200000c0 RSI: 0000000020000000 RDI: 000000000040000a RBP: 00000000004bfbb9 R08: 0000000020000100 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 000000000056bf60 R13: 00007ffe19002dff R14: 00007f68f2b87300 R15: 0000000000022000 Allocated by task 17768: kasan_save_stack mm/kasan/common.c:38 [inline] kasan_set_track mm/kasan/common.c:46 [inline] set_alloc_info mm/kasan/common.c:427 [inline] ____kasan_kmalloc+0xc2/0xf0 mm/kasan/common.c:506 kasan_kmalloc include/linux/kasan.h:233 [inline] __kmalloc+0xb4/0x380 mm/slub.c:4055 kmalloc include/linux/slab.h:559 [inline] kzalloc include/linux/slab.h:684 [inline] fib6_info_alloc+0x2c/0xd0 net/ipv6/ip6_fib.c:154 ip6_route_info_create+0x55d/0x1a10 net/ipv6/route.c:3638 ip6_route_add+0x22/0x120 net/ipv6/route.c:3728 inet6_rtm_newroute+0x2cd/0x2260 net/ipv6/route.c:5352 rtnetlink_rcv_msg+0xb34/0xe70 net/core/rtnetlink.c:5553 netlink_rcv_skb+0x1f0/0x460 net/netlink/af_netlink.c:2502 netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline] netlink_unicast+0x7de/0x9b0 net/netlink/af_netlink.c:1338 netlink_sendmsg+0xaa6/0xe90 net/netlink/af_netlink.c:1927 sock_sendmsg_nosec net/socket.c:654 [inline] sock_sendmsg net/socket.c:674 [inline] ____sys_sendmsg+0x5a2/0x900 net/socket.c:2350 ___sys_sendmsg net/socket.c:2404 [inline] __sys_sendmsg+0x319/0x400 net/socket.c:2433 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xae Last potentially related work creation: kasan_save_stack+0x27/0x50 mm/kasan/common.c:38 kasan_record_aux_stack+0xee/0x120 mm/kasan/generic.c:345 __call_rcu kernel/rcu/tree.c:3039 [inline] call_rcu+0x1b1/0xa30 kernel/rcu/tree.c:3114 fib6_info_release include/net/ip6_fib.h:337 [inline] ip6_route_info_create+0x10c4/0x1a10 net/ipv6/route.c:3718 ip6_route_add+0x22/0x120 net/ipv6/route.c:3728 inet6_rtm_newroute+0x2cd/0x2260 net/ipv6/route.c:5352 rtnetlink_rcv_msg+0xb34/0xe70 net/core/rtnetlink.c:5553 netlink_rcv_skb+0x1f0/0x460 net/netlink/af_netlink.c:2502 netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline] netlink_unicast+0x7de/0x9b0 net/netlink/af_netlink.c:1338 netlink_sendmsg+0xaa6/0xe90 net/netlink/af_netlink.c:1927 sock_sendmsg_nosec net/socket.c:654 [inline] sock_sendmsg net/socket.c:674 [inline] ____sys_sendmsg+0x5a2/0x900 net/socket.c:2350 ___sys_sendmsg net/socket.c:2404 [inline] __sys_sendmsg+0x319/0x400 net/socket.c:2433 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xae Second to last potentially related work creation: kasan_save_stack+0x27/0x50 mm/kasan/common.c:38 kasan_record_aux_stack+0xee/0x120 mm/kasan/generic.c:345 insert_work+0x54/0x400 kernel/workqueue.c:1331 __queue_work+0x981/0xcc0 kernel/workqueue.c:1497 queue_work_on+0x111/0x200 kernel/workqueue.c:1524 queue_work include/linux/workqueue.h:507 [inline] call_usermodehelper_exec+0x283/0x470 kernel/umh.c:433 kobject_uevent_env+0x1349/0x1730 lib/kobject_uevent.c:617 kvm_uevent_notify_change+0x309/0x3b0 arch/x86/kvm/../../../virt/kvm/kvm_main.c:4809 kvm_destroy_vm arch/x86/kvm/../../../virt/kvm/kvm_main.c:877 [inline] kvm_put_kvm+0x9c/0xd10 arch/x86/kvm/../../../virt/kvm/kvm_main.c:920 kvm_vcpu_release+0x53/0x60 arch/x86/kvm/../../../virt/kvm/kvm_main.c:3120 __fput+0x352/0x7b0 fs/file_table.c:280 task_work_run+0x146/0x1c0 kernel/task_work.c:140 tracehook_notify_resume include/linux/tracehook.h:189 [inline] exit_to_user_mode_loop kernel/entry/common.c:174 [inline] exit_to_user_mode_prepare+0x10b/0x1e0 kernel/entry/common.c:208 __syscall_exit_to_user_mode_work kernel/entry/common.c:290 [inline] syscall_exit_to_user_mode+0x26/0x70 kernel/entry/common.c:301 entry_SYSCALL_64_after_hwframe+0x44/0xae The buggy address belongs to the object at ffff8880145c7800 which belongs to the cache kmalloc-192 of size 192 The buggy address is located 56 bytes to the right of 192-byte region [ffff8880145c7800, ffff8880145c78c0) The buggy address belongs to the page: page:ffffea00005171c0 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x145c7 flags: 0xfff00000000200(slab) raw: 00fff00000000200 ffffea00006474c0 0000000200000002 ffff888010c41a00 raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8880145c7780: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ffff8880145c7800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff8880145c7880: 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc fc ^ ffff8880145c7900: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880145c7980: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ================================================================== In the ip6_route_info_create function, in the case that the nh pointer is not NULL, the fib6_nh in fib6_info has not been allocated. Therefore, when trying to free fib6_info in this error case using fib6_info_release, the function will call fib6_info_destroy_rcu, which it will access fib6_nh_release(f6i->fib6_nh); However, f6i->fib6_nh doesn't have any refcount yet given the lack of allocation causing the reported memory issue above. Therefore, releasing the empty pointer directly instead would be the solution. Fixes: f88d8ea67fbdb ("ipv6: Plumb support for nexthop object in a fib6_info") Fixes: 706ec91916462 ("ipv6: Fix nexthop refcnt leak when creating ipv6 route info") Signed-off-by: Coco Li Cc: David Ahern Reviewed-by: Eric Dumazet Reviewed-by: David Ahern Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 1dcf3d435bf6147691560b8670ff06bfaa023a69 Author: Rahul Lakkireddy Date: Wed Jun 2 19:38:59 2021 +0530 cxgb4: fix regression with HASH tc prio value update [ Upstream commit a27fb314cba8cb84cd6456a4699c3330a83c326d ] commit db43b30cd89c ("cxgb4: add ethtool n-tuple filter deletion") has moved searching for next highest priority HASH filter rule to cxgb4_flow_rule_destroy(), which searches the rhashtable before the the rule is removed from it and hence always finds at least 1 entry. Fix by removing the rule from rhashtable first before calling cxgb4_flow_rule_destroy() and hence avoid fetching stale info. Fixes: db43b30cd89c ("cxgb4: add ethtool n-tuple filter deletion") Signed-off-by: Rahul Lakkireddy Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8067da904921c1de8c1cd055170ab1f5944945e3 Author: Magnus Karlsson Date: Mon May 10 11:38:53 2021 +0200 ixgbevf: add correct exception tracing for XDP [ Upstream commit faae81420d162551b6ef2d804aafc00f4cd68e0e ] Add missing exception tracing to XDP when a number of different errors can occur. The support was only partial. Several errors where not logged which would confuse the user quite a lot not knowing where and why the packets disappeared. Fixes: 21092e9ce8b1 ("ixgbevf: Add support for XDP_TX action") Reported-by: Jesper Dangaard Brouer Signed-off-by: Magnus Karlsson Tested-by: Vishakha Jambekar Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit e0b61cda5f07b87b07841ee15066e90b6cb2ca6e Author: Magnus Karlsson Date: Mon May 10 11:38:52 2021 +0200 igb: add correct exception tracing for XDP [ Upstream commit 74431c40b9c5fa673fff83ec157a76a69efd5c72 ] Add missing exception tracing to XDP when a number of different errors can occur. The support was only partial. Several errors where not logged which would confuse the user quite a lot not knowing where and why the packets disappeared. Fixes: 9cbc948b5a20 ("igb: add XDP support") Reported-by: Jesper Dangaard Brouer Signed-off-by: Magnus Karlsson Tested-by: Vishakha Jambekar Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit e513d889625b5d8c6c2942243cd7f967455d300a Author: Wei Yongjun Date: Wed May 19 14:16:14 2021 +0000 ieee802154: fix error return code in ieee802154_llsec_getparams() [ Upstream commit 373e864cf52403b0974c2f23ca8faf9104234555 ] Fix to return negative error code -ENOBUFS from the error handling case instead of 0, as done elsewhere in this function. Fixes: 3e9c156e2c21 ("ieee802154: add netlink interfaces for llsec") Reported-by: Hulk Robot Signed-off-by: Wei Yongjun Link: https://lore.kernel.org/r/20210519141614.3040055-1-weiyongjun1@huawei.com Signed-off-by: Stefan Schmidt Signed-off-by: Sasha Levin commit 2a0ba0125c2c62566023882293face06046698a5 Author: Zhen Lei Date: Sat May 8 14:25:17 2021 +0800 ieee802154: fix error return code in ieee802154_add_iface() [ Upstream commit 79c6b8ed30e54b401c873dbad2511f2a1c525fd5 ] Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Fixes: be51da0f3e34 ("ieee802154: Stop using NLA_PUT*().") Reported-by: Hulk Robot Signed-off-by: Zhen Lei Link: https://lore.kernel.org/r/20210508062517.2574-1-thunder.leizhen@huawei.com Signed-off-by: Stefan Schmidt Signed-off-by: Sasha Levin commit ff5039ec75c83d2ed5b781dc7733420ee8c985fc Author: Daniel Borkmann Date: Fri May 28 09:16:31 2021 +0000 bpf, lockdown, audit: Fix buggy SELinux lockdown permission checks [ Upstream commit ff40e51043af63715ab413995ff46996ecf9583f ] Commit 59438b46471a ("security,lockdown,selinux: implement SELinux lockdown") added an implementation of the locked_down LSM hook to SELinux, with the aim to restrict which domains are allowed to perform operations that would breach lockdown. This is indirectly also getting audit subsystem involved to report events. The latter is problematic, as reported by Ondrej and Serhei, since it can bring down the whole system via audit: 1) The audit events that are triggered due to calls to security_locked_down() can OOM kill a machine, see below details [0]. 2) It also seems to be causing a deadlock via avc_has_perm()/slow_avc_audit() when trying to wake up kauditd, for example, when using trace_sched_switch() tracepoint, see details in [1]. Triggering this was not via some hypothetical corner case, but with existing tools like runqlat & runqslower from bcc, for example, which make use of this tracepoint. Rough call sequence goes like: rq_lock(rq) -> -------------------------+ trace_sched_switch() -> | bpf_prog_xyz() -> +-> deadlock selinux_lockdown() -> | audit_log_end() -> | wake_up_interruptible() -> | try_to_wake_up() -> | rq_lock(rq) --------------+ What's worse is that the intention of 59438b46471a to further restrict lockdown settings for specific applications in respect to the global lockdown policy is completely broken for BPF. The SELinux policy rule for the current lockdown check looks something like this: allow : lockdown { }; However, this doesn't match with the 'current' task where the security_locked_down() is executed, example: httpd does a syscall. There is a tracing program attached to the syscall which triggers a BPF program to run, which ends up doing a bpf_probe_read_kernel{,_str}() helper call. The selinux_lockdown() hook does the permission check against 'current', that is, httpd in this example. httpd has literally zero relation to this tracing program, and it would be nonsensical having to write an SELinux policy rule against httpd to let the tracing helper pass. The policy in this case needs to be against the entity that is installing the BPF program. For example, if bpftrace would generate a histogram of syscall counts by user space application: bpftrace -e 'tracepoint:raw_syscalls:sys_enter { @[comm] = count(); }' bpftrace would then go and generate a BPF program from this internally. One way of doing it [for the sake of the example] could be to call bpf_get_current_task() helper and then access current->comm via one of bpf_probe_read_kernel{,_str}() helpers. So the program itself has nothing to do with httpd or any other random app doing a syscall here. The BPF program _explicitly initiated_ the lockdown check. The allow/deny policy belongs in the context of bpftrace: meaning, you want to grant bpftrace access to use these helpers, but other tracers on the system like my_random_tracer _not_. Therefore fix all three issues at the same time by taking a completely different approach for the security_locked_down() hook, that is, move the check into the program verification phase where we actually retrieve the BPF func proto. This also reliably gets the task (current) that is trying to install the BPF tracing program, e.g. bpftrace/bcc/perf/systemtap/etc, and it also fixes the OOM since we're moving this out of the BPF helper's fast-path which can be called several millions of times per second. The check is then also in line with other security_locked_down() hooks in the system where the enforcement is performed at open/load time, for example, open_kcore() for /proc/kcore access or module_sig_check() for module signatures just to pick few random ones. What's out of scope in the fix as well as in other security_locked_down() hook locations /outside/ of BPF subsystem is that if the lockdown policy changes on the fly there is no retrospective action. This requires a different discussion, potentially complex infrastructure, and it's also not clear whether this can be solved generically. Either way, it is out of scope for a suitable stable fix which this one is targeting. Note that the breakage is specifically on 59438b46471a where it started to rely on 'current' as UAPI behavior, and _not_ earlier infrastructure such as 9d1f8be5cf42 ("bpf: Restrict bpf when kernel lockdown is in confidentiality mode"). [0] https://bugzilla.redhat.com/show_bug.cgi?id=1955585, Jakub Hrozek says: I starting seeing this with F-34. When I run a container that is traced with BPF to record the syscalls it is doing, auditd is flooded with messages like: type=AVC msg=audit(1619784520.593:282387): avc: denied { confidentiality } for pid=476 comm="auditd" lockdown_reason="use of bpf to read kernel RAM" scontext=system_u:system_r:auditd_t:s0 tcontext=system_u:system_r:auditd_t:s0 tclass=lockdown permissive=0 This seems to be leading to auditd running out of space in the backlog buffer and eventually OOMs the machine. [...] auditd running at 99% CPU presumably processing all the messages, eventually I get: Apr 30 12:20:42 fedora kernel: audit: backlog limit exceeded Apr 30 12:20:42 fedora kernel: audit: backlog limit exceeded Apr 30 12:20:42 fedora kernel: audit: audit_backlog=2152579 > audit_backlog_limit=64 Apr 30 12:20:42 fedora kernel: audit: audit_backlog=2152626 > audit_backlog_limit=64 Apr 30 12:20:42 fedora kernel: audit: audit_backlog=2152694 > audit_backlog_limit=64 Apr 30 12:20:42 fedora kernel: audit: audit_lost=6878426 audit_rate_limit=0 audit_backlog_limit=64 Apr 30 12:20:45 fedora kernel: oci-seccomp-bpf invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=-1000 Apr 30 12:20:45 fedora kernel: CPU: 0 PID: 13284 Comm: oci-seccomp-bpf Not tainted 5.11.12-300.fc34.x86_64 #1 Apr 30 12:20:45 fedora kernel: Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-2.fc32 04/01/2014 [...] [1] https://lore.kernel.org/linux-audit/CANYvDQN7H5tVp47fbYcRasv4XF07eUbsDwT_eDCHXJUj43J7jQ@mail.gmail.com/, Serhei Makarov says: Upstream kernel 5.11.0-rc7 and later was found to deadlock during a bpf_probe_read_compat() call within a sched_switch tracepoint. The problem is reproducible with the reg_alloc3 testcase from SystemTap's BPF backend testsuite on x86_64 as well as the runqlat, runqslower tools from bcc on ppc64le. Example stack trace: [...] [ 730.868702] stack backtrace: [ 730.869590] CPU: 1 PID: 701 Comm: in:imjournal Not tainted, 5.12.0-0.rc2.20210309git144c79ef3353.166.fc35.x86_64 #1 [ 730.871605] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014 [ 730.873278] Call Trace: [ 730.873770] dump_stack+0x7f/0xa1 [ 730.874433] check_noncircular+0xdf/0x100 [ 730.875232] __lock_acquire+0x1202/0x1e10 [ 730.876031] ? __lock_acquire+0xfc0/0x1e10 [ 730.876844] lock_acquire+0xc2/0x3a0 [ 730.877551] ? __wake_up_common_lock+0x52/0x90 [ 730.878434] ? lock_acquire+0xc2/0x3a0 [ 730.879186] ? lock_is_held_type+0xa7/0x120 [ 730.880044] ? skb_queue_tail+0x1b/0x50 [ 730.880800] _raw_spin_lock_irqsave+0x4d/0x90 [ 730.881656] ? __wake_up_common_lock+0x52/0x90 [ 730.882532] __wake_up_common_lock+0x52/0x90 [ 730.883375] audit_log_end+0x5b/0x100 [ 730.884104] slow_avc_audit+0x69/0x90 [ 730.884836] avc_has_perm+0x8b/0xb0 [ 730.885532] selinux_lockdown+0xa5/0xd0 [ 730.886297] security_locked_down+0x20/0x40 [ 730.887133] bpf_probe_read_compat+0x66/0xd0 [ 730.887983] bpf_prog_250599c5469ac7b5+0x10f/0x820 [ 730.888917] trace_call_bpf+0xe9/0x240 [ 730.889672] perf_trace_run_bpf_submit+0x4d/0xc0 [ 730.890579] perf_trace_sched_switch+0x142/0x180 [ 730.891485] ? __schedule+0x6d8/0xb20 [ 730.892209] __schedule+0x6d8/0xb20 [ 730.892899] schedule+0x5b/0xc0 [ 730.893522] exit_to_user_mode_prepare+0x11d/0x240 [ 730.894457] syscall_exit_to_user_mode+0x27/0x70 [ 730.895361] entry_SYSCALL_64_after_hwframe+0x44/0xae [...] Fixes: 59438b46471a ("security,lockdown,selinux: implement SELinux lockdown") Reported-by: Ondrej Mosnacek Reported-by: Jakub Hrozek Reported-by: Serhei Makarov Reported-by: Jiri Olsa Signed-off-by: Daniel Borkmann Acked-by: Alexei Starovoitov Tested-by: Jiri Olsa Cc: Paul Moore Cc: James Morris Cc: Jerome Marchand Cc: Frank Eigler Cc: Linus Torvalds Link: https://lore.kernel.org/bpf/01135120-8bf7-df2e-cff0-1d73f1f841c3@iogearbox.net Signed-off-by: Sasha Levin commit cdf3f6db1a86fc1e3d70423f4ee4fa81e4831157 Author: Tobias Klauser Date: Wed Jan 27 18:46:15 2021 +0100 bpf: Simplify cases in bpf_base_func_proto [ Upstream commit 61ca36c8c4eb3bae35a285b1ae18c514cde65439 ] !perfmon_capable() is checked before the last switch(func_id) in bpf_base_func_proto. Thus, the cases BPF_FUNC_trace_printk and BPF_FUNC_snprintf_btf can be moved to that last switch(func_id) to omit the inline !perfmon_capable() checks. Signed-off-by: Tobias Klauser Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20210127174615.3038-1-tklauser@distanz.ch Signed-off-by: Sasha Levin commit 4cf297ef595ce98cb4e9d80ae3e00bb5af0a8de0 Author: Zhihao Cheng Date: Tue Jun 1 09:19:35 2021 +0000 drm/i915/selftests: Fix return value check in live_breadcrumbs_smoketest() [ Upstream commit 10c1f0cbcea93beec5d3bdc02b1a3b577b4985e7 ] In case of error, the function live_context() returns ERR_PTR() and never returns NULL. The NULL test in the return value check should be replaced with IS_ERR(). Fixes: 52c0fdb25c7c ("drm/i915: Replace global breadcrumbs with per-context interrupt tracking") Reported-by: Hulk Robot Signed-off-by: Zhihao Cheng Reviewed-by: Tvrtko Ursulin Link: https://patchwork.freedesktop.org/patch/msgid/33c46ef24cd547d0ad21dc106441491a@intel.com [tursulin: Wrap commit text, fix Fixes: tag.] Signed-off-by: Tvrtko Ursulin (cherry picked from commit 8f4caef8d5401b42c6367d46c23da5e0e8111516) Signed-off-by: Jani Nikula Signed-off-by: Sasha Levin commit 8d614eebc003bb7763993e6fcdc8f853401bc17e Author: Pablo Neira Ayuso Date: Fri May 28 13:45:16 2021 +0200 netfilter: nfnetlink_cthelper: hit EBUSY on updates if size mismatches [ Upstream commit 8971ee8b087750a23f3cd4dc55bff2d0303fd267 ] The private helper data size cannot be updated. However, updates that contain NFCTH_PRIV_DATA_LEN might bogusly hit EBUSY even if the size is the same. Fixes: 12f7a505331e ("netfilter: add user-space connection tracking helper infrastructure") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 5f3429c05e4028a0e241afdad856dd15dec2ffb9 Author: Pablo Neira Ayuso Date: Thu May 27 21:54:42 2021 +0200 netfilter: nft_ct: skip expectations for confirmed conntrack [ Upstream commit 1710eb913bdcda3917f44d383c32de6bdabfc836 ] nft_ct_expect_obj_eval() calls nf_ct_ext_add() for a confirmed conntrack entry. However, nf_ct_ext_add() can only be called for !nf_ct_is_confirmed(). [ 1825.349056] WARNING: CPU: 0 PID: 1279 at net/netfilter/nf_conntrack_extend.c:48 nf_ct_xt_add+0x18e/0x1a0 [nf_conntrack] [ 1825.351391] RIP: 0010:nf_ct_ext_add+0x18e/0x1a0 [nf_conntrack] [ 1825.351493] Code: 41 5c 41 5d 41 5e 41 5f c3 41 bc 0a 00 00 00 e9 15 ff ff ff ba 09 00 00 00 31 f6 4c 89 ff e8 69 6c 3d e9 eb 96 45 31 ed eb cd <0f> 0b e9 b1 fe ff ff e8 86 79 14 e9 eb bf 0f 1f 40 00 0f 1f 44 00 [ 1825.351721] RSP: 0018:ffffc90002e1f1e8 EFLAGS: 00010202 [ 1825.351790] RAX: 000000000000000e RBX: ffff88814f5783c0 RCX: ffffffffc0e4f887 [ 1825.351881] RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88814f578440 [ 1825.351971] RBP: 0000000000000000 R08: 0000000000000000 R09: ffff88814f578447 [ 1825.352060] R10: ffffed1029eaf088 R11: 0000000000000001 R12: ffff88814f578440 [ 1825.352150] R13: ffff8882053f3a00 R14: 0000000000000000 R15: 0000000000000a20 [ 1825.352240] FS: 00007f992261c900(0000) GS:ffff889faec00000(0000) knlGS:0000000000000000 [ 1825.352343] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1825.352417] CR2: 000056070a4d1158 CR3: 000000015efe0000 CR4: 0000000000350ee0 [ 1825.352508] Call Trace: [ 1825.352544] nf_ct_helper_ext_add+0x10/0x60 [nf_conntrack] [ 1825.352641] nft_ct_expect_obj_eval+0x1b8/0x1e0 [nft_ct] [ 1825.352716] nft_do_chain+0x232/0x850 [nf_tables] Add the ct helper extension only for unconfirmed conntrack. Skip rule evaluation if the ct helper extension does not exist. Thus, you can only create expectations from the first packet. It should be possible to remove this limitation by adding a new action to attach a generic ct helper to the first packet. Then, use this ct helper extension from follow up packets to create the ct expectation. While at it, add a missing check to skip the template conntrack too and remove check for IPCT_UNTRACK which is implicit to !ct. Fixes: 857b46027d6f ("netfilter: nft_ct: add ct expectations support") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit c440cd080761b18a52cac20f2a42e5da1e3995af Author: Max Gurtovoy Date: Tue Jun 1 19:22:05 2021 +0300 nvmet: fix freeing unallocated p2pmem [ Upstream commit bcd9a0797d73eeff659582f23277e7ab6e5f18f3 ] In case p2p device was found but the p2p pool is empty, the nvme target is still trying to free the sgl from the p2p pool instead of the regular sgl pool and causing a crash (BUG() is called). Instead, assign the p2p_dev for the request only if it was allocated from p2p pool. This is the crash that was caused: [Sun May 30 19:13:53 2021] ------------[ cut here ]------------ [Sun May 30 19:13:53 2021] kernel BUG at lib/genalloc.c:518! [Sun May 30 19:13:53 2021] invalid opcode: 0000 [#1] SMP PTI ... [Sun May 30 19:13:53 2021] kernel BUG at lib/genalloc.c:518! ... [Sun May 30 19:13:53 2021] RIP: 0010:gen_pool_free_owner+0xa8/0xb0 ... [Sun May 30 19:13:53 2021] Call Trace: [Sun May 30 19:13:53 2021] ------------[ cut here ]------------ [Sun May 30 19:13:53 2021] pci_free_p2pmem+0x2b/0x70 [Sun May 30 19:13:53 2021] pci_p2pmem_free_sgl+0x4f/0x80 [Sun May 30 19:13:53 2021] nvmet_req_free_sgls+0x1e/0x80 [nvmet] [Sun May 30 19:13:53 2021] kernel BUG at lib/genalloc.c:518! [Sun May 30 19:13:53 2021] nvmet_rdma_release_rsp+0x4e/0x1f0 [nvmet_rdma] [Sun May 30 19:13:53 2021] nvmet_rdma_send_done+0x1c/0x60 [nvmet_rdma] Fixes: c6e3f1339812 ("nvmet: add metadata support for block devices") Reviewed-by: Israel Rukshin Signed-off-by: Max Gurtovoy Reviewed-by: Logan Gunthorpe Reviewed-by: Chaitanya Kulkarni Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 2a8cda3867cd06fbc3f414a78e1c692f973d21e4 Author: Yevgeny Kliteynik Date: Wed Dec 9 16:40:38 2020 +0200 net/mlx5: DR, Create multi-destination flow table with level less than 64 [ Upstream commit 216214c64a8c1cb9078c2c0aec7bb4a2f8e75397 ] Flow table that contains flow pointing to multiple flow tables or multiple TIRs must have a level lower than 64. In our case it applies to muli- destination flow table. Fix the level of the created table to comply with HW Spec definitions, and still make sure that its level lower than SW-owned tables, so that it would be possible to point from the multi-destination FW table to SW tables. Fixes: 34583beea4b7 ("net/mlx5: DR, Create multi-destination table for SW-steering use") Signed-off-by: Yevgeny Kliteynik Reviewed-by: Alex Vesker Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit c8972cf28ea11043280135859903ad69b03e0851 Author: Roi Dayan Date: Tue Apr 13 14:35:22 2021 +0300 net/mlx5e: Check for needed capability for cvlan matching [ Upstream commit afe93f71b5d3cdae7209213ec8ef25210b837b93 ] If not supported show an error and return instead of trying to offload to the hardware and fail. Fixes: 699e96ddf47f ("net/mlx5e: Support offloading tc double vlan headers match") Reported-by: Pablo Neira Ayuso Signed-off-by: Roi Dayan Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 730700337593b41551e17427bc33edcbd95d3f05 Author: Moshe Shemesh Date: Thu Apr 8 07:30:57 2021 +0300 net/mlx5: Check firmware sync reset requested is set before trying to abort it [ Upstream commit 5940e64281c09976ce2b560244217e610bf9d029 ] In case driver sent NACK to firmware on sync reset request, it will get sync reset abort event while it didn't set sync reset requested mode. Thus, on abort sync reset event handler, driver should check reset requested is set before trying to stop sync reset poll. Fixes: 7dd6df329d4c ("net/mlx5: Handle sync reset abort event") Signed-off-by: Moshe Shemesh Reviewed-by: Tariq Toukan Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit c1ea8c0e71ead1efaaba33e241c1e7d35e9cbf51 Author: Aya Levin Date: Tue May 25 15:35:25 2021 +0300 net/mlx5e: Fix incompatible casting [ Upstream commit d8ec92005f806dfa7524e9171eca707c0bb1267e ] Device supports setting of a single fec mode at a time, enforce this by bitmap_weight == 1. Input from fec command is in u32, avoid cast to unsigned long and use bitmap_from_arr32 to populate bitmap safely. Fixes: 4bd9d5070b92 ("net/mlx5e: Enforce setting of a single FEC mode") Signed-off-by: Aya Levin Reviewed-by: Tariq Toukan Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit f1d4184f128dede82a59a841658ed40d4e6d3aa2 Author: Maxim Mikityanskiy Date: Tue Jun 1 15:08:00 2021 +0300 net/tls: Fix use-after-free after the TLS device goes down and up [ Upstream commit c55dcdd435aa6c6ad6ccac0a4c636d010ee367a4 ] When a netdev with active TLS offload goes down, tls_device_down is called to stop the offload and tear down the TLS context. However, the socket stays alive, and it still points to the TLS context, which is now deallocated. If a netdev goes up, while the connection is still active, and the data flow resumes after a number of TCP retransmissions, it will lead to a use-after-free of the TLS context. This commit addresses this bug by keeping the context alive until its normal destruction, and implements the necessary fallbacks, so that the connection can resume in software (non-offloaded) kTLS mode. On the TX side tls_sw_fallback is used to encrypt all packets. The RX side already has all the necessary fallbacks, because receiving non-decrypted packets is supported. The thing needed on the RX side is to block resync requests, which are normally produced after receiving non-decrypted packets. The necessary synchronization is implemented for a graceful teardown: first the fallbacks are deployed, then the driver resources are released (it used to be possible to have a tls_dev_resync after tls_dev_del). A new flag called TLS_RX_DEV_DEGRADED is added to indicate the fallback mode. It's used to skip the RX resync logic completely, as it becomes useless, and some objects may be released (for example, resync_async, which is allocated and freed by the driver). Fixes: e8f69799810c ("net/tls: Add generic NIC offload infrastructure") Signed-off-by: Maxim Mikityanskiy Reviewed-by: Tariq Toukan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 874ece252ed269f5ac1f55167a3f2735ab0f249f Author: Maxim Mikityanskiy Date: Tue Jun 1 15:07:59 2021 +0300 net/tls: Replace TLS_RX_SYNC_RUNNING with RCU [ Upstream commit 05fc8b6cbd4f979a6f25759c4a17dd5f657f7ecd ] RCU synchronization is guaranteed to finish in finite time, unlike a busy loop that polls a flag. This patch is a preparation for the bugfix in the next patch, where the same synchronize_net() call will also be used to sync with the TX datapath. Signed-off-by: Maxim Mikityanskiy Reviewed-by: Tariq Toukan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit a5de17bb916a7f5b2e5b35a7c961ebee6d95bb28 Author: Alexander Aring Date: Mon May 31 17:00:30 2021 -0400 net: sock: fix in-kernel mark setting [ Upstream commit dd9082f4a9f94280fbbece641bf8fc0a25f71f7a ] This patch fixes the in-kernel mark setting by doing an additional sk_dst_reset() which was introduced by commit 50254256f382 ("sock: Reset dst when changing sk_mark via setsockopt"). The code is now shared to avoid any further suprises when changing the socket mark value. Fixes: 84d1c617402e ("net: sock: add sock_set_mark") Reported-by: Marcelo Ricardo Leitner Signed-off-by: Alexander Aring Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 09fdb6747b7ed3bc4da720301de52ac7b159214a Author: Vladimir Oltean Date: Mon May 31 13:20:45 2021 +0300 net: dsa: tag_8021q: fix the VLAN IDs used for encoding sub-VLANs [ Upstream commit 4ef8d857b5f494e62bce9085031563fda35f9563 ] When using sub-VLANs in the range of 1-7, the resulting value from: rx_vid = dsa_8021q_rx_vid_subvlan(ds, port, subvlan); is wrong according to the description from tag_8021q.c: | 11 | 10 | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +-----------+-----+-----------------+-----------+-----------------------+ | DIR | SVL | SWITCH_ID | SUBVLAN | PORT | +-----------+-----+-----------------+-----------+-----------------------+ For example, when ds->index == 0, port == 3 and subvlan == 1, dsa_8021q_rx_vid_subvlan() returns 1027, same as it returns for subvlan == 0, but it should have returned 1043. This is because the low portion of the subvlan bits are not masked properly when writing into the 12-bit VLAN value. They are masked into bits 4:3, but they should be masked into bits 5:4. Fixes: 3eaae1d05f2b ("net: dsa: tag_8021q: support up to 8 VLANs per port using sub-VLANs") Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 091283e3d5eb9f424b85e71804fc26092c3c4915 Author: Li Huafei Date: Tue Jun 1 17:27:50 2021 +0800 perf probe: Fix NULL pointer dereference in convert_variable_location() [ Upstream commit 3cb17cce1e76ccc5499915a4d7e095a1ad6bf7ff ] If we just check whether the variable can be converted, 'tvar' should be a null pointer. However, the null pointer check is missing in the 'Constant value' execution path. The following cases can trigger this problem: $ cat test.c #include void main(void) { int a; const int b = 1; asm volatile("mov %1, %0" : "=r"(a): "i"(b)); printf("a: %d\n", a); } $ gcc test.c -o test -O -g $ sudo ./perf probe -x ./test -L "main" 0 void main(void) { 2 int a; const int b = 1; asm volatile("mov %1, %0" : "=r"(a): "i"(b)); 6 printf("a: %d\n", a); } $ sudo ./perf probe -x ./test -V "main:6" Segmentation fault The check on 'tvar' is added. If 'tavr' is a null pointer, we return 0 to indicate that the variable can be converted. Now, we can successfully show the variables that can be accessed. $ sudo ./perf probe -x ./test -V "main:6" Available variables at main:6 @ char* __fmt int a int b However, the variable 'b' cannot be tracked. $ sudo ./perf probe -x ./test -D "main:6 b" Failed to find the location of the 'b' variable at this address. Perhaps it has been optimized out. Use -V with the --range option to show 'b' location range. Error: Failed to add events. This is because __die_find_variable_cb() did not successfully match variable 'b', which has the DW_AT_const_value attribute instead of DW_AT_location. We added support for DW_AT_const_value in __die_find_variable_cb(). With this modification, we can successfully track the variable 'b'. $ sudo ./perf probe -x ./test -D "main:6 b" p:probe_test/main_L6 /home/lhf/test:0x1156 b=\1:s32 Fixes: 66f69b219716 ("perf probe: Support DW_AT_const_value constant value") Signed-off-by: Li Huafei Tested-by: Arnaldo Carvalho de Melo Cc: Alexander Shishkin Cc: Frank Ch. Eigler Cc: Jianlin Lv Cc: Jiri Olsa Cc: Mark Rutland Cc: Masami Hiramatsu Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Srikar Dronamraju Cc: Yang Jihong Cc: Zhang Jinhao http://lore.kernel.org/lkml/20210601092750.169601-1-lihuafei1@huawei.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 100c872c75112da26630309f4020991ffab2a11d Author: Erik Kaneda Date: Fri May 21 15:28:08 2021 -0700 ACPICA: Clean up context mutex during object deletion [ Upstream commit e4dfe108371214500ee10c2cf19268f53acaa803 ] ACPICA commit bc43c878fd4ff27ba75b1d111b97ee90d4a82707 Fixes: c27f3d011b08 ("Fix race in GenericSerialBus (I2C) and GPIO OpRegion parameter handling") Link: https://github.com/acpica/acpica/commit/bc43c878 Reported-by: John Garry Reported-by: Xiang Chen Tested-by: Xiang Chen Signed-off-by: Erik Kaneda Signed-off-by: Bob Moore Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit df7c913f90c3dcda988a254141bf01eb3bb6f123 Author: Sagi Grimberg Date: Thu May 27 18:16:38 2021 -0700 nvme-rdma: fix in-casule data send for chained sgls [ Upstream commit 12b2aaadb6d5ef77434e8db21f469f46fe2d392e ] We have only 2 inline sg entries and we allow 4 sg entries for the send wr sge. Larger sgls entries will be chained. However when we build in-capsule send wr sge, we iterate without taking into account that the sgl may be chained and still fit in-capsule (which can happen if the sgl is bigger than 2, but lower-equal to 4). Fix in-capsule data mapping to correctly iterate chained sgls. Fixes: 38e1800275d3 ("nvme-rdma: Avoid preallocating big SGL for data") Reported-by: Walker, Benjamin Signed-off-by: Sagi Grimberg Reviewed-by: Max Gurtovoy Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit b198f77a3613a066cefa91f2cd9e0766612a19ce Author: Paolo Abeni Date: Thu May 27 16:31:38 2021 -0700 mptcp: always parse mptcp options for MPC reqsk [ Upstream commit 06f9a435b3aa12f4de6da91f11fdce8ce7b46205 ] In subflow_syn_recv_sock() we currently skip options parsing for OoO packet, given that such packets may not carry the relevant MPC option. If the peer generates an MPC+data TSO packet and some of the early segments are lost or get reorder, we server will ignore the peer key, causing transient, unexpected fallback to TCP. The solution is always parsing the incoming MPTCP options, and do the fallback only for in-order packets. This actually cleans the existing code a bit. Fixes: d22f4988ffec ("mptcp: process MP_CAPABLE data option") Reported-by: Matthieu Baerts Signed-off-by: Paolo Abeni Signed-off-by: Mat Martineau Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit be0d8507268646a6ca524c0f40f29c501b3d78d9 Author: Ariel Levkovich Date: Wed May 26 20:01:10 2021 +0300 net/sched: act_ct: Fix ct template allocation for zone 0 [ Upstream commit fb91702b743dec78d6507c53a2dec8a8883f509d ] Fix current behavior of skipping template allocation in case the ct action is in zone 0. Skipping the allocation may cause the datapath ct code to ignore the entire ct action with all its attributes (commit, nat) in case the ct action in zone 0 was preceded by a ct clear action. The ct clear action sets the ct_state to untracked and resets the skb->_nfct pointer. Under these conditions and without an allocated ct template, the skb->_nfct pointer will remain NULL which will cause the tc ct action handler to exit without handling commit and nat actions, if such exist. For example, the following rule in OVS dp: recirc_id(0x2),ct_state(+new-est-rel-rpl+trk),ct_label(0/0x1), \ in_port(eth0),actions:ct_clear,ct(commit,nat(src=10.11.0.12)), \ recirc(0x37a) Will result in act_ct skipping the commit and nat actions in zone 0. The change removes the skipping of template allocation for zone 0 and treats it the same as any other zone. Fixes: b57dc7c13ea9 ("net/sched: Introduce action ct") Signed-off-by: Ariel Levkovich Acked-by: Marcelo Ricardo Leitner Link: https://lore.kernel.org/r/20210526170110.54864-1-lariel@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f07c548314776231f0d47d73ec6caa5b17e876e8 Author: Paul Blakey Date: Wed May 26 14:44:09 2021 +0300 net/sched: act_ct: Offload connections with commit action [ Upstream commit 0cc254e5aa37cf05f65bcdcdc0ac5c58010feb33 ] Currently established connections are not offloaded if the filter has a "ct commit" action. This behavior will not offload connections of the following scenario: $ tc_filter add dev $DEV ingress protocol ip prio 1 flower \ ct_state -trk \ action ct commit action goto chain 1 $ tc_filter add dev $DEV ingress protocol ip chain 1 prio 1 flower \ action mirred egress redirect dev $DEV2 $ tc_filter add dev $DEV2 ingress protocol ip prio 1 flower \ action ct commit action goto chain 1 $ tc_filter add dev $DEV2 ingress protocol ip prio 1 chain 1 flower \ ct_state +trk+est \ action mirred egress redirect dev $DEV Offload established connections, regardless of the commit flag. Fixes: 46475bb20f4b ("net/sched: act_ct: Software offload of established flows") Reviewed-by: Oz Shlomo Reviewed-by: Jiri Pirko Acked-by: Marcelo Ricardo Leitner Signed-off-by: Paul Blakey Link: https://lore.kernel.org/r/1622029449-27060-1-git-send-email-paulb@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4f00f9c169d9f6840613a44490d7800be8d73a61 Author: Parav Pandit Date: Wed May 26 23:00:27 2021 +0300 devlink: Correct VIRTUAL port to not have phys_port attributes [ Upstream commit b28d8f0c25a9b0355116cace5f53ea52bd4020c8 ] Physical port name, port number attributes do not belong to virtual port flavour. When VF or SF virtual ports are registered they incorrectly append "np0" string in the netdevice name of the VF/SF. Before this fix, VF netdevice name were ens2f0np0v0, ens2f0np0v1 for VF 0 and 1 respectively. After the fix, they are ens2f0v0, ens2f0v1. With this fix, reading /sys/class/net/ens2f0v0/phys_port_name returns -EOPNOTSUPP. Also devlink port show example for 2 VFs on one PF to ensure that any physical port attributes are not exposed. $ devlink port show pci/0000:06:00.0/65535: type eth netdev ens2f0np0 flavour physical port 0 splittable false pci/0000:06:00.3/196608: type eth netdev ens2f0v0 flavour virtual splittable false pci/0000:06:00.4/262144: type eth netdev ens2f0v1 flavour virtual splittable false This change introduces a netdevice name change on systemd/udev version 245 and higher which honors phys_port_name sysfs file for generation of netdevice name. This also aligns to phys_port_name usage which is limited to switchdev ports as described in [1]. [1] https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/tree/Documentation/networking/switchdev.rst Fixes: acf1ee44ca5d ("devlink: Introduce devlink port flavour virtual") Signed-off-by: Parav Pandit Reviewed-by: Jiri Pirko Link: https://lore.kernel.org/r/20210526200027.14008-1-parav@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 56c45ab00abab9481bb55151bf5719ec7c93f01a Author: Arnd Bergmann Date: Fri May 14 15:58:50 2021 +0200 HID: i2c-hid: fix format string mismatch [ Upstream commit dc5f9f55502e13ba05731d5046a14620aa2ff456 ] clang doesn't like printing a 32-bit integer using %hX format string: drivers/hid/i2c-hid/i2c-hid-core.c:994:18: error: format specifies type 'unsigned short' but the argument has type '__u32' (aka 'unsigned int') [-Werror,-Wformat] client->name, hid->vendor, hid->product); ^~~~~~~~~~~ drivers/hid/i2c-hid/i2c-hid-core.c:994:31: error: format specifies type 'unsigned short' but the argument has type '__u32' (aka 'unsigned int') [-Werror,-Wformat] client->name, hid->vendor, hid->product); ^~~~~~~~~~~~ Use an explicit cast to truncate it to the low 16 bits instead. Fixes: 9ee3e06610fd ("HID: i2c-hid: override HID descriptors for certain devices") Signed-off-by: Arnd Bergmann Reviewed-by: Nathan Chancellor Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 744db828d6f9a0908f64d337642bb8ee227a7ea9 Author: Zhen Lei Date: Sat May 8 10:47:37 2021 +0800 HID: pidff: fix error return code in hid_pidff_init() [ Upstream commit 3dd653c077efda8152f4dd395359617d577a54cd ] Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Fixes: 224ee88fe395 ("Input: add force feedback driver for PID devices") Reported-by: Hulk Robot Signed-off-by: Zhen Lei Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 39b92726a38092c704c4e1bcc8262a8959ae978e Author: Tom Rix Date: Fri May 7 12:18:19 2021 -0700 HID: logitech-hidpp: initialize level variable [ Upstream commit 81c8bf9170477d453b24a6bc3300d201d641e645 ] Static analysis reports this representative problem hid-logitech-hidpp.c:1356:23: warning: Assigned value is garbage or undefined hidpp->battery.level = level; ^ ~~~~~ In some cases, 'level' is never set in hidpp20_battery_map_status_voltage() Since level is not available on all hw, initialize level to unknown. Fixes: be281368f297 ("hid-logitech-hidpp: read battery voltage from newer devices") Signed-off-by: Tom Rix Reviewed-by: Filipe Laíns Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 4b1aba653642e469d954afefafa842025e10f00a Author: Julian Anastasov Date: Mon May 24 22:54:57 2021 +0300 ipvs: ignore IP_VS_SVC_F_HASHED flag when adding service [ Upstream commit 56e4ee82e850026d71223262c07df7d6af3bd872 ] syzbot reported memory leak [1] when adding service with HASHED flag. We should ignore this flag both from sockopt and netlink provided data, otherwise the service is not hashed and not visible while releasing resources. [1] BUG: memory leak unreferenced object 0xffff888115227800 (size 512): comm "syz-executor263", pid 8658, jiffies 4294951882 (age 12.560s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [] kmalloc include/linux/slab.h:556 [inline] [] kzalloc include/linux/slab.h:686 [inline] [] ip_vs_add_service+0x598/0x7c0 net/netfilter/ipvs/ip_vs_ctl.c:1343 [] do_ip_vs_set_ctl+0x810/0xa40 net/netfilter/ipvs/ip_vs_ctl.c:2570 [] nf_setsockopt+0x68/0xa0 net/netfilter/nf_sockopt.c:101 [] ip_setsockopt+0x259/0x1ff0 net/ipv4/ip_sockglue.c:1435 [] raw_setsockopt+0x18c/0x1b0 net/ipv4/raw.c:857 [] __sys_setsockopt+0x1b0/0x360 net/socket.c:2117 [] __do_sys_setsockopt net/socket.c:2128 [inline] [] __se_sys_setsockopt net/socket.c:2125 [inline] [] __x64_sys_setsockopt+0x22/0x30 net/socket.c:2125 [] do_syscall_64+0x3a/0xb0 arch/x86/entry/common.c:47 [] entry_SYSCALL_64_after_hwframe+0x44/0xae Reported-and-tested-by: syzbot+e562383183e4b1766930@syzkaller.appspotmail.com Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Julian Anastasov Reviewed-by: Simon Horman Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 46ae882bb19a12e8df9936e8dcf1924b6abb2b56 Author: Max Gurtovoy Date: Tue May 18 22:21:31 2021 +0300 vfio/platform: fix module_put call in error flow [ Upstream commit dc51ff91cf2d1e9a2d941da483602f71d4a51472 ] The ->parent_module is the one that use in try_module_get. It should also be the one the we use in module_put during vfio_platform_open(). Fixes: 32a2d71c4e80 ("vfio: platform: introduce vfio-platform-base module") Signed-off-by: Max Gurtovoy Message-Id: <20210518192133.59195-1-mgurtovoy@nvidia.com> Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit 2adb0313b132cdade0827820f1d0db4833dfb4ef Author: Wei Yongjun Date: Thu May 20 13:36:41 2021 +0000 samples: vfio-mdev: fix error handing in mdpy_fb_probe() [ Upstream commit 752774ce7793a1f8baa55aae31f3b4caac49cbe4 ] Fix to return a negative error code from the framebuffer_alloc() error handling case instead of 0, also release regions in some error handing cases. Fixes: cacade1946a4 ("sample: vfio mdev display - guest driver") Reported-by: Hulk Robot Signed-off-by: Wei Yongjun Message-Id: <20210520133641.1421378-1-weiyongjun1@huawei.com> Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit c25454a4f4cbb172c47a6a49506de8ab133928a1 Author: Randy Dunlap Date: Sat May 15 12:08:56 2021 -0700 vfio/pci: zap_vma_ptes() needs MMU [ Upstream commit 2a55ca37350171d9b43d561528f23d4130097255 ] zap_vma_ptes() is only available when CONFIG_MMU is set/enabled. Without CONFIG_MMU, vfio_pci.o has build errors, so make VFIO_PCI depend on MMU. riscv64-linux-ld: drivers/vfio/pci/vfio_pci.o: in function `vfio_pci_mmap_open': vfio_pci.c:(.text+0x1ec): undefined reference to `zap_vma_ptes' riscv64-linux-ld: drivers/vfio/pci/vfio_pci.o: in function `.L0 ': vfio_pci.c:(.text+0x165c): undefined reference to `zap_vma_ptes' Fixes: 11c4cd07ba11 ("vfio-pci: Fault mmaps to enable vma tracking") Signed-off-by: Randy Dunlap Reported-by: kernel test robot Cc: Alex Williamson Cc: Cornelia Huck Cc: kvm@vger.kernel.org Cc: Jason Gunthorpe Cc: Eric Auger Message-Id: <20210515190856.2130-1-rdunlap@infradead.org> Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit c303db1211a751d1e2c6a016687ef5e9734ee4b8 Author: Zhen Lei Date: Sat May 15 10:04:58 2021 +0800 vfio/pci: Fix error return code in vfio_ecap_init() [ Upstream commit d1ce2c79156d3baf0830990ab06d296477b93c26 ] The error code returned from vfio_ext_cap_len() is stored in 'len', not in 'ret'. Fixes: 89e1f7d4c66d ("vfio: Add PCI device driver") Reported-by: Hulk Robot Signed-off-by: Zhen Lei Reviewed-by: Max Gurtovoy Message-Id: <20210515020458.6771-1-thunder.leizhen@huawei.com> Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit 8d27efbb0ee49251169feda005ec244aef73f8a6 Author: Rasmus Villemoes Date: Wed Apr 21 21:46:36 2021 +0200 efi: cper: fix snprintf() use in cper_dimm_err_location() [ Upstream commit 942859d969de7f6f7f2659a79237a758b42782da ] snprintf() should be given the full buffer size, not one less. And it guarantees nul-termination, so doing it manually afterwards is pointless. It's even potentially harmful (though probably not in practice because CPER_REC_LEN is 256), due to the "return how much would have been written had the buffer been big enough" semantics. I.e., if the bank and/or device strings are long enough that the "DIMM location ..." output gets truncated, writing to msg[n] is a buffer overflow. Signed-off-by: Rasmus Villemoes Fixes: 3760cd20402d4 ("CPER: Adjust code flow of some functions") Signed-off-by: Ard Biesheuvel Signed-off-by: Sasha Levin commit 951f8ef71d691f754483cc9d871cb493379fdb35 Author: Dan Carpenter Date: Fri Apr 23 14:48:31 2021 +0300 efi/libstub: prevent read overflow in find_file_option() [ Upstream commit c4039b29fe9637e1135912813f830994af4c867f ] If the buffer has slashes up to the end then this will read past the end of the array. I don't anticipate that this is an issue for many people in real life, but it's the right thing to do and it makes static checkers happy. Fixes: 7a88a6227dc7 ("efi/libstub: Fix path separator regression") Signed-off-by: Dan Carpenter Signed-off-by: Ard Biesheuvel Signed-off-by: Sasha Levin commit b828601c752b1053a18f750bc413949cefa2a58b Author: Heiner Kallweit Date: Fri Apr 30 16:22:51 2021 +0200 efi: Allow EFI_MEMORY_XP and EFI_MEMORY_RO both to be cleared [ Upstream commit 45add3cc99feaaf57d4b6f01d52d532c16a1caee ] UEFI spec 2.9, p.108, table 4-1 lists the scenario that both attributes are cleared with the description "No memory access protection is possible for Entry". So we can have valid entries where both attributes are cleared, so remove the check. Signed-off-by: Heiner Kallweit Fixes: 10f0d2f577053 ("efi: Implement generic support for the Memory Attributes table") Signed-off-by: Ard Biesheuvel Signed-off-by: Sasha Levin commit 5148066edbdc89c6fe5bc419c31a5c22e5f83bdb Author: Changbin Du Date: Wed Mar 24 22:54:35 2021 +0800 efi/fdt: fix panic when no valid fdt found [ Upstream commit 668a84c1bfb2b3fd5a10847825a854d63fac7baa ] setup_arch() would invoke efi_init()->efi_get_fdt_params(). If no valid fdt found then initial_boot_params will be null. So we should stop further fdt processing here. I encountered this issue on risc-v. Signed-off-by: Changbin Du Fixes: b91540d52a08b ("RISC-V: Add EFI runtime services") Signed-off-by: Ard Biesheuvel Signed-off-by: Sasha Levin commit 39a909a9720dd5a7b423f97c3737541d0ef76c06 Author: Florian Westphal Date: Tue May 4 16:40:00 2021 +0200 netfilter: conntrack: unregister ipv4 sockopts on error unwind [ Upstream commit 22cbdbcfb61acc78d5fc21ebb13ccc0d7e29f793 ] When ipv6 sockopt register fails, the ipv4 one needs to be removed. Fixes: a0ae2562c6c ("netfilter: conntrack: remove l3proto abstraction") Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 46e65061793405766c8368738cb5ecf5eca6caf3 Author: Grant Peltier Date: Fri May 14 16:19:55 2021 -0500 hwmon: (pmbus/isl68137) remove READ_TEMPERATURE_3 for RAA228228 [ Upstream commit 2a29db088c7ae7121801a0d7a60740ed2d18c4f3 ] The initial version of the RAA228228 datasheet claimed that the device supported READ_TEMPERATURE_3 but not READ_TEMPERATURE_1. It has since been discovered that the datasheet was incorrect. The RAA228228 does support READ_TEMPERATURE_1 but does not support READ_TEMPERATURE_3. Signed-off-by: Grant Peltier Fixes: 51fb91ed5a6f ("hwmon: (pmbus/isl68137) remove READ_TEMPERATURE_1 telemetry for RAA228228") Link: https://lore.kernel.org/r/20210514211954.GA24646@raspberrypi Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 0d0df2e53223167d305dde815664bc830cd4cce6 Author: Armin Wolf Date: Thu May 13 17:45:46 2021 +0200 hwmon: (dell-smm-hwmon) Fix index values [ Upstream commit 35d470b5fbc9f82feb77b56bb0d5d0b5cd73e9da ] When support for up to 10 temp sensors and for disabling automatic BIOS fan control was added, noone updated the index values used for disallowing fan support and fan type calls. Fix those values. Signed-off-by: Armin Wolf Reviewed-by: Pali Rohár Link: https://lore.kernel.org/r/20210513154546.12430-1-W_Armin@gmx.de Fixes: 1bb46a20e73b ("hwmon: (dell-smm) Support up to 10 temp sensors") Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 70df000fb8808e2ea63e6beb2ff570c083592614 Author: Grant Grundler Date: Tue Jan 19 17:12:08 2021 -0800 net: usb: cdc_ncm: don't spew notifications [ Upstream commit de658a195ee23ca6aaffe197d1d2ea040beea0a2 ] RTL8156 sends notifications about every 32ms. Only display/log notifications when something changes. This issue has been reported by others: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1832472 https://lkml.org/lkml/2020/8/27/1083 ... [785962.779840] usb 1-1: new high-speed USB device number 5 using xhci_hcd [785962.929944] usb 1-1: New USB device found, idVendor=0bda, idProduct=8156, bcdDevice=30.00 [785962.929949] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=6 [785962.929952] usb 1-1: Product: USB 10/100/1G/2.5G LAN [785962.929954] usb 1-1: Manufacturer: Realtek [785962.929956] usb 1-1: SerialNumber: 000000001 [785962.991755] usbcore: registered new interface driver cdc_ether [785963.017068] cdc_ncm 1-1:2.0: MAC-Address: 00:24:27:88:08:15 [785963.017072] cdc_ncm 1-1:2.0: setting rx_max = 16384 [785963.017169] cdc_ncm 1-1:2.0: setting tx_max = 16384 [785963.017682] cdc_ncm 1-1:2.0 usb0: register 'cdc_ncm' at usb-0000:00:14.0-1, CDC NCM, 00:24:27:88:08:15 [785963.019211] usbcore: registered new interface driver cdc_ncm [785963.023856] usbcore: registered new interface driver cdc_wdm [785963.025461] usbcore: registered new interface driver cdc_mbim [785963.038824] cdc_ncm 1-1:2.0 enx002427880815: renamed from usb0 [785963.089586] cdc_ncm 1-1:2.0 enx002427880815: network connection: disconnected [785963.121673] cdc_ncm 1-1:2.0 enx002427880815: network connection: disconnected [785963.153682] cdc_ncm 1-1:2.0 enx002427880815: network connection: disconnected ... This is about 2KB per second and will overwrite all contents of a 1MB dmesg buffer in under 10 minutes rendering them useless for debugging many kernel problems. This is also an extra 180 MB/day in /var/logs (or 1GB per week) rendering the majority of those logs useless too. When the link is up (expected state), spew amount is >2x higher: ... [786139.600992] cdc_ncm 2-1:2.0 enx002427880815: network connection: connected [786139.632997] cdc_ncm 2-1:2.0 enx002427880815: 2500 mbit/s downlink 2500 mbit/s uplink [786139.665097] cdc_ncm 2-1:2.0 enx002427880815: network connection: connected [786139.697100] cdc_ncm 2-1:2.0 enx002427880815: 2500 mbit/s downlink 2500 mbit/s uplink [786139.729094] cdc_ncm 2-1:2.0 enx002427880815: network connection: connected [786139.761108] cdc_ncm 2-1:2.0 enx002427880815: 2500 mbit/s downlink 2500 mbit/s uplink ... Chrome OS cannot support RTL8156 until this is fixed. Signed-off-by: Grant Grundler Reviewed-by: Hayes Wang Link: https://lore.kernel.org/r/20210120011208.3768105-1-grundler@chromium.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1d62b7ac83e0791200563b9c2deb658c2d196dcf Author: Josef Bacik Date: Fri Jun 4 17:53:04 2021 +0200 btrfs: tree-checker: do not error out if extent ref hash doesn't match commit 1119a72e223f3073a604f8fccb3a470ccd8a4416 upstream. The tree checker checks the extent ref hash at read and write time to make sure we do not corrupt the file system. Generally extent references go inline, but if we have enough of them we need to make an item, which looks like key.objectid = key.type = key.offset = hash(tree, owner, offset) However if key.offset collide with an unrelated extent reference we'll simply key.offset++ until we get something that doesn't collide. Obviously this doesn't match at tree checker time, and thus we error while writing out the transaction. This is relatively easy to reproduce, simply do something like the following xfs_io -f -c "pwrite 0 1M" file offset=2 for i in {0..10000} do xfs_io -c "reflink file 0 ${offset}M 1M" file offset=$(( offset + 2 )) done xfs_io -c "reflink file 0 17999258914816 1M" file xfs_io -c "reflink file 0 35998517829632 1M" file xfs_io -c "reflink file 0 53752752058368 1M" file btrfs filesystem sync And the sync will error out because we'll abort the transaction. The magic values above are used because they generate hash collisions with the first file in the main subvol. The fix for this is to remove the hash value check from tree checker, as we have no idea which offset ours should belong to. Reported-by: Tuomas Lähdekorpi Fixes: 0785a9aacf9d ("btrfs: tree-checker: Add EXTENT_DATA_REF check") CC: stable@vger.kernel.org # 5.4+ Reviewed-by: Filipe Manana Signed-off-by: Josef Bacik Reviewed-by: David Sterba [ add comment] Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 65859eca4dff1af0db5e36d1cfbac15b834c6a65 Author: Greg Kroah-Hartman Date: Thu Jun 3 09:00:52 2021 +0200 Linux 5.10.42 Link: https://lore.kernel.org/r/20210531130657.971257589@linuxfoundation.org Tested-by: Fox Chen Tested-by: Pavel Machek (CIP) Tested-by: Salvatore Bonaccorso Tested-by: Florian Fainelli Tested-by: Jason Self Tested-by: Linux Kernel Functional Testing Tested-by: Hulk Robot Tested-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 972b4c19f55da91a42682c74634d36bf5ef3061c Author: Chunfeng Yun Date: Sat Apr 10 09:20:45 2021 +0800 usb: core: reduce power-on-good delay time of root hub commit 90d28fb53d4a51299ff324dede015d5cb11b88a2 upstream. Return the exactly delay time given by root hub descriptor, this helps to reduce resume time etc. Due to the root hub descriptor is usually provided by the host controller driver, if there is compatibility for a root hub, we can fix it easily without affect other root hub Acked-by: Alan Stern Signed-off-by: Chunfeng Yun Link: https://lore.kernel.org/r/1618017645-12259-1-git-send-email-chunfeng.yun@mediatek.com Signed-off-by: Greg Kroah-Hartman commit 5c7b23b7962865766147c5d7dc3f6e15b96dbe18 Author: Chinmay Agarwal Date: Thu Apr 22 01:12:22 2021 +0530 neighbour: Prevent Race condition in neighbour subsytem commit eefb45eef5c4c425e87667af8f5e904fbdd47abf upstream. Following Race Condition was detected: : Executing: __netif_receive_skb() ->__netif_receive_skb_core() -> arp_rcv() -> arp_process().arp_process() calls __neigh_lookup() which takes a reference on neighbour entry 'n'. Moves further along, arp_process() and calls neigh_update()-> __neigh_update(). Neighbour entry is unlocked just before a call to neigh_update_gc_list. This unlocking paves way for another thread that may take a reference on the same and mark it dead and remove it from gc_list. - neigh_flush_dev() is under execution and calls neigh_mark_dead(n) marking the neighbour entry 'n' as dead. Also n will be removed from gc_list. Moves further along neigh_flush_dev() and calls neigh_cleanup_and_release(n), but since reference count increased in t1, 'n' couldn't be destroyed. - Code hits neigh_update_gc_list, with neighbour entry set as dead. - arp_process() finally calls neigh_release(n), destroying the neighbour entry and we have a destroyed ntry still part of gc_list. Fixes: eb4e8fac00d1("neighbour: Prevent a dead entry from updating gc_list") Signed-off-by: Chinmay Agarwal Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 9427906999778401518c592662c8801d00eb46bb Author: Masahiro Yamada Date: Tue Feb 2 15:06:04 2021 +0900 scripts/clang-tools: switch explicitly to Python 3 commit 074075aea2ff72dade5231b4ee9f2ab9a055f1ec upstream. For the same reason as commit 51839e29cb59 ("scripts: switch explicitly to Python 3"), switch some more scripts, which I tested and confirmed working on Python 3. Signed-off-by: Masahiro Yamada Acked-by: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman commit c1febac44856c9346bef939b9b0987ee8f0609e2 Author: Johan Hovold Date: Wed May 19 14:47:17 2021 +0200 net: hso: bail out on interrupt URB allocation failure commit 4d52ebc7ace491d58f96d1f4a1cb9070c506b2e7 upstream. Commit 31db0dbd7244 ("net: hso: check for allocation failure in hso_create_bulk_serial_device()") recently started returning an error when the driver fails to allocate resources for the interrupt endpoint and tiocmget functionality. For consistency let's bail out from probe also if the URB allocation fails. Signed-off-by: Johan Hovold Reviewed-by: Dan Carpenter Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 0e3045c15ff9d44e7ac56c0f70d671ac03694bb2 Author: Greg Kroah-Hartman Date: Thu May 13 21:40:38 2021 +0200 Revert "Revert "ALSA: usx2y: Fix potential NULL pointer dereference"" commit 27b57bb76a897be80494ee11ee4e85326d19383d upstream. This reverts commit 4667a6fc1777ce071504bab570d3599107f4790f. Takashi writes: I have already started working on the bigger cleanup of this driver code based on 5.13-rc1, so could you drop this revert? I missed our previous discussion about this, my fault for applying it. Reported-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 899b5131e74cd09ddd204addf763deaf6870ab57 Author: Trond Myklebust Date: Tue May 25 18:43:38 2021 -0400 SUNRPC: More fixes for backlog congestion commit e86be3a04bc4aeaf12f93af35f08f8d4385bcd98 upstream. Ensure that we fix the XPRT_CONGESTED starvation issue for RDMA as well as socket based transports. Ensure we always initialise the request after waking up from the backlog list. Fixes: e877a88d1f06 ("SUNRPC in case of backlog, hand free slots directly to waiting task") Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit c2779f8ddc9ac9206b2ee7fe397cd17921fabc67 Author: Liu Jian Date: Tue May 25 09:41:39 2021 +0800 bpftool: Add sock_release help info for cgroup attach/prog load command commit a8deba8547e39f26440101164a3bbc2899c5b305 upstream. The help information was not added at the time when the function got added. Fix this and add the missing information to its cli, documentation and bash completion. Fixes: db94cc0b4805 ("bpftool: Add support for BPF_CGROUP_INET_SOCK_RELEASE") Signed-off-by: Liu Jian Signed-off-by: Daniel Borkmann Reviewed-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20210525014139.323859-1-liujian56@huawei.com Signed-off-by: Greg Kroah-Hartman commit 534b6229196efe56c4db3ba05321556f39ed51de Author: Yunsheng Lin Date: Tue May 18 19:36:03 2021 +0800 net: hns3: check the return of skb_checksum_help() commit 9bb5a495424fd4bfa672eb1f31481248562fa156 upstream. Currently skb_checksum_help()'s return is ignored, but it may return error when it fails to allocate memory when linearizing. So adds checking for the return of skb_checksum_help(). Fixes: 76ad4f0ee747("net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC") Fixes: 3db084d28dc0("net: hns3: Fix for vxlan tx checksum bug") Signed-off-by: Yunsheng Lin Signed-off-by: Huazhong Tan Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit bc924bbccc50f28d9b9dc43dd747a43044e0130f Author: Magnus Karlsson Date: Thu May 6 14:43:49 2021 +0200 samples/bpf: Consider frame size in tx_only of xdpsock sample commit 3b80d106e110d39d3f678954d3b55078669cf07e upstream. Fix the tx_only micro-benchmark in xdpsock to take frame size into consideration. It was hardcoded to the default value of frame_size which is 4K. Changing this on the command line to 2K made half of the packets illegal as they were outside the umem and were therefore discarded by the kernel. Fixes: 46738f73ea4f ("samples/bpf: add use of need_wakeup flag in xdpsock") Signed-off-by: Magnus Karlsson Signed-off-by: Daniel Borkmann Acked-by: Maciej Fijalkowski Link: https://lore.kernel.org/bpf/20210506124349.6666-1-magnus.karlsson@gmail.com Signed-off-by: Greg Kroah-Hartman commit 02ce4c943e2ed7660786d3618afadf27b61b0758 Author: Greg Kroah-Hartman Date: Mon May 31 08:35:11 2021 +0200 i915: fix build warning in intel_dp_get_link_status() There is a build warning using gcc-11 showing a mis-match in the .h and .c definitions of intel_dp_get_link_status(): CC [M] drivers/gpu/drm/i915/display/intel_dp.o drivers/gpu/drm/i915/display/intel_dp.c:4139:56: warning: argument 2 of type ‘u8[6]’ {aka ‘unsigned char[6]’} with mismatched bound [-Warray-parameter=] 4139 | intel_dp_get_link_status(struct intel_dp *intel_dp, u8 link_status[DP_LINK_STATUS_SIZE]) | ~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from drivers/gpu/drm/i915/display/intel_dp.c:51: drivers/gpu/drm/i915/display/intel_dp.h:105:57: note: previously declared as ‘u8 *’ {aka ‘unsigned char *’} 105 | intel_dp_get_link_status(struct intel_dp *intel_dp, u8 *link_status); | ~~~~^~~~~~~~~~~ This was fixed accidentally commit b30edfd8d0b4 ("drm/i915: Switch to LTTPR non-transparent mode link training") by getting rid of the function entirely, but that is not a viable backport for a stable kernel, so just fix up the function definition to remove the build warning entirely. There is no functional change for this, and it fixes up one of the last 'make allmodconfig' build warnings when using gcc-11 on this kernel tree. Signed-off-by: Greg Kroah-Hartman commit 8d2ab018a07a05b67c8b2435aa8b5e880a494f01 Author: Stefan Chulski Date: Tue May 25 19:04:41 2021 +0300 net: mvpp2: add buffer header handling in RX [ Upstream commit 17f9c1b63cdd4439523cfcdf5683e5070b911f24 ] If Link Partner sends frames larger than RX buffer size, MAC mark it as oversize but still would pass it to the Packet Processor. In this scenario, Packet Processor scatter frame between multiple buffers, but only a single buffer would be returned to the Buffer Manager pool and it would not refill the poll. Patch add handling of oversize error with buffer header handling, so all buffers would be returned to the Buffer Manager pool. Fixes: 3f518509dedc ("ethernet: Add new driver for Marvell Armada 375 network unit") Reported-by: Russell King Signed-off-by: Stefan Chulski Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit ac493452e937b8939eaf2d24cac51a4804b6c20e Author: Vlad Buslov Date: Tue May 25 16:21:52 2021 +0300 net: zero-initialize tc skb extension on allocation [ Upstream commit 9453d45ecb6c2199d72e73c993e9d98677a2801b ] Function skb_ext_add() doesn't initialize created skb extension with any value and leaves it up to the user. However, since extension of type TC_SKB_EXT originally contained only single value tc_skb_ext->chain its users used to just assign the chain value without setting whole extension memory to zero first. This assumption changed when TC_SKB_EXT extension was extended with additional fields but not all users were updated to initialize the new fields which leads to use of uninitialized memory afterwards. UBSAN log: [ 778.299821] UBSAN: invalid-load in net/openvswitch/flow.c:899:28 [ 778.301495] load of value 107 is not a valid value for type '_Bool' [ 778.303215] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.12.0-rc7+ #2 [ 778.304933] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 [ 778.307901] Call Trace: [ 778.308680] [ 778.309358] dump_stack+0xbb/0x107 [ 778.310307] ubsan_epilogue+0x5/0x40 [ 778.311167] __ubsan_handle_load_invalid_value.cold+0x43/0x48 [ 778.312454] ? memset+0x20/0x40 [ 778.313230] ovs_flow_key_extract.cold+0xf/0x14 [openvswitch] [ 778.314532] ovs_vport_receive+0x19e/0x2e0 [openvswitch] [ 778.315749] ? ovs_vport_find_upcall_portid+0x330/0x330 [openvswitch] [ 778.317188] ? create_prof_cpu_mask+0x20/0x20 [ 778.318220] ? arch_stack_walk+0x82/0xf0 [ 778.319153] ? secondary_startup_64_no_verify+0xb0/0xbb [ 778.320399] ? stack_trace_save+0x91/0xc0 [ 778.321362] ? stack_trace_consume_entry+0x160/0x160 [ 778.322517] ? lock_release+0x52e/0x760 [ 778.323444] netdev_frame_hook+0x323/0x610 [openvswitch] [ 778.324668] ? ovs_netdev_get_vport+0xe0/0xe0 [openvswitch] [ 778.325950] __netif_receive_skb_core+0x771/0x2db0 [ 778.327067] ? lock_downgrade+0x6e0/0x6f0 [ 778.328021] ? lock_acquire+0x565/0x720 [ 778.328940] ? generic_xdp_tx+0x4f0/0x4f0 [ 778.329902] ? inet_gro_receive+0x2a7/0x10a0 [ 778.330914] ? lock_downgrade+0x6f0/0x6f0 [ 778.331867] ? udp4_gro_receive+0x4c4/0x13e0 [ 778.332876] ? lock_release+0x52e/0x760 [ 778.333808] ? dev_gro_receive+0xcc8/0x2380 [ 778.334810] ? lock_downgrade+0x6f0/0x6f0 [ 778.335769] __netif_receive_skb_list_core+0x295/0x820 [ 778.336955] ? process_backlog+0x780/0x780 [ 778.337941] ? mlx5e_rep_tc_netdevice_event_unregister+0x20/0x20 [mlx5_core] [ 778.339613] ? seqcount_lockdep_reader_access.constprop.0+0xa7/0xc0 [ 778.341033] ? kvm_clock_get_cycles+0x14/0x20 [ 778.342072] netif_receive_skb_list_internal+0x5f5/0xcb0 [ 778.343288] ? __kasan_kmalloc+0x7a/0x90 [ 778.344234] ? mlx5e_handle_rx_cqe_mpwrq+0x9e0/0x9e0 [mlx5_core] [ 778.345676] ? mlx5e_xmit_xdp_frame_mpwqe+0x14d0/0x14d0 [mlx5_core] [ 778.347140] ? __netif_receive_skb_list_core+0x820/0x820 [ 778.348351] ? mlx5e_post_rx_mpwqes+0xa6/0x25d0 [mlx5_core] [ 778.349688] ? napi_gro_flush+0x26c/0x3c0 [ 778.350641] napi_complete_done+0x188/0x6b0 [ 778.351627] mlx5e_napi_poll+0x373/0x1b80 [mlx5_core] [ 778.352853] __napi_poll+0x9f/0x510 [ 778.353704] ? mlx5_flow_namespace_set_mode+0x260/0x260 [mlx5_core] [ 778.355158] net_rx_action+0x34c/0xa40 [ 778.356060] ? napi_threaded_poll+0x3d0/0x3d0 [ 778.357083] ? sched_clock_cpu+0x18/0x190 [ 778.358041] ? __common_interrupt+0x8e/0x1a0 [ 778.359045] __do_softirq+0x1ce/0x984 [ 778.359938] __irq_exit_rcu+0x137/0x1d0 [ 778.360865] irq_exit_rcu+0xa/0x20 [ 778.361708] common_interrupt+0x80/0xa0 [ 778.362640] [ 778.363212] asm_common_interrupt+0x1e/0x40 [ 778.364204] RIP: 0010:native_safe_halt+0xe/0x10 [ 778.365273] Code: 4f ff ff ff 4c 89 e7 e8 50 3f 40 fe e9 dc fe ff ff 48 89 df e8 43 3f 40 fe eb 90 cc e9 07 00 00 00 0f 00 2d 74 05 62 00 fb f4 90 e9 07 00 00 00 0f 00 2d 64 05 62 00 f4 c3 cc cc 0f 1f 44 00 [ 778.369355] RSP: 0018:ffffffff84407e48 EFLAGS: 00000246 [ 778.370570] RAX: ffff88842de46a80 RBX: ffffffff84425840 RCX: ffffffff83418468 [ 778.372143] RDX: 000000000026f1da RSI: 0000000000000004 RDI: ffffffff8343af5e [ 778.373722] RBP: fffffbfff0884b08 R08: 0000000000000000 R09: ffff88842de46bcb [ 778.375292] R10: ffffed1085bc8d79 R11: 0000000000000001 R12: 0000000000000000 [ 778.376860] R13: ffffffff851124a0 R14: 0000000000000000 R15: dffffc0000000000 [ 778.378491] ? rcu_eqs_enter.constprop.0+0xb8/0xe0 [ 778.379606] ? default_idle_call+0x5e/0xe0 [ 778.380578] default_idle+0xa/0x10 [ 778.381406] default_idle_call+0x96/0xe0 [ 778.382350] do_idle+0x3d4/0x550 [ 778.383153] ? arch_cpu_idle_exit+0x40/0x40 [ 778.384143] cpu_startup_entry+0x19/0x20 [ 778.385078] start_kernel+0x3c7/0x3e5 [ 778.385978] secondary_startup_64_no_verify+0xb0/0xbb Fix the issue by providing new function tc_skb_ext_alloc() that allocates tc skb extension and initializes its memory to 0 before returning it to the caller. Change all existing users to use new API instead of calling skb_ext_add() directly. Fixes: 038ebb1a713d ("net/sched: act_ct: fix miss set mru for ovs after defrag in act_ct") Fixes: d29334c15d33 ("net/sched: act_api: fix miss set post_ct for ovs after do conntrack in act_ct") Signed-off-by: Vlad Buslov Acked-by: Cong Wang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8cad65950b180fc855c7d28daf856a908b4974ba Author: Randy Dunlap Date: Sun May 16 17:54:17 2021 -0700 MIPS: ralink: export rt_sysc_membase for rt2880_wdt.c [ Upstream commit fef532ea0cd871afab7d9a7b6e9da99ac2c24371 ] rt2880_wdt.c uses (well, attempts to use) rt_sysc_membase. However, when this watchdog driver is built as a loadable module, there is a build error since the rt_sysc_membase symbol is not exported. Export it to quell the build error. ERROR: modpost: "rt_sysc_membase" [drivers/watchdog/rt2880_wdt.ko] undefined! Fixes: 473cf939ff34 ("watchdog: add ralink watchdog driver") Signed-off-by: Randy Dunlap Cc: Guenter Roeck Cc: Wim Van Sebroeck Cc: John Crispin Cc: linux-mips@vger.kernel.org Cc: linux-watchdog@vger.kernel.org Acked-by: Guenter Roeck Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit 70a922f590686a5aecbae30a21923289b6eada0a Author: Randy Dunlap Date: Sun May 16 17:01:08 2021 -0700 MIPS: alchemy: xxs1500: add gpio-au1000.h header file [ Upstream commit ff4cff962a7eedc73e54b5096693da7f86c61346 ] board-xxs1500.c references 2 functions without declaring them, so add the header file to placate the build. ../arch/mips/alchemy/board-xxs1500.c: In function 'board_setup': ../arch/mips/alchemy/board-xxs1500.c:56:2: error: implicit declaration of function 'alchemy_gpio1_input_enable' [-Werror=implicit-function-declaration] 56 | alchemy_gpio1_input_enable(); ../arch/mips/alchemy/board-xxs1500.c:57:2: error: implicit declaration of function 'alchemy_gpio2_enable'; did you mean 'alchemy_uart_enable'? [-Werror=implicit-function-declaration] 57 | alchemy_gpio2_enable(); Fixes: 8e026910fcd4 ("MIPS: Alchemy: merge GPR/MTX-1/XXS1500 board code into single files") Signed-off-by: Randy Dunlap Cc: Thomas Bogendoerfer Cc: linux-mips@vger.kernel.org Cc: Manuel Lauss Cc: Ralf Baechle Acked-by: Manuel Lauss Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit f6442ee08fe66c8e45c4f246531a2aaf4f17a7a7 Author: George McCollister Date: Mon May 24 13:50:54 2021 -0500 net: hsr: fix mac_len checks [ Upstream commit 48b491a5cc74333c4a6a82fe21cea42c055a3b0b ] Commit 2e9f60932a2c ("net: hsr: check skb can contain struct hsr_ethhdr in fill_frame_info") added the following which resulted in -EINVAL always being returned: if (skb->mac_len < sizeof(struct hsr_ethhdr)) return -EINVAL; mac_len was not being set correctly so this check completely broke HSR/PRP since it was always 14, not 20. Set mac_len correctly and modify the mac_len checks to test in the correct places since sometimes it is legitimately 14. Fixes: 2e9f60932a2c ("net: hsr: check skb can contain struct hsr_ethhdr in fill_frame_info") Signed-off-by: George McCollister Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit a6a0af3c902c6c9b126755b9c2df92bb46275b3e Author: Taehee Yoo Date: Sun May 23 14:38:53 2021 +0000 sch_dsmark: fix a NULL deref in qdisc_reset() [ Upstream commit 9b76eade16423ef06829cccfe3e100cfce31afcd ] If Qdisc_ops->init() is failed, Qdisc_ops->reset() would be called. When dsmark_init(Qdisc_ops->init()) is failed, it possibly doesn't initialize dsmark_qdisc_data->q. But dsmark_reset(Qdisc_ops->reset()) uses dsmark_qdisc_data->q pointer wihtout any null checking. So, panic would occur. Test commands: sysctl net.core.default_qdisc=dsmark -w ip link add dummy0 type dummy ip link add vw0 link dummy0 type virt_wifi ip link set vw0 up Splat looks like: KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] CPU: 3 PID: 684 Comm: ip Not tainted 5.12.0+ #910 RIP: 0010:qdisc_reset+0x2b/0x680 Code: 1f 44 00 00 48 b8 00 00 00 00 00 fc ff df 41 57 41 56 41 55 41 54 55 48 89 fd 48 83 c7 18 53 48 89 fa 48 c1 ea 03 48 83 ec 20 <80> 3c 02 00 0f 85 09 06 00 00 4c 8b 65 18 0f 1f 44 00 00 65 8b 1d RSP: 0018:ffff88800fda6bf8 EFLAGS: 00010282 RAX: dffffc0000000000 RBX: ffff8880050ed800 RCX: 0000000000000000 RDX: 0000000000000003 RSI: ffffffff99e34100 RDI: 0000000000000018 RBP: 0000000000000000 R08: fffffbfff346b553 R09: fffffbfff346b553 R10: 0000000000000001 R11: fffffbfff346b552 R12: ffffffffc0824940 R13: ffff888109e83800 R14: 00000000ffffffff R15: ffffffffc08249e0 FS: 00007f5042287680(0000) GS:ffff888119800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055ae1f4dbd90 CR3: 0000000006760002 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? rcu_read_lock_bh_held+0xa0/0xa0 dsmark_reset+0x3d/0xf0 [sch_dsmark] qdisc_reset+0xa9/0x680 qdisc_destroy+0x84/0x370 qdisc_create_dflt+0x1fe/0x380 attach_one_default_qdisc.constprop.41+0xa4/0x180 dev_activate+0x4d5/0x8c0 ? __dev_open+0x268/0x390 __dev_open+0x270/0x390 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Taehee Yoo Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit cd751bde9e0dd23d9c512528722f4d8bf0782759 Author: Stefan Roese Date: Sat May 22 09:56:30 2021 +0200 net: ethernet: mtk_eth_soc: Fix packet statistics support for MT7628/88 [ Upstream commit ad79fd2c42f7626bdf6935cd72134c2a5a59ff2d ] The MT7628/88 SoC(s) have other (limited) packet counter registers than currently supported in the mtk_eth_soc driver. This patch adds support for reading these registers, so that the packet statistics are correctly updated. Additionally the defines for the non-MT7628 variant packet counter registers are added and used in this patch instead of using hard coded values. Signed-off-by: Stefan Roese Fixes: 296c9120752b ("net: ethernet: mediatek: Add MT7628/88 SoC support") Cc: Felix Fietkau Cc: John Crispin Cc: Ilya Lipnitskiy Cc: Reto Schneider Cc: Reto Schneider Cc: David S. Miller Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f103ae7c9c8bca7a6f1d237e95445c1e52443081 Author: kernel test robot Date: Sun May 23 02:09:00 2021 +0800 ALSA: usb-audio: scarlett2: snd_scarlett_gen2_controls_create() can be static [ Upstream commit 2b899f31f1a6db2db4608bac2ac04fe2c4ad89eb ] sound/usb/mixer_scarlett_gen2.c:2000:5: warning: symbol 'snd_scarlett_gen2_controls_create' was not declared. Should it be static? Fixes: 265d1a90e4fb ("ALSA: usb-audio: scarlett2: Improve driver startup messages") Reported-by: kernel test robot Signed-off-by: kernel test robot Link: https://lore.kernel.org/r/20210522180900.GA83915@f59a3af2f1d9 Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 5a2e1ce7abc2895fac02234efe1be37a362dbae9 Author: Francesco Ruggeri Date: Fri May 21 13:21:14 2021 -0700 ipv6: record frag_max_size in atomic fragments in input path [ Upstream commit e29f011e8fc04b2cdc742a2b9bbfa1b62518381a ] Commit dbd1759e6a9c ("ipv6: on reassembly, record frag_max_size") filled the frag_max_size field in IP6CB in the input path. The field should also be filled in case of atomic fragments. Fixes: dbd1759e6a9c ('ipv6: on reassembly, record frag_max_size') Signed-off-by: Francesco Ruggeri Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5ac72351655f8b033a2935646f53b7465c903418 Author: Aleksander Jan Bajkowski Date: Fri May 21 16:45:58 2021 +0200 net: lantiq: fix memory corruption in RX ring [ Upstream commit c7718ee96dbc2f9c5fc3b578abdf296dd44b9c20 ] In a situation where memory allocation or dma mapping fails, an invalid address is programmed into the descriptor. This can lead to memory corruption. If the memory allocation fails, DMA should reuse the previous skb and mapping and drop the packet. This patch also increments rx drop counter. Fixes: fe1a56420cf2 ("net: lantiq: Add Lantiq / Intel VRX200 Ethernet driver ") Signed-off-by: Aleksander Jan Bajkowski Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 988439906f6fa243846cd0526bc7175979c89014 Author: Dan Carpenter Date: Wed May 19 17:20:27 2021 +0300 scsi: libsas: Use _safe() loop in sas_resume_port() [ Upstream commit 8c7e7b8486cda21269d393245883c5e4737d5ee7 ] If sas_notify_lldd_dev_found() fails then this code calls: sas_unregister_dev(port, dev); which removes "dev", our list iterator, from the list. This could lead to an endless loop. We need to use list_for_each_entry_safe(). Link: https://lore.kernel.org/r/YKUeq6gwfGcvvhty@mwanda Fixes: 303694eeee5e ("[SCSI] libsas: suspend / resume support") Reviewed-by: John Garry Signed-off-by: Dan Carpenter Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 3a17d8adfa02ea5b1d7719d7dbc5a1727684ee03 Author: Stephen Boyd Date: Wed May 19 18:48:07 2021 -0700 ASoC: qcom: lpass-cpu: Use optional clk APIs [ Upstream commit af2702549d68519ac78228e915d9b2c199056787 ] This driver spits out a warning for me at boot: sc7180-lpass-cpu 62f00000.lpass: asoc_qcom_lpass_cpu_platform_probe() error getting optional null: -2 but it looks like it is all an optional clk. Use the optional clk APIs here so that we don't see this message and everything else is the same. Cc: Srinivas Kandagatla Cc: Banajit Goswami Fixes: 3e53ac8230c1 ("ASoC: qcom: make osr clock optional") Signed-off-by: Stephen Boyd Reviewed-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20210520014807.3749797-1-swboyd@chromium.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 3cfd11506ed032446358eedf7e31b4defd819d91 Author: Jesse Brandeburg Date: Thu May 20 11:18:35 2021 -0700 ixgbe: fix large MTU request from VF [ Upstream commit 63e39d29b3da02e901349f6cd71159818a4737a6 ] Check that the MTU value requested by the VF is in the supported range of MTUs before attempting to set the VF large packet enable, otherwise reject the request. This also avoids unnecessary register updates in the case of the 82599 controller. Fixes: 872844ddb9e4 ("ixgbe: Enable jumbo frames support w/ SR-IOV") Co-developed-by: Piotr Skajewski Signed-off-by: Piotr Skajewski Signed-off-by: Jesse Brandeburg Co-developed-by: Mateusz Palczewski Signed-off-by: Mateusz Palczewski Tested-by: Konrad Jankowski Signed-off-by: Tony Nguyen Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 9948170c8eb41f767a3125e9cfa22e9f6fcd400a Author: Jussi Maki Date: Wed May 19 15:47:42 2021 +0000 bpf: Set mac_len in bpf_skb_change_head [ Upstream commit 84316ca4e100d8cbfccd9f774e23817cb2059868 ] The skb_change_head() helper did not set "skb->mac_len", which is problematic when it's used in combination with skb_redirect_peer(). Without it, redirecting a packet from a L3 device such as wireguard to the veth peer device will cause skb->data to point to the middle of the IP header on entry to tcp_v4_rcv() since the L2 header is not pulled correctly due to mac_len=0. Fixes: 3a0af8fd61f9 ("bpf: BPF for lightweight tunnel infrastructure") Signed-off-by: Jussi Maki Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20210519154743.2554771-2-joamaki@gmail.com Signed-off-by: Sasha Levin commit 24cb8bb7f62367e81242fbec2a8813c4c660098e Author: Yinjun Zhang Date: Thu May 20 10:58:34 2021 +0200 bpf, offload: Reorder offload callback 'prepare' in verifier [ Upstream commit ceb11679d9fcf3fdb358a310a38760fcbe9b63ed ] Commit 4976b718c355 ("bpf: Introduce pseudo_btf_id") switched the order of resolve_pseudo_ldimm(), in which some pseudo instructions are rewritten. Thus those rewritten instructions cannot be passed to driver via 'prepare' offload callback. Reorder the 'prepare' offload callback to fix it. Fixes: 4976b718c355 ("bpf: Introduce pseudo_btf_id") Signed-off-by: Yinjun Zhang Signed-off-by: Simon Horman Signed-off-by: Daniel Borkmann Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20210520085834.15023-1-simon.horman@netronome.com Signed-off-by: Sasha Levin commit 78d5f411615a7d59974c5aa33d572e5ea918ea8f Author: Dan Carpenter Date: Thu May 20 08:08:24 2021 +0300 ASoC: cs35l33: fix an error code in probe() [ Upstream commit 833bc4cf9754643acc69b3c6b65988ca78df4460 ] This error path returns zero (success) but it should return -EINVAL. Fixes: 3333cb7187b9 ("ASoC: cs35l33: Initial commit of the cs35l33 CODEC driver.") Signed-off-by: Dan Carpenter Reviewed-by: Charles Keepax Link: https://lore.kernel.org/r/YKXuyGEzhPT35R3G@mwanda Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit d29df5fc69ee6e9d109c59159d82fffacb381c93 Author: Dan Carpenter Date: Wed May 19 17:16:50 2021 +0300 staging: emxx_udc: fix loop in _nbu2ss_nuke() [ Upstream commit e0112a7c9e847ada15a631b88e279d547e8f26a7 ] The _nbu2ss_ep_done() function calls: list_del_init(&req->queue); which means that the loop will never exit. Fixes: ca3d253eb967 ("Staging: emxx_udc: Iterate list using list_for_each_entry") Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/YKUd0sDyjm/lkJfJ@mwanda Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 02f03883fdb10ad7e66717c70ea163a8d27ae6e7 Author: Raju Rangoju Date: Wed May 19 16:48:31 2021 +0530 cxgb4: avoid accessing registers when clearing filters [ Upstream commit 88c380df84fbd03f9b137c2b9d0a44b9f2f553b0 ] Hardware register having the server TID base can contain invalid values when adapter is in bad state (for example, due to AER fatal error). Reading these invalid values in the register can lead to out-of-bound memory access. So, fix by using the saved server TID base when clearing filters. Fixes: b1a79360ee86 ("cxgb4: Delete all hash and TCAM filters before resource cleanup") Signed-off-by: Raju Rangoju Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit a5212518b78c05150d675abb280cae194c564122 Author: Lu Baolu Date: Wed May 19 09:50:27 2021 +0800 iommu/vt-d: Use user privilege for RID2PASID translation [ Upstream commit 54c80d907400189b09548039be8f3b6e297e8ae3 ] When first-level page tables are used for IOVA translation, we use user privilege by setting U/S bit in the page table entry. This is to make it consistent with the second level translation, where the U/S enforcement is not available. Clear the SRE (Supervisor Request Enable) field in the pasid table entry of RID2PASID so that requests requesting the supervisor privilege are blocked and treated as DMA remapping faults. Fixes: b802d070a52a1 ("iommu/vt-d: Use iova over first level") Suggested-by: Jacob Pan Signed-off-by: Lu Baolu Link: https://lore.kernel.org/r/20210512064426.3440915-1-baolu.lu@linux.intel.com Link: https://lore.kernel.org/r/20210519015027.108468-3-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit a663c1e418a3b5b8e8edfad4bc8e7278c312d6fc Author: Jian Shen Date: Tue May 18 19:36:01 2021 +0800 net: hns3: put off calling register_netdev() until client initialize complete [ Upstream commit a289a7e5c1d49b7d47df9913c1cc81fb48fab613 ] Currently, the netdevice is registered before client initializing complete. So there is a timewindow between netdevice available and usable. In this case, if user try to change the channel number or ring param, it may cause the hns3_set_rx_cpu_rmap() being called twice, and report bug. [47199.416502] hns3 0000:35:00.0 eth1: set channels: tqp_num=1, rxfh=0 [47199.430340] hns3 0000:35:00.0 eth1: already uninitialized [47199.438554] hns3 0000:35:00.0: rss changes from 4 to 1 [47199.511854] hns3 0000:35:00.0: Channels changed, rss_size from 4 to 1, tqps from 4 to 1 [47200.163524] ------------[ cut here ]------------ [47200.171674] kernel BUG at lib/cpu_rmap.c:142! [47200.177847] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP [47200.185259] Modules linked in: hclge(+) hns3(-) hns3_cae(O) hns_roce_hw_v2 hnae3 vfio_iommu_type1 vfio_pci vfio_virqfd vfio pv680_mii(O) [last unloaded: hclge] [47200.205912] CPU: 1 PID: 8260 Comm: ethtool Tainted: G O 5.11.0-rc3+ #1 [47200.215601] Hardware name: , xxxxxx 02/04/2021 [47200.223052] pstate: 60400009 (nZCv daif +PAN -UAO -TCO BTYPE=--) [47200.230188] pc : cpu_rmap_add+0x38/0x40 [47200.237472] lr : irq_cpu_rmap_add+0x84/0x140 [47200.243291] sp : ffff800010e93a30 [47200.247295] x29: ffff800010e93a30 x28: ffff082100584880 [47200.254155] x27: 0000000000000000 x26: 0000000000000000 [47200.260712] x25: 0000000000000000 x24: 0000000000000004 [47200.267241] x23: ffff08209ba03000 x22: ffff08209ba038c0 [47200.273789] x21: 000000000000003f x20: ffff0820e2bc1680 [47200.280400] x19: ffff0820c970ec80 x18: 00000000000000c0 [47200.286944] x17: 0000000000000000 x16: ffffb43debe4a0d0 [47200.293456] x15: fffffc2082990600 x14: dead000000000122 [47200.300059] x13: ffffffffffffffff x12: 000000000000003e [47200.306606] x11: ffff0820815b8080 x10: ffff53e411988000 [47200.313171] x9 : 0000000000000000 x8 : ffff0820e2bc1700 [47200.319682] x7 : 0000000000000000 x6 : 000000000000003f [47200.326170] x5 : 0000000000000040 x4 : ffff800010e93a20 [47200.332656] x3 : 0000000000000004 x2 : ffff0820c970ec80 [47200.339168] x1 : ffff0820e2bc1680 x0 : 0000000000000004 [47200.346058] Call trace: [47200.349324] cpu_rmap_add+0x38/0x40 [47200.354300] hns3_set_rx_cpu_rmap+0x6c/0xe0 [hns3] [47200.362294] hns3_reset_notify_init_enet+0x1cc/0x340 [hns3] [47200.370049] hns3_change_channels+0x40/0xb0 [hns3] [47200.376770] hns3_set_channels+0x12c/0x2a0 [hns3] [47200.383353] ethtool_set_channels+0x140/0x250 [47200.389772] dev_ethtool+0x714/0x23d0 [47200.394440] dev_ioctl+0x4cc/0x640 [47200.399277] sock_do_ioctl+0x100/0x2a0 [47200.404574] sock_ioctl+0x28c/0x470 [47200.409079] __arm64_sys_ioctl+0xb4/0x100 [47200.415217] el0_svc_common.constprop.0+0x84/0x210 [47200.422088] do_el0_svc+0x28/0x34 [47200.426387] el0_svc+0x28/0x70 [47200.431308] el0_sync_handler+0x1a4/0x1b0 [47200.436477] el0_sync+0x174/0x180 [47200.441562] Code: 11000405 79000c45 f8247861 d65f03c0 (d4210000) [47200.448869] ---[ end trace a01efe4ce42e5f34 ]--- The process is like below: excuting hns3_client_init | register_netdev() | hns3_set_channels() | | hns3_set_rx_cpu_rmap() hns3_reset_notify_uninit_enet() | | | quit without calling function | hns3_free_rx_cpu_rmap for flag | HNS3_NIC_STATE_INITED is unset. | | | hns3_reset_notify_init_enet() | | set HNS3_NIC_STATE_INITED call hns3_set_rx_cpu_rmap()-- crash Fix it by calling register_netdev() at the end of function hns3_client_init(). Fixes: 08a100689d4b ("net: hns3: re-organize vector handle") Signed-off-by: Jian Shen Signed-off-by: Huazhong Tan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 09867c500ec41e9b5a942d111554023a8c57cb72 Author: Jiaran Zhang Date: Tue May 18 19:36:00 2021 +0800 net: hns3: fix incorrect resp_msg issue [ Upstream commit a710b9ffbebaf713f7dbd4dbd9524907e5d66f33 ] In hclge_mbx_handler(), if there are two consecutive mailbox messages that requires resp_msg, the resp_msg is not cleared after processing the first message, which will cause the resp_msg data of second message incorrect. Fix it by clearing the resp_msg before processing every mailbox message. Fixes: bb5790b71bad ("net: hns3: refactor mailbox response scheme between PF and VF") Signed-off-by: Jiaran Zhang Signed-off-by: Huazhong Tan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 815eb57e048b3cbb7c0b9c51105086c4c75fcb27 Author: Bixuan Cui Date: Sat May 8 11:14:51 2021 +0800 iommu/virtio: Add missing MODULE_DEVICE_TABLE [ Upstream commit 382d91fc0f4f1b13f8a0dcbf7145f4f175b71a18 ] This patch adds missing MODULE_DEVICE_TABLE definition which generates correct modalias for automatic loading of this driver when it is built as an external module. Reported-by: Hulk Robot Signed-off-by: Bixuan Cui Fixes: fa4afd78ea12 ("iommu/virtio: Build virtio-iommu as module") Reviewed-by: Jean-Philippe Brucker Link: https://lore.kernel.org/r/20210508031451.53493-1-cuibixuan@huawei.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 8e534c981d7c45ecb6702178e9ea79d10313f63e Author: David Awogbemila Date: Mon May 17 14:08:15 2021 -0700 gve: Correct SKB queue index validation. [ Upstream commit fbd4a28b4fa66faaa7f510c0adc531d37e0a7848 ] SKBs with skb_get_queue_mapping(skb) == tx_cfg.num_queues should also be considered invalid. Fixes: f5cedc84a30d ("gve: Add transmit and receive support") Signed-off-by: David Awogbemila Acked-by: Willem de Brujin Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 48f4ddec0ab9895fde6f2b0d8a091747043e64cd Author: Catherine Sullivan Date: Mon May 17 14:08:14 2021 -0700 gve: Upgrade memory barrier in poll routine [ Upstream commit f81781835f0adfae8d701545386030d223efcd6f ] As currently written, if the driver checks for more work (via gve_tx_poll or gve_rx_poll) before the device posts work and the irq doorbell is not unmasked (via iowrite32be(GVE_IRQ_ACK | GVE_IRQ_EVENT, ...)) before the device attempts to raise an interrupt, an interrupt is lost and this could potentially lead to the traffic being completely halted. For example, if a tx queue has already been stopped, the driver won't get the chance to complete work and egress will be halted. We need a full memory barrier in the poll routine to ensure that the irq doorbell is unmasked before the driver checks for more work. Fixes: f5cedc84a30d ("gve: Add transmit and receive support") Signed-off-by: Catherine Sullivan Signed-off-by: David Awogbemila Acked-by: Willem de Brujin Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit da21a35c00ff1a1794d4f166d3b3fa8db4d0f6fb Author: David Awogbemila Date: Mon May 17 14:08:13 2021 -0700 gve: Add NULL pointer checks when freeing irqs. [ Upstream commit 5218e919c8d06279884aa0baf76778a6817d5b93 ] When freeing notification blocks, we index priv->msix_vectors. If we failed to allocate priv->msix_vectors (see abort_with_msix_vectors) this could lead to a NULL pointer dereference if the driver is unloaded. Fixes: 893ce44df565 ("gve: Add basic driver framework for Compute Engine Virtual NIC") Signed-off-by: David Awogbemila Acked-by: Willem de Brujin Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7114438671d6ad4be746ad13d74f278db273db0c Author: David Awogbemila Date: Mon May 17 14:08:12 2021 -0700 gve: Update mgmt_msix_idx if num_ntfy changes [ Upstream commit e96b491a0ffa35a8a9607c193fa4d894ca9fb32f ] If we do not get the expected number of vectors from pci_enable_msix_range, we update priv->num_ntfy_blks but not priv->mgmt_msix_idx. This patch fixes this so that priv->mgmt_msix_idx is updated accordingly. Fixes: f5cedc84a30d ("gve: Add transmit and receive support") Signed-off-by: David Awogbemila Acked-by: Willem de Bruijn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b6ef5bfcd9d758ad0071c5623f33844808d7e81f Author: Catherine Sullivan Date: Mon May 17 14:08:11 2021 -0700 gve: Check TX QPL was actually assigned [ Upstream commit 5aec55b46c6238506cdf0c60cd0e42ab77a1e5e0 ] Correctly check the TX QPL was assigned and unassigned if other steps in the allocation fail. Fixes: f5cedc84a30d (gve: Add transmit and receive support) Signed-off-by: Catherine Sullivan Signed-off-by: David Awogbemila Acked-by: Willem de Bruijn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8b2cdc004d21a7255f219706dca64411108f7897 Author: Julian Wiedmann Date: Mon May 17 10:47:06 2021 +0200 net/smc: remove device from smcd_dev_list after failed device_add() [ Upstream commit 444d7be9532dcfda8e0385226c862fd7e986f607 ] If the device_add() for a smcd_dev fails, there's no cleanup step that rolls back the earlier list_add(). The device subsequently gets freed, and we end up with a corrupted list. Add some error handling that removes the device from the list. Fixes: c6ba7c9ba43d ("net/smc: add base infrastructure for SMC-D and ISM") Signed-off-by: Julian Wiedmann Signed-off-by: Karsten Graul Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit beb39adb150f8f3b516ddf7c39835a9788704d23 Author: Taehee Yoo Date: Sun May 16 14:44:42 2021 +0000 mld: fix panic in mld_newpack() [ Upstream commit 020ef930b826d21c5446fdc9db80fd72a791bc21 ] mld_newpack() doesn't allow to allocate high order page, only order-0 allocation is allowed. If headroom size is too large, a kernel panic could occur in skb_put(). Test commands: ip netns del A ip netns del B ip netns add A ip netns add B ip link add veth0 type veth peer name veth1 ip link set veth0 netns A ip link set veth1 netns B ip netns exec A ip link set lo up ip netns exec A ip link set veth0 up ip netns exec A ip -6 a a 2001:db8:0::1/64 dev veth0 ip netns exec B ip link set lo up ip netns exec B ip link set veth1 up ip netns exec B ip -6 a a 2001:db8:0::2/64 dev veth1 for i in {1..99} do let A=$i-1 ip netns exec A ip link add ip6gre$i type ip6gre \ local 2001:db8:$A::1 remote 2001:db8:$A::2 encaplimit 100 ip netns exec A ip -6 a a 2001:db8:$i::1/64 dev ip6gre$i ip netns exec A ip link set ip6gre$i up ip netns exec B ip link add ip6gre$i type ip6gre \ local 2001:db8:$A::2 remote 2001:db8:$A::1 encaplimit 100 ip netns exec B ip -6 a a 2001:db8:$i::2/64 dev ip6gre$i ip netns exec B ip link set ip6gre$i up done Splat looks like: kernel BUG at net/core/skbuff.c:110! invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI CPU: 0 PID: 7 Comm: kworker/0:1 Not tainted 5.12.0+ #891 Workqueue: ipv6_addrconf addrconf_dad_work RIP: 0010:skb_panic+0x15d/0x15f Code: 92 fe 4c 8b 4c 24 10 53 8b 4d 70 45 89 e0 48 c7 c7 00 ae 79 83 41 57 41 56 41 55 48 8b 54 24 a6 26 f9 ff <0f> 0b 48 8b 6c 24 20 89 34 24 e8 4a 4e 92 fe 8b 34 24 48 c7 c1 20 RSP: 0018:ffff88810091f820 EFLAGS: 00010282 RAX: 0000000000000089 RBX: ffff8881086e9000 RCX: 0000000000000000 RDX: 0000000000000089 RSI: 0000000000000008 RDI: ffffed1020123efb RBP: ffff888005f6eac0 R08: ffffed1022fc0031 R09: ffffed1022fc0031 R10: ffff888117e00187 R11: ffffed1022fc0030 R12: 0000000000000028 R13: ffff888008284eb0 R14: 0000000000000ed8 R15: 0000000000000ec0 FS: 0000000000000000(0000) GS:ffff888117c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f8b801c5640 CR3: 0000000033c2c006 CR4: 00000000003706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? ip6_mc_hdr.isra.26.constprop.46+0x12a/0x600 ? ip6_mc_hdr.isra.26.constprop.46+0x12a/0x600 skb_put.cold.104+0x22/0x22 ip6_mc_hdr.isra.26.constprop.46+0x12a/0x600 ? rcu_read_lock_sched_held+0x91/0xc0 mld_newpack+0x398/0x8f0 ? ip6_mc_hdr.isra.26.constprop.46+0x600/0x600 ? lock_contended+0xc40/0xc40 add_grhead.isra.33+0x280/0x380 add_grec+0x5ca/0xff0 ? mld_sendpack+0xf40/0xf40 ? lock_downgrade+0x690/0x690 mld_send_initial_cr.part.34+0xb9/0x180 ipv6_mc_dad_complete+0x15d/0x1b0 addrconf_dad_completed+0x8d2/0xbb0 ? lock_downgrade+0x690/0x690 ? addrconf_rs_timer+0x660/0x660 ? addrconf_dad_work+0x73c/0x10e0 addrconf_dad_work+0x73c/0x10e0 Allowing high order page allocation could fix this problem. Fixes: 72e09ad107e7 ("ipv6: avoid high order allocations") Signed-off-by: Taehee Yoo Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7e31bcbb335ec8cc4b948915e652d013a5816371 Author: Michael Chan Date: Sat May 15 03:25:19 2021 -0400 bnxt_en: Fix context memory setup for 64K page size. [ Upstream commit 702279d2ce4650000bb6302013630304e359dc13 ] There was a typo in the code that checks for 64K BNXT_PAGE_SHIFT in bnxt_hwrm_set_pg_attr(). Fix it and make the code more understandable with a new macro BNXT_SET_CTX_PAGE_ATTR(). Fixes: 1b9394e5a2ad ("bnxt_en: Configure context memory on new devices.") Reviewed-by: Edwin Peer Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4ebb03c9ffbe089280c6bc020473f5bbe97994c3 Author: Andy Gospodarek Date: Sat May 15 03:25:18 2021 -0400 bnxt_en: Include new P5 HV definition in VF check. [ Upstream commit ab21494be9dc7d62736c5fcd06be65d49df713ee ] Otherwise, some of the recently added HyperV VF IDs would not be recognized as VF devices and they would not initialize properly. Fixes: 7fbf359bb2c1 ("bnxt_en: Add PCI IDs for Hyper-V VF devices.") Reviewed-by: Edwin Peer Signed-off-by: Andy Gospodarek Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8f793568b02ec96e203edfde11ef164347aaaaf3 Author: Zhen Lei Date: Sat May 15 15:16:05 2021 +0800 net: bnx2: Fix error return code in bnx2_init_board() [ Upstream commit 28c66b6da4087b8cfe81c2ec0a46eb6116dafda9 ] Fix to return -EPERM from the error handling case instead of 0, as done elsewhere in this function. Fixes: b6016b767397 ("[BNX2]: New Broadcom gigabit network driver.") Reported-by: Hulk Robot Signed-off-by: Zhen Lei Reviewed-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8eaca8d1caac22e826055369225d5718119e3f80 Author: Dan Carpenter Date: Fri May 14 17:24:48 2021 +0300 net: hso: check for allocation failure in hso_create_bulk_serial_device() [ Upstream commit 31db0dbd72444abe645d90c20ecb84d668f5af5e ] In current kernels, small allocations never actually fail so this patch shouldn't affect runtime. Originally this error handling code written with the idea that if the "serial->tiocmget" allocation failed, then we would continue operating instead of bailing out early. But in later years we added an unchecked dereference on the next line. serial->tiocmget->serial_state_notification = kzalloc(); ^^^^^^^^^^^^^^^^^^ Since these allocations are never going fail in real life, this is mostly a philosophical debate, but I think bailing out early is the correct behavior that the user would want. And generally it's safer to bail as soon an error happens. Fixes: af0de1303c4e ("usb: hso: obey DMA rules in tiocmget") Signed-off-by: Dan Carpenter Reviewed-by: Johan Hovold Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f9fc21e2b11eb861a903aec8009dc03d9202933a Author: Yunsheng Lin Date: Fri May 14 11:17:01 2021 +0800 net: sched: fix tx action reschedule issue with stopped queue [ Upstream commit dcad9ee9e0663d74a89b25b987f9c7be86432812 ] The netdev qeueue might be stopped when byte queue limit has reached or tx hw ring is full, net_tx_action() may still be rescheduled if STATE_MISSED is set, which consumes unnecessary cpu without dequeuing and transmiting any skb because the netdev queue is stopped, see qdisc_run_end(). This patch fixes it by checking the netdev queue state before calling qdisc_run() and clearing STATE_MISSED if netdev queue is stopped during qdisc_run(), the net_tx_action() is rescheduled again when netdev qeueue is restarted, see netif_tx_wake_queue(). As there is time window between netif_xmit_frozen_or_stopped() checking and STATE_MISSED clearing, between which STATE_MISSED may set by net_tx_action() scheduled by netif_tx_wake_queue(), so set the STATE_MISSED again if netdev queue is restarted. Fixes: 6b3ba9146fe6 ("net: sched: allow qdiscs to handle locking") Reported-by: Michal Kubecek Acked-by: Jakub Kicinski Signed-off-by: Yunsheng Lin Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 2f23d5bcd9f89c239da83abd6270f5f0d9dd95bc Author: Yunsheng Lin Date: Fri May 14 11:17:00 2021 +0800 net: sched: fix tx action rescheduling issue during deactivation [ Upstream commit 102b55ee92f9fda4dde7a45d2b20538e6e3e3d1e ] Currently qdisc_run() checks the STATE_DEACTIVATED of lockless qdisc before calling __qdisc_run(), which ultimately clear the STATE_MISSED when all the skb is dequeued. If STATE_DEACTIVATED is set before clearing STATE_MISSED, there may be rescheduling of net_tx_action() at the end of qdisc_run_end(), see below: CPU0(net_tx_atcion) CPU1(__dev_xmit_skb) CPU2(dev_deactivate) . . . . set STATE_MISSED . . __netif_schedule() . . . set STATE_DEACTIVATED . . qdisc_reset() . . . .<--------------- . synchronize_net() clear __QDISC_STATE_SCHED | . . . | . . . | . some_qdisc_is_busy() . | . return *false* . | . . test STATE_DEACTIVATED | . . __qdisc_run() *not* called | . . . | . . test STATE_MISS | . . __netif_schedule()--------| . . . . . . . . __qdisc_run() is not called by net_tx_atcion() in CPU0 because CPU2 has set STATE_DEACTIVATED flag during dev_deactivate(), and STATE_MISSED is only cleared in __qdisc_run(), __netif_schedule is called at the end of qdisc_run_end(), causing tx action rescheduling problem. qdisc_run() called by net_tx_action() runs in the softirq context, which should has the same semantic as the qdisc_run() called by __dev_xmit_skb() protected by rcu_read_lock_bh(). And there is a synchronize_net() between STATE_DEACTIVATED flag being set and qdisc_reset()/some_qdisc_is_busy in dev_deactivate(), we can safely bail out for the deactived lockless qdisc in net_tx_action(), and qdisc_reset() will reset all skb not dequeued yet. So add the rcu_read_lock() explicitly to protect the qdisc_run() and do the STATE_DEACTIVATED checking in net_tx_action() before calling qdisc_run_begin(). Another option is to do the checking in the qdisc_run_end(), but it will add unnecessary overhead for non-tx_action case, because __dev_queue_xmit() will not see qdisc with STATE_DEACTIVATED after synchronize_net(), the qdisc with STATE_DEACTIVATED can only be seen by net_tx_action() because of __netif_schedule(). The STATE_DEACTIVATED checking in qdisc_run() is to avoid race between net_tx_action() and qdisc_reset(), see: commit d518d2ed8640 ("net/sched: fix race between deactivation and dequeue for NOLOCK qdisc"). As the bailout added above for deactived lockless qdisc in net_tx_action() provides better protection for the race without calling qdisc_run() at all, so remove the STATE_DEACTIVATED checking in qdisc_run(). After qdisc_reset(), there is no skb in qdisc to be dequeued, so clear the STATE_MISSED in dev_reset_queue() too. Fixes: 6b3ba9146fe6 ("net: sched: allow qdiscs to handle locking") Acked-by: Jakub Kicinski Signed-off-by: Yunsheng Lin V8: Clearing STATE_MISSED before calling __netif_schedule() has avoid the endless rescheduling problem, but there may still be a unnecessary rescheduling, so adjust the commit log. Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 21c71510925308a1d81513e1519165c063d1b57c Author: Yunsheng Lin Date: Fri May 14 11:16:59 2021 +0800 net: sched: fix packet stuck problem for lockless qdisc [ Upstream commit a90c57f2cedd52a511f739fb55e6244e22e1a2fb ] Lockless qdisc has below concurrent problem: cpu0 cpu1 . . q->enqueue . . . qdisc_run_begin() . . . dequeue_skb() . . . sch_direct_xmit() . . . . q->enqueue . qdisc_run_begin() . return and do nothing . . qdisc_run_end() . cpu1 enqueue a skb without calling __qdisc_run() because cpu0 has not released the lock yet and spin_trylock() return false for cpu1 in qdisc_run_begin(), and cpu0 do not see the skb enqueued by cpu1 when calling dequeue_skb() because cpu1 may enqueue the skb after cpu0 calling dequeue_skb() and before cpu0 calling qdisc_run_end(). Lockless qdisc has below another concurrent problem when tx_action is involved: cpu0(serving tx_action) cpu1 cpu2 . . . . q->enqueue . . qdisc_run_begin() . . dequeue_skb() . . . q->enqueue . . . . sch_direct_xmit() . . . qdisc_run_begin() . . return and do nothing . . . clear __QDISC_STATE_SCHED . . qdisc_run_begin() . . return and do nothing . . . . . . qdisc_run_end() . This patch fixes the above data race by: 1. If the first spin_trylock() return false and STATE_MISSED is not set, set STATE_MISSED and retry another spin_trylock() in case other CPU may not see STATE_MISSED after it releases the lock. 2. reschedule if STATE_MISSED is set after the lock is released at the end of qdisc_run_end(). For tx_action case, STATE_MISSED is also set when cpu1 is at the end if qdisc_run_end(), so tx_action will be rescheduled again to dequeue the skb enqueued by cpu2. Clear STATE_MISSED before retrying a dequeuing when dequeuing returns NULL in order to reduce the overhead of the second spin_trylock() and __netif_schedule() calling. Also clear the STATE_MISSED before calling __netif_schedule() at the end of qdisc_run_end() to avoid doing another round of dequeuing in the pfifo_fast_dequeue(). The performance impact of this patch, tested using pktgen and dummy netdev with pfifo_fast qdisc attached: threads without+this_patch with+this_patch delta 1 2.61Mpps 2.60Mpps -0.3% 2 3.97Mpps 3.82Mpps -3.7% 4 5.62Mpps 5.59Mpps -0.5% 8 2.78Mpps 2.77Mpps -0.3% 16 2.22Mpps 2.22Mpps -0.0% Fixes: 6b3ba9146fe6 ("net: sched: allow qdiscs to handle locking") Acked-by: Jakub Kicinski Tested-by: Juergen Gross Signed-off-by: Yunsheng Lin Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 60e2193a600a3abee933ba0267e30794fcd0f20e Author: Jim Ma Date: Fri May 14 11:11:02 2021 +0800 tls splice: check SPLICE_F_NONBLOCK instead of MSG_DONTWAIT [ Upstream commit 974271e5ed45cfe4daddbeb16224a2156918530e ] In tls_sw_splice_read, checkout MSG_* is inappropriate, should use SPLICE_*, update tls_wait_data to accept nonblock arguments instead of flags for recvmsg and splice. Fixes: c46234ebb4d1 ("tls: RX path for ktls") Signed-off-by: Jim Ma Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 886dd7f3e9d3e72f643159dbd060d489fb44fd90 Author: Tao Liu Date: Thu May 13 21:08:00 2021 +0800 openvswitch: meter: fix race when getting now_ms. [ Upstream commit e4df1b0c24350a0f00229ff895a91f1072bd850d ] We have observed meters working unexpected if traffic is 3+Gbit/s with multiple connections. now_ms is not pretected by meter->lock, we may get a negative long_delta_ms when another cpu updated meter->used, then: delta_ms = (u32)long_delta_ms; which will be a large value. band->bucket += delta_ms * band->rate; then we get a wrong band->bucket. OpenVswitch userspace datapath has fixed the same issue[1] some time ago, and we port the implementation to kernel datapath. [1] https://patchwork.ozlabs.org/project/openvswitch/patch/20191025114436.9746-1-i.maximets@ovn.org/ Fixes: 96fbc13d7e77 ("openvswitch: Add meter infrastructure") Signed-off-by: Tao Liu Suggested-by: Ilya Maximets Reviewed-by: Ilya Maximets Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b96adbf6601d76ee0bdd9bfa5bcdd0cdd5333d78 Author: Ayush Sawal Date: Thu May 13 15:11:51 2021 +0530 cxgb4/ch_ktls: Clear resources when pf4 device is removed [ Upstream commit 65e302a9bd57b62872040d57eea1201562a7cbb2 ] This patch maintain the list of active tids and clear all the active connection resources when DETACH notification comes. Fixes: a8c16e8ed624f ("crypto/chcr: move nic TLS functionality to drivers/net") Signed-off-by: Ayush Sawal Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit ada298f861a306f30ffe1ae0014491865bdfee82 Author: Christophe JAILLET Date: Thu May 13 09:24:55 2021 +0200 net: mdio: octeon: Fix some double free issues [ Upstream commit e1d027dd97e1e750669cdc0d3b016a4f54e473eb ] 'bus->mii_bus' has been allocated with 'devm_mdiobus_alloc_size()' in the probe function. So it must not be freed explicitly or there will be a double free. Remove the incorrect 'mdiobus_free' in the error handling path of the probe function and in remove function. Suggested-By: Andrew Lunn Fixes: 35d2aeac9810 ("phy: mdio-octeon: Use devm_mdiobus_alloc_size()") Signed-off-by: Christophe JAILLET Reviewed-by: Russell King Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4bd833bb5e856d632569dcbf93bf2c5955fb6156 Author: Christophe JAILLET Date: Thu May 13 09:44:49 2021 +0200 net: mdio: thunder: Fix a double free issue in the .remove function [ Upstream commit a93a0a15876d2a077a3bc260b387d2457a051f24 ] 'bus->mii_bus' have been allocated with 'devm_mdiobus_alloc_size()' in the probe function. So it must not be freed explicitly or there will be a double free. Remove the incorrect 'mdiobus_free' in the remove function. Fixes: 379d7ac7ca31 ("phy: mdio-thunder: Add driver for Cavium Thunder SoC MDIO buses.") Signed-off-by: Christophe JAILLET Reviewed-by: Russell King Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4246f7dc354f29b8b8a81f4f4579a9bdbfe06360 Author: Dan Carpenter Date: Wed May 12 13:02:48 2021 +0300 chelsio/chtls: unlock on error in chtls_pt_recvmsg() [ Upstream commit 832ce924b1a14e139e184a6da9f5a69a5e47b256 ] This error path needs to release some memory and call release_sock(sk); before returning. Fixes: 6919a8264a32 ("Crypto/chtls: add/delete TLS header in driver") Signed-off-by: Dan Carpenter Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8ee7ef4a57a9e1228b6f345aaa70aa8951c7e9cd Author: Fugang Duan Date: Wed May 12 10:43:59 2021 +0800 net: fec: fix the potential memory leak in fec_enet_init() [ Upstream commit 619fee9eb13b5d29e4267cb394645608088c28a8 ] If the memory allocated for cbd_base is failed, it should free the memory allocated for the queues, otherwise it causes memory leak. And if the memory allocated for the queues is failed, it can return error directly. Fixes: 59d0f7465644 ("net: fec: init multi queue date structure") Signed-off-by: Fugang Duan Signed-off-by: Joakim Zhang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 9c386011fa61ade4b20de22eb4f60b2b893ab0d4 Author: Richard Sanger Date: Wed May 12 13:31:22 2021 +1200 net: packetmmap: fix only tx timestamp on request [ Upstream commit 171c3b151118a2fe0fc1e2a9d1b5a1570cfe82d2 ] The packetmmap tx ring should only return timestamps if requested via setsockopt PACKET_TIMESTAMP, as documented. This allows compatibility with non-timestamp aware user-space code which checks tp_status == TP_STATUS_AVAILABLE; not expecting additional timestamp flags to be set in tp_status. Fixes: b9c32fb27170 ("packet: if hw/sw ts enabled in rx/tx ring, report which ts we got") Cc: Daniel Borkmann Cc: Willem de Bruijn Signed-off-by: Richard Sanger Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 1f1b431a4fcd96a6be85ab5a61bd874960d182cf Author: Paolo Abeni Date: Tue May 11 10:35:21 2021 +0200 net: really orphan skbs tied to closing sk [ Upstream commit 098116e7e640ba677d9e345cbee83d253c13d556 ] If the owing socket is shutting down - e.g. the sock reference count already dropped to 0 and only sk_wmem_alloc is keeping the sock alive, skb_orphan_partial() becomes a no-op. When forwarding packets over veth with GRO enabled, the above causes refcount errors. This change addresses the issue with a plain skb_orphan() call in the critical scenario. Fixes: 9adc89af724f ("net: let skb_orphan_partial wake-up waiters.") Signed-off-by: Paolo Abeni Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f5da0820c59da3e5895735e2a4a39ff7d4c1308f Author: Andy Shevchenko Date: Tue May 11 17:09:12 2021 +0300 spi: Assume GPIO CS active high in ACPI case [ Upstream commit 6b69546912a57ff8c31061f98e56383cc0beffd3 ] Currently GPIO CS handling, when descriptors are in use, doesn't take into consideration that in ACPI case the default polarity is Active High and can't be altered. Instead we have to use the per-chip definition provided by SPISerialBus() resource. Fixes: 766c6b63aa04 ("spi: fix client driver breakages when using GPIO descriptors") Cc: Liguang Zhang Cc: Jay Fang Cc: Sven Van Asbroeck Signed-off-by: Andy Shevchenko Tested-by: Xin Hao Link: https://lore.kernel.org/r/20210511140912.30757-1-andriy.shevchenko@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit cd37040ba9312e840839eecfa69e0623751098d5 Author: Eric Farman Date: Tue May 11 21:56:29 2021 +0200 vfio-ccw: Check initialized flag in cp_init() [ Upstream commit c6c82e0cd8125d30f2f1b29205c7e1a2f1a6785b ] We have a really nice flag in the channel_program struct that indicates if it had been initialized by cp_init(), and use it as a guard in the other cp accessor routines, but not for a duplicate call into cp_init(). The possibility of this occurring is low, because that flow is protected by the private->io_mutex and FSM CP_PROCESSING state. But then why bother checking it in (for example) cp_prefetch() then? Let's just be consistent and check for that in cp_init() too. Fixes: 71189f263f8a3 ("vfio-ccw: make it safe to access channel programs") Signed-off-by: Eric Farman Reviewed-by: Cornelia Huck Acked-by: Matthew Rosato Message-Id: <20210511195631.3995081-2-farman@linux.ibm.com> Signed-off-by: Cornelia Huck Signed-off-by: Sasha Levin commit ee67cbc13fc5c512b9211314466e814f071884e2 Author: Alex Elder Date: Tue May 11 14:42:04 2021 -0500 net: ipa: memory region array is variable size [ Upstream commit 440c3247cba3d9433ac435d371dd7927d68772a7 ] IPA configuration data includes an array of memory region descriptors. That was a fixed-size array at one time, but at some point we started defining it such that it was only as big as required for a given platform. The actual number of entries in the array is recorded in the configuration data along with the array. A loop in ipa_mem_config() still assumes the array has entries for all defined memory region IDs. As a result, this loop can go past the end of the actual array and attempt to write "canary" values based on nonsensical data. Fix this, by stashing the number of entries in the array, and using that rather than IPA_MEM_COUNT in the initialization loop found in ipa_mem_config(). The only remaining use of IPA_MEM_COUNT is in a validation check to ensure configuration data doesn't have too many entries. That's fine for now. Fixes: 3128aae8c439a ("net: ipa: redefine struct ipa_mem_data") Signed-off-by: Alex Elder Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit bf5c8f984f7f71f7f792d2cdc657e66fe60db397 Author: Joakim Zhang Date: Mon May 10 14:55:09 2021 +0800 net: stmmac: Fix MAC WoL not working if PHY does not support WoL [ Upstream commit 576f9eacc680d2b1f37e8010cff62f7b227ea769 ] Both get and set WoL will check device_can_wakeup(), if MAC supports PMT, it will set device wakeup capability. After commit 1d8e5b0f3f2c ("net: stmmac: Support WOL with phy"), device wakeup capability will be overwrite in stmmac_init_phy() according to phy's Wol feature. If phy doesn't support WoL, then MAC will lose wakeup capability. To fix this issue, only overwrite device wakeup capability when MAC doesn't support PMT. For STMMAC now driver checks MAC's WoL capability if MAC supports PMT, if not support, driver will check PHY's WoL capability. Fixes: 1d8e5b0f3f2c ("net: stmmac: Support WOL with phy") Reviewed-by: Jisheng Zhang Signed-off-by: Joakim Zhang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 95cfa6c030477e790ac089826aa92bd52a84f72c Author: Richard Fitzgerald Date: Tue May 11 14:28:55 2021 +0100 ASoC: cs42l42: Regmap must use_single_read/write [ Upstream commit 0fad605fb0bdc00d8ad78696300ff2fbdee6e048 ] cs42l42 does not support standard burst transfers so the use_single_read and use_single_write flags must be set in the regmap config. Because of this bug, the patch: commit 0a0eb567e1d4 ("ASoC: cs42l42: Minor error paths fixups") broke cs42l42 probe() because without the use_single_* flags it causes regmap to issue a burst read. However, the missing use_single_* could cause problems anyway because the regmap cache can attempt burst transfers if these flags are not set. Fixes: 2c394ca79604 ("ASoC: Add support for CS42L42 codec") Signed-off-by: Richard Fitzgerald Acked-by: Charles Keepax Link: https://lore.kernel.org/r/20210511132855.27159-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 211c5d16e3575a96752a58c5f55a8abef399fa46 Author: Zou Wei Date: Tue May 11 11:44:33 2021 +0800 interconnect: qcom: Add missing MODULE_DEVICE_TABLE [ Upstream commit 1fd86e280d8b21762901e43d42d66dbfe8b8e0d3 ] This patch adds missing MODULE_DEVICE_TABLE definition which generates correct modalias for automatic loading of this driver when it is built as an external module. Reported-by: Hulk Robot Signed-off-by: Zou Wei Link: https://lore.kernel.org/r/1620704673-104205-1-git-send-email-zou_wei@huawei.com Fixes: 976daac4a1c5 ("interconnect: qcom: Consolidate interconnect RPMh support") Signed-off-by: Georgi Djakov Signed-off-by: Sasha Levin commit 4e3cea8035b6f1b9055e69cc6ebf9fa4e50763ae Author: Subbaraman Narayanamurthy Date: Thu Apr 22 11:36:10 2021 -0700 interconnect: qcom: bcm-voter: add a missing of_node_put() [ Upstream commit a00593737f8bac2c9e97b696e7ff84a4446653e8 ] Add a missing of_node_put() in of_bcm_voter_get() to avoid the reference leak. Signed-off-by: Subbaraman Narayanamurthy Reviewed-by: Matthias Kaehlcke Link: https://lore.kernel.org/r/1619116570-13308-1-git-send-email-subbaram@codeaurora.org Fixes: 976daac4a1c5 ("interconnect: qcom: Consolidate interconnect RPMh support") Signed-off-by: Georgi Djakov Signed-off-by: Sasha Levin commit d7932e68520e337be97192b41f320f710996ec77 Author: Vladimir Oltean Date: Sun May 9 22:33:38 2021 +0300 net: dsa: fix error code getting shifted with 4 in dsa_slave_get_sset_count [ Upstream commit b94cbc909f1d80378a1f541968309e5c1178c98b ] DSA implements a bunch of 'standardized' ethtool statistics counters, namely tx_packets, tx_bytes, rx_packets, rx_bytes. So whatever the hardware driver returns in .get_sset_count(), we need to add 4 to that. That is ok, except that .get_sset_count() can return a negative error code, for example: b53_get_sset_count -> phy_ethtool_get_sset_count -> return -EIO -EIO is -5, and with 4 added to it, it becomes -1, aka -EPERM. One can imagine that certain error codes may even become positive, although based on code inspection I did not see instances of that. Check the error code first, if it is negative return it as-is. Based on a similar patch for dsa_master_get_strings from Dan Carpenter: https://patchwork.kernel.org/project/netdevbpf/patch/YJaSe3RPgn7gKxZv@mwanda/ Fixes: 91da11f870f0 ("net: Distributed Switch Architecture protocol support") Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d5b0a1513b6ca8dbe69302ab7993ca6209715bab Author: Christophe JAILLET Date: Sat May 8 07:38:22 2021 +0200 net: netcp: Fix an error message [ Upstream commit ddb6e00f8413e885ff826e32521cff7924661de0 ] 'ret' is known to be 0 here. The expected error code is stored in 'tx_pipe->dma_queue', so use it instead. While at it, switch from %d to %pe which is more user friendly. Fixes: 84640e27f230 ("net: netcp: Add Keystone NetCP core ethernet driver") Signed-off-by: Christophe JAILLET Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 1354ec840899e87259286cc844d4c161ea86fae7 Author: Rikard Falkeborn Date: Sat May 22 17:42:02 2021 -0700 linux/bits.h: fix compilation error with GENMASK [ Upstream commit f747e6667ebb2ffb8133486c9cd19800d72b0d98 ] GENMASK() has an input check which uses __builtin_choose_expr() to enable a compile time sanity check of its inputs if they are known at compile time. However, it turns out that __builtin_constant_p() does not always return a compile time constant [0]. It was thought this problem was fixed with gcc 4.9 [1], but apparently this is not the case [2]. Switch to use __is_constexpr() instead which always returns a compile time constant, regardless of its inputs. Link: https://lore.kernel.org/lkml/42b4342b-aefc-a16a-0d43-9f9c0d63ba7a@rasmusvillemoes.dk [0] Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19449 [1] Link: https://lore.kernel.org/lkml/1ac7bbc2-45d9-26ed-0b33-bf382b8d858b@I-love.SAKURA.ne.jp [2] Link: https://lkml.kernel.org/r/20210511203716.117010-1-rikard.falkeborn@gmail.com Signed-off-by: Rikard Falkeborn Reported-by: Tetsuo Handa Acked-by: Arnd Bergmann Reviewed-by: Andy Shevchenko Cc: Ard Biesheuvel Cc: Yury Norov Cc: Peter Zijlstra Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit b0f5d4891ea3a80ad619312355494dc25073e219 Author: Gulam Mohamed Date: Fri May 14 15:18:42 2021 +0200 block: fix a race between del_gendisk and BLKRRPART [ Upstream commit bc6a385132601c29a6da1dbf8148c0d3c9ad36dc ] When BLKRRPART is called concurrently with del_gendisk, the partitions rescan can create a stale partition that will never be be cleaned up. Fix this by checking the the disk is up before rescanning partitions while under bd_mutex. Signed-off-by: Gulam Mohamed [hch: split from a larger patch] Signed-off-by: Christoph Hellwig Reviewed-by: Ming Lei Link: https://lore.kernel.org/r/20210514131842.1600568-3-hch@lst.de Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit ff945d033a047f0714a98dde059ad6fbf3462e9e Author: Hans de Goede Date: Thu May 20 11:32:28 2021 +0200 platform/x86: touchscreen_dmi: Add info for the Chuwi Hi10 Pro (CWI529) tablet [ Upstream commit e68671e9e1275dfdda333c3e83b6d28963af16b6 ] Add touchscreen info for the Chuwi Hi10 Pro (CWI529) tablet. This includes info for getting the firmware directly from the UEFI, so that the user does not need to manually install the firmware in /lib/firmware/silead. This change will make the touchscreen on these devices work OOTB, without requiring any manual setup. Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20210520093228.7439-1-hdegoede@redhat.com Signed-off-by: Sasha Levin commit 5fbc70eef88a8566c32d4ea103669814e5188475 Author: Christian König Date: Tue May 18 17:48:02 2021 +0200 drm/amdgpu: stop touching sched.ready in the backend [ Upstream commit a2b4785f01280a4291edb9fda69032fc2e4bfd3f ] This unfortunately comes up in regular intervals and breaks GPU reset for the engine in question. The sched.ready flag controls if an engine can't get working during hw_init, but should never be set to false during hw_fini. v2: squash in unused variable fix (Alex) Signed-off-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 4951dd498d483fa961c92541b55ffb32db7f2dbf Author: Lang Yu Date: Mon May 17 12:47:20 2021 +0800 drm/amd/amdgpu: fix a potential deadlock in gpu reset [ Upstream commit 9c2876d56f1ce9b6b2072f1446fb1e8d1532cb3d ] When amdgpu_ib_ring_tests failed, the reset logic called amdgpu_device_ip_suspend twice, then deadlock occurred. Deadlock log: [ 805.655192] amdgpu 0000:04:00.0: amdgpu: ib ring test failed (-110). [ 806.290952] [drm] free PSP TMR buffer [ 806.319406] ============================================ [ 806.320315] WARNING: possible recursive locking detected [ 806.321225] 5.11.0-custom #1 Tainted: G W OEL [ 806.322135] -------------------------------------------- [ 806.323043] cat/2593 is trying to acquire lock: [ 806.323825] ffff888136b1cdc8 (&adev->dm.dc_lock){+.+.}-{3:3}, at: dm_suspend+0xb8/0x1d0 [amdgpu] [ 806.325668] but task is already holding lock: [ 806.326664] ffff888136b1cdc8 (&adev->dm.dc_lock){+.+.}-{3:3}, at: dm_suspend+0xb8/0x1d0 [amdgpu] [ 806.328430] other info that might help us debug this: [ 806.329539] Possible unsafe locking scenario: [ 806.330549] CPU0 [ 806.330983] ---- [ 806.331416] lock(&adev->dm.dc_lock); [ 806.332086] lock(&adev->dm.dc_lock); [ 806.332738] *** DEADLOCK *** [ 806.333747] May be due to missing lock nesting notation [ 806.334899] 3 locks held by cat/2593: [ 806.335537] #0: ffff888100d3f1b8 (&attr->mutex){+.+.}-{3:3}, at: simple_attr_read+0x4e/0x110 [ 806.337009] #1: ffff888136b1fd78 (&adev->reset_sem){++++}-{3:3}, at: amdgpu_device_lock_adev+0x42/0x94 [amdgpu] [ 806.339018] #2: ffff888136b1cdc8 (&adev->dm.dc_lock){+.+.}-{3:3}, at: dm_suspend+0xb8/0x1d0 [amdgpu] [ 806.340869] stack backtrace: [ 806.341621] CPU: 6 PID: 2593 Comm: cat Tainted: G W OEL 5.11.0-custom #1 [ 806.342921] Hardware name: AMD Celadon-CZN/Celadon-CZN, BIOS WLD0C23N_Weekly_20_12_2 12/23/2020 [ 806.344413] Call Trace: [ 806.344849] dump_stack+0x93/0xbd [ 806.345435] __lock_acquire.cold+0x18a/0x2cf [ 806.346179] lock_acquire+0xca/0x390 [ 806.346807] ? dm_suspend+0xb8/0x1d0 [amdgpu] [ 806.347813] __mutex_lock+0x9b/0x930 [ 806.348454] ? dm_suspend+0xb8/0x1d0 [amdgpu] [ 806.349434] ? amdgpu_device_indirect_rreg+0x58/0x70 [amdgpu] [ 806.350581] ? _raw_spin_unlock_irqrestore+0x47/0x50 [ 806.351437] ? dm_suspend+0xb8/0x1d0 [amdgpu] [ 806.352437] ? rcu_read_lock_sched_held+0x4f/0x80 [ 806.353252] ? rcu_read_lock_sched_held+0x4f/0x80 [ 806.354064] mutex_lock_nested+0x1b/0x20 [ 806.354747] ? mutex_lock_nested+0x1b/0x20 [ 806.355457] dm_suspend+0xb8/0x1d0 [amdgpu] [ 806.356427] ? soc15_common_set_clockgating_state+0x17d/0x19 [amdgpu] [ 806.357736] amdgpu_device_ip_suspend_phase1+0x78/0xd0 [amdgpu] [ 806.360394] amdgpu_device_ip_suspend+0x21/0x70 [amdgpu] [ 806.362926] amdgpu_device_pre_asic_reset+0xb3/0x270 [amdgpu] [ 806.365560] amdgpu_device_gpu_recover.cold+0x679/0x8eb [amdgpu] Signed-off-by: Lang Yu Acked-by: Christian KÃnig Reviewed-by: Andrey Grodzovsky Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit f98cdf084405333ee2f5be548a91b2d168e49276 Author: xinhui pan Date: Tue May 18 10:56:07 2021 +0800 drm/amdgpu: Fix a use-after-free [ Upstream commit 1e5c37385097c35911b0f8a0c67ffd10ee1af9a2 ] looks like we forget to set ttm->sg to NULL. Hit panic below [ 1235.844104] general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b7b4b: 0000 [#1] SMP DEBUG_PAGEALLOC NOPTI [ 1235.989074] Call Trace: [ 1235.991751] sg_free_table+0x17/0x20 [ 1235.995667] amdgpu_ttm_backend_unbind.cold+0x4d/0xf7 [amdgpu] [ 1236.002288] amdgpu_ttm_backend_destroy+0x29/0x130 [amdgpu] [ 1236.008464] ttm_tt_destroy+0x1e/0x30 [ttm] [ 1236.013066] ttm_bo_cleanup_memtype_use+0x51/0xa0 [ttm] [ 1236.018783] ttm_bo_release+0x262/0xa50 [ttm] [ 1236.023547] ttm_bo_put+0x82/0xd0 [ttm] [ 1236.027766] amdgpu_bo_unref+0x26/0x50 [amdgpu] [ 1236.032809] amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0x7aa/0xd90 [amdgpu] [ 1236.040400] kfd_ioctl_alloc_memory_of_gpu+0xe2/0x330 [amdgpu] [ 1236.046912] kfd_ioctl+0x463/0x690 [amdgpu] Signed-off-by: xinhui pan Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 9fdb8ed37a3a44f9c49372b69f87fd5f61cb3240 Author: Jingwen Chen Date: Mon May 17 16:16:10 2021 +0800 drm/amd/amdgpu: fix refcount leak [ Upstream commit fa7e6abc75f3d491bc561734312d065dc9dc2a77 ] [Why] the gem object rfb->base.obj[0] is get according to num_planes in amdgpufb_create, but is not put according to num_planes [How] put rfb->base.obj[0] in amdgpu_fbdev_destroy according to num_planes Signed-off-by: Jingwen Chen Acked-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 07ab4dfe0323f4984d89d2f06d0389c295ea0d6a Author: Chris Park Date: Tue May 4 16:20:55 2021 -0400 drm/amd/display: Disconnect non-DP with no EDID [ Upstream commit 080039273b126eeb0185a61c045893a25dbc046e ] [Why] Active DP dongles return no EDID when dongle is connected, but VGA display is taken out. Current driver behavior does not remove the active display when this happens, and this is a gap between dongle DTP and dongle behavior. [How] For active DP dongles and non-DP scenario, disconnect sink on detection when no EDID is read due to timeout. Signed-off-by: Chris Park Reviewed-by: Nicholas Kazlauskas Acked-by: Stylon Wang Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 530baa6f3c0632b17ee3d0feaba6dc68d53e0e09 Author: Steve French Date: Sat May 15 09:52:22 2021 -0500 SMB3: incorrect file id in requests compounded with open [ Upstream commit c0d46717b95735b0eacfddbcca9df37a49de9c7a ] See MS-SMB2 3.2.4.1.4, file ids in compounded requests should be set to 0xFFFFFFFFFFFFFFFF (we were treating it as u32 not u64 and setting it incorrectly). Signed-off-by: Steve French Reported-by: Stefan Metzmacher Reviewed-by: Shyam Prasad N Signed-off-by: Sasha Levin commit 518457d0270c564e1aef2c7c09ca79e42c5b4550 Author: Teava Radu Date: Tue May 4 20:57:46 2021 +0200 platform/x86: touchscreen_dmi: Add info for the Mediacom Winpad 7.0 W700 tablet [ Upstream commit 39a6172ea88b3117353ae16cbb0a53cd80a9340a ] Add touchscreen info for the Mediacom Winpad 7.0 W700 tablet. Tested on 5.11 hirsute. Note: it's hw clone to Wintron surftab 7. Signed-off-by: Teava Radu Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20210504185746.175461-6-hdegoede@redhat.com Signed-off-by: Sasha Levin commit c5bda3a559df212f6a84e439691d5bb0a73c45bf Author: Andy Shevchenko Date: Wed May 19 13:15:21 2021 +0300 platform/x86: intel_punit_ipc: Append MODULE_DEVICE_TABLE for ACPI [ Upstream commit bc1eca606d8084465e6f89fd646cc71defbad490 ] The intel_punit_ipc driver might be compiled as a module. When udev handles the event of the devices appearing the intel_punit_ipc module is missing. Append MODULE_DEVICE_TABLE for ACPI case to fix the loading issue. Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210519101521.79338-1-andriy.shevchenko@linux.intel.com Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin commit fe156a601caca51840fba2bf1ef3f83a1aaaa9cc Author: Shyam Sundar S K Date: Fri May 14 23:30:47 2021 +0530 platform/x86: hp-wireless: add AMD's hardware id to the supported list [ Upstream commit f048630bdd55eb5379ef35f971639fe52fabe499 ] Newer AMD based laptops uses AMDI0051 as the hardware id to support the airplane mode button. Adding this to the supported list. Signed-off-by: Shyam Sundar S K Link: https://lore.kernel.org/r/20210514180047.1697543-1-Shyam-sundar.S-k@amd.com Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin commit 7e13db503918820e6333811cdc6f151dcea5090a Author: Josef Bacik Date: Fri May 14 10:56:16 2021 -0400 btrfs: do not BUG_ON in link_to_fixup_dir [ Upstream commit 91df99a6eb50d5a1bc70fff4a09a0b7ae6aab96d ] While doing error injection testing I got the following panic kernel BUG at fs/btrfs/tree-log.c:1862! invalid opcode: 0000 [#1] SMP NOPTI CPU: 1 PID: 7836 Comm: mount Not tainted 5.13.0-rc1+ #305 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014 RIP: 0010:link_to_fixup_dir+0xd5/0xe0 RSP: 0018:ffffb5800180fa30 EFLAGS: 00010216 RAX: fffffffffffffffb RBX: 00000000fffffffb RCX: ffff8f595287faf0 RDX: ffffb5800180fa37 RSI: ffff8f5954978800 RDI: 0000000000000000 RBP: ffff8f5953af9450 R08: 0000000000000019 R09: 0000000000000001 R10: 000151f408682970 R11: 0000000120021001 R12: ffff8f5954978800 R13: ffff8f595287faf0 R14: ffff8f5953c77dd0 R15: 0000000000000065 FS: 00007fc5284c8c40(0000) GS:ffff8f59bbd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fc5287f47c0 CR3: 000000011275e002 CR4: 0000000000370ee0 Call Trace: replay_one_buffer+0x409/0x470 ? btree_read_extent_buffer_pages+0xd0/0x110 walk_up_log_tree+0x157/0x1e0 walk_log_tree+0xa6/0x1d0 btrfs_recover_log_trees+0x1da/0x360 ? replay_one_extent+0x7b0/0x7b0 open_ctree+0x1486/0x1720 btrfs_mount_root.cold+0x12/0xea ? __kmalloc_track_caller+0x12f/0x240 legacy_get_tree+0x24/0x40 vfs_get_tree+0x22/0xb0 vfs_kern_mount.part.0+0x71/0xb0 btrfs_mount+0x10d/0x380 ? vfs_parse_fs_string+0x4d/0x90 legacy_get_tree+0x24/0x40 vfs_get_tree+0x22/0xb0 path_mount+0x433/0xa10 __x64_sys_mount+0xe3/0x120 do_syscall_64+0x3d/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae We can get -EIO or any number of legitimate errors from btrfs_search_slot(), panicing here is not the appropriate response. The error path for this code handles errors properly, simply return the error. Signed-off-by: Josef Bacik Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 88f566beb1cf843876cffc4153640e5267d1171b Author: Filipe Manana Date: Fri May 14 10:03:40 2021 +0100 btrfs: release path before starting transaction when cloning inline extent [ Upstream commit 6416954ca75baed71640bf3828625bf165fb9b5e ] When cloning an inline extent there are a few cases, such as when we have an implicit hole at file offset 0, where we start a transaction while holding a read lock on a leaf. Starting the transaction results in a call to sb_start_intwrite(), which results in doing a read lock on a percpu semaphore. Lockdep doesn't like this and complains about it: [46.580704] ====================================================== [46.580752] WARNING: possible circular locking dependency detected [46.580799] 5.13.0-rc1 #28 Not tainted [46.580832] ------------------------------------------------------ [46.580877] cloner/3835 is trying to acquire lock: [46.580918] c00000001301d638 (sb_internal#2){.+.+}-{0:0}, at: clone_copy_inline_extent+0xe4/0x5a0 [46.581167] [46.581167] but task is already holding lock: [46.581217] c000000007fa2550 (btrfs-tree-00){++++}-{3:3}, at: __btrfs_tree_read_lock+0x70/0x1d0 [46.581293] [46.581293] which lock already depends on the new lock. [46.581293] [46.581351] [46.581351] the existing dependency chain (in reverse order) is: [46.581410] [46.581410] -> #1 (btrfs-tree-00){++++}-{3:3}: [46.581464] down_read_nested+0x68/0x200 [46.581536] __btrfs_tree_read_lock+0x70/0x1d0 [46.581577] btrfs_read_lock_root_node+0x88/0x200 [46.581623] btrfs_search_slot+0x298/0xb70 [46.581665] btrfs_set_inode_index+0xfc/0x260 [46.581708] btrfs_new_inode+0x26c/0x950 [46.581749] btrfs_create+0xf4/0x2b0 [46.581782] lookup_open.isra.57+0x55c/0x6a0 [46.581855] path_openat+0x418/0xd20 [46.581888] do_filp_open+0x9c/0x130 [46.581920] do_sys_openat2+0x2ec/0x430 [46.581961] do_sys_open+0x90/0xc0 [46.581993] system_call_exception+0x3d4/0x410 [46.582037] system_call_common+0xec/0x278 [46.582078] [46.582078] -> #0 (sb_internal#2){.+.+}-{0:0}: [46.582135] __lock_acquire+0x1e90/0x2c50 [46.582176] lock_acquire+0x2b4/0x5b0 [46.582263] start_transaction+0x3cc/0x950 [46.582308] clone_copy_inline_extent+0xe4/0x5a0 [46.582353] btrfs_clone+0x5fc/0x880 [46.582388] btrfs_clone_files+0xd8/0x1c0 [46.582434] btrfs_remap_file_range+0x3d8/0x590 [46.582481] do_clone_file_range+0x10c/0x270 [46.582558] vfs_clone_file_range+0x1b0/0x310 [46.582605] ioctl_file_clone+0x90/0x130 [46.582651] do_vfs_ioctl+0x874/0x1ac0 [46.582697] sys_ioctl+0x6c/0x120 [46.582733] system_call_exception+0x3d4/0x410 [46.582777] system_call_common+0xec/0x278 [46.582822] [46.582822] other info that might help us debug this: [46.582822] [46.582888] Possible unsafe locking scenario: [46.582888] [46.582942] CPU0 CPU1 [46.582984] ---- ---- [46.583028] lock(btrfs-tree-00); [46.583062] lock(sb_internal#2); [46.583119] lock(btrfs-tree-00); [46.583174] lock(sb_internal#2); [46.583212] [46.583212] *** DEADLOCK *** [46.583212] [46.583266] 6 locks held by cloner/3835: [46.583299] #0: c00000001301d448 (sb_writers#12){.+.+}-{0:0}, at: ioctl_file_clone+0x90/0x130 [46.583382] #1: c00000000f6d3768 (&sb->s_type->i_mutex_key#15){+.+.}-{3:3}, at: lock_two_nondirectories+0x58/0xc0 [46.583477] #2: c00000000f6d72a8 (&sb->s_type->i_mutex_key#15/4){+.+.}-{3:3}, at: lock_two_nondirectories+0x9c/0xc0 [46.583574] #3: c00000000f6d7138 (&ei->i_mmap_lock){+.+.}-{3:3}, at: btrfs_remap_file_range+0xd0/0x590 [46.583657] #4: c00000000f6d35f8 (&ei->i_mmap_lock/1){+.+.}-{3:3}, at: btrfs_remap_file_range+0xe0/0x590 [46.583743] #5: c000000007fa2550 (btrfs-tree-00){++++}-{3:3}, at: __btrfs_tree_read_lock+0x70/0x1d0 [46.583828] [46.583828] stack backtrace: [46.583872] CPU: 1 PID: 3835 Comm: cloner Not tainted 5.13.0-rc1 #28 [46.583931] Call Trace: [46.583955] [c0000000167c7200] [c000000000c1ee78] dump_stack+0xec/0x144 (unreliable) [46.584052] [c0000000167c7240] [c000000000274058] print_circular_bug.isra.32+0x3a8/0x400 [46.584123] [c0000000167c72e0] [c0000000002741f4] check_noncircular+0x144/0x190 [46.584191] [c0000000167c73b0] [c000000000278fc0] __lock_acquire+0x1e90/0x2c50 [46.584259] [c0000000167c74f0] [c00000000027aa94] lock_acquire+0x2b4/0x5b0 [46.584317] [c0000000167c75e0] [c000000000a0d6cc] start_transaction+0x3cc/0x950 [46.584388] [c0000000167c7690] [c000000000af47a4] clone_copy_inline_extent+0xe4/0x5a0 [46.584457] [c0000000167c77c0] [c000000000af525c] btrfs_clone+0x5fc/0x880 [46.584514] [c0000000167c7990] [c000000000af5698] btrfs_clone_files+0xd8/0x1c0 [46.584583] [c0000000167c7a00] [c000000000af5b58] btrfs_remap_file_range+0x3d8/0x590 [46.584652] [c0000000167c7ae0] [c0000000005d81dc] do_clone_file_range+0x10c/0x270 [46.584722] [c0000000167c7b40] [c0000000005d84f0] vfs_clone_file_range+0x1b0/0x310 [46.584793] [c0000000167c7bb0] [c00000000058bf80] ioctl_file_clone+0x90/0x130 [46.584861] [c0000000167c7c10] [c00000000058c894] do_vfs_ioctl+0x874/0x1ac0 [46.584922] [c0000000167c7d10] [c00000000058db4c] sys_ioctl+0x6c/0x120 [46.584978] [c0000000167c7d60] [c0000000000364a4] system_call_exception+0x3d4/0x410 [46.585046] [c0000000167c7e10] [c00000000000d45c] system_call_common+0xec/0x278 [46.585114] --- interrupt: c00 at 0x7ffff7e22990 [46.585160] NIP: 00007ffff7e22990 LR: 00000001000010ec CTR: 0000000000000000 [46.585224] REGS: c0000000167c7e80 TRAP: 0c00 Not tainted (5.13.0-rc1) [46.585280] MSR: 800000000280f033 CR: 28000244 XER: 00000000 [46.585374] IRQMASK: 0 [46.585374] GPR00: 0000000000000036 00007fffffffdec0 00007ffff7f17100 0000000000000004 [46.585374] GPR04: 000000008020940d 00007fffffffdf40 0000000000000000 0000000000000000 [46.585374] GPR08: 0000000000000004 0000000000000000 0000000000000000 0000000000000000 [46.585374] GPR12: 0000000000000000 00007ffff7ffa940 0000000000000000 0000000000000000 [46.585374] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [46.585374] GPR20: 0000000000000000 000000009123683e 00007fffffffdf40 0000000000000000 [46.585374] GPR24: 0000000000000000 0000000000000000 0000000000000000 0000000000000004 [46.585374] GPR28: 0000000100030260 0000000100030280 0000000000000003 000000000000005f [46.585919] NIP [00007ffff7e22990] 0x7ffff7e22990 [46.585964] LR [00000001000010ec] 0x1000010ec [46.586010] --- interrupt: c00 This should be a false positive, as both locks are acquired in read mode. Nevertheless, we don't need to hold a leaf locked when we start the transaction, so just release the leaf (path) before starting it. Reported-by: Ritesh Harjani Link: https://lore.kernel.org/linux-btrfs/20210513214404.xks77p566fglzgum@riteshh-domain/ Reviewed-by: Anand Jain Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 8eaa762e1d187afcf2035c72c1b9de7ffe765913 Author: Ajish Koshy Date: Wed May 5 17:31:03 2021 +0530 scsi: pm80xx: Fix drives missing during rmmod/insmod loop [ Upstream commit d1acd81bd6eb685aa9fef25624fb36d297f6404e ] When driver is loaded after rmmod some drives are not showing up during discovery. SATA drives are directly attached to the controller connected phys. During device discovery, the IDENTIFY command (qc timeout (cmd 0xec)) is timing out during revalidation. This will trigger abort from host side and controller successfully aborts the command and returns success. Post this successful abort response ATA library decides to mark the disk as NODEV. To overcome this, inside pm8001_scan_start() after phy_start() call, add get start response and wait for few milliseconds to trigger next phy start. This millisecond delay will give sufficient time for the controller state machine to accept next phy start. Link: https://lore.kernel.org/r/20210505120103.24497-1-ajish.koshy@microchip.com Signed-off-by: Ajish Koshy Signed-off-by: Viswas G Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 71084e2a4d2fbe7fcb5ea455020318dd16520247 Author: Peter Zijlstra Date: Wed Apr 14 14:45:43 2021 +0200 openrisc: Define memory barrier mb [ Upstream commit 8b549c18ae81dbc36fb11e4aa08b8378c599ca95 ] This came up in the discussion of the requirements of qspinlock on an architecture. OpenRISC uses qspinlock, but it was noticed that the memmory barrier was not defined. Peter defined it in the mail thread writing: As near as I can tell this should do. The arch spec only lists this one instruction and the text makes it sound like a completion barrier. This is correct so applying this patch. Signed-off-by: Peter Zijlstra [shorne@gmail.com:Turned the mail into a patch] Signed-off-by: Stafford Horne Signed-off-by: Sasha Levin commit 6384103641e37257a5b2d466606431c159e763c8 Author: Matt Wang Date: Tue May 11 03:04:37 2021 +0000 scsi: BusLogic: Fix 64-bit system enumeration error for Buslogic [ Upstream commit 56f396146af278135c0ff958c79b5ee1bd22453d ] Commit 391e2f25601e ("[SCSI] BusLogic: Port driver to 64-bit") introduced a serious issue for 64-bit systems. With this commit, 64-bit kernel will enumerate 8*15 non-existing disks. This is caused by the broken CCB structure. The change from u32 data to void *data increased CCB length on 64-bit system, which introduced an extra 4 byte offset of the CDB. This leads to incorrect response to INQUIRY commands during enumeration. Fix disk enumeration failure by reverting the portion of the commit above which switched the data pointer from u32 to void. Link: https://lore.kernel.org/r/C325637F-1166-4340-8F0F-3BCCD59D4D54@vmware.com Acked-by: Khalid Aziz Signed-off-by: Matt Wang Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit d644642794044f7ace84d99df47818842c7f56fb Author: Peter Wang Date: Wed May 12 18:01:45 2021 +0800 scsi: ufs: ufs-mediatek: Fix power down spec violation [ Upstream commit c625b80b9d00f3546722cd77527f9697c8c4c911 ] As per spec, e.g. JESD220E chapter 7.2, while powering off the UFS device, RST_N signal should be between VSS(Ground) and VCCQ/VCCQ2. The power down sequence after fixing: Power down: 1. Assert RST_N low 2. Turn-off VCC 3. Turn-off VCCQ/VCCQ2 Link: https://lore.kernel.org/r/1620813706-25331-1-git-send-email-peter.wang@mediatek.com Reviewed-by: Stanley Chu Signed-off-by: Peter Wang Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit c7e0c6047c4f2a9664e48e3671af80c513220a44 Author: Boris Burkov Date: Tue Apr 6 15:31:18 2021 -0700 btrfs: return whole extents in fiemap [ Upstream commit 15c7745c9a0078edad1f7df5a6bb7b80bc8cca23 ] `xfs_io -c 'fiemap ' ` can give surprising results on btrfs that differ from xfs. btrfs prints out extents trimmed to fit the user input. If the user's fiemap request has an offset, then rather than returning each whole extent which intersects that range, we also trim the start extent to not have start < off. Documentation in filesystems/fiemap.txt and the xfs_io man page suggests that returning the whole extent is expected. Some cases which all yield the same fiemap in xfs, but not btrfs: dd if=/dev/zero of=$f bs=4k count=1 sudo xfs_io -c 'fiemap 0 1024' $f 0: [0..7]: 26624..26631 sudo xfs_io -c 'fiemap 2048 1024' $f 0: [4..7]: 26628..26631 sudo xfs_io -c 'fiemap 2048 4096' $f 0: [4..7]: 26628..26631 sudo xfs_io -c 'fiemap 3584 512' $f 0: [7..7]: 26631..26631 sudo xfs_io -c 'fiemap 4091 5' $f 0: [7..6]: 26631..26630 I believe this is a consequence of the logic for merging contiguous extents represented by separate extent items. That logic needs to track the last offset as it loops through the extent items, which happens to pick up the start offset on the first iteration, and trim off the beginning of the full extent. To fix it, start `off` at 0 rather than `start` so that we keep the iteration/merging intact without cutting off the start of the extent. after the fix, all the above commands give: 0: [0..7]: 26624..26631 The merging logic is exercised by fstest generic/483, and I have written a new fstest for checking we don't have backwards or zero-length fiemaps for cases like those above. Reviewed-by: Josef Bacik Signed-off-by: Boris Burkov Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit df451eab6e0010cfdf4a85c8586f14c2986b472f Author: Greg Kroah-Hartman Date: Mon May 3 13:57:36 2021 +0200 brcmfmac: properly check for bus register errors [ Upstream commit 419b4a142a7ece36cebcd434f8ce2af59ef94b85 ] The brcmfmac driver ignores any errors on initialization with the different busses by deferring the initialization to a workqueue and ignoring all possible errors that might happen. Fix up all of this by only allowing the module to load if all bus registering worked properly. Cc: Kalle Valo Link: https://lore.kernel.org/r/20210503115736.2104747-70-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit f0044d135d15ec2fbec496243f2d74ca3d45d38b Author: Greg Kroah-Hartman Date: Mon May 3 13:57:35 2021 +0200 Revert "brcmfmac: add a check for the status of usb_register" [ Upstream commit 30a350947692f794796f563029d29764497f2887 ] This reverts commit 42daad3343be4a4e1ee03e30a5f5cc731dadfef5. Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not. Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change. The original commit here did nothing to actually help if usb_register() failed, so it gives a "false sense of security" when there is none. The correct solution is to correctly unwind from this error. Cc: Kangjie Lu Cc: Kalle Valo Link: https://lore.kernel.org/r/20210503115736.2104747-69-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 43e6b2ed46acd8afa6c04cc2fcdc078b9d96106a Author: Tom Seewald Date: Mon May 3 13:57:32 2021 +0200 net: liquidio: Add missing null pointer checks [ Upstream commit dbc97bfd3918ed9268bfc174cae8a7d6b3d51aad ] The functions send_rx_ctrl_cmd() in both liquidio/lio_main.c and liquidio/lio_vf_main.c do not check if the call to octeon_alloc_soft_command() fails and returns a null pointer. Both functions also return void so errors are not propagated back to the caller. Fix these issues by updating both instances of send_rx_ctrl_cmd() to return an integer rather than void, and have them return -ENOMEM if an allocation failure occurs. Also update all callers of send_rx_ctrl_cmd() so that they now check the return value. Cc: David S. Miller Signed-off-by: Tom Seewald Link: https://lore.kernel.org/r/20210503115736.2104747-66-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit e6fbd9faca9f417f01c047bf7d59fb7ddc0d29f7 Author: Greg Kroah-Hartman Date: Mon May 3 13:57:31 2021 +0200 Revert "net: liquidio: fix a NULL pointer dereference" [ Upstream commit 4fd798a5a89114c1892574c50f2aebd49bc5b4f5 ] This reverts commit fe543b2f174f34a7a751aa08b334fe6b105c4569. Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not. Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change. While the original commit does keep the immediate "NULL dereference" from happening, it does not properly propagate the error back to the callers, AND it does not fix this same identical issue in the drivers/net/ethernet/cavium/liquidio/lio_vf_main.c for some reason. Cc: Kangjie Lu Cc: David S. Miller Link: https://lore.kernel.org/r/20210503115736.2104747-65-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 32aba713787902a8b26170ccd3008cb0317aaa5a Author: Greg Kroah-Hartman Date: Mon May 3 13:57:30 2021 +0200 media: gspca: properly check for errors in po1030_probe() [ Upstream commit dacb408ca6f0e34df22b40d8dd5fae7f8e777d84 ] If m5602_write_sensor() or m5602_write_bridge() fail, do not continue to initialize the device but return the error to the calling funtion. Cc: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/20210503115736.2104747-64-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 3d8ac40a7f22006ac9ec003f7ff342f46e645262 Author: Greg Kroah-Hartman Date: Mon May 3 13:57:29 2021 +0200 Revert "media: gspca: Check the return value of write_bridge for timeout" [ Upstream commit 8e23e83c752b54e98102627a1cc09281ad71a299 ] This reverts commit a21a0eb56b4e8fe4a330243af8030f890cde2283. Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not. Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change. Different error values should never be "OR" together and expect anything sane to come out of the result. Cc: Aditya Pakki Cc: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/20210503115736.2104747-63-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 9ffea48d9da23175472bea7ae8fcab694477bf2d Author: Alaa Emad Date: Mon May 3 13:57:28 2021 +0200 media: gspca: mt9m111: Check write_bridge for timeout [ Upstream commit e932f5b458eee63d013578ea128b9ff8ef5f5496 ] If m5602_write_bridge times out, it will return a negative error value. So properly check for this and handle the error correctly instead of just ignoring it. Cc: Mauro Carvalho Chehab Signed-off-by: Alaa Emad Link: https://lore.kernel.org/r/20210503115736.2104747-62-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit e4bb3dba9e24966a26830cc03c1a62e88a030de1 Author: Greg Kroah-Hartman Date: Mon May 3 13:57:27 2021 +0200 Revert "media: gspca: mt9m111: Check write_bridge for timeout" [ Upstream commit d8c3be2fb2079d0cb4cd29d6aba58dbe54771e42 ] This reverts commit 656025850074f5c1ba2e05be37bda57ba2b8d491. Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not. Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change. Different error values should never be "OR" together and expect anything sane to come out of the result. Cc: Aditya Pakki Cc: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/20210503115736.2104747-61-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 9fd73df80fa4b1373ab050c28aa3f66f30de5bd9 Author: Alaa Emad Date: Mon May 3 13:57:26 2021 +0200 media: dvb: Add check on sp8870_readreg return [ Upstream commit c6d822c56e7fd29e6fa1b1bb91b98f6a1e942b3c ] The function sp8870_readreg returns a negative value when i2c_transfer fails so properly check for this and return the error if it happens. Cc: Sean Young Cc: Mauro Carvalho Chehab Signed-off-by: Alaa Emad Link: https://lore.kernel.org/r/20210503115736.2104747-60-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 7dae0ca98ae4fe71b68183e9f8a2b2258298a20d Author: Greg Kroah-Hartman Date: Mon May 3 13:57:25 2021 +0200 Revert "media: dvb: Add check on sp8870_readreg" [ Upstream commit 47e4ff06fa7f5ba4860543a2913bbd0c164640aa ] This reverts commit 467a37fba93f2b4fe3ab597ff6a517b22b566882. Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not. Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change. This commit is not properly checking for an error at all, so if a read succeeds from this device, it will error out. Cc: Aditya Pakki Cc: Sean Young Cc: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/20210503115736.2104747-59-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 3bf09ab413c78ae30197a4b797ff0af764b8db9e Author: Greg Kroah-Hartman Date: Mon May 3 13:57:24 2021 +0200 ASoC: cs43130: handle errors in cs43130_probe() properly [ Upstream commit 2da441a6491d93eff8ffff523837fd621dc80389 ] cs43130_probe() does not do any valid error checking of things it initializes, OR what it does, it does not unwind properly if there are errors. Fix this up by moving the sysfs files to an attribute group so the driver core will correctly add/remove them all at once and handle errors with them, and correctly check for creating a new workqueue and unwinding if that fails. Cc: Mark Brown Link: https://lore.kernel.org/r/20210503115736.2104747-58-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit ce333cc94e2a0ae89be5b48dfb757fcd2f9b06b6 Author: Greg Kroah-Hartman Date: Mon May 3 13:57:23 2021 +0200 Revert "ASoC: cs43130: fix a NULL pointer dereference" [ Upstream commit fdda0dd2686ecd1f2e616c9e0366ea71b40c485d ] This reverts commit a2be42f18d409213bb7e7a736e3ef6ba005115bb. Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not. Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change. The original patch here is not correct, sysfs files that were created are not unwound. Cc: Kangjie Lu Cc: Mark Brown Link: https://lore.kernel.org/r/20210503115736.2104747-57-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 7fe86d957a457f2d058a4de6b515efab81efdf2b Author: Greg Kroah-Hartman Date: Mon May 3 13:57:20 2021 +0200 libertas: register sysfs groups properly [ Upstream commit 7e79b38fe9a403b065ac5915465f620a8fb3de84 ] The libertas driver was trying to register sysfs groups "by hand" which causes them to be created _after_ the device is initialized and announced to userspace, which causes races and can prevent userspace tools from seeing the sysfs files correctly. Fix this up by using the built-in sysfs_groups pointers in struct net_device which were created for this very reason, fixing the race condition, and properly allowing for any error that might have occured to be handled properly. Cc: Kalle Valo Link: https://lore.kernel.org/r/20210503115736.2104747-54-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit bf2b6ffa9689a2dc18248631dee8304833eb9276 Author: Greg Kroah-Hartman Date: Mon May 3 13:57:19 2021 +0200 Revert "libertas: add checks for the return value of sysfs_create_group" [ Upstream commit 46651077765c80a0d6f87f3469129a72e49ce91b ] This reverts commit 434256833d8eb988cb7f3b8a41699e2fe48d9332. Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not. Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change. The original commit was incorrect, the error needs to be propagated back to the caller AND if the second group call fails, the first needs to be removed. There are much better ways to solve this, the driver should NOT be calling sysfs_create_group() on its own as it is racing userspace and loosing. Cc: Kangjie Lu Cc: Kalle Valo Link: https://lore.kernel.org/r/20210503115736.2104747-53-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit e04f1a7e31a3a5550c5897cb7ef5ef8ee6081fa8 Author: Phillip Potter Date: Mon May 3 13:57:18 2021 +0200 dmaengine: qcom_hidma: comment platform_driver_register call [ Upstream commit 4df2a8b0ad634d98a67e540a4e18a60f943e7d9f ] Place a comment in hidma_mgmt_init explaining why success must currently be assumed, due to the cleanup issue that would need to be considered were this module ever to be unloadable or were this platform_driver_register call ever to fail. Acked-By: Vinod Koul Acked-By: Sinan Kaya Signed-off-by: Phillip Potter Link: https://lore.kernel.org/r/20210503115736.2104747-52-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 611640b63ae80876520a38bc4753fabf5b0cf1b4 Author: Greg Kroah-Hartman Date: Mon May 3 13:57:17 2021 +0200 Revert "dmaengine: qcom_hidma: Check for driver register failure" [ Upstream commit 43ed0fcf613a87dd0221ec72d1ade4d6544f2ffc ] This reverts commit a474b3f0428d6b02a538aa10b3c3b722751cb382. Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not. Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change. The original change is NOT correct, as it does not correctly unwind from the resources that was allocated before the call to platform_driver_register(). Cc: Aditya Pakki Acked-By: Vinod Koul Acked-By: Sinan Kaya Link: https://lore.kernel.org/r/20210503115736.2104747-51-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit d9029b19abe59ab945022aff2b5fad3225688397 Author: Phillip Potter Date: Mon May 3 13:57:14 2021 +0200 isdn: mISDN: correctly handle ph_info allocation failure in hfcsusb_ph_info [ Upstream commit 5265db2ccc735e2783b790d6c19fb5cee8c025ed ] Modify return type of hfcusb_ph_info to int, so that we can pass error value up the call stack when allocation of ph_info fails. Also change three of four call sites to actually account for the memory failure. The fourth, in ph_state_nt, is infeasible to change as it is in turn called by ph_state which is used as a function pointer argument to mISDN_initdchannel, which would necessitate changing its signature and updating all the places where it is used (too many). Fixes original flawed commit (38d22659803a) from the University of Minnesota. Cc: David S. Miller Signed-off-by: Phillip Potter Link: https://lore.kernel.org/r/20210503115736.2104747-48-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit fb278d346835f6f1b9973973678999f15ea37d17 Author: Greg Kroah-Hartman Date: Mon May 3 13:57:13 2021 +0200 Revert "isdn: mISDN: Fix potential NULL pointer dereference of kzalloc" [ Upstream commit 36a2c87f7ed9e305d05b9a5c044cc6c494771504 ] This reverts commit 38d22659803a033b1b66cd2624c33570c0dde77d. Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not. Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change. While it looks like the original change is correct, it is not, as none of the setup actually happens, and the error value is not propagated upwards. Cc: Aditya Pakki Cc: David S. Miller Link: https://lore.kernel.org/r/20210503115736.2104747-47-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 34f4c208a8ce5e640a523f089cfe22c7b4c8f2f8 Author: Anirudh Rayabharam Date: Mon May 3 13:57:10 2021 +0200 ath6kl: return error code in ath6kl_wmi_set_roam_lrssi_cmd() [ Upstream commit 54433367840b46a1555c8ed36c4c0cfc5dbf1358 ] Propagate error code from failure of ath6kl_wmi_cmd_send() to the caller. Signed-off-by: Anirudh Rayabharam Cc: Kalle Valo Link: https://lore.kernel.org/r/20210503115736.2104747-44-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 7e0dc2e96870ae5ff4a445e6dfc787381cb9b657 Author: Greg Kroah-Hartman Date: Mon May 3 13:57:09 2021 +0200 Revert "ath6kl: return error code in ath6kl_wmi_set_roam_lrssi_cmd()" [ Upstream commit efba106f89fc6848726716c101f4c84e88720a9c ] This reverts commit fc6a6521556c8250e356ddc6a3f2391aa62dc976. Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not. Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change. The change being reverted does NOTHING as the caller to this function does not even look at the return value of the call. So the "claim" that this fixed an an issue is not true. It will be fixed up properly in a future patch by propagating the error up the stack correctly. Cc: Kangjie Lu Cc: Kalle Valo Link: https://lore.kernel.org/r/20210503115736.2104747-43-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 576675c286a0fed3dde088421cb4f47d868d8850 Author: Phillip Potter Date: Mon May 3 13:57:08 2021 +0200 isdn: mISDNinfineon: check/cleanup ioremap failure correctly in setup_io [ Upstream commit c446f0d4702d316e1c6bf621f70e79678d28830a ] Move hw->cfg.mode and hw->addr.mode assignments from hw->ci->cfg_mode and hw->ci->addr_mode respectively, to be before the subsequent checks for memory IO mode (and possible ioremap calls in this case). Also introduce ioremap error checks at both locations. This allows resources to be properly freed on ioremap failure, as when the caller of setup_io then subsequently calls release_io via its error path, release_io can now correctly determine the mode as it has been set before the ioremap call. Finally, refactor release_io function so that it will call release_mem_region in the memory IO case, regardless of whether or not hw->cfg.p/hw->addr.p are NULL. This means resources are then properly released on failure. This properly implements the original reverted commit (d721fe99f6ad) from the University of Minnesota, whilst also implementing the ioremap check for the hw->ci->cfg_mode if block as well. Cc: David S. Miller Signed-off-by: Phillip Potter Link: https://lore.kernel.org/r/20210503115736.2104747-42-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 941062256773afedd173102c08da4c41c2ab12d4 Author: Greg Kroah-Hartman Date: Mon May 3 13:57:07 2021 +0200 Revert "isdn: mISDNinfineon: fix potential NULL pointer dereference" [ Upstream commit abd7bca23bd4247124265152d00ffd4b2b0d6877 ] This reverts commit d721fe99f6ada070ae8fc0ec3e01ce5a42def0d9. Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not. Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change. The original commit was incorrect, it should have never have used "unlikely()" and if it ever does trigger, resources are left grabbed. Given there are no users for this code around, I'll just revert this and leave it "as is" as the odds that ioremap() will ever fail here is horrendiously low. Cc: Kangjie Lu Cc: David S. Miller Link: https://lore.kernel.org/r/20210503115736.2104747-41-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 1f886612686ca511edfea4406312c3cea601bcaa Author: Greg Kroah-Hartman Date: Mon May 3 13:57:03 2021 +0200 Revert "ALSA: usx2y: Fix potential NULL pointer dereference" [ Upstream commit 4667a6fc1777ce071504bab570d3599107f4790f ] This reverts commit a2c6433ee5a35a8de6d563f6512a26f87835ea0f. Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not. Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change. The original patch was incorrect, and would leak memory if the error path the patch added was hit. Cc: Aditya Pakki Reviewed-by: Takashi Iwai Link: https://lore.kernel.org/r/20210503115736.2104747-37-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 95886dbe3e1c8a0a6c244c6b6178fa9ba2db462d Author: Greg Kroah-Hartman Date: Mon May 3 13:56:59 2021 +0200 Revert "ALSA: gus: add a check of the status of snd_ctl_add" [ Upstream commit 1dacca7fa1ebea47d38d20cd2df37094805d2649 ] This reverts commit 0f25e000cb4398081748e54f62a902098aa79ec1. Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not. Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change. The original commit did nothing if there was an error, except to print out a message, which is pointless. So remove the commit as it gives a "false sense of doing something". Cc: Kangjie Lu Reviewed-by: Takashi Iwai Link: https://lore.kernel.org/r/20210503115736.2104747-33-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c8972b14044a81abcb29526e89140cd81364febb Author: Tom Seewald Date: Mon May 3 13:56:56 2021 +0200 char: hpet: add checks after calling ioremap [ Upstream commit b11701c933112d49b808dee01cb7ff854ba6a77a ] The function hpet_resources() calls ioremap() two times, but in both cases it does not check if ioremap() returned a null pointer. Fix this by adding null pointer checks and returning an appropriate error. Signed-off-by: Tom Seewald Link: https://lore.kernel.org/r/20210503115736.2104747-30-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 0f4e71f3d3393c56df8e0690db84f0c395fc2d31 Author: Greg Kroah-Hartman Date: Mon May 3 13:56:55 2021 +0200 Revert "char: hpet: fix a missing check of ioremap" [ Upstream commit 566f53238da74801b48e985788e5f7c9159e5940 ] This reverts commit 13bd14a41ce3105d5b1f3cd8b4d1e249d17b6d9b. Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not. Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change. While this is technically correct, it is only fixing ONE of these errors in this function, so the patch is not fully correct. I'll leave this revert and provide a fix for this later that resolves this same "problem" everywhere in this function. Cc: Kangjie Lu Link: https://lore.kernel.org/r/20210503115736.2104747-29-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 4d2b8fcc3fc88a58daf69a9fc4f79fb818ac419d Author: Du Cheng Date: Mon May 3 13:56:46 2021 +0200 net: caif: remove BUG_ON(dev == NULL) in caif_xmit [ Upstream commit 65a67792e3416f7c5d7daa47d99334cbb19a7449 ] The condition of dev == NULL is impossible in caif_xmit(), hence it is for the removal. Explanation: The static caif_xmit() is only called upon via a function pointer `ndo_start_xmit` defined in include/linux/netdevice.h: ``` struct net_device_ops { ... netdev_tx_t (*ndo_start_xmit)(struct sk_buff *skb, struct net_device *dev); ... } ``` The exhausive list of call points are: ``` drivers/net/ethernet/qualcomm/rmnet/rmnet_map_command.c dev->netdev_ops->ndo_start_xmit(skb, dev); ^ ^ drivers/infiniband/ulp/opa_vnic/opa_vnic_netdev.c struct opa_vnic_adapter *adapter = opa_vnic_priv(netdev); ^ ^ return adapter->rn_ops->ndo_start_xmit(skb, netdev); // adapter would crash first ^ ^ drivers/usb/gadget/function/f_ncm.c ncm->netdev->netdev_ops->ndo_start_xmit(NULL, ncm->netdev); ^ ^ include/linux/netdevice.h static inline netdev_tx_t __netdev_start_xmit(... { return ops->ndo_start_xmit(skb, dev); ^ } const struct net_device_ops *ops = dev->netdev_ops; ^ rc = __netdev_start_xmit(ops, skb, dev, more); ^ ``` In each of the enumerated scenarios, it is impossible for the NULL-valued dev to reach the caif_xmit() without crashing the kernel earlier, therefore `BUG_ON(dev == NULL)` is rather useless, hence the removal. Cc: David S. Miller Signed-off-by: Du Cheng Link: https://lore.kernel.org/r/20210503115736.2104747-20-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 8b5bd5b7424a5bb0291ac7411c604225da24f56e Author: Greg Kroah-Hartman Date: Mon May 3 13:56:45 2021 +0200 Revert "net: caif: replace BUG_ON with recovery code" [ Upstream commit 4df07045fcfd684379a394d0f2aa0cc4067bda2a ] This reverts commit c5dea815834c7d2e9fc633785455bc428b7a1956. Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not. Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change. The original change here was pointless as dev can never be NULL in this function so the claim in the changelog that this "fixes" anything is incorrect (also the developer forgot about panic_on_warn). A follow-up change will resolve this issue properly. Cc: Aditya Pakki Cc: David S. Miller Link: https://lore.kernel.org/r/20210503115736.2104747-19-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 62c2472aeee411260dae6fabc8248eedf2e3b94d Author: Anirudh Rayabharam Date: Mon May 3 13:56:44 2021 +0200 net/smc: properly handle workqueue allocation failure [ Upstream commit bbeb18f27a44ce6adb00d2316968bc59dc640b9b ] In smcd_alloc_dev(), if alloc_ordered_workqueue() fails, properly catch it, clean up and return NULL to let the caller know there was a failure. Move the call to alloc_ordered_workqueue higher in the function in order to abort earlier without needing to unwind the call to device_initialize(). Cc: Ursula Braun Cc: David S. Miller Signed-off-by: Anirudh Rayabharam Link: https://lore.kernel.org/r/20210503115736.2104747-18-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 83d4efe6bf0309a86b00ec86dadf3ee847e3ab5e Author: Greg Kroah-Hartman Date: Mon May 3 13:56:43 2021 +0200 Revert "net/smc: fix a NULL pointer dereference" [ Upstream commit 5369ead83f5aff223b6418c99cb1fe9a8f007363 ] This reverts commit e183d4e414b64711baf7a04e214b61969ca08dfa. Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not. Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change. The original commit causes a memory leak and does not properly fix the issue it claims to fix. I will send a follow-on patch to resolve this properly. Cc: Kangjie Lu Cc: Ursula Braun Cc: David S. Miller Link: https://lore.kernel.org/r/20210503115736.2104747-17-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 71723a796ab7881f491d663c6cd94b29be5fba50 Author: Anirudh Rayabharam Date: Mon May 3 13:56:42 2021 +0200 net: fujitsu: fix potential null-ptr-deref [ Upstream commit 52202be1cd996cde6e8969a128dc27ee45a7cb5e ] In fmvj18x_get_hwinfo(), if ioremap fails there will be NULL pointer deref. To fix this, check the return value of ioremap and return -1 to the caller in case of failure. Cc: "David S. Miller" Acked-by: Dominik Brodowski Signed-off-by: Anirudh Rayabharam Link: https://lore.kernel.org/r/20210503115736.2104747-16-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit b67c3d74adc3f7f832f57c170234bbe1fc69c87c Author: Greg Kroah-Hartman Date: Mon May 3 13:56:41 2021 +0200 Revert "net: fujitsu: fix a potential NULL pointer dereference" [ Upstream commit 5f94eaa4ee23e80841fa359a372f84cfe25daee1 ] This reverts commit 9f4d6358e11bbc7b839f9419636188e4151fb6e4. Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not. Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change. The original change does not change any behavior as the caller of this function onlyu checks for "== -1" as an error condition so this error is not handled properly. Remove this change and it will be fixed up properly in a later commit. Cc: Kangjie Lu Cc: David S. Miller Reviewed-by: Dominik Brodowski Link: https://lore.kernel.org/r/20210503115736.2104747-15-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 52610c1d2577eae5942303df4074b4fafeaf900d Author: Atul Gopinathan Date: Mon May 3 13:56:38 2021 +0200 serial: max310x: unregister uart driver in case of failure and abort [ Upstream commit 3890e3dea315f1a257d1b940a2a4e2fa16a7b095 ] The macro "spi_register_driver" invokes the function "__spi_register_driver()" which has a return type of int and can fail, returning a negative value in such a case. This is currently ignored and the init() function yields success even if the spi driver failed to register. Fix this by collecting the return value of "__spi_register_driver()" and also unregister the uart driver in case of failure. Cc: Jiri Slaby Signed-off-by: Atul Gopinathan Link: https://lore.kernel.org/r/20210503115736.2104747-12-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit f7d0b8542fbc1347240cb9068d97db50af0672c8 Author: Greg Kroah-Hartman Date: Mon May 3 13:56:37 2021 +0200 Revert "serial: max310x: pass return value of spi_register_driver" [ Upstream commit b0a85abbe92e1a6f3e8580a4590fa7245de7090b ] This reverts commit 51f689cc11333944c7a457f25ec75fcb41e99410. Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not. Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change. This change did not properly unwind from the error condition, so it was not correct. Cc: Kangjie Lu Acked-by: Jiri Slaby Link: https://lore.kernel.org/r/20210503115736.2104747-11-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 6bbcc1206c4093c33a10b3f0914ab61eba11f2f5 Author: Greg Kroah-Hartman Date: Mon May 3 13:56:34 2021 +0200 Revert "ALSA: sb: fix a missing check of snd_ctl_add" [ Upstream commit 4b059ce1f4b368208c2310925f49be77f15e527b ] This reverts commit beae77170c60aa786f3e4599c18ead2854d8694d. Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not. Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It is safe to ignore this error as the mixer element is optional, and the driver is very legacy. Cc: Aditya Pakki Reviewed-by: Takashi Iwai Link: https://lore.kernel.org/r/20210503115736.2104747-8-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 870a11325e69b383ab977c0ad2edc6f4e7a8ca09 Author: Greg Kroah-Hartman Date: Mon May 3 13:56:33 2021 +0200 Revert "media: usb: gspca: add a missed check for goto_low_power" [ Upstream commit fd013265e5b5576a74a033920d6c571e08d7c423 ] This reverts commit 5b711870bec4dc9a6d705d41e127e73944fa3650. Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not. Upon review, this commit was found to do does nothing useful as a user can do nothing with this information and if an error did happen, the code would continue on as before. Because of this, just revert it. Cc: Kangjie Lu Cc: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/20210503115736.2104747-7-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit dac2dde8ee5497c635767e4d84d0ee2b36a60e32 Author: Greg Kroah-Hartman Date: Wed Apr 28 09:49:31 2021 +0200 Revert "crypto: cavium/nitrox - add an error message to explain the failure of pci_request_mem_regions" [ Upstream commit 6a3239a738d86c5e9b5aad17fefe2c2bfd6ced83 ] This reverts commit 9fcddaf2e28d779cb946d23838ba6d50f299aa80 as it was submitted under a fake name and we can not knowingly accept anonymous contributions to the repository. This commit was part of a submission "test" to the Linux kernel community by some "researchers" at umn.edu. As outlined at: https://www-users.cs.umn.edu/%7Ekjlu/papers/full-disclosure.pdf it was done so as an attempt to submit a known-buggy patch to see if it could get by our review. However, the submission turned out to actually be correct, and not have a bug in it as the author did not understand how the PCI driver model works at all, and so the submission was accepted. As this change is of useless consequence, there is no loss of functionality in reverting it. Cc: "David S. Miller" Cc: Christophe JAILLET Cc: linux-crypto@vger.kernel.org Acked-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman Email: Herbert Xu Link: https://lore.kernel.org/r/YIkTi9a3nnL50wMq@kroah.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 2bfa3ab89cec2dcc53bc8dd4084fb2ce88e459c2 Author: Zou Wei Date: Wed May 12 11:17:47 2021 +0800 gpio: cadence: Add missing MODULE_DEVICE_TABLE [ Upstream commit 1e948b1752b58c9c570989ab29ceef5b38fdccda ] This patch adds missing MODULE_DEVICE_TABLE definition which generates correct modalias for automatic loading of this driver when it is built as an external module. Reported-by: Hulk Robot Signed-off-by: Zou Wei Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 515181e38e9788a0fff038109dd62b8bf6819e76 Author: Kai-Heng Feng Date: Fri Apr 30 14:07:35 2021 +0800 platform/x86: hp_accel: Avoid invoking _INI to speed up resume [ Upstream commit 79d341e26ebcdbc622348aaaab6f8f89b6fdb25f ] hp_accel can take almost two seconds to resume on some HP laptops. The bottleneck is on evaluating _INI, which is only needed to run once. Resolve the issue by only invoking _INI when it's necessary. Namely, on probe and on hibernation restore. Signed-off-by: Kai-Heng Feng Acked-by: Éric Piel Link: https://lore.kernel.org/r/20210430060736.590321-1-kai.heng.feng@canonical.com Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin commit 3267a061096efc91eda52c2a0c61ba76e46e4b34 Author: Paolo Abeni Date: Tue May 11 19:13:51 2021 +0200 mptcp: fix data stream corruption commit 29249eac5225429b898f278230a6ca2baa1ae154 upstream. Maxim reported several issues when forcing a TCP transparent proxy to use the MPTCP protocol for the inbound connections. He also provided a clean reproducer. The problem boils down to 'mptcp_frag_can_collapse_to()' assuming that only MPTCP will use the given page_frag. If others - e.g. the plain TCP protocol - allocate page fragments, we can end-up re-using already allocated memory for mptcp_data_frag. Fix the issue ensuring that the to-be-expanded data fragment is located at the current page frag end. v1 -> v2: - added missing fixes tag (Mat) Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/178 Reported-and-tested-by: Maxim Galaganov Fixes: 18b683bff89d ("mptcp: queue data for mptcp level retransmission") Signed-off-by: Paolo Abeni Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit deeb7d84f20a5b390c1b1bae088170f568958d20 Author: Paolo Abeni Date: Tue May 25 14:23:11 2021 -0700 mptcp: drop unconditional pr_warn on bad opt commit 3812ce895047afdb78dc750a236515416e0ccded upstream. This is a left-over of early day. A malicious peer can flood the kernel logs with useless messages, just drop it. Fixes: f296234c98a8 ("mptcp: Add handling of incoming MP_JOIN requests") Signed-off-by: Paolo Abeni Signed-off-by: Mat Martineau Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 71227b62143d6d3f7a59d689ecdb393273015a7a Author: Paolo Abeni Date: Tue May 25 14:23:12 2021 -0700 mptcp: avoid error message on infinite mapping commit 3ed0a585bfadb6bd7080f11184adbc9edcce7dbc upstream. Another left-over. Avoid flooding dmesg with useless text, we already have a MIB for that event. Fixes: 648ef4b88673 ("mptcp: Implement MPTCP receive path") Signed-off-by: Paolo Abeni Signed-off-by: Mat Martineau Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit cb554bbf364ba8b6925456e8207f3a12ad275e48 Author: Hou Pu Date: Thu May 20 19:30:45 2021 +0800 nvmet-tcp: fix inline data size comparison in nvmet_tcp_queue_response commit 25df1acd2d36eb72b14c3d00f6b861b1e00b3aab upstream. Using "<=" instead "<" to compare inline data size. Fixes: bdaf13279192 ("nvmet-tcp: fix a segmentation fault during io parsing error") Signed-off-by: Hou Pu Reviewed-by: Sagi Grimberg Signed-off-by: Christoph Hellwig Signed-off-by: Greg Kroah-Hartman commit e31975c346bf653276423a5d1f25f1c597c522ba Author: Felix Fietkau Date: Tue May 25 18:07:58 2021 +0200 perf jevents: Fix getting maximum number of fds commit 75ea44e356b5de8c817f821c9dd68ae329e82add upstream. On some hosts, rlim.rlim_max can be returned as RLIM_INFINITY. By casting it to int, it is interpreted as -1, which will cause get_maxfds to return 0, causing "Invalid argument" errors in nftw() calls. Fix this by casting the second argument of min() to rlim_t instead. Fixes: 80eeb67fe577 ("perf jevents: Program to convert JSON file") Signed-off-by: Felix Fietkau Cc: Alexander Shishkin Cc: Andi Kleen Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Sukadev Bhattiprolu Link: http://lore.kernel.org/lkml/20210525160758.97829-1-nbd@nbd.name Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit ee8a8dd10e1e02bc831f03c3f30ee97e0e09c663 Author: David Howells Date: Thu May 27 11:24:33 2021 +0100 afs: Fix the nlink handling of dir-over-dir rename commit f610a5a29c3cfb7d37bdfa4ef52f72ea51f24a76 upstream. Fix rename of one directory over another such that the nlink on the deleted directory is cleared to 0 rather than being decremented to 1. This was causing the generic/035 xfstest to fail. Fixes: e49c7b2f6de7 ("afs: Build an abstraction around an "operation" concept") Signed-off-by: David Howells Reviewed-by: Marc Dionne cc: linux-afs@lists.infradead.org Link: https://lore.kernel.org/r/162194384460.3999479.7605572278074191079.stgit@warthog.procyon.org.uk/ # v1 Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit ce23a0ad495536148fd7065dbd5b247b423343eb Author: Geert Uytterhoeven Date: Thu May 6 13:15:40 2021 +0200 i2c: sh_mobile: Use new clock calculation formulas for RZ/G2E commit c4740e293c93c747e65d53d9aacc2ba8521d1489 upstream. When switching the Gen3 SoCs to the new clock calculation formulas, the match entry for RZ/G2E added in commit 51243b73455f2d12 ("i2c: sh_mobile: Add support for r8a774c0 (RZ/G2E)") was forgotten. Fixes: e8a27567509b2439 ("i2c: sh_mobile: use new clock calculation formulas for Gen3") Signed-off-by: Geert Uytterhoeven Reviewed-by: Fabrizio Castro Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit b523feb7e8e44652f92f3babb953a976e7ccbbef Author: Jean Delvare Date: Tue May 25 17:03:36 2021 +0200 i2c: i801: Don't generate an interrupt on bus reset commit e4d8716c3dcec47f1557024add24e1f3c09eb24b upstream. Now that the i2c-i801 driver supports interrupts, setting the KILL bit in a attempt to recover from a timed out transaction triggers an interrupt. Unfortunately, the interrupt handler (i801_isr) is not prepared for this situation and will try to process the interrupt as if it was signaling the end of a successful transaction. In the case of a block transaction, this can result in an out-of-range memory access. This condition was reproduced several times by syzbot: https://syzkaller.appspot.com/bug?extid=ed71512d469895b5b34e https://syzkaller.appspot.com/bug?extid=8c8dedc0ba9e03f6c79e https://syzkaller.appspot.com/bug?extid=c8ff0b6d6c73d81b610e https://syzkaller.appspot.com/bug?extid=33f6c360821c399d69eb https://syzkaller.appspot.com/bug?extid=be15dc0b1933f04b043a https://syzkaller.appspot.com/bug?extid=b4d3fd1dfd53e90afd79 So disable interrupts while trying to reset the bus. Interrupts will be enabled again for the following transaction. Fixes: 636752bcb517 ("i2c-i801: Enable IRQ for SMBus transactions") Reported-by: syzbot+b4d3fd1dfd53e90afd79@syzkaller.appspotmail.com Signed-off-by: Jean Delvare Acked-by: Andy Shevchenko Cc: Jarkko Nikula Tested-by: Jarkko Nikula Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit 87f18aa51e3e32aa77f86e6e30b73d46c792cd59 Author: Qii Wang Date: Thu May 27 20:04:04 2021 +0800 i2c: mediatek: Disable i2c start_en and clear intr_stat brfore reset commit fed1bd51a504eb96caa38b4f13ab138fc169ea75 upstream. The i2c controller driver do dma reset after transfer timeout, but sometimes dma reset will trigger an unexpected DMA_ERR irq. It will cause the i2c controller to continuously send interrupts to the system and cause soft lock-up. So we need to disable i2c start_en and clear intr_stat to stop i2c controller before dma reset when transfer timeout. Fixes: aafced673c06("i2c: mediatek: move dma reset before i2c reset") Signed-off-by: Qii Wang Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit eff3c5b67fbb99558c3faac4750044a74d5dbdbe Author: Krzysztof Kozlowski Date: Wed May 26 08:39:37 2021 -0400 i2c: s3c2410: fix possible NULL pointer deref on read message after write commit 24990423267ec283b9d86f07f362b753eb9b0ed5 upstream. Interrupt handler processes multiple message write requests one after another, till the driver message queue is drained. However if driver encounters a read message without preceding START, it stops the I2C transfer as it is an invalid condition for the controller. At least the comment describes a requirement "the controller forces us to send a new START when we change direction". This stop results in clearing the message queue (i2c->msg = NULL). The code however immediately jumped back to label "retry_write" which dereferenced the "i2c->msg" making it a possible NULL pointer dereference. The Coverity analysis: 1. Condition !is_msgend(i2c), taking false branch. if (!is_msgend(i2c)) { 2. Condition !is_lastmsg(i2c), taking true branch. } else if (!is_lastmsg(i2c)) { 3. Condition i2c->msg->flags & 1, taking true branch. if (i2c->msg->flags & I2C_M_RD) { 4. write_zero_model: Passing i2c to s3c24xx_i2c_stop, which sets i2c->msg to NULL. s3c24xx_i2c_stop(i2c, -EINVAL); 5. Jumping to label retry_write. goto retry_write; 6. var_deref_model: Passing i2c to is_msgend, which dereferences null i2c->msg. if (!is_msgend(i2c)) {" All previous calls to s3c24xx_i2c_stop() in this interrupt service routine are followed by jumping to end of function (acknowledging the interrupt and returning). This seems a reasonable choice also here since message buffer was entirely emptied. Addresses-Coverity: Explicit null dereferenced Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Krzysztof Kozlowski Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit 935c9443f81c89dce04683c73d0f136d2d89351c Author: Vladimir Oltean Date: Mon May 24 12:25:22 2021 +0300 net: dsa: sja1105: fix VL lookup command packing for P/Q/R/S commit ba61cf167cb77e54c1ec5adb7aa49a22ab3c9b28 upstream. At the beginning of the sja1105_dynamic_config.c file there is a diagram of the dynamic config interface layout: packed_buf | V +-----------------------------------------+------------------+ | ENTRY BUFFER | COMMAND BUFFER | +-----------------------------------------+------------------+ <----------------------- packed_size ------------------------> So in order to pack/unpack the command bits into the buffer, sja1105_vl_lookup_cmd_packing must first advance the buffer pointer by the length of the entry. This is similar to what the other *cmd_packing functions do. This bug exists because the command packing function for P/Q/R/S was copied from the E/T generation, and on E/T, the command was actually embedded within the entry buffer itself. Fixes: 94f94d4acfb2 ("net: dsa: sja1105: add static tables for virtual links") Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 83999bf40c78ec344b7c1066dc50f21ac2519bdf Author: Vladimir Oltean Date: Mon May 24 12:25:23 2021 +0300 net: dsa: sja1105: call dsa_unregister_switch when allocating memory fails commit dc596e3fe63f88e3d1e509f64e7f761cd4135538 upstream. Unlike other drivers which pretty much end their .probe() execution with dsa_register_switch(), the sja1105 does some extra stuff. When that fails with -ENOMEM, the driver is quick to return that, forgetting to call dsa_unregister_switch(). Not critical, but a bug nonetheless. Fixes: 4d7525085a9b ("net: dsa: sja1105: offload the Credit-Based Shaper qdisc") Fixes: a68578c20a96 ("net: dsa: Make deferred_xmit private to sja1105") Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit dd8609f203448ca6d58ae71461208b3f6b0329b0 Author: Vladimir Oltean Date: Mon May 24 12:25:24 2021 +0300 net: dsa: sja1105: add error handling in sja1105_setup() commit cec279a898a3b004411682f212215ccaea1cd0fb upstream. If any of sja1105_static_config_load(), sja1105_clocking_setup() or sja1105_devlink_setup() fails, we can't just return in the middle of sja1105_setup() or memory will leak. Add a cleanup path. Fixes: 0a7bdbc23d8a ("net: dsa: sja1105: move devlink param code to sja1105_devlink.c") Fixes: 8aa9ebccae87 ("net: dsa: Introduce driver for NXP SJA1105 5-port L2 switch") Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 4a368bc25ab60a8e87d450327037fa743c88a545 Author: Vladimir Oltean Date: Mon May 24 12:25:25 2021 +0300 net: dsa: sja1105: error out on unsupported PHY mode commit 6729188d2646709941903052e4b78e1d82c239b9 upstream. The driver continues probing when a port is configured for an unsupported PHY interface type, instead it should stop. Fixes: 8aa9ebccae87 ("net: dsa: Introduce driver for NXP SJA1105 5-port L2 switch") Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 4ef506c0718b0fdc1d0a6dfac1682cc85fdaabf1 Author: Vladimir Oltean Date: Mon May 24 12:25:26 2021 +0300 net: dsa: sja1105: use 4095 as the private VLAN for untagged traffic commit ed040abca4c1db72dfd3b8483b6ed6bfb7c2571e upstream. One thing became visible when writing the blamed commit, and that was that STP and PTP frames injected by net/dsa/tag_sja1105.c using the deferred xmit mechanism are always classified to the pvid of the CPU port, regardless of whatever VLAN there might be in these packets. So a decision needed to be taken regarding the mechanism through which we should ensure that delivery of STP and PTP traffic is possible when we are in a VLAN awareness mode that involves tag_8021q. This is because tag_8021q is not concerned with managing the pvid of the CPU port, since as far as tag_8021q is concerned, no traffic should be sent as untagged from the CPU port. So we end up not actually having a pvid on the CPU port if we only listen to tag_8021q, and unless we do something about it. The decision taken at the time was to keep VLAN 1 in the list of priv->dsa_8021q_vlans, and make it a pvid of the CPU port. This ensures that STP and PTP frames can always be sent to the outside world. However there is a problem. If we do the following while we are in the best_effort_vlan_filtering=true mode: ip link add br0 type bridge vlan_filtering 1 ip link set swp2 master br0 bridge vlan del dev swp2 vid 1 Then untagged and pvid-tagged frames should be dropped. But we observe that they aren't, and this is because of the precaution we took that VID 1 is always installed on all ports. So clearly VLAN 1 is not good for this purpose. What about VLAN 0? Well, VLAN 0 is managed by the 8021q module, and that module wants to ensure that 802.1p tagged frames are always received by a port, and are always transmitted as VLAN-tagged (with VLAN ID 0). Whereas we want our STP and PTP frames to be untagged if the stack sent them as untagged - we don't want the driver to just decide out of the blue that it adds VID 0 to some packets. So what to do? Well, there is one other VLAN that is reserved, and that is 4095: $ ip link add link swp2 name swp2.4095 type vlan id 4095 Error: 8021q: Invalid VLAN id. $ bridge vlan add dev swp2 vid 4095 Error: bridge: Vlan id is invalid. After we made this change, VLAN 1 is indeed forwarded and/or dropped according to the bridge VLAN table, there are no further alterations done by the sja1105 driver. Fixes: ec5ae61076d0 ("net: dsa: sja1105: save/restore VLANs using a delta commit method") Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 6f4b79217f6b959087414b45ac6c95b159d092ba Author: Vladimir Oltean Date: Mon May 24 12:25:27 2021 +0300 net: dsa: sja1105: update existing VLANs from the bridge VLAN list commit b38e659de966a122fe2cb178c1e39c9bea06bc62 upstream. When running this sequence of operations: ip link add br0 type bridge vlan_filtering 1 ip link set swp4 master br0 bridge vlan add dev swp4 vid 1 We observe the traffic sent on swp4 is still untagged, even though the bridge has overwritten the existing VLAN entry: port vlan ids swp4 1 PVID br0 1 PVID Egress Untagged This happens because we didn't consider that the 'bridge vlan add' command just overwrites VLANs like it's nothing. We treat the 'vid 1 pvid untagged' and the 'vid 1' as two separate VLANs, and the first still has precedence when calling sja1105_build_vlan_table. Obviously there is a disagreement regarding semantics, and we end up doing something unexpected from the PoV of the bridge. Let's actually consider an "existing VLAN" to be one which is on the same port, and has the same VLAN ID, as one we already have, and update it if it has different flags than we do. The first blamed commit is the one introducing the bug, the second one is the latest on top of which the bugfix still applies. Fixes: ec5ae61076d0 ("net: dsa: sja1105: save/restore VLANs using a delta commit method") Fixes: 5899ee367ab3 ("net: dsa: tag_8021q: add a context structure") Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit caff86f85512b8e0d9830e8b8b0dfe13c68ce5b6 Author: Dan Carpenter Date: Sat May 8 16:30:35 2021 +0300 net: dsa: fix a crash if ->get_sset_count() fails commit a269333fa5c0c8e53c92b5a28a6076a28cde3e83 upstream. If ds->ops->get_sset_count() fails then it "count" is a negative error code such as -EOPNOTSUPP. Because "i" is an unsigned int, the negative error code is type promoted to a very high value and the loop will corrupt memory until the system crashes. Fix this by checking for error codes and changing the type of "i" to just int. Fixes: badf3ada60ab ("net: dsa: Provide CPU port statistics to master netdev") Signed-off-by: Dan Carpenter Reviewed-by: Andrew Lunn Reviewed-by: Florian Fainelli Reviewed-by: Vladimir Oltean Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b91117b66fe875723a4e79ec6263526fffdb44d2 Author: DENG Qingfang Date: Sun May 23 22:51:54 2021 +0800 net: dsa: mt7530: fix VLAN traffic leaks commit 474a2ddaa192777522a7499784f1d60691cd831a upstream. PCR_MATRIX field was set to all 1's when VLAN filtering is enabled, but was not reset when it is disabled, which may cause traffic leaks: ip link add br0 type bridge vlan_filtering 1 ip link add br1 type bridge vlan_filtering 1 ip link set swp0 master br0 ip link set swp1 master br1 ip link set br0 type bridge vlan_filtering 0 ip link set br1 type bridge vlan_filtering 0 # traffic in br0 and br1 will start leaking to each other As port_bridge_{add,del} have set up PCR_MATRIX properly, remove the PCR_MATRIX write from mt7530_port_set_vlan_aware. Fixes: 83163f7dca56 ("net: dsa: mediatek: add VLAN support for MT7530") Signed-off-by: DENG Qingfang Reviewed-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 6d6bc8c75290866e59ee25ab6bb0114eb166b980 Author: Roi Dayan Date: Mon May 10 14:50:24 2021 +0300 netfilter: flowtable: Remove redundant hw refresh bit commit c07531c01d8284aedaf95708ea90e76d11af0e21 upstream. Offloading conns could fail for multiple reasons and a hw refresh bit is set to try to reoffload it in next sw packet. But it could be in some cases and future points that the hw refresh bit is not set but a refresh could succeed. Remove the hw refresh bit and do offload refresh if requested. There won't be a new work entry if a work is already pending anyway as there is the hw pending bit. Fixes: 8b3646d6e0c4 ("net/sched: act_ct: Support refreshing the flow table entries") Signed-off-by: Roi Dayan Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit fe6921e3b8451a537e01c031b8212366bb386e3e Author: Christophe JAILLET Date: Sun May 9 21:12:27 2021 +0200 spi: spi-fsl-dspi: Fix a resource leak in an error handling path commit 680ec0549a055eb464dce6ffb4bfb736ef87236e upstream. 'dspi_request_dma()' should be undone by a 'dspi_release_dma()' call in the error handling path of the probe function, as already done in the remove function Fixes: 90ba37033cb9 ("spi: spi-fsl-dspi: Add DMA support for Vybrid") Signed-off-by: Christophe JAILLET Reviewed-by: Vladimir Oltean Link: https://lore.kernel.org/r/d51caaac747277a1099ba8dea07acd85435b857e.1620587472.git.christophe.jaillet@wanadoo.fr Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 6da24cfc83ba4f97ea44fc7ae9999a006101755c Author: Xin Long Date: Sat May 8 03:57:03 2021 +0800 tipc: skb_linearize the head skb when reassembling msgs commit b7df21cf1b79ab7026f545e7bf837bd5750ac026 upstream. It's not a good idea to append the frag skb to a skb's frag_list if the frag_list already has skbs from elsewhere, such as this skb was created by pskb_copy() where the frag_list was cloned (all the skbs in it were skb_get'ed) and shared by multiple skbs. However, the new appended frag skb should have been only seen by the current skb. Otherwise, it will cause use after free crashes as this appended frag skb are seen by multiple skbs but it only got skb_get called once. The same thing happens with a skb updated by pskb_may_pull() with a skb_cloned skb. Li Shuang has reported quite a few crashes caused by this when doing testing over macvlan devices: [] kernel BUG at net/core/skbuff.c:1970! [] Call Trace: [] skb_clone+0x4d/0xb0 [] macvlan_broadcast+0xd8/0x160 [macvlan] [] macvlan_process_broadcast+0x148/0x150 [macvlan] [] process_one_work+0x1a7/0x360 [] worker_thread+0x30/0x390 [] kernel BUG at mm/usercopy.c:102! [] Call Trace: [] __check_heap_object+0xd3/0x100 [] __check_object_size+0xff/0x16b [] simple_copy_to_iter+0x1c/0x30 [] __skb_datagram_iter+0x7d/0x310 [] __skb_datagram_iter+0x2a5/0x310 [] skb_copy_datagram_iter+0x3b/0x90 [] tipc_recvmsg+0x14a/0x3a0 [tipc] [] ____sys_recvmsg+0x91/0x150 [] ___sys_recvmsg+0x7b/0xc0 [] kernel BUG at mm/slub.c:305! [] Call Trace: [] [] kmem_cache_free+0x3ff/0x400 [] __netif_receive_skb_core+0x12c/0xc40 [] ? kmem_cache_alloc+0x12e/0x270 [] netif_receive_skb_internal+0x3d/0xb0 [] ? get_rx_page_info+0x8e/0xa0 [be2net] [] be_poll+0x6ef/0xd00 [be2net] [] ? irq_exit+0x4f/0x100 [] net_rx_action+0x149/0x3b0 ... This patch is to fix it by linearizing the head skb if it has frag_list set in tipc_buf_append(). Note that we choose to do this before calling skb_unshare(), as __skb_linearize() will avoid skb_copy(). Also, we can not just drop the frag_list either as the early time. Fixes: 45c8b7b175ce ("tipc: allow non-linear first fragment buffer") Reported-by: Li Shuang Signed-off-by: Xin Long Acked-by: Jon Maloy Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 5195ec5e365a2a9331bfeb585b613a6e94f98dba Author: Xin Long Date: Mon May 17 02:28:58 2021 +0800 tipc: wait and exit until all work queues are done commit 04c26faa51d1e2fe71cf13c45791f5174c37f986 upstream. On some host, a crash could be triggered simply by repeating these commands several times: # modprobe tipc # tipc bearer enable media udp name UDP1 localip 127.0.0.1 # rmmod tipc [] BUG: unable to handle kernel paging request at ffffffffc096bb00 [] Workqueue: events 0xffffffffc096bb00 [] Call Trace: [] ? process_one_work+0x1a7/0x360 [] ? worker_thread+0x30/0x390 [] ? create_worker+0x1a0/0x1a0 [] ? kthread+0x116/0x130 [] ? kthread_flush_work_fn+0x10/0x10 [] ? ret_from_fork+0x35/0x40 When removing the TIPC module, the UDP tunnel sock will be delayed to release in a work queue as sock_release() can't be done in rtnl_lock(). If the work queue is schedule to run after the TIPC module is removed, kernel will crash as the work queue function cleanup_beareri() code no longer exists when trying to invoke it. To fix it, this patch introduce a member wq_count in tipc_net to track the numbers of work queues in schedule, and wait and exit until all work queues are done in tipc_exit_net(). Fixes: d0f91938bede ("tipc: add ip/udp media type") Reported-by: Shuang Li Signed-off-by: Xin Long Acked-by: Jon Maloy Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 0aa2212940b85f71b81383e6bfdf70c439eeff04 Author: Hoang Le Date: Fri May 14 08:23:03 2021 +0700 Revert "net:tipc: Fix a double free in tipc_sk_mcast_rcv" commit 75016891357a628d2b8acc09e2b9b2576c18d318 upstream. This reverts commit 6bf24dc0cc0cc43b29ba344b66d78590e687e046. Above fix is not correct and caused memory leak issue. Fixes: 6bf24dc0cc0c ("net:tipc: Fix a double free in tipc_sk_mcast_rcv") Acked-by: Jon Maloy Acked-by: Tung Nguyen Signed-off-by: Hoang Le Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 5343fcfc6cc8747438f60cc60a73c7f4a9082b16 Author: NeilBrown Date: Mon May 17 09:59:10 2021 +1000 SUNRPC in case of backlog, hand free slots directly to waiting task commit e877a88d1f069edced4160792f42c2a8e2dba942 upstream. If sunrpc.tcp_max_slot_table_entries is small and there are tasks on the backlog queue, then when a request completes it is freed and the first task on the queue is woken. The expectation is that it will wake and claim that request. However if it was a sync task and the waiting process was killed at just that moment, it will wake and NOT claim the request. As long as TASK_CONGESTED remains set, requests can only be claimed by tasks woken from the backlog, and they are woken only as requests are freed, so when a task doesn't claim a request, no other task can ever get that request until TASK_CONGESTED is cleared. Each time this happens the number of available requests is decreased by one. With a sufficiently high workload and sufficiently low setting of max_slot (16 in the case where this was seen), TASK_CONGESTED can remain set for an extended period, and the above scenario (of a process being killed just as its task was woken) can repeat until no requests can be allocated. Then traffic stops. This patch addresses the problem by introducing a positive handover of a request from a completing task to a backlog task - the request is never freed when there is a backlog. When a task is woken it might not already have a request attached in which case it is *not* freed (as with current code) but is initialised (if needed) and used. If it isn't used it will eventually be freed by rpc_exit_task(). xprt_release() is enhanced to be able to correctly release an uninitialised request. Fixes: ba60eb25ff6b ("SUNRPC: Fix a livelock problem in the xprt->backlog queue") Signed-off-by: NeilBrown Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 5dc905501f71b03019e53c33f91ed25072c738c3 Author: Ariel Levkovich Date: Wed Mar 31 10:09:02 2021 +0300 net/mlx5: Set term table as an unmanaged flow table commit 6ff51ab8aa8fcbcddeeefce8ca705b575805d12b upstream. Termination tables are restricted to have the default miss action and cannot be set to forward to another table in case of a miss. If the fs prio of the termination table is not the last one in the list, fs_core will attempt to attach it to another table. Set the unmanaged ft flag when creating the termination table ft and select the tc offload prio for it to prevent fs_core from selecting the forwarding to next ft miss action and use the default one. In addition, set the flow that forwards to the termination table to ignore ft level restrictions since the ft level is not set by fs_core for unamanged fts. Fixes: 249ccc3c95bd ("net/mlx5e: Add support for offloading traffic from uplink to uplink") Signed-off-by: Ariel Levkovich Signed-off-by: Greg Kroah-Hartman commit 143154a151c98c144a5bce63cd69f0b21be8b010 Author: Vladyslav Tarasiuk Date: Sun May 9 09:43:18 2021 +0300 net/mlx4: Fix EEPROM dump support commit db825feefc6868896fed5e361787ba3bee2fd906 upstream. Fix SFP and QSFP* EEPROM queries by setting i2c_address, offset and page number correctly. For SFP set the following params: - I2C address for offsets 0-255 is 0x50. For 256-511 - 0x51. - Page number is zero. - Offset is 0-255. At the same time, QSFP* parameters are different: - I2C address is always 0x50. - Page number is not limited to zero. - Offset is 0-255 for page zero and 128-255 for others. To set parameters accordingly to cable used, implement function to query module ID and implement respective helper functions to set parameters correctly. Fixes: 135dd9594f12 ("net/mlx4_en: ethtool, Remove unsupported SFP EEPROM high pages query") Signed-off-by: Vladyslav Tarasiuk Signed-off-by: Tariq Toukan Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 2e4b0b95a489259f9d35a3db17023061f8f3d587 Author: Roi Dayan Date: Mon May 3 18:01:02 2021 +0300 net/mlx5e: Fix null deref accessing lag dev commit 83026d83186bc48bb41ee4872f339b83f31dfc55 upstream. It could be the lag dev is null so stop processing the event. In bond_enslave() the active/backup slave being set before setting the upper dev so first event is without an upper dev. After setting the upper dev with bond_master_upper_dev_link() there is a second event and in that event we have an upper dev. Fixes: 7e51891a237f ("net/mlx5e: Use netdev events to set/del egress acl forward-to-vport rule") Signed-off-by: Roi Dayan Reviewed-by: Maor Dickman Signed-off-by: Saeed Mahameed Signed-off-by: Greg Kroah-Hartman commit cb6cc62d9e0f852c7226fa607e3ef7517e69e937 Author: Jianbo Liu Date: Fri Apr 30 06:58:29 2021 +0000 net/mlx5: Set reformat action when needed for termination rules commit 442b3d7b671bcb779ebdad46edd08051eb8b28d9 upstream. For remote mirroring, after the tunnel packets are received, they are decapsulated and sent to representor, then re-encapsulated and sent out over another tunnel. So reformat action is set only when the destination is required to do encapsulation. Fixes: 249ccc3c95bd ("net/mlx5e: Add support for offloading traffic from uplink to uplink") Signed-off-by: Jianbo Liu Reviewed-by: Ariel Levkovich Signed-off-by: Saeed Mahameed Signed-off-by: Greg Kroah-Hartman commit 2dde54e76b68a51b0e2f036c95db18d83a75dbdf Author: Dima Chumak Date: Mon Apr 26 15:16:26 2021 +0300 net/mlx5e: Fix nullptr in add_vlan_push_action() commit dca59f4a791960ec73fa15803faa0abe0f92ece2 upstream. The result of dev_get_by_index_rcu() is not checked for NULL and then gets dereferenced immediately. Also, the RCU lock must be held by the caller of dev_get_by_index_rcu(), which isn't satisfied by the call stack. Fix by handling nullptr return value when iflink device is not found. Add RCU locking around dev_get_by_index_rcu() to avoid possible adverse effects while iterating over the net_device's hlist. It is safe not to increment reference count of the net_device pointer in case of a successful lookup, because it's already handled by VLAN code during VLAN device registration (see register_vlan_dev and netdev_upper_dev_link). Fixes: 278748a95aa3 ("net/mlx5e: Offload TC e-switch rules with egress VLAN device") Addresses-Coverity: ("Dereference null return value") Signed-off-by: Dima Chumak Reviewed-by: Vlad Buslov Signed-off-by: Saeed Mahameed Signed-off-by: Greg Kroah-Hartman commit 89a0e388c6f2ea73434727ca4780150874e225a7 Author: Eli Cohen Date: Thu Apr 22 15:48:10 2021 +0300 {net,vdpa}/mlx5: Configure interface MAC into mpfs L2 table commit 7c9f131f366ab414691907fa0407124ea2b2f3bc upstream. net/mlx5: Expose MPFS configuration API MPFS is the multi physical function switch that bridges traffic between the physical port and any physical functions associated with it. The driver is required to add or remove MAC entries to properly forward incoming traffic to the correct physical function. We export the API to control MPFS so that other drivers, such as mlx5_vdpa are able to add MAC addresses of their network interfaces. The MAC address of the vdpa interface must be configured into the MPFS L2 address. Failing to do so could cause, in some NIC configurations, failure to forward packets to the vdpa network device instance. Fix this by adding calls to update the MPFS table. CC: CC: CC: Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported mlx5 devices") Signed-off-by: Eli Cohen Signed-off-by: Saeed Mahameed Signed-off-by: Greg Kroah-Hartman commit bbd00c4d50db3558c01b008a98f994063d5c9c4e Author: Aya Levin Date: Wed Apr 21 14:26:31 2021 +0300 net/mlx5e: Fix error path of updating netdev queues commit 5e7923acbd86d0ff29269688d8a9c47ad091dd46 upstream. Avoid division by zero in the error flow. In the driver TC number can be either 1 or 8. When TC count is set to 1, driver zero netdev->num_tc. Hence, need to convert it back from 0 to 1 in the error flow. Fixes: fa3748775b92 ("net/mlx5e: Handle errors from netif_set_real_num_{tx,rx}_queues") Signed-off-by: Aya Levin Reviewed-by: Maxim Mikityanskiy Signed-off-by: Saeed Mahameed Signed-off-by: Greg Kroah-Hartman commit 02a8da446b498f2fa4adf61209c1c666d825b7aa Author: Dima Chumak Date: Tue Apr 13 22:43:08 2021 +0300 net/mlx5e: Fix multipath lag activation commit 97817fcc684ed01497bd19d0cd4dea699665b9cf upstream. When handling FIB_EVENT_ENTRY_REPLACE event for a new multipath route, lag activation can be missed if a stale (struct lag_mp)->mfi pointer exists, which was associated with an older multipath route that had been removed. Normally, when a route is removed, it triggers mlx5_lag_fib_event(), which handles FIB_EVENT_ENTRY_DEL and clears mfi pointer. But, if mlx5_lag_check_prereq() condition isn't met, for example when eswitch is in legacy mode, the fib event is skipped and mfi pointer becomes stale. Fix by resetting mfi pointer to NULL every time mlx5_lag_mp_init() is called. Fixes: 544fe7c2e654 ("net/mlx5e: Activate HW multipath and handle port affinity based on FIB events") Signed-off-by: Dima Chumak Reviewed-by: Roi Dayan Signed-off-by: Saeed Mahameed Signed-off-by: Greg Kroah-Hartman commit fc41e45aa7e679b2e216f2f0b817a2d3be3a58a4 Author: Saeed Mahameed Date: Thu Feb 25 11:20:00 2021 -0800 net/mlx5e: reset XPS on error flow if netdev isn't registered yet commit 77ecd10d0a8aaa6e4871d8c63626e4c9fc5e47db upstream. mlx5e_attach_netdev can be called prior to registering the netdevice: Example stack: ipoib_new_child_link -> ipoib_intf_init-> rdma_init_netdev-> mlx5_rdma_setup_rn-> mlx5e_attach_netdev-> mlx5e_num_channels_changed -> mlx5e_set_default_xps_cpumasks -> netif_set_xps_queue -> __netif_set_xps_queue -> kmalloc If any later stage fails at any point after mlx5e_num_channels_changed() returns, XPS allocated maps will never be freed as they are only freed during netdev unregistration, which will never happen for yet to be registered netdevs. Fixes: 3909a12e7913 ("net/mlx5e: Fix configuration of XPS cpumasks and netdev queues in corner cases") Signed-off-by: Saeed Mahameed Signed-off-by: Aya Levin Reviewed-by: Tariq Toukan Signed-off-by: Greg Kroah-Hartman commit d66083c0d6f5125a4d982aa177dd71ab4cd3d212 Author: Neil Armstrong Date: Fri Apr 30 10:27:44 2021 +0200 drm/meson: fix shutdown crash when component not probed commit 7cfc4ea78fc103ea51ecbacd9236abb5b1c490d2 upstream. When main component is not probed, by example when the dw-hdmi module is not loaded yet or in probe defer, the following crash appears on shutdown: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000038 ... pc : meson_drv_shutdown+0x24/0x50 lr : platform_drv_shutdown+0x20/0x30 ... Call trace: meson_drv_shutdown+0x24/0x50 platform_drv_shutdown+0x20/0x30 device_shutdown+0x158/0x360 kernel_restart_prepare+0x38/0x48 kernel_restart+0x18/0x68 __do_sys_reboot+0x224/0x250 __arm64_sys_reboot+0x24/0x30 ... Simply check if the priv struct has been allocated before using it. Fixes: fa0c16caf3d7 ("drm: meson_drv add shutdown function") Reported-by: Stefan Agner Signed-off-by: Neil Armstrong Tested-by: Martin Blumenstingl Reviewed-by: Martin Blumenstingl Link: https://patchwork.freedesktop.org/patch/msgid/20210430082744.3638743-1-narmstrong@baylibre.com Signed-off-by: Greg Kroah-Hartman commit 92db1265f6cbd8b20c4407f478b5c6eea7fc4b61 Author: Zhang Xiaoxu Date: Tue May 25 23:32:35 2021 -0400 NFSv4: Fix v4.0/v4.1 SEEK_DATA return -ENOTSUPP when set NFS_V4_2 config commit e67afa7ee4a59584d7253e45d7f63b9528819a13 upstream. Since commit bdcc2cd14e4e ("NFSv4.2: handle NFS-specific llseek errors"), nfs42_proc_llseek would return -EOPNOTSUPP rather than -ENOTSUPP when SEEK_DATA on NFSv4.0/v4.1. This will lead xfstests generic/285 not run on NFSv4.0/v4.1 when set the CONFIG_NFS_V4_2, rather than run failed. Fixes: bdcc2cd14e4e ("NFSv4.2: handle NFS-specific llseek errors") Cc: # 4.2 Signed-off-by: Zhang Xiaoxu Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 7087db95c0a06ab201b8ebfac6a7ec1e34257997 Author: Trond Myklebust Date: Tue May 25 10:40:12 2021 -0400 NFS: Don't corrupt the value of pg_bytes_written in nfs_do_recoalesce() commit 0d0ea309357dea0d85a82815f02157eb7fcda39f upstream. The value of mirror->pg_bytes_written should only be updated after a successful attempt to flush out the requests on the list. Fixes: a7d42ddb3099 ("nfs: add mirroring support to pgio layer") Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit ee21cd3aa8548e0cbc8c67a80b62113aedd2d101 Author: Trond Myklebust Date: Tue May 25 10:23:05 2021 -0400 NFS: Fix an Oopsable condition in __nfs_pageio_add_request() commit 56517ab958b7c11030e626250c00b9b1a24b41eb upstream. Ensure that nfs_pageio_error_cleanup() resets the mirror array contents, so that the structure reflects the fact that it is now empty. Also change the test in nfs_pageio_do_add_request() to be more robust by checking whether or not the list is empty rather than relying on the value of pg_count. Fixes: a7d42ddb3099 ("nfs: add mirroring support to pgio layer") Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 9b367fe770b1b80d7bf64ed0d177544a44405f6e Author: Dan Carpenter Date: Tue May 11 11:49:42 2021 +0300 NFS: fix an incorrect limit in filelayout_decode_layout() commit 769b01ea68b6c49dc3cde6adf7e53927dacbd3a8 upstream. The "sizeof(struct nfs_fh)" is two bytes too large and could lead to memory corruption. It should be NFS_MAXFHSIZE because that's the size of the ->data[] buffer. I reversed the size of the arguments to put the variable on the left. Fixes: 16b374ca439f ("NFSv4.1: pnfs: filelayout: add driver's LAYOUTGET and GETDEVICEINFO infrastructure") Signed-off-by: Dan Carpenter Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 1fbbcd1752ff4fbfed3752a5d52e518625e660d7 Author: zhouchuangao Date: Sun May 9 19:34:37 2021 -0700 fs/nfs: Use fatal_signal_pending instead of signal_pending commit bb002388901151fe35b6697ab116f6ed0721a9ed upstream. We set the state of the current process to TASK_KILLABLE via prepare_to_wait(). Should we use fatal_signal_pending() to detect the signal here? Fixes: b4868b44c562 ("NFSv4: Wait for stateid updates after CLOSE/OPEN_DOWNGRADE") Signed-off-by: zhouchuangao Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 1b364f8ede200e79e25df0df588fcedc322518fb Author: Thadeu Lima de Souza Cascardo Date: Tue Apr 13 13:21:03 2021 -0300 Bluetooth: cmtp: fix file refcount when cmtp_attach_device fails commit 8da3a0b87f4f1c3a3bbc4bfb78cf68476e97d183 upstream. When cmtp_attach_device fails, cmtp_add_connection returns the error value which leads to the caller to doing fput through sockfd_put. But cmtp_session kthread, which is stopped in this path will also call fput, leading to a potential refcount underflow or a use-after-free. Add a refcount before we signal the kthread to stop. The kthread will try to grab the cmtp_session_sem mutex before doing the fput, which is held when get_file is called, so there should be no races there. Reported-by: Ryota Shiga Signed-off-by: Thadeu Lima de Souza Cascardo Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman commit 635ac38b36255d3cfb8312cf7c471334f4d537e0 Author: Pavel Skripkin Date: Mon May 24 23:02:08 2021 +0300 net: usb: fix memory leak in smsc75xx_bind commit 46a8b29c6306d8bbfd92b614ef65a47c900d8e70 upstream. Syzbot reported memory leak in smsc75xx_bind(). The problem was is non-freed memory in case of errors after memory allocation. backtrace: [] kmalloc include/linux/slab.h:556 [inline] [] kzalloc include/linux/slab.h:686 [inline] [] smsc75xx_bind+0x7a/0x334 drivers/net/usb/smsc75xx.c:1460 [] usbnet_probe+0x3b6/0xc30 drivers/net/usb/usbnet.c:1728 Fixes: d0cad871703b ("smsc75xx: SMSC LAN75xx USB gigabit ethernet adapter driver") Cc: stable@kernel.vger.org Reported-and-tested-by: syzbot+b558506ba8165425fee2@syzkaller.appspotmail.com Signed-off-by: Pavel Skripkin Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 77c6f2b36de1ae5742a1ad20cd5911849ed085f7 Author: Bjorn Andersson Date: Sat May 15 20:47:30 2021 -0700 usb: typec: mux: Fix matching with typec_altmode_desc commit acf5631c239dfc53489f739c4ad47f490c5181ff upstream. In typec_mux_match() "nval" is assigned the number of elements in the "svid" fwnode property, then the variable is used to store the success of the read and finally attempts to loop between 0 and "success" - i.e. not at all - and the code returns indicating that no match was found. Fix this by using a separate variable to track the success of the read, to allow the loop to get a change to find a match. Fixes: 96a6d031ca99 ("usb: typec: mux: Find the muxes by also matching against the device node") Reviewed-by: Heikki Krogerus Cc: stable Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20210516034730.621461-1-bjorn.andersson@linaro.org Signed-off-by: Greg Kroah-Hartman commit bd4caf585b80b244163ff3fcfd11920e2a559a4b Author: Yoshihiro Shimoda Date: Mon May 24 15:01:55 2021 +0900 usb: gadget: udc: renesas_usb3: Fix a race in usb3_start_pipen() commit e752dbc59e1241b13b8c4f7b6eb582862e7668fe upstream. The usb3_start_pipen() is called by renesas_usb3_ep_queue() and usb3_request_done_pipen() so that usb3_start_pipen() is possible to cause a race when getting usb3_first_req like below: renesas_usb3_ep_queue() spin_lock_irqsave() list_add_tail() spin_unlock_irqrestore() usb3_start_pipen() usb3_first_req = usb3_get_request() --- [1] --- interrupt --- usb3_irq_dma_int() usb3_request_done_pipen() usb3_get_request() usb3_start_pipen() usb3_first_req = usb3_get_request() ... (the req is possible to be finished in the interrupt) The usb3_first_req [1] above may have been finished after the interrupt ended so that this driver caused to start a transfer wrongly. To fix this issue, getting/checking the usb3_first_req are under spin_lock_irqsave() in the same section. Fixes: 746bfe63bba3 ("usb: gadget: renesas_usb3: add support for Renesas USB3.0 peripheral controller") Cc: stable Signed-off-by: Yoshihiro Shimoda Link: https://lore.kernel.org/r/20210524060155.1178724-1-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Greg Kroah-Hartman commit adccf17982628ed82eabd915799104ca4fcd4a76 Author: Thinh Nguyen Date: Wed May 12 20:17:09 2021 -0700 usb: dwc3: gadget: Properly track pending and queued SG commit 25dda9fc56bd90d45f9a4516bcfa5211e61b4290 upstream. The driver incorrectly uses req->num_pending_sgs to track both the number of pending and queued SG entries. It only prepares the next request if the previous is done, and it doesn't update num_pending_sgs until there is TRB completion interrupt. This may starve the controller of more TRBs until the num_pending_sgs is decremented. Fix this by decrementing the num_pending_sgs after they are queued and properly track both num_mapped_sgs and num_queued_sgs. Fixes: c96e6725db9d ("usb: dwc3: gadget: Correct the logic for queuing sgs") Cc: Reported-by: Michael Grzeschik Tested-by: Michael Grzeschik Acked-by: Felipe Balbi Signed-off-by: Thinh Nguyen Link: https://lore.kernel.org/r/ba24591dbcaad8f244a3e88bd449bb7205a5aec3.1620874069.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit a40b07afcb866abe3f6f63d531317523dcd1af00 Author: Srinivas Pandruvada Date: Fri Apr 30 05:23:43 2021 -0700 thermal/drivers/intel: Initialize RW trip to THERMAL_TEMP_INVALID commit eb8500b874cf295971a6a2a04e14eb0854197a3c upstream. After commit 81ad4276b505 ("Thermal: Ignore invalid trip points") all user_space governor notifications via RW trip point is broken in intel thermal drivers. This commits marks trip_points with value of 0 during call to thermal_zone_device_register() as invalid. RW trip points can be 0 as user space will set the correct trip temperature later. During driver init, x86_package_temp and all int340x drivers sets RW trip temperature as 0. This results in all these trips marked as invalid by the thermal core. To fix this initialize RW trips to THERMAL_TEMP_INVALID instead of 0. Cc: Signed-off-by: Srinivas Pandruvada Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20210430122343.1789899-1-srinivas.pandruvada@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit bfd46c08d6099647f719cd2e40a27bbc851e6374 Author: Zolton Jheng Date: Mon May 10 10:32:00 2021 +0800 USB: serial: pl2303: add device id for ADLINK ND-6530 GC commit f8e8c1b2f782e7391e8a1c25648ce756e2a7d481 upstream. This adds the device id for the ADLINK ND-6530 which is a PL2303GC based device. Signed-off-by: Zolton Jheng Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 794794459c52238cc60db7e6e52d486670de0221 Author: Dominik Andreas Schorpp Date: Thu Apr 22 09:58:52 2021 +0200 USB: serial: ftdi_sio: add IDs for IDS GmbH Products commit c5a80540e425a5f9a82b0f3163e3b6a4331f33bc upstream. Add the IDS GmbH Vendor ID and the Product IDs for SI31A (2xRS232) and CM31A (LoRaWAN Modem). Signed-off-by: Dominik Andreas Schorpp Signed-off-by: Juergen Borleis Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit f9a5cbdf86efafa3fd4d09176ec5648763146c39 Author: Daniele Palmas Date: Wed Apr 28 09:26:34 2021 +0200 USB: serial: option: add Telit LE910-S1 compositions 0x7010, 0x7011 commit e467714f822b5d167a7fb03d34af91b5b6af1827 upstream. Add support for the following Telit LE910-S1 compositions: 0x7010: rndis, tty, tty, tty 0x7011: ecm, tty, tty, tty Signed-off-by: Daniele Palmas Link: https://lore.kernel.org/r/20210428072634.5091-1-dnlplm@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 682437d58e8b278dc56f4236f05134e340956659 Author: Sean MacLennan Date: Sat May 1 20:40:45 2021 -0400 USB: serial: ti_usb_3410_5052: add startech.com device id commit 89b1a3d811e6f8065d6ae8a25e7682329b4a31e2 upstream. This adds support for the Startech.com generic serial to USB converter. It seems to be a bone stock TI_3410. I have been using this patch for years. Signed-off-by: Sean MacLennan Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 6a931ceb0b9401fe18d0c500e08164bf9cc7be4b Author: Zheyu Ma Date: Fri May 21 06:08:43 2021 +0000 serial: rp2: use 'request_firmware' instead of 'request_firmware_nowait' commit 016002848c82eeb5d460489ce392d91fe18c475c upstream. In 'rp2_probe', the driver registers 'rp2_uart_interrupt' then calls 'rp2_fw_cb' through 'request_firmware_nowait'. In 'rp2_fw_cb', if the firmware don't exists, function just return without initializing ports of 'rp2_card'. But now the interrupt handler function has been registered, and when an interrupt comes, 'rp2_uart_interrupt' may access those ports then causing NULL pointer dereference or other bugs. Because the driver does some initialization work in 'rp2_fw_cb', in order to make the driver ready to handle interrupts, 'request_firmware' should be used instead of asynchronous 'request_firmware_nowait'. This report reveals it: INFO: trying to register non-static key. the code is fine but needs lockdep annotation. turning off the locking correctness validator. CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.19.177-gdba4159c14ef-dirty #45 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59- gc9ba5276e321-prebuilt.qemu.org 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xec/0x156 lib/dump_stack.c:118 assign_lock_key kernel/locking/lockdep.c:727 [inline] register_lock_class+0x14e5/0x1ba0 kernel/locking/lockdep.c:753 __lock_acquire+0x187/0x3750 kernel/locking/lockdep.c:3303 lock_acquire+0x124/0x340 kernel/locking/lockdep.c:3907 __raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline] _raw_spin_lock+0x32/0x50 kernel/locking/spinlock.c:144 spin_lock include/linux/spinlock.h:329 [inline] rp2_ch_interrupt drivers/tty/serial/rp2.c:466 [inline] rp2_asic_interrupt.isra.9+0x15d/0x990 drivers/tty/serial/rp2.c:493 rp2_uart_interrupt+0x49/0xe0 drivers/tty/serial/rp2.c:504 __handle_irq_event_percpu+0xfb/0x770 kernel/irq/handle.c:149 handle_irq_event_percpu+0x79/0x150 kernel/irq/handle.c:189 handle_irq_event+0xac/0x140 kernel/irq/handle.c:206 handle_fasteoi_irq+0x232/0x5c0 kernel/irq/chip.c:725 generic_handle_irq_desc include/linux/irqdesc.h:155 [inline] handle_irq+0x230/0x3a0 arch/x86/kernel/irq_64.c:87 do_IRQ+0xa7/0x1e0 arch/x86/kernel/irq.c:247 common_interrupt+0xf/0xf arch/x86/entry/entry_64.S:670 RIP: 0010:native_safe_halt+0x28/0x30 arch/x86/include/asm/irqflags.h:61 Code: 00 00 55 be 04 00 00 00 48 c7 c7 00 c2 2f 8c 48 89 e5 e8 fb 31 e7 f8 8b 05 75 af 8d 03 85 c0 7e 07 0f 00 2d 8a 61 65 00 fb f4 <5d> c3 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 RSP: 0018:ffff88806b71fcc8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffffde RAX: 0000000000000000 RBX: ffffffff8bde7e48 RCX: ffffffff88a21285 RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffffffff8c2fc200 RBP: ffff88806b71fcc8 R08: fffffbfff185f840 R09: fffffbfff185f840 R10: 0000000000000001 R11: fffffbfff185f840 R12: 0000000000000002 R13: ffffffff8bea18a0 R14: 0000000000000000 R15: 0000000000000000 arch_safe_halt arch/x86/include/asm/paravirt.h:94 [inline] default_idle+0x6f/0x360 arch/x86/kernel/process.c:557 arch_cpu_idle+0xf/0x20 arch/x86/kernel/process.c:548 default_idle_call+0x3b/0x60 kernel/sched/idle.c:93 cpuidle_idle_call kernel/sched/idle.c:153 [inline] do_idle+0x2ab/0x3c0 kernel/sched/idle.c:263 cpu_startup_entry+0xcb/0xe0 kernel/sched/idle.c:369 start_secondary+0x3b8/0x4e0 arch/x86/kernel/smpboot.c:271 secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:243 BUG: unable to handle kernel NULL pointer dereference at 0000000000000010 PGD 8000000056d27067 P4D 8000000056d27067 PUD 56d28067 PMD 0 Oops: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.19.177-gdba4159c14ef-dirty #45 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59- gc9ba5276e321-prebuilt.qemu.org 04/01/2014 RIP: 0010:readl arch/x86/include/asm/io.h:59 [inline] RIP: 0010:rp2_ch_interrupt drivers/tty/serial/rp2.c:472 [inline] RIP: 0010:rp2_asic_interrupt.isra.9+0x181/0x990 drivers/tty/serial/rp2.c: 493 Code: df e8 43 5d c2 05 48 8d 83 e8 01 00 00 48 89 85 60 ff ff ff 48 c1 e8 03 42 80 3c 30 00 0f 85 aa 07 00 00 48 8b 83 e8 01 00 00 <8b> 40 10 89 c1 89 85 68 ff ff ff 48 8b 83 e8 01 00 00 89 48 10 83 RSP: 0018:ffff88806c287cd0 EFLAGS: 00010046 RAX: 0000000000000000 RBX: ffff88806ade6820 RCX: ffffffff814300b1 RDX: 1ffff1100d5bcd06 RSI: 0000000000000004 RDI: ffff88806ade6820 RBP: ffff88806c287db8 R08: ffffed100d5bcd05 R09: ffffed100d5bcd05 R10: 0000000000000001 R11: ffffed100d5bcd04 R12: ffffc90001e00000 R13: ffff888069654e10 R14: dffffc0000000000 R15: ffff888069654df0 FS: 0000000000000000(0000) GS:ffff88806c280000(0000) knlGS: 0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000010 CR3: 000000006892c000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: rp2_uart_interrupt+0x49/0xe0 drivers/tty/serial/rp2.c:504 __handle_irq_event_percpu+0xfb/0x770 kernel/irq/handle.c:149 handle_irq_event_percpu+0x79/0x150 kernel/irq/handle.c:189 handle_irq_event+0xac/0x140 kernel/irq/handle.c:206 handle_fasteoi_irq+0x232/0x5c0 kernel/irq/chip.c:725 generic_handle_irq_desc include/linux/irqdesc.h:155 [inline] handle_irq+0x230/0x3a0 arch/x86/kernel/irq_64.c:87 do_IRQ+0xa7/0x1e0 arch/x86/kernel/irq.c:247 common_interrupt+0xf/0xf arch/x86/entry/entry_64.S:670 RIP: 0010:native_safe_halt+0x28/0x30 arch/x86/include/asm/irqflags.h:61 Code: 00 00 55 be 04 00 00 00 48 c7 c7 00 c2 2f 8c 48 89 e5 e8 fb 31 e7 f8 8b 05 75 af 8d 03 85 c0 7e 07 0f 00 2d 8a 61 65 00 fb f4 <5d> c3 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 RSP: 0018:ffff88806b71fcc8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffffde RAX: 0000000000000000 RBX: ffffffff8bde7e48 RCX: ffffffff88a21285 RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffffffff8c2fc200 RBP: ffff88806b71fcc8 R08: fffffbfff185f840 R09: fffffbfff185f840 R10: 0000000000000001 R11: fffffbfff185f840 R12: 0000000000000002 R13: ffffffff8bea18a0 R14: 0000000000000000 R15: 0000000000000000 arch_safe_halt arch/x86/include/asm/paravirt.h:94 [inline] default_idle+0x6f/0x360 arch/x86/kernel/process.c:557 arch_cpu_idle+0xf/0x20 arch/x86/kernel/process.c:548 default_idle_call+0x3b/0x60 kernel/sched/idle.c:93 cpuidle_idle_call kernel/sched/idle.c:153 [inline] do_idle+0x2ab/0x3c0 kernel/sched/idle.c:263 cpu_startup_entry+0xcb/0xe0 kernel/sched/idle.c:369 start_secondary+0x3b8/0x4e0 arch/x86/kernel/smpboot.c:271 secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:243 Modules linked in: Dumping ftrace buffer: (ftrace buffer empty) CR2: 0000000000000010 ---[ end trace 11804dbb55cb1a64 ]--- RIP: 0010:readl arch/x86/include/asm/io.h:59 [inline] RIP: 0010:rp2_ch_interrupt drivers/tty/serial/rp2.c:472 [inline] RIP: 0010:rp2_asic_interrupt.isra.9+0x181/0x990 drivers/tty/serial/rp2.c: 493 Code: df e8 43 5d c2 05 48 8d 83 e8 01 00 00 48 89 85 60 ff ff ff 48 c1 e8 03 42 80 3c 30 00 0f 85 aa 07 00 00 48 8b 83 e8 01 00 00 <8b> 40 10 89 c1 89 85 68 ff ff ff 48 8b 83 e8 01 00 00 89 48 10 83 RSP: 0018:ffff88806c287cd0 EFLAGS: 00010046 RAX: 0000000000000000 RBX: ffff88806ade6820 RCX: ffffffff814300b1 RDX: 1ffff1100d5bcd06 RSI: 0000000000000004 RDI: ffff88806ade6820 RBP: ffff88806c287db8 R08: ffffed100d5bcd05 R09: ffffed100d5bcd05 R10: 0000000000000001 R11: ffffed100d5bcd04 R12: ffffc90001e00000 R13: ffff888069654e10 R14: dffffc0000000000 R15: ffff888069654df0 FS: 0000000000000000(0000) GS:ffff88806c280000(0000) knlGS: 0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000010 CR3: 000000006892c000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Reported-by: Zheyu Ma Signed-off-by: Zheyu Ma Link: https://lore.kernel.org/r/1621577323-1541-1-git-send-email-zheyuma97@gmail.com Cc: stable Signed-off-by: Greg Kroah-Hartman commit e95571170159f0dcfc227a4c0875b30a7e38f097 Author: Geert Uytterhoeven Date: Mon May 10 14:07:55 2021 +0200 serial: sh-sci: Fix off-by-one error in FIFO threshold register setting commit 2ea2e019c190ee3973ef7bcaf829d8762e56e635 upstream. The Receive FIFO Data Count Trigger field (RTRG[6:0]) in the Receive FIFO Data Count Trigger Register (HSRTRGR) of HSCIF can only hold values ranging from 0-127. As the FIFO size is equal to 128 on HSCIF, the user can write an out-of-range value, touching reserved bits. Fix this by limiting the trigger value to the FIFO size minus one. Reverse the order of the checks, to avoid rx_trig becoming zero if the FIFO size is one. Note that this change has no impact on other SCIF variants, as their maximum supported trigger value is lower than the FIFO size anyway, and the code below takes care of enforcing these limits. Fixes: a380ed461f66d1b8 ("serial: sh-sci: implement FIFO threshold register setting") Reported-by: Linh Phung Reviewed-by: Wolfram Sang Reviewed-by: Ulrich Hecht Signed-off-by: Geert Uytterhoeven Cc: stable Link: https://lore.kernel.org/r/5eff320aef92ffb33d00e57979fd3603bbb4a70f.1620648218.git.geert+renesas@glider.be Signed-off-by: Greg Kroah-Hartman commit 604c654323fa45d3f78502beb054d97a65c28349 Author: Colin Ian King Date: Mon Apr 26 11:55:14 2021 +0100 serial: tegra: Fix a mask operation that is always true commit 3ddb4ce1e6e3bd112778ab93bbd9092f23a878ec upstream. Currently the expression lsr | UART_LSR_TEMT is always true and this seems suspect. I believe the intent was to mask lsr with UART_LSR_TEMT to check that bit, so the expression should be using the & operator instead. Fix this. Fixes: b9c2470fb150 ("serial: tegra: flush the RX fifo on frame error") Signed-off-by: Colin Ian King Cc: stable Link: https://lore.kernel.org/r/20210426105514.23268-1-colin.king@canonical.com Signed-off-by: Greg Kroah-Hartman commit d007150b4e15bfcb8d36cfd88a5645d42e44d383 Author: Rafael J. Wysocki Date: Fri May 14 14:10:15 2021 +0200 drivers: base: Fix device link removal commit 80dd33cf72d1ab4f0af303f1fa242c6d6c8d328f upstream. When device_link_free() drops references to the supplier and consumer devices of the device link going away and the reference being dropped turns out to be the last one for any of those device objects, its ->release callback will be invoked and it may sleep which goes against the SRCU callback execution requirements. To address this issue, make the device link removal code carry out the device_link_free() actions preceded by SRCU synchronization from a separate work item (the "long" workqueue is used for that, because it does not matter when the device link memory is released and it may take time to get to that point) instead of using SRCU callbacks. While at it, make the code work analogously when SRCU is not enabled to reduce the differences between the SRCU and non-SRCU cases. Fixes: 843e600b8a2b ("driver core: Fix sleeping in invalid context during device link deletion") Cc: stable Reported-by: chenxiang (M) Tested-by: chenxiang (M) Reviewed-by: Saravana Kannan Signed-off-by: Rafael J. Wysocki Link: https://lore.kernel.org/r/5722787.lOV4Wx5bFT@kreacher Signed-off-by: Greg Kroah-Hartman commit 8d83f109e920d2776991fa142bb904d985dca2ed Author: Alan Stern Date: Tue May 18 16:18:35 2021 -0400 USB: usbfs: Don't WARN about excessively large memory allocations commit 4f2629ea67e7225c3fd292c7fe4f5b3c9d6392de upstream. Syzbot found that the kernel generates a WARNing if the user tries to submit a bulk transfer through usbfs with a buffer that is way too large. This isn't a bug in the kernel; it's merely an invalid request from the user and the usbfs code does handle it correctly. In theory the same thing can happen with async transfers, or with the packet descriptor table for isochronous transfers. To prevent the MM subsystem from complaining about these bad allocation requests, add the __GFP_NOWARN flag to the kmalloc calls for these buffers. CC: Andrew Morton CC: Reported-and-tested-by: syzbot+882a85c0c8ec4a3e2281@syzkaller.appspotmail.com Signed-off-by: Alan Stern Link: https://lore.kernel.org/r/20210518201835.GA1140918@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman commit bc439b4b6a6beb723f1258659a9ca1a48ae4972c Author: Zhu Lingshan Date: Sat May 8 15:11:52 2021 +0800 Revert "irqbypass: do not start cons/prod when failed connect" commit e44b49f623c77bee7451f1a82ccfb969c1028ae2 upstream. This reverts commit a979a6aa009f3c99689432e0cdb5402a4463fb88. The reverted commit may cause VM freeze on arm64 with GICv4, where stopping a consumer is implemented by suspending the VM. Should the connect fail, the VM will not be resumed, which is a bit of a problem. It also erroneously calls the producer destructor unconditionally, which is unexpected. Reported-by: Shaokun Zhang Suggested-by: Marc Zyngier Acked-by: Jason Wang Acked-by: Michael S. Tsirkin Reviewed-by: Eric Auger Tested-by: Shaokun Zhang Signed-off-by: Zhu Lingshan [maz: tags and cc-stable, commit message update] Signed-off-by: Marc Zyngier Fixes: a979a6aa009f ("irqbypass: do not start cons/prod when failed connect") Link: https://lore.kernel.org/r/3a2c66d6-6ca0-8478-d24b-61e8e3241b20@hisilicon.com Link: https://lore.kernel.org/r/20210508071152.722425-1-lingshan.zhu@intel.com Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit b98a0380bc814fce20209e2906617d65a891e354 Author: Johan Hovold Date: Fri May 21 15:31:09 2021 +0200 USB: trancevibrator: fix control-request direction commit 746e4acf87bcacf1406e05ef24a0b7139147c63e upstream. The direction of the pipe argument must match the request-type direction bit or control requests may fail depending on the host-controller-driver implementation. Fix the set-speed request which erroneously used USB_DIR_IN and update the default timeout argument to match (same value). Fixes: 5638e4d92e77 ("USB: add PlayStation 2 Trance Vibrator driver") Cc: stable@vger.kernel.org # 2.6.19 Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20210521133109.17396-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit ae46660bf29f7695e5c20e603630e8765d0328c2 Author: Christian Gmeiner Date: Thu May 27 11:54:40 2021 +0200 serial: 8250_pci: handle FL_NOIRQ board flag commit 9808f9be31c68af43f6e531f2c851ebb066513fe upstream. In commit 8428413b1d14 ("serial: 8250_pci: Implement MSI(-X) support") the way the irq gets allocated was changed. With that change the handling FL_NOIRQ got lost. Restore the old behaviour. Fixes: 8428413b1d14 ("serial: 8250_pci: Implement MSI(-X) support") Cc: Signed-off-by: Christian Gmeiner Link: https://lore.kernel.org/r/20210527095529.26281-1-christian.gmeiner@gmail.com Signed-off-by: Greg Kroah-Hartman commit 60f9e33bb716163666305a192c6b32b4cb81eaa4 Author: Randy Wright Date: Fri May 14 10:26:54 2021 -0600 serial: 8250_pci: Add support for new HPE serial device commit e0e24208792080135248f23fdf6d51aa2e04df05 upstream. Add support for new HPE serial device. It is MSI enabled, but otherwise similar to legacy HP server serial devices. Tested-by: Jerry Hoemann Signed-off-by: Randy Wright Cc: stable Link: https://lore.kernel.org/r/1621009614-28836-1-git-send-email-rwright@hpe.com Signed-off-by: Greg Kroah-Hartman commit a4a261328ce14cec36460a185bd2064791e3a323 Author: Maximilian Luz Date: Wed May 12 23:04:13 2021 +0200 serial: 8250_dw: Add device HID for new AMD UART controller commit 3c35d2a960c0077a4cb09bf4989f45d289332ea0 upstream. Add device HID AMDI0022 to the AMD UART controller driver match table and create a platform device for it. This controller can be found on Microsoft Surface Laptop 4 devices and seems similar enough that we can just copy the existing AMDI0020 entries. Cc: # 5.10+ Tested-by: Sachi King Acked-by: Andy Shevchenko # for 8250_dw part Signed-off-by: Maximilian Luz Link: https://lore.kernel.org/r/20210512210413.1982933-1-luzmaximilian@gmail.com Signed-off-by: Greg Kroah-Hartman commit 595505fc6f8b0f85d58f7a97a9ad6a139af8397e Author: Andrew Jeffery Date: Thu May 20 11:43:33 2021 +0930 serial: 8250: Add UART_BUG_TXRACE workaround for Aspeed VUART commit df8f2be2fd0b44b2cb6077068f52e05f0ac40897 upstream. Aspeed Virtual UARTs directly bridge e.g. the system console UART on the LPC bus to the UART interface on the BMC's internal APB. As such there's no RS-232 signalling involved - the UART interfaces on each bus are directly connected as the producers and consumers of the one set of FIFOs. The APB in the AST2600 generally runs at 100MHz while the LPC bus peaks at 33MHz. The difference in clock speeds exposes a race in the VUART design where a Tx data burst on the APB interface can result in a byte lost on the LPC interface. The symptom is LSR[DR] remains clear on the LPC interface despite data being present in its Rx FIFO, while LSR[THRE] remains clear on the APB interface as the host has not consumed the data the BMC has transmitted. In this state, the UART has stalled and no further data can be transmitted without manual intervention (e.g. resetting the FIFOs, resulting in loss of data). The recommended work-around is to insert a read cycle on the APB interface between writes to THR. Cc: ChiaWei Wang Tested-by: ChiaWei Wang Reviewed-by: Jiri Slaby Signed-off-by: Andrew Jeffery Cc: stable Link: https://lore.kernel.org/r/20210520021334.497341-2-andrew@aj.id.au Signed-off-by: Greg Kroah-Hartman commit 023cd911d4c2252b4cb851f4c3f43203093bc5da Author: Alexandru Ardelean Date: Thu May 13 15:07:44 2021 +0300 iio: adc: ad7192: handle regulator voltage error first commit b0f27fca5a6c7652e265aae6a4452ce2f2ed64da upstream. This change fixes a corner-case, where for a zero regulator value, the driver would exit early, initializing the driver only partially. The driver would be in an unknown state. This change reworks the code to check regulator_voltage() return value for negative (error) first, and return early. This is the more common idiom. Also, this change is removing the 'voltage_uv' variable and using the 'ret' value directly. The only place where 'voltage_uv' is being used is to compute the internal reference voltage, and the type of this variable is 'int' (same are for 'ret'). Using only 'ret' avoids having to assign it on the error path. Fixes: ab0afa65bbc7 ("staging: iio: adc: ad7192: fail probe on get_voltage") Cc: Alexandru Tachici Signed-off-by: Alexandru Ardelean Signed-off-by: Jonathan Cameron Cc: Signed-off-by: Greg Kroah-Hartman commit 885fbd6d360c690e07714f68dbb0544bb446c956 Author: Jonathan Cameron Date: Thu May 13 15:07:43 2021 +0300 iio: adc: ad7192: Avoid disabling a clock that was never enabled. commit e32fe6d90f44922ccbb94016cfc3c238359e3e39 upstream. Found by inspection. If the internal clock source is being used, the driver doesn't call clk_prepare_enable() and as such we should not call clk_disable_unprepare() Use the same condition to protect the disable path as is used on the enable one. Note this will all get simplified when the driver moves over to a full devm_ flow, but that would make backporting the fix harder. Fix obviously predates move out of staging, but backporting will become more complex (and is unlikely to happen), hence that patch is given in the fixes tag. Alexandru's sign off is here because he added this patch into a larger series that Jonathan then applied. Fixes: b581f748cce0 ("staging: iio: adc: ad7192: move out of staging") Cc: Alexandru Tachici Reviewed-by: Alexandru Ardelean Signed-off-by: Jonathan Cameron Signed-off-by: Alexandru Ardelean Cc: Signed-off-by: Greg Kroah-Hartman commit e07d42897009160742f958ba2ffce54bbe6d7e4b Author: YueHaibing Date: Fri May 14 16:02:54 2021 +0800 iio: adc: ad7793: Add missing error code in ad7793_setup() commit 4ed243b1da169bcbc1ec5507867e56250c5f1ff9 upstream. Set error code while device ID query failed. Fixes: 88bc30548aae ("IIO: ADC: New driver for AD7792/AD7793 3 Channel SPI ADC") Signed-off-by: YueHaibing Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit bd298334bffedfc4b9b296fd59bce5ecac1ebb97 Author: Jonathan Cameron Date: Sat May 1 17:53:14 2021 +0100 iio: adc: ad7923: Fix undersized rx buffer. commit 01fcf129f61b26d5b3d2d8afb03e770dee271bc8 upstream. Fixes tag is where the max channels became 8, but timestamp space was missing before that. Fixes: 851644a60d20 ("iio: adc: ad7923: Add support for the ad7908/ad7918/ad7928") Signed-off-by: Jonathan Cameron Cc: Daniel Junho Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210501165314.511954-3-jic23@kernel.org Cc: Signed-off-by: Greg Kroah-Hartman commit f70122825076117787b91e7f219e21c09f11a5b9 Author: Jonathan Cameron Date: Thu May 13 15:07:42 2021 +0300 iio: adc: ad7124: Fix potential overflow due to non sequential channel numbers commit f2a772c51206b0c3f262e4f6a3812c89a650191b upstream. Channel numbering must start at 0 and then not have any holes, or it is possible to overflow the available storage. Note this bug was introduced as part of a fix to ensure we didn't rely on the ordering of child nodes. So we need to support arbitrary ordering but they all need to be there somewhere. Note I hit this when using qemu to test the rest of this series. Arguably this isn't the best fix, but it is probably the most minimal option for backporting etc. Alexandru's sign-off is here because he carried this patch in a larger set that Jonathan then applied. Fixes: d7857e4ee1ba6 ("iio: adc: ad7124: Fix DT channel configuration") Reviewed-by: Alexandru Ardelean Signed-off-by: Jonathan Cameron Signed-off-by: Alexandru Ardelean Cc: Signed-off-by: Greg Kroah-Hartman commit fbb02b5e7a34fcc0b40698f0b4535b93251c48aa Author: Jonathan Cameron Date: Thu May 13 15:07:41 2021 +0300 iio: adc: ad7124: Fix missbalanced regulator enable / disable on error. commit 4573472315f0fa461330545ff2aa2f6da0b1ae76 upstream. If the devm_regulator_get() call succeeded but not the regulator_enable() then regulator_disable() would be called on a regulator that was not enabled. Fix this by moving regulator enabling / disabling over to devm_ management via devm_add_action_or_reset. Alexandru's sign-off here because he pulled Jonathan's patch into a larger set which Jonathan then applied. Fixes: b3af341bbd96 ("iio: adc: Add ad7124 support") Reviewed-by: Alexandru Ardelean Signed-off-by: Jonathan Cameron Signed-off-by: Alexandru Ardelean Cc: Signed-off-by: Greg Kroah-Hartman commit dceb4ec04222505be7a83be413f68fff9273695d Author: Jonathan Cameron Date: Sat May 1 17:53:13 2021 +0100 iio: adc: ad7768-1: Fix too small buffer passed to iio_push_to_buffers_with_timestamp() commit a1caeebab07e9d72eec534489f47964782b93ba9 upstream. Add space for the timestamp to be inserted. Also ensure correct alignment for passing to iio_push_to_buffers_with_timestamp() Fixes: a5f8c7da3dbe ("iio: adc: Add AD7768-1 ADC basic support") Signed-off-by: Jonathan Cameron Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210501165314.511954-2-jic23@kernel.org Cc: Signed-off-by: Greg Kroah-Hartman commit a78238fa3bee447b4e9c7c767d22c62501484d36 Author: Andy Shevchenko Date: Mon May 10 12:56:49 2021 +0300 iio: dac: ad5770r: Put fwnode in error case during ->probe() commit 98b7b0ca0828907dbb706387c11356a45463e2ea upstream. device_for_each_child_node() bumps a reference counting of a returned variable. We have to balance it whenever we return to the caller. Fixes: cbbb819837f6 ("iio: dac: ad5770r: Add AD5770R support") Cc: Alexandru Tachici Signed-off-by: Andy Shevchenko Reviewed-by: Alexandru Ardelean Link: https://lore.kernel.org/r/20210510095649.3302835-1-andy.shevchenko@gmail.com Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 619289733df016526738a3d2d646b7afd31cd975 Author: Rui Miguel Silva Date: Wed May 12 23:39:29 2021 +0100 iio: gyro: fxas21002c: balance runtime power in error path commit 2a54c8c9ebc2006bf72554afc84ffc67768979a0 upstream. If we fail to read temperature or axis we need to decrement the runtime pm reference count to trigger autosuspend. Add the call to pm_put to do that in case of error. Fixes: a0701b6263ae ("iio: gyro: add core driver for fxas21002c") Suggested-by: Mauro Carvalho Chehab Signed-off-by: Rui Miguel Silva Link: https://lore.kernel.org/linux-iio/CBBZA9T1OY9C.2611WSV49DV2G@arch-thunder/ Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 0239a3746332802073c618b20f4270d42defe462 Author: Lucas Stankus Date: Tue May 11 17:54:18 2021 -0300 staging: iio: cdc: ad7746: avoid overwrite of num_channels commit 04f5b9f539ce314f758d919a14dc7a669f3b7838 upstream. AD7745 devices don't have the CIN2 pins and therefore can't handle related channels. Forcing the number of AD7746 channels may lead to enabling more channels than what the hardware actually supports. Avoid num_channels being overwritten after first assignment. Signed-off-by: Lucas Stankus Fixes: 83e416f458d53 ("staging: iio: adc: Replace, rewrite ad7745 from scratch.") Signed-off-by: Jonathan Cameron Cc: Signed-off-by: Greg Kroah-Hartman commit ead51afc7f0d01747f77e2f0ae934de69425bcc7 Author: Alexander Usyskin Date: Wed May 26 22:33:34 2021 +0300 mei: request autosuspend after sending rx flow control commit bbf0a94744edfeee298e4a9ab6fd694d639a5cdf upstream. A rx flow control waiting in the control queue may block autosuspend. Re-request autosuspend after flow control been sent to unblock the transition to the low power state. Cc: Signed-off-by: Alexander Usyskin Signed-off-by: Tomas Winkler Link: https://lore.kernel.org/r/20210526193334.445759-1-tomas.winkler@intel.com Signed-off-by: Greg Kroah-Hartman commit 31283877e3cd4a48d75cffdafe05746f2cb28b15 Author: Marc Zyngier Date: Mon May 24 18:07:52 2021 +0100 KVM: arm64: Prevent mixed-width VM creation commit 66e94d5cafd4decd4f92d16a022ea587d7f4094f upstream. It looks like we have tolerated creating mixed-width VMs since... forever. However, that was never the intention, and we'd rather not have to support that pointless complexity. Forbid such a setup by making sure all the vcpus have the same register width. Reported-by: Steven Price Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org Acked-by: Mark Rutland Link: https://lore.kernel.org/r/20210524170752.1549797-1-maz@kernel.org Signed-off-by: Greg Kroah-Hartman commit bb2e3adf237cca502e9179f3118f000504fe6fb3 Author: Wanpeng Li Date: Tue May 18 05:00:33 2021 -0700 KVM: X86: Fix vCPU preempted state from guest's point of view commit 1eff0ada88b48e4ac1e3fe26483b3684fedecd27 upstream. Commit 66570e966dd9 (kvm: x86: only provide PV features if enabled in guest's CPUID) avoids to access pv tlb shootdown host side logic when this pv feature is not exposed to guest, however, kvm_steal_time.preempted not only leveraged by pv tlb shootdown logic but also mitigate the lock holder preemption issue. From guest's point of view, vCPU is always preempted since we lose the reset of kvm_steal_time.preempted before vmentry if pv tlb shootdown feature is not exposed. This patch fixes it by clearing kvm_steal_time.preempted before vmentry. Fixes: 66570e966dd9 (kvm: x86: only provide PV features if enabled in guest's CPUID) Reviewed-by: Sean Christopherson Cc: stable@vger.kernel.org Signed-off-by: Wanpeng Li Message-Id: <1621339235-11131-3-git-send-email-wanpengli@tencent.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 439a0b07fdef816ba141343b7191099c661f2363 Author: Mathias Nyman Date: Tue Apr 27 15:48:29 2021 +0300 thunderbolt: dma_port: Fix NVM read buffer bounds and offset issue commit b106776080a1cf953a1b2fd50cb2a995db4732be upstream. Up to 64 bytes of data can be read from NVM in one go. Read address must be dword aligned. Data is read into a local buffer. If caller asks to read data starting at an unaligned address then full dword is anyway read from NVM into a local buffer. Data is then copied from the local buffer starting at the unaligned offset to the caller buffer. In cases where asked data length + unaligned offset is over 64 bytes we need to make sure we don't read past the 64 bytes in the local buffer when copying to caller buffer, and make sure that we don't skip copying unaligned offset bytes from local buffer anymore after the first round of 64 byte NVM data read. Fixes: 3e13676862f9 ("thunderbolt: Add support for DMA configuration based mailbox") Cc: stable@vger.kernel.org Signed-off-by: Mathias Nyman Signed-off-by: Mika Westerberg Signed-off-by: Greg Kroah-Hartman commit 1b4a65408ec58c6cd972eca643ffad90bcb1880d Author: Mathias Nyman Date: Thu Mar 25 10:32:50 2021 +0200 thunderbolt: usb4: Fix NVM read buffer bounds and offset issue commit 22c7a18ed5f007faccb7527bc890463763214081 upstream. Up to 64 bytes of data can be read from NVM in one go. Read address must be dword aligned. Data is read into a local buffer. If caller asks to read data starting at an unaligned address then full dword is anyway read from NVM into a local buffer. Data is then copied from the local buffer starting at the unaligned offset to the caller buffer. In cases where asked data length + unaligned offset is over 64 bytes we need to make sure we don't read past the 64 bytes in the local buffer when copying to caller buffer, and make sure that we don't skip copying unaligned offset bytes from local buffer anymore after the first round of 64 byte NVM data read. Fixes: b04079837b20 ("thunderbolt: Add initial support for USB4") Cc: stable@vger.kernel.org Signed-off-by: Mathias Nyman Signed-off-by: Mika Westerberg Signed-off-by: Greg Kroah-Hartman commit 5394ae9d8c7961dd93807fdf1b12a1dde96b0a55 Author: Dongliang Mu Date: Fri May 14 20:43:48 2021 +0800 misc/uss720: fix memory leak in uss720_probe commit dcb4b8ad6a448532d8b681b5d1a7036210b622de upstream. uss720_probe forgets to decrease the refcount of usbdev in uss720_probe. Fix this by decreasing the refcount of usbdev by usb_put_dev. BUG: memory leak unreferenced object 0xffff888101113800 (size 2048): comm "kworker/0:1", pid 7, jiffies 4294956777 (age 28.870s) hex dump (first 32 bytes): ff ff ff ff 31 00 00 00 00 00 00 00 00 00 00 00 ....1........... 00 00 00 00 00 00 00 00 00 00 00 00 03 00 00 00 ................ backtrace: [] kmalloc include/linux/slab.h:554 [inline] [] kzalloc include/linux/slab.h:684 [inline] [] usb_alloc_dev+0x32/0x450 drivers/usb/core/usb.c:582 [] hub_port_connect drivers/usb/core/hub.c:5129 [inline] [] hub_port_connect_change drivers/usb/core/hub.c:5363 [inline] [] port_event drivers/usb/core/hub.c:5509 [inline] [] hub_event+0x1171/0x20c0 drivers/usb/core/hub.c:5591 [] process_one_work+0x2c9/0x600 kernel/workqueue.c:2275 [] worker_thread+0x59/0x5d0 kernel/workqueue.c:2421 [] kthread+0x178/0x1b0 kernel/kthread.c:292 [] ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294 Fixes: 0f36163d3abe ("[PATCH] usb: fix uss720 schedule with interrupts off") Cc: stable Reported-by: syzbot+636c58f40a86b4a879e7@syzkaller.appspotmail.com Signed-off-by: Dongliang Mu Link: https://lore.kernel.org/r/20210514124348.6587-1-mudongliangabcd@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 1a2494c9eb021a735bb136a537b6d6a7c370cc77 Author: Ondrej Mosnacek Date: Fri May 7 13:57:19 2021 +0200 serial: core: fix suspicious security_locked_down() call commit 5e722b217ad3cf41f5504db80a68062df82b5242 upstream. The commit that added this check did so in a very strange way - first security_locked_down() is called, its value stored into retval, and if it's nonzero, then an additional check is made for (change_irq || change_port), and if this is true, the function returns. However, if the goto exit branch is not taken, the code keeps the retval value and continues executing the function. Then, depending on whether uport->ops->verify_port is set, the retval value may or may not be reset to zero and eventually the error value from security_locked_down() may abort the function a few lines below. I will go out on a limb and assume that this isn't the intended behavior and that an error value from security_locked_down() was supposed to abort the function only in case (change_irq || change_port) is true. Note that security_locked_down() should be called last in any series of checks, since the SELinux implementation of this hook will do a check against the policy and generate an audit record in case of denial. If the operation was to carry on after calling security_locked_down(), then the SELinux denial record would be bogus. See commit 59438b46471a ("security,lockdown,selinux: implement SELinux lockdown") for how SELinux implements this hook. Fixes: 794edf30ee6c ("lockdown: Lock down TIOCSSERIAL") Acked-by: Kees Cook Signed-off-by: Ondrej Mosnacek Cc: stable Link: https://lore.kernel.org/r/20210507115719.140799-1-omosnace@redhat.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit b71781c58982e9814c926e7e9c71744fbb8a2795 Author: Sargun Dhillon Date: Mon May 17 12:39:06 2021 -0700 seccomp: Refactor notification handler to prepare for new semantics commit ddc473916955f7710d1eb17c1273d91c8622a9fe upstream. This refactors the user notification code to have a do / while loop around the completion condition. This has a small change in semantic, in that previously we ignored addfd calls upon wakeup if the notification had been responded to, but instead with the new change we check for an outstanding addfd calls prior to returning to userspace. Rodrigo Campos also identified a bug that can result in addfd causing an early return, when the supervisor didn't actually handle the syscall [1]. [1]: https://lore.kernel.org/lkml/20210413160151.3301-1-rodrigo@kinvolk.io/ Fixes: 7cf97b125455 ("seccomp: Introduce addfd ioctl to seccomp user notifier") Signed-off-by: Sargun Dhillon Acked-by: Tycho Andersen Acked-by: Christian Brauner Signed-off-by: Kees Cook Tested-by: Rodrigo Campos Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210517193908.3113-3-sargun@sargun.me Signed-off-by: Greg Kroah-Hartman commit a160cabf86a749f1fe1202b50b281e376e13e193 Author: Sargun Dhillon Date: Mon May 17 12:39:05 2021 -0700 Documentation: seccomp: Fix user notification documentation commit aac902925ea646e461c95edc98a8a57eb0def917 upstream. The documentation had some previously incorrect information about how userspace notifications (and responses) were handled due to a change from a previously proposed patchset. Signed-off-by: Sargun Dhillon Acked-by: Tycho Andersen Acked-by: Christian Brauner Signed-off-by: Kees Cook Fixes: 6a21cc50f0c7 ("seccomp: add a return code to trap to userspace") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210517193908.3113-2-sargun@sargun.me Signed-off-by: Greg Kroah-Hartman commit adfe1d01e6f0c90e4ff465e6772c9e2b6acac8c2 Author: Greg Kroah-Hartman Date: Thu May 20 15:08:39 2021 +0200 kgdb: fix gcc-11 warnings harder commit bda7d3ab06f19c02dcef61fefcb9dd954dfd5e4f upstream. 40cc3a80bb42 ("kgdb: fix gcc-11 warning on indentation") tried to fix up the gcc-11 complaints in this file by just reformatting the #defines. That worked for gcc 11.1.0, but in gcc 11.1.1 as shipped by Fedora 34, the warning came back for one of the #defines. Fix this up again by putting { } around the if statement, now it is quiet again. Fixes: 40cc3a80bb42 ("kgdb: fix gcc-11 warning on indentation") Cc: Arnd Bergmann Cc: Daniel Thompson Cc: Jason Wessel Link: https://lore.kernel.org/r/20210520130839.51987-1-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit eeb3f0b0c3514f37d0df66d11d4afe9d9cfff603 Author: Michael Ellerman Date: Wed Nov 4 21:08:42 2020 +1100 selftests/gpio: Fix build when source tree is read only [ Upstream commit b68c1c65dec5fb5186ebd33ce52059b4c6db8500 ] Currently the gpio selftests fail to build if the source tree is read only: make -j 160 -C tools/testing/selftests TARGETS=gpio make[1]: Entering directory '/linux/tools/testing/selftests/gpio' make OUTPUT=/linux/tools/gpio/ -C /linux/tools/gpio make[2]: Entering directory '/linux/tools/gpio' mkdir -p /linux/tools/gpio/include/linux 2>&1 || true ln -sf /linux/tools/gpio/../../include/uapi/linux/gpio.h /linux/tools/gpio/include/linux/gpio.h ln: failed to create symbolic link '/linux/tools/gpio/include/linux/gpio.h': Read-only file system This happens because we ask make to build ../../../gpio (tools/gpio) without pointing OUTPUT away from the source directory. To fix it we create a subdirectory of the existing OUTPUT directory, called tools-gpio, and tell tools/gpio to build in there. Signed-off-by: Michael Ellerman Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 008f98f1dbac4a409dcfe58498dfab298ae7a80d Author: Michael Ellerman Date: Wed Nov 4 21:08:41 2020 +1100 selftests/gpio: Move include of lib.mk up [ Upstream commit 449539da2e237336bc750b41f1736a77f9aca25c ] Move the include of lib.mk up so that in a subsequent patch we can use OUTPUT, which is initialised by lib.mk, in the definition of the GPIO variables. Signed-off-by: Michael Ellerman Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit beac83e8bd09a4a9cab625e12ec9ec38791f5d12 Author: Michael Ellerman Date: Wed Nov 4 21:08:40 2020 +1100 selftests/gpio: Use TEST_GEN_PROGS_EXTENDED [ Upstream commit ff2c395b9257f0e617f9cd212893f3c72c80ee6c ] Use TEST_GEN_PROGS_EXTENDED rather than TEST_PROGS_EXTENDED. That tells the lib.mk logic that the files it references are to be generated by the Makefile. Having done that we don't need to override the all rule. Signed-off-by: Michael Ellerman Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 1cdabf921bfacc63245a2eafbaeaf0bde9f193ef Author: James Zhu Date: Wed May 19 11:42:48 2021 -0400 drm/amdgpu/jpeg2.0: add cancel_delayed_work_sync before power gate commit ff48f6dbf0ff896c98d167a67a5b975fb034356b upstream. Add cancel_delayed_work_sync before set power gating state to avoid race condition issue when power gating. Signed-off-by: James Zhu Reviewed-by: Leo Liu Acked-by: Christian König Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit bed5cc65ff3d088ceb5a59e77944d626300a2ef2 Author: James Zhu Date: Wed May 19 11:40:39 2021 -0400 drm/amdgpu/vcn2.5: add cancel_delayed_work_sync before power gate commit 2fb536ea42d557f39f70c755f68e1aa1ad466c55 upstream. Add cancel_delayed_work_sync before set power gating state to avoid race condition issue when power gating. Signed-off-by: James Zhu Reviewed-by: Leo Liu Acked-by: Christian König Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit efd47c9d586d5a1e5818fc263b06188e49b5dc9f Author: James Zhu Date: Wed May 19 11:26:32 2021 -0400 drm/amdgpu/vcn2.0: add cancel_delayed_work_sync before power gate commit 0c6013377b4027e69d8f3e63b6bf556b6cb87802 upstream. Add cancel_delayed_work_sync before set power gating state to avoid race condition issue when power gating. Signed-off-by: James Zhu Reviewed-by: Leo Liu Acked-by: Christian König Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 01abf69154d0dd3d92b375b3a4db230844ba7c74 Author: Kevin Wang Date: Wed May 19 11:03:11 2021 +0800 drm/amdkfd: correct sienna_cichlid SDMA RLC register offset error commit ba515a5821dc0d101ded0379b14b1d1471ebfaba upstream. 1.correct KFD SDMA RLC queue register offset error. (all sdma rlc register offset is base on SDMA0.RLC0_RLC0_RB_CNTL) 2.HQD_N_REGS (19+6+7+12) 12: the 2 more resgisters than navi1x (SDMAx_RLCy_MIDCMD_DATA{9,10}) the patch also can be fixed NULL pointer issue when read /sys/kernel/debug/kfd/hqds on sienna_cichlid chip. Signed-off-by: Kevin Wang Reviewed-by: Likun Gao Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 2e4f262ef51d7336b319656897d7dce9d5b49bad Author: James Zhu Date: Tue May 18 10:58:22 2021 -0400 drm/amdgpu/vcn1: add cancel_delayed_work_sync before power gate commit b95f045ea35673572ef46d6483ad8bd6d353d63c upstream. Add cancel_delayed_work_sync before set power gating state to avoid race condition issue when power gating. Signed-off-by: James Zhu Reviewed-by: Leo Liu Acked-by: Christian König Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit e3a662e5e882b2d1b0d03a7671798cacbedcc540 Author: Evan Quan Date: Tue May 18 09:01:47 2021 +0800 drm/amd/pm: correct MGpuFanBoost setting commit 1a0b713c73688c6bafbe6faf8c90390b11b26fc6 upstream. No MGpuFanBoost setting for those ASICs which do not support it. Otherwise, it may breaks their fan control feature. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1580 Signed-off-by: Evan Quan Reviewed-by: Kenneth Feng Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 1a8ecc3cd1a1250c12128717e47d160f22ba3866 Author: Mikulas Patocka Date: Tue May 25 13:17:19 2021 -0400 dm snapshot: properly fix a crash when an origin has no snapshots commit 7e768532b2396bcb7fbf6f82384b85c0f1d2f197 upstream. If an origin target has no snapshots, o->split_boundary is set to 0. This causes BUG_ON(sectors <= 0) in block/bio.c:bio_split(). Fix this by initializing chunk_size, and in turn split_boundary, to rounddown_pow_of_two(UINT_MAX) -- the largest power of two that fits into "unsigned" type. Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit cc5d84b1b07d5239c2ca591cab3e3e4e7b0384e4 Author: Sriram R Date: Tue May 11 20:02:58 2021 +0200 ath11k: Clear the fragment cache during key install commit c3944a5621026c176001493d48ee66ff94e1a39a upstream. Currently the fragment cache setup during peer assoc is cleared only during peer delete. In case a key reinstallation happens with the same peer, the same fragment cache with old fragments added before key installation could be clubbed with fragments received after. This might be exploited to mix fragments of different data resulting in a proper unintended reassembled packet to be passed up the stack. Hence flush the fragment cache on every key installation to prevent potential attacks (CVE-2020-24587). Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.4.0.1-01734-QCAHKSWPL_SILICONZ-1 v2 Cc: stable@vger.kernel.org Signed-off-by: Sriram R Signed-off-by: Jouni Malinen Link: https://lore.kernel.org/r/20210511200110.218dc777836f.I9af6fc76215a35936c4152552018afb5079c5d8c@changeid Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 8135f46f5a48b33aa11f0f74d61f0d8604a6bd18 Author: Sriram R Date: Tue May 11 20:02:57 2021 +0200 ath10k: Validate first subframe of A-MSDU before processing the list commit 62a8ff67eba52dae9b107e1fb8827054ed00a265 upstream. In certain scenarios a normal MSDU can be received as an A-MSDU when the A-MSDU present bit of a QoS header gets flipped during reception. Since this bit is unauthenticated, the hardware crypto engine can pass the frame to the driver without any error indication. This could result in processing unintended subframes collected in the A-MSDU list. Hence, validate A-MSDU list by checking if the first frame has a valid subframe header. Comparing the non-aggregated MSDU and an A-MSDU, the fields of the first subframe DA matches the LLC/SNAP header fields of a normal MSDU. In order to avoid processing such frames, add a validation to filter such A-MSDU frames where the first subframe header DA matches with the LLC/SNAP header pattern. Tested-on: QCA9984 hw1.0 PCI 10.4-3.10-00047 Cc: stable@vger.kernel.org Signed-off-by: Sriram R Signed-off-by: Jouni Malinen Link: https://lore.kernel.org/r/20210511200110.e6f5eb7b9847.I38a77ae26096862527a5eab73caebd7346af8b66@changeid Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 6643b21aee1c3cac10da9dfb0fa17aacc431fa91 Author: Wen Gong Date: Tue May 11 20:02:56 2021 +0200 ath10k: Fix TKIP Michael MIC verification for PCIe commit 0dc267b13f3a7e8424a898815dd357211b737330 upstream. TKIP Michael MIC was not verified properly for PCIe cases since the validation steps in ieee80211_rx_h_michael_mic_verify() in mac80211 did not get fully executed due to unexpected flag values in ieee80211_rx_status. Fix this by setting the flags property to meet mac80211 expectations for performing Michael MIC validation there. This fixes CVE-2020-26141. It does the same as ath10k_htt_rx_proc_rx_ind_hl() for SDIO which passed MIC verification case. This applies only to QCA6174/QCA9377 PCIe. Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00110-QCARMSWP-1 Cc: stable@vger.kernel.org Signed-off-by: Wen Gong Signed-off-by: Jouni Malinen Link: https://lore.kernel.org/r/20210511200110.c3f1d42c6746.I795593fcaae941c471425b8c7d5f7bb185d29142@changeid Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit c4d5271830c606af4a6803b645af30e79e2a5e8b Author: Wen Gong Date: Tue May 11 20:02:55 2021 +0200 ath10k: drop MPDU which has discard flag set by firmware for SDIO commit 079a108feba474b4b32bd3471db03e11f2f83b81 upstream. When the discard flag is set by the firmware for an MPDU, it should be dropped. This allows a mitigation for CVE-2020-24588 to be implemented in the firmware. Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00049 Cc: stable@vger.kernel.org Signed-off-by: Wen Gong Signed-off-by: Jouni Malinen Link: https://lore.kernel.org/r/20210511200110.11968c725b5c.Idd166365ebea2771c0c0a38c78b5060750f90e17@changeid Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 425cee63609137fa0c8f84f59f0dd0e94f296efe Author: Wen Gong Date: Tue May 11 20:02:54 2021 +0200 ath10k: drop fragments with multicast DA for SDIO commit 40e7462dad6f3d06efdb17d26539e61ab6e34db1 upstream. Fragmentation is not used with multicast frames. Discard unexpected fragments with multicast DA. This fixes CVE-2020-26145. Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00049 Cc: stable@vger.kernel.org Signed-off-by: Wen Gong Signed-off-by: Jouni Malinen Link: https://lore.kernel.org/r/20210511200110.9ca6ca7945a9.I1e18b514590af17c155bda86699bc3a971a8dcf4@changeid Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit b1b3dcd653772f93b69be50263a0ca50d7c9e77f Author: Wen Gong Date: Tue May 11 20:02:53 2021 +0200 ath10k: drop fragments with multicast DA for PCIe commit 65c415a144ad8132b6a6d97d4a1919ffc728e2d1 upstream. Fragmentation is not used with multicast frames. Discard unexpected fragments with multicast DA. This fixes CVE-2020-26145. Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00110-QCARMSWP-1 Cc: stable@vger.kernel.org Signed-off-by: Wen Gong Signed-off-by: Jouni Malinen Link: https://lore.kernel.org/r/20210511200110.5a0bd289bda8.Idd6ebea20038fb1cfee6de924aa595e5647c9eae@changeid Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit c17b3e1ffc14dbe03762f585c6d4553c1497e7ca Author: Wen Gong Date: Tue May 11 20:02:52 2021 +0200 ath10k: add CCMP PN replay protection for fragmented frames for PCIe commit a1166b2653db2f3de7338b9fb8a0f6e924b904ee upstream. PN replay check for not fragmented frames is finished in the firmware, but this was not done for fragmented frames when ath10k is used with QCA6174/QCA6377 PCIe. mac80211 has the function ieee80211_rx_h_defragment() for PN replay check for fragmented frames, but this does not get checked with QCA6174 due to the ieee80211_has_protected() condition not matching the cleared Protected bit case. Validate the PN of received fragmented frames within ath10k when CCMP is used and drop the fragment if the PN is not correct (incremented by exactly one from the previous fragment). This applies only for QCA6174/QCA6377 PCIe. Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00110-QCARMSWP-1 Cc: stable@vger.kernel.org Signed-off-by: Wen Gong Signed-off-by: Jouni Malinen Link: https://lore.kernel.org/r/20210511200110.9ba2664866a4.I756e47b67e210dba69966d989c4711ffc02dc6bc@changeid Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 6abcc01e8b3b804a7f18721666d978f39470e30c Author: Wen Gong Date: Tue May 11 20:02:51 2021 +0200 mac80211: extend protection against mixed key and fragment cache attacks commit 3edc6b0d6c061a70d8ca3c3c72eb1f58ce29bfb1 upstream. For some chips/drivers, e.g., QCA6174 with ath10k, the decryption is done by the hardware, and the Protected bit in the Frame Control field is cleared in the lower level driver before the frame is passed to mac80211. In such cases, the condition for ieee80211_has_protected() is not met in ieee80211_rx_h_defragment() of mac80211 and the new security validation steps are not executed. Extend mac80211 to cover the case where the Protected bit has been cleared, but the frame is indicated as having been decrypted by the hardware. This extends protection against mixed key and fragment cache attack for additional drivers/chips. This fixes CVE-2020-24586 and CVE-2020-24587 for such cases. Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00110-QCARMSWP-1 Cc: stable@vger.kernel.org Signed-off-by: Wen Gong Signed-off-by: Jouni Malinen Link: https://lore.kernel.org/r/20210511200110.037aa5ca0390.I7bb888e2965a0db02a67075fcb5deb50eb7408aa@changeid Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 2b9b07b9a06fab16bda3d33da3be70fe33bd95cb Author: Johannes Berg Date: Tue May 11 20:02:50 2021 +0200 mac80211: do not accept/forward invalid EAPOL frames commit a8c4d76a8dd4fb9666fc8919a703d85fb8f44ed8 upstream. EAPOL frames are used for authentication and key management between the AP and each individual STA associated in the BSS. Those frames are not supposed to be sent by one associated STA to another associated STA (either unicast for broadcast/multicast). Similarly, in 802.11 they're supposed to be sent to the authenticator (AP) address. Since it is possible for unexpected EAPOL frames to result in misbehavior in supplicant implementations, it is better for the AP to not allow such cases to be forwarded to other clients either directly, or indirectly if the AP interface is part of a bridge. Accept EAPOL (control port) frames only if they're transmitted to the own address, or, due to interoperability concerns, to the PAE group address. Disable forwarding of EAPOL (or well, the configured control port protocol) frames back to wireless medium in all cases. Previously, these frames were accepted from fully authenticated and authorized stations and also from unauthenticated stations for one of the cases. Additionally, to avoid forwarding by the bridge, rewrite the PAE group address case to the local MAC address. Cc: stable@vger.kernel.org Co-developed-by: Jouni Malinen Signed-off-by: Jouni Malinen Link: https://lore.kernel.org/r/20210511200110.cb327ed0cabe.Ib7dcffa2a31f0913d660de65ba3c8aca75b1d10f@changeid Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit bf710b60bc7b07b65809dae76e4f9589a259ea20 Author: Johannes Berg Date: Tue May 11 20:02:49 2021 +0200 mac80211: prevent attacks on TKIP/WEP as well commit 7e44a0b597f04e67eee8cdcbe7ee706c6f5de38b upstream. Similar to the issues fixed in previous patches, TKIP and WEP should be protected even if for TKIP we have the Michael MIC protecting it, and WEP is broken anyway. However, this also somewhat protects potential other algorithms that drivers might implement. Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210511200110.430e8c202313.Ia37e4e5b6b3eaab1a5ae050e015f6c92859dbe27@changeid Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit e64ea0597050157f926ac2ba9b478a44ee5be945 Author: Johannes Berg Date: Tue May 11 20:02:48 2021 +0200 mac80211: check defrag PN against current frame commit bf30ca922a0c0176007e074b0acc77ed345e9990 upstream. As pointed out by Mathy Vanhoef, we implement the RX PN check on fragmented frames incorrectly - we check against the last received PN prior to the new frame, rather than to the one in this frame itself. Prior patches addressed the security issue here, but in order to be able to reason better about the code, fix it to really compare against the current frame's PN, not the last stored one. Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210511200110.bfbc340ff071.Id0b690e581da7d03d76df90bb0e3fd55930bc8a0@changeid Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit f51fe83ead3a24371277c5c2ea56a2478b8fe9ca Author: Johannes Berg Date: Tue May 11 20:02:47 2021 +0200 mac80211: add fragment cache to sta_info commit 3a11ce08c45b50d69c891d71760b7c5b92074709 upstream. Prior patches protected against fragmentation cache attacks by coloring keys, but this shows that it can lead to issues when multiple stations use the same sequence number. Add a fragment cache to struct sta_info (in addition to the one in the interface) to separate fragments for different stations properly. This then automatically clear most of the fragment cache when a station disconnects (or reassociates) from an AP, or when client interfaces disconnect from the network, etc. On the way, also fix the comment there since this brings us in line with the recommendation in 802.11-2016 ("An AP should support ..."). Additionally, remove a useless condition (since there's no problem purging an already empty list). Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210511200110.fc35046b0d52.I1ef101e3784d13e8f6600d83de7ec9a3a45bcd52@changeid Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 9b21fcae6f68a775630171eafaea5558a7ad5592 Author: Johannes Berg Date: Tue May 11 20:02:46 2021 +0200 mac80211: drop A-MSDUs on old ciphers commit 270032a2a9c4535799736142e1e7c413ca7b836e upstream. With old ciphers (WEP and TKIP) we shouldn't be using A-MSDUs since A-MSDUs are only supported if we know that they are, and the only practical way for that is HT support which doesn't support old ciphers. However, we would normally accept them anyway. Since we check the MMIC before deaggregating A-MSDUs, and the A-MSDU bit in the QoS header is not protected in TKIP (or WEP), this enables attacks similar to CVE-2020-24588. To prevent that, drop A-MSDUs completely with old ciphers. Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210511200110.076543300172.I548e6e71f1ee9cad4b9a37bf212ae7db723587aa@changeid Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit c730d72aa6e85a71ee74530d601d4d894d791b43 Author: Mathy Vanhoef Date: Tue May 11 20:02:45 2021 +0200 cfg80211: mitigate A-MSDU aggregation attacks commit 2b8a1fee3488c602aca8bea004a087e60806a5cf upstream. Mitigate A-MSDU injection attacks (CVE-2020-24588) by detecting if the destination address of a subframe equals an RFC1042 (i.e., LLC/SNAP) header, and if so dropping the complete A-MSDU frame. This mitigates known attacks, although new (unknown) aggregation-based attacks may remain possible. This defense works because in A-MSDU aggregation injection attacks, a normal encrypted Wi-Fi frame is turned into an A-MSDU frame. This means the first 6 bytes of the first A-MSDU subframe correspond to an RFC1042 header. In other words, the destination MAC address of the first A-MSDU subframe contains the start of an RFC1042 header during an aggregation attack. We can detect this and thereby prevent this specific attack. For details, see Section 7.2 of "Fragment and Forge: Breaking Wi-Fi Through Frame Aggregation and Fragmentation". Note that for kernel 4.9 and above this patch depends on "mac80211: properly handle A-MSDUs that start with a rfc1042 header". Otherwise this patch has no impact and attacks will remain possible. Cc: stable@vger.kernel.org Signed-off-by: Mathy Vanhoef Link: https://lore.kernel.org/r/20210511200110.25d93176ddaf.I9e265b597f2cd23eb44573f35b625947b386a9de@changeid Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit e3561d5af01c2c49ed52c8d2644be752d5b13ec2 Author: Mathy Vanhoef Date: Tue May 11 20:02:44 2021 +0200 mac80211: properly handle A-MSDUs that start with an RFC 1042 header commit a1d5ff5651ea592c67054233b14b30bf4452999c upstream. Properly parse A-MSDUs whose first 6 bytes happen to equal a rfc1042 header. This can occur in practice when the destination MAC address equals AA:AA:03:00:00:00. More importantly, this simplifies the next patch to mitigate A-MSDU injection attacks. Cc: stable@vger.kernel.org Signed-off-by: Mathy Vanhoef Link: https://lore.kernel.org/r/20210511200110.0b2b886492f0.I23dd5d685fe16d3b0ec8106e8f01b59f499dffed@changeid Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 42d98e02193d163c1523a8840a2effcc4c6eb111 Author: Mathy Vanhoef Date: Tue May 11 20:02:43 2021 +0200 mac80211: prevent mixed key and fragment cache attacks commit 94034c40ab4a3fcf581fbc7f8fdf4e29943c4a24 upstream. Simultaneously prevent mixed key attacks (CVE-2020-24587) and fragment cache attacks (CVE-2020-24586). This is accomplished by assigning a unique color to every key (per interface) and using this to track which key was used to decrypt a fragment. When reassembling frames, it is now checked whether all fragments were decrypted using the same key. To assure that fragment cache attacks are also prevented, the ID that is assigned to keys is unique even over (re)associations and (re)connects. This means fragments separated by a (re)association or (re)connect will not be reassembled. Because mac80211 now also prevents the reassembly of mixed encrypted and plaintext fragments, all cache attacks are prevented. Cc: stable@vger.kernel.org Signed-off-by: Mathy Vanhoef Link: https://lore.kernel.org/r/20210511200110.3f8290e59823.I622a67769ed39257327a362cfc09c812320eb979@changeid Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit f7829b014bb670a77f6f66d265b058534367d04b Author: Mathy Vanhoef Date: Tue May 11 20:02:42 2021 +0200 mac80211: assure all fragments are encrypted commit 965a7d72e798eb7af0aa67210e37cf7ecd1c9cad upstream. Do not mix plaintext and encrypted fragments in protected Wi-Fi networks. This fixes CVE-2020-26147. Previously, an attacker was able to first forward a legitimate encrypted fragment towards a victim, followed by a plaintext fragment. The encrypted and plaintext fragment would then be reassembled. For further details see Section 6.3 and Appendix D in the paper "Fragment and Forge: Breaking Wi-Fi Through Frame Aggregation and Fragmentation". Because of this change there are now two equivalent conditions in the code to determine if a received fragment requires sequential PNs, so we also move this test to a separate function to make the code easier to maintain. Cc: stable@vger.kernel.org Signed-off-by: Mathy Vanhoef Link: https://lore.kernel.org/r/20210511200110.30c4394bb835.I5acfdb552cc1d20c339c262315950b3eac491397@changeid Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit b1f45a26bd322525c14edd9504f6d46dfad679a4 Author: Stefano Brivio Date: Mon May 10 07:58:22 2021 +0200 netfilter: nft_set_pipapo_avx2: Add irq_fpu_usable() check, fallback to non-AVX2 version commit f0b3d338064e1fe7531f0d2977e35f3b334abfb4 upstream. Arturo reported this backtrace: [709732.358791] WARNING: CPU: 3 PID: 456 at arch/x86/kernel/fpu/core.c:128 kernel_fpu_begin_mask+0xae/0xe0 [709732.358793] Modules linked in: binfmt_misc nft_nat nft_chain_nat nf_nat nft_counter nft_ct nf_tables nf_conntrack_netlink nfnetlink 8021q garp stp mrp llc vrf intel_rapl_msr intel_rapl_common skx_edac nfit libnvdimm ipmi_ssif x86_pkg_temp_thermal intel_powerclamp coretemp crc32_pclmul mgag200 ghash_clmulni_intel drm_kms_helper cec aesni_intel drm libaes crypto_simd cryptd glue_helper mei_me dell_smbios iTCO_wdt evdev intel_pmc_bxt iTCO_vendor_support dcdbas pcspkr rapl dell_wmi_descriptor wmi_bmof sg i2c_algo_bit watchdog mei acpi_ipmi ipmi_si button nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ipmi_devintf ipmi_msghandler ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 dm_mod raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor sd_mod t10_pi crc_t10dif crct10dif_generic raid6_pq libcrc32c crc32c_generic raid1 raid0 multipath linear md_mod ahci libahci tg3 libata xhci_pci libphy xhci_hcd ptp usbcore crct10dif_pclmul crct10dif_common bnxt_en crc32c_intel scsi_mod [709732.358941] pps_core i2c_i801 lpc_ich i2c_smbus wmi usb_common [709732.358957] CPU: 3 PID: 456 Comm: jbd2/dm-0-8 Not tainted 5.10.0-0.bpo.5-amd64 #1 Debian 5.10.24-1~bpo10+1 [709732.358959] Hardware name: Dell Inc. PowerEdge R440/04JN2K, BIOS 2.9.3 09/23/2020 [709732.358964] RIP: 0010:kernel_fpu_begin_mask+0xae/0xe0 [709732.358969] Code: ae 54 24 04 83 e3 01 75 38 48 8b 44 24 08 65 48 33 04 25 28 00 00 00 75 33 48 83 c4 10 5b c3 65 8a 05 5e 21 5e 76 84 c0 74 92 <0f> 0b eb 8e f0 80 4f 01 40 48 81 c7 00 14 00 00 e8 dd fb ff ff eb [709732.358972] RSP: 0018:ffffbb9700304740 EFLAGS: 00010202 [709732.358976] RAX: 0000000000000001 RBX: 0000000000000003 RCX: 0000000000000001 [709732.358979] RDX: ffffbb9700304970 RSI: ffff922fe1952e00 RDI: 0000000000000003 [709732.358981] RBP: ffffbb9700304970 R08: ffff922fc868a600 R09: ffff922fc711e462 [709732.358984] R10: 000000000000005f R11: ffff922ff0b27180 R12: ffffbb9700304960 [709732.358987] R13: ffffbb9700304b08 R14: ffff922fc664b6c8 R15: ffff922fc664b660 [709732.358990] FS: 0000000000000000(0000) GS:ffff92371fec0000(0000) knlGS:0000000000000000 [709732.358993] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [709732.358996] CR2: 0000557a6655bdd0 CR3: 000000026020a001 CR4: 00000000007706e0 [709732.358999] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [709732.359001] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [709732.359003] PKRU: 55555554 [709732.359005] Call Trace: [709732.359009] [709732.359035] nft_pipapo_avx2_lookup+0x4c/0x1cba [nf_tables] [709732.359046] ? sched_clock+0x5/0x10 [709732.359054] ? sched_clock_cpu+0xc/0xb0 [709732.359061] ? record_times+0x16/0x80 [709732.359068] ? plist_add+0xc1/0x100 [709732.359073] ? psi_group_change+0x47/0x230 [709732.359079] ? skb_clone+0x4d/0xb0 [709732.359085] ? enqueue_task_rt+0x22b/0x310 [709732.359098] ? bnxt_start_xmit+0x1e8/0xaf0 [bnxt_en] [709732.359102] ? packet_rcv+0x40/0x4a0 [709732.359121] nft_lookup_eval+0x59/0x160 [nf_tables] [709732.359133] nft_do_chain+0x350/0x500 [nf_tables] [709732.359152] ? nft_lookup_eval+0x59/0x160 [nf_tables] [709732.359163] ? nft_do_chain+0x364/0x500 [nf_tables] [709732.359172] ? fib4_rule_action+0x6d/0x80 [709732.359178] ? fib_rules_lookup+0x107/0x250 [709732.359184] nft_nat_do_chain+0x8a/0xf2 [nft_chain_nat] [709732.359193] nf_nat_inet_fn+0xea/0x210 [nf_nat] [709732.359202] nf_nat_ipv4_out+0x14/0xa0 [nf_nat] [709732.359207] nf_hook_slow+0x44/0xc0 [709732.359214] ip_output+0xd2/0x100 [709732.359221] ? __ip_finish_output+0x210/0x210 [709732.359226] ip_forward+0x37d/0x4a0 [709732.359232] ? ip4_key_hashfn+0xb0/0xb0 [709732.359238] ip_sublist_rcv_finish+0x4f/0x60 [709732.359243] ip_sublist_rcv+0x196/0x220 [709732.359250] ? ip_rcv_finish_core.isra.22+0x400/0x400 [709732.359255] ip_list_rcv+0x137/0x160 [709732.359264] __netif_receive_skb_list_core+0x29b/0x2c0 [709732.359272] netif_receive_skb_list_internal+0x1a6/0x2d0 [709732.359280] gro_normal_list.part.156+0x19/0x40 [709732.359286] napi_complete_done+0x67/0x170 [709732.359298] bnxt_poll+0x105/0x190 [bnxt_en] [709732.359304] ? irqentry_exit+0x29/0x30 [709732.359309] ? asm_common_interrupt+0x1e/0x40 [709732.359315] net_rx_action+0x144/0x3c0 [709732.359322] __do_softirq+0xd5/0x29c [709732.359329] asm_call_irq_on_stack+0xf/0x20 [709732.359332] [709732.359339] do_softirq_own_stack+0x37/0x40 [709732.359346] irq_exit_rcu+0x9d/0xa0 [709732.359353] common_interrupt+0x78/0x130 [709732.359358] asm_common_interrupt+0x1e/0x40 [709732.359366] RIP: 0010:crc_41+0x0/0x1e [crc32c_intel] [709732.359370] Code: ff ff f2 4d 0f 38 f1 93 a8 fe ff ff f2 4c 0f 38 f1 81 b0 fe ff ff f2 4c 0f 38 f1 8a b0 fe ff ff f2 4d 0f 38 f1 93 b0 fe ff ff 4c 0f 38 f1 81 b8 fe ff ff f2 4c 0f 38 f1 8a b8 fe ff ff f2 4d [709732.359373] RSP: 0018:ffffbb97008dfcd0 EFLAGS: 00000246 [709732.359377] RAX: 000000000000002a RBX: 0000000000000400 RCX: ffff922fc591dd50 [709732.359379] RDX: ffff922fc591dea0 RSI: 0000000000000a14 RDI: ffffffffc00dddc0 [709732.359382] RBP: 0000000000001000 R08: 000000000342d8c3 R09: 0000000000000000 [709732.359384] R10: 0000000000000000 R11: ffff922fc591dff0 R12: ffffbb97008dfe58 [709732.359386] R13: 000000000000000a R14: ffff922fd2b91e80 R15: ffff922fef83fe38 [709732.359395] ? crc_43+0x1e/0x1e [crc32c_intel] [709732.359403] ? crc32c_pcl_intel_update+0x97/0xb0 [crc32c_intel] [709732.359419] ? jbd2_journal_commit_transaction+0xaec/0x1a30 [jbd2] [709732.359425] ? irq_exit_rcu+0x3e/0xa0 [709732.359447] ? kjournald2+0xbd/0x270 [jbd2] [709732.359454] ? finish_wait+0x80/0x80 [709732.359470] ? commit_timeout+0x10/0x10 [jbd2] [709732.359476] ? kthread+0x116/0x130 [709732.359481] ? kthread_park+0x80/0x80 [709732.359488] ? ret_from_fork+0x1f/0x30 [709732.359494] ---[ end trace 081a19978e5f09f5 ]--- that is, nft_pipapo_avx2_lookup() uses the FPU running from a softirq that interrupted a kthread, also using the FPU. That's exactly the reason why irq_fpu_usable() is there: use it, and if we can't use the FPU, fall back to the non-AVX2 version of the lookup operation, i.e. nft_pipapo_lookup(). Reported-by: Arturo Borrero Gonzalez Cc: # 5.6.x Fixes: 7400b063969b ("nft_set_pipapo: Introduce AVX2-based lookup implementation") Signed-off-by: Stefano Brivio Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit e6294c06e7c62ffdd5bf3df696d3a4fcbb753d3c Author: Davide Caratti Date: Sat May 22 15:15:13 2021 +0200 net/sched: fq_pie: fix OOB access in the traffic path commit e70f7a11876a1a788ceadf75e9e5f7af2c868680 upstream. the following script: # tc qdisc add dev eth0 handle 0x1 root fq_pie flows 2 # tc qdisc add dev eth0 clsact # tc filter add dev eth0 egress matchall action skbedit priority 0x10002 # ping 192.0.2.2 -I eth0 -c2 -w1 -q produces the following splat: BUG: KASAN: slab-out-of-bounds in fq_pie_qdisc_enqueue+0x1314/0x19d0 [sch_fq_pie] Read of size 4 at addr ffff888171306924 by task ping/942 CPU: 3 PID: 942 Comm: ping Not tainted 5.12.0+ #441 Hardware name: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066+0f1aadab 04/01/2014 Call Trace: dump_stack+0x92/0xc1 print_address_description.constprop.7+0x1a/0x150 kasan_report.cold.13+0x7f/0x111 fq_pie_qdisc_enqueue+0x1314/0x19d0 [sch_fq_pie] __dev_queue_xmit+0x1034/0x2b10 ip_finish_output2+0xc62/0x2120 __ip_finish_output+0x553/0xea0 ip_output+0x1ca/0x4d0 ip_send_skb+0x37/0xa0 raw_sendmsg+0x1c4b/0x2d00 sock_sendmsg+0xdb/0x110 __sys_sendto+0x1d7/0x2b0 __x64_sys_sendto+0xdd/0x1b0 do_syscall_64+0x3c/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7fe69735c3eb Code: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 f3 0f 1e fa 48 8d 05 75 42 2c 00 41 89 ca 8b 00 85 c0 75 14 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 75 c3 0f 1f 40 00 41 57 4d 89 c7 41 56 41 89 RSP: 002b:00007fff06d7fb38 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 000055e961413700 RCX: 00007fe69735c3eb RDX: 0000000000000040 RSI: 000055e961413700 RDI: 0000000000000003 RBP: 0000000000000040 R08: 000055e961410500 R09: 0000000000000010 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff06d81260 R13: 00007fff06d7fb40 R14: 00007fff06d7fc30 R15: 000055e96140f0a0 Allocated by task 917: kasan_save_stack+0x19/0x40 __kasan_kmalloc+0x7f/0xa0 __kmalloc_node+0x139/0x280 fq_pie_init+0x555/0x8e8 [sch_fq_pie] qdisc_create+0x407/0x11b0 tc_modify_qdisc+0x3c2/0x17e0 rtnetlink_rcv_msg+0x346/0x8e0 netlink_rcv_skb+0x120/0x380 netlink_unicast+0x439/0x630 netlink_sendmsg+0x719/0xbf0 sock_sendmsg+0xe2/0x110 ____sys_sendmsg+0x5ba/0x890 ___sys_sendmsg+0xe9/0x160 __sys_sendmsg+0xd3/0x170 do_syscall_64+0x3c/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae The buggy address belongs to the object at ffff888171306800 which belongs to the cache kmalloc-256 of size 256 The buggy address is located 36 bytes to the right of 256-byte region [ffff888171306800, ffff888171306900) The buggy address belongs to the page: page:00000000bcfb624e refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x171306 head:00000000bcfb624e order:1 compound_mapcount:0 flags: 0x17ffffc0010200(slab|head|node=0|zone=2|lastcpupid=0x1fffff) raw: 0017ffffc0010200 dead000000000100 dead000000000122 ffff888100042b40 raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888171306800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff888171306880: 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc fc >ffff888171306900: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ ffff888171306980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff888171306a00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fix fq_pie traffic path to avoid selecting 'q->flows + q->flows_cnt' as a valid flow: it's an address beyond the allocated memory. Fixes: ec97ecf1ebe4 ("net: sched: add Flow Queue PIE packet scheduler") CC: stable@vger.kernel.org Signed-off-by: Davide Caratti Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit e583eb5e7282b22c51a482ee6bf01fca1f0543f0 Author: Davide Caratti Date: Sat May 22 15:14:45 2021 +0200 net/sched: fq_pie: re-factor fix for fq_pie endless loop commit 3a62fed2fd7b6fea96d720e779cafc30dfb3a22e upstream. the patch that fixed an endless loop in_fq_pie_init() was not considering that 65535 is a valid class id. The correct bugfix for this infinite loop is to change 'idx' to become an u32, like Colin proposed in the past [1]. Fix this as follows: - restore 65536 as maximum possible values of 'flows_cnt' - use u32 'idx' when iterating on 'q->flows' - fix the TDC selftest This reverts commit bb2f930d6dd708469a587dc9ed1efe1ef969c0bf. [1] https://lore.kernel.org/netdev/20210407163808.499027-1-colin.king@canonical.com/ CC: Colin Ian King CC: stable@vger.kernel.org Fixes: bb2f930d6dd7 ("net/sched: fix infinite loop in sch_fq_pie") Fixes: ec97ecf1ebe4 ("net: sched: add Flow Queue PIE packet scheduler") Signed-off-by: Davide Caratti Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 47da4f61422991c42af6fbbc75ccdd747f392068 Author: Johan Hovold Date: Mon May 24 11:25:11 2021 +0200 net: hso: fix control-request directions commit 1a6e9a9c68c1f183872e4bcc947382111c2e04eb upstream. The direction of the pipe argument must match the request-type direction bit or control requests may fail depending on the host-controller-driver implementation. Fix the tiocmset and rfkill requests which erroneously used usb_rcvctrlpipe(). Fixes: 72dc1c096c70 ("HSO: add option hso driver") Cc: stable@vger.kernel.org # 2.6.27 Signed-off-by: Johan Hovold Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit fb003a1bd60358c0ccee0145079de258a6cf0ba8 Author: Kees Cook Date: Tue May 25 12:37:35 2021 -0700 proc: Check /proc/$pid/attr/ writes against file opener commit bfb819ea20ce8bbeeba17e1a6418bf8bda91fc28 upstream. Fix another "confused deputy" weakness[1]. Writes to /proc/$pid/attr/ files need to check the opener credentials, since these fds do not transition state across execve(). Without this, it is possible to trick another process (which may have different credentials) to write to its own /proc/$pid/attr/ files, leading to unexpected and possibly exploitable behaviors. [1] https://www.kernel.org/doc/html/latest/security/credentials.html?highlight=confused#open-file-credentials Fixes: 1da177e4c3f41 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Kees Cook Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 03b777ce8d7030f7b9d69c77eb706cf6b134655c Author: Adrian Hunter Date: Fri May 21 12:20:53 2021 +0300 perf scripts python: exported-sql-viewer.py: Fix warning display commit f56299a9c998e0bfbd4ab07cafe9eb8444512448 upstream. Deprecation warnings are useful only for the developer, not an end user. Display warnings only when requested using the python -W option. This stops the display of warnings like: tools/perf/scripts/python/exported-sql-viewer.py:5102: DeprecationWarning: an integer is required (got type PySide2.QtCore.Qt.AlignmentFlag). Implicit conversion to integers using __int__ is deprecated, and may be removed in a future version of Python. err = app.exec_() Since the warning can be fixed only in PySide2, we must wait for it to be finally fixed there. Signed-off-by: Adrian Hunter Cc: Jiri Olsa Cc: stable@vger.kernel.org # v5.3+ Link: http://lore.kernel.org/lkml/20210521092053.25683-4-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 76b6c5a98f1a8232097fad9bb3e2ef6afdde2e8c Author: Adrian Hunter Date: Fri May 21 12:20:52 2021 +0300 perf scripts python: exported-sql-viewer.py: Fix Array TypeError commit fd931b2e234a7cc451a7bbb1965d6ce623189158 upstream. The 'Array' class is present in more than one python standard library. In some versions of Python 3, the following error occurs: Traceback (most recent call last): File "tools/perf/scripts/python/exported-sql-viewer.py", line 4702, in reports_menu.addAction(CreateAction(label, "Create a new window displaying branch events", lambda a=None,x=dbid: self.NewBranchView(x), self)) File "tools/perf/scripts/python/exported-sql-viewer.py", line 4727, in NewBranchView BranchWindow(self.glb, event_id, ReportVars(), self) File "tools/perf/scripts/python/exported-sql-viewer.py", line 3208, in __init__ self.model = LookupCreateModel(model_name, lambda: BranchModel(glb, event_id, report_vars.where_clause)) File "tools/perf/scripts/python/exported-sql-viewer.py", line 343, in LookupCreateModel model = create_fn() File "tools/perf/scripts/python/exported-sql-viewer.py", line 3208, in self.model = LookupCreateModel(model_name, lambda: BranchModel(glb, event_id, report_vars.where_clause)) File "tools/perf/scripts/python/exported-sql-viewer.py", line 3124, in __init__ self.fetcher = SQLFetcher(glb, sql, prep, self.AddSample) File "tools/perf/scripts/python/exported-sql-viewer.py", line 2658, in __init__ self.buffer = Array(c_char, self.buffer_size, lock=False) TypeError: abstract class This apparently happens because Python can be inconsistent about which class of the name 'Array' gets imported. Fix by importing explicitly by name so that only the desired 'Array' gets imported. Fixes: 8392b74b575c3 ("perf scripts python: exported-sql-viewer.py: Add ability to display all the database tables") Signed-off-by: Adrian Hunter Cc: Jiri Olsa Cc: stable@vger.kernel.org Link: http://lore.kernel.org/lkml/20210521092053.25683-3-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 07f7694169931cc7b603e0cd12ed025cb15612ad Author: Adrian Hunter Date: Fri May 21 12:20:51 2021 +0300 perf scripts python: exported-sql-viewer.py: Fix copy to clipboard from Top Calls by elapsed Time report commit a6172059758ba1b496ae024cece7d5bdc8d017db upstream. Provide missing argument to prevent following error when copying a selection to the clipboard: Traceback (most recent call last): File "tools/perf/scripts/python/exported-sql-viewer.py", line 4041, in menu.addAction(CreateAction("&Copy selection", "Copy to clipboard", lambda: CopyCellsToClipboardHdr(self.view), self.view)) File "tools/perf/scripts/python/exported-sql-viewer.py", line 4021, in CopyCellsToClipboardHdr CopyCellsToClipboard(view, False, True) File "tools/perf/scripts/python/exported-sql-viewer.py", line 4018, in CopyCellsToClipboard view.CopyCellsToClipboard(view, as_csv, with_hdr) File "tools/perf/scripts/python/exported-sql-viewer.py", line 3871, in CopyTableCellsToClipboard val = model.headerData(col, Qt.Horizontal) TypeError: headerData() missing 1 required positional argument: 'role' Fixes: 96c43b9a7ab3b ("perf scripts python: exported-sql-viewer.py: Add copy to clipboard") Signed-off-by: Adrian Hunter Cc: Jiri Olsa Cc: stable@vger.kernel.org Link: http://lore.kernel.org/lkml/20210521092053.25683-2-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 7285b92dc55ffba2bf7026d1befce8859be1325f Author: Adrian Hunter Date: Wed May 19 10:45:13 2021 +0300 perf intel-pt: Fix transaction abort handling commit cb7987837c31b217b28089bbc78922d5c9187869 upstream. When adding support for power events, some handling of FUP packets was unified. That resulted in breaking reporting of TSX aborts, by not considering the associated TIP packet. Fix that. Example: A machine that supports TSX is required. It will have flag "rtm". Kernel parameter tsx=on may be required. # for w in `cat /proc/cpuinfo | grep -m1 flags `;do echo $w | grep rtm ; done rtm Test program: #include #include int main() { int x = 0; if (_xbegin() == _XBEGIN_STARTED) { x = 1; _xabort(1); } else { printf("x = %d\n", x); } return 0; } Compile with -mrtm i.e. gcc -Wall -Wextra -mrtm xabort.c -o xabort Record: perf record -e intel_pt/cyc/u --filter 'filter main @ ./xabort' ./xabort Before: # perf script --itrace=be -F+flags,+addr,-period,-event --ns xabort 1478 [007] 92161.431348552: tr strt 0 [unknown] ([unknown]) => 400b6d main+0x0 (/root/xabort) xabort 1478 [007] 92161.431348624: jmp 400b96 main+0x29 (/root/xabort) => 400bae main+0x41 (/root/xabort) xabort 1478 [007] 92161.431348624: return 400bb4 main+0x47 (/root/xabort) => 400b87 main+0x1a (/root/xabort) xabort 1478 [007] 92161.431348637: jcc 400b8a main+0x1d (/root/xabort) => 400b98 main+0x2b (/root/xabort) xabort 1478 [007] 92161.431348644: tr end call 400ba9 main+0x3c (/root/xabort) => 40f690 printf+0x0 (/root/xabort) xabort 1478 [007] 92161.431360859: tr strt 0 [unknown] ([unknown]) => 400bae main+0x41 (/root/xabort) xabort 1478 [007] 92161.431360882: tr end return 400bb4 main+0x47 (/root/xabort) => 401139 __libc_start_main+0x309 (/root/xabort) After: # perf script --itrace=be -F+flags,+addr,-period,-event --ns xabort 1478 [007] 92161.431348552: tr strt 0 [unknown] ([unknown]) => 400b6d main+0x0 (/root/xabort) xabort 1478 [007] 92161.431348624: tx abrt 400b93 main+0x26 (/root/xabort) => 400b87 main+0x1a (/root/xabort) xabort 1478 [007] 92161.431348637: jcc 400b8a main+0x1d (/root/xabort) => 400b98 main+0x2b (/root/xabort) xabort 1478 [007] 92161.431348644: tr end call 400ba9 main+0x3c (/root/xabort) => 40f690 printf+0x0 (/root/xabort) xabort 1478 [007] 92161.431360859: tr strt 0 [unknown] ([unknown]) => 400bae main+0x41 (/root/xabort) xabort 1478 [007] 92161.431360882: tr end return 400bb4 main+0x47 (/root/xabort) => 401139 __libc_start_main+0x309 (/root/xabort) Fixes: a472e65fc490a ("perf intel-pt: Add decoder support for ptwrite and power event packets") Signed-off-by: Adrian Hunter Cc: Andi Kleen Cc: Jiri Olsa Cc: stable@vger.kernel.org Link: http://lore.kernel.org/lkml/20210519074515.9262-2-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit ce3ea6b66ded81e8c61897fae81e2173368487a1 Author: Adrian Hunter Date: Wed May 19 10:45:14 2021 +0300 perf intel-pt: Fix sample instruction bytes commit c954eb72b31a9dc56c99b450253ec5b121add320 upstream. The decoder reports the current instruction if it was decoded. In some cases the current instruction is not decoded, in which case the instruction bytes length must be set to zero. Ensure that is always done. Note perf script can anyway get the instruction bytes for any samples where they are not present. Also note, that there is a redundant "ptq->insn_len = 0" statement which is not removed until a subsequent patch in order to make this patch apply cleanly to stable branches. Example: A machne that supports TSX is required. It will have flag "rtm". Kernel parameter tsx=on may be required. # for w in `cat /proc/cpuinfo | grep -m1 flags `;do echo $w | grep rtm ; done rtm Test program: #include #include int main() { int x = 0; if (_xbegin() == _XBEGIN_STARTED) { x = 1; _xabort(1); } else { printf("x = %d\n", x); } return 0; } Compile with -mrtm i.e. gcc -Wall -Wextra -mrtm xabort.c -o xabort Record: perf record -e intel_pt/cyc/u --filter 'filter main @ ./xabort' ./xabort Before: # perf script --itrace=xe -F+flags,+insn,-period --xed --ns xabort 1478 [007] 92161.431348581: transactions: x 400b81 main+0x14 (/root/xabort) mov $0xffffffff, %eax xabort 1478 [007] 92161.431348624: transactions: tx abrt 400b93 main+0x26 (/root/xabort) mov $0xffffffff, %eax After: # perf script --itrace=xe -F+flags,+insn,-period --xed --ns xabort 1478 [007] 92161.431348581: transactions: x 400b81 main+0x14 (/root/xabort) xbegin 0x6 xabort 1478 [007] 92161.431348624: transactions: tx abrt 400b93 main+0x26 (/root/xabort) xabort $0x1 Fixes: faaa87680b25d ("perf intel-pt/bts: Report instruction bytes and length in sample") Signed-off-by: Adrian Hunter Cc: Andi Kleen Cc: Jiri Olsa Cc: stable@vger.kernel.org Link: http://lore.kernel.org/lkml/20210519074515.9262-3-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit f01134321d04f47c718bb41b799bcdeda27873d2 Author: Rolf Eike Beer Date: Tue May 25 15:08:02 2021 +0800 iommu/vt-d: Fix sysfs leak in alloc_iommu() commit 0ee74d5a48635c848c20f152d0d488bf84641304 upstream. iommu_device_sysfs_add() is called before, so is has to be cleaned on subsequent errors. Fixes: 39ab9555c2411 ("iommu: Add sysfs bindings for struct iommu_device") Cc: stable@vger.kernel.org # 4.11.x Signed-off-by: Rolf Eike Beer Acked-by: Lu Baolu Link: https://lore.kernel.org/r/17411490.HIIP88n32C@mobilepool36.emlix.com Link: https://lore.kernel.org/r/20210525070802.361755-2-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit f9890652185b72b8de9ebeb4406037640b6e1b53 Author: Anna Schumaker Date: Wed May 19 12:54:51 2021 -0400 NFSv4: Fix a NULL pointer dereference in pnfs_mark_matching_lsegs_return() commit a421d218603ffa822a0b8045055c03eae394a7eb upstream. Commit de144ff4234f changes _pnfs_return_layout() to call pnfs_mark_matching_lsegs_return() passing NULL as the struct pnfs_layout_range argument. Unfortunately, pnfs_mark_matching_lsegs_return() doesn't check if we have a value here before dereferencing it, causing an oops. I'm able to hit this crash consistently when running connectathon basic tests on NFS v4.1/v4.2 against Ontap. Fixes: de144ff4234f ("NFSv4: Don't discard segments marked for return in _pnfs_return_layout()") Cc: stable@vger.kernel.org Signed-off-by: Anna Schumaker Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 3e5b48d9e713cb2fdc33a2b23acb9b3e48edf3af Author: Aurelien Aptel Date: Fri May 21 17:19:27 2021 +0200 cifs: set server->cipher_type to AES-128-CCM for SMB3.0 commit 6d2fcfe6b517fe7cbf2687adfb0a16cdcd5d9243 upstream. SMB3.0 doesn't have encryption negotiate context but simply uses the SMB2_GLOBAL_CAP_ENCRYPTION flag. When that flag is present in the neg response cifs.ko uses AES-128-CCM which is the only cipher available in this context. cipher_type was set to the server cipher only when parsing encryption negotiate context (SMB3.1.1). For SMB3.0 it was set to 0. This means cipher_type value can be 0 or 1 for AES-128-CCM. Fix this by checking for SMB3.0 and encryption capability and setting cipher_type appropriately. Signed-off-by: Aurelien Aptel Cc: Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 020b6b0dc7b61346e829bef3877110ba83628fb6 Author: Geoffrey D. Bennett Date: Fri May 21 17:50:13 2021 +0930 ALSA: usb-audio: scarlett2: Improve driver startup messages commit 265d1a90e4fb6d3264d8122fbd10760e5e733be6 upstream. Add separate init function to call the existing controls_create function so a custom error can be displayed if initialisation fails. Use info level instead of error for notifications. Display the VID/PID so device_setup is targeted to the right device. Display "enabled" message to easily confirm that the driver is loaded. Signed-off-by: Geoffrey D. Bennett Cc: Link: https://lore.kernel.org/r/b5d140c65f640faf2427e085fbbc0297b32e5fce.1621584566.git.g@b4.vu Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 9a75ed5103855500362d35c9107b7e78df320154 Author: Geoffrey D. Bennett Date: Fri May 21 17:50:12 2021 +0930 ALSA: usb-audio: scarlett2: Fix device hang with ehci-pci commit 764fa6e686e0107c0357a988d193de04cf047583 upstream. Use usb_rcvctrlpipe() not usb_sndctrlpipe() for USB control input in the Scarlett Gen 2 mixer driver. This fixes the device hang during initialisation when used with the ehci-pci host driver. Fixes: 9e4d5c1be21f ("ALSA: usb-audio: Scarlett Gen 2 mixer interface") Signed-off-by: Geoffrey D. Bennett Cc: Link: https://lore.kernel.org/r/66a3d05dac325d5b53e4930578e143cef1f50dbe.1621584566.git.g@b4.vu Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 7b42f41dab4c5c0a2f9cd53c9b5db793cc7b2c21 Author: Jeremy Szu Date: Thu May 20 01:03:56 2021 +0800 ALSA: hda/realtek: fix mute/micmute LEDs and speaker for HP Zbook Fury 17 G8 commit 50dbfae972cbe0e3c631e73c7c58cbc48bfc6a49 upstream. The HP ZBook Studio 17.3 Inch G8 is using ALC285 codec which is using 0x04 to control mute LED and 0x01 to control micmute LED. In the other hand, there is no output from right channel of speaker. Therefore, add a quirk to make it works. Signed-off-by: Jeremy Szu Cc: Link: https://lore.kernel.org/r/20210519170357.58410-4-jeremy.szu@canonical.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 7573b58a2d8fcb5e0f83e8fa1756ab14f3569914 Author: Jeremy Szu Date: Thu May 20 01:03:55 2021 +0800 ALSA: hda/realtek: fix mute/micmute LEDs and speaker for HP Zbook Fury 15 G8 commit e650c1a959da49f2b873cb56564b825882c22e7a upstream. The HP ZBook Fury 15.6 Inch G8 is using ALC285 codec which is using 0x04 to control mute LED and 0x01 to control micmute LED. In the other hand, there is no output from right channel of speaker. Therefore, add a quirk to make it works. Signed-off-by: Jeremy Szu Cc: Link: https://lore.kernel.org/r/20210519170357.58410-3-jeremy.szu@canonical.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit b8cd7164b345a479e36dc67bdb036df7ddb19581 Author: Jeremy Szu Date: Thu May 20 01:03:54 2021 +0800 ALSA: hda/realtek: fix mute/micmute LEDs and speaker for HP Zbook G8 commit bbe183e07817a46cf8d3d7fc88093df81d23a957 upstream. The HP ZBook Studio 15.6 Inch G8 is using ALC285 codec which is using 0x04 to control mute LED and 0x01 to control micmute LED. In the other hand, there is no output from right channel of speaker. Therefore, add a quirk to make it works. Signed-off-by: Jeremy Szu Cc: Link: https://lore.kernel.org/r/20210519170357.58410-2-jeremy.szu@canonical.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 8ffce2b02b4542236861fc1afbf3e4a561edbd7c Author: Jeremy Szu Date: Thu May 20 01:03:53 2021 +0800 ALSA: hda/realtek: fix mute/micmute LEDs for HP 855 G8 commit 0e68c4b11f1e66d211ad242007e9f1076a6b7709 upstream. The HP EliteBook 855 G8 Notebook PC is using ALC285 codec which needs ALC285_FIXUP_HP_MUTE_LED fixup to make it works. After applying the fixup, the mute/micmute LEDs work good. Signed-off-by: Jeremy Szu Cc: Link: https://lore.kernel.org/r/20210519170357.58410-1-jeremy.szu@canonical.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 7906018de7365995756171f3bc2a4d3208ccc66e Author: Peter Ujfalusi Date: Mon May 24 23:37:26 2021 +0300 ALSA: hda/realtek: Chain in pop reduction fixup for ThinkStation P340 commit 29c8f40b54a45dd23971e2bc395697731bcffbe1 upstream. Lenovo ThinkStation P340 uses ALC623 codec (SSID 17aa:1048) and it produces bug plock/pop noise over line out (green jack on the back) which can be fixed by applying ALC269_FIXUP_NO_SHUTUP tot he machine. Convert the existing entry for the same SSID to chain to apply this fixup as well. Suggested-by: Takashi Iwai Signed-off-by: Peter Ujfalusi Cc: Link: https://lore.kernel.org/r/20210524203726.2278-1-peter.ujfalusi@linux.intel.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 2f0f8e06e7ea2325b585bc07a058932f2cc75208 Author: Hui Wang Date: Sat May 22 11:47:41 2021 +0800 ALSA: hda/realtek: Headphone volume is controlled by Front mixer commit 119b75c150773425a89033215eab4d15d4198f8b upstream. On some ASUS and MSI machines, the audio codec is alc1220 and the Headphone is connected to audio mixer 0xf and DAC 0x5, in theory the Headphone volume is controlled by DAC 0x5 (Heapdhone Playback Volume), but somehow it is controlled by DAC 0x2 (Front Playback Volume), maybe this is a defect on the codec alc1220. Because of this issue, the PA couldn't switch the headphone and Lineout correctly, If we apply the quirk CLEVO_P950 to those machines, the Lineout and Headphone will share the audio mixer 0xc and DAC 0x2, and generate Headphone+LO mixer, then PA could handle them when switching between them. BugLink: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/1206 Cc: Signed-off-by: Hui Wang Link: https://lore.kernel.org/r/20210522034741.13415-1-hui.wang@canonical.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 8ca63ce0278219b5c60d610d8caba6bda116636f Author: Hui Wang Date: Sat May 22 12:26:45 2021 +0800 ALSA: hda/realtek: the bass speaker can't output sound on Yoga 9i commit 9ebaef0540a981093bce5df15af32354d32391d9 upstream. The Lenovo Yoga 9i has bass speaker, but the bass speaker can't work, that is because there is an i2s amplifier on that speaker, need to run ideapad_s740_coef() to initialize the amplifier. And also needs to apply ALC285_FIXUP_THINKPAD_HEADSET_JACK to rename the speaker's mixer control name, otherwise the PA can't handle them. BugLink: http://bugs.launchpad.net/bugs/1926165 Signed-off-by: Hui Wang Cc: Link: https://lore.kernel.org/r/20210522042645.14221-1-hui.wang@canonical.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman