From: Oleg Nesterov <oleg@redhat.com> To: Andy Lutomirski <luto@amacapital.net> Cc: "H. Peter Anvin" <hpa@zytor.com>, linux-arch <linux-arch@vger.kernel.org>, X86 ML <x86@kernel.org>, Frederic Weisbecker <fweisbec@gmail.com>, LSM List <linux-security-module@vger.kernel.org>, Linux MIPS Mailing List <linux-mips@linux-mips.org>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, Alexei Starovoitov <ast@plumgrid.com>, Will Drewry <wad@chromium.org>, Kees Cook <keescook@chromium.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org> Subject: Re: [PATCH v4 0/5] x86: two-phase syscall tracing and seccomp fastpath Date: Wed, 30 Jul 2014 17:32:59 +0200 [thread overview] Message-ID: <20140730153259.GA25478@redhat.com> (raw) In-Reply-To: <CALCETrXHF5YzPQDvnJs=mFNm2Ff_FekGu_Y8-JyMaWh2hctR7A@mail.gmail.com> On 07/29, Andy Lutomirski wrote: > > > SAVE_REST is 6 movq instructions and a subq. FIXUP_TOP_OF_STACK is 7 > > movqs (and 8 if I ever get my way). RESTORE_TOP_OF_STACK is 4. > > RESTORE_REST is 6 movqs and an adsq. So we're talking about avoiding > > 21 movqs, and addq, and a subq. That may be significant. (And I > > suspect that the difference is much larger on platforms like arm64, > > but that's a separate issue.) OK, thanks. We could probably simplify the logic in phase1 + phase2 if it was a single function though. > To put some more options on the table: there's an argument to be made > that the whole fast-path/slow-path split isn't worth it. We could > unconditionally set up a full frame for all syscalls. This means: Or, at least, can't we allocate the full frame and avoid "add/sub %rsp"? > This means: ... > On the > other hand, there's zero chance that this would be ready for 3.17. > > I'd tend to advocate for keeping the approach in my patches for now. Yes, sure, I didn't try to convince you to change this code. Thanks. Oleg.
WARNING: multiple messages have this Message-ID (diff)
From: oleg@redhat.com (Oleg Nesterov) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH v4 0/5] x86: two-phase syscall tracing and seccomp fastpath Date: Wed, 30 Jul 2014 17:32:59 +0200 [thread overview] Message-ID: <20140730153259.GA25478@redhat.com> (raw) In-Reply-To: <CALCETrXHF5YzPQDvnJs=mFNm2Ff_FekGu_Y8-JyMaWh2hctR7A@mail.gmail.com> On 07/29, Andy Lutomirski wrote: > > > SAVE_REST is 6 movq instructions and a subq. FIXUP_TOP_OF_STACK is 7 > > movqs (and 8 if I ever get my way). RESTORE_TOP_OF_STACK is 4. > > RESTORE_REST is 6 movqs and an adsq. So we're talking about avoiding > > 21 movqs, and addq, and a subq. That may be significant. (And I > > suspect that the difference is much larger on platforms like arm64, > > but that's a separate issue.) OK, thanks. We could probably simplify the logic in phase1 + phase2 if it was a single function though. > To put some more options on the table: there's an argument to be made > that the whole fast-path/slow-path split isn't worth it. We could > unconditionally set up a full frame for all syscalls. This means: Or, at least, can't we allocate the full frame and avoid "add/sub %rsp"? > This means: ... > On the > other hand, there's zero chance that this would be ready for 3.17. > > I'd tend to advocate for keeping the approach in my patches for now. Yes, sure, I didn't try to convince you to change this code. Thanks. Oleg.
next prev parent reply other threads:[~2014-07-30 15:35 UTC|newest] Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-07-29 3:38 [PATCH v4 0/5] x86: two-phase syscall tracing and seccomp fastpath Andy Lutomirski 2014-07-29 3:38 ` Andy Lutomirski 2014-07-29 3:38 ` [PATCH v4 1/5] x86,x32,audit: Fix x32's AUDIT_ARCH wrt audit Andy Lutomirski 2014-07-29 3:38 ` Andy Lutomirski 2014-07-29 3:38 ` [PATCH v4 2/5] x86,entry: Only call user_exit if TIF_NOHZ Andy Lutomirski 2014-07-29 3:38 ` Andy Lutomirski 2014-07-29 19:32 ` Oleg Nesterov 2014-07-29 19:32 ` Oleg Nesterov 2014-07-30 16:43 ` Frederic Weisbecker 2014-07-30 16:43 ` Frederic Weisbecker 2014-07-30 17:23 ` Andy Lutomirski 2014-07-30 17:23 ` Andy Lutomirski 2014-07-30 17:23 ` Andy Lutomirski 2014-07-31 15:16 ` Frederic Weisbecker 2014-07-31 15:16 ` Frederic Weisbecker 2014-07-31 15:16 ` Frederic Weisbecker 2014-07-31 16:42 ` Oleg Nesterov 2014-07-31 16:42 ` Oleg Nesterov 2014-07-31 16:42 ` Oleg Nesterov 2014-07-31 16:49 ` Frederic Weisbecker 2014-07-31 16:49 ` Frederic Weisbecker 2014-07-31 16:49 ` Frederic Weisbecker 2014-07-31 16:54 ` Oleg Nesterov 2014-07-31 16:54 ` Oleg Nesterov 2014-07-31 16:54 ` Oleg Nesterov 2014-07-31 16:58 ` Oleg Nesterov 2014-07-31 16:58 ` Oleg Nesterov 2014-07-31 16:58 ` Oleg Nesterov 2014-07-31 17:17 ` Frederic Weisbecker 2014-07-31 17:17 ` Frederic Weisbecker 2014-07-31 17:17 ` Frederic Weisbecker 2014-07-29 3:38 ` [PATCH v4 3/5] x86: Split syscall_trace_enter into two phases Andy Lutomirski 2014-07-29 3:38 ` Andy Lutomirski 2014-07-29 19:25 ` Oleg Nesterov 2014-07-29 19:25 ` Oleg Nesterov 2014-07-29 3:38 ` [PATCH v4 4/5] x86_64,entry: Treat regs->ax the same in fastpath and slowpath syscalls Andy Lutomirski 2014-07-29 3:38 ` [PATCH v4 4/5] x86_64, entry: " Andy Lutomirski 2014-07-29 3:38 ` [PATCH v4 5/5] x86_64,entry: Use split-phase syscall_trace_enter for 64-bit syscalls Andy Lutomirski 2014-07-29 3:38 ` [PATCH v4 5/5] x86_64, entry: " Andy Lutomirski 2014-07-29 19:20 ` [PATCH v4 0/5] x86: two-phase syscall tracing and seccomp fastpath Oleg Nesterov 2014-07-29 19:20 ` Oleg Nesterov 2014-07-29 20:54 ` Andy Lutomirski 2014-07-29 20:54 ` Andy Lutomirski 2014-07-29 20:54 ` Andy Lutomirski 2014-07-29 23:30 ` Andy Lutomirski 2014-07-29 23:30 ` Andy Lutomirski 2014-07-29 23:30 ` Andy Lutomirski 2014-07-30 15:32 ` Oleg Nesterov [this message] 2014-07-30 15:32 ` Oleg Nesterov 2014-07-30 15:32 ` Oleg Nesterov 2014-07-30 16:59 ` Frederic Weisbecker 2014-07-30 16:59 ` Frederic Weisbecker 2014-07-30 16:59 ` Frederic Weisbecker 2014-07-30 17:25 ` Andy Lutomirski 2014-07-30 17:25 ` Andy Lutomirski 2014-07-30 17:25 ` Andy Lutomirski 2014-07-31 16:56 ` H. Peter Anvin 2014-07-31 16:56 ` H. Peter Anvin 2014-07-31 16:56 ` H. Peter Anvin 2014-07-31 17:20 ` Frederic Weisbecker 2014-07-31 17:20 ` Frederic Weisbecker 2014-07-31 17:20 ` Frederic Weisbecker
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=20140730153259.GA25478@redhat.com \ --to=oleg@redhat.com \ --cc=ast@plumgrid.com \ --cc=fweisbec@gmail.com \ --cc=hpa@zytor.com \ --cc=keescook@chromium.org \ --cc=linux-arch@vger.kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mips@linux-mips.org \ --cc=linux-security-module@vger.kernel.org \ --cc=luto@amacapital.net \ --cc=wad@chromium.org \ --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: linkBe 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.