On Sat, 5 Mar 2022, Liam Howlett wrote: > * Hugh Dickins <hughd@xxxxxxxxxx> [220304 17:48]: > > On Fri, 4 Mar 2022, Liam Howlett wrote: > > > * Liam R. Howlett <Liam.Howlett@xxxxxxxxxx> [220304 13:49]: > > > > * Hugh Dickins <hughd@xxxxxxxxxx> [220303 23:36]: > > > > > > I just thought of something after my initial email > > > > > > How does the ->set_policy() requirement on tmpfs play out for the > > > mpol_equal() check earlier in that for loop? > > > > It took me a while to page all this back in (and remind myself of > > what is case 8) to answer that question! > > > > The answer is that the mpol_equal() check at the top of the loop is on > > an existing, unmodified vma; so it's right to assume that any necessary > > set_policy() has already been done. > > > > Whereas the mpol_equal() check being removed in this patch, is being > > done on a vma which may have just been extended to cover a greater range: > > so although the relevant set_policy() may have already been done on a part > > of its range, there is now another part which needs the policy applied. > > Doesn't the policy get checked during vma_merge()? Specifically the > mpol_equal(policy, vma_policy(next)) check? Sorry, I'm reduced to the unhelpful reply of "Yes. So?" If vma_merge() finds that vma's new_pol allows it to be merged with prev, that still requires mbind_range() (or its call to vma_replace_policy()) to set_policy() on prev (now assigned to vma), to apply that new_pol to the extension of prev - vma_merge() would have checked mpol_equal(), but would not have done the set_policy(). Hugh
