From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758236Ab1GDQLJ (ORCPT ); Mon, 4 Jul 2011 12:11:09 -0400 Received: from out5.smtp.messagingengine.com ([66.111.4.29]:38402 "EHLO out5.smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755976Ab1GDQLH (ORCPT ); Mon, 4 Jul 2011 12:11:07 -0400 X-Sasl-enc: cMKijyWln+868KB1MousSQXYSoixegUTePttXgv4DIlt 1309795865 Date: Mon, 4 Jul 2011 09:09:41 -0700 From: Greg KH To: Kees Cook Cc: Steven Rostedt , linux-security-module@vger.kernel.org, ksummit-2011-discuss@lists.linux-foundation.org, Will Drewry , linux-doc@vger.kernel.org, fweisbec@gmail.com, Chris Evans , djm@mindrot.org, James Morris , Eric Paris , linux-kernel@vger.kernel.org, Randy Dunlap , tglx@linutronix.de, Ingo Molnar , Linus Torvalds , segoon@openwall.com Subject: Re: [Ksummit-2011-discuss] [PATCH v9 05/13] seccomp_filter: Document what seccomp_filter is and how it works. Message-ID: <20110704160941.GA18303@kroah.com> References: <20110701115600.GK20990@elte.hu> <20110701130705.GG12605@elte.hu> <20110701161027.GA29035@elte.hu> <1309543448.26417.156.camel@gandalf.stny.rr.com> <20110701202538.GN32221@outflux.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110701202538.GN32221@outflux.net> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jul 01, 2011 at 01:25:38PM -0700, Kees Cook wrote: > On Fri, Jul 01, 2011 at 02:04:08PM -0400, Steven Rostedt wrote: > > On Fri, 2011-07-01 at 11:43 -0500, Will Drewry wrote: > > > On Fri, Jul 1, 2011 at 11:10 AM, Ingo Molnar wrote: > > > > > I'd like to be able to move along security for the platform today and > > > not in two years, but if my only chance of any form of this being > > > ACK'd is to write it such that it shares code with perf and has a > > > shiny new ABI, then I'll queue up the work for when I can start trying > > > to tackle it. > > > > As this seems to be dragging on, and does not look to be solved by > > October, I would like to propose this topic for the Kernel Summit in > > Prague. I believe all parties involved may be there, and if not, I will > > push hard to get them there. > > > > Email is not always the best median for discussions. Face to face can > > usually solve things much quicker. > > How about we put it in as-is and mark it experimental, and then folks > can discuss improvements to it in Oct after all the API users have had > a chance to play with it? Four months seems like a needless delay to me. > I respect the objections, but it doesn't seem to balance against the > demonstrated need for this feature when faced with a viable working patch > series. We can't add something and then remove it if userspace programs are depending on it, sorry.