On 5/13/22 17:26, Minchan Kim wrote:
Anything else further can we get insight from the warning? For example, pin_user_pages going on against a hugetlb page which are concurrently running alloc_contig_range(it's exported function so anyone can call randomly) so alloc_contig_range changes pageblock type as MIGRATE_ISOLATE under us so the hit at the warning?
Well, yes. First of all, the comments above the warning that fired have gone a little bit stale: they claim that we can only hit the warning if the page refcount overflows. However, we almost certainly got here via: try_grab_folio() /* * Can't do FOLL_LONGTERM + FOLL_PIN gup fast path if not in a * right zone, so fail and let the caller fall back to the slow * path. */ if (unlikely((flags & FOLL_LONGTERM) && !is_pinnable_page(page))) /* which we just changed */ return NULL; ...and now I'm starting to think that this warning might fire even with the corrected check for MIGRATE_CMA || MIGRATE_ISOLATE. Because try_grab_folio() didn't always have this early exit and it is starting to look wrong. Simply attempting to pin a non-pinnable huge page would hit this warning. Adding additional reasons that a page is not pinnable (which the patch does) could make this more likely to fire. I need to look at this a little more closely, it is making me wonder whether the is_pinnable_page() check is a problem in this path. The comment in try_grab_folio() indicates that the early return is a hack (it assumes that the caller is in the gup fast path), and maybe the hack is just wrong here--I think we're actually on the slow gup path. Not good. Mike, any thoughts here? thanks, -- John Hubbard NVIDIA
