Select Git revision
Search by author
- Any Author
- authors
-
Aaron Kim akim
-
Aaron Kloc akloc
-
Aaron Nabil aaronna
-
Abel Fang abel_fang
-
Abhijit Adsule adsule
-
Abhishek Kar abhiskar
-
Adam Ford aford
-
Adam Snyder adsnyder
-
Adam Yeh adam.yeh
-
Adigarla Devi adigarla.devi
-
aditya gunda agunda
-
Adrien Martinez adrien.martinez
-
Agathon Jung agathon.jung
-
Ahmed Ibrahim ahmedibrahim
-
Ahming Chrn ahmingchen
-
Aiden Chang achang
-
Aiden Li liang10
-
Akash Nair akash_thulasidharan
-
Akash Ranjan akash_ranjan
-
Akshay Mahajan akshay_mahajan
- Oct 12, 2022
-
-
Oleksandr Mazur authored
[ Upstream commit 9124dbcc ] Aldrin2 (98DX8525) is a Marvell Prestera PP, with 100G support. Signed-off-by:
Oleksandr Mazur <oleksandr.mazur@plvision.eu> V2: - retarget to net tree instead of net-next; - fix missed colon in patch subject ('net marvell' vs 'net: mavell'); Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Haimin Zhang authored
[ Upstream commit 94160108 ] There is uninit value bug in dgram_sendmsg function in net/ieee802154/socket.c when the length of valid data pointed by the msg->msg_name isn't verified. We introducing a helper function ieee802154_sockaddr_check_size to check namelen. First we check there is addr_type in ieee802154_addr_sa. Then, we check namelen according to addr_type. Also fixed in raw_bind, dgram_bind, dgram_connect. Signed-off-by:
Haimin Zhang <tcs_kernel@tencent.com> Signed-off-by:
-
Letu Ren authored
[ Upstream commit fbfe96869b782364caebae0445763969ddb6ea67 ] In __qedf_probe(), if qedf->cdev is NULL which means qed_ops->common->probe() failed, then the program will goto label err1, and scsi_host_put() will free lport->host pointer. Because the memory qedf points to is allocated by libfc_host_alloc(), it will be freed by scsi_host_put(). However, the if statement below label err0 only checks whether qedf is NULL but doesn't check whether the memory has been freed. So a UAF bug can occur. There are two ways to reach the statements below err0. The first one is described as before, "qedf" should be set to NULL. The second one is goto "err0" directly. In the latter scenario qedf hasn't been changed and it has the initial value NULL. As a result the if statement is not reachable in any situation. The KASAN logs are as follows: [ 2.312969] BUG: KASAN: use-after-free in __qedf_probe+0x5dcf/0x6bc0 [ 2.312969] [ 2.312969] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 [ 2.312969] Call Trace: [ 2.312969] dump_stack_lvl+0x59/0x7b [ 2.312969] print_address_description+0x7c/0x3b0 [ 2.312969] ? __qedf_probe+0x5dcf/0x6bc0 [ 2.312969] __kasan_report+0x160/0x1c0 [ 2.312969] ? __qedf_probe+0x5dcf/0x6bc0 [ 2.312969] kasan_report+0x4b/0x70 [ 2.312969] ? kobject_put+0x25d/0x290 [ 2.312969] kasan_check_range+0x2ca/0x310 [ 2.312969] __qedf_probe+0x5dcf/0x6bc0 [ 2.312969] ? selinux_kernfs_init_security+0xdc/0x5f0 [ 2.312969] ? trace_rpm_return_int_rcuidle+0x18/0x120 [ 2.312969] ? rpm_resume+0xa5c/0x16e0 [ 2.312969] ? qedf_get_generic_tlv_data+0x160/0x160 [ 2.312969] local_pci_probe+0x13c/0x1f0 [ 2.312969] pci_device_probe+0x37e/0x6c0 Link: https://lore.kernel.org/r/20211112120641.16073-1-fantasquex@gmail.com Reported-by:
Zheyu Ma <zheyuma97@gmail.com> Acked-by:
Saurav Kashyap <skashyap@marvell.com> Co-developed-by:
Wende Tan <twd2.me@gmail.com> Signed-off-by:
Letu Ren <fantasquex@gmail.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Sergei Antonov authored
[ Upstream commit 02181e68 ] Driver moxart-mmc.c has .compatible = "moxa,moxart-mmc". But moxart .dts/.dtsi and the documentation file moxa,moxart-dma.txt contain compatible = "moxa,moxart-sdhci". Change moxart .dts/.dtsi files and moxa,moxart-dma.txt to match the driver. Replace 'sdhci' with 'mmc' in names too, since SDHCI is a different controller from FTSDC010. Suggested-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Sergei Antonov <saproj@gmail.com> Cc: Jonas Jensen <jonas.jensen@gmail.com> Link: https://lore.kernel.org/r/20220907175341.1477383-1-saproj@gmail.com ' Signed-off-by:
-
Swati Agarwal authored
[ Upstream commit 8f2b6bc7 ] The driver does not handle the failure case while calling dma_set_mask_and_coherent API. In case of failure, capture the return value of API and then report an error. Addresses-coverity: Unchecked return value (CHECKED_RETURN) Signed-off-by:
Swati Agarwal <swati.agarwal@xilinx.com> Reviewed-by:
Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com> Link: https://lore.kernel.org/r/20220817061125.4720-4-swati.agarwal@xilinx.com Signed-off-by:
Vinod Koul <vkoul@kernel.org> Signed-off-by:
-
Swati Agarwal authored
[ Upstream commit 462bce79 ] Free the allocated resources for missing xlnx,num-fstores property. Signed-off-by:
-
Swati Agarwal authored
[ Upstream commit 91df7751 ] Add missing cleanup in devm_platform_ioremap_resource(). When probe fails remove dma channel resources and disable clocks in accordance with the order of resources allocated . Signed-off-by:
-
Cristian Marussi authored
[ Upstream commit dea796fc ] Currently, when removing the SCMI PM driver not all the resources registered with genpd subsystem are properly de-registered. As a side effect of this after a driver unload/load cycle you get a splat with a few warnings like this: | debugfs: Directory 'BIG_CPU0' with parent 'pm_genpd' already present! | debugfs: Directory 'BIG_CPU1' with parent 'pm_genpd' already present! | debugfs: Directory 'LITTLE_CPU0' with parent 'pm_genpd' already present! | debugfs: Directory 'LITTLE_CPU1' with parent 'pm_genpd' already present! | debugfs: Directory 'LITTLE_CPU2' with parent 'pm_genpd' already present! | debugfs: Directory 'LITTLE_CPU3' with parent 'pm_genpd' already present! | debugfs: Directory 'BIG_SSTOP' with parent 'pm_genpd' already present! | debugfs: Directory 'LITTLE_SSTOP' with parent 'pm_genpd' already present! | debugfs: Directory 'DBGSYS' with parent 'pm_genpd' already present! | debugfs: Directory 'GPUTOP' with parent 'pm_genpd' already present! Add a proper scmi_pm_domain_remove callback to the driver in order to take care of all the needed cleanups not handled by devres framework. Link: https://lore.kernel.org/r/20220817172731.1185305-7-cristian.marussi@arm.com Signed-off-by:
Cristian Marussi <cristian.marussi@arm.com> Signed-off-by:
Sudeep Holla <sudeep.holla@arm.com> Signed-off-by:
-
Cristian Marussi authored
[ Upstream commit 76f89c95 ] Accessing sensor domains descriptors by the index upon the SCMI drivers requests through the SCMI sensor operations interface can potentially lead to out-of-bound violations if the SCMI driver misbehave. Add an internal consistency check before any such domains descriptors accesses. Link: https://lore.kernel.org/r/20220817172731.1185305-4-cristian.marussi@arm.com Signed-off-by:
-
Cristian Marussi authored
[ Upstream commit 1ecb7d27 ] SCMI protocols abstract and expose a number of protocol specific resources like clocks, sensors and so on. Information about such specific domain resources are generally exposed via an `info_get` protocol operation. Improve the sanity check on these operations where needed. Link: https://lore.kernel.org/r/20220817172731.1185305-3-cristian.marussi@arm.com Signed-off-by:
-
Dongliang Mu authored
commit 2e488f13 upstream. In alloc_inode, inode_init_always() could return -ENOMEM if security_inode_alloc() fails, which causes inode->i_private uninitialized. Then nilfs_is_metadata_file_inode() returns true and nilfs_free_inode() wrongly calls nilfs_mdt_destroy(), which frees the uninitialized inode->i_private and leads to crashes(e.g., UAF/GPF). Fix this by moving security_inode_alloc just prior to this_cpu_inc(nr_inodes) Link: https://lkml.kernel.org/r/CAFcO6XOcf1Jj2SeGt=jJV59wmhESeSKpfR0omdFRq+J9nD1vfQ@mail.gmail.com Reported-by:
butt3rflyh4ck <butterflyhuangxx@gmail.com> Reported-by:
Hao Sun <sunhao.th@gmail.com> Reported-by:
Jiacheng Xu <stitch@zju.edu.cn> Reviewed-by:
Christian Brauner (Microsoft) <brauner@kernel.org> Signed-off-by:
Dongliang Mu <mudongliangabcd@gmail.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: stable@vger.kernel.org Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Yang Shi authored
commit bedf0341 upstream. The IPI broadcast is used to serialize against fast-GUP, but fast-GUP will move to use RCU instead of disabling local interrupts in fast-GUP. Using an IPI is the old-styled way of serializing against fast-GUP although it still works as expected now. And fast-GUP now fixed the potential race with THP collapse by checking whether PMD is changed or not. So IPI broadcast in radix pmd collapse flush is not necessary anymore. But it is still needed for hash TLB. Link: https://lkml.kernel.org/r/20220907180144.555485-2-shy828301@gmail.com Suggested-by:
Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> Signed-off-by:
Yang Shi <shy828301@gmail.com> Acked-by:
David Hildenbrand <david@redhat.com> Acked-by:
Peter Xu <peterx@redhat.com> Cc: Christophe Leroy <christophe.leroy@csgroup.eu> Cc: Hugh Dickins <hughd@google.com> Cc: Jason Gunthorpe <jgg@nvidia.com> Cc: John Hubbard <jhubbard@nvidia.com> Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Nicholas Piggin <npiggin@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Yang Shi authored
commit 70cbc3cc upstream. Since general RCU GUP fast was introduced in commit 2667f50e ("mm: introduce a general RCU get_user_pages_fast()"), a TLB flush is no longer sufficient to handle concurrent GUP-fast in all cases, it only handles traditional IPI-based GUP-fast correctly. On architectures that send an IPI broadcast on TLB flush, it works as expected. But on the architectures that do not use IPI to broadcast TLB flush, it may have the below race: CPU A CPU B THP collapse fast GUP gup_pmd_range() <-- see valid pmd gup_pte_range() <-- work on pte pmdp_collapse_flush() <-- clear pmd and flush __collapse_huge_page_isolate() check page pinned <-- before GUP bump refcount pin the page check PTE <-- no change __collapse_huge_page_copy() copy data to huge page ptep_clear() install huge pmd for the huge page return the stale page discard the stale page The race can be fixed by checking whether PMD is changed or not after taking the page pin in fast GUP, just like what it does for PTE. If the PMD is changed it means there may be parallel THP collapse, so GUP should back off. Also update the stale comment about serializing against fast GUP in khugepaged. Link: https://lkml.kernel.org/r/20220907180144.555485-1-shy828301@gmail.com Fixes: 2667f50e ("mm: introduce a general RCU get_user_pages_fast()") Acked-by:
John Hubbard <jhubbard@nvidia.com> Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> Cc: Hugh Dickins <hughd@google.com> Cc: Jason Gunthorpe <jgg@nvidia.com> Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Nicholas Piggin <npiggin@gmail.com> Cc: Christophe Leroy <christophe.leroy@csgroup.eu> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Jalal Mostafa authored
commit 60240bc2 upstream. The flag for need_wakeup is not set for xsks with `XDP_SHARED_UMEM` flag and of different queue ids and/or devices. They should inherit the flag from the first socket buffer pool since no flags can be specified once `XDP_SHARED_UMEM` is specified. Fixes: b5aea28d ("xsk: Add shared umem support between queue ids") Signed-off-by:
Jalal Mostafa <jalal.a.mostapha@gmail.com> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Acked-by:
Magnus Karlsson <magnus.karlsson@intel.com> Link: https://lore.kernel.org/bpf/20220921135701.10199-1-jalal.a.mostapha@gmail.com Signed-off-by:
-
Shuah Khan authored
commit 8bfdfa0d upstream. Update mediator information in the CoC interpretation document. Signed-off-by:
Shuah Khan <skhan@linuxfoundation.org> Link: https://lore.kernel.org/r/20220901212319.56644-1-skhan@linuxfoundation.org Cc: stable@vger.kernel.org Signed-off-by:
Jonathan Corbet <corbet@lwn.net> Signed-off-by:
-
Sami Tolvanen authored
commit 21206351 upstream. We enable -Wcast-function-type globally in the kernel to warn about mismatching types in function pointer casts. Compilers currently warn only about ABI incompability with this flag, but Clang 16 will enable a stricter version of the check by default that checks for an exact type match. This will be very noisy in the kernel, so disable -Wcast-function-type-strict without W=1 until the new warnings have been addressed. Cc: stable@vger.kernel.org Link: https://reviews.llvm.org/D134831 Link: https://github.com/ClangBuiltLinux/linux/issues/1724 Suggested-by:
Nathan Chancellor <nathan@kernel.org> Signed-off-by:
Sami Tolvanen <samitolvanen@google.com> Signed-off-by:
Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20220930203310.4010564-1-samitolvanen@google.com Signed-off-by:
-
- Oct 05, 2022
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20221003070721.971297651@linuxfoundation.org Tested-by:
Jon Hunter <jonathanh@nvidia.com> Tested-by:
Ron Economos <re@w6rz.net> Tested-by:
Slade Watkins <srw@sladewatkins.net> Tested-by:
Bagas Sanjaya <bagasdotme@gmail.com> Tested-by:
Sudip Mukherjee <sudip.mukherjee@codethink.co.uk> Tested-by:
Kelsey Steele <kelseysteele@linux.microsoft.com> Signed-off-by:
-
Chris Wilson authored
commit d119888b upstream. i915_perf assumes that it can use the i915_gem_context reference to protect its i915->gem.contexts.list iteration. However, this requires that we do not remove the context from the list until after we drop the final reference and release the struct. If, as currently, we remove the context from the list during context_close(), the link.next pointer may be poisoned while we are holding the context reference and cause a GPF: [ 4070.573157] i915 0000:00:02.0: [drm:i915_perf_open_ioctl [i915]] filtering on ctx_id=0x1fffff ctx_id_mask=0x1fffff [ 4070.574881] general protection fault, probably for non-canonical address 0xdead000000000100: 0000 [#1] PREEMPT SMP [ 4070.574897] CPU: 1 PID: 284392 Comm: amd_performance Tainted: G E 5.17.9 #180 [ 4070.574903] Hardware name: Intel Corporation NUC7i5BNK/NUC7i5BNB, BIOS BNKBL357.86A.0052.2017.0918.1346 09/18/2017 [ 4070.574907] RIP: 0010:oa_configure_all_contexts.isra.0+0x222/0x350 [i915] [ 4070.574982] Code: 08 e8 32 6e 10 e1 4d 8b 6d 50 b8 ff ff ff ff 49 83 ed 50 f0 41 0f c1 04 24 83 f8 01 0f 84 e3 00 00 00 85 c0 0f 8e fa 00 00 00 <49> 8b 45 50 48 8d 70 b0 49 8d 45 50 48 39 44 24 10 0f 85 34 fe ff [ 4070.574990] RSP: 0018:ffffc90002077b78 EFLAGS: 00010202 [ 4070.574995] RAX: 0000000000000002 RBX: 0000000000000002 RCX: 0000000000000000 [ 4070.575000] RDX: 0000000000000001 RSI: ffffc90002077b20 RDI: ffff88810ddc7c68 [ 4070.575004] RBP: 0000000000000001 R08: ffff888103242648 R09: fffffffffffffffc [ 4070.575008] R10: ffffffff82c50bc0 R11: 0000000000025c80 R12: ffff888101bf1860 [ 4070.575012] R13: dead0000000000b0 R14: ffffc90002077c04 R15: ffff88810be5cabc [ 4070.575016] FS: 00007f1ed50c0780(0000) GS:ffff88885ec80000(0000) knlGS:0000000000000000 [ 4070.575021] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 4070.575025] CR2: 00007f1ed5590280 CR3: 000000010ef6f005 CR4: 00000000003706e0 [ 4070.575029] Call Trace: [ 4070.575033] <TASK> [ 4070.575037] lrc_configure_all_contexts+0x13e/0x150 [i915] [ 4070.575103] gen8_enable_metric_set+0x4d/0x90 [i915] [ 4070.575164] i915_perf_open_ioctl+0xbc0/0x1500 [i915] [ 4070.575224] ? asm_common_interrupt+0x1e/0x40 [ 4070.575232] ? i915_oa_init_reg_state+0x110/0x110 [i915] [ 4070.575290] drm_ioctl_kernel+0x85/0x110 [ 4070.575296] ? update_load_avg+0x5f/0x5e0 [ 4070.575302] drm_ioctl+0x1d3/0x370 [ 4070.575307] ? i915_oa_init_reg_state+0x110/0x110 [i915] [ 4070.575382] ? gen8_gt_irq_handler+0x46/0x130 [i915] [ 4070.575445] __x64_sys_ioctl+0x3c4/0x8d0 [ 4070.575451] ? __do_softirq+0xaa/0x1d2 [ 4070.575456] do_syscall_64+0x35/0x80 [ 4070.575461] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 4070.575467] RIP: 0033:0x7f1ed5c10397 [ 4070.575471] Code: 3c 1c e8 1c ff ff ff 85 c0 79 87 49 c7 c4 ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a9 da 0d 00 f7 d8 64 89 01 48 [ 4070.575478] RSP: 002b:00007ffd65c8d7a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 4070.575484] RAX: ffffffffffffffda RBX: 0000000000000006 RCX: 00007f1ed5c10397 [ 4070.575488] RDX: 00007ffd65c8d7c0 RSI: 0000000040106476 RDI: 0000000000000006 [ 4070.575492] RBP: 00005620972f9c60 R08: 000000000000000a R09: 0000000000000005 [ 4070.575496] R10: 000000000000000d R11: 0000000000000246 R12: 000000000000000a [ 4070.575500] R13: 000000000000000d R14: 0000000000000000 R15: 00007ffd65c8d7c0 [ 4070.575505] </TASK> [ 4070.575507] Modules linked in: nls_ascii(E) nls_cp437(E) vfat(E) fat(E) i915(E) x86_pkg_temp_thermal(E) intel_powerclamp(E) crct10dif_pclmul(E) crc32_pclmul(E) crc32c_intel(E) aesni_intel(E) crypto_simd(E) intel_gtt(E) cryptd(E) ttm(E) rapl(E) intel_cstate(E) drm_kms_helper(E) cfbfillrect(E) syscopyarea(E) cfbimgblt(E) intel_uncore(E) sysfillrect(E) mei_me(E) sysimgblt(E) i2c_i801(E) fb_sys_fops(E) mei(E) intel_pch_thermal(E) i2c_smbus(E) cfbcopyarea(E) video(E) button(E) efivarfs(E) autofs4(E) [ 4070.575549] ---[ end trace 0000000000000000 ]--- v3: fix incorrect syntax of spin_lock() replacing spin_lock_irqsave() v2: irqsave not required in a worker, neither conversion to irq safe elsewhere (Tvrtko), - perf: it's safe to call gen8_configure_context() even if context has been closed, no need to check, - drop unrelated cleanup (Andi, Tvrtko) Reported-by:
Mark Janes <mark.janes@intel.com> Closes: https://gitlab.freedesktop.org/drm/intel/issues/6222 References: a4e7ccda ("drm/i915: Move context management under GEM") Fixes: f8246cf4 ("drm/i915/gem: Drop free_work for GEM contexts") Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by:
Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: <stable@vger.kernel.org> # v5.12+ Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> [janusz: backport] Signed-off-by:
-
Nadav Amit authored
commit efd608fa upstream. I encountered some occasional crashes of poke_int3_handler() when kprobes are set, while accessing desc->vec. The text poke mechanism claims to have an RCU-like behavior, but it does not appear that there is any quiescent state to ensure that nobody holds reference to desc. As a result, the following race appears to be possible, which can lead to memory corruption. CPU0 CPU1 ---- ---- text_poke_bp_batch() -> smp_store_release(&bp_desc, &desc) [ notice that desc is on the stack ] poke_int3_handler() [ int3 might be kprobe's so sync events are do not help ] -> try_get_desc(descp=&bp_desc) desc = __READ_ONCE(bp_desc) if (!desc) [false, success] WRITE_ONCE(bp_desc, NULL); atomic_dec_and_test(&desc.refs) [ success, desc space on the stack is being reused and might have non-zero value. ] arch_atomic_inc_not_zero(&desc->refs) [ might succeed since desc points to stack memory that was freed and might be reused. ] Fix this issue with small backportable patch. Instead of trying to make RCU-like behavior for bp_desc, just eliminate the unnecessary level of indirection of bp_desc, and hold the whole descriptor as a global. Anyhow, there is only a single descriptor at any given moment. Fixes: 1f676247 ("x86/alternatives: Implement a better poke_int3_handler() completion scheme") Signed-off-by:
Nadav Amit <namit@vmware.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: stable@kernel.org Link: https://lkml.kernel.org/r/20220920224743.3089-1-namit@vmware.com Signed-off-by:
-
Jim Mattson authored
[ Upstream commit aae2e722 ] The only thing reported by CPUID.9 is the value of IA32_PLATFORM_DCA_CAP[31:0] in EAX. This MSR doesn't even exist in the guest, since CPUID.1:ECX.DCA[bit 18] is clear in the guest. Clear CPUID.9 in KVM_GET_SUPPORTED_CPUID. Fixes: 24c82e57 ("KVM: Sanitize cpuid") Signed-off-by:
Jim Mattson <jmattson@google.com> Message-Id: <20220922231854.249383-1-jmattson@google.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
-
Florian Fainelli authored
[ Upstream commit 1b24a132 ] After commit 31fd9b79 ("ARM: dts: BCM5301X: update CRU block description") a warning from clk-iproc-pll.c was generated due to a duplicate PLL name as well as the console stopped working. Upon closer inspection it became clear that iproc_pll_clk_setup() used the Device Tree node unit name as an unique identifier as well as a parent name to parent all clocks under the PLL. BCM5301X was the first platform on which that got noticed because of the DT node unit name renaming but the same assumptions hold true for any user of the iproc_pll_clk_setup() function. The first 'clock-output-names' property is always guaranteed to be unique as well as providing the actual desired PLL clock name, so we utilize that to register the PLL and as a parent name of all children clock. Fixes: 5fe225c1 ("clk: iproc: add initial common clock support") Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Acked-by:
Rafał Miłecki <rafal@milecki.pl> Link: https://lore.kernel.org/r/20220905161504.1526-1-f.fainelli@gmail.com Signed-off-by:
Stephen Boyd <sboyd@kernel.org> Signed-off-by:
-
Han Xu authored
[ Upstream commit b1ff1bfe ] There is no dedicate parent clock for QSPI so SET_RATE_PARENT flag should not be used. For instance, the default parent clock for QSPI is pll2_bus, which is also the parent clock for quite a few modules, such as MMDC, once GPMI NAND set clock rate for EDO5 mode can cause system hang due to pll2_bus rate changed. Fixes: f1541e15 ("clk: imx6sx: Switch to clk_hw based API") Signed-off-by:
Han Xu <han.xu@nxp.com> Link: https://lore.kernel.org/r/20220915150959.3646702-1-han.xu@nxp.com Tested-by:
Fabio Estevam <festevam@denx.de> Reviewed-by:
Abel Vesa <abel.vesa@linaro.org> Signed-off-by:
-
Stefan Roesch authored
[ Upstream commit 1a91794c ] This splits of the setup part of the function setxattr in its own dedicated function called setxattr_copy. In addition it also exposes a new function called do_setxattr for making the setxattr call. This makes it possible to call these two functions from io_uring in the processing of an xattr request. Signed-off-by:
Stefan Roesch <shr@fb.com> Acked-by:
Christian Brauner <christian.brauner@ubuntu.com> Link: https://lore.kernel.org/r/20220323154420.3301504-2-shr@fb.com Signed-off-by:
Jens Axboe <axboe@kernel.dk> Stable-dep-of: 06bbaa6d ("[coredump] don't use __kernel_write() on kmap_local_page()") Signed-off-by:
-
Angus Chen authored
[ Upstream commit db5db1a0 ] The q_pair_id to address a queue pair in the lm bar should be calculated by queue_id / 2 rather than queue_id / nr_vring. Fixes: 2ddae773 ("vDPA/ifcvf: detect and use the onboard number of queues directly") Signed-off-by:
Angus Chen <angus.chen@jaguarmicro.com> Reviewed-by:
Jason Wang <jasowang@redhat.com> Reviewed-by:
Michael S. Tsirkin <mst@redhat.com> Acked-by:
Zhu Lingshan <lingshan.zhu@intel.com> Message-Id: <20220923091013.191-1-angus.chen@jaguarmicro.com> Signed-off-by:
-
Wang Yufen authored
[ Upstream commit bc7a3198 ] The socket 2 bind the addr in use, bind should fail with EADDRINUSE. So if bind success or errno != EADDRINUSE, testcase should be failed. Fixes: 3ca8e402 ("soreuseport: BPF selection functional test") Signed-off-by:
Wang Yufen <wangyufen@huawei.com> Link: https://lore.kernel.org/r/1663916557-10730-1-git-send-email-wangyufen@huawei.com Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
-
Lukas Wunner authored
[ Upstream commit ea64cdfa ] Commit 744d23c7 ("net: phy: Warn about incorrect mdio_bus_phy_resume() state") introduced a WARN() on resume from system sleep if a PHY is not in PHY_HALTED state. Commit 6dbe852c ("net: phy: Don't WARN for PHY_READY state in mdio_bus_phy_resume()") added an exemption for PHY_READY state from the WARN(). It turns out PHY_UP state needs to be exempted as well because the following may happen on suspend: mdio_bus_phy_suspend() phy_stop_machine() phydev->state = PHY_UP # if (phydev->state >= PHY_UP) Fixes: 744d23c7 ("net: phy: Warn about incorrect mdio_bus_phy_resume() state") Reported-by:
Marek Szyprowski <m.szyprowski@samsung.com> Tested-by:
Lukas Wunner <lukas@wunner.de> Acked-by:
-
Junxiao Chang authored
[ Upstream commit 49725ffc ] This commit fixes DMA engine reset timeout issue in suspend/resume with ADLink I-Pi SMARC Plus board which dmesg shows: ... [ 54.678271] PM: suspend exit [ 54.754066] intel-eth-pci 0000:00:1d.2 enp0s29f2: PHY [stmmac-3:01] driver [Maxlinear Ethernet GPY215B] (irq=POLL) [ 54.755808] intel-eth-pci 0000:00:1d.2 enp0s29f2: Register MEM_TYPE_PAGE_POOL RxQ-0 ... [ 54.780482] intel-eth-pci 0000:00:1d.2 enp0s29f2: Register MEM_TYPE_PAGE_POOL RxQ-7 [ 55.784098] intel-eth-pci 0000:00:1d.2: Failed to reset the dma [ 55.784111] intel-eth-pci 0000:00:1d.2 enp0s29f2: stmmac_hw_setup: DMA engine initialization failed [ 55.784115] intel-eth-pci 0000:00:1d.2 enp0s29f2: stmmac_open: Hw setup failed ... The issue is related with serdes which impacts clock. There is serdes in ADLink I-Pi SMARC board ethernet controller. Please refer to commit b9663b7c ("net: stmmac: Enable SERDES power up/down sequence") for detial. When issue is reproduced, DMA engine clock is not ready because serdes is not powered up. To reproduce DMA engine reset timeout issue with hardware which has serdes in GBE controller, install Ubuntu. In Ubuntu GUI, click "Power Off/Log Out" -> "Suspend" menu, it disables network interface, then goes to sleep mode. When it wakes up, it enables network interface again. Stmmac driver is called in this way: 1. stmmac_release: Stop network interface. In this function, it disables DMA engine and network interface; 2. stmmac_suspend: It is called in kernel suspend flow. But because network interface has been disabled(netif_running(ndev) is false), it does nothing and returns directly; 3. System goes into S3 or S0ix state. Some time later, system is waken up by keyboard or mouse; 4. stmmac_resume: It does nothing because network interface has been disabled; 5. stmmac_open: It is called to enable network interace again. DMA engine is initialized in this API, but serdes is not power on so there will be DMA engine reset timeout issue. Similarly, serdes powerdown should be added in stmmac_release. Network interface might be disabled by cmd "ifconfig eth0 down", DMA engine, phy and mac have been disabled in ndo_stop callback, serdes should be powered down as well. It doesn't make sense that serdes is on while other components have been turned off. If ethernet interface is in enabled state(netif_running(ndev) is true) before suspend/resume, the issue couldn't be reproduced because serdes could be powered up in stmmac_resume. Because serdes_powerup is added in stmmac_open, it doesn't need to be called in probe function. Fixes: b9663b7c ("net: stmmac: Enable SERDES power up/down sequence") Signed-off-by:
Junxiao Chang <junxiao.chang@intel.com> Reviewed-by:
Voon Weifeng <weifeng.voon@intel.com> Tested-by:
Jimmy JS Chen <jimmyjs.chen@adlinktech.com> Tested-by:
Looi, Hong Aun <hong.aun.looi@intel.com> Link: https://lore.kernel.org/r/20220923050448.1220250-1-junxiao.chang@intel.com Signed-off-by:
-
Hans de Goede authored
[ Upstream commit d873697e ] Commit 10cb8e61 ("mac80211: enable QoS support for nl80211 ctrl port") changed ieee80211_tx_control_port() to aways call __ieee80211_select_queue() without checking local->hw.queues. __ieee80211_select_queue() returns a queue-id between 0 and 3, which means that now ieee80211_tx_control_port() may end up setting the queue-mapping for a skb to a value higher then local->hw.queues if local->hw.queues is less then 4. Specifically this is a problem for ralink rt2500-pci cards where local->hw.queues is 2. There this causes rt2x00queue_get_tx_queue() to return NULL and the following error to be logged: "ieee80211 phy0: rt2x00mac_tx: Error - Attempt to send packet over invalid queue 2", after which association with the AP fails. Other callers of __ieee80211_select_queue() skip calling it when local->hw.queues < IEEE80211_NUM_ACS, add the same check to ieee80211_tx_control_port(). This fixes ralink rt2500-pci and similar cards when less then 4 tx-queues no longer working. Fixes: 10cb8e61 ("mac80211: enable QoS support for nl80211 ctrl port") Cc: Markus Theil <markus.theil@tu-ilmenau.de> Suggested-by:
Stanislaw Gruszka <stf_xl@wp.pl> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20220918192052.443529-1-hdegoede@redhat.com Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Michael Kelley authored
[ Upstream commit c292a337 ] The IOC_PR_CLEAR and IOC_PR_RELEASE ioctls are non-functional on NVMe devices because the nvme_pr_clear() and nvme_pr_release() functions set the IEKEY field incorrectly. The IEKEY field should be set only when the key is zero (i.e, not specified). The current code does it backwards. Furthermore, the NVMe spec describes the persistent reservation "clear" function as an option on the reservation release command. The current implementation of nvme_pr_clear() erroneously uses the reservation register command. Fix these errors. Note that NVMe version 1.3 and later specify that setting the IEKEY field will return an error of Invalid Field in Command. The fix will set IEKEY when the key is zero, which is appropriate as these ioctls consider a zero key to be "unspecified", and the intention of the spec change is to require a valid key. Tested on a version 1.4 PCI NVMe device in an Azure VM. Fixes: 1673f1f0 ("nvme: move block_device_operations and ns/ctrl freeing to common code") Fixes: 1d277a63 ("NVMe: Add persistent reservation ops") Signed-off-by:
Michael Kelley <mikelley@microsoft.com> Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Peng Wu authored
[ Upstream commit 4774db8d ] The devm_ioremap() function returns NULL on error, it doesn't return error pointers. Fixes: 3a1a274e ("mlxbf_gige: compute MDIO period based on i1clk") Signed-off-by:
Peng Wu <wupeng58@huawei.com> Link: https://lore.kernel.org/r/20220923023640.116057-1-wupeng58@huawei.com Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
-
Rafael Mendonca authored
[ Upstream commit c635ebe8d911a93bd849a9419b01a58783de76f1 ] The label passed to the QDESC_GET for the ETHOFLD TXQ, RXQ, and FLQ, is the 'out' one, which skips the 'out_unlock' label, and thus doesn't unlock the 'uld_mutex' before returning. Additionally, since commit 5148e595 ("cxgb4: add EOTID tracking and software context dump"), the access to these ETHOFLD hardware queues should be protected by the 'mqprio_mutex' instead. Fixes: 2d0cb84d ("cxgb4: add ETHOFLD hardware queue support") Fixes: 5148e595 ("cxgb4: add EOTID tracking and software context dump") Signed-off-by:
Rafael Mendonca <rafaelmendsr@gmail.com> Reviewed-by:
Rahul Lakkireddy <rahul.lakkireddy@chelsio.com> Link: https://lore.kernel.org/r/20220922175109.764898-1-rafaelmendsr@gmail.com Signed-off-by:
-
Hangyu Hua authored
[ Upstream commit 6e23ec0b ] nf_ct_put need to be called to put the refcount got by tcf_ct_fill_params to avoid possible refcount leak when tcf_ct_flow_table_get fails. Fixes: c34b961a ("net/sched: act_ct: Create nf flow table per zone") Signed-off-by:
Hangyu Hua <hbh25y@gmail.com> Link: https://lore.kernel.org/r/20220923020046.8021-1-hbh25y@gmail.com Signed-off-by:
-
Peilin Ye authored
[ Upstream commit a4320615 ] Currently usbnet_disconnect() unanchors and frees all deferred URBs using usb_scuttle_anchored_urbs(), which does not free urb->context, causing a memory leak as reported by syzbot. Use a usb_get_from_anchor() while loop instead, similar to what we did in commit 19cfe912 ("Bluetooth: btusb: Fix memory leak in play_deferred"). Also free urb->sg. Reported-and-tested-by:
<syzbot+dcd3e13cf4472f2e0ba1@syzkaller.appspotmail.com> Fixes: 69ee472f ("usbnet & cdc-ether: Autosuspend for online devices") Fixes: 638c5115 ("USBNET: support DMA SG") Signed-off-by:
Peilin Ye <peilin.ye@bytedance.com> Link: https://lore.kernel.org/r/20220923042551.2745-1-yepeilin.cs@gmail.com Signed-off-by:
-
Pali Rohár authored
[ Upstream commit 4335417d ] pwm support incompatible with Armada 80x0/70x0 API is not only in Armada 370, but also in Armada XP, 38x and 39x. So basically every non-A8K platform. Fix check for pwm support appropriately. Fixes: 85b7d8ab ("gpio: mvebu: add pwm support for Armada 8K/7K") Signed-off-by:
Pali Rohár <pali@kernel.org> Signed-off-by:
Bartosz Golaszewski <brgl@bgdev.pl> Signed-off-by:
-
Yang Yingliang authored
[ Upstream commit a54dc27b ] devm_gpiod_get_optional() may return ERR_PTR(-EPROBE_DEFER), add a minus sign to fix it. Fixes: 6ccb1d8f ("Input: add MELFAS MIP4 Touchscreen driver") Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20220924030715.1653538-1-yangyingliang@huawei.com Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Brian Norris authored
[ Upstream commit cc62d98b ] This reverts commit 211f276e. For quite some time, core DRM helpers already ensure that any relevant connectors/CRTCs/etc. are disabled, as well as their associated components (e.g., bridges) when suspending the system. Thus, analogix_dp_bridge_{enable,disable}() already get called, which in turn call drm_panel_{prepare,unprepare}(). This makes these drm_panel_*() calls redundant. Besides redundancy, there are a few problems with this handling: (1) drm_panel_{prepare,unprepare}() are *not* reference-counted APIs and are not in general designed to be handled by multiple callers -- although some panel drivers have a coarse 'prepared' flag that mitigates some damage, at least. So at a minimum this is redundant and confusing, but in some cases, this could be actively harmful. (2) The error-handling is a bit non-standard. We ignored errors in suspend(), but handled errors in resume(). And recently, people noticed that the clk handling is unbalanced in error paths, and getting *that* right is not actually trivial, given the current way errors are mostly ignored. (3) In the particular way analogix_dp_{suspend,resume}() get used (e.g., in rockchip_dp_*(), as a late/early callback), we don't necessarily have a proper PM relationship between the DP/bridge device and the panel device. So while the DP bridge gets resumed, the panel's parent device (e.g., platform_device) may still be suspended, and so any prepare() calls may fail. So remove the superfluous, possibly-harmful suspend()/resume() handling of panel state. Fixes: 211f276e ("drm: bridge: analogix/dp: add panel prepare/unprepare in suspend/resume time") Link: https://lore.kernel.org/all/Yv2CPBD3Picg%2FgVe@google.com/ Signed-off-by:
Brian Norris <briannorris@chromium.org> Reviewed-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
-
Francesco Dolcini authored
[ Upstream commit 051ad278 ] Correct I2C address for the register list in lt8912_write_lvds_config(), these registers are on the first I2C address (0x48), the current function is just writing garbage to the wrong registers and this creates multiple issues (artifacts and output completely corrupted) on some HDMI displays. Correct I2C address comes from Lontium documentation and it is the one used on other out-of-tree LT8912B drivers [1]. [1] https://github.com/boundarydevices/linux/blob/boundary-imx_5.10.x_2.0.0/drivers/video/lt8912.c#L296 Fixes: 30e2ae94 ("drm/bridge: Introduce LT8912B DSI to HDMI bridge") Signed-off-by:
Francesco Dolcini <francesco.dolcini@toradex.com> Signed-off-by:
Philippe Schenker <philippe.schenker@toradex.com> Acked-by:
Adrien Grassein <adrien.grassein@gmail.com> Signed-off-by:
Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220922124306.34729-4-dev@pschenker.ch Signed-off-by:
-
Philippe Schenker authored
[ Upstream commit 6dd1de12 ] The Lontium LT8912 does have a setting for DVI or HDMI. This patch reads from EDID what the display needs and sets it accordingly. Fixes: 30e2ae94 ("drm/bridge: Introduce LT8912B DSI to HDMI bridge") Signed-off-by:
-
Philippe Schenker authored
[ Upstream commit da73a94f ] Currently the bridge driver does not take care whether or not the display needs positive/negative vertical/horizontal syncs. Pass these two flags to the bridge from the EDID that was read out from the display. Fixes: 30e2ae94 ("drm/bridge: Introduce LT8912B DSI to HDMI bridge") Signed-off-by:
-
Martin Povišer authored
[ Upstream commit 0a0342ed ] On probe of the ASoC component, the device is reset but the regcache is retained. This means the regcache gets out of sync if the codec is rebound to a sound card for a second time. Fix it by reinitializing the regcache to defaults after the device is reset. Fixes: b0bcbe61 ("ASoC: tas2770: Fix calling reset in probe") Signed-off-by:
Martin Povišer <povik+lin@cutebit.org> Link: https://lore.kernel.org/r/20220919173453.84292-1-povik+lin@cutebit.org Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
