On Thu, Feb 13, 2020 at 6:02 PM Minchan Kim <minchan@xxxxxxxxxx> wrote:
> On Wed, Feb 12, 2020 at 04:21:59PM -0800, Alexander Duyck wrote:
> > On Wed, 2020-02-12 at 15:39 -0800, Minchan Kim wrote:
> > > In upcoming patches, do_madvise will be called from external process
> > > context so it shouldn't asssume "current" is always hinted process's
> > > task_struct. Thus, let's get the mm_struct from vma->vm_mm, not
> > > current because vma is always hinted process's one. And let's pass
> > > *current* as new task argument of do_madvise so it shouldn't change
> > > existing behavior.
[...]
> > > @@ -763,8 +763,8 @@ static long madvise_dontneed_free(struct vm_area_struct *vma,
> > > if (!userfaultfd_remove(vma, start, end)) {
> > > *prev = NULL; /* mmap_sem has been dropped, prev is stale */
> > >
> > > - down_read(¤t->mm->mmap_sem);
> > > - vma = find_vma(current->mm, start);
> > > + down_read(&mm->mmap_sem);
> > > + vma = find_vma(mm, start);
> > > if (!vma)
> > > return -ENOMEM;
> > > if (start < vma->vm_start) {
> >
> > This piece of code has me wondering if it is valid to be using vma->mm at
> > the start of the function. I assume we are probably safe since we read the
> > mm value before the semaphore was released in userfaultfd_remove. It might
> > make more sense to just pass the task to the function and use task->mm-
> > >mmap_sem instead.
>
> As Jann pointed out, we couldn't use task->mm once we verified it via
> access_mm. However, I believe vma->vm_mm is safe(Ccing Jann for double
> check).
Looks safe to me, too.
