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