From: "Dmitry V. Levin" <ldv@altlinux.org>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
x86@kernel.org, Andy Lutomirski <luto@kernel.org>,
Eugene Syromyatnikov <evgsyr@gmail.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] x86/asm/64: do not clear high 32 bits of syscall number when CONFIG_X86_X32=y
Date: Thu, 14 Sep 2017 23:21:14 +0300 [thread overview]
Message-ID: <20170914202114.GA16764@altlinux.org> (raw)
In-Reply-To: <20170913164921.GA14063@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1295 bytes --]
On Wed, Sep 13, 2017 at 06:49:21PM +0200, Oleg Nesterov wrote:
> On 09/13, Dmitry V. Levin wrote:
> >
> > Before this change, CONFIG_X86_X32=y fastpath behaviour was different
> > from slowpath:
>
> and even with this change they differ if CONFIG_X86_X32=n?
No, I don't think so.
> do_syscall_64() does "nr & __SYSCALL_MASK" unconditionally,
yes
> this clears the upper bits, no?
Why? As "nr" is of type "unsigned long" and __SYSCALL_MASK is either
(~(__X32_SYSCALL_BIT)) or (~0), that is, an integer with the sign bit set,
in "nr & __SYSCALL_MASK" expression __SYSCALL_MASK is sign-extended
to unsigned long. When __SYSCALL_MASK is defined to (~0),
"nr & __SYSCALL_MASK" is optimized to "nr" at compilation time:
$ echo 'unsigned long foo(unsigned long nr) { return nr & (~0); }' |
gcc -Wall -O2 -xc -S -o - - |
sed -n '/cfi_/,/cfi_/p'
.cfi_startproc
movq %rdi, %rax
ret
.cfi_endproc
> And why __SYSCALL_MASK is not "unsigned long" ? IOW, why do we want to silently
> ignore the upper bits in $rax ?
__SYSCALL_MASK is "int" but it is being sign-extended to unsigned long in all
(two) places of arch/x86/entry/common.c where it is used.
> Or I am totally confused?
The thing looks like it was designed to confuse people.
--
ldv
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
next prev parent reply other threads:[~2017-09-14 20:21 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-12 22:57 [PATCH] x86/asm/64: do not clear high 32 bits of syscall number when CONFIG_X86_X32=y Dmitry V. Levin
2017-09-13 16:49 ` Oleg Nesterov
2017-09-14 19:40 ` Eugene Syromyatnikov
2017-09-14 20:24 ` Dmitry V. Levin
2017-09-14 20:21 ` Dmitry V. Levin [this message]
2017-09-15 16:12 ` Oleg Nesterov
2017-09-14 21:05 ` Andy Lutomirski
2017-09-14 21:33 ` Dmitry V. Levin
2017-09-14 21:38 ` Andy Lutomirski
2017-09-15 5:31 ` Ingo Molnar
2017-09-15 5:46 ` hpa
2017-09-17 16:45 ` Dmitry V. Levin
2017-09-15 5:47 ` hpa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170914202114.GA16764@altlinux.org \
--to=ldv@altlinux.org \
--cc=evgsyr@gmail.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=oleg@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.