* Hugh Dickins <hughd@xxxxxxxxxx> [220304 21:29]: > 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(). I must be missing something. If mpol_equal() isn't sufficient to ensure we don't need to set_policy(), then why are the other vma_merge() cases okay - such as madvise_update_vma() and mlock_fixup()? Won't the mem policy change in the same way in these cases? Thanks, Liam
