<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 26, 2019 at 3:52 PM Richard Palethorpe <<a href="mailto:rpalethorpe@suse.de" target="_blank">rpalethorpe@suse.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello,<br>
<br>
Li Wang <<a href="mailto:liwang@redhat.com" target="_blank">liwang@redhat.com</a>> writes:<br>
<br>
> The test#2 is going to simulate the race condition, where move_pages()<br>
> and soft offline are called on a single hugetlb page concurrently. But,<br>
> it return EBUSY and report FAIL in soft-offline a moving hugepage as a<br>
> result sometimes.<br>
><br>
> The root cause seems a call to page_huge_active return false, then the<br>
> soft offline action will failed to isolate hugepage with EBUSY return as<br>
> below call trace:<br>
><br>
> In Parent:<br>
>   madvise(..., MADV_SOFT_OFFLINE)<br>
>   ...<br>
>     soft_offline_page<br>
>       soft_offline_in_use_page<br>
>         soft_offline_huge_page<br>
>           isolate_huge_page<br>
>             page_huge_active<br>
>              # return false at here<br>
><br>
> In Child:<br>
>   move_pages()<br>
>   ...<br>
>     do_move_pages<br>
>       do_move_pages_to_node<br>
>         add_page_for_migration<br>
>           isolate_huge_page<br>
>             # it has already isolated the hugepage<br>
><br>
> In this patch, I simply regard the returned EBUSY as a normal situation and<br>
> mask it in error handler. Because move_pages is calling add_page_for_migration<br>
> to isolate hugepage before do migration, so that's very possible to hit the<br>
> collision and return EBUSY on the same page.<br>
<br>
We also get EIO (on aarch64) and ENOMEM (on x86). From looking at<br>
migrate_pages, this seems normal, although the behaviour on older kernels<br>
is different to newer ones.<br>
<br>
On OpenSUSE with kernel 5.2 the test completes without any problem, but<br>
on SLES kernel 5.12 we get the other error codes.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Can you help to check if these commits have been backported to SLEL kernel-5.12?</div><div class="gmail_default" style="font-size:small">    commit e66f17ff71772b209eed39de35aaa99ba819c93d</div><div class="gmail_default" style="font-size:small">    commit c9d398fa237882ea07167e23bcfc5e6847066518</div><div class="gmail_default" style="font-size:small">    commit 4643d67e8cb0b3536ef0ab5cddd1cedc73fa14ad</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The move_pages12 test actually found three regression BUG which has all been fixed in the mainline kernel so far.</div></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
TBH I'm not sure what we are testing when checking the return value of<br>
<span class="gmail_default" style="font-size:small"></span>MADV_SOFT_OFFLINE? The bug is not reproduced if madvise always fails, so<br>
the test should pass right?<br></blockquote><div> </div><div><div class="gmail_default" style="font-size:small">The return value checking of <span class="gmail_default"></span>MADV_SOFT_OFFLINE are two:</div><div class="gmail_default" style="font-size:small">    EINVAL - To make sure system support <span class="gmail_default"></span>MADV_SOFT_OFFLINE<br></div><div class="gmail_default" style="font-size:small">    EBUSY -  To make ignore the defect(EBUSY when soft-offlining hugepage) designed by the kernel</div></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The madvise(MADV_SOFT_OFFLINE) should not always fail, it might get failure occasionally on EBUSY(ignored already), but exit with TCONF if hit EINVAL.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">@MIke & @Naoyo, If I was wrong please correct me.</div></div><div><br></div>-- <br><div dir="ltr" class="m_-992398280566816610m_-4674187973698281157m_4453656924332093744gmail_signature"><div dir="ltr"><div>Regards,<br></div><div>Li Wang<br></div></div></div></div>