Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 19 Sep 2022 13:57:10 -0700
From:   Andrew Morton <akpm@linux-foundation.org>
To:     Dawei Li <set_pte_at@outlook.com>
Cc:     hch@lst.de, linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm: mmap lock holding assertion on remap_pfn_range
Message-Id: <20220919135710.d52984bda33620f42d450010@linux-foundation.org>
In-Reply-To: <TYCP286MB23233CBD7126B624E1832699CA4D9@TYCP286MB2323.JPNP286.PROD.OUTLOOK.COM>
References: <TYCP286MB23233CBD7126B624E1832699CA4D9@TYCP286MB2323.JPNP286.PROD.OUTLOOK.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk

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