From mboxrd@z Thu Jan 1 00:00:00 1970 From: Oleg Nesterov Subject: Re: [PATCH v9 09/11] seccomp: introduce writer locking Date: Wed, 9 Jul 2014 20:42:15 +0200 Message-ID: <20140709184215.GA4866@redhat.com> References: <1403911380-27787-1-git-send-email-keescook@chromium.org> <1403911380-27787-10-git-send-email-keescook@chromium.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <1403911380-27787-10-git-send-email-keescook@chromium.org> Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-subscribe: List-owner: List-post: List-archive: To: Kees Cook Cc: linux-kernel@vger.kernel.org, Andy Lutomirski , "Michael Kerrisk (man-pages)" , Alexei Starovoitov , Andrew Morton , Daniel Borkmann , Will Drewry , Julien Tinnes , David Drysdale , linux-api@vger.kernel.org, x86@kernel.org, linux-arm-kernel@lists.infradead.org, linux-mips@linux-mips.org, linux-arch@vger.kernel.org, linux-security-module@vger.kernel.org List-Id: linux-arch.vger.kernel.org On 06/27, Kees Cook wrote: > > static u32 seccomp_run_filters(int syscall) > { > - struct seccomp_filter *f; > + struct seccomp_filter *f = ACCESS_ONCE(current->seccomp.filter); I am not sure... This is fine if this ->filter is the 1st (and only) one, in this case we can rely on rmb() in the caller. But the new filter can be installed at any moment. Say, right after that rmb() although this doesn't matter. Either we need smp_read_barrier_depends() after that, or smp_load_acquire() like the previous version did? Oleg. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com ([209.132.183.28]:3173 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756601AbaGISoK (ORCPT ); Wed, 9 Jul 2014 14:44:10 -0400 Date: Wed, 9 Jul 2014 20:42:15 +0200 From: Oleg Nesterov Subject: Re: [PATCH v9 09/11] seccomp: introduce writer locking Message-ID: <20140709184215.GA4866@redhat.com> References: <1403911380-27787-1-git-send-email-keescook@chromium.org> <1403911380-27787-10-git-send-email-keescook@chromium.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1403911380-27787-10-git-send-email-keescook@chromium.org> Sender: linux-arch-owner@vger.kernel.org List-ID: To: Kees Cook Cc: linux-kernel@vger.kernel.org, Andy Lutomirski , "Michael Kerrisk (man-pages)" , Alexei Starovoitov , Andrew Morton , Daniel Borkmann , Will Drewry , Julien Tinnes , David Drysdale , linux-api@vger.kernel.org, x86@kernel.org, linux-arm-kernel@lists.infradead.org, linux-mips@linux-mips.org, linux-arch@vger.kernel.org, linux-security-module@vger.kernel.org Message-ID: <20140709184215.Sxuma628wav-zdWN28ejTrZfRICu4SKxomQrR_OiVOE@z> On 06/27, Kees Cook wrote: > > static u32 seccomp_run_filters(int syscall) > { > - struct seccomp_filter *f; > + struct seccomp_filter *f = ACCESS_ONCE(current->seccomp.filter); I am not sure... This is fine if this ->filter is the 1st (and only) one, in this case we can rely on rmb() in the caller. But the new filter can be installed at any moment. Say, right after that rmb() although this doesn't matter. Either we need smp_read_barrier_depends() after that, or smp_load_acquire() like the previous version did? Oleg.