From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753347AbdCAWQl (ORCPT ); Wed, 1 Mar 2017 17:16:41 -0500 Received: from mail-ua0-f177.google.com ([209.85.217.177]:36234 "EHLO mail-ua0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752994AbdCAWQe (ORCPT ); Wed, 1 Mar 2017 17:16:34 -0500 MIME-Version: 1.0 X-Originating-IP: [108.49.102.27] In-Reply-To: References: <1487585948-6401-1-git-send-email-elena.reshetova@intel.com> <1487585948-6401-16-git-send-email-elena.reshetova@intel.com> <2236FBA76BA1254E88B949DDB74E612B41C4DE27@IRSMSX102.ger.corp.intel.com> From: Paul Moore Date: Wed, 1 Mar 2017 14:35:15 -0500 Message-ID: Subject: Re: [PATCH 15/19] kernel: convert audit_tree.count from atomic_t to refcount_t To: Kees Cook Cc: "Reshetova, Elena" , "linux-kernel@vger.kernel.org" , "cgroups@vger.kernel.org" , "linux-audit@redhat.com" , "linux-fsdevel@vger.kernel.org" , "peterz@infradead.org" , "gregkh@linuxfoundation.org" , "viro@zeniv.linux.org.uk" , "tj@kernel.org" , "mingo@redhat.com" , "hannes@cmpxchg.org" , "lizefan@huawei.com" , "acme@kernel.org" , "alexander.shishkin@linux.intel.com" , Eric Paris , "akpm@linux-foundation.org" , "arnd@arndb.de" , "luto@kernel.org" , Hans Liljestrand , David Windsor Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 28, 2017 at 7:16 PM, Kees Cook wrote: > On Tue, Feb 28, 2017 at 2:11 PM, Paul Moore wrote: >> I just realized that include/linux/refcount.h didn't make it into >> v4.10 which means there is going to be delay until I merge them into >> the audit tree (I don't base the tree on -rc releases except under >> extreme circumstances). I've got the patches queued up in a private >> holding branch (I added #includes BTW) so I won't forget, but as a >> FYI, they likely won't make it in until v4.12. > > I'm not asking for you to change this, but I am curious: doesn't that > force you to always be a release behind? I've tended to base trees on > -rc2 (and then the final release while the next merge window is open). > But that may be because I tend to have such wide dependencies... In general, yes ... and if you are just looking for the short answer I'd leave it at that. I do leave door open for exceptions under unusual circumstances, but I don't believe the refcount_t conversion is one of those cases. The longer answer lies in a balancing act between what I understand Linus' and/or James desires (different upstream maintainers, different approaches, but for my own sanity I like to stick to a single "process" across my trees), the linux-next effort, branch stability (aka limited or predictable rebases), and my own testing requirements. First off, the current policy I follow for the SELinux and audit trees can be found here: * http://www.paul-moore.com/blog/d/2016/03/kernel-repo-process.html ... it's relatively simple and has proven to work reasonably well over the past year or so. On occasion, the subsystem changes in a given release are significant enough that I skip a rebase (step #2 in the process) but that has only happened once (twice?) with the audit tree and didn't prove to be a real problem; this is less of an issue with the SELinux tree as James often rebases the linux-security tree to the current -rc1 or -rc2 tree. As for the balancing act ... My understanding is that Linus doesn't like to see pull requests from trees based on -rcX tags, he would much prefer to see trees based on a proper release, e.g. v4.10; on the plus side, Linus is willing to put up with some merge fuzzing so long as it is understandable and/or well explained. James wants pull requests that apply with zero merge conflicts to his linux-security/next tree; on the plus side, the linux-security/next tree tends to be based on the current -rc1/2 so a broad set of dependencies isn't too bad (which is important for SELinux). The linux-next people want to see a commit ID follow a steady progression of multiple weeks in the subsystem -next branch and then a trickle up through various trees until it hits Linus' tree. The branch stability requirements are pretty obvious, and with the exception of the -next branches during/immediately-after the merge window, I don't really rebase branches unless there is a Very Good Reason. Finally, my own testing requirements are such that I want to test the current SELinux and audit -next/-stable branches against the latest bits in Linus' tree (e.g. -rcX releases) on a weekly basis so keeping those branches as current as possible is important; I talked a bit more about my testing at Flock 2016, slides/video at the link below: * http://www.paul-moore.com/blog/d/2016/08/flock-kernel-testing.html * https://copr.fedorainfracloud.org/coprs/pcmoore/kernel-secnext There ya go, probably more than you wanted to know, but that's why things are the way they are with the SELinux and audit trees. I remain open to new ideas about how to manage the trees, but the current arrangement seems to work reasonably well at the moment. -- paul moore www.paul-moore.com From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ua0-f178.google.com ([209.85.217.178]:34444 "EHLO mail-ua0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751595AbdCAUhb (ORCPT ); Wed, 1 Mar 2017 15:37:31 -0500 Received: by mail-ua0-f178.google.com with SMTP id f54so53340791uaa.1 for ; Wed, 01 Mar 2017 12:36:54 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <1487585948-6401-1-git-send-email-elena.reshetova@intel.com> <1487585948-6401-16-git-send-email-elena.reshetova@intel.com> <2236FBA76BA1254E88B949DDB74E612B41C4DE27@IRSMSX102.ger.corp.intel.com> From: Paul Moore Date: Wed, 1 Mar 2017 14:35:15 -0500 Message-ID: Subject: Re: [PATCH 15/19] kernel: convert audit_tree.count from atomic_t to refcount_t To: Kees Cook Cc: "Reshetova, Elena" , "linux-kernel@vger.kernel.org" , "cgroups@vger.kernel.org" , "linux-audit@redhat.com" , "linux-fsdevel@vger.kernel.org" , "peterz@infradead.org" , "gregkh@linuxfoundation.org" , "viro@zeniv.linux.org.uk" , "tj@kernel.org" , "mingo@redhat.com" , "hannes@cmpxchg.org" , "lizefan@huawei.com" , "acme@kernel.org" , "alexander.shishkin@linux.intel.com" , Eric Paris , "akpm@linux-foundation.org" , "arnd@arndb.de" , "luto@kernel.org" , Hans Liljestrand , David Windsor Content-Type: text/plain; charset=UTF-8 Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Tue, Feb 28, 2017 at 7:16 PM, Kees Cook wrote: > On Tue, Feb 28, 2017 at 2:11 PM, Paul Moore wrote: >> I just realized that include/linux/refcount.h didn't make it into >> v4.10 which means there is going to be delay until I merge them into >> the audit tree (I don't base the tree on -rc releases except under >> extreme circumstances). I've got the patches queued up in a private >> holding branch (I added #includes BTW) so I won't forget, but as a >> FYI, they likely won't make it in until v4.12. > > I'm not asking for you to change this, but I am curious: doesn't that > force you to always be a release behind? I've tended to base trees on > -rc2 (and then the final release while the next merge window is open). > But that may be because I tend to have such wide dependencies... In general, yes ... and if you are just looking for the short answer I'd leave it at that. I do leave door open for exceptions under unusual circumstances, but I don't believe the refcount_t conversion is one of those cases. The longer answer lies in a balancing act between what I understand Linus' and/or James desires (different upstream maintainers, different approaches, but for my own sanity I like to stick to a single "process" across my trees), the linux-next effort, branch stability (aka limited or predictable rebases), and my own testing requirements. First off, the current policy I follow for the SELinux and audit trees can be found here: * http://www.paul-moore.com/blog/d/2016/03/kernel-repo-process.html ... it's relatively simple and has proven to work reasonably well over the past year or so. On occasion, the subsystem changes in a given release are significant enough that I skip a rebase (step #2 in the process) but that has only happened once (twice?) with the audit tree and didn't prove to be a real problem; this is less of an issue with the SELinux tree as James often rebases the linux-security tree to the current -rc1 or -rc2 tree. As for the balancing act ... My understanding is that Linus doesn't like to see pull requests from trees based on -rcX tags, he would much prefer to see trees based on a proper release, e.g. v4.10; on the plus side, Linus is willing to put up with some merge fuzzing so long as it is understandable and/or well explained. James wants pull requests that apply with zero merge conflicts to his linux-security/next tree; on the plus side, the linux-security/next tree tends to be based on the current -rc1/2 so a broad set of dependencies isn't too bad (which is important for SELinux). The linux-next people want to see a commit ID follow a steady progression of multiple weeks in the subsystem -next branch and then a trickle up through various trees until it hits Linus' tree. The branch stability requirements are pretty obvious, and with the exception of the -next branches during/immediately-after the merge window, I don't really rebase branches unless there is a Very Good Reason. Finally, my own testing requirements are such that I want to test the current SELinux and audit -next/-stable branches against the latest bits in Linus' tree (e.g. -rcX releases) on a weekly basis so keeping those branches as current as possible is important; I talked a bit more about my testing at Flock 2016, slides/video at the link below: * http://www.paul-moore.com/blog/d/2016/08/flock-kernel-testing.html * https://copr.fedorainfracloud.org/coprs/pcmoore/kernel-secnext There ya go, probably more than you wanted to know, but that's why things are the way they are with the SELinux and audit trees. I remain open to new ideas about how to manage the trees, but the current arrangement seems to work reasonably well at the moment. -- paul moore www.paul-moore.com From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Moore Subject: Re: [PATCH 15/19] kernel: convert audit_tree.count from atomic_t to refcount_t Date: Wed, 1 Mar 2017 14:35:15 -0500 Message-ID: References: <1487585948-6401-1-git-send-email-elena.reshetova@intel.com> <1487585948-6401-16-git-send-email-elena.reshetova@intel.com> <2236FBA76BA1254E88B949DDB74E612B41C4DE27@IRSMSX102.ger.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paul-moore-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=v/CZOH9it/u9PpYmRhF1pBUOoJNnskuxBGL7JMtLBfw=; b=SdBvO9Ax5LZ0gB2lLlsDi/n+UkeWWrlHk47DeQ4xtBJGLX4Ly0Pi2i4DmZUYXLOPqP x7cXsoNcBjZPLeD5lLDEhIG72KuVTh8expcjQmfORHao9D52pK8pIkJn7XSAIt8xMJZH CjLifNUW4PedR2uaCX+AJhLugRnB1oRAbLjStibL2zjMUV7Npt57eNQtfqif0aKla7yk SOQ7ZJiTN7eeFCLuWkRulAoc/+PYB237Pj5pd5Fgv6SnuroU4zremo9QXtLbdzgndvoh g9z6A0nkv+hDzOQRVlEaFGJDkArx/1nZl3+RezSgNYXgQlWnRXyBf09D5ZkPhLSepiE4 PK/Q== In-Reply-To: List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Kees Cook Cc: "lizefan@huawei.com" , "arnd@arndb.de" , "peterz@infradead.org" , "gregkh@linuxfoundation.org" , Hans Liljestrand , "linux-kernel@vger.kernel.org" , "acme@kernel.org" , "tj@kernel.org" , "alexander.shishkin@linux.intel.com" , "linux-audit@redhat.com" , "viro@zeniv.linux.org.uk" , "luto@kernel.org" , "hannes@cmpxchg.org" , "linux-fsdevel@vger.kernel.org" , "cgroups@vger.kernel.org" , "akpm@linux-foundation.org" On Tue, Feb 28, 2017 at 7:16 PM, Kees Cook wrote: > On Tue, Feb 28, 2017 at 2:11 PM, Paul Moore wrote: >> I just realized that include/linux/refcount.h didn't make it into >> v4.10 which means there is going to be delay until I merge them into >> the audit tree (I don't base the tree on -rc releases except under >> extreme circumstances). I've got the patches queued up in a private >> holding branch (I added #includes BTW) so I won't forget, but as a >> FYI, they likely won't make it in until v4.12. > > I'm not asking for you to change this, but I am curious: doesn't that > force you to always be a release behind? I've tended to base trees on > -rc2 (and then the final release while the next merge window is open). > But that may be because I tend to have such wide dependencies... In general, yes ... and if you are just looking for the short answer I'd leave it at that. I do leave door open for exceptions under unusual circumstances, but I don't believe the refcount_t conversion is one of those cases. The longer answer lies in a balancing act between what I understand Linus' and/or James desires (different upstream maintainers, different approaches, but for my own sanity I like to stick to a single "process" across my trees), the linux-next effort, branch stability (aka limited or predictable rebases), and my own testing requirements. First off, the current policy I follow for the SELinux and audit trees can be found here: * http://www.paul-moore.com/blog/d/2016/03/kernel-repo-process.html ... it's relatively simple and has proven to work reasonably well over the past year or so. On occasion, the subsystem changes in a given release are significant enough that I skip a rebase (step #2 in the process) but that has only happened once (twice?) with the audit tree and didn't prove to be a real problem; this is less of an issue with the SELinux tree as James often rebases the linux-security tree to the current -rc1 or -rc2 tree. As for the balancing act ... My understanding is that Linus doesn't like to see pull requests from trees based on -rcX tags, he would much prefer to see trees based on a proper release, e.g. v4.10; on the plus side, Linus is willing to put up with some merge fuzzing so long as it is understandable and/or well explained. James wants pull requests that apply with zero merge conflicts to his linux-security/next tree; on the plus side, the linux-security/next tree tends to be based on the current -rc1/2 so a broad set of dependencies isn't too bad (which is important for SELinux). The linux-next people want to see a commit ID follow a steady progression of multiple weeks in the subsystem -next branch and then a trickle up through various trees until it hits Linus' tree. The branch stability requirements are pretty obvious, and with the exception of the -next branches during/immediately-after the merge window, I don't really rebase branches unless there is a Very Good Reason. Finally, my own testing requirements are such that I want to test the current SELinux and audit -next/-stable branches against the latest bits in Linus' tree (e.g. -rcX releases) on a weekly basis so keeping those branches as current as possible is important; I talked a bit more about my testing at Flock 2016, slides/video at the link below: * http://www.paul-moore.com/blog/d/2016/08/flock-kernel-testing.html * https://copr.fedorainfracloud.org/coprs/pcmoore/kernel-secnext There ya go, probably more than you wanted to know, but that's why things are the way they are with the SELinux and audit trees. I remain open to new ideas about how to manage the trees, but the current arrangement seems to work reasonably well at the moment. -- paul moore www.paul-moore.com