Re: [PATCH v8 1/3] mm: rearrange madvise code to allow for reuse

From: Suren Baghdasaryan
Date: Sat Aug 28 2021 - 17:59:49 EST


On Sat, Aug 28, 2021 at 9:19 AM Cyrill Gorcunov <gorcunov@xxxxxxxxx> wrote:
>
> On Fri, Aug 27, 2021 at 12:18:56PM -0700, Suren Baghdasaryan wrote:
> ...
> >
> > +/*
> > + * Apply an madvise behavior to a region of a vma. madvise_update_vma
> > + * will handle splitting a vm area into separate areas, each area with its own
> > + * behavior.
> > + */
> > +static int madvise_vma_behavior(struct vm_area_struct *vma,
> > + struct vm_area_struct **prev,
> > + unsigned long start, unsigned long end,
> > + unsigned long behavior)
> > +{
> > + int error = 0;
>
>
> Hi Suren! A nitpick -- this variable is never used with default value
> so I think we could drop assignment here.
> ...
> > + case MADV_DONTFORK:
> > + new_flags |= VM_DONTCOPY;
> > + break;
> > + case MADV_DOFORK:
> > + if (vma->vm_flags & VM_IO) {
> > + error = -EINVAL;
>
> We can exit early here, without jumping to the end of the function, right?
>
> > + goto out;
> > + }
> > + new_flags &= ~VM_DONTCOPY;
> > + break;
> > + case MADV_WIPEONFORK:
> > + /* MADV_WIPEONFORK is only supported on anonymous memory. */
> > + if (vma->vm_file || vma->vm_flags & VM_SHARED) {
> > + error = -EINVAL;
>
> And here too.
>
> > + goto out;
> > + }
> > + new_flags |= VM_WIPEONFORK;
> > + break;
> > + case MADV_KEEPONFORK:
> > + new_flags &= ~VM_WIPEONFORK;
> > + break;
> > + case MADV_DONTDUMP:
> > + new_flags |= VM_DONTDUMP;
> > + break;
> > + case MADV_DODUMP:
> > + if (!is_vm_hugetlb_page(vma) && new_flags & VM_SPECIAL) {
> > + error = -EINVAL;
>
> Same.
>
> > + goto out;
> > + }
> > + new_flags &= ~VM_DONTDUMP;
> > + break;
> > + case MADV_MERGEABLE:
> > + case MADV_UNMERGEABLE:
> > + error = ksm_madvise(vma, start, end, behavior, &new_flags);
> > + if (error)
> > + goto out;
> > + break;
> > + case MADV_HUGEPAGE:
> > + case MADV_NOHUGEPAGE:
> > + error = hugepage_madvise(vma, &new_flags, behavior);
> > + if (error)
> > + goto out;
> > + break;
> > + }
> > +
> > + error = madvise_update_vma(vma, prev, start, end, new_flags);
> > +
> > +out:
>
> I suppose we better keep the former comment on why we maps ENOMEM to EAGAIN?

Thanks for the review Cyrill! Proposed changes sound good to me. Will
change in the next revision.
Suren.

>
> Cyrill