- 29 6月, 2023 5 次提交
-
-
由 Long Li 提交于
Offering: HULK hulk inclusion category: bugfix bugzilla: 188865, https://gitee.com/openeuler/kernel/issues/I76JSK -------------------------------- When recovery intents, it may capture some deferred ops and commit the new intent items, if recovery intents fails, there will be no done item drop the reference to the new intent item. This leads to a memory leak as fllows: unreferenced object 0xffff888016719108 (size 432): comm "mount", pid 529, jiffies 4294706839 (age 144.463s) hex dump (first 32 bytes): 08 91 71 16 80 88 ff ff 08 91 71 16 80 88 ff ff ..q.......q..... 18 91 71 16 80 88 ff ff 18 91 71 16 80 88 ff ff ..q.......q..... backtrace: [<ffffffff8230c68f>] xfs_efi_init+0x18f/0x1d0 [<ffffffff8230c720>] xfs_extent_free_create_intent+0x50/0x150 [<ffffffff821b671a>] xfs_defer_create_intents+0x16a/0x340 [<ffffffff821bac3e>] xfs_defer_ops_capture_and_commit+0x8e/0xad0 [<ffffffff82322bb9>] xfs_cui_item_recover+0x819/0x980 [<ffffffff823289b6>] xlog_recover_process_intents+0x246/0xb70 [<ffffffff8233249a>] xlog_recover_finish+0x8a/0x9a0 [<ffffffff822eeafb>] xfs_log_mount_finish+0x2bb/0x4a0 [<ffffffff822c0f4f>] xfs_mountfs+0x14bf/0x1e70 [<ffffffff822d1f80>] xfs_fs_fill_super+0x10d0/0x1b20 [<ffffffff81a21fa2>] get_tree_bdev+0x3d2/0x6d0 [<ffffffff81a1ee09>] vfs_get_tree+0x89/0x2c0 [<ffffffff81a9f35f>] path_mount+0xecf/0x1800 [<ffffffff81a9fd83>] do_mount+0xf3/0x110 [<ffffffff81aa00e4>] __x64_sys_mount+0x154/0x1f0 [<ffffffff83968739>] do_syscall_64+0x39/0x80 Fix it by abort intent items in capture list that don't have a done item when recovery intents fail. If transaction that have deferred ops is commmit fails in xfs_defer_ops_capture_and_commit(), defer capture would not added to capture list, it also need abort too. Signed-off-by: NLong Li <leo.lilong@huawei.com>
-
由 Long Li 提交于
Offering: HULK hulk inclusion category: bugfix bugzilla: 188865, https://gitee.com/openeuler/kernel/issues/I76JSK -------------------------------- Factor out xfs_defer_pending_abort() from xfs_defer_trans_abort(), which not use transaction parameter, so it can be used after the transaction life cycle. Signed-off-by: NLong Li <leo.lilong@huawei.com>
-
由 yangerkun 提交于
Offering: HULK hulk inclusion category: bugfix bugzilla: 188870, https://gitee.com/openeuler/kernel/issues/I76JSK -------------------------------- During the test of growfs + power-off, we encountered a mounting failure issue. The specific call stack is as follows: [584505.210179] XFS (loop0): xfs_buf_find: daddr 0x6d6002 out of range, EOFS 0x6d6000 ... [584505.210739] Call Trace: [584505.210776] xfs_buf_get_map+0x44/0x230 [xfs] [584505.210780] ? trace_event_buffer_commit+0x57/0x140 [584505.210818] xfs_buf_read_map+0x54/0x280 [xfs] [584505.210858] ? xlog_recover_items_pass2+0x53/0xb0 [xfs] [584505.210899] xlog_recover_buf_commit_pass2+0x112/0x440 [xfs] [584505.210939] ? xlog_recover_items_pass2+0x53/0xb0 [xfs] [584505.210980] xlog_recover_items_pass2+0x53/0xb0 [xfs] [584505.211020] xlog_recover_commit_trans+0x2ca/0x320 [xfs] [584505.211061] xlog_recovery_process_trans+0xc6/0xf0 [xfs] [584505.211101] xlog_recover_process_data+0x9e/0x110 [xfs] [584505.211141] xlog_do_recovery_pass+0x3b4/0x5c0 [xfs] [584505.211181] xlog_do_log_recovery+0x5e/0x80 [xfs] [584505.211223] xlog_do_recover+0x33/0x1a0 [xfs] [584505.211262] xlog_recover+0xd7/0x170 [xfs] [584505.211303] xfs_log_mount+0x217/0x2b0 [xfs] [584505.211341] xfs_mountfs+0x3da/0x870 [xfs] [584505.211384] xfs_fc_fill_super+0x3fa/0x7a0 [xfs] [584505.211428] ? xfs_setup_devices+0x80/0x80 [xfs] [584505.211432] get_tree_bdev+0x16f/0x260 [584505.211434] vfs_get_tree+0x25/0xc0 [584505.211436] do_new_mount+0x156/0x1b0 [584505.211438] __se_sys_mount+0x165/0x1d0 [584505.211440] do_syscall_64+0x33/0x40 [584505.211442] entry_SYSCALL_64_after_hwframe+0x61/0xc6 After analyzing the log records, we have discovered the following content: ============================================================================ cycle: 173 version: 2 lsn: 173,2742 tail_lsn: 173,1243 length of Log Record: 25600 prev offset: 2702 num ops: 258 uuid: fb958458-48a3-4c76-ae23-7a1cf3053065 format: little endian linux h_size: 32768 ---------------------------------------------------------------------------- ... ---------------------------------------------------------------------------- Oper (100): tid: 1c010724 len: 24 clientid: TRANS flags: none BUF: #regs: 2 start blkno: 7168002 (0x6d6002) len: 1 bmap size: 1 flags: 0x3800 Oper (101): tid: 1c010724 len: 128 clientid: TRANS flags: none AGI Buffer: XAGI ver: 1 seq#: 28 len: 2048 cnt: 0 root: 3 level: 1 free#: 0x0 newino: 0x140 bucket[0 - 3]: 0xffffffff 0xffffffff 0xffffffff 0xffffffff bucket[4 - 7]: 0xffffffff 0xffffffff 0xffffffff 0xffffffff bucket[8 - 11]: 0xffffffff 0xffffffff 0xffffffff 0xffffffff bucket[12 - 15]: 0xffffffff 0xffffffff 0xffffffff 0xffffffff bucket[16 - 19]: 0xffffffff ---------------------------------------------------------------------------- ... ---------------------------------------------------------------------------- Oper (108): tid: 1c010724 len: 24 clientid: TRANS flags: none BUF: #regs: 2 start blkno: 0 (0x0) len: 1 bmap size: 1 flags: 0x9000 Oper (109): tid: 1c010724 len: 384 clientid: TRANS flags: none SUPER BLOCK Buffer: icount: 6360863066640355328 ifree: 898048 fdblks: 0 frext: 0 ---------------------------------------------------------------------------- ... We found that in the log records, the modification transaction for the expanded block is before the growfs transaction, which leads to verification failure during log replay. We need to ensure that when replaying logs, transactions related to the superblock are replayed first. Signed-off-by: NWu Guanghao <wuguanghao3@huawei.com> Signed-off-by: Nyangerkun <yangerkun@huawei.com> Signed-off-by: NLong Li <leo.lilong@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @ci-robot PR sync from: Yu Liao <liaoyu15@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/6LHNPN45YXYLIR67CAIS2GKF3WWDRBD6/ Link:https://gitee.com/openeuler/kernel/pulls/1132 Reviewed-by: sanglipeng <sanglipeng1@jd.com> Reviewed-by: Wei Li <liwei391@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @ci-robot PR sync from: Xia Fukun <xiafukun@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/LCJWGRWDEBQ2SDVR5JOAP447NA4IDPK4/ Link:https://gitee.com/openeuler/kernel/pulls/1262 Reviewed-by: Zucheng Zheng <zhengzucheng@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
- 28 6月, 2023 6 次提交
-
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @openeuler-sync-bot Origin pull request: https://gitee.com/openeuler/kernel/pulls/1077 PR sync from: Wei Li <liwei391@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/thread/J4QNVBAATO5YYR4XQ6PLJNMFVEF6SNPX/ Link:https://gitee.com/openeuler/kernel/pulls/1127 Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com>
-
由 openeuler-ci-bot 提交于
!1261 usb: gadget: udc: renesas_usb3: Fix use after free bug in renesas_usb3_remove due to race condition Merge Pull Request from: @ci-robot PR sync from: Jialin Zhang <zhangjialin11@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/7KTWBBNYFJCK5RNBNMDHJRJHHWNO7JEZ/ Link:https://gitee.com/openeuler/kernel/pulls/1261 Reviewed-by: Wei Li <liwei391@huawei.com> Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @ma-wupeng Introduce new syscall set_mempolicy_home_node and mempolicy MPOL_PREFERRED_MANY. This patch series introduces the concept of the MPOL_PREFERRED_MANY mempolicy. This mempolicy mode can be used with either the set_mempolicy(2) or mbind(2) interfaces. Like the MPOL_PREFERRED interface, it allows an application to set a preference for nodes which will fulfil memory allocation requests. Unlike the MPOL_PREFERRED mode, it takes a set of nodes. Like the MPOL_BIND interface, it works over a set of nodes. Unlike MPOL_BIND, it will not cause a SIGSEGV or invoke the OOM killer if those preferred nodes are not available. mm: add new syscall set_mempolicy_home_node Link:https://gitee.com/openeuler/kernel/pulls/637 Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 Xia Fukun 提交于
stable inclusion from stable-v5.10.173 commit e9743b3052e125c44b555f07f2876a4bdccfd983 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7F2UT CVE: CVE-2023-3220 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e9743b3052e125c44b555f07f2876a4bdccfd983 -------------------------------- [ Upstream commit 93340e10 ] As kzalloc may fail and return NULL pointer, it should be better to check pstates in order to avoid the NULL pointer dereference. Fixes: 25fdd593 ("drm/msm: Add SDM845 DPU support") Signed-off-by: NJiasheng Jiang <jiasheng@iscas.ac.cn> Reviewed-by: NAbhinav Kumar <quic_abhinavk@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/514160/ Link: https://lore.kernel.org/r/20221206080236.43687-1-jiasheng@iscas.ac.cnSigned-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NXia Fukun <xiafukun@huawei.com>
-
由 Zheng Wang 提交于
mainline inclusion from mainline-v6.4-rc1 commit 2b947f87 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7EDYS CVE: CVE-2023-35828 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2b947f8769be8b8181dc795fd292d3e7120f5204 -------------------------------- In renesas_usb3_probe, role_work is bound with renesas_usb3_role_work. renesas_usb3_start will be called to start the work. If we remove the driver which will call usbhs_remove, there may be an unfinished work. The possible sequence is as follows: CPU0 CPU1 renesas_usb3_role_work renesas_usb3_remove usb_role_switch_unregister device_unregister kfree(sw) //free usb3->role_sw usb_role_switch_set_role //use usb3->role_sw The usb3->role_sw could be freed under such circumstance and then used in usb_role_switch_set_role. This bug was found by static analysis. And note that removing a driver is a root-only operation, and should never happen in normal case. But the root user may directly remove the device which will also trigger the remove function. Fix it by canceling the work before cleanup in the renesas_usb3_remove. Fixes: 39facfa0 ("usb: gadget: udc: renesas_usb3: Add register of usb role switch") Signed-off-by: NZheng Wang <zyytlz.wz@163.com> Reviewed-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Link: https://lore.kernel.org/r/20230320062931.505170-1-zyytlz.wz@163.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @ci-robot PR sync from: Cai Xinchen <caixinchen1@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/NYV2JFJ3O7YZNQOGH4SYOIN6Z5C2J3LP/ Link:https://gitee.com/openeuler/kernel/pulls/1247 Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
- 27 6月, 2023 4 次提交
-
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @ci-robot PR sync from: Liu Shixin <liushixin2@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/5RIDEB6A7NBTUWJUHQL6MOC4ZUD2N323/ Link:https://gitee.com/openeuler/kernel/pulls/1246 Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @ci-robot PR sync from: Liu Shixin <liushixin2@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/NL3WSSDH4CG2P2J6NDYTGUIS3A4PSEFY/ Fix two bugfix of hugetlb: 1) Invalid use of nr_online_nodes; 2) Inconsistency between 1G hugepage and 2M hugepage. Peng Liu (2): hugetlb: fix wrong use of nr_online_nodes hugetlb: fix hugepages_setup when deal with pernode -- 2.25.1 Link:https://gitee.com/openeuler/kernel/pulls/1245 Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @ci-robot PR sync from: Tong Tiangen <tongtiangen@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/6SPGFOOWI5JQIZEOAPQCWFRHCMH4UUGY/ Link:https://gitee.com/openeuler/kernel/pulls/1242 Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 Jiasheng Jiang 提交于
stable inclusion from stable-v5.10.166 commit 7b4516ba56f1fcb13ffc91912f3074e28362228d category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7FCLX CVE: CVE-2023-3358 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=7b4516ba56f1fcb13ffc91912f3074e28362228d ---------------------------------------- [ Upstream commit b3d40c3e ] As the kcalloc may return NULL pointer, it should be better to check the ishtp_dma_tx_map before use in order to avoid NULL pointer dereference. Fixes: 3703f53b ("HID: intel_ish-hid: ISH Transport layer") Signed-off-by: NJiasheng Jiang <jiasheng@iscas.ac.cn> Acked-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NCai Xinchen <caixinchen1@huawei.com>
-
- 26 6月, 2023 11 次提交
-
-
由 Joao Martins 提交于
mainline inclusion from mainline-v6.2-rc1 commit 11aad263 category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I6SROX CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=11aad2631bf74b3c811dee76154702aab855a323 -------------------------------- Today with `hugetlb_free_vmemmap=on` the struct page memory that is freed back to page allocator is as following: for a 2M hugetlb page it will reuse the first 4K vmemmap page to remap the remaining 7 vmemmap pages, and for a 1G hugetlb it will remap the remaining 4095 vmemmap pages. Essentially, that means that it breaks the first 4K of a potentially contiguous chunk of memory of 32K (for 2M hugetlb pages) or 16M (for 1G hugetlb pages). For this reason the memory that it's free back to page allocator cannot be used for hugetlb to allocate huge pages of the same size, but rather only of a smaller huge page size: Trying to assign a 64G node to hugetlb (on a 128G 2node guest, each node having 64G): * Before allocation: Free pages count per migrate type at order 0 1 2 3 4 5 6 7 8 9 10 ... Node 0, zone Normal, type Movable 340 100 32 15 1 2 0 0 0 1 15558 $ echo 32768 > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages $ cat /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages 31987 * After: Node 0, zone Normal, type Movable 30893 32006 31515 7 0 0 0 0 0 0 0 Notice how the memory freed back are put back into 4K / 8K / 16K page pools. And it allocates a total of 31987 pages (63974M). To fix this behaviour rather than remapping second vmemmap page (thus breaking the contiguous block of memory backing the struct pages) repopulate the first vmemmap page with a new one. We allocate and copy from the currently mapped vmemmap page, and then remap it later on. The same algorithm works if there's a pre initialized walk::reuse_page and the head page doesn't need to be skipped and instead we remap it when the @addr being changed is the @reuse_addr. The new head page is allocated in vmemmap_remap_free() given that on restore there's no need for functional change. Note that, because right now one hugepage is remapped at a time, thus only one free 4K page at a time is needed to remap the head page. Should it fail to allocate said new page, it reuses the one that's already mapped just like before. As a result, for every 64G of contiguous hugepages it can give back 1G more of contiguous memory per 64G, while needing in total 128M new 4K pages (for 2M hugetlb) or 256k (for 1G hugetlb). After the changes, try to assign a 64G node to hugetlb (on a 128G 2node guest, each node with 64G): * Before allocation Free pages count per migrate type at order 0 1 2 3 4 5 6 7 8 9 10 ... Node 0, zone Normal, type Movable 1 1 1 0 0 1 0 0 1 1 15564 $ echo 32768 > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages $ cat /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages 32394 * After: Node 0, zone Normal, type Movable 0 50 97 108 96 81 70 46 18 0 0 In the example above, 407 more hugeltb 2M pages are allocated i.e. 814M out of the 32394 (64788M) allocated. So the memory freed back is indeed being used back in hugetlb and there's no massive order-0..order-2 pages accumulated unused. [joao.m.martins@oracle.com: v3] Link: https://lkml.kernel.org/r/20221109200623.96867-1-joao.m.martins@oracle.com [joao.m.martins@oracle.com: add smp_wmb() to ensure page contents are visible prior to PTE write] Link: https://lkml.kernel.org/r/20221110121214.6297-1-joao.m.martins@oracle.com Link: https://lkml.kernel.org/r/20221107153922.77094-1-joao.m.martins@oracle.comSigned-off-by: NJoao Martins <joao.m.martins@oracle.com> Reviewed-by: NMuchun Song <songmuchun@bytedance.com> Cc: Mike Kravetz <mike.kravetz@oracle.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Conflicts: mm/hugetlb_vmemmap.c Signed-off-by: NLiu Shixin <liushixin2@huawei.com>
-
由 Peng Liu 提交于
mainline inclusion from mainline-v5.19-rc1 commit f87442f4 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6OWV4 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f87442f407af80dac4dc81c8a7772b71b36b2e09 -------------------------------- Hugepages can be specified to pernode since "hugetlbfs: extend the definition of hugepages parameter to support node allocation", but the following problem is observed. Confusing behavior is observed when both 1G and 2M hugepage is set after "numa=off". cmdline hugepage settings: hugepagesz=1G hugepages=0:3,1:3 hugepagesz=2M hugepages=0:1024,1:1024 results: HugeTLB registered 1.00 GiB page size, pre-allocated 0 pages HugeTLB registered 2.00 MiB page size, pre-allocated 1024 pages Furthermore, confusing behavior can be also observed when an invalid node behind a valid node. To fix this, never allocate any typical hugepage when an invalid parameter is received. Link: https://lkml.kernel.org/r/20220413032915.251254-3-liupeng256@huawei.com Fixes: b5389086 ("hugetlbfs: extend the definition of hugepages parameter to support node allocation") Signed-off-by: NPeng Liu <liupeng256@huawei.com> Reviewed-by: NMike Kravetz <mike.kravetz@oracle.com> Cc: Baolin Wang <baolin.wang@linux.alibaba.com> Cc: David Hildenbrand <david@redhat.com> Cc: Liu Yuntao <liuyuntao10@huawei.com> Cc: Muchun Song <songmuchun@bytedance.com> Cc: Zhenguo Yao <yaozhenguo1@gmail.com> Cc: Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLiu Shixin <liushixin2@huawei.com>
-
由 Peng Liu 提交于
mainline inclusion from mainline-v5.19-rc1 commit 0a7a0f6f category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6OWV4 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0a7a0f6f7f3679c906fc55e3805c1d5e2c566f55 -------------------------------- Patch series "hugetlb: Fix some incorrect behavior", v3. This series fix three bugs of hugetlb: 1) Invalid use of nr_online_nodes; 2) Inconsistency between 1G hugepage and 2M hugepage; 3) Useless information in dmesg. This patch (of 4): Certain systems are designed to have sparse/discontiguous nodes. In this case, nr_online_nodes can not be used to walk through numa node. Also, a valid node may be greater than nr_online_nodes. However, in hugetlb, it is assumed that nodes are contiguous. For sparse/discontiguous nodes, the current code may treat a valid node as invalid, and will fail to allocate all hugepages on a valid node that "nid >= nr_online_nodes". As David suggested: if (tmp >= nr_online_nodes) goto invalid; Just imagine node 0 and node 2 are online, and node 1 is offline. Assuming that "node < 2" is valid is wrong. Recheck all the places that use nr_online_nodes, and repair them one by one. [liupeng256@huawei.com: v4] Link: https://lkml.kernel.org/r/20220416103526.3287348-1-liupeng256@huawei.com Link: https://lkml.kernel.org/r/20220413032915.251254-1-liupeng256@huawei.com Link: https://lkml.kernel.org/r/20220413032915.251254-2-liupeng256@huawei.com Fixes: 4178158e ("hugetlbfs: fix issue of preallocation of gigantic pages can't work") Fixes: b5389086 ("hugetlbfs: extend the definition of hugepages parameter to support node allocation") Fixes: e79ce983 ("hugetlbfs: fix a truncation issue in hugepages parameter") Fixes: f9317f77 ("hugetlb: clean up potential spectre issue warnings") Signed-off-by: NPeng Liu <liupeng256@huawei.com> Suggested-by: NDavid Hildenbrand <david@redhat.com> Reviewed-by: NBaolin Wang <baolin.wang@linux.alibaba.com> Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com> Reviewed-by: NDavidlohr Bueso <dave@stgolabs.net> Reviewed-by: NMike Kravetz <mike.kravetz@oracle.com> Acked-by: NDavid Hildenbrand <david@redhat.com> Cc: Zhenguo Yao <yaozhenguo1@gmail.com> Cc: Muchun Song <songmuchun@bytedance.com> Cc: Liu Yuntao <liuyuntao10@huawei.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Conflicts: mm/hugetlb.c Signed-off-by: NLiu Shixin <liushixin2@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @ci-robot PR sync from: Hui Tang <tanghui20@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/YBGT2EBOTBD7PFWTPX3DX74QNLLTRRVR/ Link:https://gitee.com/openeuler/kernel/pulls/1217 Reviewed-by: Zucheng Zheng <zhengzucheng@huawei.com> Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 Tong Tiangen 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7F28R CVE: NA -------------------------------- On Hisilicon LINXICORE9100 cores, sharing tlb entries on two cores when TTBRx.CNP=1 differs from the standard ARM core. This causes issues when tlb entries sharing between CPU cores. Avoid these issues by disabling CNP feature for Hisilicon LINXICORE9100 cores. Signed-off-by: NTong Tiangen <tongtiangen@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @ci-robot PR sync from: Zhang Zekun <zhangzekun11@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/OQE3GDKPH36NAFWPS5QAOYB7RBEGMMIE/ Link:https://gitee.com/openeuler/kernel/pulls/1223 Reviewed-by: Weilong Chen <chenweilong@huawei.com> Reviewed-by: Hanjun Guo <guohanjun@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @ci-robot PR sync from: "GONG, Ruiqi" <gongruiqi1@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/2UQWQFUDJJ3AA4KWKXEAZSYYXWTLW3UM/ Link:https://gitee.com/openeuler/kernel/pulls/1181 Reviewed-by: sanglipeng <sanglipeng1@jd.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @ci-robot PR sync from: Wupeng Ma <mawupeng1@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/HO6QXFWOBWOT6QFQ3P5VMHCBDUJXVKCI/ Link:https://gitee.com/openeuler/kernel/pulls/1220 Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @ci-robot PR sync from: Wupeng Ma <mawupeng1@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/DBYQ7YX2NZXNZFVXLHOUZRNTPCMRY75Q/ From: Ma Wupeng <mawupeng1@huawei.com> Fix memory reliable related issues. Ma Wupeng (3): mm: mem_reliable: Fix reliable page counter mismatch problem mm: mem_reliable: Update reliable page counter to zero if underflows efi: Disable mirror feature during crashkernel -- 2.25.1 Link:https://gitee.com/openeuler/kernel/pulls/1191 Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @ci-robot PR sync from: Wupeng Ma <mawupeng1@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/JDE2LDXAOHQR2RGYUMOGCZOLNJGVO7EW/ From: Ma Wupeng <mawupeng1@huawei.com> 1. fix memleak with efi_fake_mem 2. disable efi_fake_mem support by default for arm64 Ma Wupeng (2): efi: Fix UAF for arm64 when enable efi_fake_mem config: Disable EFI_FAKE_MEMMAP support for arm64 by default -- 2.25.1 Link:https://gitee.com/openeuler/kernel/pulls/1194 Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @ci-robot PR sync from: Liu Shixin <liushixin2@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/LB3KEGYTHZN2JVMAZADIFG73PYZUD2RV/ This series patches add swap control for memory cgroup. Patch[2] add page type in memory.reclaim interface to support reclaim anon pages. Patch[4] add memory.force_swapin interface to support swap back pages proactively. Patch[5] add memory.swap.max interface to limit usage of swap for memory cgroup. Patch[6-7] add memory.swapfile interface to limit available swap device for memory cgroup. v2->v3: Enable memcg swap qos for x86_64 and arm64 by default. v1->v2: Rebase on the latest version and fix merge conflicts. Liu Shixin (7): memcg: add page type to memory.reclaim interface memcg: introduce memcg swap qos feature memcg: introduce per-memcg swapin interface memcg: add restrict to swap to cgroup1 mm/swapfile: introduce per-memcg swapfile control mm: swap_slots: add per-type slot cache config: enable memcg swap qos for x86_64 and arm64 by default Yosry Ahmed (1): mm: vmpressure: don't count proactive reclaim in vmpressure -- 2.25.1 Link:https://gitee.com/openeuler/kernel/pulls/1228 Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
- 25 6月, 2023 14 次提交
-
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @ci-robot PR sync from: Zheng Zengkai <zhengzengkai@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/523BXW5DZPQ2JZPS3ZS4NBZ6GCRCWCWW/ Link:https://gitee.com/openeuler/kernel/pulls/1227 Reviewed-by: Jason Zeng <jason.zeng@intel.com> Reviewed-by: Xie XiuQi <xiexiuqi@huawei.com> Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com>
-
由 Liu Shixin 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I7CGGT CVE: NA -------------------------------- Support memcg swap qos by default on x86_64 and arm64 platforms. Signed-off-by: NLiu Shixin <liushixin2@huawei.com>
-
由 Liu Shixin 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I7CGGT CVE: NA -------------------------------- Since we support per-memcg swapfile control, we need per-type slot cache to optimize performance. To reduce memory waste, allocate per-type slot cache when enable feature or online the corresponding swap device. Signed-off-by: NLiu Shixin <liushixin2@huawei.com>
-
由 Liu Shixin 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I7CGGT CVE: NA -------------------------------- With memory.swapfile interface, the avail swap device can be limit for memcg. The acceptable parameters are 'all', 'none' and valid swap device. Usage: echo /dev/zram0 > memory.swapfile If the swap device is offline, the swapfile will be fallback to 'none'. Signed-off-by: NLiu Shixin <liushixin2@huawei.com>
-
由 Liu Shixin 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I7CGGT CVE: NA -------------------------------- The memsw can't limit the usage of swap space. Add memory.swap.max interface to limit the difference value of memsw.usage and memory.usage. Since a page may occupy both swap entry and a swap cache page, this value is not exactly equal to swap.usage. Signed-off-by: NLiu Shixin <liushixin2@huawei.com>
-
由 Liu Shixin 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I7CGGT CVE: NA -------------------------------- Add a new per-memcg swapin interface to load data into memory in advance to improve access efficiency. Usage: # echo 0 > memory.force_swapin Signed-off-by: NLiu Shixin <liushixin2@huawei.com>
-
由 Liu Shixin 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I7CGGT CVE: NA -------------------------------- Introduce memcg swap qos including subsequent sub-features. Add CONFIG_MEMCG_SWAP_QOS and static key memcg_swap_qos_key. Signed-off-by: NLiu Shixin <liushixin2@huawei.com>
-
由 Liu Shixin 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I7CGGT CVE: NA -------------------------------- Add anon/file to memory.reclaim interface to limit only reclaim one type pages. The lru algorithm can reclaim cold pages and balance between file and anon. But it didn't consider the speed of backend device. For example, if there is zram device, reclaim anon pages might has less impact on performance. So extend memory.reclaim interface to reclaim one type pages. Usage: "echo <size> type=anon > memory.reclaim" "echo <size> type=file > memory.reclaim" Also compatible with the previous format. Signed-off-by: NLiu Shixin <liushixin2@huawei.com>
-
由 Yosry Ahmed 提交于
mainline inclusion from mainline-v6.0-rc1 commit 73b73bac category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I7CGGT CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=73b73bac90d97400e29e585c678c4d0ebfd2680d -------------------------------- memory.reclaim is a cgroup v2 interface that allows users to proactively reclaim memory from a memcg, without real memory pressure. Reclaim operations invoke vmpressure, which is used: (a) To notify userspace of reclaim efficiency in cgroup v1, and (b) As a signal for a memcg being under memory pressure for networking (see mem_cgroup_under_socket_pressure()). For (a), vmpressure notifications in v1 are not affected by this change since memory.reclaim is a v2 feature. For (b), the effects of the vmpressure signal (according to Shakeel [1]) are as follows: 1. Reducing send and receive buffers of the current socket. 2. May drop packets on the rx path. 3. May throttle current thread on the tx path. Since proactive reclaim is invoked directly by userspace, not by memory pressure, it makes sense not to throttle networking. Hence, this change makes sure that proactive reclaim caused by memory.reclaim does not trigger vmpressure. [1] https://lore.kernel.org/lkml/CALvZod68WdrXEmBpOkadhB5GPYmCXaDZzXH=yyGOCAjFRn4NDQ@mail.gmail.com/ [yosryahmed@google.com: update documentation] Link: https://lkml.kernel.org/r/20220721173015.2643248-1-yosryahmed@google.com Link: https://lkml.kernel.org/r/20220714064918.2576464-1-yosryahmed@google.comSigned-off-by: NYosry Ahmed <yosryahmed@google.com> Acked-by: NShakeel Butt <shakeelb@google.com> Acked-by: NMichal Hocko <mhocko@suse.com> Acked-by: NDavid Rientjes <rientjes@google.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Roman Gushchin <roman.gushchin@linux.dev> Cc: Muchun Song <songmuchun@bytedance.com> Cc: Matthew Wilcox <willy@infradead.org> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: David Hildenbrand <david@redhat.com> Cc: Miaohe Lin <linmiaohe@huawei.com> Cc: NeilBrown <neilb@suse.de> Cc: Alistair Popple <apopple@nvidia.com> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Peter Xu <peterx@redhat.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
-
由 Zheng Zengkai 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5RQLJ -------------------------------- 5a2451f1 ("x86/fpu: Avoid kabi change caused by struct fpu") will lead to performance degradation of libmicro pthread_create testcase. Assuming that no 3rd party driver will reach into struct fpu, replace kabi fix macro from KABI_DEPRECATE to KABI_BROKEN_REMOVE for element "union fpregs_state state" of struct fpu. Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @ci-robot PR sync from: Zhang Xiaoxu <zhangxiaoxu5@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/OUV33PGH22SGOMA622E2MXOQEGDVIIGV/ Link:https://gitee.com/openeuler/kernel/pulls/1221 Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com>
-
由 Zhang Zekun 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7ASVH CVE: NA --------------------------------------- In fio test with iodepth=256 with allowd cpus to 0-255, we observe a serve performance decrease. The statistic of cache hit rate are relatively low. Here are some statistics about the iova_cpu_rcahe of all cpus: iova alloc order 0 1 2 3 4 5 ---------------------------------------------------------------------- average cpu_rcache hit rate 0.9941 0.7408 0.8109 0.8854 0.9082 0.8887 Jobs: 12 (f=12): [R(12)][20.0%][r=1091MiB/s][r=279k IOPS][eta 00m:28s] Jobs: 12 (f=12): [R(12)][22.2%][r=1426MiB/s][r=365k IOPS][eta 00m:28s] Jobs: 12 (f=12): [R(12)][25.0%][r=1607MiB/s][r=411k IOPS][eta 00m:27s] Jobs: 12 (f=12): [R(12)][27.8%][r=1501MiB/s][r=384k IOPS][eta 00m:26s] Jobs: 12 (f=12): [R(12)][30.6%][r=1486MiB/s][r=380k IOPS][eta 00m:25s] Jobs: 12 (f=12): [R(12)][33.3%][r=1393MiB/s][r=357k IOPS][eta 00m:24s] Jobs: 12 (f=12): [R(12)][36.1%][r=1550MiB/s][r=397k IOPS][eta 00m:23s] Jobs: 12 (f=12): [R(12)][38.9%][r=1485MiB/s][r=380k IOPS][eta 00m:22s] The under lying hisi sas driver has 16 thread irqs to free iova, but these irq call back function will only free iovas on 16 certain cpus(cpu{0, 16,32...,240}). For example, thread irq which smp affinity is 0-15, will only free iova on cpu 0. However, the driver will alloc iova on all cpus(cpu{0-255}), cpus without free iova in local cpu_rcache need to get free iovas from iova_rcache->depot. The current size of iova_rcache->depot max size is 32, and it seems to be too small for 256 users (16 cpus will put iovas to iova_rcache->depot and 240 cpus will try to get iova from it). Set iova_rcache->depot to 128 can fix the performance issue, and the performance can return to normal. iova alloc order 0 1 2 3 4 5 ---------------------------------------------------------------------- average cpu_rcache hit rate 0.9925 0.9736 0.9789 0.9867 0.9889 0.9906 Jobs: 12 (f=12): [R(12)][12.9%][r=7526MiB/s][r=1927k IOPS][eta 04m:30s] Jobs: 12 (f=12): [R(12)][13.2%][r=7527MiB/s][r=1927k IOPS][eta 04m:29s] Jobs: 12 (f=12): [R(12)][13.5%][r=7529MiB/s][r=1927k IOPS][eta 04m:28s] Jobs: 12 (f=12): [R(12)][13.9%][r=7531MiB/s][r=1928k IOPS][eta 04m:27s] Jobs: 12 (f=12): [R(12)][14.2%][r=7529MiB/s][r=1928k IOPS][eta 04m:26s] Jobs: 12 (f=12): [R(12)][14.5%][r=7528MiB/s][r=1927k IOPS][eta 04m:25s] Jobs: 12 (f=12): [R(12)][14.8%][r=7527MiB/s][r=1927k IOPS][eta 04m:24s] Jobs: 12 (f=12): [R(12)][15.2%][r=7525MiB/s][r=1926k IOPS][eta 04m:23s] Signed-off-by: NZhang Zekun <zhangzekun11@huawei.com>
-
由 Zheng Wang 提交于
stable inclusion from stable-v5.10.180 commit de19d02d734ef29f5dbd2c12fe810fa960ecd83f category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7EDZ3 CVE: CVE-2023-35829 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=de19d02d734ef29f5dbd2c12fe810fa960ecd83f -------------------------------- [ Upstream commit 3228cec2 ] In rkvdec_probe, rkvdec->watchdog_work is bound with rkvdec_watchdog_func. Then rkvdec_vp9_run may be called to start the work. If we remove the module which will call rkvdec_remove to make cleanup, there may be a unfinished work. The possible sequence is as follows, which will cause a typical UAF bug. Fix it by canceling the work before cleanup in rkvdec_remove. CPU0 CPU1 |rkvdec_watchdog_func rkvdec_remove | rkvdec_v4l2_cleanup| v4l2_m2m_release | kfree(m2m_dev); | | | v4l2_m2m_get_curr_priv | m2m_dev->curr_ctx //use Fixes: cd33c830 ("media: rkvdec: Add the rkvdec driver") Signed-off-by: NZheng Wang <zyytlz.wz@163.com> Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: NMauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NZhang Xiaoxu <zhangxiaoxu5@huawei.com>
-
由 David Hildenbrand 提交于
mainline inclusion from mainline-v5.11-rc1 commit 8dc4bb58 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7F3HQ CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8dc4bb58a146655eb057247d7c9d19e73928715b -------------------------------- virtio-mem soon wants to use offline_and_remove_memory() memory that exceeds a single Linux memory block (memory_block_size_bytes()). Let's remove that restriction. Let's remember the old state and try to restore that if anything goes wrong. While re-onlining can, in general, fail, it's highly unlikely to happen (usually only when a notifier fails to allocate memory, and these are rather rare). This will be used by virtio-mem to offline+remove memory ranges that are bigger than a single memory block - for example, with a device block size of 1 GiB (e.g., gigantic pages in the hypervisor) and a Linux memory block size of 128MB. While we could compress the state into 2 bit, using 8 bit is much easier. This handling is similar, but different to acpi_scan_try_to_offline(): a) We don't try to offline twice. I am not sure if this CONFIG_MEMCG optimization is still relevant - it should only apply to ZONE_NORMAL (where we have no guarantees). If relevant, we can always add it. b) acpi_scan_try_to_offline() simply onlines all memory in case something goes wrong. It doesn't restore previous online type. Let's do that, so we won't overwrite what e.g., user space configured. Reviewed-by: NWei Yang <richard.weiyang@linux.alibaba.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Jason Wang <jasowang@redhat.com> Cc: Pankaj Gupta <pankaj.gupta.linux@gmail.com> Cc: Michal Hocko <mhocko@kernel.org> Cc: Oscar Salvador <osalvador@suse.de> Cc: Wei Yang <richard.weiyang@linux.alibaba.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: NDavid Hildenbrand <david@redhat.com> Link: https://lore.kernel.org/r/20201112133815.13332-28-david@redhat.comSigned-off-by: NMichael S. Tsirkin <mst@redhat.com> Acked-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NMa Wupeng <mawupeng1@huawei.com>
-