- 06 7月, 2022 40 次提交
-
-
由 Rik van Riel 提交于
stable inclusion from stable-v5.10.110 commit fa37c1714367e530f592d451607433ab58d56643 bugzilla: https://gitee.com/openeuler/kernel/issues/I574AL Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=fa37c1714367e530f592d451607433ab58d56643 -------------------------------- commit e53ac737 upstream. Sometimes the page offlining code can leave behind a hwpoisoned clean page cache page. This can lead to programs being killed over and over and over again as they fault in the hwpoisoned page, get killed, and then get re-spawned by whatever wanted to run them. This is particularly embarrassing when the page was offlined due to having too many corrected memory errors. Now we are killing tasks due to them trying to access memory that probably isn't even corrupted. This problem can be avoided by invalidating the page from the page fault handler, which already has a branch for dealing with these kinds of pages. With this patch we simply pretend the page fault was successful if the page was invalidated, return to userspace, incur another page fault, read in the file from disk (to a new memory page), and then everything works again. Link: https://lkml.kernel.org/r/20220212213740.423efcea@imladris.surriel.comSigned-off-by: NRik van Riel <riel@surriel.com> Reviewed-by: NMiaohe Lin <linmiaohe@huawei.com> Acked-by: NNaoya Horiguchi <naoya.horiguchi@nec.com> Reviewed-by: NOscar Salvador <osalvador@suse.de> Cc: John Hubbard <jhubbard@nvidia.com> Cc: Mel Gorman <mgorman@suse.de> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Matthew Wilcox <willy@infradead.org> Cc: <stable@vger.kernel.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYu Liao <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Alistair Popple 提交于
stable inclusion from stable-v5.10.110 commit 7188e7c96f39ae40b8f8d6a807d3f338fb1927ac bugzilla: https://gitee.com/openeuler/kernel/issues/I574AL Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=7188e7c96f39ae40b8f8d6a807d3f338fb1927ac -------------------------------- commit ddbc84f3 upstream. ZONE_MOVABLE uses the remaining memory in each node. Its starting pfn is also aligned to MAX_ORDER_NR_PAGES. It is possible for the remaining memory in a node to be less than MAX_ORDER_NR_PAGES, meaning there is not enough room for ZONE_MOVABLE on that node. Unfortunately this condition is not checked for. This leads to zone_movable_pfn[] getting set to a pfn greater than the last pfn in a node. calculate_node_totalpages() then sets zone->present_pages to be greater than zone->spanned_pages which is invalid, as spanned_pages represents the maximum number of pages in a zone assuming no holes. Subsequently it is possible free_area_init_core() will observe a zone of size zero with present pages. In this case it will skip setting up the zone, including the initialisation of free_lists[]. However populated_zone() checks zone->present_pages to see if a zone has memory available. This is used by iterators such as walk_zones_in_node(). pagetypeinfo_showfree() uses this to walk the free_list of each zone in each node, which are assumed to be initialised due to the zone not being empty. As free_area_init_core() never initialised the free_lists[] this results in the following kernel crash when trying to read /proc/pagetypeinfo: 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 DEBUG_PAGEALLOC NOPTI CPU: 0 PID: 456 Comm: cat Not tainted 5.16.0 #461 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014 RIP: 0010:pagetypeinfo_show+0x163/0x460 Code: 9e 82 e8 80 57 0e 00 49 8b 06 b9 01 00 00 00 4c 39 f0 75 16 e9 65 02 00 00 48 83 c1 01 48 81 f9 a0 86 01 00 0f 84 48 02 00 00 <48> 8b 00 4c 39 f0 75 e7 48 c7 c2 80 a2 e2 82 48 c7 c6 79 ef e3 82 RSP: 0018:ffffc90001c4bd10 EFLAGS: 00010003 RAX: 0000000000000000 RBX: ffff88801105f638 RCX: 0000000000000001 RDX: 0000000000000001 RSI: 000000000000068b RDI: ffff8880163dc68b RBP: ffffc90001c4bd90 R08: 0000000000000001 R09: ffff8880163dc67e R10: 656c6261766f6d6e R11: 6c6261766f6d6e55 R12: ffff88807ffb4a00 R13: ffff88807ffb49f8 R14: ffff88807ffb4580 R15: ffff88807ffb3000 FS: 00007f9c83eff5c0(0000) GS:ffff88807dc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000000013c8e000 CR4: 0000000000350ef0 Call Trace: seq_read_iter+0x128/0x460 proc_reg_read_iter+0x51/0x80 new_sync_read+0x113/0x1a0 vfs_read+0x136/0x1d0 ksys_read+0x70/0xf0 __x64_sys_read+0x1a/0x20 do_syscall_64+0x3b/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae Fix this by checking that the aligned zone_movable_pfn[] does not exceed the end of the node, and if it does skip creating a movable zone on this node. Link: https://lkml.kernel.org/r/20220215025831.2113067-1-apopple@nvidia.com Fixes: 2a1e274a ("Create the ZONE_MOVABLE zone") Signed-off-by: NAlistair Popple <apopple@nvidia.com> Acked-by: NDavid Hildenbrand <david@redhat.com> Acked-by: NMel Gorman <mgorman@techsingularity.net> Cc: John Hubbard <jhubbard@nvidia.com> Cc: Zi Yan <ziy@nvidia.com> Cc: Anshuman Khandual <anshuman.khandual@arm.com> Cc: Oscar Salvador <osalvador@suse.de> Cc: <stable@vger.kernel.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYu Liao <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Sean Nyekjaer 提交于
stable inclusion from stable-v5.10.110 commit 3a21ee89bc22c2768aa6ccbf6fd85ccbab430f04 bugzilla: https://gitee.com/openeuler/kernel/issues/I574AL Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=3a21ee89bc22c2768aa6ccbf6fd85ccbab430f04 -------------------------------- commit 8cba3234 upstream. Prevent rawnand access while in a suspended state. Commit 013e6292 ("mtd: rawnand: Simplify the locking") allows the rawnand layer to return errors rather than waiting in a blocking wait. Tested on a iMX6ULL. Fixes: 013e6292 ("mtd: rawnand: Simplify the locking") Signed-off-by: NSean Nyekjaer <sean@geanix.com> Reviewed-by: NBoris Brezillon <boris.brezillon@collabora.com> Cc: stable@vger.kernel.org Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20220208085213.1838273-1-sean@geanix.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYu Liao <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Miquel Raynal 提交于
stable inclusion from stable-v5.10.110 commit 145a63201d0000ab6ad951bcbfb8db550e74f4b2 bugzilla: https://gitee.com/openeuler/kernel/issues/I574AL Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=145a63201d0000ab6ad951bcbfb8db550e74f4b2 -------------------------------- commit 5fd6739e upstream. By working with external hardware ECC engines, we figured out that Under certain circumstances, it is needed for the SPI controller to check INT_TX_EMPTY and INT_RX_NOT_EMPTY in both receive and transmit path (not only in the receive path). The delay penalty being negligible, move this code in the common path. Fixes: b942d80b ("spi: Add MXIC controller driver") Cc: stable@vger.kernel.org Suggested-by: NMason Yang <masonccyang@mxic.com.tw> Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: NZhengxun Li <zhengxunli@mxic.com.tw> Reviewed-by: NMark Brown <broonie@kernel.org> Link: https://lore.kernel.org/linux-mtd/20220127091808.1043392-10-miquel.raynal@bootlin.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYu Liao <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Krzysztof Kozlowski 提交于
stable inclusion from stable-v5.10.110 commit be22ebe79e64c3a8eb76f68743d97771f244cb18 bugzilla: https://gitee.com/openeuler/kernel/issues/I574AL Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=be22ebe79e64c3a8eb76f68743d97771f244cb18 -------------------------------- commit 50ebd19e upstream. The driver iterates over its devicetree children with for_each_child_of_node() and stores for later found node pointer. This has to be put in error paths to avoid leak during re-probing. Fixes: ab663789 ("pinctrl: samsung: Match pin banks with their device nodes") Cc: <stable@vger.kernel.org> Signed-off-by: NKrzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Reviewed-by: NSam Protsenko <semen.protsenko@linaro.org> Reviewed-by: NChanho Park <chanho61.park@samsung.com> Link: https://lore.kernel.org/r/20220111201426.326777-2-krzysztof.kozlowski@canonical.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYu Liao <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Alistair Delva 提交于
stable inclusion from stable-v5.10.110 commit b97b305656a7013690e7b6e310f0e827e0bbff90 bugzilla: https://gitee.com/openeuler/kernel/issues/I574AL Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=b97b305656a7013690e7b6e310f0e827e0bbff90 -------------------------------- commit f89672cc upstream. Check count for 0, to avoid a potential underflow. Make the check the same as the one in rproc_recovery_write(). Fixes: 3afdc59e ("remoteproc: Add coredump debugfs entry") Signed-off-by: NAlistair Delva <adelva@google.com> Cc: Rishabh Bhatnagar <rishabhb@codeaurora.org> Cc: stable@vger.kernel.org Cc: Ohad Ben-Cohen <ohad@wizery.com> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Cc: Sibi Sankar <sibis@codeaurora.org> Cc: linux-remoteproc@vger.kernel.org Cc: kernel-team@android.com Reviewed-by: NBjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: NBjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220119232139.1125908-1-adelva@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYu Liao <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Chao Yu 提交于
stable inclusion from stable-v5.10.110 commit 784630df174f373538c44268f2e3a743bd8d5868 bugzilla: https://gitee.com/openeuler/kernel/issues/I574AL Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=784630df174f373538c44268f2e3a743bd8d5868 -------------------------------- commit 5b5b4f85 upstream. As bughunter reported in bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215709 f2fs may hang when mounting a fuzzed image, the dmesg shows as below: __filemap_get_folio+0x3a9/0x590 pagecache_get_page+0x18/0x60 __get_meta_page+0x95/0x460 [f2fs] get_checkpoint_version+0x2a/0x1e0 [f2fs] validate_checkpoint+0x8e/0x2a0 [f2fs] f2fs_get_valid_checkpoint+0xd0/0x620 [f2fs] f2fs_fill_super+0xc01/0x1d40 [f2fs] mount_bdev+0x18a/0x1c0 f2fs_mount+0x15/0x20 [f2fs] legacy_get_tree+0x28/0x50 vfs_get_tree+0x27/0xc0 path_mount+0x480/0xaa0 do_mount+0x7c/0xa0 __x64_sys_mount+0x8b/0xe0 do_syscall_64+0x38/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae The root cause is cp_pack_total_block_count field in checkpoint was fuzzed to one, as calcuated, two cp pack block locates in the same block address, so then read latter cp pack block, it will block on the page lock due to the lock has already held when reading previous cp pack block, fix it by adding sanity check for cp_pack_total_block_count. Cc: stable@vger.kernel.org Signed-off-by: NChao Yu <chao.yu@oppo.com> Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYu Liao <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Juhyung Park 提交于
stable inclusion from stable-v5.10.110 commit e58ee6bd939b773675240f5d0f5b88a367c037c4 bugzilla: https://gitee.com/openeuler/kernel/issues/I574AL Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e58ee6bd939b773675240f5d0f5b88a367c037c4 -------------------------------- commit 680af5b8 upstream. cnt should be passed to sb_has_quota_active() instead of type to check active quota properly. Moreover, when the type is -1, the compiler with enough inline knowledge can discard sb_has_quota_active() check altogether, causing a NULL pointer dereference at the following inode_lock(dqopt->files[cnt]): [ 2.796010] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0 [ 2.796024] Mem abort info: [ 2.796025] ESR = 0x96000005 [ 2.796028] EC = 0x25: DABT (current EL), IL = 32 bits [ 2.796029] SET = 0, FnV = 0 [ 2.796031] EA = 0, S1PTW = 0 [ 2.796032] Data abort info: [ 2.796034] ISV = 0, ISS = 0x00000005 [ 2.796035] CM = 0, WnR = 0 [ 2.796046] user pgtable: 4k pages, 39-bit VAs, pgdp=00000003370d1000 [ 2.796048] [00000000000000a0] pgd=0000000000000000, pud=0000000000000000 [ 2.796051] Internal error: Oops: 96000005 [#1] PREEMPT SMP [ 2.796056] CPU: 7 PID: 640 Comm: f2fs_ckpt-259:7 Tainted: G S 5.4.179-arter97-r8-64666-g2f16e087f9d8 #1 [ 2.796057] Hardware name: Qualcomm Technologies, Inc. Lahaina MTP lemonadep (DT) [ 2.796059] pstate: 80c00005 (Nzcv daif +PAN +UAO) [ 2.796065] pc : down_write+0x28/0x70 [ 2.796070] lr : f2fs_quota_sync+0x100/0x294 [ 2.796071] sp : ffffffa3f48ffc30 [ 2.796073] x29: ffffffa3f48ffc30 x28: 0000000000000000 [ 2.796075] x27: ffffffa3f6d718b8 x26: ffffffa415fe9d80 [ 2.796077] x25: ffffffa3f7290048 x24: 0000000000000001 [ 2.796078] x23: 0000000000000000 x22: ffffffa3f7290000 [ 2.796080] x21: ffffffa3f72904a0 x20: ffffffa3f7290110 [ 2.796081] x19: ffffffa3f77a9800 x18: ffffffc020aae038 [ 2.796083] x17: ffffffa40e38e040 x16: ffffffa40e38e6d0 [ 2.796085] x15: ffffffa40e38e6cc x14: ffffffa40e38e6d0 [ 2.796086] x13: 00000000000004f6 x12: 00162c44ff493000 [ 2.796088] x11: 0000000000000400 x10: ffffffa40e38c948 [ 2.796090] x9 : 0000000000000000 x8 : 00000000000000a0 [ 2.796091] x7 : 0000000000000000 x6 : 0000d1060f00002a [ 2.796093] x5 : ffffffa3f48ff718 x4 : 000000000000000d [ 2.796094] x3 : 00000000060c0000 x2 : 0000000000000001 [ 2.796096] x1 : 0000000000000000 x0 : 00000000000000a0 [ 2.796098] Call trace: [ 2.796100] down_write+0x28/0x70 [ 2.796102] f2fs_quota_sync+0x100/0x294 [ 2.796104] block_operations+0x120/0x204 [ 2.796106] f2fs_write_checkpoint+0x11c/0x520 [ 2.796107] __checkpoint_and_complete_reqs+0x7c/0xd34 [ 2.796109] issue_checkpoint_thread+0x6c/0xb8 [ 2.796112] kthread+0x138/0x414 [ 2.796114] ret_from_fork+0x10/0x18 [ 2.796117] Code: aa0803e0 aa1f03e1 52800022 aa0103e9 (c8e97d02) [ 2.796120] ---[ end trace 96e942e8eb6a0b53 ]--- [ 2.800116] Kernel panic - not syncing: Fatal exception [ 2.800120] SMP: stopping secondary CPUs Fixes: 9de71ede ("f2fs: quota: fix potential deadlock") Cc: <stable@vger.kernel.org> # v5.15+ Signed-off-by: NJuhyung Park <qkrwngud825@gmail.com> Reviewed-by: NChao Yu <chao@kernel.org> Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYu Liao <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Chao Yu 提交于
stable inclusion from stable-v5.10.110 commit ec67040703c8423473c419c2b5caa362f53efed6 bugzilla: https://gitee.com/openeuler/kernel/issues/I574AL Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=ec67040703c8423473c419c2b5caa362f53efed6 -------------------------------- commit 6d18762e upstream. As Pavel Machek reported in below link [1]: After commit 77900c45 ("f2fs: fix to do sanity check in is_alive()"), node page should be unlock via calling f2fs_put_page() in the error path of is_alive(), otherwise, f2fs may hang when it tries to lock the node page, fix it. [1] https://lore.kernel.org/stable/20220124203637.GA19321@duo.ucw.cz/ Fixes: 77900c45 ("f2fs: fix to do sanity check in is_alive()") Cc: <stable@vger.kernel.org> Reported-by: NPavel Machek <pavel@denx.de> Signed-off-by: NPavel Machek <pavel@denx.de> Signed-off-by: NChao Yu <chao@kernel.org> Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYu Liao <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Dan Carpenter 提交于
stable inclusion from stable-v5.10.110 commit 7af164fa2f1abc577d357d22d83a2f3490875d7e bugzilla: https://gitee.com/openeuler/kernel/issues/I574AL Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=7af164fa2f1abc577d357d22d83a2f3490875d7e -------------------------------- commit 23a9dbbe upstream. On a 32 bit system, the "len * sizeof(*p)" operation can have an integer overflow. Cc: stable@vger.kernel.org Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NChuck Lever <chuck.lever@oracle.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYu Liao <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Dan Carpenter 提交于
stable inclusion from stable-v5.10.110 commit 65e21cc042f4c1518c8c55283f53bc725b78419d bugzilla: https://gitee.com/openeuler/kernel/issues/I574AL Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=65e21cc042f4c1518c8c55283f53bc725b78419d -------------------------------- commit 184416d4 upstream. Smatch complains: fs/nfsd/nfsxdr.c:341 nfssvc_decode_writeargs() warn: no lower bound on 'args->len' Change the type to unsigned to prevent this issue. Cc: stable@vger.kernel.org Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NChuck Lever <chuck.lever@oracle.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYu Liao <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 NeilBrown 提交于
stable inclusion from stable-v5.10.110 commit b7b430104a14a05c74297e794a0fe237f822ebb1 bugzilla: https://gitee.com/openeuler/kernel/issues/I574AL Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=b7b430104a14a05c74297e794a0fe237f822ebb1 -------------------------------- commit 3848e96e upstream. xprt_destory() claims XPRT_LOCKED and then calls del_timer_sync(). Both xprt_unlock_connect() and xprt_release() call ->release_xprt() which drops XPRT_LOCKED and *then* xprt_schedule_autodisconnect() which calls mod_timer(). This may result in mod_timer() being called *after* del_timer_sync(). When this happens, the timer may fire long after the xprt has been freed, and run_timer_softirq() will probably crash. The pairing of ->release_xprt() and xprt_schedule_autodisconnect() is always called under ->transport_lock. So if we take ->transport_lock to call del_timer_sync(), we can be sure that mod_timer() will run first (if it runs at all). Cc: stable@vger.kernel.org Signed-off-by: NNeilBrown <neilb@suse.de> Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYu Liao <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Gwendal Grignou 提交于
stable inclusion from stable-v5.10.110 commit f51ab2f60a44c42b29010b17f98d1f902de40a5c bugzilla: https://gitee.com/openeuler/kernel/issues/I574AL Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f51ab2f60a44c42b29010b17f98d1f902de40a5c -------------------------------- commit f97ec5d7 upstream. Allocating memory with kmalloc and GPF_DMA32 is not allowed, the allocator will ignore the attribute. Instead, use dma_alloc_coherent() API as we allocate a small amount of memory to transfer firmware fragment to the ISH. On Arcada chromebook, after the patch the warning: "Unexpected gfp: 0x4 (GFP_DMA32). Fixing up to gfp: 0xcc0 (GFP_KERNEL). Fix your code!" is gone. The ISH firmware is loaded properly and we can interact with the ISH: > ectool --name cros_ish version ... Build info: arcada_ish_v2.0.3661+3c1a1c1ae0 2022-02-08 05:37:47 @localhost Tool version: v2.0.12300-900b03ec7f 2022-02-08 10:01:48 @localhost Fixes: commit 91b22810 ("HID: intel-ish-hid: ISH firmware loader client driver") Signed-off-by: NGwendal Grignou <gwendal@chromium.org> Acked-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Cc: stable@vger.kernel.org Signed-off-by: NJiri Kosina <jkosina@suse.cz> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYu Liao <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Ang Tien Sung 提交于
stable inclusion from stable-v5.10.110 commit a1df8e60f25a9990988c4ae1dc0f4cd553329419 bugzilla: https://gitee.com/openeuler/kernel/issues/I574AL Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=a1df8e60f25a9990988c4ae1dc0f4cd553329419 -------------------------------- commit b850b7a8 upstream. Fix a bug whereby, the return response of parameter a1 from an SMC call is not properly set to the callback data during an INTEL_SIP_SMC_RSU_ERROR command. Link: https://lore.kernel.org/lkml/20220216081513.28319-1-tien.sung.ang@intel.com Fixes: 6b50d882 ("firmware: add remote status update client support") Cc: stable@vger.kernel.org Signed-off-by: NAng Tien Sung <tien.sung.ang@intel.com> Signed-off-by: NDinh Nguyen <dinguyen@kernel.org> Link: https://lore.kernel.org/r/20220223144146.399263-1-dinguyen@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYu Liao <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Bagas Sanjaya 提交于
stable inclusion from stable-v5.10.110 commit e94f5fbe7ab304b604df119e6355109304500da6 bugzilla: https://gitee.com/openeuler/kernel/issues/I574AL Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e94f5fbe7ab304b604df119e6355109304500da6 -------------------------------- commit 555d4493 upstream. The link to stable tree is redirected to https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git. Update accordingly. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Sasha Levin <sashal@kernel.org> Cc: Jonathan Corbet <corbet@lwn.net> Cc: stable@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: NBagas Sanjaya <bagasdotme@gmail.com> Link: https://lore.kernel.org/r/20220314113329.485372-6-bagasdotme@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYu Liao <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Bagas Sanjaya 提交于
stable inclusion from stable-v5.10.110 commit f4bab992ee258654c63005a8385e256f09c651ca bugzilla: https://gitee.com/openeuler/kernel/issues/I574AL Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f4bab992ee258654c63005a8385e256f09c651ca -------------------------------- commit 587d39b2 upstream. There is also stable release candidate tree. Mention it, however with a warning that the tree is for testing purposes. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Sasha Levin <sashal@kernel.org> Cc: Jonathan Corbet <corbet@lwn.net> Cc: stable@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: NBagas Sanjaya <bagasdotme@gmail.com> Link: https://lore.kernel.org/r/20220314113329.485372-5-bagasdotme@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYu Liao <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Eric Biggers 提交于
stable inclusion from stable-v5.10.110 commit 10ee5662d5a65bf3883eefe59b053eb4c115bc87 bugzilla: https://gitee.com/openeuler/kernel/issues/I574AL Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=10ee5662d5a65bf3883eefe59b053eb4c115bc87 -------------------------------- commit c51abd96 upstream. In many cases, keyctl_pkey_params_get_2() is validating the user buffer lengths against the wrong algorithm properties. Fix it to check against the correct properties. Probably this wasn't noticed before because for all asymmetric keys of the "public_key" subtype, max_data_size == max_sig_size == max_enc_size == max_dec_size. However, this isn't necessarily true for the "asym_tpm" subtype (it should be, but it's not strictly validated). Of course, future key types could have different values as well. Fixes: 00d60fd3 ("KEYS: Provide keyctls to drive the new key type ops for asymmetric keys [ver #2]") Cc: <stable@vger.kernel.org> # v4.20+ Signed-off-by: NEric Biggers <ebiggers@google.com> Reviewed-by: NJarkko Sakkinen <jarkko@kernel.org> Signed-off-by: NJarkko Sakkinen <jarkko@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYu Liao <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Kunihiko Hayashi 提交于
stable inclusion from stable-v5.10.110 commit 2775d8e3643628f2f1575cfbb40fa4caf538d740 bugzilla: https://gitee.com/openeuler/kernel/issues/I574AL Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=2775d8e3643628f2f1575cfbb40fa4caf538d740 -------------------------------- commit ca85a667 upstream. Fixed-rate clocks in UniPhier don't have any parent clocks, however, initial data "init.flags" isn't initialized, so it might be determined that there is a parent clock for fixed-rate clock. This sets init.flags to zero as initialization. Cc: <stable@vger.kernel.org> Fixes: 734d82f4 ("clk: uniphier: add core support code for UniPhier clock driver") Signed-off-by: NKunihiko Hayashi <hayashi.kunihiko@socionext.com> Link: https://lore.kernel.org/r/1646808918-30899-1-git-send-email-hayashi.kunihiko@socionext.comSigned-off-by: NStephen Boyd <sboyd@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYu Liao <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Dan Carpenter 提交于
stable inclusion from stable-v5.10.110 commit 25cd5872d9a76da68c60cd8018cbb0f1bf439711 bugzilla: https://gitee.com/openeuler/kernel/issues/I574AL Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=25cd5872d9a76da68c60cd8018cbb0f1bf439711 -------------------------------- commit 5f8583a3 upstream. Cleanup if gb_svc_queue_deferred_request() fails. Link: https://lore.kernel.org/r/20220202072016.GA6748@kili Fixes: ee2f2074 ("greybus: svc: reconfig APBridgeA-Switch link to handle required load") Cc: stable@vger.kernel.org # 4.9 [johan: fix commit summary prefix and rename label ] Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NJohan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20220202113347.1288-2-johan@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYu Liao <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Liam Beguin 提交于
stable inclusion from stable-v5.10.110 commit 9f0cd81174579c4ca1f02d9f90bae88b916810e0 bugzilla: https://gitee.com/openeuler/kernel/issues/I574AL Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=9f0cd81174579c4ca1f02d9f90bae88b916810e0 -------------------------------- commit ca851233 upstream. iio_convert_raw_to_processed_unlocked() assumes the offset is an integer. Make a best effort to get a valid offset value for fractional cases without breaking implicit truncations. Fixes: 48e44ce0 ("iio:inkern: Add function to read the processed value") Signed-off-by: NLiam Beguin <liambeguin@gmail.com> Reviewed-by: NPeter Rosin <peda@axentia.se> Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20220108205319.2046348-4-liambeguin@gmail.com Cc: <Stable@vger.kernel.org> Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYu Liao <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Liam Beguin 提交于
stable inclusion from stable-v5.10.110 commit 19e533452fbebfd053556732073cf94b7ac59127 bugzilla: https://gitee.com/openeuler/kernel/issues/I574AL Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=19e533452fbebfd053556732073cf94b7ac59127 -------------------------------- commit 14b457fd upstream. When a consumer calls iio_read_channel_processed() and no channel scale is available, it's assumed that the scale is one and the raw value is returned as expected. On the other hand, if the consumer calls iio_convert_raw_to_processed() the scaling factor requested by the consumer is not applied. This for example causes the consumer to process mV when expecting uV. Make sure to always apply the scaling factor requested by the consumer. Fixes: adc8ec5f ("iio: inkern: pass through raw values if no scaling") Signed-off-by: NLiam Beguin <liambeguin@gmail.com> Reviewed-by: NPeter Rosin <peda@axentia.se> Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20220108205319.2046348-3-liambeguin@gmail.com Cc: <Stable@vger.kernel.org> Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYu Liao <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Liam Beguin 提交于
stable inclusion from stable-v5.10.110 commit e10dbe7f6ac123935d1aa4563430f107fa288e53 bugzilla: https://gitee.com/openeuler/kernel/issues/I574AL Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e10dbe7f6ac123935d1aa4563430f107fa288e53 -------------------------------- commit 1bca97ff upstream. When a consumer calls iio_read_channel_processed() and the channel has an integer scale, the scale channel scale is applied and the processed value is returned as expected. On the other hand, if the consumer calls iio_convert_raw_to_processed() the scaling factor requested by the consumer is not applied. This for example causes the consumer to process mV when expecting uV. Make sure to always apply the scaling factor requested by the consumer. Fixes: 48e44ce0 ("iio:inkern: Add function to read the processed value") Signed-off-by: NLiam Beguin <liambeguin@gmail.com> Reviewed-by: NPeter Rosin <peda@axentia.se> Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20220108205319.2046348-2-liambeguin@gmail.com Cc: <Stable@vger.kernel.org> Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYu Liao <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Liam Beguin 提交于
stable inclusion from stable-v5.10.110 commit 9f4fffc2ab26b4c8ac9c7e9e72dc203ed1081f64 bugzilla: https://gitee.com/openeuler/kernel/issues/I574AL Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=9f4fffc2ab26b4c8ac9c7e9e72dc203ed1081f64 -------------------------------- commit 51593106 upstream. All four scaling coefficients can take signed values. Make tmp a signed 64-bit integer and switch to div_s64() to preserve signs during 64-bit divisions. Fixes: 8b74816b ("iio: afe: rescale: new driver") Signed-off-by: NLiam Beguin <liambeguin@gmail.com> Reviewed-by: NPeter Rosin <peda@axentia.se> Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20220108205319.2046348-5-liambeguin@gmail.com Cc: <Stable@vger.kernel.org> Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYu Liao <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 James Clark 提交于
stable inclusion from stable-v5.10.110 commit 9cd1b02655c748b9b2c769c18f04338beefdfcc1 bugzilla: https://gitee.com/openeuler/kernel/issues/I574AL Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=9cd1b02655c748b9b2c769c18f04338beefdfcc1 -------------------------------- commit ea75a342 upstream. It's impossible to program a valid value for TRCCONFIGR.QE when TRCIDR0.QSUPP==0b10. In that case the following is true: Q element support is implemented, and only supports Q elements without instruction counts. TRCCONFIGR.QE can only take the values 0b00 or 0b11. Currently the low bit of QSUPP is checked to see if the low bit of QE can be written to, but as you can see when QSUPP==0b10 the low bit is cleared making it impossible to ever write the only valid value of 0b11 to QE. 0b10 would be written instead, which is a reserved QE value even for all values of QSUPP. The fix is to allow writing the low bit of QE for any non zero value of QSUPP. This change also ensures that the low bit is always set, even when the user attempts to only set the high bit. Signed-off-by: NJames Clark <james.clark@arm.com> Reviewed-by: NMike Leach <mike.leach@linaro.org> Fixes: d8c66962 ("coresight-etm4x: Controls pertaining to the reset, mode, pe and events") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20220120113047.2839622-2-james.clark@arm.comSigned-off-by: NMathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: NSuzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYu Liao <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Alexander Usyskin 提交于
stable inclusion from stable-v5.10.110 commit 7b478cb67b8c56f20e48e225e0485ceee94da97f bugzilla: https://gitee.com/openeuler/kernel/issues/I574AL Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=7b478cb67b8c56f20e48e225e0485ceee94da97f -------------------------------- commit c10187b1 upstream. Usage of the iterator outside of the list_for_each_entry is considered harmful. https://lkml.org/lkml/2022/2/17/1032 Do not reference the loop variable outside of the loop, by rearranging the orders of execution. Instead of performing search loop and checking outside the loop if the end of the list was hit and no matching element was found, the execution is performed inside the loop upon a successful match followed by a goto statement to the next step, therefore no condition has to be performed after the loop has ended. Cc: <stable@vger.kernel.org> Signed-off-by: NAlexander Usyskin <alexander.usyskin@intel.com> Signed-off-by: NTomas Winkler <tomas.winkler@intel.com> Link: https://lore.kernel.org/r/20220308095926.300412-1-tomas.winkler@intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYu Liao <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Alexander Usyskin 提交于
stable inclusion from stable-v5.10.110 commit ec8975417d714e8a6abab334645a7370887eca09 bugzilla: https://gitee.com/openeuler/kernel/issues/I574AL Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=ec8975417d714e8a6abab334645a7370887eca09 -------------------------------- commit 7bbbd084 upstream. Add Alder Lake N device ID. Cc: <stable@vger.kernel.org> Signed-off-by: NAlexander Usyskin <alexander.usyskin@intel.com> Signed-off-by: NTomas Winkler <tomas.winkler@intel.com> Link: https://lore.kernel.org/r/20220301071115.96145-1-tomas.winkler@intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYu Liao <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Anssi Hannula 提交于
stable inclusion from stable-v5.10.110 commit 0a0c61dd071d7affdbfcf0d87dc5cb10b1d0980c bugzilla: https://gitee.com/openeuler/kernel/issues/I574AL Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=0a0c61dd071d7affdbfcf0d87dc5cb10b1d0980c -------------------------------- commit 05519b85 upstream. xhci_decode_ctrl_ctx() returns the untouched buffer as-is if both "drop" and "add" parameters are zero. Fix the function to return an empty string in that case. It was not immediately clear from the possible call chains whether this issue is currently actually triggerable or not. Note that before commit 4843b4b5 ("xhci: fix even more unsafe memory usage in xhci tracing") the result effect in the failure case was different as a static buffer was used here, but the code still worked incorrectly. Fixes: 90d6d573 ("xhci: Add tracing for input control context") Cc: stable@vger.kernel.org Signed-off-by: NAnssi Hannula <anssi.hannula@bitwise.fi> Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> commit 4843b4b5 ("xhci: fix even more unsafe memory usage in xhci tracing") Link: https://lore.kernel.org/r/20220303110903.1662404-4-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYu Liao <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Mathias Nyman 提交于
stable inclusion from stable-v5.10.110 commit 811f4035194912ac2cb89965dd0851125634b3c8 bugzilla: https://gitee.com/openeuler/kernel/issues/I574AL Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=811f4035194912ac2cb89965dd0851125634b3c8 -------------------------------- commit 14073ce9 upstream. xhci_reset() timeout was increased from 250ms to 10 seconds in order to give Renesas 720201 xHC enough time to get ready in probe. xhci_reset() is called with interrupts disabled in other places, and waiting for 10 seconds there is not acceptable. Add a timeout parameter to xhci_reset(), and adjust it back to 250ms when called from xhci_stop() or xhci_shutdown() where interrupts are disabled, and successful reset isn't that critical. This solves issues when deactivating host mode on platforms like SM8450. For now don't change the timeout if xHC is reset in xhci_resume(). No issues are reported for it, and we need the reset to succeed. Locking around that reset needs to be revisited later. Additionally change the signed integer timeout parameter in xhci_handshake() to a u64 to match the timeout value we pass to readl_poll_timeout_atomic() Fixes: 22ceac19 ("xhci: Increase reset timeout for Renesas 720201 host.") Cc: stable@vger.kernel.org Reported-by: NSergey Shtylyov <s.shtylyov@omp.ru> Reported-by: NPavan Kondeti <quic_pkondeti@quicinc.com> Tested-by: NPavan Kondeti <quic_pkondeti@quicinc.com> Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20220303110903.1662404-2-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYu Liao <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Henry Lin 提交于
stable inclusion from stable-v5.10.110 commit 3a820d1ca1233a709e41541ce7fb04928e75e700 bugzilla: https://gitee.com/openeuler/kernel/issues/I574AL Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=3a820d1ca1233a709e41541ce7fb04928e75e700 -------------------------------- commit 70c05e4c upstream. A race between system resume and device-initiated resume may result in runtime PM imbalance on USB2 root hub. If a device-initiated resume starts and system resume xhci_bus_resume() directs U0 before hub driver sees the resuming device in RESUME state, device-initiated resume will not be finished in xhci_handle_usb2_port_link_resume(). In this case, usb_hcd_end_port_resume() call is missing. This changes calls usb_hcd_end_port_resume() if resuming device reaches U0 to keep runtime PM balance. Fixes: a231ec41 ("xhci: refactor U0 link state handling in get_port_status") Cc: stable@vger.kernel.org Signed-off-by: NHenry Lin <henryl@nvidia.com> Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20220303110903.1662404-5-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYu Liao <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Anssi Hannula 提交于
stable inclusion from stable-v5.10.110 commit c41387f96a223726ca00b011ed3c1e9a645f7ac5 bugzilla: https://gitee.com/openeuler/kernel/issues/I574AL Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=c41387f96a223726ca00b011ed3c1e9a645f7ac5 -------------------------------- commit 3105bc97 upstream. xhci_decode_usbsts() is expected to return a zero-terminated string by its only caller, xhci_stop_endpoint_command_watchdog(), which directly logs the return value: xhci_warn(xhci, "USBSTS:%s\n", xhci_decode_usbsts(str, usbsts)); However, if no recognized bits are set in usbsts, the function will return without having called any sprintf() and therefore return an untouched non-zero-terminated caller-provided buffer, causing garbage to be output to log. Fix that by always including the raw value in the output. Note that before commit 4843b4b5 ("xhci: fix even more unsafe memory usage in xhci tracing") the result effect in the failure case was different as a static buffer was used here, but the code still worked incorrectly. Fixes: 9c1aa36e ("xhci: Show host status when watchdog triggers and host is assumed dead.") Cc: stable@vger.kernel.org Signed-off-by: NAnssi Hannula <anssi.hannula@bitwise.fi> Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20220303110903.1662404-3-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYu Liao <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Alan Stern 提交于
stable inclusion from stable-v5.10.110 commit 1e0f089f70db06f2d1d3e5b973de83e71c4038da bugzilla: https://gitee.com/openeuler/kernel/issues/I574AL Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=1e0f089f70db06f2d1d3e5b973de83e71c4038da -------------------------------- commit 1892bf90 upstream. The kernel test robot found a problem with the ene_ub6250 subdriver in usb-storage: It uses structures containing bitfields to represent hardware bits in its SD_STATUS, MS_STATUS, and SM_STATUS bytes. This is not safe; it presumes a particular bit ordering and it assumes the compiler will not insert padding, neither of which is guaranteed. This patch fixes the problem by changing the structures to simple u8 values, with the bitfields replaced by bitmask constants. CC: <stable@vger.kernel.org> Signed-off-by: NAlan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/YjOcbuU106UpJ/V8@rowland.harvard.eduSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYu Liao <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Xie Yongji 提交于
stable inclusion from stable-v5.10.110 commit 39a70732eb52c95c28e8424d0240ea104a9c8890 bugzilla: https://gitee.com/openeuler/kernel/issues/I574AL Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=39a70732eb52c95c28e8424d0240ea104a9c8890 -------------------------------- commit 57a13a5b upstream. The block layer can't support a block size larger than page size yet. And a block size that's too small or not a power of two won't work either. If a misconfigured device presents an invalid block size in configuration space, it will result in the kernel crash something like below: [ 506.154324] BUG: kernel NULL pointer dereference, address: 0000000000000008 [ 506.160416] RIP: 0010:create_empty_buffers+0x24/0x100 [ 506.174302] Call Trace: [ 506.174651] create_page_buffers+0x4d/0x60 [ 506.175207] block_read_full_page+0x50/0x380 [ 506.175798] ? __mod_lruvec_page_state+0x60/0xa0 [ 506.176412] ? __add_to_page_cache_locked+0x1b2/0x390 [ 506.177085] ? blkdev_direct_IO+0x4a0/0x4a0 [ 506.177644] ? scan_shadow_nodes+0x30/0x30 [ 506.178206] ? lru_cache_add+0x42/0x60 [ 506.178716] do_read_cache_page+0x695/0x740 [ 506.179278] ? read_part_sector+0xe0/0xe0 [ 506.179821] read_part_sector+0x36/0xe0 [ 506.180337] adfspart_check_ICS+0x32/0x320 [ 506.180890] ? snprintf+0x45/0x70 [ 506.181350] ? read_part_sector+0xe0/0xe0 [ 506.181906] bdev_disk_changed+0x229/0x5c0 [ 506.182483] blkdev_get_whole+0x6d/0x90 [ 506.183013] blkdev_get_by_dev+0x122/0x2d0 [ 506.183562] device_add_disk+0x39e/0x3c0 [ 506.184472] virtblk_probe+0x3f8/0x79b [virtio_blk] [ 506.185461] virtio_dev_probe+0x15e/0x1d0 [virtio] So let's use a block layer helper to validate the block size. Signed-off-by: NXie Yongji <xieyongji@bytedance.com> Acked-by: NMichael S. Tsirkin <mst@redhat.com> Link: https://lore.kernel.org/r/20211026144015.188-5-xieyongji@bytedance.comSigned-off-by: NJens Axboe <axboe@kernel.dk> Signed-off-by: NLee Jones <lee.jones@linaro.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYu Liao <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Lino Sanfilippo 提交于
stable inclusion from stable-v5.10.110 commit 290e05f346d1829e849662c97e42d5ad984f5258 bugzilla: https://gitee.com/openeuler/kernel/issues/I574AL Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=290e05f346d1829e849662c97e42d5ad984f5258 -------------------------------- commit 7e0438f8 upstream. The following sequence of operations results in a refcount warning: 1. Open device /dev/tpmrm. 2. Remove module tpm_tis_spi. 3. Write a TPM command to the file descriptor opened at step 1. ------------[ cut here ]------------ WARNING: CPU: 3 PID: 1161 at lib/refcount.c:25 kobject_get+0xa0/0xa4 refcount_t: addition on 0; use-after-free. Modules linked in: tpm_tis_spi tpm_tis_core tpm mdio_bcm_unimac brcmfmac sha256_generic libsha256 sha256_arm hci_uart btbcm bluetooth cfg80211 vc4 brcmutil ecdh_generic ecc snd_soc_core crc32_arm_ce libaes raspberrypi_hwmon ac97_bus snd_pcm_dmaengine bcm2711_thermal snd_pcm snd_timer genet snd phy_generic soundcore [last unloaded: spi_bcm2835] CPU: 3 PID: 1161 Comm: hold_open Not tainted 5.10.0ls-main-dirty #2 Hardware name: BCM2711 [<c0410c3c>] (unwind_backtrace) from [<c040b580>] (show_stack+0x10/0x14) [<c040b580>] (show_stack) from [<c1092174>] (dump_stack+0xc4/0xd8) [<c1092174>] (dump_stack) from [<c0445a30>] (__warn+0x104/0x108) [<c0445a30>] (__warn) from [<c0445aa8>] (warn_slowpath_fmt+0x74/0xb8) [<c0445aa8>] (warn_slowpath_fmt) from [<c08435d0>] (kobject_get+0xa0/0xa4) [<c08435d0>] (kobject_get) from [<bf0a715c>] (tpm_try_get_ops+0x14/0x54 [tpm]) [<bf0a715c>] (tpm_try_get_ops [tpm]) from [<bf0a7d6c>] (tpm_common_write+0x38/0x60 [tpm]) [<bf0a7d6c>] (tpm_common_write [tpm]) from [<c05a7ac0>] (vfs_write+0xc4/0x3c0) [<c05a7ac0>] (vfs_write) from [<c05a7ee4>] (ksys_write+0x58/0xcc) [<c05a7ee4>] (ksys_write) from [<c04001a0>] (ret_fast_syscall+0x0/0x4c) Exception stack(0xc226bfa8 to 0xc226bff0) bfa0: 00000000 000105b4 00000003 beafe664 00000014 00000000 bfc0: 00000000 000105b4 000103f8 00000004 00000000 00000000 b6f9c000 beafe684 bfe0: 0000006c beafe648 0001056c b6eb6944 ---[ end trace d4b8409def9b8b1f ]--- The reason for this warning is the attempt to get the chip->dev reference in tpm_common_write() although the reference counter is already zero. Since commit 8979b02a ("tpm: Fix reference count to main device") the extra reference used to prevent a premature zero counter is never taken, because the required TPM_CHIP_FLAG_TPM2 flag is never set. Fix this by moving the TPM 2 character device handling from tpm_chip_alloc() to tpm_add_char_device() which is called at a later point in time when the flag has been set in case of TPM2. Commit fdc915f7 ("tpm: expose spaces via a device link /dev/tpmrm<n>") already introduced function tpm_devs_release() to release the extra reference but did not implement the required put on chip->devs that results in the call of this function. Fix this by putting chip->devs in tpm_chip_unregister(). Finally move the new implementation for the TPM 2 handling into a new function to avoid multiple checks for the TPM_CHIP_FLAG_TPM2 flag in the good case and error cases. Cc: stable@vger.kernel.org Fixes: fdc915f7 ("tpm: expose spaces via a device link /dev/tpmrm<n>") Fixes: 8979b02a ("tpm: Fix reference count to main device") Co-developed-by: NJason Gunthorpe <jgg@ziepe.ca> Signed-off-by: NJason Gunthorpe <jgg@ziepe.ca> Signed-off-by: NLino Sanfilippo <LinoSanfilippo@gmx.de> Tested-by: NStefan Berger <stefanb@linux.ibm.com> Reviewed-by: NJason Gunthorpe <jgg@nvidia.com> Reviewed-by: NJarkko Sakkinen <jarkko@kernel.org> Signed-off-by: NJarkko Sakkinen <jarkko@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYu Liao <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Robin Murphy 提交于
stable inclusion from stable-v5.10.110 commit fcd3c31dd1608b9977860562a8847b57b0596b4b bugzilla: https://gitee.com/openeuler/kernel/issues/I574AL Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=fcd3c31dd1608b9977860562a8847b57b0596b4b -------------------------------- commit 5b61343b upstream. For various reasons based on the allocator behaviour and typical use-cases at the time, when the max32_alloc_size optimisation was introduced it seemed reasonable to couple the reset of the tracked size to the update of cached32_node upon freeing a relevant IOVA. However, since subsequent optimisations focused on helping genuine 32-bit devices make best use of even more limited address spaces, it is now a lot more likely for cached32_node to be anywhere in a "full" 32-bit address space, and as such more likely for space to become available from IOVAs below that node being freed. At this point, the short-cut in __cached_rbnode_delete_update() really doesn't hold up any more, and we need to fix the logic to reliably provide the expected behaviour. We still want cached32_node to only move upwards, but we should reset the allocation size if *any* 32-bit space has become available. Reported-by: NYunfei Wang <yf.wang@mediatek.com> Signed-off-by: NRobin Murphy <robin.murphy@arm.com> Reviewed-by: NMiles Chen <miles.chen@mediatek.com> Link: https://lore.kernel.org/r/033815732d83ca73b13c11485ac39336f15c3b40.1646318408.git.robin.murphy@arm.comSigned-off-by: NJoerg Roedel <jroedel@suse.de> Cc: Miles Chen <miles.chen@mediatek.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYu Liao <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Waiman Long 提交于
stable inclusion from stable-v5.10.110 commit 68c80088f52bfae7fc16ce0ed25ce969ddfb2ded bugzilla: https://gitee.com/openeuler/kernel/issues/I574AL Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=68c80088f52bfae7fc16ce0ed25ce969ddfb2ded -------------------------------- commit 61cc4534 upstream. It was found that reading /proc/lockdep after a lockdep splat may potentially cause an access to freed memory if lockdep_unregister_key() is called after the splat but before access to /proc/lockdep [1]. This is due to the fact that graph_lock() call in lockdep_unregister_key() fails after the clearing of debug_locks by the splat process. After lockdep_unregister_key() is called, the lock_name may be freed but the corresponding lock_class structure still have a reference to it. That invalid memory pointer will then be accessed when /proc/lockdep is read by a user and a use-after-free (UAF) error will be reported if KASAN is enabled. To fix this problem, lockdep_unregister_key() is now modified to always search for a matching key irrespective of the debug_locks state and zap the corresponding lock class if a matching one is found. [1] https://lore.kernel.org/lkml/77f05c15-81b6-bddd-9650-80d5f23fe330@i-love.sakura.ne.jp/ Fixes: 8b39adbe ("locking/lockdep: Make lockdep_unregister_key() honor 'debug_locks' again") Reported-by: NTetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> Signed-off-by: NWaiman Long <longman@redhat.com> Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: NBart Van Assche <bvanassche@acm.org> Cc: Cheng-Jui Wang <cheng-jui.wang@mediatek.com> Link: https://lkml.kernel.org/r/20220103023558.1377055-1-longman@redhat.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYu Liao <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Claudiu Beznea 提交于
stable inclusion from stable-v5.10.110 commit f19d8dfad67b641af274a9a317a12f31c430e254 bugzilla: https://gitee.com/openeuler/kernel/issues/I574AL Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f19d8dfad67b641af274a9a317a12f31c430e254 -------------------------------- [ Upstream commit e981bc74 ] Add spi_device_id tables to avoid logs like "SPI driver ksz9477-switch has no spi_device_id". Signed-off-by: NClaudiu Beznea <claudiu.beznea@microchip.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NYu Liao <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Linus Walleij 提交于
stable inclusion from stable-v5.10.110 commit ef1a6ab36dc3644073736ca5df9f6742a1aa9a64 bugzilla: https://gitee.com/openeuler/kernel/issues/I574AL Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=ef1a6ab36dc3644073736ca5df9f6742a1aa9a64 -------------------------------- [ Upstream commit e941dc13 ] I observed the following problem with the BT404 touch pad running the Phosh UI: When e.g. typing on the virtual keyboard pressing "g" would produce "ggg". After some analysis it turns out the firmware reports that three fingers hit that coordinate at the same time, finger 0, 2 and 4 (of the five available 0,1,2,3,4). DOWN Zinitix-TS 3-0020: finger 0 down (246, 395) Zinitix-TS 3-0020: finger 1 up (0, 0) Zinitix-TS 3-0020: finger 2 down (246, 395) Zinitix-TS 3-0020: finger 3 up (0, 0) Zinitix-TS 3-0020: finger 4 down (246, 395) UP Zinitix-TS 3-0020: finger 0 up (246, 395) Zinitix-TS 3-0020: finger 2 up (246, 395) Zinitix-TS 3-0020: finger 4 up (246, 395) This is one touch and release: i.e. this is all reported on touch (down) and release. There is a field in the struct touch_event called finger_cnt which is actually a bitmask of the fingers active in the event. Rename this field finger_mask as this matches the use contents better, then use for_each_set_bit() to iterate over just the fingers that are actally active. Factor out a finger reporting function zinitix_report_fingers() to handle all fingers. Also be more careful in reporting finger down/up: we were reporting every event with input_mt_report_slot_state(..., true); but this should only be reported on finger down or move, not on finger up, so also add code to check p->sub_status to see what is happening and report correctly. After this my Zinitix BT404 touchscreen report fingers flawlessly. The vendor drive I have notably does not use the "finger_cnt" and contains obviously incorrect code like this: if (touch_dev->touch_info.finger_cnt > MAX_SUPPORTED_FINGER_NUM) touch_dev->touch_info.finger_cnt = MAX_SUPPORTED_FINGER_NUM; As MAX_SUPPORTED_FINGER_NUM is an ordinal and the field is a bitmask this seems quite confused. Signed-off-by: NLinus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20220228233017.2270599-1-linus.walleij@linaro.orgSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NYu Liao <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Biju Das 提交于
stable inclusion from stable-v5.10.110 commit 21680aabc4d3b789e0379c17561d27f9bc8f6d31 bugzilla: https://gitee.com/openeuler/kernel/issues/I574AL Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=21680aabc4d3b789e0379c17561d27f9bc8f6d31 -------------------------------- [ Upstream commit ebc4cb43 ] While computing sgs in spi_map_buf(), the data type used in min_t() for max_seg_size is 'unsigned int' where as that of ctlr->max_dma_len is 'size_t'. min_t(unsigned int,x,y) gives wrong results if one of x/y is 'size_t' Consider the below examples on a 64-bit machine (ie size_t is 64-bits, and unsigned int is 32-bit). case 1) min_t(unsigned int, 5, 0x100000001); case 2) min_t(size_t, 5, 0x100000001); Case 1 returns '1', where as case 2 returns '5'. As you can see the result from case 1 is wrong. This patch fixes the above issue by using the data type of the parameters that are used in min_t with maximum data length. Fixes: commit 1a4e53d2 ("spi: Fix invalid sgs value") Reported-by: NLinus Torvalds <torvalds@linux-foundation.org> Suggested-by: NGeert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: NBiju Das <biju.das.jz@bp.renesas.com> Reviewed-by: NLad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://lore.kernel.org/r/20220316175317.465-1-biju.das.jz@bp.renesas.comSigned-off-by: NMark Brown <broonie@kernel.org> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NYu Liao <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Bartosz Golaszewski 提交于
stable inclusion from stable-v5.10.110 commit 8fb7af1b5a8350ad1052051f8c9fe88a22f3064e bugzilla: https://gitee.com/openeuler/kernel/issues/I574AL Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=8fb7af1b5a8350ad1052051f8c9fe88a22f3064e -------------------------------- [ Upstream commit 56e337f2 ] This reverts commit fc328a7d. This commit - while attempting to fix a regression - has caused a number of other problems. As the fallout from it is more significant than the initial problem itself, revert it for now before we find a correct solution. Link: https://lore.kernel.org/all/20220314192522.GA3031157@roeck-us.net/ Link: https://lore.kernel.org/stable/20220314155509.552218-1-michael@walle.cc/ Link: https://lore.kernel.org/all/20211217153555.9413-1-marcelo.jimenez@gmail.com/Signed-off-by: NBartosz Golaszewski <brgl@bgdev.pl> Reported-and-bisected-by: NGuenter Roeck <linux@roeck-us.net> Reported-by: NMichael Walle <michael@walle.cc> Cc: Thorsten Leemhuis <linux@leemhuis.info> Cc: Marcelo Roberto Jimenez <marcelo.jimenez@gmail.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NYu Liao <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Minghao Chi (CGEL ZTE) 提交于
stable inclusion from stable-v5.10.110 commit 18a4417a192f6d2527792d71963a06d36f6dd1b5 bugzilla: https://gitee.com/openeuler/kernel/issues/I574AL Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=18a4417a192f6d2527792d71963a06d36f6dd1b5 -------------------------------- [ Upstream commit 2a760554 ] It is not recommened to use platform_get_resource(pdev, IORESOURCE_IRQ) for requesting IRQ's resources any more, as they can be not ready yet in case of DT-booting. platform_get_irq() instead is a recommended way for getting IRQ even if it was not retrieved earlier. It also makes code simpler because we're getting "int" value right away and no conversion from resource to int is required. Reported-by: NZeal Robot <zealci@zte.com.cn> Signed-off-by: NMinghao Chi (CGEL ZTE) <chi.minghao@zte.com.cn> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NYu Liao <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-