|
Message-ID: <CAB=4xhq1CPz74LchQ32oyhR1vUKjhMiTXENYbgeh=BoaYNP9JQ@mail.gmail.com> Date: Wed, 29 Feb 2012 09:41:13 -0800 From: Roland McGrath <mcgrathr@...gle.com> To: Oleg Nesterov <oleg@...hat.com> Cc: Will Drewry <wad@...omium.org>, linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org, linux-doc@...r.kernel.org, kernel-hardening@...ts.openwall.com, netdev@...r.kernel.org, x86@...nel.org, arnd@...db.de, davem@...emloft.net, hpa@...or.com, mingo@...hat.com, peterz@...radead.org, rdunlap@...otime.net, tglx@...utronix.de, luto@....edu, eparis@...hat.com, serge.hallyn@...onical.com, djm@...drot.org, scarybeasts@...il.com, indan@....nu, pmoore@...hat.com, akpm@...ux-foundation.org, corbet@....net, eric.dumazet@...il.com, markus@...omium.org, coreyb@...ux.vnet.ibm.com, keescook@...omium.org, Denys Vlasenko <dvlasenk@...hat.com> Subject: Re: [PATCH v11 10/12] ptrace,seccomp: Add PTRACE_SECCOMP support I don't think TIF_NOTIFY_RESUME is apropos here. That only triggers on returning to user mode, i.e. after syscall exit. But regardless of the exact implementation details, I don't think it will be prohibitive to add some means by which the fast-path can back off before actual syscall entry and go to the slow path for ptrace reporting. Since there is no strong reason to think it can't be reorganized that way later, I don't see any good rationale for constraining the seccomp-filter feature definition based on a plan to optimize the implementation in the future. Thanks, Roland
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.