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>

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>

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>

hulk inclusion
category: other
bugzilla: https://gitee.com/openeuler/kernel/issues/I6ET9W

----------------------------------------------
Signed-off-by: NXu Qiang <xuqiang36@huawei.com>

hulk inclusion
category: other
bugzilla: https://gitee.com/openeuler/kernel/issues/I6ET9W

----------------------------------------------
Signed-off-by: NXu Qiang <xuqiang36@huawei.com>

hulk inclusion
category: other
bugzilla: https://gitee.com/openeuler/kernel/issues/I6ET9W

----------------------------------------------
Signed-off-by: NXu Qiang <xuqiang36@huawei.com>

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>

hulk inclusion
category: other
bugzilla: https://gitee.com/openeuler/kernel/issues/I6ET9W

----------------------------------------------
Signed-off-by: NXu Qiang <xuqiang36@huawei.com>

hulk inclusion
category: other
bugzilla: https://gitee.com/openeuler/kernel/issues/I6ET9W

----------------------------------------------
Signed-off-by: NXu Qiang <xuqiang36@huawei.com>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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)

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)

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)

mainline inclusion
from mainline-v5.16-rc1
commit 7e6ec49c
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6AW65
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7e6ec49c18988f1b8dab0677271dafde5f8d9a43

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

When reading memcg->socket_pressure in mem_cgroup_under_socket_pressure()
and writing memcg->socket_pressure in vmpressure() at the same time, the
following data-race occurs:

  BUG: KCSAN: data-race in __sk_mem_reduce_allocated / vmpressure

  write to 0xffff8881286f4938 of 8 bytes by task 24550 on cpu 3:
   vmpressure+0x218/0x230 mm/vmpressure.c:307
   shrink_node_memcgs+0x2b9/0x410 mm/vmscan.c:2658
   shrink_node+0x9d2/0x11d0 mm/vmscan.c:2769
   shrink_zones+0x29f/0x470 mm/vmscan.c:2972
   do_try_to_free_pages+0x193/0x6e0 mm/vmscan.c:3027
   try_to_free_mem_cgroup_pages+0x1c0/0x3f0 mm/vmscan.c:3345
   reclaim_high mm/memcontrol.c:2440 [inline]
   mem_cgroup_handle_over_high+0x18b/0x4d0 mm/memcontrol.c:2624
   tracehook_notify_resume include/linux/tracehook.h:197 [inline]
   exit_to_user_mode_loop kernel/entry/common.c:164 [inline]
   exit_to_user_mode_prepare+0x110/0x170 kernel/entry/common.c:191
   syscall_exit_to_user_mode+0x16/0x30 kernel/entry/common.c:266
   ret_from_fork+0x15/0x30 arch/x86/entry/entry_64.S:289

  read to 0xffff8881286f4938 of 8 bytes by interrupt on cpu 1:
   mem_cgroup_under_socket_pressure include/linux/memcontrol.h:1483 [inline]
   sk_under_memory_pressure include/net/sock.h:1314 [inline]
   __sk_mem_reduce_allocated+0x1d2/0x270 net/core/sock.c:2696
   __sk_mem_reclaim+0x44/0x50 net/core/sock.c:2711
   sk_mem_reclaim include/net/sock.h:1490 [inline]
   ......
   net_rx_action+0x17a/0x480 net/core/dev.c:6864
   __do_softirq+0x12c/0x2af kernel/softirq.c:298
   run_ksoftirqd+0x13/0x20 kernel/softirq.c:653
   smpboot_thread_fn+0x33f/0x510 kernel/smpboot.c:165
   kthread+0x1fc/0x220 kernel/kthread.c:292
   ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296

Fix it by using READ_ONCE() and WRITE_ONCE() to read and write
memcg->socket_pressure.

Link: https://lkml.kernel.org/r/20211025082843.671690-1-songyuanzheng@huawei.comSigned-off-by: NYuanzheng Song <songyuanzheng@huawei.com>
Reviewed-by: NMuchun Song <songmuchun@bytedance.com>
Cc: Shakeel Butt <shakeelb@google.com>
Cc: Roman Gushchin <guro@fb.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Alex Shi <alexs@kernel.org>
Cc: Wei Yang <richard.weiyang@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NCai Xinchen <caixinchen1@huawei.com>
Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
(cherry picked from commit bbc0f30d)

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: NGuo Mengqi <guomengqi3@huawei.com>
Reviewed-by: Nchenweilong <chenweilong@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
(cherry picked from commit 056e261b)

mainline inclusion
from mainline-v6.1-rc7
commit ea4452de
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: 3f913fc5 ("mm: fix missing handler for __GFP_NOWARN")
Signed-off-by: NQi Zheng <zhengqi.arch@bytedance.com>
Reported-by: NDmitry Vyukov <dvyukov@google.com>
Reviewed-by: NAkinobu Mita <akinobu.mita@gmail.com>
Reviewed-by: NJason 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: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NYe Weihua <yeweihua4@huawei.com>
Reviewed-by: Ntong tiangen <tongtiangen@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
(cherry picked from commit 49457cf7)

hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6AQE8
CVE: NA

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

The function memcpy_mcs() is designed to copy in memory and should be
supported by kasan.
Signed-off-by: NTong Tiangen <tongtiangen@huawei.com>

mainline inclusion
from mainline-v6.2-rc1
commit de2e5171
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I67BWQ
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=de2e5171433126d340573cb7d0d4fcac084ab2a0

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

When handling MADV_WILLNEED in madvise(), a soflockup may occurr in
swapin_walk_pmd_entry() if swapping in lots of memory on a slow device.
Add a cond_resched() to avoid the possible softlockup.

Link: https://lkml.kernel.org/r/20221205140327.72304-1-wangkefeng.wang@huawei.com
Fixes: 1998cc04 ("mm: make madvise(MADV_WILLNEED) support swap file prefetch")
Signed-off-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Cc: Shaohua Li <shli@fusionio.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Rik van Riel <riel@redhat.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>

Conflicts:
	mm/madvise.c
Signed-off-by: NLonglong Xia <xialonglong1@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I66OCA
CVE: NA

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

Since free_pages_prepare() will clear the PagePool without lock in
free_page_to_dhugetlb_pool() and free_page_list_to_dhugetlb_pool(),
it is unreliable to check whether a page is freed by PagePool in
hpool_merge_page().
Move free_pages_prepare() after ClearPagePool(), which can guarantee
all allocated page has PagePool flag.

Fixes: 71197c63 ("mm/dynamic_hugetlb: free pages to dhugetlb_pool")
Signed-off-by: NLiu Shixin <liushixin2@huawei.com>
Reviewed-by: NTong Tiangen <tongtiangen@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>