Re: [PATCH v13 04/20] mm, arm64: untag user pointers passed to memory syscalls

Re: [PATCH v13 04/20] mm, arm64: untag user pointers passed to memory syscalls

[Catalin Marinas]

On Wed, Mar 20, 2019 at 03:51:18PM +0100, Andrey Konovalov wrote:
> This patch is a part of a series that extends arm64 kernel ABI to allow to
> pass tagged user pointers (with the top byte set to something else other
> than 0x00) as syscall arguments.
> 
> This patch allows tagged pointers to be passed to the following memory
> syscalls: madvise, mbind, get_mempolicy, mincore, mlock, mlock2, brk,
> mmap_pgoff, old_mmap, munmap, remap_file_pages, mprotect, pkey_mprotect,
> mremap, msync and shmdt.
> 
> This is done by untagging pointers passed to these syscalls in the
> prologues of their handlers.
> 
> Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
> ---
>  ipc/shm.c      | 2 ++
>  mm/madvise.c   | 2 ++
>  mm/mempolicy.c | 5 +++++
>  mm/migrate.c   | 1 +
>  mm/mincore.c   | 2 ++
>  mm/mlock.c     | 5 +++++
>  mm/mmap.c      | 7 +++++++
>  mm/mprotect.c  | 1 +
>  mm/mremap.c    | 2 ++
>  mm/msync.c     | 2 ++
>  10 files changed, 29 insertions(+)

I wonder whether it's better to keep these as wrappers in the arm64
code.

-- 
Catalin
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v13 09/20] net, arm64: untag user pointers in tcp_zerocopy_receive

[Catalin Marinas]

On Wed, Mar 20, 2019 at 03:51:23PM +0100, Andrey Konovalov wrote:
> This patch is a part of a series that extends arm64 kernel ABI to allow to
> pass tagged user pointers (with the top byte set to something else other
> than 0x00) as syscall arguments.
> 
> tcp_zerocopy_receive() uses provided user pointers for vma lookups, which
> can only by done with untagged pointers.
> 
> Untag user pointers in this function.
> 
> Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
> ---
>  net/ipv4/tcp.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
> index 6baa6dc1b13b..855a1f68c1ea 100644
> --- a/net/ipv4/tcp.c
> +++ b/net/ipv4/tcp.c
> @@ -1761,6 +1761,8 @@ static int tcp_zerocopy_receive(struct sock *sk,
>  	if (address & (PAGE_SIZE - 1) || address != zc->address)
>  		return -EINVAL;
>  
> +	address = untagged_addr(address);
> +
>  	if (sk->sk_state == TCP_LISTEN)
>  		return -ENOTCONN;

I don't think we need this patch if we stick to Vincenzo's ABI
restrictions. Can zc->address be an anonymous mmap()? My understanding
of TCP_ZEROCOPY_RECEIVE is that this is an mmap() on a socket, so user
should not tag such pointer.

We want to allow tagged pointers to work transparently only for heap and
stack, hence the restriction to anonymous mmap() and those addresses
below sbrk(0).

-- 
Catalin
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v13 10/20] kernel, arm64: untag user pointers in prctl_set_mm*

[Catalin Marinas]

On Wed, Mar 20, 2019 at 03:51:24PM +0100, Andrey Konovalov wrote:
> @@ -2120,13 +2135,14 @@ static int prctl_set_mm(int opt, unsigned long addr,
>  	if (opt == PR_SET_MM_AUXV)
>  		return prctl_set_auxv(mm, addr, arg4);
>  
> -	if (addr >= TASK_SIZE || addr < mmap_min_addr)
> +	if (untagged_addr(addr) >= TASK_SIZE ||
> +			untagged_addr(addr) < mmap_min_addr)
>  		return -EINVAL;
>  
>  	error = -EINVAL;
>  
>  	down_write(&mm->mmap_sem);
> -	vma = find_vma(mm, addr);
> +	vma = find_vma(mm, untagged_addr(addr));
>  
>  	prctl_map.start_code	= mm->start_code;
>  	prctl_map.end_code	= mm->end_code;

Does this mean that we are left with tagged addresses for the
mm->start_code etc. values? I really don't think we should allow this,
I'm not sure what the implications are in other parts of the kernel.

Arguably, these are not even pointer values but some address ranges. I
know we decided to relax this notion for mmap/mprotect/madvise() since
the user function prototypes take pointer as arguments but it feels like
we are overdoing it here (struct prctl_mm_map doesn't even have
pointers).

What is the use-case for allowing tagged addresses here? Can user space
handle untagging?

-- 
Catalin
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v13 11/20] tracing, arm64: untag user pointers in seq_print_user_ip

[Catalin Marinas]

On Wed, Mar 20, 2019 at 03:51:25PM +0100, Andrey Konovalov wrote:
> This patch is a part of a series that extends arm64 kernel ABI to allow to
> pass tagged user pointers (with the top byte set to something else other
> than 0x00) as syscall arguments.
> 
> seq_print_user_ip() uses provided user pointers for vma lookups, which
> can only by done with untagged pointers.
> 
> Untag user pointers in this function.
> 
> Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
> ---
>  kernel/trace/trace_output.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/trace/trace_output.c b/kernel/trace/trace_output.c
> index 54373d93e251..6376bee93c84 100644
> --- a/kernel/trace/trace_output.c
> +++ b/kernel/trace/trace_output.c
> @@ -370,6 +370,7 @@ static int seq_print_user_ip(struct trace_seq *s, struct mm_struct *mm,
>  {
>  	struct file *file = NULL;
>  	unsigned long vmstart = 0;
> +	unsigned long untagged_ip = untagged_addr(ip);
>  	int ret = 1;
>  
>  	if (s->full)
> @@ -379,7 +380,7 @@ static int seq_print_user_ip(struct trace_seq *s, struct mm_struct *mm,
>  		const struct vm_area_struct *vma;
>  
>  		down_read(&mm->mmap_sem);
> -		vma = find_vma(mm, ip);
> +		vma = find_vma(mm, untagged_ip);
>  		if (vma) {
>  			file = vma->vm_file;
>  			vmstart = vma->vm_start;
> @@ -388,7 +389,7 @@ static int seq_print_user_ip(struct trace_seq *s, struct mm_struct *mm,
>  			ret = trace_seq_path(s, &file->f_path);
>  			if (ret)
>  				trace_seq_printf(s, "[+0x%lx]",
> -						 ip - vmstart);
> +						 untagged_ip - vmstart);
>  		}
>  		up_read(&mm->mmap_sem);
>  	}

How would we end up with a tagged address here? Does "ip" here imply
instruction pointer, which we wouldn't tag?

-- 
Catalin
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v13 12/20] uprobes, arm64: untag user pointers in find_active_uprobe

[Catalin Marinas]

On Wed, Mar 20, 2019 at 03:51:26PM +0100, Andrey Konovalov wrote:
> This patch is a part of a series that extends arm64 kernel ABI to allow to
> pass tagged user pointers (with the top byte set to something else other
> than 0x00) as syscall arguments.
> 
> find_active_uprobe() uses user pointers (obtained via
> instruction_pointer(regs)) for vma lookups, which can only by done with
> untagged pointers.
> 
> Untag user pointers in this function.
> 
> Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
> ---
>  kernel/events/uprobes.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
> index c5cde87329c7..d3a2716a813a 100644
> --- a/kernel/events/uprobes.c
> +++ b/kernel/events/uprobes.c
> @@ -1992,6 +1992,8 @@ static struct uprobe *find_active_uprobe(unsigned long bp_vaddr, int *is_swbp)
>  	struct uprobe *uprobe = NULL;
>  	struct vm_area_struct *vma;
>  
> +	bp_vaddr = untagged_addr(bp_vaddr);
> +
>  	down_read(&mm->mmap_sem);
>  	vma = find_vma(mm, bp_vaddr);
>  	if (vma && vma->vm_start <= bp_vaddr) {

Similarly here, that's a breakpoint address, hence instruction pointer
(PC) which is untagged.

-- 
Catalin
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v13 13/20] bpf, arm64: untag user pointers in stack_map_get_build_id_offset

[Catalin Marinas]

On Wed, Mar 20, 2019 at 03:51:27PM +0100, Andrey Konovalov wrote:
> This patch is a part of a series that extends arm64 kernel ABI to allow to
> pass tagged user pointers (with the top byte set to something else other
> than 0x00) as syscall arguments.
> 
> stack_map_get_build_id_offset() uses provided user pointers for vma
> lookups, which can only by done with untagged pointers.
> 
> Untag user pointers in this function for doing the lookup and
> calculating the offset, but save as is in the bpf_stack_build_id
> struct.
> 
> Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
> ---
>  kernel/bpf/stackmap.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/bpf/stackmap.c b/kernel/bpf/stackmap.c
> index 950ab2f28922..bb89341d3faf 100644
> --- a/kernel/bpf/stackmap.c
> +++ b/kernel/bpf/stackmap.c
> @@ -320,7 +320,9 @@ static void stack_map_get_build_id_offset(struct bpf_stack_build_id *id_offs,
>  	}
>  
>  	for (i = 0; i < trace_nr; i++) {
> -		vma = find_vma(current->mm, ips[i]);
> +		u64 untagged_ip = untagged_addr(ips[i]);
> +
> +		vma = find_vma(current->mm, untagged_ip);
>  		if (!vma || stack_map_get_build_id(vma, id_offs[i].build_id)) {
>  			/* per entry fall back to ips */
>  			id_offs[i].status = BPF_STACK_BUILD_ID_IP;
> @@ -328,7 +330,7 @@ static void stack_map_get_build_id_offset(struct bpf_stack_build_id *id_offs,
>  			memset(id_offs[i].build_id, 0, BPF_BUILD_ID_SIZE);
>  			continue;
>  		}
> -		id_offs[i].offset = (vma->vm_pgoff << PAGE_SHIFT) + ips[i]
> +		id_offs[i].offset = (vma->vm_pgoff << PAGE_SHIFT) + untagged_ip
>  			- vma->vm_start;
>  		id_offs[i].status = BPF_STACK_BUILD_ID_VALID;
>  	}

Can the ips[*] here ever be tagged?

-- 
Catalin
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v13 14/20] drm/amdgpu, arm64: untag user pointers in amdgpu_ttm_tt_get_user_pages

[Catalin Marinas]

On Wed, Mar 20, 2019 at 03:51:28PM +0100, Andrey Konovalov wrote:
> This patch is a part of a series that extends arm64 kernel ABI to allow to
> pass tagged user pointers (with the top byte set to something else other
> than 0x00) as syscall arguments.
> 
> amdgpu_ttm_tt_get_user_pages() uses provided user pointers for vma
> lookups, which can only by done with untagged pointers.
> 
> Untag user pointers in this function.
> 
> Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> index 73e71e61dc99..891b027fa33b 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> @@ -751,10 +751,11 @@ int amdgpu_ttm_tt_get_user_pages(struct ttm_tt *ttm, struct page **pages)
>  		 * check that we only use anonymous memory to prevent problems
>  		 * with writeback
>  		 */
> -		unsigned long end = gtt->userptr + ttm->num_pages * PAGE_SIZE;
> +		unsigned long userptr = untagged_addr(gtt->userptr);
> +		unsigned long end = userptr + ttm->num_pages * PAGE_SIZE;
>  		struct vm_area_struct *vma;
>  
> -		vma = find_vma(mm, gtt->userptr);
> +		vma = find_vma(mm, userptr);
>  		if (!vma || vma->vm_file || vma->vm_end < end) {
>  			up_read(&mm->mmap_sem);
>  			return -EPERM;

I tried to track this down but I failed to see whether user could
provide an tagged pointer here (under the restrictions as per Vincenzo's
ABI document).

-- 
Catalin
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v13 15/20] drm/radeon, arm64: untag user pointers in radeon_ttm_tt_pin_userptr

[Catalin Marinas]

On Wed, Mar 20, 2019 at 03:51:29PM +0100, Andrey Konovalov wrote:
> This patch is a part of a series that extends arm64 kernel ABI to allow to
> pass tagged user pointers (with the top byte set to something else other
> than 0x00) as syscall arguments.
> 
> radeon_ttm_tt_pin_userptr() uses provided user pointers for vma
> lookups, which can only by done with untagged pointers.
> 
> Untag user pointers in this function.
> 
> Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
> ---
>  drivers/gpu/drm/radeon/radeon_ttm.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c b/drivers/gpu/drm/radeon/radeon_ttm.c
> index 9920a6fc11bf..872a98796117 100644
> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> @@ -497,9 +497,10 @@ static int radeon_ttm_tt_pin_userptr(struct ttm_tt *ttm)
>  	if (gtt->userflags & RADEON_GEM_USERPTR_ANONONLY) {
>  		/* check that we only pin down anonymous memory
>  		   to prevent problems with writeback */
> -		unsigned long end = gtt->userptr + ttm->num_pages * PAGE_SIZE;
> +		unsigned long userptr = untagged_addr(gtt->userptr);
> +		unsigned long end = userptr + ttm->num_pages * PAGE_SIZE;
>  		struct vm_area_struct *vma;
> -		vma = find_vma(gtt->usermm, gtt->userptr);
> +		vma = find_vma(gtt->usermm, userptr);
>  		if (!vma || vma->vm_file || vma->vm_end < end)
>  			return -EPERM;
>  	}

Same comment as on the previous patch.

-- 
Catalin
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v13 17/20] media/v4l2-core, arm64: untag user pointers in videobuf_dma_contig_user_get

[Catalin Marinas]

On Wed, Mar 20, 2019 at 03:51:31PM +0100, Andrey Konovalov wrote:
> This patch is a part of a series that extends arm64 kernel ABI to allow to
> pass tagged user pointers (with the top byte set to something else other
> than 0x00) as syscall arguments.
> 
> videobuf_dma_contig_user_get() uses provided user pointers for vma
> lookups, which can only by done with untagged pointers.
> 
> Untag the pointers in this function.
> 
> Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
> ---
>  drivers/media/v4l2-core/videobuf-dma-contig.c | 9 +++++----
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/videobuf-dma-contig.c b/drivers/media/v4l2-core/videobuf-dma-contig.c
> index e1bf50df4c70..8a1ddd146b17 100644
> --- a/drivers/media/v4l2-core/videobuf-dma-contig.c
> +++ b/drivers/media/v4l2-core/videobuf-dma-contig.c
> @@ -160,6 +160,7 @@ static void videobuf_dma_contig_user_put(struct videobuf_dma_contig_memory *mem)
>  static int videobuf_dma_contig_user_get(struct videobuf_dma_contig_memory *mem,
>  					struct videobuf_buffer *vb)
>  {
> +	unsigned long untagged_baddr = untagged_addr(vb->baddr);
>  	struct mm_struct *mm = current->mm;
>  	struct vm_area_struct *vma;
>  	unsigned long prev_pfn, this_pfn;
> @@ -167,22 +168,22 @@ static int videobuf_dma_contig_user_get(struct videobuf_dma_contig_memory *mem,
>  	unsigned int offset;
>  	int ret;
>  
> -	offset = vb->baddr & ~PAGE_MASK;
> +	offset = untagged_baddr & ~PAGE_MASK;
>  	mem->size = PAGE_ALIGN(vb->size + offset);
>  	ret = -EINVAL;
>  
>  	down_read(&mm->mmap_sem);
>  
> -	vma = find_vma(mm, vb->baddr);
> +	vma = find_vma(mm, untagged_baddr);
>  	if (!vma)
>  		goto out_up;
>  
> -	if ((vb->baddr + mem->size) > vma->vm_end)
> +	if ((untagged_baddr + mem->size) > vma->vm_end)
>  		goto out_up;
>  
>  	pages_done = 0;
>  	prev_pfn = 0; /* kill warning */
> -	user_address = vb->baddr;
> +	user_address = untagged_baddr;
>  
>  	while (pages_done < (mem->size >> PAGE_SHIFT)) {
>  		ret = follow_pfn(vma, user_address, &this_pfn);

I don't think vb->baddr here is anonymous mmap() but worth checking the
call paths.

-- 
Catalin
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v13 18/20] tee/optee, arm64: untag user pointers in check_mem_type

[Catalin Marinas]

On Wed, Mar 20, 2019 at 03:51:32PM +0100, Andrey Konovalov wrote:
> This patch is a part of a series that extends arm64 kernel ABI to allow to
> pass tagged user pointers (with the top byte set to something else other
> than 0x00) as syscall arguments.
> 
> check_mem_type() uses provided user pointers for vma lookups (via
> __check_mem_type()), which can only by done with untagged pointers.
> 
> Untag user pointers in this function.
> 
> Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
> ---
>  drivers/tee/optee/call.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/tee/optee/call.c b/drivers/tee/optee/call.c
> index a5afbe6dee68..e3be20264092 100644
> --- a/drivers/tee/optee/call.c
> +++ b/drivers/tee/optee/call.c
> @@ -563,6 +563,7 @@ static int check_mem_type(unsigned long start, size_t num_pages)
>  	int rc;
>  
>  	down_read(&mm->mmap_sem);
> +	start = untagged_addr(start);
>  	rc = __check_mem_type(find_vma(mm, start),
>  			      start + num_pages * PAGE_SIZE);
>  	up_read(&mm->mmap_sem);

I guess we could just untag this in tee_shm_register(). The tag is not
relevant to a TEE implementation (firmware) anyway.

-- 
Catalin
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v13 09/20] net, arm64: untag user pointers in tcp_zerocopy_receive

[Kevin Brodsky]

On 22/03/2019 12:04, Catalin Marinas wrote:
> On Wed, Mar 20, 2019 at 03:51:23PM +0100, Andrey Konovalov wrote:
>> This patch is a part of a series that extends arm64 kernel ABI to allow to
>> pass tagged user pointers (with the top byte set to something else other
>> than 0x00) as syscall arguments.
>>
>> tcp_zerocopy_receive() uses provided user pointers for vma lookups, which
>> can only by done with untagged pointers.
>>
>> Untag user pointers in this function.
>>
>> Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
>> ---
>>   net/ipv4/tcp.c | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
>> index 6baa6dc1b13b..855a1f68c1ea 100644
>> --- a/net/ipv4/tcp.c
>> +++ b/net/ipv4/tcp.c
>> @@ -1761,6 +1761,8 @@ static int tcp_zerocopy_receive(struct sock *sk,
>>   	if (address & (PAGE_SIZE - 1) || address != zc->address)
>>   		return -EINVAL;
>>   
>> +	address = untagged_addr(address);
>> +
>>   	if (sk->sk_state == TCP_LISTEN)
>>   		return -ENOTCONN;
> I don't think we need this patch if we stick to Vincenzo's ABI
> restrictions. Can zc->address be an anonymous mmap()? My understanding
> of TCP_ZEROCOPY_RECEIVE is that this is an mmap() on a socket, so user
> should not tag such pointer.

Good point, I hadn't looked into the interface properly. The `vma->vm_ops != 
&tcp_vm_ops` check just below makes sure that the mapping is specifically tied to a 
TCP socket, so definitely not included in the ABI relaxation.

> We want to allow tagged pointers to work transparently only for heap and
> stack, hence the restriction to anonymous mmap() and those addresses
> below sbrk(0).

That's not quite true: in the ABI relaxation v2, all private mappings that are either 
anonymous or backed by a regular file are included. The scope is quite a bit larger 
than heap and stack, even though this is what we're primarily interested in for now.

Kevin
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v13 14/20] drm/amdgpu, arm64: untag user pointers in amdgpu_ttm_tt_get_user_pages

[Kevin Brodsky]

On 22/03/2019 15:59, Catalin Marinas wrote:
> On Wed, Mar 20, 2019 at 03:51:28PM +0100, Andrey Konovalov wrote:
>> This patch is a part of a series that extends arm64 kernel ABI to allow to
>> pass tagged user pointers (with the top byte set to something else other
>> than 0x00) as syscall arguments.
>>
>> amdgpu_ttm_tt_get_user_pages() uses provided user pointers for vma
>> lookups, which can only by done with untagged pointers.
>>
>> Untag user pointers in this function.
>>
>> Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
>> ---
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 5 +++--
>>   1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>> index 73e71e61dc99..891b027fa33b 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>> @@ -751,10 +751,11 @@ int amdgpu_ttm_tt_get_user_pages(struct ttm_tt *ttm, struct page **pages)
>>   		 * check that we only use anonymous memory to prevent problems
>>   		 * with writeback
>>   		 */
>> -		unsigned long end = gtt->userptr + ttm->num_pages * PAGE_SIZE;
>> +		unsigned long userptr = untagged_addr(gtt->userptr);
>> +		unsigned long end = userptr + ttm->num_pages * PAGE_SIZE;
>>   		struct vm_area_struct *vma;
>>   
>> -		vma = find_vma(mm, gtt->userptr);
>> +		vma = find_vma(mm, userptr);
>>   		if (!vma || vma->vm_file || vma->vm_end < end) {
>>   			up_read(&mm->mmap_sem);
>>   			return -EPERM;
> I tried to track this down but I failed to see whether user could
> provide an tagged pointer here (under the restrictions as per Vincenzo's
> ABI document).

->userptr is set by radeon_ttm_tt_set_userptr(), itself called from 
radeon_gem_userptr_ioctl(). Any page-aligned value is allowed.

Kevin
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v13 17/20] media/v4l2-core, arm64: untag user pointers in videobuf_dma_contig_user_get

[Kevin Brodsky]

On 22/03/2019 16:07, Catalin Marinas wrote:
> On Wed, Mar 20, 2019 at 03:51:31PM +0100, Andrey Konovalov wrote:
>> This patch is a part of a series that extends arm64 kernel ABI to allow to
>> pass tagged user pointers (with the top byte set to something else other
>> than 0x00) as syscall arguments.
>>
>> videobuf_dma_contig_user_get() uses provided user pointers for vma
>> lookups, which can only by done with untagged pointers.
>>
>> Untag the pointers in this function.
>>
>> Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
>> ---
>>   drivers/media/v4l2-core/videobuf-dma-contig.c | 9 +++++----
>>   1 file changed, 5 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/media/v4l2-core/videobuf-dma-contig.c b/drivers/media/v4l2-core/videobuf-dma-contig.c
>> index e1bf50df4c70..8a1ddd146b17 100644
>> --- a/drivers/media/v4l2-core/videobuf-dma-contig.c
>> +++ b/drivers/media/v4l2-core/videobuf-dma-contig.c
>> @@ -160,6 +160,7 @@ static void videobuf_dma_contig_user_put(struct videobuf_dma_contig_memory *mem)
>>   static int videobuf_dma_contig_user_get(struct videobuf_dma_contig_memory *mem,
>>   					struct videobuf_buffer *vb)
>>   {
>> +	unsigned long untagged_baddr = untagged_addr(vb->baddr);
>>   	struct mm_struct *mm = current->mm;
>>   	struct vm_area_struct *vma;
>>   	unsigned long prev_pfn, this_pfn;
>> @@ -167,22 +168,22 @@ static int videobuf_dma_contig_user_get(struct videobuf_dma_contig_memory *mem,
>>   	unsigned int offset;
>>   	int ret;
>>   
>> -	offset = vb->baddr & ~PAGE_MASK;
>> +	offset = untagged_baddr & ~PAGE_MASK;
>>   	mem->size = PAGE_ALIGN(vb->size + offset);
>>   	ret = -EINVAL;
>>   
>>   	down_read(&mm->mmap_sem);
>>   
>> -	vma = find_vma(mm, vb->baddr);
>> +	vma = find_vma(mm, untagged_baddr);
>>   	if (!vma)
>>   		goto out_up;
>>   
>> -	if ((vb->baddr + mem->size) > vma->vm_end)
>> +	if ((untagged_baddr + mem->size) > vma->vm_end)
>>   		goto out_up;
>>   
>>   	pages_done = 0;
>>   	prev_pfn = 0; /* kill warning */
>> -	user_address = vb->baddr;
>> +	user_address = untagged_baddr;
>>   
>>   	while (pages_done < (mem->size >> PAGE_SHIFT)) {
>>   		ret = follow_pfn(vma, user_address, &this_pfn);
> I don't think vb->baddr here is anonymous mmap() but worth checking the
> call paths.

I spent some time on this, I didn't find any restriction on the kind of mapping 
that's allowed here. The API regarding V4L2_MEMORY_USERPTR doesn't seem to say 
anything about that either [0] [1]. It's probably best to ask the V4L2 maintainers.

Kevin

[0] https://www.kernel.org/doc/html/latest/media/uapi/v4l/vidioc-qbuf.html
[1] https://www.kernel.org/doc/html/latest/media/uapi/v4l/userp.html
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v13 04/20] mm, arm64: untag user pointers passed to memory syscalls

[Andrey Konovalov]

On Fri, Mar 22, 2019 at 12:44 PM Catalin Marinas
<catalin.marinas@arm.com> wrote:
>
> On Wed, Mar 20, 2019 at 03:51:18PM +0100, Andrey Konovalov wrote:
> > This patch is a part of a series that extends arm64 kernel ABI to allow to
> > pass tagged user pointers (with the top byte set to something else other
> > than 0x00) as syscall arguments.
> >
> > This patch allows tagged pointers to be passed to the following memory
> > syscalls: madvise, mbind, get_mempolicy, mincore, mlock, mlock2, brk,
> > mmap_pgoff, old_mmap, munmap, remap_file_pages, mprotect, pkey_mprotect,
> > mremap, msync and shmdt.
> >
> > This is done by untagging pointers passed to these syscalls in the
> > prologues of their handlers.
> >
> > Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
> > ---
> >  ipc/shm.c      | 2 ++
> >  mm/madvise.c   | 2 ++
> >  mm/mempolicy.c | 5 +++++
> >  mm/migrate.c   | 1 +
> >  mm/mincore.c   | 2 ++
> >  mm/mlock.c     | 5 +++++
> >  mm/mmap.c      | 7 +++++++
> >  mm/mprotect.c  | 1 +
> >  mm/mremap.c    | 2 ++
> >  mm/msync.c     | 2 ++
> >  10 files changed, 29 insertions(+)
>
> I wonder whether it's better to keep these as wrappers in the arm64
> code.

I don't think I understand what you propose, could you elaborate?
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v13 04/20] mm, arm64: untag user pointers passed to memory syscalls

[Steven Rostedt]

On Thu, 28 Mar 2019 19:10:07 +0100
Andrey Konovalov <andreyknvl@google.com> wrote:

> > > Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
> > > ---
> > >  ipc/shm.c      | 2 ++
> > >  mm/madvise.c   | 2 ++
> > >  mm/mempolicy.c | 5 +++++
> > >  mm/migrate.c   | 1 +
> > >  mm/mincore.c   | 2 ++
> > >  mm/mlock.c     | 5 +++++
> > >  mm/mmap.c      | 7 +++++++
> > >  mm/mprotect.c  | 1 +
> > >  mm/mremap.c    | 2 ++
> > >  mm/msync.c     | 2 ++
> > >  10 files changed, 29 insertions(+)  
> >
> > I wonder whether it's better to keep these as wrappers in the arm64
> > code.  
> 
> I don't think I understand what you propose, could you elaborate?

I believe Catalin is saying that instead of placing things like:

@@ -1593,6 +1593,7 @@ SYSCALL_DEFINE3(shmat, int, shmid, char __user *, shmaddr, int, shmflg)
 	unsigned long ret;
 	long err;
 
+	shmaddr = untagged_addr(shmaddr);

To instead have the shmaddr set to the untagged_addr() before calling
the system call, and passing the untagged addr to the system call, as
that goes through the arm64 architecture specific code first.

-- Steve
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v13 11/20] tracing, arm64: untag user pointers in seq_print_user_ip

[Andrey Konovalov]

On Fri, Mar 22, 2019 at 4:45 PM Catalin Marinas <catalin.marinas@arm.com> wrote:
>
> On Wed, Mar 20, 2019 at 03:51:25PM +0100, Andrey Konovalov wrote:
> > This patch is a part of a series that extends arm64 kernel ABI to allow to
> > pass tagged user pointers (with the top byte set to something else other
> > than 0x00) as syscall arguments.
> >
> > seq_print_user_ip() uses provided user pointers for vma lookups, which
> > can only by done with untagged pointers.
> >
> > Untag user pointers in this function.
> >
> > Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
> > ---
> >  kernel/trace/trace_output.c | 5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/kernel/trace/trace_output.c b/kernel/trace/trace_output.c
> > index 54373d93e251..6376bee93c84 100644
> > --- a/kernel/trace/trace_output.c
> > +++ b/kernel/trace/trace_output.c
> > @@ -370,6 +370,7 @@ static int seq_print_user_ip(struct trace_seq *s, struct mm_struct *mm,
> >  {
> >       struct file *file = NULL;
> >       unsigned long vmstart = 0;
> > +     unsigned long untagged_ip = untagged_addr(ip);
> >       int ret = 1;
> >
> >       if (s->full)
> > @@ -379,7 +380,7 @@ static int seq_print_user_ip(struct trace_seq *s, struct mm_struct *mm,
> >               const struct vm_area_struct *vma;
> >
> >               down_read(&mm->mmap_sem);
> > -             vma = find_vma(mm, ip);
> > +             vma = find_vma(mm, untagged_ip);
> >               if (vma) {
> >                       file = vma->vm_file;
> >                       vmstart = vma->vm_start;
> > @@ -388,7 +389,7 @@ static int seq_print_user_ip(struct trace_seq *s, struct mm_struct *mm,
> >                       ret = trace_seq_path(s, &file->f_path);
> >                       if (ret)
> >                               trace_seq_printf(s, "[+0x%lx]",
> > -                                              ip - vmstart);
> > +                                              untagged_ip - vmstart);
> >               }
> >               up_read(&mm->mmap_sem);
> >       }
>
> How would we end up with a tagged address here? Does "ip" here imply
> instruction pointer, which we wouldn't tag?

Yes, it's the instruction pointer. I think I got confused and decided
that it's OK to have instruction pointer tagged, but I guess it's not
a part of this ABI relaxation. I'll drop the patches that untag
instruction pointers.
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v13 13/20] bpf, arm64: untag user pointers in stack_map_get_build_id_offset

[Andrey Konovalov]

On Fri, Mar 22, 2019 at 4:52 PM Catalin Marinas <catalin.marinas@arm.com> wrote:
>
> On Wed, Mar 20, 2019 at 03:51:27PM +0100, Andrey Konovalov wrote:
> > This patch is a part of a series that extends arm64 kernel ABI to allow to
> > pass tagged user pointers (with the top byte set to something else other
> > than 0x00) as syscall arguments.
> >
> > stack_map_get_build_id_offset() uses provided user pointers for vma
> > lookups, which can only by done with untagged pointers.
> >
> > Untag user pointers in this function for doing the lookup and
> > calculating the offset, but save as is in the bpf_stack_build_id
> > struct.
> >
> > Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
> > ---
> >  kernel/bpf/stackmap.c | 6 ++++--
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/kernel/bpf/stackmap.c b/kernel/bpf/stackmap.c
> > index 950ab2f28922..bb89341d3faf 100644
> > --- a/kernel/bpf/stackmap.c
> > +++ b/kernel/bpf/stackmap.c
> > @@ -320,7 +320,9 @@ static void stack_map_get_build_id_offset(struct bpf_stack_build_id *id_offs,
> >       }
> >
> >       for (i = 0; i < trace_nr; i++) {
> > -             vma = find_vma(current->mm, ips[i]);
> > +             u64 untagged_ip = untagged_addr(ips[i]);
> > +
> > +             vma = find_vma(current->mm, untagged_ip);
> >               if (!vma || stack_map_get_build_id(vma, id_offs[i].build_id)) {
> >                       /* per entry fall back to ips */
> >                       id_offs[i].status = BPF_STACK_BUILD_ID_IP;
> > @@ -328,7 +330,7 @@ static void stack_map_get_build_id_offset(struct bpf_stack_build_id *id_offs,
> >                       memset(id_offs[i].build_id, 0, BPF_BUILD_ID_SIZE);
> >                       continue;
> >               }
> > -             id_offs[i].offset = (vma->vm_pgoff << PAGE_SHIFT) + ips[i]
> > +             id_offs[i].offset = (vma->vm_pgoff << PAGE_SHIFT) + untagged_ip
> >                       - vma->vm_start;
> >               id_offs[i].status = BPF_STACK_BUILD_ID_VALID;
> >       }
>
> Can the ips[*] here ever be tagged?

Those are instruction pointers AFAIU, so no, not within the current
ABI. I'll drop this patch. Thanks!

>
> --
> Catalin
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v13 09/20] net, arm64: untag user pointers in tcp_zerocopy_receive

[Andrey Konovalov]

On Mon, Mar 25, 2019 at 2:54 PM Kevin Brodsky <kevin.brodsky@arm.com> wrote:
>
> On 22/03/2019 12:04, Catalin Marinas wrote:
> > On Wed, Mar 20, 2019 at 03:51:23PM +0100, Andrey Konovalov wrote:
> >> This patch is a part of a series that extends arm64 kernel ABI to allow to
> >> pass tagged user pointers (with the top byte set to something else other
> >> than 0x00) as syscall arguments.
> >>
> >> tcp_zerocopy_receive() uses provided user pointers for vma lookups, which
> >> can only by done with untagged pointers.
> >>
> >> Untag user pointers in this function.
> >>
> >> Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
> >> ---
> >>   net/ipv4/tcp.c | 2 ++
> >>   1 file changed, 2 insertions(+)
> >>
> >> diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
> >> index 6baa6dc1b13b..855a1f68c1ea 100644
> >> --- a/net/ipv4/tcp.c
> >> +++ b/net/ipv4/tcp.c
> >> @@ -1761,6 +1761,8 @@ static int tcp_zerocopy_receive(struct sock *sk,
> >>      if (address & (PAGE_SIZE - 1) || address != zc->address)
> >>              return -EINVAL;
> >>
> >> +    address = untagged_addr(address);
> >> +
> >>      if (sk->sk_state == TCP_LISTEN)
> >>              return -ENOTCONN;
> > I don't think we need this patch if we stick to Vincenzo's ABI
> > restrictions. Can zc->address be an anonymous mmap()? My understanding
> > of TCP_ZEROCOPY_RECEIVE is that this is an mmap() on a socket, so user
> > should not tag such pointer.
>
> Good point, I hadn't looked into the interface properly. The `vma->vm_ops !=
> &tcp_vm_ops` check just below makes sure that the mapping is specifically tied to a
> TCP socket, so definitely not included in the ABI relaxation.
>
> > We want to allow tagged pointers to work transparently only for heap and
> > stack, hence the restriction to anonymous mmap() and those addresses
> > below sbrk(0).

Right, I'll drop this patch, thanks for noticing!

>
> That's not quite true: in the ABI relaxation v2, all private mappings that are either
> anonymous or backed by a regular file are included. The scope is quite a bit larger
> than heap and stack, even though this is what we're primarily interested in for now.
>
> Kevin
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v13 17/20] media/v4l2-core, arm64: untag user pointers in videobuf_dma_contig_user_get

[Andrey Konovalov]

On Mon, Mar 25, 2019 at 3:08 PM Kevin Brodsky <kevin.brodsky@arm.com> wrote:
>
> On 22/03/2019 16:07, Catalin Marinas wrote:
> > On Wed, Mar 20, 2019 at 03:51:31PM +0100, Andrey Konovalov wrote:
> >> This patch is a part of a series that extends arm64 kernel ABI to allow to
> >> pass tagged user pointers (with the top byte set to something else other
> >> than 0x00) as syscall arguments.
> >>
> >> videobuf_dma_contig_user_get() uses provided user pointers for vma
> >> lookups, which can only by done with untagged pointers.
> >>
> >> Untag the pointers in this function.
> >>
> >> Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
> >> ---
> >>   drivers/media/v4l2-core/videobuf-dma-contig.c | 9 +++++----
> >>   1 file changed, 5 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/media/v4l2-core/videobuf-dma-contig.c b/drivers/media/v4l2-core/videobuf-dma-contig.c
> >> index e1bf50df4c70..8a1ddd146b17 100644
> >> --- a/drivers/media/v4l2-core/videobuf-dma-contig.c
> >> +++ b/drivers/media/v4l2-core/videobuf-dma-contig.c
> >> @@ -160,6 +160,7 @@ static void videobuf_dma_contig_user_put(struct videobuf_dma_contig_memory *mem)
> >>   static int videobuf_dma_contig_user_get(struct videobuf_dma_contig_memory *mem,
> >>                                      struct videobuf_buffer *vb)
> >>   {
> >> +    unsigned long untagged_baddr = untagged_addr(vb->baddr);
> >>      struct mm_struct *mm = current->mm;
> >>      struct vm_area_struct *vma;
> >>      unsigned long prev_pfn, this_pfn;
> >> @@ -167,22 +168,22 @@ static int videobuf_dma_contig_user_get(struct videobuf_dma_contig_memory *mem,
> >>      unsigned int offset;
> >>      int ret;
> >>
> >> -    offset = vb->baddr & ~PAGE_MASK;
> >> +    offset = untagged_baddr & ~PAGE_MASK;
> >>      mem->size = PAGE_ALIGN(vb->size + offset);
> >>      ret = -EINVAL;
> >>
> >>      down_read(&mm->mmap_sem);
> >>
> >> -    vma = find_vma(mm, vb->baddr);
> >> +    vma = find_vma(mm, untagged_baddr);
> >>      if (!vma)
> >>              goto out_up;
> >>
> >> -    if ((vb->baddr + mem->size) > vma->vm_end)
> >> +    if ((untagged_baddr + mem->size) > vma->vm_end)
> >>              goto out_up;
> >>
> >>      pages_done = 0;
> >>      prev_pfn = 0; /* kill warning */
> >> -    user_address = vb->baddr;
> >> +    user_address = untagged_baddr;
> >>
> >>      while (pages_done < (mem->size >> PAGE_SHIFT)) {
> >>              ret = follow_pfn(vma, user_address, &this_pfn);
> > I don't think vb->baddr here is anonymous mmap() but worth checking the
> > call paths.

The call path is
__videobuf_iolock()->videobuf_dma_contig_user_get()->find_vma().

>
> I spent some time on this, I didn't find any restriction on the kind of mapping
> that's allowed here. The API regarding V4L2_MEMORY_USERPTR doesn't seem to say
> anything about that either [0] [1]. It's probably best to ask the V4L2 maintainers.

Mauro, could you comment on whether the vb->baddr argument for the
V4L2_MEMORY_USERPTR API can come from an anonymous memory mapping?

>
> Kevin
>
> [0] https://www.kernel.org/doc/html/latest/media/uapi/v4l/vidioc-qbuf.html
> [1] https://www.kernel.org/doc/html/latest/media/uapi/v4l/userp.html
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v13 18/20] tee/optee, arm64: untag user pointers in check_mem_type

[Andrey Konovalov]

On Fri, Mar 22, 2019 at 5:22 PM Catalin Marinas <catalin.marinas@arm.com> wrote:
>
> On Wed, Mar 20, 2019 at 03:51:32PM +0100, Andrey Konovalov wrote:
> > This patch is a part of a series that extends arm64 kernel ABI to allow to
> > pass tagged user pointers (with the top byte set to something else other
> > than 0x00) as syscall arguments.
> >
> > check_mem_type() uses provided user pointers for vma lookups (via
> > __check_mem_type()), which can only by done with untagged pointers.
> >
> > Untag user pointers in this function.
> >
> > Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
> > ---
> >  drivers/tee/optee/call.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/tee/optee/call.c b/drivers/tee/optee/call.c
> > index a5afbe6dee68..e3be20264092 100644
> > --- a/drivers/tee/optee/call.c
> > +++ b/drivers/tee/optee/call.c
> > @@ -563,6 +563,7 @@ static int check_mem_type(unsigned long start, size_t num_pages)
> >       int rc;
> >
> >       down_read(&mm->mmap_sem);
> > +     start = untagged_addr(start);
> >       rc = __check_mem_type(find_vma(mm, start),
> >                             start + num_pages * PAGE_SIZE);
> >       up_read(&mm->mmap_sem);
>
> I guess we could just untag this in tee_shm_register(). The tag is not
> relevant to a TEE implementation (firmware) anyway.

Will do in v14, thanks!

>
> --
> Catalin
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v13 10/20] kernel, arm64: untag user pointers in prctl_set_mm*

[Andrey Konovalov]

On Fri, Mar 22, 2019 at 4:41 PM Catalin Marinas <catalin.marinas@arm.com> wrote:
>
> On Wed, Mar 20, 2019 at 03:51:24PM +0100, Andrey Konovalov wrote:
> > @@ -2120,13 +2135,14 @@ static int prctl_set_mm(int opt, unsigned long addr,
> >       if (opt == PR_SET_MM_AUXV)
> >               return prctl_set_auxv(mm, addr, arg4);
> >
> > -     if (addr >= TASK_SIZE || addr < mmap_min_addr)
> > +     if (untagged_addr(addr) >= TASK_SIZE ||
> > +                     untagged_addr(addr) < mmap_min_addr)
> >               return -EINVAL;
> >
> >       error = -EINVAL;
> >
> >       down_write(&mm->mmap_sem);
> > -     vma = find_vma(mm, addr);
> > +     vma = find_vma(mm, untagged_addr(addr));
> >
> >       prctl_map.start_code    = mm->start_code;
> >       prctl_map.end_code      = mm->end_code;
>
> Does this mean that we are left with tagged addresses for the
> mm->start_code etc. values? I really don't think we should allow this,
> I'm not sure what the implications are in other parts of the kernel.
>
> Arguably, these are not even pointer values but some address ranges. I
> know we decided to relax this notion for mmap/mprotect/madvise() since
> the user function prototypes take pointer as arguments but it feels like
> we are overdoing it here (struct prctl_mm_map doesn't even have
> pointers).
>
> What is the use-case for allowing tagged addresses here? Can user space
> handle untagging?

I don't know any use cases for this. I did it because it seems to be
covered by the relaxed ABI. I'm not entirely sure what to do here,
should I just drop this patch?

>
> --
> Catalin
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v13 15/20] drm/radeon, arm64: untag user pointers in radeon_ttm_tt_pin_userptr

[Andrey Konovalov]

On Fri, Mar 22, 2019 at 5:01 PM Catalin Marinas <catalin.marinas@arm.com> wrote:
>
> On Wed, Mar 20, 2019 at 03:51:29PM +0100, Andrey Konovalov wrote:
> > This patch is a part of a series that extends arm64 kernel ABI to allow to
> > pass tagged user pointers (with the top byte set to something else other
> > than 0x00) as syscall arguments.
> >
> > radeon_ttm_tt_pin_userptr() uses provided user pointers for vma
> > lookups, which can only by done with untagged pointers.
> >
> > Untag user pointers in this function.
> >
> > Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
> > ---
> >  drivers/gpu/drm/radeon/radeon_ttm.c | 5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c b/drivers/gpu/drm/radeon/radeon_ttm.c
> > index 9920a6fc11bf..872a98796117 100644
> > --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> > +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> > @@ -497,9 +497,10 @@ static int radeon_ttm_tt_pin_userptr(struct ttm_tt *ttm)
> >       if (gtt->userflags & RADEON_GEM_USERPTR_ANONONLY) {
> >               /* check that we only pin down anonymous memory
> >                  to prevent problems with writeback */
> > -             unsigned long end = gtt->userptr + ttm->num_pages * PAGE_SIZE;
> > +             unsigned long userptr = untagged_addr(gtt->userptr);
> > +             unsigned long end = userptr + ttm->num_pages * PAGE_SIZE;
> >               struct vm_area_struct *vma;
> > -             vma = find_vma(gtt->usermm, gtt->userptr);
> > +             vma = find_vma(gtt->usermm, userptr);
> >               if (!vma || vma->vm_file || vma->vm_end < end)
> >                       return -EPERM;
> >       }
>
> Same comment as on the previous patch.

As Kevin wrote in the amd driver related thread, the call trace is:
radeon_gem_userptr_ioctl()->radeon_ttm_tt_set_userptr()->...->radeon_ttm_tt_pin_userptr()->find_vma()

>
> --
> Catalin
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v13 14/20] drm/amdgpu, arm64: untag user pointers in amdgpu_ttm_tt_get_user_pages

[Andrey Konovalov]

On Mon, Mar 25, 2019 at 11:21 PM Kuehling, Felix <Felix.Kuehling@amd.com> wrote:
>
> On 2019-03-20 10:51 a.m., Andrey Konovalov wrote:
> > This patch is a part of a series that extends arm64 kernel ABI to allow to
> > pass tagged user pointers (with the top byte set to something else other
> > than 0x00) as syscall arguments.
> >
> > amdgpu_ttm_tt_get_user_pages() uses provided user pointers for vma
> > lookups, which can only by done with untagged pointers.
> >
> > Untag user pointers in this function.
> >
> > Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
> > ---
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 5 +++--
> >   1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> > index 73e71e61dc99..891b027fa33b 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> > @@ -751,10 +751,11 @@ int amdgpu_ttm_tt_get_user_pages(struct ttm_tt *ttm, struct page **pages)
> >                * check that we only use anonymous memory to prevent problems
> >                * with writeback
> >                */
> > -             unsigned long end = gtt->userptr + ttm->num_pages * PAGE_SIZE;
> > +             unsigned long userptr = untagged_addr(gtt->userptr);
> > +             unsigned long end = userptr + ttm->num_pages * PAGE_SIZE;
> >               struct vm_area_struct *vma;
> >
> > -             vma = find_vma(mm, gtt->userptr);
> > +             vma = find_vma(mm, userptr);
> >               if (!vma || vma->vm_file || vma->vm_end < end) {
> >                       up_read(&mm->mmap_sem);
> >                       return -EPERM;
>
> We'll need to be careful that we don't break your change when the
> following commit gets applied through drm-next for Linux 5.2:
>
> https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-5.2-wip&id=915d3eecfa23693bac9e54cdacf84fb4efdcc5c4
>
> Would it make sense to apply the untagging in amdgpu_ttm_tt_set_userptr
> instead? That would avoid this conflict and I think it would clearly put
> the untagging into the user mode code path where the tagged pointer
> originates.
>
> In amdgpu_gem_userptr_ioctl and amdgpu_amdkfd_gpuvm.c (init_user_pages)
> we also set up an MMU notifier with the (tagged) pointer from user mode.
> That should probably also use the untagged address so that MMU notifiers
> for the untagged address get correctly matched up with the right BO. I'd
> move the untagging further up the call stack to cover that. For the GEM
> case I think amdgpu_gem_userptr_ioctl would be the right place. For the
> KFD case, I'd do this in amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu.

Will do in v14, thanks a lot for looking at this!

Is this applicable to the radeon driver (drivers/gpu/drm/radeon) as
well? It seems to be using very similar structure.

>
> Regards,
>    Felix
>
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v13 14/20] drm/amdgpu, arm64: untag user pointers in amdgpu_ttm_tt_get_user_pages

[Kuehling, Felix]

On 2019-04-02 10:37 a.m., Andrey Konovalov wrote:
> On Mon, Mar 25, 2019 at 11:21 PM Kuehling, Felix <Felix.Kuehling@amd.com> wrote:
>> On 2019-03-20 10:51 a.m., Andrey Konovalov wrote:
>>> This patch is a part of a series that extends arm64 kernel ABI to allow to
>>> pass tagged user pointers (with the top byte set to something else other
>>> than 0x00) as syscall arguments.
>>>
>>> amdgpu_ttm_tt_get_user_pages() uses provided user pointers for vma
>>> lookups, which can only by done with untagged pointers.
>>>
>>> Untag user pointers in this function.
>>>
>>> Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
>>> ---
>>>    drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 5 +++--
>>>    1 file changed, 3 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>>> index 73e71e61dc99..891b027fa33b 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>>> @@ -751,10 +751,11 @@ int amdgpu_ttm_tt_get_user_pages(struct ttm_tt *ttm, struct page **pages)
>>>                 * check that we only use anonymous memory to prevent problems
>>>                 * with writeback
>>>                 */
>>> -             unsigned long end = gtt->userptr + ttm->num_pages * PAGE_SIZE;
>>> +             unsigned long userptr = untagged_addr(gtt->userptr);
>>> +             unsigned long end = userptr + ttm->num_pages * PAGE_SIZE;
>>>                struct vm_area_struct *vma;
>>>
>>> -             vma = find_vma(mm, gtt->userptr);
>>> +             vma = find_vma(mm, userptr);
>>>                if (!vma || vma->vm_file || vma->vm_end < end) {
>>>                        up_read(&mm->mmap_sem);
>>>                        return -EPERM;
>> We'll need to be careful that we don't break your change when the
>> following commit gets applied through drm-next for Linux 5.2:
>>
>> https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-5.2-wip&id=915d3eecfa23693bac9e54cdacf84fb4efdcc5c4
>>
>> Would it make sense to apply the untagging in amdgpu_ttm_tt_set_userptr
>> instead? That would avoid this conflict and I think it would clearly put
>> the untagging into the user mode code path where the tagged pointer
>> originates.
>>
>> In amdgpu_gem_userptr_ioctl and amdgpu_amdkfd_gpuvm.c (init_user_pages)
>> we also set up an MMU notifier with the (tagged) pointer from user mode.
>> That should probably also use the untagged address so that MMU notifiers
>> for the untagged address get correctly matched up with the right BO. I'd
>> move the untagging further up the call stack to cover that. For the GEM
>> case I think amdgpu_gem_userptr_ioctl would be the right place. For the
>> KFD case, I'd do this in amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu.
> Will do in v14, thanks a lot for looking at this!
>
> Is this applicable to the radeon driver (drivers/gpu/drm/radeon) as
> well? It seems to be using very similar structure.

I think so. Radeon doesn't have the KFD bits any more. But the GEM 
interface and MMU notifier are very similar.

Regards,
   Felix


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v13 10/20] kernel, arm64: untag user pointers in prctl_set_mm*

[Andrey Konovalov]

On Mon, Apr 1, 2019 at 6:44 PM Andrey Konovalov <andreyknvl@google.com> wrote:
>
> On Fri, Mar 22, 2019 at 4:41 PM Catalin Marinas <catalin.marinas@arm.com> wrote:
> >
> > On Wed, Mar 20, 2019 at 03:51:24PM +0100, Andrey Konovalov wrote:
> > > @@ -2120,13 +2135,14 @@ static int prctl_set_mm(int opt, unsigned long addr,
> > >       if (opt == PR_SET_MM_AUXV)
> > >               return prctl_set_auxv(mm, addr, arg4);
> > >
> > > -     if (addr >= TASK_SIZE || addr < mmap_min_addr)
> > > +     if (untagged_addr(addr) >= TASK_SIZE ||
> > > +                     untagged_addr(addr) < mmap_min_addr)
> > >               return -EINVAL;
> > >
> > >       error = -EINVAL;
> > >
> > >       down_write(&mm->mmap_sem);
> > > -     vma = find_vma(mm, addr);
> > > +     vma = find_vma(mm, untagged_addr(addr));
> > >
> > >       prctl_map.start_code    = mm->start_code;
> > >       prctl_map.end_code      = mm->end_code;
> >
> > Does this mean that we are left with tagged addresses for the
> > mm->start_code etc. values? I really don't think we should allow this,
> > I'm not sure what the implications are in other parts of the kernel.
> >
> > Arguably, these are not even pointer values but some address ranges. I
> > know we decided to relax this notion for mmap/mprotect/madvise() since
> > the user function prototypes take pointer as arguments but it feels like
> > we are overdoing it here (struct prctl_mm_map doesn't even have
> > pointers).
> >
> > What is the use-case for allowing tagged addresses here? Can user space
> > handle untagging?
>
> I don't know any use cases for this. I did it because it seems to be
> covered by the relaxed ABI. I'm not entirely sure what to do here,
> should I just drop this patch?

ping

>
> >
> > --
> > Catalin
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v13 10/20] kernel, arm64: untag user pointers in prctl_set_mm*

[Catalin Marinas]

On Mon, Apr 01, 2019 at 06:44:34PM +0200, Andrey Konovalov wrote:
> On Fri, Mar 22, 2019 at 4:41 PM Catalin Marinas <catalin.marinas@arm.com> wrote:
> > On Wed, Mar 20, 2019 at 03:51:24PM +0100, Andrey Konovalov wrote:
> > > @@ -2120,13 +2135,14 @@ static int prctl_set_mm(int opt, unsigned long addr,
> > >       if (opt == PR_SET_MM_AUXV)
> > >               return prctl_set_auxv(mm, addr, arg4);
> > >
> > > -     if (addr >= TASK_SIZE || addr < mmap_min_addr)
> > > +     if (untagged_addr(addr) >= TASK_SIZE ||
> > > +                     untagged_addr(addr) < mmap_min_addr)
> > >               return -EINVAL;
> > >
> > >       error = -EINVAL;
> > >
> > >       down_write(&mm->mmap_sem);
> > > -     vma = find_vma(mm, addr);
> > > +     vma = find_vma(mm, untagged_addr(addr));
> > >
> > >       prctl_map.start_code    = mm->start_code;
> > >       prctl_map.end_code      = mm->end_code;
> >
> > Does this mean that we are left with tagged addresses for the
> > mm->start_code etc. values? I really don't think we should allow this,
> > I'm not sure what the implications are in other parts of the kernel.
> >
> > Arguably, these are not even pointer values but some address ranges. I
> > know we decided to relax this notion for mmap/mprotect/madvise() since
> > the user function prototypes take pointer as arguments but it feels like
> > we are overdoing it here (struct prctl_mm_map doesn't even have
> > pointers).
> >
> > What is the use-case for allowing tagged addresses here? Can user space
> > handle untagging?
> 
> I don't know any use cases for this. I did it because it seems to be
> covered by the relaxed ABI. I'm not entirely sure what to do here,
> should I just drop this patch?

If we allow tagged addresses to be passed here, we'd have to untag them
before they end up in the mm->start_code etc. members.

I know we are trying to relax the ABI here w.r.t. address ranges but
mostly because we couldn't figure out a way to document unambiguously
the difference between a user pointer that may be dereferenced by the
kernel (tags allowed) and an address typically used for managing the
address space layout. Suggestions welcomed.

I'd say just drop this patch and capture it in the ABI document.

-- 
Catalin
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v13 10/20] kernel, arm64: untag user pointers in prctl_set_mm*

[Andrey Konovalov]

On Fri, Apr 26, 2019 at 4:50 PM Catalin Marinas <catalin.marinas@arm.com> wrote:
>
> On Mon, Apr 01, 2019 at 06:44:34PM +0200, Andrey Konovalov wrote:
> > On Fri, Mar 22, 2019 at 4:41 PM Catalin Marinas <catalin.marinas@arm.com> wrote:
> > > On Wed, Mar 20, 2019 at 03:51:24PM +0100, Andrey Konovalov wrote:
> > > > @@ -2120,13 +2135,14 @@ static int prctl_set_mm(int opt, unsigned long addr,
> > > >       if (opt == PR_SET_MM_AUXV)
> > > >               return prctl_set_auxv(mm, addr, arg4);
> > > >
> > > > -     if (addr >= TASK_SIZE || addr < mmap_min_addr)
> > > > +     if (untagged_addr(addr) >= TASK_SIZE ||
> > > > +                     untagged_addr(addr) < mmap_min_addr)
> > > >               return -EINVAL;
> > > >
> > > >       error = -EINVAL;
> > > >
> > > >       down_write(&mm->mmap_sem);
> > > > -     vma = find_vma(mm, addr);
> > > > +     vma = find_vma(mm, untagged_addr(addr));
> > > >
> > > >       prctl_map.start_code    = mm->start_code;
> > > >       prctl_map.end_code      = mm->end_code;
> > >
> > > Does this mean that we are left with tagged addresses for the
> > > mm->start_code etc. values? I really don't think we should allow this,
> > > I'm not sure what the implications are in other parts of the kernel.
> > >
> > > Arguably, these are not even pointer values but some address ranges. I
> > > know we decided to relax this notion for mmap/mprotect/madvise() since
> > > the user function prototypes take pointer as arguments but it feels like
> > > we are overdoing it here (struct prctl_mm_map doesn't even have
> > > pointers).
> > >
> > > What is the use-case for allowing tagged addresses here? Can user space
> > > handle untagging?
> >
> > I don't know any use cases for this. I did it because it seems to be
> > covered by the relaxed ABI. I'm not entirely sure what to do here,
> > should I just drop this patch?
>
> If we allow tagged addresses to be passed here, we'd have to untag them
> before they end up in the mm->start_code etc. members.
>
> I know we are trying to relax the ABI here w.r.t. address ranges but
> mostly because we couldn't figure out a way to document unambiguously
> the difference between a user pointer that may be dereferenced by the
> kernel (tags allowed) and an address typically used for managing the
> address space layout. Suggestions welcomed.
>
> I'd say just drop this patch and capture it in the ABI document.

OK, will do in v14.

Vincenzo, could you add a note about this into tour patchset?

>
> --
> Catalin
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v13 16/20] IB/mlx4, arm64: untag user pointers in mlx4_get_umem_mr

[Leon Romanovsky]

On Wed, Mar 20, 2019 at 03:51:30PM +0100, Andrey Konovalov wrote:
> This patch is a part of a series that extends arm64 kernel ABI to allow to
> pass tagged user pointers (with the top byte set to something else other
> than 0x00) as syscall arguments.
>
> mlx4_get_umem_mr() uses provided user pointers for vma lookups, which can
> only by done with untagged pointers.
>
> Untag user pointers in this function.
>
> Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
> ---
>  drivers/infiniband/hw/mlx4/mr.c | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/infiniband/hw/mlx4/mr.c b/drivers/infiniband/hw/mlx4/mr.c
> index 395379a480cb..9a35ed2c6a6f 100644
> --- a/drivers/infiniband/hw/mlx4/mr.c
> +++ b/drivers/infiniband/hw/mlx4/mr.c
> @@ -378,6 +378,7 @@ static struct ib_umem *mlx4_get_umem_mr(struct ib_udata *udata, u64 start,
>  	 * again
>  	 */
>  	if (!ib_access_writable(access_flags)) {
> +		unsigned long untagged_start = untagged_addr(start);
>  		struct vm_area_struct *vma;
>
>  		down_read(&current->mm->mmap_sem);
> @@ -386,9 +387,9 @@ static struct ib_umem *mlx4_get_umem_mr(struct ib_udata *udata, u64 start,
>  		 * cover the memory, but for now it requires a single vma to
>  		 * entirely cover the MR to support RO mappings.
>  		 */
> -		vma = find_vma(current->mm, start);
> -		if (vma && vma->vm_end >= start + length &&
> -		    vma->vm_start <= start) {
> +		vma = find_vma(current->mm, untagged_start);
> +		if (vma && vma->vm_end >= untagged_start + length &&
> +		    vma->vm_start <= untagged_start) {
>  			if (vma->vm_flags & VM_WRITE)
>  				access_flags |= IB_ACCESS_LOCAL_WRITE;
>  		} else {
> --

Thanks,
Reviewed-by: Leon Romanovsky <leonro@mellanox.com>

Interesting, the followup question is why mlx4 is only one driver in IB which
needs such code in umem_mr. I'll take a look on it.

Thanks
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v13 16/20] IB/mlx4, arm64: untag user pointers in mlx4_get_umem_mr

[Catalin Marinas]

(trimmed down the cc list slightly as the message bounces)

On Mon, Apr 29, 2019 at 09:09:15PM +0300, Leon Romanovsky wrote:
> On Wed, Mar 20, 2019 at 03:51:30PM +0100, Andrey Konovalov wrote:
> > This patch is a part of a series that extends arm64 kernel ABI to allow to
> > pass tagged user pointers (with the top byte set to something else other
> > than 0x00) as syscall arguments.
> >
> > mlx4_get_umem_mr() uses provided user pointers for vma lookups, which can
> > only by done with untagged pointers.
> >
> > Untag user pointers in this function.
> >
> > Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
> > ---
> >  drivers/infiniband/hw/mlx4/mr.c | 7 ++++---
> >  1 file changed, 4 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/infiniband/hw/mlx4/mr.c b/drivers/infiniband/hw/mlx4/mr.c
> > index 395379a480cb..9a35ed2c6a6f 100644
> > --- a/drivers/infiniband/hw/mlx4/mr.c
> > +++ b/drivers/infiniband/hw/mlx4/mr.c
> > @@ -378,6 +378,7 @@ static struct ib_umem *mlx4_get_umem_mr(struct ib_udata *udata, u64 start,
> >  	 * again
> >  	 */
> >  	if (!ib_access_writable(access_flags)) {
> > +		unsigned long untagged_start = untagged_addr(start);
> >  		struct vm_area_struct *vma;
> >
> >  		down_read(&current->mm->mmap_sem);
> > @@ -386,9 +387,9 @@ static struct ib_umem *mlx4_get_umem_mr(struct ib_udata *udata, u64 start,
> >  		 * cover the memory, but for now it requires a single vma to
> >  		 * entirely cover the MR to support RO mappings.
> >  		 */
> > -		vma = find_vma(current->mm, start);
> > -		if (vma && vma->vm_end >= start + length &&
> > -		    vma->vm_start <= start) {
> > +		vma = find_vma(current->mm, untagged_start);
> > +		if (vma && vma->vm_end >= untagged_start + length &&
> > +		    vma->vm_start <= untagged_start) {
> >  			if (vma->vm_flags & VM_WRITE)
> >  				access_flags |= IB_ACCESS_LOCAL_WRITE;
> >  		} else {
> > --
> 
> Thanks,
> Reviewed-by: Leon Romanovsky <leonro@mellanox.com>

Thanks for the review.

> Interesting, the followup question is why mlx4 is only one driver in IB which
> needs such code in umem_mr. I'll take a look on it.

I don't know. Just using the light heuristics of find_vma() shows some
other places. For example, ib_umem_odp_get() gets the umem->address via
ib_umem_start(). This was previously set in ib_umem_get() as called from
mlx4_get_umem_mr(). Should the above patch have just untagged "start" on
entry?

BTW, what's the provenience of such "start" address here? Is it
something that the user would have malloc()'ed? We try to impose some
restrictions one what is allowed to be tagged in user so that we don't
have to untag the addresses in the kernel. For example, if it was the
result of an mmap() on the device file, we don't allow tagging.

Thanks.

-- 
Catalin

Re: [PATCH v13 16/20] IB/mlx4, arm64: untag user pointers in mlx4_get_umem_mr

[Leon Romanovsky]

On Tue, Apr 30, 2019 at 12:16:25PM +0100, Catalin Marinas wrote:
> (trimmed down the cc list slightly as the message bounces)
>
> On Mon, Apr 29, 2019 at 09:09:15PM +0300, Leon Romanovsky wrote:
> > On Wed, Mar 20, 2019 at 03:51:30PM +0100, Andrey Konovalov wrote:
> > > This patch is a part of a series that extends arm64 kernel ABI to allow to
> > > pass tagged user pointers (with the top byte set to something else other
> > > than 0x00) as syscall arguments.
> > >
> > > mlx4_get_umem_mr() uses provided user pointers for vma lookups, which can
> > > only by done with untagged pointers.
> > >
> > > Untag user pointers in this function.
> > >
> > > Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
> > > ---
> > >  drivers/infiniband/hw/mlx4/mr.c | 7 ++++---
> > >  1 file changed, 4 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/infiniband/hw/mlx4/mr.c b/drivers/infiniband/hw/mlx4/mr.c
> > > index 395379a480cb..9a35ed2c6a6f 100644
> > > --- a/drivers/infiniband/hw/mlx4/mr.c
> > > +++ b/drivers/infiniband/hw/mlx4/mr.c
> > > @@ -378,6 +378,7 @@ static struct ib_umem *mlx4_get_umem_mr(struct ib_udata *udata, u64 start,
> > >  	 * again
> > >  	 */
> > >  	if (!ib_access_writable(access_flags)) {
> > > +		unsigned long untagged_start = untagged_addr(start);
> > >  		struct vm_area_struct *vma;
> > >
> > >  		down_read(&current->mm->mmap_sem);
> > > @@ -386,9 +387,9 @@ static struct ib_umem *mlx4_get_umem_mr(struct ib_udata *udata, u64 start,
> > >  		 * cover the memory, but for now it requires a single vma to
> > >  		 * entirely cover the MR to support RO mappings.
> > >  		 */
> > > -		vma = find_vma(current->mm, start);
> > > -		if (vma && vma->vm_end >= start + length &&
> > > -		    vma->vm_start <= start) {
> > > +		vma = find_vma(current->mm, untagged_start);
> > > +		if (vma && vma->vm_end >= untagged_start + length &&
> > > +		    vma->vm_start <= untagged_start) {
> > >  			if (vma->vm_flags & VM_WRITE)
> > >  				access_flags |= IB_ACCESS_LOCAL_WRITE;
> > >  		} else {
> > > --
> >
> > Thanks,
> > Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
>
> Thanks for the review.
>
> > Interesting, the followup question is why mlx4 is only one driver in IB which
> > needs such code in umem_mr. I'll take a look on it.
>
> I don't know. Just using the light heuristics of find_vma() shows some
> other places. For example, ib_umem_odp_get() gets the umem->address via
> ib_umem_start(). This was previously set in ib_umem_get() as called from
> mlx4_get_umem_mr(). Should the above patch have just untagged "start" on
> entry?

ODP flows are not applicable to any driver except mlx5.
According to commit message of d8f9cc328c88 ("IB/mlx4: Mark user
MR as writable if actual virtual memory is writable"), the code in its
current form needed to deal with different mappings between RDMA memory
requested and VMA memory underlined.

>
> BTW, what's the provenience of such "start" address here? Is it
> something that the user would have malloc()'ed? We try to impose some
> restrictions one what is allowed to be tagged in user so that we don't
> have to untag the addresses in the kernel. For example, if it was the
> result of an mmap() on the device file, we don't allow tagging.

The *_reg_user_mr() is called from userspace through ibv_reg_mr() call [1]
and this is how "address" and access flags are provided.

Right now, the address should point to memory accessible by
get_user_pages(), however mmap-ed memory uses remap_pfn_range()
to provide such pages which makes them unusable for get_user_pages().

I would be glad to see this is a current limitation of RDMA stack and
not as a final design decision.

[1] https://linux.die.net/man/3/ibv_reg_mr

>
> Thanks.
>
> --
> Catalin

Re: [PATCH v13 10/20] kernel, arm64: untag user pointers in prctl_set_mm*

[Vincenzo Frascino]

Hi Andrey,

sorry for the late reply, I came back from holiday and try to catch up with the
emails.

On 4/29/19 3:23 PM, Andrey Konovalov wrote:
> On Fri, Apr 26, 2019 at 4:50 PM Catalin Marinas <catalin.marinas@arm.com> wrote:
>>
>> On Mon, Apr 01, 2019 at 06:44:34PM +0200, Andrey Konovalov wrote:
>>> On Fri, Mar 22, 2019 at 4:41 PM Catalin Marinas <catalin.marinas@arm.com> wrote:
>>>> On Wed, Mar 20, 2019 at 03:51:24PM +0100, Andrey Konovalov wrote:
>>>>> @@ -2120,13 +2135,14 @@ static int prctl_set_mm(int opt, unsigned long addr,
>>>>>       if (opt == PR_SET_MM_AUXV)
>>>>>               return prctl_set_auxv(mm, addr, arg4);
>>>>>
>>>>> -     if (addr >= TASK_SIZE || addr < mmap_min_addr)
>>>>> +     if (untagged_addr(addr) >= TASK_SIZE ||
>>>>> +                     untagged_addr(addr) < mmap_min_addr)
>>>>>               return -EINVAL;
>>>>>
>>>>>       error = -EINVAL;
>>>>>
>>>>>       down_write(&mm->mmap_sem);
>>>>> -     vma = find_vma(mm, addr);
>>>>> +     vma = find_vma(mm, untagged_addr(addr));
>>>>>
>>>>>       prctl_map.start_code    = mm->start_code;
>>>>>       prctl_map.end_code      = mm->end_code;
>>>>
>>>> Does this mean that we are left with tagged addresses for the
>>>> mm->start_code etc. values? I really don't think we should allow this,
>>>> I'm not sure what the implications are in other parts of the kernel.
>>>>
>>>> Arguably, these are not even pointer values but some address ranges. I
>>>> know we decided to relax this notion for mmap/mprotect/madvise() since
>>>> the user function prototypes take pointer as arguments but it feels like
>>>> we are overdoing it here (struct prctl_mm_map doesn't even have
>>>> pointers).
>>>>
>>>> What is the use-case for allowing tagged addresses here? Can user space
>>>> handle untagging?
>>>
>>> I don't know any use cases for this. I did it because it seems to be
>>> covered by the relaxed ABI. I'm not entirely sure what to do here,
>>> should I just drop this patch?
>>
>> If we allow tagged addresses to be passed here, we'd have to untag them
>> before they end up in the mm->start_code etc. members.
>>
>> I know we are trying to relax the ABI here w.r.t. address ranges but
>> mostly because we couldn't figure out a way to document unambiguously
>> the difference between a user pointer that may be dereferenced by the
>> kernel (tags allowed) and an address typically used for managing the
>> address space layout. Suggestions welcomed.
>>
>> I'd say just drop this patch and capture it in the ABI document.
> 
> OK, will do in v14.
> 
> Vincenzo, could you add a note about this into tour patchset?
>

Ok, I will add a note that covers this case in v3 of my document.

>>
>> --
>> Catalin

-- 
Regards,
Vincenzo
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v13 16/20] IB/mlx4, arm64: untag user pointers in mlx4_get_umem_mr

[Jason Gunthorpe]

On Tue, Apr 30, 2019 at 12:16:25PM +0100, Catalin Marinas wrote:
> > Interesting, the followup question is why mlx4 is only one driver in IB which
> > needs such code in umem_mr. I'll take a look on it.
> 
> I don't know. Just using the light heuristics of find_vma() shows some
> other places. For example, ib_umem_odp_get() gets the umem->address via
> ib_umem_start(). This was previously set in ib_umem_get() as called from
> mlx4_get_umem_mr(). Should the above patch have just untagged "start" on
> entry?

I have a feeling that there needs to be something for this in the odp
code..

Presumably mmu notifiers and what not also use untagged pointers? Most
likely then the umem should also be storing untagged pointers.

This probably becomes problematic because we do want the tag in cases
talking about the base VA of the MR..

Jason

Re: [PATCH v13 16/20] IB/mlx4, arm64: untag user pointers in mlx4_get_umem_mr

[Catalin Marinas]

Thanks Jason and Leon for the information.

On Thu, May 02, 2019 at 03:44:42PM -0300, Jason Gunthorpe wrote:
> On Tue, Apr 30, 2019 at 12:16:25PM +0100, Catalin Marinas wrote:
> > > Interesting, the followup question is why mlx4 is only one driver in IB which
> > > needs such code in umem_mr. I'll take a look on it.
> > 
> > I don't know. Just using the light heuristics of find_vma() shows some
> > other places. For example, ib_umem_odp_get() gets the umem->address via
> > ib_umem_start(). This was previously set in ib_umem_get() as called from
> > mlx4_get_umem_mr(). Should the above patch have just untagged "start" on
> > entry?
> 
> I have a feeling that there needs to be something for this in the odp
> code..
> 
> Presumably mmu notifiers and what not also use untagged pointers? Most
> likely then the umem should also be storing untagged pointers.

Yes.

> This probably becomes problematic because we do want the tag in cases
> talking about the base VA of the MR..

It depends on whether the tag is relevant to the kernel or not. The only
useful case so far is for the kernel performing copy_form_user() etc.
accesses so they'd get checked in the presence of hardware memory
tagging (MTE; but it's not mandatory, a 0 tag would do as well).

If we talk about a memory range where the content is relatively opaque
(or irrelevant) to the kernel code, we don't really need the tag. I'm
not familiar to RDMA but I presume it would be a device accessing such
MR but not through the user VA directly. The tag is a property of the
buffer address/pointer when accessed by the CPU at that specific address
range. Any DMA or even kernel accessing it through the linear mapping
(get_user_pages()) would drop such tag.

-- 
Catalin

Re: [PATCH v13 16/20] IB/mlx4, arm64: untag user pointers in mlx4_get_umem_mr

[Jason Gunthorpe]

On Fri, May 03, 2019 at 05:28:46PM +0100, Catalin Marinas wrote:
> Thanks Jason and Leon for the information.
> 
> On Thu, May 02, 2019 at 03:44:42PM -0300, Jason Gunthorpe wrote:
> > On Tue, Apr 30, 2019 at 12:16:25PM +0100, Catalin Marinas wrote:
> > > > Interesting, the followup question is why mlx4 is only one driver in IB which
> > > > needs such code in umem_mr. I'll take a look on it.
> > > 
> > > I don't know. Just using the light heuristics of find_vma() shows some
> > > other places. For example, ib_umem_odp_get() gets the umem->address via
> > > ib_umem_start(). This was previously set in ib_umem_get() as called from
> > > mlx4_get_umem_mr(). Should the above patch have just untagged "start" on
> > > entry?
> > 
> > I have a feeling that there needs to be something for this in the odp
> > code..
> > 
> > Presumably mmu notifiers and what not also use untagged pointers? Most
> > likely then the umem should also be storing untagged pointers.
> 
> Yes.
> 
> > This probably becomes problematic because we do want the tag in cases
> > talking about the base VA of the MR..
> 
> It depends on whether the tag is relevant to the kernel or not. The only
> useful case so far is for the kernel performing copy_form_user() etc.
> accesses so they'd get checked in the presence of hardware memory
> tagging (MTE; but it's not mandatory, a 0 tag would do as well).
> 
> If we talk about a memory range where the content is relatively opaque
> (or irrelevant) to the kernel code, we don't really need the tag. I'm
> not familiar to RDMA but I presume it would be a device accessing such
> MR but not through the user VA directly. 

RDMA exposes the user VA directly (the IOVA) as part of the wire
protocol, we must preserve the tag in these cases as that is what the
userspace is using for the pointer.

So the ODP stuff will definately need some adjusting when it interacts
with the mmu notifiers and get user pages.

Jason