lkml.org 
[lkml]   [2022]   [Sep]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] mm: mmap lock holding assertion on remap_pfn_range
On Mon, 19 Sep 2022 23:47:32 +0800 Dawei Li <set_pte_at@outlook.com> wrote:

> remap_pfn_range() creates/modifies the mapping between user virtual
> address and physical address, the caller of which must hold mmap
> writer lock to achieve access consistency of mapping.
>
> The callers fall into categories below:
> 1) fops->mmap() implemented by driver
> For this case, mmap_lock has been taken externally, the rule holds true.
>
> 2) Some arch codes do mapping on their own(vdso e.g.), rather than via
> fops->mmap().
>
> 3) Some driver codes do mapping into user address space, for some
> reasons, the mapping is not implemented by fops->mmap().
>
> For the last two cases, an explicit assertion must be made.

Why "must" it be made? Are callers known to get this wrong?

> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -2551,6 +2551,11 @@ int remap_pfn_range(struct vm_area_struct *vma, unsigned long addr,
> {
> int err;
>
> + if (!vma->vm_mm)
> + return -EINVAL;

Can this happen? If so, under what circumstances?

> + mmap_assert_write_locked(vma->vm_mm);
> +
> err = track_pfn_remap(vma, &prot, pfn, addr, PAGE_ALIGN(size));
> if (err)
> return -EINVAL;
> --
> 2.25.1

\
 
 \ /
  Last update: 2022-09-19 22:58    [W:0.031 / U:1.056 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site