On Tue, Apr 02, 2019 at 02:47:34PM +0200, Andrey Konovalov wrote: > On Fri, Mar 29, 2019 at 11:30 AM Catalin Marinas > <catalin.marinas@xxxxxxx> wrote: > > On Thu, Mar 28, 2019 at 02:19:34PM -0400, Steven Rostedt wrote: > > > On Thu, 28 Mar 2019 19:10:07 +0100 > > > Andrey Konovalov <andreyknvl@xxxxxxxxxx> wrote: > > > > > > > > > Signed-off-by: Andrey Konovalov <andreyknvl@xxxxxxxxxx> > > > > > > --- > > > > > > 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. > > > > Indeed. For example, we already have a SYSCALL_DEFINE6(mmap, ...) in > > arch/arm64/kernel/sys.c, just add the untagging there. We could do > > something similar for the other syscalls. I don't mind doing this in the > > generic code but if it's only needed for arm64, I'd rather keep the > > generic changes to a minimum. > > Do I understand correctly, that I'll need to add ksys_ wrappers for > each of the memory syscalls, and then redefine them in > arch/arm64/kernel/sys.c with arm64_ prefix, like it is done for the > personality syscall right now? This will require generic changes as > well. Yes. My aim is to keep the number of untagged_addr() calls in the generic code to a minimum (rather than just keeping the generic code changes small). -- Catalin