On Mon, Mar 23, 2015 at 3:05 PM, <josh@xxxxxxxxxxxxxxxx> wrote: > On Mon, Mar 23, 2015 at 02:11:45PM +0000, David Drysdale wrote: >> On Sun, Mar 15, 2015 at 7:59 AM, Josh Triplett <josh@xxxxxxxxxxxxxxxx> wrote: >> > diff --git a/arch/x86/ia32/ia32entry.S b/arch/x86/ia32/ia32entry.S >> > index 0286735..ba28306 100644 >> > --- a/arch/x86/ia32/ia32entry.S >> > +++ b/arch/x86/ia32/ia32entry.S >> > @@ -483,6 +483,7 @@ GLOBAL(\label) >> > PTREGSCALL stub32_execveat, compat_sys_execveat >> > PTREGSCALL stub32_fork, sys_fork >> > PTREGSCALL stub32_vfork, sys_vfork >> > + PTREGSCALL stub32_clone4, compat_sys_clone4 >> > >> > ALIGN >> > GLOBAL(stub32_clone) >> > diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S >> > index 1d74d16..ead143f 100644 >> > --- a/arch/x86/kernel/entry_64.S >> > +++ b/arch/x86/kernel/entry_64.S >> > @@ -520,6 +520,7 @@ END(\label) >> > FORK_LIKE clone >> > FORK_LIKE fork >> > FORK_LIKE vfork >> > + FORK_LIKE clone4 >> > FIXED_FRAME stub_iopl, sys_iopl >> > >> > ENTRY(stub_execve) >> > diff --git a/arch/x86/syscalls/syscall_32.tbl b/arch/x86/syscalls/syscall_32.tbl >> > index b3560ec..56fcc90 100644 >> > --- a/arch/x86/syscalls/syscall_32.tbl >> > +++ b/arch/x86/syscalls/syscall_32.tbl >> > @@ -365,3 +365,4 @@ >> > 356 i386 memfd_create sys_memfd_create >> > 357 i386 bpf sys_bpf >> > 358 i386 execveat sys_execveat stub32_execveat >> > +359 i386 clone4 sys_clone4 stub32_clone4 >> > diff --git a/arch/x86/syscalls/syscall_64.tbl b/arch/x86/syscalls/syscall_64.tbl >> > index 8d656fb..af15b0f 100644 >> > --- a/arch/x86/syscalls/syscall_64.tbl >> > +++ b/arch/x86/syscalls/syscall_64.tbl >> > @@ -329,6 +329,7 @@ >> > 320 common kexec_file_load sys_kexec_file_load >> > 321 common bpf sys_bpf >> > 322 64 execveat stub_execveat >> > +323 64 clone4 stub_clone4 >> > >> > # >> > # x32-specific system call numbers start at 512 to avoid cache impact >> > @@ -368,3 +369,4 @@ >> > 543 x32 io_setup compat_sys_io_setup >> > 544 x32 io_submit compat_sys_io_submit >> > 545 x32 execveat stub_x32_execveat >> > +546 x32 clone4 stub32_clone4 >> >> Doesn't this need an x32 specific wrapper (to ensure the full >> set of registers are saved)? > > I'm not an x32 expert; I don't know how x32 interacts with pt_regs and > compat syscalls. Could an x32 expert weigh in, please? > > - Josh Triplett (In the absence of an x32 expert chiming in...) As I understand it: - stub32_clone4 expects 32-bit calling conventions and calls compat_sys_clone4 - stub_clone4 expects 64-bit calling conventions and calls sys_clone4 - stub_x32_clone4 would expect 64-bit calling conventions but call compat_sys_clone4. Also, I have a suspicion that different field types in the [compat_]clone4_args structure may cause problems -- I *think* its (final) layout will be 4+4+4+4+4+4 on 32-bit, 8+8+8+8+8+4 on 64-bit, but 4+4+8+8+4+4 on x32. Have you tried running a test with a userspace program compiled with -mx32? -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
