On 10/22/18 3:46 PM, Michal Hocko wrote: > On Mon 22-10-18 15:35:24, Vlastimil Babka wrote: >> On 10/22/18 3:30 PM, Michal Hocko wrote: >>> On Mon 22-10-18 15:15:38, Vlastimil Babka wrote: >>>>> Forgot to add. One notable exception would be that the previous code >>>>> would allow to hit >>>>> WARN_ON_ONCE(policy->mode == MPOL_BIND && (gfp & __GFP_THISNODE)); >>>>> in policy_node if the requested node (e.g. cpu local one) was outside of >>>>> the mbind nodemask. This is not possible now. We haven't heard about any >>>>> such warning yet so it is unlikely that it happens though. >>>> >>>> I don't think the previous code could hit the warning, as the hugepage >>>> path that would add __GFP_THISNODE didn't call policy_node() (containing >>>> the warning) at all. IIRC early of your patch did hit the warning >>>> though, which is why you added the MPOL_BIND policy check. >>> >>> Are you sure? What prevents node_isset(node, policy_nodemask()) == F and >>> fallback to the !huge allocation path? >> >> That can indeed happen, but then the code also skipped the "gfp |= >> __GFP_THISNODE" part, right? So the warning wouldn't trigger. > > I thought I have crawled all the code paths back then but maybe there > were some phantom ones... If you are sure about then we can stick with > the original changelog. The __GFP_THISNODE would have to already be set in the 'gfp' parameter of alloc_pages_vma(), and alloc_hugepage_direct_gfpmask() could not add it. So in the context of alloc_hugepage_direct_gfpmask() users I believe the patch is not removing nor adding the possibility of the warning to trigger.
