- Aug 26, 2021
-
-
Sasha Levin authored
Tested-by:
Linux Kernel Functional Testing <lkft@linaro.org> Tested-by:
Guenter Roeck <linux@roeck-us.net> Tested-by:
Shuah Khan <skhan@linuxfoundation.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Jeff Layton authored
[ Upstream commit fdd92b64 ] We've had CONFIG_MANDATORY_FILE_LOCKING since 2015 and a lot of distros have disabled it. Warn the stragglers that still use "-o mand" that we'll be dropping support for that mount option. Cc: stable@vger.kernel.org Signed-off-by:
Jeff Layton <jlayton@kernel.org> Signed-off-by:
-
Jens Axboe authored
[ Upstream commit a30f895a ] We currently check for ret != 0 to indicate error, but '1' is a valid return and just indicates that the allocation succeeded with a wrap. Correct the check to be for < 0, like it was before the xarray conversion. Cc: stable@vger.kernel.org Fixes: 61cf9370 ("io_uring: Convert personality_idr to XArray") Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Mike Kravetz authored
[ Upstream commit c7b1850d ] syzbot hit kernel BUG at fs/hugetlbfs/inode.c:532 as described in [1]. This BUG triggers if the HPageRestoreReserve flag is set on a page in the page cache. It should never be set, as the routine huge_add_to_page_cache explicitly clears the flag after adding a page to the cache. The only code other than huge page allocation which sets the flag is restore_reserve_on_error. It will potentially set the flag in rare out of memory conditions. syzbot was injecting errors to cause memory allocation errors which exercised this specific path. The code in restore_reserve_on_error is doing the right thing. However, there are instances where pages in the page cache were being passed to restore_reserve_on_error. This is incorrect, as once a page goes into the cache reservation information will not be modified for the page until it is removed from the cache. Error paths do not remove pages from the cache, so even in the case of error, the page will remain in the cache and no reservation adjustment is needed. Modify routines that potentially call restore_reserve_on_error with a page cache page to no longer do so. Note on fixes tag: Prior to commit 846be085 ("mm/hugetlb: expand restore_reserve_on_error functionality") the routine would not process page cache pages because the HPageRestoreReserve flag is not set on such pages. Therefore, this issue could not be trigggered. The code added by commit 846be085 ("mm/hugetlb: expand restore_reserve_on_error functionality") is needed and correct. It exposed incorrect calls to restore_reserve_on_error which is the root cause addressed by this commit. [1] https://lore.kernel.org/linux-mm/00000000000050776d05c9b7c7f0@google.com/ Link: https://lkml.kernel.org/r/20210818213304.37038-1-mike.kravetz@oracle.com Fixes: 846be085 ("mm/hugetlb: expand restore_reserve_on_error functionality") Signed-off-by:
Mike Kravetz <mike.kravetz@oracle.com> Reported-by:
<syzbot+67654e51e54455f1c585@syzkaller.appspotmail.com> Cc: Mina Almasry <almasrymina@google.com> Cc: Axel Rasmussen <axelrasmussen@google.com> Cc: Peter Xu <peterx@redhat.com> Cc: Muchun Song <songmuchun@bytedance.com> Cc: Michal Hocko <mhocko@suse.com> Cc: Naoya Horiguchi <naoya.horiguchi@linux.dev> Cc: <stable@vger.kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Marco Elver authored
[ Upstream commit a7cb5d23 ] Originally the addr != NULL check was meant to take care of the case where __kfence_pool == NULL (KFENCE is disabled). However, this does not work for addresses where addr > 0 && addr < KFENCE_POOL_SIZE. This can be the case on NULL-deref where addr > 0 && addr < PAGE_SIZE or any other faulting access with addr < KFENCE_POOL_SIZE. While the kernel would likely crash, the stack traces and report might be confusing due to double faults upon KFENCE's attempt to unprotect such an address. Fix it by just checking that __kfence_pool != NULL instead. Link: https://lkml.kernel.org/r/20210818130300.2482437-1-elver@google.com Fixes: 0ce20dd8 ("mm: add Kernel Electric-Fence infrastructure") Signed-off-by:
Marco Elver <elver@google.com> Reported-by:
Kuan-Ying Lee <Kuan-Ying.Lee@mediatek.com> Acked-by:
Alexander Potapenko <glider@google.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: <stable@vger.kernel.org> [5.12+] Signed-off-by:
-
Naoya Horiguchi authored
[ Upstream commit fcc00621 ] HWPoisonHandlable() sometimes returns false for typical user pages due to races with average memory events like transfers over LRU lists. This causes failures in hwpoison handling. There's retry code for such a case but does not work because the retry loop reaches the retry limit too quickly before the page settles down to handlable state. Let get_any_page() call shake_page() to fix it. [naoya.horiguchi@nec.com: get_any_page(): return -EIO when retry limit reached] Link: https://lkml.kernel.org/r/20210819001958.2365157-1-naoya.horiguchi@linux.dev Link: https://lkml.kernel.org/r/20210817053703.2267588-1-naoya.horiguchi@linux.dev Fixes: 25182f05 ("mm,hwpoison: fix race with hugetlb page allocation") Signed-off-by:
Naoya Horiguchi <naoya.horiguchi@nec.com> Reported-by:
Tony Luck <tony.luck@intel.com> Reviewed-by:
Yang Shi <shy828301@gmail.com> Cc: Oscar Salvador <osalvador@suse.de> Cc: Muchun Song <songmuchun@bytedance.com> Cc: Mike Kravetz <mike.kravetz@oracle.com> Cc: Michal Hocko <mhocko@suse.com> Cc: <stable@vger.kernel.org> [5.13+] Signed-off-by:
-
Naoya Horiguchi authored
[ Upstream commit 0ed950d1 ] __get_hwpoison_page() could fail to grab refcount by some race condition, so it's helpful if we can handle it by retrying. We already have retry logic, so make get_hwpoison_page() call get_any_page() when called from memory_failure(). As a result, get_hwpoison_page() can return negative values (i.e. error code), so some callers are also changed to handle error cases. soft_offline_page() does nothing for -EBUSY because that's enough and users in userspace can easily handle it. unpoison_memory() is also unchanged because it's broken and need thorough fixes (will be done later). Link: https://lkml.kernel.org/r/20210603233632.2964832-3-nao.horiguchi@gmail.com Signed-off-by:
-
Johannes Weiner authored
[ Upstream commit f56ce412 ] We've noticed occasional OOM killing when memory.low settings are in effect for cgroups. This is unexpected and undesirable as memory.low is supposed to express non-OOMing memory priorities between cgroups. The reason for this is proportional memory.low reclaim. When cgroups are below their memory.low threshold, reclaim passes them over in the first round, and then retries if it couldn't find pages anywhere else. But when cgroups are slightly above their memory.low setting, page scan force is scaled down and diminished in proportion to the overage, to the point where it can cause reclaim to fail as well - only in that case we currently don't retry, and instead trigger OOM. To fix this, hook proportional reclaim into the same retry logic we have in place for when cgroups are skipped entirely. This way if reclaim fails and some cgroups were scanned with diminished pressure, we'll try another full-force cycle before giving up and OOMing. [akpm@linux-foundation.org: coding-style fixes] Link: https://lkml.kernel.org/r/20210817180506.220056-1-hannes@cmpxchg.org Fixes: 9783aa99 ("mm, memcg: proportional memory.{low,min} reclaim") Signed-off-by:
Johannes Weiner <hannes@cmpxchg.org> Reported-by:
Leon Yang <lnyng@fb.com> Reviewed-by:
Rik van Riel <riel@surriel.com> Reviewed-by:
Shakeel Butt <shakeelb@google.com> Acked-by:
Roman Gushchin <guro@fb.com> Acked-by:
Chris Down <chris@chrisdown.name> Acked-by:
Michal Hocko <mhocko@suse.com> Cc: <stable@vger.kernel.org> [5.4+] Signed-off-by:
-
Petr Pavlu authored
[ Upstream commit aa3e1ba3 ] Function init_resources() allocates a boot memory block to hold an array of resources which it adds to iomem_resource. The array is filled in from its end and the function then attempts to free any unused memory at the beginning. The problem is that size of the unused memory is incorrectly calculated and this can result in releasing memory which is in use by active resources. Their data then gets corrupted later when the memory is reused by a different part of the system. Fix the size of the released memory to correctly match the number of unused resource entries. Fixes: ffe0e526 ("RISC-V: Improve init_resources()") Signed-off-by:
Petr Pavlu <petr.pavlu@suse.com> Reviewed-by:
Sunil V L <sunilvl@ventanamicro.com> Acked-by:
Nick Kossifidis <mick@ics.forth.gr> Tested-by:
Palmer Dabbelt <palmerdabbelt@google.com> Signed-off-by:
-
Takashi Iwai authored
[ Upstream commit 65ca89c2 ] The commit 2e6b8363 ("ASoC: intel: atom: Fix reference to PCM buffer address") changed the reference of PCM buffer address to substream->runtime->dma_addr as the buffer address may change dynamically. However, I forgot that the dma_addr field is still not set up for the CONTINUOUS buffer type (that this driver uses) yet in 5.14 and earlier kernels, and it resulted in garbage I/O. The problem will be fixed in 5.15, but we need to address it quickly for now. The fix is to deduce the address again from the DMA pointer with virt_to_phys(), but from the right one, substream->runtime->dma_area. Fixes: 2e6b8363 ("ASoC: intel: atom: Fix reference to PCM buffer address") Reported-and-tested-by:
Hans de Goede <hdegoede@redhat.com> Cc: <stable@vger.kernel.org> Acked-by:
Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/2048c6aa-2187-46bd-6772-36a4fb3c5aeb@redhat.com Link: https://lore.kernel.org/r/20210819152945.8510-1-tiwai@suse.de Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Kai-Heng Feng authored
[ Upstream commit 8903376d ] The mic has lots of noises if mic boost is enabled. So disable mic boost to get crystal clear audio capture. Signed-off-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210818144119.121738-1-kai.heng.feng@canonical.com Signed-off-by:
-
Marcin Bachry authored
[ Upstream commit e0bff432 ] The Renoir XHCI controller apparently doesn't resume reliably with the standard D3hot-to-D0 delay. Increase it to 20ms. [Alex: I talked to the AMD USB hardware team and the AMD Windows team and they are not aware of any HW errata or specific issues. The HW works fine in Windows. I was told Windows uses a rather generous default delay of 100ms for PCI state transitions.] Link: https://lore.kernel.org/r/20210722025858.220064-1-alexander.deucher@amd.com Signed-off-by:
Marcin Bachry <hegel666@gmail.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Cc: stable@vger.kernel.org Cc: Mario Limonciello <mario.limonciello@amd.com> Cc: Prike Liang <prike.liang@amd.com> Cc: Shyam Sundar S K <shyam-sundar.s-k@amd.com> Signed-off-by:
-
Christophe Leroy authored
[ Upstream commit ef486bf4 ] Commit b5efec00 ("powerpc/32s: Move KUEP locking/unlocking in C") removed the 'isync' instruction after adding/removing NX bit in user segments. The reasoning behind this change was that when setting the NX bit we don't mind it taking effect with delay as the kernel never executes text from userspace, and when clearing the NX bit this is to return to userspace and then the 'rfi' should synchronise the context. However, it looks like on book3s/32 having a hash page table, at least on the G3 processor, we get an unexpected fault from userspace, then this is followed by something wrong in the verification of MSR_PR at end of another interrupt. This is fixed by adding back the removed isync() following update of NX bit in user segment registers. Only do it for cores with an hash table, as 603 cores don't exhibit that problem and the two isync increase ./null_syscall selftest by 6 cycles on an MPC 832x. First problem: unexpected WARN_ON() for mysterious PROTFAULT WARNING: CPU: 0 PID: 1660 at arch/powerpc/mm/fault.c:354 do_page_fault+0x6c/0x5b0 Modules linked in: CPU: 0 PID: 1660 Comm: Xorg Not tainted 5.13.0-pmac-00028-gb3c15b60339a #40 NIP: c001b5c8 LR: c001b6f8 CTR: 00000000 REGS: e2d09e40 TRAP: 0700 Not tainted (5.13.0-pmac-00028-gb3c15b60339a) MSR: 00021032 <ME,IR,DR,RI> CR: 42d04f30 XER: 20000000 GPR00: c000424c e2d09f00 c301b680 e2d09f40 0000001e 42000000 00cba028 00000000 GPR08: 08000000 48000010 c301b680 e2d09f30 22d09f30 00c1fff0 00cba000 a7b7ba4c GPR16: 00000031 00000000 00000000 00000000 00000000 00000000 a7b7b0d0 00c5c010 GPR24: a7b7b64c a7b7d2f0 00000004 00000000 c1efa6c0 00cba02c 00000300 e2d09f40 NIP [c001b5c8] do_page_fault+0x6c/0x5b0 LR [c001b6f8] do_page_fault+0x19c/0x5b0 Call Trace: [e2d09f00] [e2d09f04] 0xe2d09f04 (unreliable) [e2d09f30] [c000424c] DataAccess_virt+0xd4/0xe4 --- interrupt: 300 at 0xa7a261dc NIP: a7a261dc LR: a7a253bc CTR: 00000000 REGS: e2d09f40 TRAP: 0300 Not tainted (5.13.0-pmac-00028-gb3c15b60339a) MSR: 0000d032 <EE,PR,ME,IR,DR,RI> CR: 228428e2 XER: 20000000 DAR: 00cba02c DSISR: 42000000 GPR00: a7a27448 afa6b0e0 a74c35c0 a7b7b614 0000001e a7b7b614 00cba028 00000000 GPR08: 00020fd9 00000031 00cb9ff8 a7a273b0 220028e2 00c1fff0 00cba000 a7b7ba4c GPR16: 00000031 00000000 00000000 00000000 00000000 00000000 a7b7b0d0 00c5c010 GPR24: a7b7b64c a7b7d2f0 00000004 00000002 0000001e a7b7b614 a7b7aff4 00000030 NIP [a7a261dc] 0xa7a261dc LR [a7a253bc] 0xa7a253bc --- interrupt: 300 Instruction dump: 7c4a1378 810300a0 75278410 83820298 83a300a4 553b018c 551e0036 4082038c 2e1b0000 40920228 75280800 41820220 <0fe00000> 3b600000 41920214 81420594 Second problem: MSR PR is seen unset allthough the interrupt frame shows it set kernel BUG at arch/powerpc/kernel/interrupt.c:458! Oops: Exception in kernel mode, sig: 5 [#1] BE PAGE_SIZE=4K MMU=Hash SMP NR_CPUS=2 PowerMac Modules linked in: CPU: 0 PID: 1660 Comm: Xorg Tainted: G W 5.13.0-pmac-00028-gb3c15b60339a #40 NIP: c0011434 LR: c001629c CTR: 00000000 REGS: e2d09e70 TRAP: 0700 Tainted: G W (5.13.0-pmac-00028-gb3c15b60339a) MSR: 00029032 <EE,ME,IR,DR,RI> CR: 42d09f30 XER: 00000000 GPR00: 00000000 e2d09f30 c301b680 e2d09f40 83440000 c44d0e68 e2d09e8c 00000000 GPR08: 00000002 00dc228a 00004000 e2d09f30 22d09f30 00c1fff0 afa6ceb4 00c26144 GPR16: 00c25fb8 00c26140 afa6ceb8 90000000 00c944d8 0000001c 00000000 00200000 GPR24: 00000000 000001fb afa6d1b4 00000001 00000000 a539a2a0 a530fd80 00000089 NIP [c0011434] interrupt_exit_kernel_prepare+0x10/0x70 LR [c001629c] interrupt_return+0x9c/0x144 Call Trace: [e2d09f30] [c000424c] DataAccess_virt+0xd4/0xe4 (unreliable) --- interrupt: 300 at 0xa09be008 NIP: a09be008 LR: a09bdfe8 CTR: a09bdfc0 REGS: e2d09f40 TRAP: 0300 Tainted: G W (5.13.0-pmac-00028-gb3c15b60339a) MSR: 0000d032 <EE,PR,ME,IR,DR,RI> CR: 420028e2 XER: 20000000 DAR: a539a308 DSISR: 0a000000 GPR00: a7b90d50 afa6b2d0 a74c35c0 a0a8b690 a0a8b698 a5365d70 a4fa82a8 00000004 GPR08: 00000000 a09bdfc0 00000000 a5360000 a09bde7c 00c1fff0 afa6ceb4 00c26144 GPR16: 00c25fb8 00c26140 afa6ceb8 90000000 00c944d8 0000001c 00000000 00200000 GPR24: 00000000 000001fb afa6d1b4 00000001 00000000 a539a2a0 a530fd80 00000089 NIP [a09be008] 0xa09be008 LR [a09bdfe8] 0xa09bdfe8 --- interrupt: 300 Instruction dump: 80010024 83e1001c 7c0803a6 4bffff80 3bc00800 4bffffd0 486b42fd 4bffffcc 81430084 71480002 41820038 554a0462 <0f0a0000> 80620060 74630001 40820034 Fixes: b5efec00 ("powerpc/32s: Move KUEP locking/unlocking in C") Cc: stable@vger.kernel.org # v5.13+ Reported-by:
Stan Johnson <userm57@yahoo.com> Signed-off-by:
Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/4856f5574906e2aec0522be17bf3848a22b2cd0b.1629269345.git.christophe.leroy@csgroup.eu Signed-off-by:
-
Christophe Leroy authored
[ Upstream commit 91bb3082 ] KUEP implements the update of user segment registers. Move it into mmu-hash.h in order to use it from other places. And inline kuep_lock() and kuep_unlock(). Inlining kuep_lock() is important for system_call_exception(), otherwise system_call_exception() has to save into stack the system call parameters that are used just after, and doing that takes more instructions than kuep_lock() itself. Signed-off-by:
-
Christophe Leroy authored
[ Upstream commit 91ec6671 ] Avoids the #ifdef in mmu.c Signed-off-by:
-
Hans de Goede authored
[ Upstream commit 5571ea31 ] Commit a20dcf53 ("usb: typec: tcpm: Respond Not_Supported if no snk_vdo"), stops tcpm_pd_data_request() calling tcpm_handle_vdm_request() when port->nr_snk_vdo is not set. But the VDM might be intended for an altmode-driver, in which case nr_snk_vdo does not matter. This change breaks the forwarding of connector hotplug (HPD) events for displayport altmode on devices which don't set nr_snk_vdo. tcpm_pd_data_request() is the only caller of tcpm_handle_vdm_request(), so we can move the nr_snk_vdo check to inside it, at which point we have already looked up the altmode device so we can check for this too. Doing this check here also ensures that vdm_state gets set to VDM_STATE_DONE if it was VDM_STATE_BUSY, even if we end up with responding with PD_MSG_CTRL_NOT_SUPP later. Note that tcpm_handle_vdm_request() was already sending PD_MSG_CTRL_NOT_SUPP in some circumstances, after moving the nr_snk_vdo check the same error-path is now taken when that check fails. So that we have only one error-path for this and not two. Replace the tcpm_queue_message(PD_MSG_CTRL_NOT_SUPP) used by the existing error-path with the more robust tcpm_pd_handle_msg() from the (now removed) second error-path. Fixes: a20dcf53 ("usb: typec: tcpm: Respond Not_Supported if no snk_vdo") Cc: stable <stable@vger.kernel.org> Cc: Kyle Tso <kyletso@google.com> Acked-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by:
Kyle Tso <kyletso@google.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Niklas Schnelle authored
[ Upstream commit 2a671f77 ] The struct pci_dev uses reference counting but zPCI assumed erroneously that the last reference would always be the local reference after calling pci_stop_and_remove_bus_device(). This is usually the case but not how reference counting works and thus inherently fragile. In fact one case where this causes a NULL pointer dereference when on an SRIOV device the function 0 was hot unplugged before another function of the same multi-function device. In this case the second function's pdev->sriov->dev reference keeps the struct pci_dev of function 0 alive even after the unplug. This bug was previously hidden by the fact that we were leaking the struct pci_dev which in turn means that it always outlived the struct zpci_dev. This was fixed in commit 0b13525c ("s390/pci: fix leak of PCI device structure") exposing the broken behavior. Fix this by accounting for the long living reference a struct pci_dev has to its underlying struct zpci_dev via the zbus->function[] array and only release that in pcibios_release_device() ensuring that the struct pci_dev is not left with a dangling reference. This is a minimal fix in the future it would probably better to use fine grained reference counting for struct zpci_dev. Fixes: 05bc1be6 ("s390/pci: create zPCI bus") Cc: stable@vger.kernel.org Reviewed-by:
Matthew Rosato <mjrosato@linux.ibm.com> Signed-off-by:
Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by:
Vasily Gorbik <gor@linux.ibm.com> Signed-off-by:
-
Takashi Iwai authored
[ Upstream commit 4bf61ad5 ] ASUS B23E requires the same workaround like other machines with VT1802, otherwise it looses the codec power on a few nodes and the sound kept silence. Fixes: a0645daf ("ALSA: HDA: Early Forbid of runtime PM") Link: https://lore.kernel.org/r/ac2232f142efcd67fe6ac38897f704f7176bd200.camel@gmail.com Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210817052432.14751-1-tiwai@suse.de Signed-off-by:
-
Pingfan Liu authored
[ Upstream commit 6c34df6f ] The event filters are not applied on all of the output, which results in the flood of printk when using tp_printk. Unfolding event_trigger_unlock_commit_regs() into trace_event_buffer_commit(), so the filters can be applied on every output. Link: https://lkml.kernel.org/r/20210814034538.8428-1-kernelfans@gmail.com Cc: stable@vger.kernel.org Fixes: 0daa2302 ("tracing: Add tp_printk cmdline to have tracepoints go to printk()") Signed-off-by:
Pingfan Liu <kernelfans@gmail.com> Signed-off-by:
Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by:
-
NeilBrown authored
[ Upstream commit 3f79f6f6 ] Cross-rename lacks a check when that would prevent exchanging a directory and subvolume from different parent subvolume. This causes data inconsistencies and is caught before commit by tree-checker, turning the filesystem to read-only. Calling the renameat2 with RENAME_EXCHANGE flags like renameat2(AT_FDCWD, namesrc, AT_FDCWD, namedest, (1 << 1)) on two paths: namesrc = dir1/subvol1/dir2 namedest = subvol2/subvol3 will cause key order problem with following write time tree-checker report: [1194842.307890] BTRFS critical (device loop1): corrupt leaf: root=5 block=27574272 slot=10 ino=258, invalid previous key objectid, have 257 expect 258 [1194842.322221] BTRFS info (device loop1): leaf 27574272 gen 8 total ptrs 11 free space 15444 owner 5 [1194842.331562] BTRFS info (device loop1): refs 2 lock_owner 0 current 26561 [1194842.338772] item 0 key (256 1 0) itemoff 16123 itemsize 160 [1194842.338793] inode generation 3 size 16 mode 40755 [1194842.338801] item 1 key (256 12 256) itemoff 16111 itemsize 12 [1194842.338809] item 2 key (256 84 2248503653) itemoff 16077 itemsize 34 [1194842.338817] dir oid 258 type 2 [1194842.338823] item 3 key (256 84 2363071922) itemoff 16043 itemsize 34 [1194842.338830] dir oid 257 type 2 [1194842.338836] item 4 key (256 96 2) itemoff 16009 itemsize 34 [1194842.338843] item 5 key (256 96 3) itemoff 15975 itemsize 34 [1194842.338852] item 6 key (257 1 0) itemoff 15815 itemsize 160 [1194842.338863] inode generation 6 size 8 mode 40755 [1194842.338869] item 7 key (257 12 256) itemoff 15801 itemsize 14 [1194842.338876] item 8 key (257 84 2505409169) itemoff 15767 itemsize 34 [1194842.338883] dir oid 256 type 2 [1194842.338888] item 9 key (257 96 2) itemoff 15733 itemsize 34 [1194842.338895] item 10 key (258 12 256) itemoff 15719 itemsize 14 [1194842.339163] BTRFS error (device loop1): block=27574272 write time tree block corruption detected [1194842.339245] ------------[ cut here ]------------ [1194842.443422] WARNING: CPU: 6 PID: 26561 at fs/btrfs/disk-io.c:449 csum_one_extent_buffer+0xed/0x100 [btrfs] [1194842.511863] CPU: 6 PID: 26561 Comm: kworker/u17:2 Not tainted 5.14.0-rc3-git+ #793 [1194842.511870] Hardware name: empty empty/S3993, BIOS PAQEX0-3 02/24/2008 [1194842.511876] Workqueue: btrfs-worker-high btrfs_work_helper [btrfs] [1194842.511976] RIP: 0010:csum_one_extent_buffer+0xed/0x100 [btrfs] [1194842.512068] RSP: 0018:ffffa2c284d77da0 EFLAGS: 00010282 [1194842.512074] RAX: 0000000000000000 RBX: 0000000000001000 RCX: ffff928867bd9978 [1194842.512078] RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff928867bd9970 [1194842.512081] RBP: ffff92876b958000 R08: 0000000000000001 R09: 00000000000c0003 [1194842.512085] R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000 [1194842.512088] R13: ffff92875f989f98 R14: 0000000000000000 R15: 0000000000000000 [1194842.512092] FS: 0000000000000000(0000) GS:ffff928867a00000(0000) knlGS:0000000000000000 [1194842.512095] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [1194842.512099] CR2: 000055f5384da1f0 CR3: 0000000102fe4000 CR4: 00000000000006e0 [1194842.512103] Call Trace: [1194842.512128] ? run_one_async_free+0x10/0x10 [btrfs] [1194842.631729] btree_csum_one_bio+0x1ac/0x1d0 [btrfs] [1194842.631837] run_one_async_start+0x18/0x30 [btrfs] [1194842.631938] btrfs_work_helper+0xd5/0x1d0 [btrfs] [1194842.647482] process_one_work+0x262/0x5e0 [1194842.647520] worker_thread+0x4c/0x320 [1194842.655935] ? process_one_work+0x5e0/0x5e0 [1194842.655946] kthread+0x135/0x160 [1194842.655953] ? set_kthread_struct+0x40/0x40 [1194842.655965] ret_from_fork+0x1f/0x30 [1194842.672465] irq event stamp: 1729 [1194842.672469] hardirqs last enabled at (1735): [<ffffffffbd1104f5>] console_trylock_spinning+0x185/0x1a0 [1194842.672477] hardirqs last disabled at (1740): [<ffffffffbd1104cc>] console_trylock_spinning+0x15c/0x1a0 [1194842.672482] softirqs last enabled at (1666): [<ffffffffbdc002e1>] __do_softirq+0x2e1/0x50a [1194842.672491] softirqs last disabled at (1651): [<ffffffffbd08aab7>] __irq_exit_rcu+0xa7/0xd0 The corrupted data will not be written, and filesystem can be unmounted and mounted again (all changes since the last commit will be lost). Add the missing check for new_ino so that all non-subvolumes must reside under the same parent subvolume. There's an exception allowing to exchange two subvolumes from any parents as the directory representing a subvolume is only a logical link and does not have any other structures related to the parent subvolume, unlike files, directories etc, that are always in the inode namespace of the parent subvolume. Fixes: cdd1fedf ("btrfs: add support for RENAME_EXCHANGE and RENAME_WHITEOUT") CC: stable@vger.kernel.org # 4.7+ Reviewed-by:
Nikolay Borisov <nborisov@suse.com> Signed-off-by:
NeilBrown <neilb@suse.de> Reviewed-by:
David Sterba <dsterba@suse.com> Signed-off-by:
-
Nicolas Saenz Julienne authored
[ Upstream commit 419dd626 ] The controller doesn't seem to pick-up on clock changes, so set the SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN flag to query the clock frequency directly from the clock. Fixes: f84e411c ("mmc: sdhci-iproc: Add support for emmc2 of the BCM2711") Signed-off-by:
Nicolas Saenz Julienne <nsaenz@kernel.org> Signed-off-by:
Stefan Wahren <stefan.wahren@i2se.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/1628334401-6577-6-git-send-email-stefan.wahren@i2se.com Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Nicolas Saenz Julienne authored
[ Upstream commit c9107dd0 ] There is a known bug on BCM2711's SDHCI core integration where the controller will hang when the difference between the core clock and the bus clock is too great. Specifically this can be reproduced under the following conditions: - No SD card plugged in, polling thread is running, probing cards at 100 kHz. - BCM2711's core clock configured at 500MHz or more. So set 200 kHz as the minimum clock frequency available for that board. For more information on the issue see this: https://lore.kernel.org/linux-mmc/20210322185816.27582-1-nsaenz@kernel.org/T/#m11f2783a09b581da6b8a15f302625b43a6ecdeca Fixes: f84e411c ("mmc: sdhci-iproc: Add support for emmc2 of the BCM2711") Signed-off-by:
-
Dmitry Osipenko authored
[ Upstream commit c3ddfe66 ] The current_opp is released only when whole OPP table is released, otherwise it's only marked as removed by dev_pm_opp_remove_table(). Functions like dev_pm_opp_put_clkname() and dev_pm_opp_put_supported_hw() are checking whether OPP table is empty and it's not if current_opp is set since it holds the refcount of OPP, this produces a noisy warning from these functions about busy OPP table. Remove the checks to fix it. Cc: stable@vger.kernel.org Fixes: 81c4d8a3 ("opp: Keep track of currently programmed OPP") Signed-off-by:
Dmitry Osipenko <digetx@gmail.com> Signed-off-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
-
Kristin Paget authored
[ Upstream commit da946920 ] The 2021-model XPS 15 appears to use the same 4-speakers-on-ALC289 audio setup as the Precision models, so requires the same quirk to enable woofer output. Tested on my own 9510. Signed-off-by:
Kristin Paget <kristin@tombom.co.uk> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/e1fc95c5-c10a-1f98-a5c2-dd6e336157e1@tombom.co.uk Signed-off-by:
-
Jens Axboe authored
[ Upstream commit 21f96522 ] If an SQPOLL based ring is newly created and an application issues an io_uring_enter(2) system call on it, then we can return a spurious -EOWNERDEAD error. This happens because there's nothing to submit, and if the caller doesn't specify any other action, the initial error assignment of -EOWNERDEAD never gets overwritten. This causes us to return it directly, even if it isn't valid. Move the error assignment into the actual failure case instead. Cc: stable@vger.kernel.org Fixes: d9d05217 ("io_uring: stop SQPOLL submit on creator's death") Reported-by:
Sherlock Holo <sherlockya@gmail.com> Link: https://github.com/axboe/liburing/issues/413 Signed-off-by:
-
Pavel Begunkov authored
[ Upstream commit fe7e3257 ] Fix a bunch of problems mostly found by checkpatch.pl Signed-off-by:
Pavel Begunkov <asml.silence@gmail.com> Link: https://lore.kernel.org/r/cfaf9a2f27b43934144fe9422a916bd327099f44.1624543113.git.asml.silence@gmail.com Signed-off-by:
-
Dongliang Mu authored
[ Upstream commit 50f05bd1 ] The error handling code in tpci200_register does not free interface_regs allocated by ioremap and the current version of error handling code is problematic. Fix this by refactoring the error handling code and free interface_regs when necessary. Fixes: 43986798 ("ipack: add error handling for ioremap_nocache") Cc: stable@vger.kernel.org Reported-by:
Dongliang Mu <mudongliangabcd@gmail.com> Signed-off-by:
-
Dongliang Mu authored
[ Upstream commit 57a16810 ] The function tpci200_register called by tpci200_install and tpci200_unregister called by tpci200_uninstall are in pair. However, tpci200_unregister has some cleanup operations not in the tpci200_register. So the error handling code of tpci200_pci_probe has many different double free issues. Fix this problem by moving those cleanup operations out of tpci200_unregister, into tpci200_pci_remove and reverting the previous commit 9272e5d0 ("ipack/carriers/tpci200: Fix a double free in tpci200_pci_probe"). Fixes: 9272e5d0 ("ipack/carriers/tpci200: Fix a double free in tpci200_pci_probe") Cc: stable@vger.kernel.org Reported-by:
-
Srinivas Kandagatla authored
[ Upstream commit d7777253 ] During suspend/resume NGD remote instance is power cycled along with remotely controlled bam dma engine. So Reset the dma configuration during this suspend resume path so that we are not dealing with any stale dma setup. Without this transactions timeout after first suspend resume path. Fixes: 917809e2 ("slimbus: ngd: Add qcom SLIMBus NGD driver") Cc: <stable@vger.kernel.org> Signed-off-by:
Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20210809082428.11236-5-srinivas.kandagatla@linaro.org Signed-off-by:
-
Srinivas Kandagatla authored
[ Upstream commit c0e38eaa ] For some reason we ended up using wrong device in some places for pm_runtime calls. Fix this so that NGG driver can do runtime pm correctly. Fixes: 917809e2 ("slimbus: ngd: Add qcom SLIMBus NGD driver") Cc: <stable@vger.kernel.org> Signed-off-by:
-
Srinivas Kandagatla authored
[ Upstream commit a263c1ff ] In some usecases transaction ids are dynamically allocated inside the controller driver after sending the messages which have generic acknowledge responses. So check for this before refcounting pm_runtime. Without this we would end up imbalancing runtime pm count by doing pm_runtime_put() in both slim_do_transfer() and slim_msg_response() for a single pm_runtime_get() in slim_do_transfer() Fixes: d3062a21 ("slimbus: messaging: add slim_alloc/free_txn_tid()") Cc: <stable@vger.kernel.org> Signed-off-by:
-
Srinivas Kandagatla authored
[ Upstream commit 9659281c ] As tid is unsigned its hard to figure out if the tid is valid or invalid. So Start the transaction ids from 1 instead of zero so that we could differentiate between a valid tid and invalid tids This is useful in cases where controller would add a tid for controller specific transfers. Fixes: d3062a21 ("slimbus: messaging: add slim_alloc/free_txn_tid()") Cc: <stable@vger.kernel.org> Signed-off-by:
-
Steven Rostedt (VMware) authored
[ Upstream commit 5acce0bf ] The following commands: # echo 'read_max u64 size;' > synthetic_events # echo 'hist:keys=common_pid:count=count:onmax($count).trace(read_max,count)' > events/syscalls/sys_enter_read/trigger Causes: BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP CPU: 4 PID: 1763 Comm: bash Not tainted 5.14.0-rc2-test+ #155 Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v03.03 07/14/2016 RIP: 0010:strcmp+0xc/0x20 Code: 75 f7 31 c0 0f b6 0c 06 88 0c 02 48 83 c0 01 84 c9 75 f1 4c 89 c0 c3 0f 1f 80 00 00 00 00 31 c0 eb 08 48 83 c0 01 84 d2 74 0f <0f> b6 14 07 3a 14 06 74 ef 19 c0 83 c8 01 c3 31 c0 c3 66 90 48 89 RSP: 0018:ffffb5fdc0963ca8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffffffb3a4e040 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff9714c0d0b640 RDI: 0000000000000000 RBP: 0000000000000000 R08: 00000022986b7cde R09: ffffffffb3a4dff8 R10: 0000000000000000 R11: 0000000000000000 R12: ffff9714c50603c8 R13: 0000000000000000 R14: ffff97143fdf9e48 R15: ffff9714c01a2210 FS: 00007f1fa6785740(0000) GS:ffff9714da400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000002d863004 CR4: 00000000001706e0 Call Trace: __find_event_file+0x4e/0x80 action_create+0x6b7/0xeb0 ? kstrdup+0x44/0x60 event_hist_trigger_func+0x1a07/0x2130 trigger_process_regex+0xbd/0x110 event_trigger_write+0x71/0xd0 vfs_write+0xe9/0x310 ksys_write+0x68/0xe0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f1fa6879e87 The problem was the "trace(read_max,count)" where the "count" should be "$count" as "onmax()" only handles variables (although it really should be able to figure out that "count" is a field of sys_enter_read). But there's a path that does not find the variable and ends up passing a NULL for the event, which ends up getting passed to "strcmp()". Add a check for NULL to return and error on the command with: # cat error_log hist:syscalls:sys_enter_read: error: Couldn't create or find variable Command: hist:keys=common_pid:count=count:onmax($count).trace(read_max,count) ^ Link: https://lkml.kernel.org/r/20210808003011.4037f8d0@oasis.local.home Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: stable@vger.kernel.org Fixes: 50450603 tracing: Add 'onmax' hist trigger action support Reviewed-by:
Tom Zanussi <zanussi@kernel.org> Signed-off-by:
-
Lukas Bulwahn authored
[ Upstream commit 12f9951d ] Commit 2860cd8a ("livepatch: Use the default ftrace_ops instead of REGS when ARGS is available") intends to enable config LIVEPATCH when ftrace with ARGS is available. However, the chain of configs to enable LIVEPATCH is incomplete, as HAVE_DYNAMIC_FTRACE_WITH_ARGS is available, but the definition of DYNAMIC_FTRACE_WITH_ARGS, combining DYNAMIC_FTRACE and HAVE_DYNAMIC_FTRACE_WITH_ARGS, needed to enable LIVEPATCH, is missing in the commit. Fortunately, ./scripts/checkkconfigsymbols.py detects this and warns: DYNAMIC_FTRACE_WITH_ARGS Referencing files: kernel/livepatch/Kconfig So, define the config DYNAMIC_FTRACE_WITH_ARGS analogously to the already existing similar configs, DYNAMIC_FTRACE_WITH_REGS and DYNAMIC_FTRACE_WITH_DIRECT_CALLS, in ./kernel/trace/Kconfig to connect the chain of configs. Link: https://lore.kernel.org/kernel-janitors/CAKXUXMwT2zS9fgyQHKUUiqo8ynZBdx2UEUu1WnV_q0OCmknqhw@mail.gmail.com/ Link: https://lkml.kernel.org/r/20210806195027.16808-1-lukas.bulwahn@gmail.com Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Jiri Kosina <jikos@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Miroslav Benes <mbenes@suse.cz> Cc: stable@vger.kernel.org Fixes: 2860cd8a ("livepatch: Use the default ftrace_ops instead of REGS when ARGS is available") Signed-off-by:
Lukas Bulwahn <lukas.bulwahn@gmail.com> Signed-off-by:
-
Jaroslav Kysela authored
[ Upstream commit a2befe93 ] The original code in the cap_put_caller() function does not handle correctly the positive values returned from the passed function for multiple iterations. It means that the change notifications may be lost. Fixes: 352f7f91 ("ALSA: hda - Merge Realtek parser code to generic parser") BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=213851 Cc: <stable@kernel.org> Signed-off-by:
Jaroslav Kysela <perex@perex.cz> Link: https://lore.kernel.org/r/20210811161441.1325250-1-perex@perex.cz Signed-off-by:
-
Elliot Berman authored
[ Upstream commit 14c4c8e4 ] If rcu_read_lock_sched tracing is enabled, the tracing subsystem can perform a jump which needs to be checked by CFI. For example, stm_ftrace source is enabled as a module and hooks into enabled ftrace events. This can cause an recursive loop where find_shadow_check_fn -> rcu_read_lock_sched -> (call to stm_ftrace generates cfi slowpath) -> find_shadow_check_fn -> rcu_read_lock_sched -> ... To avoid the recursion, either the ftrace codes needs to be marked with __no_cfi or CFI should not trace. Use the "_notrace" in CFI to avoid tracing so that CFI can guard ftrace. Signed-off-by:
Elliot Berman <quic_eberman@quicinc.com> Reviewed-by:
Sami Tolvanen <samitolvanen@google.com> Cc: stable@vger.kernel.org Fixes: cf68fffb ("add support for Clang CFI") Signed-off-by:
Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20210811155914.19550-1-quic_eberman@quicinc.com Signed-off-by:
-
Andrew Delgadillo authored
[ Upstream commit 017f5fb9 ] commit a5b8ca97 ("arm64: do not descend to vdso directories twice") changes the cleaning behavior of arm64's vdso files, in that vdso.lds, vdso.so, and vdso.so.dbg are not removed upon a 'make clean/mrproper': $ make defconfig ARCH=arm64 $ make ARCH=arm64 $ make mrproper ARCH=arm64 $ git clean -nxdf Would remove arch/arm64/kernel/vdso/vdso.lds Would remove arch/arm64/kernel/vdso/vdso.so Would remove arch/arm64/kernel/vdso/vdso.so.dbg To remedy this, manually descend into arch/arm64/kernel/vdso upon cleaning. After this commit: $ make defconfig ARCH=arm64 $ make ARCH=arm64 $ make mrproper ARCH=arm64 $ git clean -nxdf <empty> Similar results are obtained for the vdso32 equivalent. Signed-off-by:
Andrew Delgadillo <adelg@google.com> Cc: stable@vger.kernel.org Fixes: a5b8ca97 ("arm64: do not descend to vdso directories twice") Link: https://lore.kernel.org/r/20210810231755.1743524-1-adelg@google.com Signed-off-by:
Will Deacon <will@kernel.org> Signed-off-by:
-
Bjorn Andersson authored
[ Upstream commit 9711759a ] As GDSCs are registered and found to be already enabled gdsc_init() ensures that 1) the kernel state matches the hardware state, and 2) votable GDSCs are properly enabled from this master as well. But as the (optional) supply regulator is enabled deep into gdsc_toggle_logic(), which is only executed for votable GDSCs, the kernel's state of the regulator might not match the hardware. The regulator might be automatically turned off if no other users are present or the next call to gdsc_disable() would cause an unbalanced regulator_disable(). Given that the votable case deals with an already enabled GDSC, most of gdsc_enable() and gdsc_toggle_logic() can be skipped. Reduce it to just clearing the SW_COLLAPSE_MASK and enabling hardware control to simply call regulator_enable() in both cases. The enablement of hardware control seems to be an independent property from the GDSC being enabled, so this is moved outside that conditional segment. Lastly, as the propagation of ALWAYS_ON to GENPD_FLAG_ALWAYS_ON needs to happen regardless of the initial state this is grouped together with the other sc->pd updates at the end of the function. Cc: stable@vger.kernel.org Fixes: 37416e55 ("clk: qcom: gdsc: Handle GDSC regulator supplies") Signed-off-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20210721224056.3035016-1-bjorn.andersson@linaro.org [sboyd@kernel.org: Rephrase commit text] Signed-off-by:
Stephen Boyd <sboyd@kernel.org> Signed-off-by:
-
Dong Aisheng authored
[ Upstream commit 283f1b9a ] The earlycon depends on the bootloader setup UART clocks being retained. There're actually two uart clocks (ipg, per) on MX6QDL, but the 'Fixes' commit change to register only one which means another clock may be disabled during booting phase and result in the earlycon unwork. Cc: stable@vger.kernel.org # v5.10+ Fixes: 379c9a24 ("clk: imx: Fix reparenting of UARTs not associated with stdout") Signed-off-by:
Dong Aisheng <aisheng.dong@nxp.com> Link: https://lore.kernel.org/r/20210702085438.1988087-1-aisheng.dong@nxp.com Reviewed-by:
Abel Vesa <abel.vesa@nxp.com> Signed-off-by:
-
Shaik Sajida Bhanu authored
[ Upstream commit 67b13f3e ] Whenever SDHC run at clock rate 50MHZ or below, the hardware data timeout value will be 21.47secs, which is approx. 22secs and we have a current software timeout value as 10secs. We have to set software timeout value more than the hardware data timeout value to avioid seeing the below register dumps. [ 332.953670] mmc2: Timeout waiting for hardware interrupt. [ 332.959608] mmc2: sdhci: ============ SDHCI REGISTER DUMP =========== [ 332.966450] mmc2: sdhci: Sys addr: 0x00000000 | Version: 0x00007202 [ 332.973256] mmc2: sdhci: Blk size: 0x00000200 | Blk cnt: 0x00000001 [ 332.980054] mmc2: sdhci: Argument: 0x00000000 | Trn mode: 0x00000027 [ 332.986864] mmc2: sdhci: Present: 0x01f801f6 | Host ctl: 0x0000001f [ 332.993671] mmc2: sdhci: Power: 0x00000001 | Blk gap: 0x00000000 [ 333.000583] mmc2: sdhci: Wake-up: 0x00000000 | Clock: 0x00000007 [ 333.007386] mmc2: sdhci: Timeout: 0x0000000e | Int stat: 0x00000000 [ 333.014182] mmc2: sdhci: Int enab: 0x03ff100b | Sig enab: 0x03ff100b [ 333.020976] mmc2: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000000 [ 333.027771] mmc2: sdhci: Caps: 0x322dc8b2 | Caps_1: 0x0000808f [ 333.034561] mmc2: sdhci: Cmd: 0x0000183a | Max curr: 0x00000000 [ 333.041359] mmc2: sdhci: Resp[0]: 0x00000900 | Resp[1]: 0x00000000 [ 333.048157] mmc2: sdhci: Resp[2]: 0x00000000 | Resp[3]: 0x00000000 [ 333.054945] mmc2: sdhci: Host ctl2: 0x00000000 [ 333.059657] mmc2: sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0x0000000ffffff218 [ 333.067178] mmc2: sdhci_msm: ----------- VENDOR REGISTER DUMP ----------- [ 333.074343] mmc2: sdhci_msm: DLL sts: 0x00000000 | DLL cfg: 0x6000642c | DLL cfg2: 0x0020a000 [ 333.083417] mmc2: sdhci_msm: DLL cfg3: 0x00000000 | DLL usr ctl: 0x00000000 | DDR cfg: 0x80040873 [ 333.092850] mmc2: sdhci_msm: Vndr func: 0x00008a9c | Vndr func2 : 0xf88218a8 Vndr func3: 0x02626040 [ 333.102371] mmc2: sdhci: ============================================ So, set software timeout value more than hardware timeout value. Signed-off-by:
Shaik Sajida Bhanu <sbhanu@codeaurora.org> Acked-by:
Adrian Hunter <adrian.hunter@intel.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/1626435974-14462-1-git-send-email-sbhanu@codeaurora.org Signed-off-by:
-
