[sync] PR-358: Backport CVEs, bugfixes and other · Pull Request !359 · openEuler/kernel

### 1. Origin pull request:
https://gitee.com/openeuler/kernel/pulls/358

### 2. Original pull request related issue(s):
https://gitee.com/openeuler/kernel/issues/I699A9

### 3. Original pull request related commit(s):
| Sha | Datetime | Message |
|---|---|---|
|[b84980c2](https://gitee.com/openeuler/kernel/commits/b84980c28e3a989d2bfc5bf16237196adf25f44f)|2023-01-18 10:58:46 +0800 CST|binder: fix UAF of alloc->vma in race with munmap() stable inclusion from stable-v5.10.154 commit 015ac18be7de25d17d6e5f1643cb3b60bfbe859e category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I68WW5 CVE: CVE-2023-20928 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=015ac18be7de25d17d6e5f1643cb3b60bfbe859e -------------------------------- In commit 720c24192404 ("ANDROID: binder: change down_write to down_read") binder assumed the mmap read lock is sufficient to protect alloc->vma inside binder_update_page_range(). This used to be accurate until commit dd2283f2605e ("mm: mmap: zap pages with read mmap_sem in munmap"), which now downgrades the mmap_lock after detaching the vma from the rbtree in munmap(). Then it proceeds to teardown and free the vma with only the read lock held. This means that accesses to alloc->vma in binder_update_page_range() now will race with vm_area_free() in munmap() and can cause a UAF as shown in the following KASAN trace: ================================================================== BUG: KASAN: use-after-free in vm_insert_page+0x7c/0x1f0 Read of size 8 at addr ffff16204ad00600 by task server/558 CPU: 3 PID: 558 Comm: server Not tainted 5.10.150-00001-gdc8dcf942daa #1 Hardware name: linux,dummy-virt (DT) Call trace: dump_backtrace+0x0/0x2a0 show_stack+0x18/0x2c dump_stack+0xf8/0x164 print_address_description.constprop.0+0x9c/0x538 kasan_report+0x120/0x200 __asan_load8+0xa0/0xc4 vm_insert_page+0x7c/0x1f0 binder_update_page_range+0x278/0x50c binder_alloc_new_buf+0x3f0/0xba0 binder_transaction+0x64c/0x3040 binder_thread_write+0x924/0x2020 binder_ioctl+0x1610/0x2e5c __arm64_sys_ioctl+0xd4/0x120 el0_svc_common.constprop.0+0xac/0x270 do_el0_svc+0x38/0xa0 el0_svc+0x1c/0x2c el0_sync_handler+0xe8/0x114 el0_sync+0x180/0x1c0 Allocated by task 559: kasan_save_stack+0x38/0x6c __kasan_kmalloc.constprop.0+0xe4/0xf0 kasan_slab_alloc+0x18/0x2c kmem_cache_alloc+0x1b0/0x2d0 vm_area_alloc+0x28/0x94 mmap_region+0x378/0x920 do_mmap+0x3f0/0x600 vm_mmap_pgoff+0x150/0x17c ksys_mmap_pgoff+0x284/0x2dc __arm64_sys_mmap+0x84/0xa4 el0_svc_common.constprop.0+0xac/0x270 do_el0_svc+0x38/0xa0 el0_svc+0x1c/0x2c el0_sync_handler+0xe8/0x114 el0_sync+0x180/0x1c0 Freed by task 560: kasan_save_stack+0x38/0x6c kasan_set_track+0x28/0x40 kasan_set_free_info+0x24/0x4c __kasan_slab_free+0x100/0x164 kasan_slab_free+0x14/0x20 kmem_cache_free+0xc4/0x34c vm_area_free+0x1c/0x2c remove_vma+0x7c/0x94 __do_munmap+0x358/0x710 __vm_munmap+0xbc/0x130 __arm64_sys_munmap+0x4c/0x64 el0_svc_common.constprop.0+0xac/0x270 do_el0_svc+0x38/0xa0 el0_svc+0x1c/0x2c el0_sync_handler+0xe8/0x114 el0_sync+0x180/0x1c0 [...] ================================================================== To prevent the race above, revert back to taking the mmap write lock inside binder_update_page_range(). One might expect an increase of mmap lock contention. However, binder already serializes these calls via top level alloc->mutex. Also, there was no performance impact shown when running the binder benchmark tests. Note this patch is specific to stable branches 5.4 and 5.10. Since in newer kernel releases binder no longer caches a pointer to the vma. Instead, it has been refactored to use vma_lookup() which avoids the issue described here. This switch was introduced in commit a43cfc87caaf ("android: binder: stop saving a pointer to the VMA"). Fixes: dd2283f2605e ("mm: mmap: zap pages with read mmap_sem in munmap") Reported-by: Jann Horn <jannh@google.com> Cc: <stable@vger.kernel.org> # 5.10.x Cc: Minchan Kim <minchan@kernel.org> Cc: Yang Shi <yang.shi@linux.alibaba.com> Cc: Liam Howlett <liam.howlett@oracle.com> Signed-off-by: Carlos Llamas <cmllamas@google.com> Acked-by: Todd Kjos <tkjos@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Chen Jiahao <chenjiahao16@huawei.com> Reviewed-by: Liao Chang <liaochang1@huawei.com> Reviewed-by: Zhang Jianhua <chris.zjh@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> |
|[9a7973c3](https://gitee.com/openeuler/kernel/commits/9a7973c30254ebeecb1ced4f89eaae88ce561d00)|2023-01-18 10:58:45 +0800 CST|io_uring: add missing item types for splice request stable inclusion from stable-v5.10.160 commit 75454b4bbfc7e6a4dd8338556f36ea9107ddf61a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6AUN9 CVE: CVE-2022-4696 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.10.y&id=75454b4bbfc7e6a4dd8338556f36ea9107ddf61a -------------------------------- Splice is like read/write and should grab current->nsproxy, denoted by IO_WQ_WORK_FILES as it refers to current->files as well Signed-off-by: Bing-Jhong Billy Jheng <billy@starlabs.sg> Reviewed-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Li Lingfeng <lilingfeng3@huawei.com> Reviewed-by: Zhang Yi <yi.zhang@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> |
|[55da2af2](https://gitee.com/openeuler/kernel/commits/55da2af2d9653751b93d63e7ffa8d6f67503ffb7)|2023-01-18 10:58:44 +0800 CST|xfs: fix overfilling of reserve pool stable inclusion from stable-v5.10.141 commit f168801da95fe62c6751235665c27edf5ca2458a category: bugfix bugzilla: 188251,https://gitee.com/openeuler/kernel/issues/I685FC CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f168801da95fe62c6751235665c27edf5ca2458a -------------------------------- commit 82be38bcf8a2e056b4c99ce79a3827fa743df6ec upstream. Due to cycling of m_sb_lock, it's possible for multiple callers of xfs_reserve_blocks to race at changing the pool size, subtracting blocks from fdblocks, and actually putting it in the pool. The result of all this is that we can overfill the reserve pool to hilarious levels. xfs_mod_fdblocks, when called with a positive value, already knows how to take freed blocks and either fill the reserve until it's full, or put them in fdblocks. Use that instead of setting m_resblks_avail directly. Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Dave Chinner <dchinner@redhat.com> Signed-off-by: Amir Goldstein <amir73il@gmail.com> Acked-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: yangerkun <yangerkun@huawei.com> Reviewed-by: Zhang Yi <yi.zhang@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> |
|[d7ed84ea](https://gitee.com/openeuler/kernel/commits/d7ed84eab34c9d40bfec9fdf3dd69aa8f49c737d)|2023-01-18 10:58:43 +0800 CST|xfs: always succeed at setting the reserve pool size stable inclusion from stable-v5.10.141 commit 72a259bdd50dd6646a88e29fc769e50377e06d57 category: bugfix bugzilla: 188251,https://gitee.com/openeuler/kernel/issues/I685FC CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=72a259bdd50dd6646a88e29fc769e50377e06d57 -------------------------------- commit 0baa2657dc4d79202148be79a3dc36c35f425060 upstream. Nowadays, xfs_mod_fdblocks will always choose to fill the reserve pool with freed blocks before adding to fdblocks. Therefore, we can change the behavior of xfs_reserve_blocks slightly -- setting the target size of the pool should always succeed, since a deficiency will eventually be made up as blocks get freed. Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Dave Chinner <dchinner@redhat.com> Signed-off-by: Amir Goldstein <amir73il@gmail.com> Acked-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: yangerkun <yangerkun@huawei.com> Reviewed-by: Zhang Yi <yi.zhang@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> |
|[a0a575a8](https://gitee.com/openeuler/kernel/commits/a0a575a8d5f1cdb04719a95d2e2950e1fc4cf4d9)|2023-01-18 10:58:42 +0800 CST|xfs: remove infinite loop when reserving free block pool stable inclusion from stable-v5.10.141 commit cb41f22df3ec7b0b4f7cd9a730a538645e324f2f category: bugfix bugzilla: 188251,https://gitee.com/openeuler/kernel/issues/I685FC CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=cb41f22df3ec7b0b4f7cd9a730a538645e324f2f -------------------------------- commit 15f04fdc75aaaa1cccb0b8b3af1be290e118a7bc upstream. [Added wrapper xfs_fdblocks_unavailable() for 5.10.y backport] Infinite loops in kernel code are scary. Calls to xfs_reserve_blocks should be rare (people should just use the defaults!) so we really don't need to try so hard. Simplify the logic here by removing the infinite loop. Cc: Brian Foster <bfoster@redhat.com> Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Dave Chinner <dchinner@redhat.com> Signed-off-by: Amir Goldstein <amir73il@gmail.com> Acked-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Conflicts: 	fs/xfs/xfs_mount.h Signed-off-by: yangerkun <yangerkun@huawei.com> Reviewed-by: Zhang Yi <yi.zhang@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> |
|[74737d9b](https://gitee.com/openeuler/kernel/commits/74737d9b328f4deb67ae2444e7935ba4486a4a5a)|2023-01-18 10:58:41 +0800 CST|xfs: use current->journal_info for detecting transaction recursion stable inclusion from stable-v5.10.129 commit b261cd005ab980c4018634a849f77e036bfd4f80 category: bugfix bugzilla: 188251,https://gitee.com/openeuler/kernel/issues/I5YNDQ CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=b261cd005ab980c4018634a849f77e036bfd4f80 -------------------------------- commit 756b1c343333a5aefcc26b0409f3fd16f72281bf upstream. Because the iomap code using PF_MEMALLOC_NOFS to detect transaction recursion in XFS is just wrong. Remove it from the iomap code and replace it with XFS specific internal checks using current->journal_info instead. [djwong: This change also realigns the lifetime of NOFS flag changes to match the incore transaction, instead of the inconsistent scheme we have now.] Fixes: 9070733b4efa ("xfs: abstract PF_FSTRANS to PF_MEMALLOC_NOFS") Signed-off-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Amir Goldstein <amir73il@gmail.com> Acked-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Conflicts: 	fs/xfs/xfs_aops.c 	fs/xfs/xfs_trans.c 	fs/xfs/xfs_trans.h Signed-off-by: yangerkun <yangerkun@huawei.com> Reviewed-by: Zhang Yi <yi.zhang@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> |
|[2c07266a](https://gitee.com/openeuler/kernel/commits/2c07266a13357ca7b0867809ad009dcf9ebf5025)|2023-01-18 10:58:40 +0800 CST|fix kabi broken due to may_pollfree hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I685FC CVE: NA -------------------------------- Commit 0845c5803f3f("[Backport] io_uring: disable polling pollfree files") adds a new member in file_operations, so we need to fix kabi broken problem. Signed-off-by: Li Lingfeng <lilingfeng3@huawei.com> Reviewed-by: Zhang Yi <yi.zhang@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> |
|[b3851214](https://gitee.com/openeuler/kernel/commits/b38512149040443ec2dee0c0e838990cb710d619)|2023-01-18 10:58:39 +0800 CST|io_uring: disable polling pollfree files stable inclusion from stable-v5.10.141 commit 28d8d2737e82fc29ff9e788597661abecc7f7994 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I685FC CEV: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v5.10.162&id=28d8d2737e82fc29ff9e788597661abecc7f7994 -------------------------------- Older kernels lack io_uring POLLFREE handling. As only affected files are signalfd and android binder the safest option would be to disable polling those files via io_uring and hope there are no users. Fixes: 221c5eb233823 ("io_uring: add support for IORING_OP_POLL") Signed-off-by: Pavel Begunkov <asml.silence@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> conflicts: include/linux/fs.h Signed-off-by: Li Lingfeng <lilingfeng3@huawei.com> Reviewed-by: Zhang Yi <yi.zhang@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> |
|[3c316171](https://gitee.com/openeuler/kernel/commits/3c316171197467b1f2110c266db1a393943db31c)|2023-01-18 10:58:38 +0800 CST|ksmbd: check nt_len to be at least CIFS_ENCPWD_SIZE in ksmbd_decode_ntlmssp_auth_blob mainline inclusion from mainline-v6.2-rc4 commit 797805d81baa814f76cf7bdab35f86408a79d707 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6A0GH CVE: CVE-2023-0210 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=797805d81baa814f76cf7bdab35f86408a79d707 -------------------------------- "nt_len - CIFS_ENCPWD_SIZE" is passed directly from ksmbd_decode_ntlmssp_auth_blob to ksmbd_auth_ntlmv2. Malicious requests can set nt_len to less than CIFS_ENCPWD_SIZE, which results in a negative number (or large unsigned value) used for a subsequent memcpy in ksmbd_auth_ntlvm2 and can cause a panic. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Cc: stable@vger.kernel.org Signed-off-by: William Liu <will@willsroot.io> Signed-off-by: Hrvoje Mišetić <misetichrvoje@gmail.com> Acked-by: Namjae Jeon <linkinjeon@kernel.org> Signed-off-by: Steve French <stfrench@microsoft.com> Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com> Reviewed-by: Zhang Yi <yi.zhang@huawei.com> Reviewed-by: Xiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> |
|[056e261b](https://gitee.com/openeuler/kernel/commits/056e261ba9267569da65b49a922d983c9883b27a)|2023-01-18 10:58:37 +0800 CST|driver: char: delete svm.c hulk inclusion category: other bugzilla: https://gitee.com/openeuler/kernel/issues/I69JDF CVE: NA ------------------------------- Delete svm driver, as it is specially designed for Hisilicon platform. Signed-off-by: Guo Mengqi <guomengqi3@huawei.com> Reviewed-by: chenweilong <chenweilong@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> |
|[49457cf7](https://gitee.com/openeuler/kernel/commits/49457cf742aafa7226b0ae3761b5c89c7add4dd8)|2023-01-18 10:58:36 +0800 CST|mm: fix unexpected changes to {failslab|fail_page_alloc}.attr mainline inclusion from mainline-v6.1-rc7 commit ea4452de2ae987342fadbdd2c044034e6480daad category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I69VVC CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=ea4452de2ae987342fadbdd2c044034e6480daad -------------------------------- When we specify __GFP_NOWARN, we only expect that no warnings will be issued for current caller. But in the __should_failslab() and __should_fail_alloc_page(), the local GFP flags alter the global {failslab|fail_page_alloc}.attr, which is persistent and shared by all tasks. This is not what we expected, let's fix it. [akpm@linux-foundation.org: unexport should_fail_ex()] Link: https://lkml.kernel.org/r/20221118100011.2634-1-zhengqi.arch@bytedance.com Fixes: 3f913fc5f974 ("mm: fix missing handler for __GFP_NOWARN") Signed-off-by: Qi Zheng <zhengqi.arch@bytedance.com> Reported-by: Dmitry Vyukov <dvyukov@google.com> Reviewed-by: Akinobu Mita <akinobu.mita@gmail.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Cc: Akinobu Mita <akinobu.mita@gmail.com> Cc: Matthew Wilcox <willy@infradead.org> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Ye Weihua <yeweihua4@huawei.com> Reviewed-by: tong tiangen <tongtiangen@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> |
|[86f3bddf](https://gitee.com/openeuler/kernel/commits/86f3bddfc99aee7ccd9b019c8462e40226600639)|2023-01-18 10:58:35 +0800 CST|fs/ntfs3: Fix attr_punch_hole() null pointer derenference mainline inclusion from mainline-v6.2-rc1 commit 6d5c9e79b726cc473d40e9cb60976dbe8e669624 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I683ER CVE: CVE-2022-4842 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6d5c9e79b726cc473d40e9cb60976dbe8e669624 -------------------------------- The bug occours due to a misuse of `attr` variable instead of `attr_b`. `attr` is being initialized as NULL, then being derenfernced as `attr->res.data_size`. This bug causes a crash of the ntfs3 driver itself, If compiled directly to the kernel, it crashes the whole system. Signed-off-by: Alon Zahavi <zahavi.alon@gmail.com> Co-developed-by: Tal Lossos <tallossos@gmail.com> Signed-off-by: Tal Lossos <tallossos@gmail.com> Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com> Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com> Reviewed-by: Zhang Yi <yi.zhang@huawei.com> Reviewed-by: Xiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> |
|[89a596c1](https://gitee.com/openeuler/kernel/commits/89a596c10ffd8e8d471edd77558b230bafbce513)|2023-01-18 10:58:34 +0800 CST|tracing/osnoise: Do not unregister events twice mainline inclusion from mainline-v5.17-rc8 commit f0cfe17bcc1dd2f0872966b554a148e888833ee9 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I699A9 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f0cfe17bcc1dd2f0872966b554a148e888833ee9 -------------------------------- Nicolas reported that using: # trace-cmd record -e all -M 10 -p osnoise --poll Resulted in the following kernel warning: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1217 at kernel/tracepoint.c:404 tracepoint_probe_unregister+0x280/0x370 [...] CPU: 0 PID: 1217 Comm: trace-cmd Not tainted 5.17.0-rc6-next-20220307-nico+ #19 RIP: 0010:tracepoint_probe_unregister+0x280/0x370 [...] CR2: 00007ff919b29497 CR3: 0000000109da4005 CR4: 0000000000170ef0 Call Trace: <TASK> osnoise_workload_stop+0x36/0x90 tracing_set_tracer+0x108/0x260 tracing_set_trace_write+0x94/0xd0 ? __check_object_size.part.0+0x10a/0x150 ? selinux_file_permission+0x104/0x150 vfs_write+0xb5/0x290 ksys_write+0x5f/0xe0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7ff919a18127 [...] ---[ end trace 0000000000000000 ]--- The warning complains about an attempt to unregister an unregistered tracepoint. This happens on trace-cmd because it first stops tracing, and then switches the tracer to nop. Which is equivalent to: # cd /sys/kernel/tracing/ # echo osnoise > current_tracer # echo 0 > tracing_on # echo nop > current_tracer The osnoise tracer stops the workload when no trace instance is actually collecting data. This can be caused both by disabling tracing or disabling the tracer itself. To avoid unregistering events twice, use the existing trace_osnoise_callback_enabled variable to check if the events (and the workload) are actually active before trying to deactivate them. Link: https://lore.kernel.org/all/c898d1911f7f9303b7e14726e7cc9678fbfb4a0e.camel@redhat.com/ Link: https://lkml.kernel.org/r/938765e17d5a781c2df429a98f0b2e7cc317b022.1646823913.git.bristot@kernel.org Cc: stable@vger.kernel.org Cc: Marcelo Tosatti <mtosatti@redhat.com> Fixes: 2fac8d6486d5 ("tracing/osnoise: Allow multiple instances of the same tracer") Reported-by: Nicolas Saenz Julienne <nsaenzju@redhat.com> Signed-off-by: Daniel Bristot de Oliveira <bristot@kernel.org> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org> Signed-off-by: Zheng Yejian <zhengyejian1@huawei.com> Reviewed-by: Xu Kuohai <xukuohai@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> |
|[4f2fd1fb](https://gitee.com/openeuler/kernel/commits/4f2fd1fb44add914aa4ebee3ee82146f0881a5b4)|2023-01-18 10:58:33 +0800 CST|tracing/osnoise: Properly unhook events if start_per_cpu_kthreads() fails mainline inclusion from mainline-v5.17-rc1 commit 0878355b51f5f26632e652c848a8e174bb02d22d category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I699A9 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0878355b51f5f26632e652c848a8e174bb02d22d -------------------------------- If start_per_cpu_kthreads() called from osnoise_workload_start() returns error, event hooks are left in broken state: unhook_irq_events() called but unhook_thread_events() and unhook_softirq_events() not called, and trace_osnoise_callback_enabled flag not cleared. On the next tracer enable, hooks get not installed due to trace_osnoise_callback_enabled flag. And on the further tracer disable an attempt to remove non-installed hooks happened, hitting a WARN_ON_ONCE() in tracepoint_remove_func(). Fix the error path by adding the missing part of cleanup. While at this, introduce osnoise_unhook_events() to avoid code duplication between this error path and normal tracer disable. Link: https://lkml.kernel.org/r/20220109153459.3701773-1-nikita.yushchenko@virtuozzo.com Cc: stable@vger.kernel.org Fixes: bce29ac9ce0b ("trace: Add osnoise tracer") Acked-by: Daniel Bristot de Oliveira <bristot@kernel.org> Signed-off-by: Nikita Yushchenko <nikita.yushchenko@virtuozzo.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Zheng Yejian <zhengyejian1@huawei.com> Reviewed-by: Xu Kuohai <xukuohai@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> |

GVPopenEuler/kernel

搜索帮助

GVP openEuler/kernel