lkml.org 
[lkml]   [2020]   [Sep]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [Patch v4 5/7] mm/hugetlb: a page from buddy is not on any list
From
Date
On 9/1/20 3:46 AM, Wei Yang wrote:
> The page allocated from buddy is not on any list, so just use list_add()
> is enough.
>
> Signed-off-by: Wei Yang <richard.weiyang@linux.alibaba.com>
> Reviewed-by: Baoquan He <bhe@redhat.com>
> Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
> ---
> mm/hugetlb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 441b7f7c623e..c9b292e664c4 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -2405,7 +2405,7 @@ struct page *alloc_huge_page(struct vm_area_struct *vma,
> h->resv_huge_pages--;
> }
> spin_lock(&hugetlb_lock);
> - list_move(&page->lru, &h->hugepage_activelist);
> + list_add(&page->lru, &h->hugepage_activelist);

Hmm, how does that list_move() actually not crash today?
Page has been taken from free lists, thus there was list_del() and page->lru
should be poisoned.
list_move() does __list_del_entry() which will either detect the poison with
CONFIG_DEBUG_LIST, or crash accessing the poison, no?
Am I missing something or does it mean this code is actually never executed in wild?

> /* Fall through */

Maybe delete this comment? This is not a switch statement.

> }
> hugetlb_cgroup_commit_charge(idx, pages_per_huge_page(h), h_cg, page);
>

\
 
 \ /
  Last update: 2020-09-02 12:51    [W:0.212 / U:0.116 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site