From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751767AbdCAArI (ORCPT ); Tue, 28 Feb 2017 19:47:08 -0500 Received: from mail-io0-f181.google.com ([209.85.223.181]:35663 "EHLO mail-io0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751529AbdCAAq7 (ORCPT ); Tue, 28 Feb 2017 19:46:59 -0500 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: Kees Cook Date: Tue, 28 Feb 2017 16:16:41 -0800 X-Google-Sender-Auth: UqxCFwGWpbVwsU6yXy-uOIVgMOE Message-ID: Subject: Re: [PATCH 15/19] kernel: convert audit_tree.count from atomic_t to refcount_t To: Paul Moore 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 2:11 PM, Paul Moore wrote: > On Tue, Feb 21, 2017 at 2:15 AM, Reshetova, Elena > wrote: >>> On Mon, Feb 20, 2017 at 5:19 AM, Elena Reshetova >>> wrote: >>> > refcount_t type and corresponding API should be >>> > used instead of atomic_t when the variable is used as >>> > a reference counter. This allows to avoid accidental >>> > refcounter overflows that might lead to use-after-free >>> > situations. >>> > >>> > Signed-off-by: Elena Reshetova >>> > Signed-off-by: Hans Liljestrand >>> > Signed-off-by: Kees Cook >>> > Signed-off-by: David Windsor >>> > --- >>> > kernel/audit_tree.c | 8 ++++---- >>> > 1 file changed, 4 insertions(+), 4 deletions(-) >>> >>> No objection on my end, same for patch 16/19. >>> >>> I have no problem merging both these patches into the audit/next >>> branch after the merge window, is that your goal or are you merging >>> these via a different tree? >> >> Thank you Paul! I think it is better if they go through the trees they supposed to go through >> since this way they would get more testing and etc. So, please take the relevant ones to your tree when the time is right. >> >> After the first round, I guess we will see what patches are not propagating and then maybe take them via Kees tree. > > 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... -Kees -- Kees Cook Pixel Security