Re: [PATCH v4 1/8] mm: pass task to do_madvise

On Thu, Feb 13, 2020 at 6:02 PM Minchan Kim [off-list ref] wrote:

On Wed, Feb 12, 2020 at 04:21:59PM -0800, Alexander Duyck wrote:

quoted

On Wed, 2020-02-12 at 15:39 -0800, Minchan Kim wrote:

quoted

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.

[...]

quoted

quoted

@@ -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(&current->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-

quoted

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.