Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933408Ab1D1SyT (ORCPT ); Thu, 28 Apr 2011 14:54:19 -0400 Received: from hrndva-omtalb.mail.rr.com ([71.74.56.124]:47022 "EHLO hrndva-omtalb.mail.rr.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755836Ab1D1SyR (ORCPT ); Thu, 28 Apr 2011 14:54:17 -0400 X-Authority-Analysis: v=1.1 cv=ZtuXOl23UuD1yoJUTgnZ6i6Z5VPlPhPMWCeUNtN8OGA= c=1 sm=0 a=wom5GMh1gUkA:10 a=0i_OOtiXEx8A:10 a=Rj1_iGo3bfgA:10 a=kj9zAlcOel0A:10 a=eAWTIsOZi86Vnn5xZOjC/w==:17 a=cm27Pg_UAAAA:8 a=aXYQbwh8cayaqPI4AyYA:9 a=CjuIK1q_8ugA:10 a=zv9_9hqRWm8A:10 a=eAWTIsOZi86Vnn5xZOjC/w==:117 X-Cloudmark-Score: 0 X-Originating-IP: 70.123.154.172 Date: Thu, 28 Apr 2011 13:54:16 -0500 From: "Serge E. Hallyn" To: Will Drewry Cc: Steven Rostedt , linux-kernel@vger.kernel.org, kees.cook@canonical.com, eparis@redhat.com, agl@chromium.org, mingo@elte.hu, jmorris@namei.org, Frederic Weisbecker , Ingo Molnar , Andrew Morton , Tejun Heo , Michal Marek , Oleg Nesterov , Roland McGrath , Peter Zijlstra , Jiri Slaby , David Howells Subject: Re: [PATCH 3/7] seccomp_filter: Enable ftrace-based system call filtering Message-ID: <20110428185416.GB13071@hallyn.com> References: <1303960136-14298-1-git-send-email-wad@chromium.org> <1303960136-14298-2-git-send-email-wad@chromium.org> <20110428165525.GB1927@hallyn.com> <1304010981.18763.192.camel@gandalf.stny.rr.com> <20110428173957.GA25940@hallyn.com> <1304014874.18763.201.camel@gandalf.stny.rr.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Content-Length: 1502 Lines: 32 Quoting Will Drewry (wad@chromium.org): > My intent was to make them available for use by seccomp.c during state > teardown/dup. I don't think there's benefit to exposing them outside > of that. Would dropping the export, and adding an local seccomp.h > with the shared functions in them resolve that more cleanly? And add a clear comment explaining :) > > Your code would have been correct if you could call kzalloc under > > rcu_read_lock() (which you can on some kernel configurations but not > > all). The issue is that you need to pull out that allocation from the > > rcu_read_lock() because rcu_read_lock assumes you can't preempt, and > > that allocation can schedule out. The access to the filters must be done > > under rcu_read_lock(), other than that, you're fine. > > That makes sense. I think I'd prefer to not share those functions > rather than guard the list just in case a future consumer of the > interface comes along. Would that make sense to you? Since I don't > see any other users right now other than seccomp.c, it might make > sense to tackle the impact when an actual need arises. > > I'll go whichever way pointed on this, though. Complicating the locking for nonexistent users doesn't seem like the right way. -serge -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/