On Mon, Apr 1, 2019 at 6:44 PM Andrey Konovalov <andreyknvl@xxxxxxxxxx> 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? ping > > > > > -- > > Catalin
