Messages in this thread | | | Date | Fri, 4 Mar 2022 18:28:39 -0800 (PST) | From | Hugh Dickins <> | Subject | Re: [PATCH mmotm] mempolicy: mbind_range() set_policy() after vma_merge() |
| |
On Sat, 5 Mar 2022, Liam Howlett wrote: > * Hugh Dickins <hughd@google.com> [220304 17:48]: > > On Fri, 4 Mar 2022, Liam Howlett wrote: > > > * Liam R. Howlett <Liam.Howlett@Oracle.com> [220304 13:49]: > > > > * Hugh Dickins <hughd@google.com> [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
| |