On Fri, May 31, 2019 at 6:20 PM Catalin Marinas catalin.marinas@arm.com wrote:
On Fri, May 31, 2019 at 04:29:10PM +0200, Andrey Konovalov wrote:
On Thu, May 30, 2019 at 7:15 PM Catalin Marinas catalin.marinas@arm.com wrote:
On Tue, May 28, 2019 at 04:14:45PM +0200, Andrey Konovalov wrote:
Thanks for a lot of valuable input! I've read through all the replies and got somewhat lost. What are the changes I need to do to this series?
- Should I move untagging for memory syscalls back to the generic
code so other arches would make use of it as well, or should I keep the arm64 specific memory syscalls wrappers and address the comments on that patch?
Keep them generic again but make sure we get agreement with Khalid on the actual ABI implications for sparc.
OK, will do. I find it hard to understand what the ABI implications are. I'll post the next version without untagging in brk, mmap, munmap, mremap (for new_address), mmap_pgoff, remap_file_pages, shmat and shmdt.
It's more about not relaxing the ABI to accept non-zero top-byte unless we have a use-case for it. For mmap() etc., I don't think that's needed but if you think otherwise, please raise it.
- Should I make untagging opt-in and controlled by a command line argument?
Opt-in, yes, but per task rather than kernel command line option. prctl() is a possibility of opting in.
OK. Should I store a flag somewhere in task_struct? Should it be inheritable on clone?
A TIF flag would do but I'd say leave it out for now (default opted in) until we figure out the best way to do this (can be a patch on top of this series).
You mean leave the whole opt-in/prctl part out? So the only change would be to move untagging for memory syscalls into generic code?
Thanks.
-- Catalin