On Thu Sep 17, 2026 at 12:22 PM EDT, Lorenzo Stoakes (ARM) wrote: > It only makes sense to manipulate VMA fields if we allocated a new VMA, > rather than merged it. > > VMA merging does not compare vm_ops or vm_private_data, so a merged VMA > keeps its own, which is also what the legacy f_op->mmap path does since it > never touches an existing VMA. Previously set_vma_user_defined_fields() > overwrote the merged VMA's fields with those set for the new mapping. In > practice these are the same values, with rare exceptions such as shmem > selecting vm_ops based on whether the file has been unlinked, so no > user-visible change is expected. > > Make this dependency explicit, and additionally constify have_mmap_prepare > while we're here. > > Signed-off-by: Lorenzo Stoakes (ARM) <[email protected]> > --- > mm/vma.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > Makse sense.
Acked-by: Zi Yan <[email protected]> -- Best Regards, Yan, Zi
