Re: [PATCH] mm/hugetl.c: keep the page mapping info when free_huge_page() hit the VM_BUG_ON_PAGE

Re: [PATCH] mm/hugetl.c: keep the page mapping info when free_huge_page() hit the VM_BUG_ON_PAGE

[Michal Hocko]

On Tue 13-11-18 20:38:16, Yongkai Wu wrote:
> It is better to keep page mapping info when free_huge_page() hit the
> VM_BUG_ON_PAGE,
> so we can get more infomation from the coredump for further analysis.

The patch seems to be whitespace damaged. Put that aside, have you
actually seen a case where preservning the page state would help to nail
down any bug.

I am not objecting to the patch, it actually makes some sense to me, I
am just curious about a background motivation.
 
> Signed-off-by: Yongkai Wu <nic_w@163.com>
> ---
>  mm/hugetlb.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index c007fb5..ba693bb 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -1248,10 +1248,11 @@ void free_huge_page(struct page *page)
>   (struct hugepage_subpool *)page_private(page);
>   bool restore_reserve;
> 
> +        VM_BUG_ON_PAGE(page_count(page), page);
> +        VM_BUG_ON_PAGE(page_mapcount(page), page);
> +
>   set_page_private(page, 0);
>   page->mapping = NULL;
> - VM_BUG_ON_PAGE(page_count(page), page);
> - VM_BUG_ON_PAGE(page_mapcount(page), page);
>   restore_reserve = PagePrivate(page);
>   ClearPagePrivate(page);
> 
> -- 
> 1.8.3.1

-- 
Michal Hocko
SUSE Labs

Re: [PATCH] mm/hugetl.c: keep the page mapping info when free_huge_page() hit the VM_BUG_ON_PAGE

[Michal Hocko]

[Please do not top-post]

On Tue 13-11-18 23:12:24, Yongkai Wu wrote:
> Dear Maintainer,
> Actually i met a VM_BUG_ON_PAGE issue in centos7.4 some days ago.When the
> issue first happen,
> i just can know that it happen in free_huge_page() when doing soft offline
> huge page.
> But because page->mapping is set to null,i can not get any further
> information how the issue happen.
> 
> So i modified the code as the patch show,and apply the new code to our
> produce line and wait some time,
> then the issue come again.And this time i can know the whole file path
> which trigger the issue by using
> crash tool to get the inode、dentry and so on,that help me to find a way to
> reproduce the issue quite easily
> and finally found the root cause and solve it.

OK, thanks for the clarification. Please repost without
the patch being clobbered by your email client and feel free to add
Acked-by: Michal Hocko <mhocko@suse.com>

A note about your experience in the changelog would be useful IMHO.
-- 
Michal Hocko
SUSE Labs

Re: [PATCH] mm/hugetl.c: keep the page mapping info when free_huge_page() hit the VM_BUG_ON_PAGE

[Mike Kravetz]

On 11/13/18 7:12 AM, Yongkai Wu wrote:
> Dear Maintainer,
> Actually i met a VM_BUG_ON_PAGE issue in centos7.4 some days ago.When the issue first happen,
> i just can know that it happen in free_huge_page() when doing soft offline huge page.
> But because page->mapping is set to null,i can not get any further information how the issue happen.
> 
> So i modified the code as the patch show,and apply the new code to our produce line and wait some time,
> then the issue come again.And this time i can know the whole file path which trigger the issue by using 
> crash tool to get the inode、dentry and so on,that help me to find a way to reproduce the issue quite easily
> and finally found the root cause and solve it.

Thank you for the information and the patch.

As previously stated by Michal, please add some additional information to the
change log (commit message) and fix the formatting of the patch.

Can you tell us more about the root cause of your issue?  What was the issue?
How could you reproduce it?  How did you solve it?
-- 
Mike Kravetz

Re: [PATCH] mm/hugetl.c: keep the page mapping info when free_huge_page() hit the VM_BUG_ON_PAGE

[Michal Hocko]

On Thu 15-11-18 16:30:32, Yongkai Wu wrote:
[...]

Thanks for the clarification. It can be helpful for somebody trying to
debug a similar issue in the future.

> But i can not find a similar bug fix report or commit log.

What about 6bc9b56433b7 ("mm: fix race on soft-offlining free huge pages") ?

-- 
Michal Hocko
SUSE Labs