Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
arch/x86/syscalls/syscall_64.tbl between commit
arch/x86/syscalls/syscall_64.tbl ("x32: Add x32 system calls to
syscall/syscall_64.tbl") from the tip tree and commit "syscalls, x86: add
__NR_kcmp syscall" from the akpm tree.
I fixed it up (see below) but did not know if this call should be marked
"common".
--
Cheers,
Stephen Rothwell [email protected]
diff --cc arch/x86/syscalls/syscall_64.tbl
index 4aecc7e,ac3066f..0000000
--- a/arch/x86/syscalls/syscall_64.tbl
+++ b/arch/x86/syscalls/syscall_64.tbl
@@@ -304,50 -304,18 +304,51 @@@
295 64 preadv sys_preadv
296 64 pwritev sys_pwritev
297 64 rt_tgsigqueueinfo sys_rt_tgsigqueueinfo
-298 64 perf_event_open sys_perf_event_open
+298 common perf_event_open sys_perf_event_open
299 64 recvmmsg sys_recvmmsg
-300 64 fanotify_init sys_fanotify_init
-301 64 fanotify_mark sys_fanotify_mark
-302 64 prlimit64 sys_prlimit64
-303 64 name_to_handle_at sys_name_to_handle_at
-304 64 open_by_handle_at sys_open_by_handle_at
-305 64 clock_adjtime sys_clock_adjtime
-306 64 syncfs sys_syncfs
+300 common fanotify_init sys_fanotify_init
+301 common fanotify_mark sys_fanotify_mark
+302 common prlimit64 sys_prlimit64
+303 common name_to_handle_at sys_name_to_handle_at
+304 common open_by_handle_at sys_open_by_handle_at
+305 common clock_adjtime sys_clock_adjtime
+306 common syncfs sys_syncfs
307 64 sendmmsg sys_sendmmsg
-308 64 setns sys_setns
-309 64 getcpu sys_getcpu
+308 common setns sys_setns
+309 common getcpu sys_getcpu
310 64 process_vm_readv sys_process_vm_readv
311 64 process_vm_writev sys_process_vm_writev
+ 312 64 kcmp sys_kcmp
+#
+# x32-specific system call numbers start at 512 to avoid cache impact
+# for native 64-bit operation.
+#
+512 x32 rt_sigaction sys32_rt_sigaction
+513 x32 rt_sigreturn stub_x32_rt_sigreturn
+514 x32 ioctl compat_sys_ioctl
+515 x32 readv compat_sys_readv
+516 x32 writev compat_sys_writev
+517 x32 recvfrom compat_sys_recvfrom
+518 x32 sendmsg compat_sys_sendmsg
+519 x32 recvmsg compat_sys_recvmsg
+520 x32 execve stub_x32_execve
+521 x32 times compat_sys_times
+522 x32 rt_sigpending sys32_rt_sigpending
+523 x32 rt_sigtimedwait compat_sys_rt_sigtimedwait
+524 x32 rt_sigqueueinfo sys32_rt_sigqueueinfo
+525 x32 sigaltstack stub_x32_sigaltstack
+526 x32 timer_create compat_sys_timer_create
+527 x32 mq_notify compat_sys_mq_notify
+528 x32 kexec_load compat_sys_kexec_load
+529 x32 waitid compat_sys_waitid
+530 x32 set_robust_list compat_sys_set_robust_list
+531 x32 get_robust_list compat_sys_get_robust_list
+532 x32 vmsplice compat_sys_vmsplice
+533 x32 move_pages compat_sys_move_pages
+534 x32 preadv compat_sys_preadv64
+535 x32 pwritev compat_sys_pwritev64
+536 x32 rt_tgsigqueueinfo compat_sys_rt_tgsigqueueinfo
+537 x32 recvmmsg compat_sys_recvmmsg
+538 x32 sendmmsg compat_sys_sendmmsg
+539 x32 process_vm_readv compat_sys_process_vm_readv
+540 x32 process_vm_writev compat_sys_process_vm_writev
On Mon, Feb 27, 2012 at 04:53:56PM +1100, Stephen Rothwell wrote:
> Hi Andrew,
>
> Today's linux-next merge of the akpm tree got a conflict in
> arch/x86/syscalls/syscall_64.tbl between commit
> arch/x86/syscalls/syscall_64.tbl ("x32: Add x32 system calls to
> syscall/syscall_64.tbl") from the tip tree and commit "syscalls, x86: add
> __NR_kcmp syscall" from the akpm tree.
>
> I fixed it up (see below) but did not know if this call should be marked
> "common".
Hi Stephen, letme fetch both trees to figure out what this new column means.
Will ping back shortly. Thanks!
Cyrill
On 02/26/2012 09:53 PM, Stephen Rothwell wrote:
> Hi Andrew,
>
> Today's linux-next merge of the akpm tree got a conflict in
> arch/x86/syscalls/syscall_64.tbl between commit
> arch/x86/syscalls/syscall_64.tbl ("x32: Add x32 system calls to
> syscall/syscall_64.tbl") from the tip tree and commit "syscalls,
> x86: add __NR_kcmp syscall" from the akpm tree.
>
> I fixed it up (see below) but did not know if this call should be
> marked "common".
It should be "common" (otherwise there would need to be an x32 variant
which would point to the compat version of the call, but in this case
even the i386 entry point goes straight to sys_kcmp.)
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
On 02/26/2012 09:57 PM, Cyrill Gorcunov wrote:
> On Mon, Feb 27, 2012 at 04:53:56PM +1100, Stephen Rothwell wrote:
>> Hi Andrew,
>>
>> Today's linux-next merge of the akpm tree got a conflict in
>> arch/x86/syscalls/syscall_64.tbl between commit
>> arch/x86/syscalls/syscall_64.tbl ("x32: Add x32 system calls to
>> syscall/syscall_64.tbl") from the tip tree and commit "syscalls, x86: add
>> __NR_kcmp syscall" from the akpm tree.
>>
>> I fixed it up (see below) but did not know if this call should be marked
>> "common".
>
> Hi Stephen, letme fetch both trees to figure out what this new column means.
> Will ping back shortly. Thanks!
>
> Cyrill
Hi Cyrill,
"common" means the same entry point is used for x86-64 and x32.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
On Sun, Feb 26, 2012 at 10:02:11PM -0800, H. Peter Anvin wrote:
> On 02/26/2012 09:57 PM, Cyrill Gorcunov wrote:
> > On Mon, Feb 27, 2012 at 04:53:56PM +1100, Stephen Rothwell wrote:
> >> Hi Andrew,
> >>
> >> Today's linux-next merge of the akpm tree got a conflict in
> >> arch/x86/syscalls/syscall_64.tbl between commit
> >> arch/x86/syscalls/syscall_64.tbl ("x32: Add x32 system calls to
> >> syscall/syscall_64.tbl") from the tip tree and commit "syscalls, x86: add
> >> __NR_kcmp syscall" from the akpm tree.
> >>
> >> I fixed it up (see below) but did not know if this call should be marked
> >> "common".
> >
> > Hi Stephen, letme fetch both trees to figure out what this new column means.
> > Will ping back shortly. Thanks!
> >
>
> Hi Cyrill,
>
> "common" means the same entry point is used for x86-64 and x32.
>
Ah, I see. Thanks for explanation, Peter! So it should be a "common" then.
Cyrill
Hi Peter,
On Sun, 26 Feb 2012 22:01:21 -0800 "H. Peter Anvin" <[email protected]> wrote:
>
> It should be "common" (otherwise there would need to be an x32 variant
> which would point to the compat version of the call, but in this case
> even the i386 entry point goes straight to sys_kcmp.)
Thanks, I will fix up the merge resolution tomorrow.
--
Cheers,
Stephen Rothwell [email protected]