Skip to content

K
Kernel

openeuler / Kernel
大约 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 07 3月, 2023 1 次提交
  3. 23 2月, 2023 1 次提交
  5. 16 2月, 2023 1 次提交
    • W
      arm64/ascend: Delete unused feature auto-tuning hugepage · 9fb6a430
      由 Wang Wensheng 提交于 
      hulk inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I6FK2R
CVE: NA

-------------------------------

This feature is not actually used and introduce a list double added
problem. Just delete its source.

------------[ cut here ]------------
list_add double add: new=ffff20000cdd1780, prev=ffff20000cdd1780, next=ffff20000cd1f300.
WARNING: CPU: 1 PID: 31515 at lib/list_debug.c:35 __list_add_valid+0x124/0x158 lib/list_debug.c:33
Modules linked in:
CPU: 1 PID: 31515 Comm: syz-executor.2 Not tainted 4.19.90 #1
Hardware name: linux,dummy-virt (DT)
pstate: 80400005 (Nzcv daif +PAN -UAO)
pc : __list_add_valid+0x124/0x158 lib/list_debug.c:33
lr : __list_add_valid+0x124/0x158 lib/list_debug.c:33
...
Call trace:
 __list_add_valid+0x124/0x158 lib/list_debug.c:33
 __list_add include/linux/list.h:60 [inline]
 list_add_tail include/linux/list.h:93 [inline]
 register_shrinker_prepared+0x4c/0x130 mm/vmscan.c:420
 register_shrinker+0x38/0x50 mm/vmscan.c:431
 hugepage_tuning_enable+0x60/0x360 mm/hugepage_tuning.c:558
 hp_enable_store+0x88/0x108 mm/hugepage_tuning.c:460
 hugepage_tuning_attr_store+0x68/0x98 mm/hugepage_tuning.c:402
 sysfs_kf_write+0x114/0x190 fs/sysfs/file.c:139
 kernfs_fop_write+0x264/0x4b8 fs/kernfs/file.c:316
 __vfs_write+0xf4/0x5a0 fs/read_write.c:487
 vfs_write+0x144/0x400 fs/read_write.c:551
 ksys_write+0xf4/0x238 fs/read_write.c:601
 __do_sys_write fs/read_write.c:613 [inline]
 __se_sys_write fs/read_write.c:610 [inline]
 __arm64_sys_write+0x74/0xa8 fs/read_write.c:610
 __invoke_syscall arch/arm64/kernel/syscall.c:36 [inline]
 invoke_syscall arch/arm64/kernel/syscall.c:48 [inline]
 el0_svc_common+0x134/0x570 arch/arm64/kernel/syscall.c:121
 el0_svc_handler+0x190/0x260 arch/arm64/kernel/syscall.c:190
 el0_svc+0x10/0x640 arch/arm64/kernel/entry.S:1028
---[ end trace 328ad58f62232ded ]---

Revert "arm64/ascend: Add auto tuning hugepage module"
This reverts commit ecec54f4.

Revert "arm64/ascend: Add hugepage flags change interface"
This reverts commit db1d159b.

Revert "arm64/ascend: Add set hugepage number helper function"
This reverts commit b6bcd500.

Revert "arm64/ascend: Add mmap hook when alloc hugepage"
This reverts commit d9952490.

Revert "arm64/ascend: Add new CONFIG for auto-tuning hugepage"
This reverts commit 2597ada2.
Signed-off-by: NWang Wensheng <wangwensheng4@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
      9fb6a430
  7. 04 2月, 2023 5 次提交
  9. 30 12月, 2022 1 次提交
  11. 08 12月, 2022 1 次提交
  13. 21 6月, 2022 1 次提交
  15. 24 3月, 2022 1 次提交
  17. 08 3月, 2022 1 次提交
  19. 17 1月, 2022 2 次提交
  21. 16 12月, 2021 1 次提交
    • N
      hugetlbfs: flush TLBs correctly after huge_pmd_unshare · 09e1590f
      由 Nadav Amit 提交于 
      stable inclusion
from linux-v4.19.219
commit b0313bc7f5fbb6beee327af39d818ffdc921821a
category: bugfix
bugzilla: 185854
CVE: CVE-2021-4002

-----------------------------------------------

commit a4a118f2 upstream.

When __unmap_hugepage_range() calls to huge_pmd_unshare() succeed, a TLB
flush is missing.  This TLB flush must be performed before releasing the
i_mmap_rwsem, in order to prevent an unshared PMDs page from being
released and reused before the TLB flush took place.

Arguably, a comprehensive solution would use mmu_gather interface to
batch the TLB flushes and the PMDs page release, however it is not an
easy solution: (1) try_to_unmap_one() and try_to_migrate_one() also call
huge_pmd_unshare() and they cannot use the mmu_gather interface; and (2)
deferring the release of the page reference for the PMDs page until
after i_mmap_rwsem is dropeed can confuse huge_pmd_unshare() into
thinking PMDs are shared when they are not.

Fix __unmap_hugepage_range() by adding the missing TLB flush, and
forcing a flush when unshare is successful.

Fixes: 24669e58 ("hugetlb: use mmu_gather instead of a temporary linked list for accumulating pages)" # 3.6
Signed-off-by: NNadav Amit <namit@vmware.com>
Reviewed-by: NMike Kravetz <mike.kravetz@oracle.com>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Conflicts:
	include/asm-generic/tlb.h
	mm/mmu_gather.c
Signed-off-by: NLiu Shixin <liushixin2@huawei.com>
Reviewed-by: Ntong tiangen <tongtiangen@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      09e1590f
  23. 02 12月, 2021 1 次提交
    • M
      hugetlb: before freeing hugetlb page set dtor to appropriate value · c65d13f3
      由 Mike Kravetz 提交于 
      mainline inclusion
from mainline-5.15-rc1
commit e32d20c0
category: bugfix
bugzilla: 180680
CVE: NA

---------------------------

When removing a hugetlb page from the pool the ref count is set to one (as
the free page has no ref count) and compound page destructor is set to
NULL_COMPOUND_DTOR.  Since a subsequent call to free the hugetlb page will
call __free_pages for non-gigantic pages and free_gigantic_page for
gigantic pages the destructor is not used.

However, consider the following race with code taking a speculative
reference on the page:

Thread 0				Thread 1
--------				--------
remove_hugetlb_page
  set_page_refcounted(page);
  set_compound_page_dtor(page,
           NULL_COMPOUND_DTOR);
					get_page_unless_zero(page)
__update_and_free_page
  __free_pages(page,
           huge_page_order(h));

		/* Note that __free_pages() will simply drop
		   the reference to the page. */

					put_page(page)
					  __put_compound_page()
					    destroy_compound_page
					      NULL_COMPOUND_DTOR
						BUG: kernel NULL pointer
						dereference, address:
						0000000000000000

To address this race, set the dtor to the normal compound page dtor for
non-gigantic pages.  The dtor for gigantic pages does not matter as
gigantic pages are changed from a compound page to 'just a group of pages'
before freeing.  Hence, the destructor is not used.

Link: https://lkml.kernel.org/r/20210809184832.18342-4-mike.kravetz@oracle.comSigned-off-by: NMike Kravetz <mike.kravetz@oracle.com>
Reviewed-by: NMuchun Song <songmuchun@bytedance.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: David Hildenbrand <david@redhat.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Naoya Horiguchi <naoya.horiguchi@linux.dev>
Cc: Mina Almasry <almasrymina@google.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
Conflicts:
	mm/hugetlb.c
Signed-off-by: NChen Wandun <chenwandun@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      c65d13f3
  25. 30 10月, 2021 4 次提交
  27. 22 10月, 2021 3 次提交
  29. 02 8月, 2021 1 次提交
  31. 29 7月, 2021 1 次提交
  33. 19 7月, 2021 1 次提交
    • M
      mm, hugetlb: fix simple resv_huge_pages underflow on UFFDIO_COPY · bf555e76
      由 Mina Almasry 提交于 
      stable inclusion
from linux-4.19.194
commit 7de60c2d5a2a66ef2c5d76952a5a3a9a4ea4d436

--------------------------------

[ Upstream commit d84cf06e ]

The userfaultfd hugetlb tests cause a resv_huge_pages underflow.  This
happens when hugetlb_mcopy_atomic_pte() is called with !is_continue on
an index for which we already have a page in the cache.  When this
happens, we allocate a second page, double consuming the reservation,
and then fail to insert the page into the cache and return -EEXIST.

To fix this, we first check if there is a page in the cache which
already consumed the reservation, and return -EEXIST immediately if so.

There is still a rare condition where we fail to copy the page contents
AND race with a call for hugetlb_no_page() for this index and again we
will underflow resv_huge_pages.  That is fixed in a more complicated
patch not targeted for -stable.

Test:

  Hacked the code locally such that resv_huge_pages underflows produce a
  warning, then:

  ./tools/testing/selftests/vm/userfaultfd hugetlb_shared 10
	2 /tmp/kokonut_test/huge/userfaultfd_test && echo test success
  ./tools/testing/selftests/vm/userfaultfd hugetlb 10
	2 /tmp/kokonut_test/huge/userfaultfd_test && echo test success

Both tests succeed and produce no warnings.  After the test runs number
of free/resv hugepages is correct.

[mike.kravetz@oracle.com: changelog fixes]

Link: https://lkml.kernel.org/r/20210528004649.85298-1-almasrymina@google.com
Fixes: 8fb5debc ("userfaultfd: hugetlbfs: add hugetlb_mcopy_atomic_pte for userfaultfd support")
Signed-off-by: NMina Almasry <almasrymina@google.com>
Reviewed-by: NMike Kravetz <mike.kravetz@oracle.com>
Cc: Axel Rasmussen <axelrasmussen@google.com>
Cc: Peter Xu <peterx@redhat.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      bf555e76
  35. 30 6月, 2021 2 次提交
  37. 14 4月, 2021 4 次提交
  39. 11 3月, 2021 4 次提交
  41. 22 2月, 2021 3 次提交