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@xxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/amd-gfx
