- 06 3月, 2023 27 次提交
-
-
由 Xu Qiang 提交于
hulk inclusion category: other bugzilla: https://gitee.com/openeuler/kernel/issues/I6ET9W ---------------------------------------------- Signed-off-by: NXu Qiang <xuqiang36@huawei.com>
-
由 Xu Qiang 提交于
hulk inclusion category: other bugzilla: https://gitee.com/openeuler/kernel/issues/I6ET9W ---------------------------------------------- Add meminfo_k2u_size and delete duplicate or similar code. Signed-off-by: NXu Qiang <xuqiang36@huawei.com>
-
由 Xu Qiang 提交于
hulk inclusion category: other bugzilla: https://gitee.com/openeuler/kernel/issues/I6ET9W ---------------------------------------------- Add meminfo_alloc_sum_byKB and meminfo_alloc_sum, and delete duplicate or similar code. Signed-off-by: NXu Qiang <xuqiang36@huawei.com>
-
由 Xu Qiang 提交于
hulk inclusion category: other bugzilla: https://gitee.com/openeuler/kernel/issues/I6ET9W ---------------------------------------------- Signed-off-by: NXu Qiang <xuqiang36@huawei.com>
-
由 Xu Qiang 提交于
hulk inclusion category: other bugzilla: https://gitee.com/openeuler/kernel/issues/I6ET9W ---------------------------------------------- Signed-off-by: NXu Qiang <xuqiang36@huawei.com>
-
由 Xu Qiang 提交于
hulk inclusion category: other bugzilla: https://gitee.com/openeuler/kernel/issues/I6ET9W ---------------------------------------------- Signed-off-by: NXu Qiang <xuqiang36@huawei.com>
-
由 Xu Qiang 提交于
hulk inclusion category: other bugzilla: https://gitee.com/openeuler/kernel/issues/I6ET9W ---------------------------------------------- comm is not memory usage information and should not be stored in sp_proc_stat. Signed-off-by: NXu Qiang <xuqiang36@huawei.com>
-
由 Xu Qiang 提交于
hulk inclusion category: other bugzilla: https://gitee.com/openeuler/kernel/issues/I6ET9W ---------------------------------------------- The tgid information is also stored in sp_group_master. Signed-off-by: NXu Qiang <xuqiang36@huawei.com>
-
由 Wang Wensheng 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I650K6 -------------------------------- There is a double delete list problem in sp_group_exit Unable to handle kernel paging request at virtual address dead000000000108 Call trace: sp_group_exit+0x104/0x238 do_exit+0x188/0xb88 __arm64_sys_exit+0x24/0x28 Calls to sp_group_exit depends on the value of group_dead, which is controlled by CLONE_THREAD. If process A clone B with CLONE_VM and *NO* CLONE_THREAD. A and B will have group_dead = 1 and have the same mm_struct on exit. So sp_group_exit processes an mm_struct more than once. To sovle the problem, we check the tgid in sp_group_exit and allow only the parent process to continue. Similar check should be added in mg_sp_group_add/del_task. Signed-off-by: NWang Wensheng <wangwensheng4@huawei.com>
-
由 Xu Qiang 提交于
hulk inclusion category: other bugzilla: https://gitee.com/openeuler/kernel/issues/I6ET9W ---------------------------------------------- Signed-off-by: NXu Qiang <xuqiang36@huawei.com>
-
由 Xu Qiang 提交于
hulk inclusion category: other bugzilla: https://gitee.com/openeuler/kernel/issues/I6ET9W ---------------------------------------------- Signed-off-by: NXu Qiang <xuqiang36@huawei.com>
-
由 Xu Qiang 提交于
hulk inclusion category: other bugzilla: https://gitee.com/openeuler/kernel/issues/I6ET9W ---------------------------------------------- Signed-off-by: NXu Qiang <xuqiang36@huawei.com>
-
由 Xu Qiang 提交于
hulk inclusion category: other bugzilla: https://gitee.com/openeuler/kernel/issues/I6ET9W ---------------------------------------------- spa_num is not general information, but differentiated information. It should not be placed in sp_spg_stat. Signed-off-by: NXu Qiang <xuqiang36@huawei.com>
-
由 Xu Qiang 提交于
hulk inclusion category: other bugzilla: https://gitee.com/openeuler/kernel/issues/I6ET9W ---------------------------------------------- Signed-off-by: NXu Qiang <xuqiang36@huawei.com>
-
由 Xu Qiang 提交于
hulk inclusion category: other bugzilla: https://gitee.com/openeuler/kernel/issues/I6ET9W ---------------------------------------------- Signed-off-by: NXu Qiang <xuqiang36@huawei.com>
-
由 Wang Wensheng 提交于
hulk inclusion category: other bugzilla: https://gitee.com/openeuler/kernel/issues/I6G76L ---------------------------------------------- 1. Give more informaton in the error log. 2. No need to limit thre rate. 3. Add a '\n' at the end of the format string. Signed-off-by: NWang Wensheng <wangwensheng4@huawei.com>
-
由 Wang Wensheng 提交于
hulk inclusion category: other bugzilla: https://gitee.com/openeuler/kernel/issues/I6G76L ---------------------------------------------- When a process is deleted from a group, the process does not apply for memory from the shared group. Otherwise, the UAF problem occurs. We checked this, but it didn't do a good job of preventing sp_alloc and del_task concurrency. The process applies for memory after passing the check, which violates our requirements and causes problems. The solution is to place the checked code in the critical area to ensure that no memory can be allocated after the check is passed. [ T7596] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000098 [ T7596] Mem abort info: [ T7596] ESR = 0x96000004 [ T7596] EC = 0x25: DABT (current EL), IL = 32 bits [ T7596] SET = 0, FnV = 0 [ T7596] EA = 0, S1PTW = 0 [ T7596] Data abort info: [ T7596] ISV = 0, ISS = 0x00000004 [ T7596] CM = 0, WnR = 0 [ T7596] user pgtable: 4k pages, 48-bit VAs, pgdp=00000001040a3000 [ T7596] [0000000000000098] pgd=0000000000000000, p4d=0000000000000000 [ T7596] Internal error: Oops: 96000004 [#1] SMP [ T7596] Modules linked in: sharepool_dev(OE) [last unloaded: demo] [ T7596] CPU: 1 PID: 7596 Comm: test_sp_group_d Tainted: G OE 5.10.0+ #8 [ T7596] Hardware name: linux,dummy-virt (DT) [ T7596] pstate: 20000005 (nzCv daif -PAN -UAO -TCO BTYPE=--) [ T7596] pc : sp_free_area+0x34/0x120 [ T7596] lr : sp_free_area+0x30/0x120 [ T7596] sp : ffff80001c6a3b20 [ T7596] x29: ffff80001c6a3b20 x28: 0000000000000009 [ T7596] x27: 0000000000000000 x26: ffff800011c49d20 [ T7596] x25: ffff0000c227f6c0 x24: 0000000000000008 [ T7596] x23: ffff0000c0cf0ce8 x22: 0000000000000001 [ T7596] x21: ffff0000c4082b30 x20: 0000000000000000 [ T7596] x19: ffff0000c4082b00 x18: 0000000000000000 [ T7596] x17: 0000000000000000 x16: 0000000000000000 [ T7596] x15: 0000000000000000 x14: 0000000000000000 [ T7596] x13: 0000000000000000 x12: ffff0005fffe12c0 [ T7596] x11: 0000000000000008 x10: ffff0005fffe12c0 [ T7596] x9 : ffff8000103eb690 x8 : 0000000000000001 [ T7596] x7 : 0000000000210d00 x6 : 0000000000000000 [ T7596] x5 : ffff8000123edea0 x4 : 0000000000000030 [ T7596] x3 : ffffeff000000000 x2 : 0000eff000000000 [ T7596] x1 : 0000e80000000000 x0 : 0000000000000000 [ T7596] Call trace: [ T7596] sp_free_area+0x34/0x120 [ T7596] __sp_area_drop_locked+0x3c/0x60 [ T7596] sp_area_drop+0x80/0xbc [ T7596] remove_vma+0x54/0x70 [ T7596] exit_mmap+0x114/0x1d0 [ T7596] mmput+0x90/0x1ec [ T7596] exit_mm+0x1d0/0x2f0 [ T7596] do_exit+0x180/0x400 [ T7596] do_group_exit+0x40/0x114 [ T7596] get_signal+0x1e8/0x720 [ T7596] do_signal+0x11c/0x1e4 [ T7596] do_notify_resume+0x15c/0x250 [ T7596] work_pending+0xc/0x6d8 [ T7596] Code: f9400001 f9402c00 97fff0e5 aa0003f4 (f9404c00) [ T7596] ---[ end trace 3c8368d77e758ebd ]--- Signed-off-by: NWang Wensheng <wangwensheng4@huawei.com>
-
由 Wang Wensheng 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I650K6 -------------------------------- The unshare process for k2task can be normalized with k2spg since there exist a local sp group for k2task. Signed-off-by: NWang Wensheng <wangwensheng4@huawei.com>
-
由 Wang Wensheng 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I650K6 -------------------------------- Rename sp_group_drop[_locked] to sp_group_put[_locked]. Rename __sp_find_spg[_locked] to sp_group_get[_locked]. Signed-off-by: NWang Wensheng <wangwensheng4@huawei.com>
-
由 Wang Wensheng 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I650K6 -------------------------------- The process for k2task can be normalized with k2spg since there exist a local sp group for k2task. Signed-off-by: NWang Wensheng <wangwensheng4@huawei.com>
-
由 Wang Wensheng 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I650K6 -------------------------------- 1. Extract a function that initialize all the members for a newly allocated sp_group. Just to decrease the function size. 2. Move the idr_alloc to the end of the function, since we should not add an uninitialized sp_group to the global idr. 3. Rename the file for hugetlb map. Signed-off-by: NWang Wensheng <wangwensheng4@huawei.com>
-
由 Xu Qiang 提交于
hulk inclusion category: other bugzilla: https://gitee.com/openeuler/kernel/issues/I6HRGK ---------------------------------------------- Add two Helper functions sp_add_group_master and sp_del_group_master to manipulate master_list. Signed-off-by: NXu Qiang <xuqiang36@huawei.com>
-
由 Xu Qiang 提交于
hulk inclusion category: other bugzilla: https://gitee.com/openeuler/kernel/issues/I6HRGK ---------------------------------------------- In spa_overview_show, spg_info_show and spg_overview_show, there is similar code. The solution is to extract the difference into the function macro. Signed-off-by: NXu Qiang <xuqiang36@huawei.com>
-
由 Zhou Guanghui 提交于
ascend inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6HRGK -------------------------------------------- The sharepool statistics record the sharepool memory information used by all containers in the system. We do not expect to query the sharepool memory information applied by processes in other containers in the container. Therefore, the sharepool statistics cannot be queried in the container to solve this problem. Signed-off-by: NZhou Guanghui <zhouguanghui1@huawei.com>
-
由 Wang Wensheng 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I650K6 -------------------------------- If we delete a task that has not been added to any group from a specified group, NULL pointer dereference would occur. [ 162.566615] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 [ 162.567699] Mem abort info: [ 162.567971] ESR = 0x96000006 [ 162.568187] EC = 0x25: DABT (current EL), IL = 32 bits [ 162.568508] SET = 0, FnV = 0 [ 162.568670] EA = 0, S1PTW = 0 [ 162.568794] Data abort info: [ 162.568906] ISV = 0, ISS = 0x00000006 [ 162.569032] CM = 0, WnR = 0 [ 162.569314] user pgtable: 4k pages, 48-bit VAs, pgdp=00000001029e0000 [ 162.569516] [0000000000000008] pgd=00000001026da003, p4d=00000001026da003, pud=0000000102a90003, pmd=0000000000000000 [ 162.570346] Internal error: Oops: 96000006 [#1] SMP [ 162.570524] CPU: 0 PID: 880 Comm: test_sp_group_d Tainted: G W O 5.10.0+ #1 [ 162.570868] Hardware name: linux,dummy-virt (DT) [ 162.571053] pstate: 00000005 (nzcv daif -PAN -UAO -TCO BTYPE=--) [ 162.571370] pc : mg_sp_group_del_task+0x164/0x488 [ 162.571511] lr : mg_sp_group_del_task+0x158/0x488 [ 162.571644] sp : ffff8000127d3ca0 [ 162.571749] x29: ffff8000127d3ca0 x28: ffff372281b8c140 [ 162.571922] x27: 0000000000000000 x26: ffff372280b261c0 [ 162.572090] x25: ffffd075db9a9000 x24: ffffd075db9a90f8 [ 162.572259] x23: ffffd075db9a90e0 x22: 0000000000000371 [ 162.572425] x21: ffff372280826b00 x20: 0000000000000000 [ 162.572592] x19: ffffd075db12b000 x18: 0000000000000000 [ 162.572756] x17: 0000000000000000 x16: ffffd075da51e60c [ 162.572923] x15: 0000ffffdcf1a540 x14: 0000000000000000 [ 162.573087] x13: 0000000000000000 x12: 0000000000000000 [ 162.573250] x11: 0000000000000040 x10: ffffd075db5f1908 [ 162.573415] x9 : ffffd075db5f1900 x8 : ffff3722816f54b0 [ 162.573579] x7 : 0000000000000000 x6 : 0000000000000000 [ 162.573741] x5 : ffff3722816f5488 x4 : 0000000000000000 [ 162.573906] x3 : ffff372280b2620c x2 : ffff37228036b4a0 [ 162.574069] x1 : 0000000000000000 x0 : ffff372280b261c0 [ 162.574239] Call trace: [ 162.574336] mg_sp_group_del_task+0x164/0x488 [ 162.575262] dev_ioctl+0x10cc/0x2478 [sharepool_dev] [ 162.575443] __arm64_sys_ioctl+0xb4/0xf0 [ 162.575585] el0_svc_common.constprop.0+0xe4/0x2d4 [ 162.575726] do_el0_svc+0x34/0xa8 [ 162.575838] el0_svc+0x1c/0x28 [ 162.575941] el0_sync_handler+0x90/0xf0 [ 162.576060] el0_sync+0x168/0x180 [ 162.576391] Code: 97f4d4bf aa0003fa b4001580 f9420c01 (f8408c20) Signed-off-by: NWang Wensheng <wangwensheng4@huawei.com>
-
由 Chen Jun 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I64Y5Y ------------------------------- If local_group_add_task fails in init_local_group. ida free the same id twice. init_local_group local_group_add_task // failed goto free_spg free_spg: free_sp_group_locked free_sp_group_id // free spg->id free_spg_id: free_new_spg_id // double free spg->id To fix it, return before calling free_new_spg_id. Signed-off-by: NChen Jun <chenjun102@huawei.com>
-
由 Zhang Zekun 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I6HRGK ---------------------------------------- Use CONFIG_EXTEND_HUGEPAGE_MAPPING to isolate code introduced in a3425d41. Besides, use tab instead of space to match the format of Kconfig Signed-off-by: NZhang Zekun <zhangzekun11@huawei.com>
-
- 25 2月, 2023 1 次提交
-
-
由 Rik van Riel 提交于
mainline inclusion from mainline-v6.1-rc2 commit 12df140f category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6EVPO Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=12df140f0bdfae5dcfc81800970dd7f6f632e00c -------------------------------- The h->*_huge_pages counters are protected by the hugetlb_lock, but alloc_huge_page has a corner case where it can decrement the counter outside of the lock. This could lead to a corrupted value of h->resv_huge_pages, which we have observed on our systems. Take the hugetlb_lock before decrementing h->resv_huge_pages to avoid a potential race. Link: https://lkml.kernel.org/r/20221017202505.0e6a4fcd@imladris.surriel.com Fixes: a88c7695 ("mm: hugetlb: fix hugepage memory leak caused by wrong reserve count") Signed-off-by: NRik van Riel <riel@surriel.com> Reviewed-by: NMike Kravetz <mike.kravetz@oracle.com> Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> Cc: Glen McCready <gkmccready@meta.com> Cc: Mike Kravetz <mike.kravetz@oracle.com> Cc: Muchun Song <songmuchun@bytedance.com> Cc: <stable@vger.kernel.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NZhang Peng <zhangpeng362@huawei.com> Reviewed-by: Ntong tiangen <tongtiangen@huawei.com> Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
-
- 17 2月, 2023 6 次提交
-
-
由 Yang Shi 提交于
stable inclusion from stable-v5.10.148 commit 377c60dd32d3289788bdb3d8840382f79d42139b category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6D0WL Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=377c60dd32d3289788bdb3d8840382f79d42139b -------------------------------- 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: NDavid Hildenbrand <david@redhat.com> Acked-by: NPeter Xu <peterx@redhat.com> Signed-off-by: NYang Shi <shy828301@gmail.com> Reviewed-by: NJohn 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: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com> Reviewed-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Minchan Kim 提交于
stable inclusion from stable-v5.10.147 commit be2cd261ca510be5cb51b198c602c516207dd32b category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6D0W8 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=be2cd261ca510be5cb51b198c602c516207dd32b -------------------------------- commit 58d426a7 upstream. MADV_PAGEOUT tries to isolate non-LRU pages and gets a warning from isolate_lru_page below. Fix it by checking PageLRU in advance. ------------[ cut here ]------------ trying to isolate tail page WARNING: CPU: 0 PID: 6175 at mm/folio-compat.c:158 isolate_lru_page+0x130/0x140 Modules linked in: CPU: 0 PID: 6175 Comm: syz-executor.0 Not tainted 5.18.12 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:isolate_lru_page+0x130/0x140 Link: https://lore.kernel.org/linux-mm/485f8c33.2471b.182d5726afb.Coremail.hantianshuo@iie.ac.cn/ Link: https://lkml.kernel.org/r/20220908151204.762596-1-minchan@kernel.org Fixes: 1a4e58cc ("mm: introduce MADV_PAGEOUT") Signed-off-by: NMinchan Kim <minchan@kernel.org> Reported-by: N韩天ç` <hantianshuo@iie.ac.cn> Suggested-by: NYang Shi <shy828301@gmail.com> Acked-by: NYang Shi <shy828301@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com> Reviewed-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Alistair Popple 提交于
stable inclusion from stable-v5.10.147 commit 1002d5fef406c8dc685679aedb16938ad57d968c category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6D0W8 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=1002d5fef406c8dc685679aedb16938ad57d968c -------------------------------- commit 60bae737 upstream. When clearing a PTE the TLB should be flushed whilst still holding the PTL to avoid a potential race with madvise/munmap/etc. For example consider the following sequence: CPU0 CPU1 ---- ---- migrate_vma_collect_pmd() pte_unmap_unlock() madvise(MADV_DONTNEED) -> zap_pte_range() pte_offset_map_lock() [ PTE not present, TLB not flushed ] pte_unmap_unlock() [ page is still accessible via stale TLB ] flush_tlb_range() In this case the page may still be accessed via the stale TLB entry after madvise returns. Fix this by flushing the TLB while holding the PTL. Fixes: 8c3328f1 ("mm/migrate: migrate_vma() unmap page from vma while collecting pages") Link: https://lkml.kernel.org/r/9f801e9d8d830408f2ca27821f606e09aa856899.1662078528.git-series.apopple@nvidia.comSigned-off-by: NAlistair Popple <apopple@nvidia.com> Reported-by: NNadav Amit <nadav.amit@gmail.com> Reviewed-by: N"Huang, Ying" <ying.huang@intel.com> Acked-by: NDavid Hildenbrand <david@redhat.com> Acked-by: NPeter Xu <peterx@redhat.com> Cc: Alex Sierra <alex.sierra@amd.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Felix Kuehling <Felix.Kuehling@amd.com> Cc: huang ying <huang.ying.caritas@gmail.com> Cc: Jason Gunthorpe <jgg@nvidia.com> Cc: John Hubbard <jhubbard@nvidia.com> Cc: Karol Herbst <kherbst@redhat.com> Cc: Logan Gunthorpe <logang@deltatee.com> Cc: Lyude Paul <lyude@redhat.com> Cc: Matthew Wilcox <willy@infradead.org> Cc: Paul Mackerras <paulus@ozlabs.org> Cc: Ralph Campbell <rcampbell@nvidia.com> Cc: <stable@vger.kernel.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com> Reviewed-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Maurizio Lombardi 提交于
stable inclusion from stable-v5.10.147 commit a54fc536911371bd5863afdcb2418ab948484b75 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6D0W8 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=a54fc536911371bd5863afdcb2418ab948484b75 -------------------------------- commit dac22531 upstream. A number of drivers call page_frag_alloc() with a fragment's size > PAGE_SIZE. In low memory conditions, __page_frag_cache_refill() may fail the order 3 cache allocation and fall back to order 0; In this case, the cache will be smaller than the fragment, causing memory corruptions. Prevent this from happening by checking if the newly allocated cache is large enough for the fragment; if not, the allocation will fail and page_frag_alloc() will return NULL. Link: https://lkml.kernel.org/r/20220715125013.247085-1-mlombard@redhat.com Fixes: b63ae8ca ("mm/net: Rename and move page fragment handling from net/ to mm/") Signed-off-by: NMaurizio Lombardi <mlombard@redhat.com> Reviewed-by: NAlexander Duyck <alexanderduyck@fb.com> Cc: Chen Lin <chen45464546@163.com> Cc: Jakub Kicinski <kuba@kernel.org> Cc: <stable@vger.kernel.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com> Reviewed-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Mel Gorman 提交于
stable inclusion from stable-v5.10.147 commit 466a26af2d105666a427e4892b2be67cfcc55f4f category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6D0W8 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=466a26af2d105666a427e4892b2be67cfcc55f4f -------------------------------- commit 3d36424b upstream. Patrick Daly reported the following problem; NODE_DATA(nid)->node_zonelists[ZONELIST_FALLBACK] - before offline operation [0] - ZONE_MOVABLE [1] - ZONE_NORMAL [2] - NULL For a GFP_KERNEL allocation, alloc_pages_slowpath() will save the offset of ZONE_NORMAL in ac->preferred_zoneref. If a concurrent memory_offline operation removes the last page from ZONE_MOVABLE, build_all_zonelists() & build_zonerefs_node() will update node_zonelists as shown below. Only populated zones are added. NODE_DATA(nid)->node_zonelists[ZONELIST_FALLBACK] - after offline operation [0] - ZONE_NORMAL [1] - NULL [2] - NULL The race is simple -- page allocation could be in progress when a memory hot-remove operation triggers a zonelist rebuild that removes zones. The allocation request will still have a valid ac->preferred_zoneref that is now pointing to NULL and triggers an OOM kill. This problem probably always existed but may be slightly easier to trigger due to 6aa303de ("mm, vmscan: only allocate and reclaim from zones with pages managed by the buddy allocator") which distinguishes between zones that are completely unpopulated versus zones that have valid pages not managed by the buddy allocator (e.g. reserved, memblock, ballooning etc). Memory hotplug had multiple stages with timing considerations around managed/present page updates, the zonelist rebuild and the zone span updates. As David Hildenbrand puts it memory offlining adjusts managed+present pages of the zone essentially in one go. If after the adjustments, the zone is no longer populated (present==0), we rebuild the zone lists. Once that's done, we try shrinking the zone (start+spanned pages) -- which results in zone_start_pfn == 0 if there are no more pages. That happens *after* rebuilding the zonelists via remove_pfn_range_from_zone(). The only requirement to fix the race is that a page allocation request identifies when a zonelist rebuild has happened since the allocation request started and no page has yet been allocated. Use a seqlock_t to track zonelist updates with a lockless read-side of the zonelist and protecting the rebuild and update of the counter with a spinlock. [akpm@linux-foundation.org: make zonelist_update_seq static] Link: https://lkml.kernel.org/r/20220824110900.vh674ltxmzb3proq@techsingularity.net Fixes: 6aa303de ("mm, vmscan: only allocate and reclaim from zones with pages managed by the buddy allocator") Signed-off-by: NMel Gorman <mgorman@techsingularity.net> Reported-by: NPatrick Daly <quic_pdaly@quicinc.com> Acked-by: NMichal Hocko <mhocko@suse.com> Reviewed-by: NDavid Hildenbrand <david@redhat.com> Cc: <stable@vger.kernel.org> [4.9+] Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com> Reviewed-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Chao Yu 提交于
stable inclusion from stable-v5.10.146 commit 379ac7905ff3f0a6a4e507d3e9f710ec4fab9124 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6D0VX Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=379ac7905ff3f0a6a4e507d3e9f710ec4fab9124 -------------------------------- commit 7e9c323c upstream. In create_unique_id(), kmalloc(, GFP_KERNEL) can fail due to out-of-memory, if it fails, return errno correctly rather than triggering panic via BUG_ON(); kernel BUG at mm/slub.c:5893! Internal error: Oops - BUG: 0 [#1] PREEMPT SMP Call trace: sysfs_slab_add+0x258/0x260 mm/slub.c:5973 __kmem_cache_create+0x60/0x118 mm/slub.c:4899 create_cache mm/slab_common.c:229 [inline] kmem_cache_create_usercopy+0x19c/0x31c mm/slab_common.c:335 kmem_cache_create+0x1c/0x28 mm/slab_common.c:390 f2fs_kmem_cache_create fs/f2fs/f2fs.h:2766 [inline] f2fs_init_xattr_caches+0x78/0xb4 fs/f2fs/xattr.c:808 f2fs_fill_super+0x1050/0x1e0c fs/f2fs/super.c:4149 mount_bdev+0x1b8/0x210 fs/super.c:1400 f2fs_mount+0x44/0x58 fs/f2fs/super.c:4512 legacy_get_tree+0x30/0x74 fs/fs_context.c:610 vfs_get_tree+0x40/0x140 fs/super.c:1530 do_new_mount+0x1dc/0x4e4 fs/namespace.c:3040 path_mount+0x358/0x914 fs/namespace.c:3370 do_mount fs/namespace.c:3383 [inline] __do_sys_mount fs/namespace.c:3591 [inline] __se_sys_mount fs/namespace.c:3568 [inline] __arm64_sys_mount+0x2f8/0x408 fs/namespace.c:3568 Cc: <stable@kernel.org> Fixes: 81819f0f ("SLUB core") Reported-by: syzbot+81684812ea68216e08c5@syzkaller.appspotmail.com Reviewed-by: NMuchun Song <songmuchun@bytedance.com> Reviewed-by: NHyeonggon Yoo <42.hyeyoo@gmail.com> Signed-off-by: NChao Yu <chao.yu@oppo.com> Acked-by: NDavid Rientjes <rientjes@google.com> Signed-off-by: NVlastimil Babka <vbabka@suse.cz> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com> Reviewed-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
- 13 2月, 2023 2 次提交
-
-
由 Jann Horn 提交于
stable inclusion from stable-v5.10.144 commit 891f03f688de8418f44b32b88f6b4faed5b2aa81 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6D0V7 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=891f03f688de8418f44b32b88f6b4faed5b2aa81 -------------------------------- This is a stable-specific patch. I botched the stable-specific rewrite of commit b67fbebd ("mmu_gather: Force tlb-flush VM_PFNMAP vmas"): As Hugh pointed out, unmap_region() actually operates on a list of VMAs, and the variable "vma" merely points to the first VMA in that list. So if we want to check whether any of the VMAs we're operating on is PFNMAP or MIXEDMAP, we have to iterate through the list and check each VMA. Signed-off-by: NJann Horn <jannh@google.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com> Reviewed-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Yee Lee 提交于
stable inclusion from stable-v5.10.143 commit a14f1799ce373b435a2a6253747dedc23ea35abc category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6D0U6 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=a14f1799ce373b435a2a6253747dedc23ea35abc -------------------------------- This reverts commit 23c2d497. Commit 23c2d497 ("mm: kmemleak: take a full lowmem check in kmemleak_*_phys()") brought false leak alarms on some archs like arm64 that does not init pfn boundary in early booting. The final solution lands on linux-6.0: commit 0c24e061 ("mm: kmemleak: add rbtree and store physical address for objects allocated with PA"). Revert this commit before linux-6.0. The original issue of invalid PA can be mitigated by additional check in devicetree. The false alarm report is as following: Kmemleak output: (Qemu/arm64) unreferenced object 0xffff0000c0170a00 (size 128): comm "swapper/0", pid 1, jiffies 4294892404 (age 126.208s) hex dump (first 32 bytes): 62 61 73 65 00 00 00 00 00 00 00 00 00 00 00 00 base............ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<(____ptrval____)>] __kmalloc_track_caller+0x1b0/0x2e4 [<(____ptrval____)>] kstrdup_const+0x8c/0xc4 [<(____ptrval____)>] kvasprintf_const+0xbc/0xec [<(____ptrval____)>] kobject_set_name_vargs+0x58/0xe4 [<(____ptrval____)>] kobject_add+0x84/0x100 [<(____ptrval____)>] __of_attach_node_sysfs+0x78/0xec [<(____ptrval____)>] of_core_init+0x68/0x104 [<(____ptrval____)>] driver_init+0x28/0x48 [<(____ptrval____)>] do_basic_setup+0x14/0x28 [<(____ptrval____)>] kernel_init_freeable+0x110/0x178 [<(____ptrval____)>] kernel_init+0x20/0x1a0 [<(____ptrval____)>] ret_from_fork+0x10/0x20 This pacth is also applicable to linux-5.17.y/linux-5.18.y/linux-5.19.y Cc: <stable@vger.kernel.org> Signed-off-by: NYee Lee <yee.lee@mediatek.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com> Reviewed-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
- 09 2月, 2023 3 次提交
-
-
由 Steven Price 提交于
stable inclusion from stable-v5.10.142 commit 47a73e5e6ba42e42db2d1400478b2e132e25ceb4 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6CSFH Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=47a73e5e6ba42e42db2d1400478b2e132e25ceb4 -------------------------------- [ Upstream commit 8782fb61 ] The mmap lock protects the page walker from changes to the page tables during the walk. However a read lock is insufficient to protect those areas which don't have a VMA as munmap() detaches the VMAs before downgrading to a read lock and actually tearing down PTEs/page tables. For users of walk_page_range() the solution is to simply call pte_hole() immediately without checking the actual page tables when a VMA is not present. We now never call __walk_page_range() without a valid vma. For walk_page_range_novma() the locking requirements are tightened to require the mmap write lock to be taken, and then walking the pgd directly with 'no_vma' set. This in turn means that all page walkers either have a valid vma, or it's that special 'novma' case for page table debugging. As a result, all the odd '(!walk->vma && !walk->no_vma)' tests can be removed. Fixes: dd2283f2 ("mm: mmap: zap pages with read mmap_sem in munmap") Reported-by: NJann Horn <jannh@google.com> Signed-off-by: NSteven Price <steven.price@arm.com> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Konstantin Khlebnikov <koct9i@gmail.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com> Reviewed-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Liu Shixin 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6ADCF CVE: NA -------------------------------- syzbot is reporting GFP_KERNEL allocation with oom_lock held when reporting memcg OOM [1]. If this allocation triggers the global OOM situation then the system can livelock because the GFP_KERNEL allocation with oom_lock held cannot trigger the global OOM killer because __alloc_pages_may_oom() fails to hold oom_lock. The problem mentioned above has been fixed by patch[2]. The is the same problem in memcg_memfs_info feature too. Refer to the patch[2], fix it by removing the allocation from mem_cgroup_print_memfs_info() completely, and pass static buffer when calling from memcg OOM path. Link: https://syzkaller.appspot.com/bug?extid=2d2aeadc6ce1e1f11d45 [1] Link: https://lkml.kernel.org/r/86afb39f-8c65-bec2-6cfc-c5e3cd600c0b@I-love.SAKURA.ne.jp [2] Fixes: 6b1d4d3a ("mm/memcg_memfs_info: show files that having pages charged in mem_cgroup") Signed-off-by: NLiu Shixin <liushixin2@huawei.com> Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com> Reviewed-by: NCai Xinchen <caixinchen1@huawei.com> Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com> (cherry picked from commit d2218535)
-
由 Tetsuo Handa 提交于
mainline inclusion from mainline-v6.0-rc1 commit 68aaee14 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6ADCF CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=68aaee147e597b495622b7c9038e5922c7c61f57 -------------------------------- syzbot is reporting GFP_KERNEL allocation with oom_lock held when reporting memcg OOM [1]. If this allocation triggers the global OOM situation then the system can livelock because the GFP_KERNEL allocation with oom_lock held cannot trigger the global OOM killer because __alloc_pages_may_oom() fails to hold oom_lock. Fix this problem by removing the allocation from memory_stat_format() completely, and pass static buffer when calling from memcg OOM path. Note that the caller holding filesystem lock was the trigger for syzbot to report this locking dependency. Doing GFP_KERNEL allocation with filesystem lock held can deadlock the system even without involving OOM situation. Link: https://syzkaller.appspot.com/bug?extid=2d2aeadc6ce1e1f11d45 [1] Link: https://lkml.kernel.org/r/86afb39f-8c65-bec2-6cfc-c5e3cd600c0b@I-love.SAKURA.ne.jp Fixes: c8713d0b ("mm: memcontrol: dump memory.stat during cgroup OOM") Signed-off-by: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Reported-by: Nsyzbot <syzbot+2d2aeadc6ce1e1f11d45@syzkaller.appspotmail.com> Suggested-by: NMichal Hocko <mhocko@suse.com> Acked-by: NMichal Hocko <mhocko@suse.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Roman Gushchin <roman.gushchin@linux.dev> Cc: Shakeel Butt <shakeelb@google.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> conflicts: mm/memcontrol.c Signed-off-by: NCai Xinchen <caixinchen1@huawei.com> Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com> Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com> Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com> (cherry picked from commit ee2d7b76)
-
- 31 1月, 2023 1 次提交
-
-
由 Alistair Popple 提交于
mainline inclusion from mainline-v6.1-rc7 commit 4a955bed category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6BG56 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4a955bed882e734807024afd8f53213d4c61ff97 -------------------------------- The migrate_to_ram() callback should always succeed, but in rare cases can fail usually returning VM_FAULT_SIGBUS. Commit 16ce101d ("mm/memory.c: fix race when faulting a device private page") incorrectly stopped passing the return code up the stack. Fix this by setting the ret variable, restoring the previous behaviour on migrate_to_ram() failure. Link: https://lkml.kernel.org/r/20221114115537.727371-1-apopple@nvidia.com Fixes: 16ce101d ("mm/memory.c: fix race when faulting a device private page") Signed-off-by: NAlistair Popple <apopple@nvidia.com> Acked-by: NDavid Hildenbrand <david@redhat.com> Reviewed-by: NFelix Kuehling <Felix.Kuehling@amd.com> Cc: Ralph Campbell <rcampbell@nvidia.com> Cc: John Hubbard <jhubbard@nvidia.com> Cc: Alex Sierra <alex.sierra@amd.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Lyude Paul <lyude@redhat.com> Cc: Jason Gunthorpe <jgg@nvidia.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NMa Wupeng <mawupeng1@huawei.com> Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com> Reviewed-by: Ntong tiangen <tongtiangen@huawei.com> Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com> (cherry picked from commit 1254c416)
-