[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-fsdevel
Subject:    Re: [PATCH 15/19] kernel: convert audit_tree.count from atomic_t to refcount_t
From:       Paul Moore <paul () paul-moore ! com>
Date:       2017-02-28 22:11:05
Message-ID: CAHC9VhQBB9srK85meAi41pxD0Vse3NiX1-zmKGXcoYh0vB_=9A () mail ! gmail ! com
[Download RAW message or body]

On Tue, Feb 21, 2017 at 2:15 AM, Reshetova, Elena
<elena.reshetova@intel.com> wrote:
> > On Mon, Feb 20, 2017 at 5:19 AM, Elena Reshetova
> > <elena.reshetova@intel.com> 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 <elena.reshetova@intel.com>
> > > Signed-off-by: Hans Liljestrand <ishkamiel@gmail.com>
> > > Signed-off-by: Kees Cook <keescook@chromium.org>
> > > Signed-off-by: David Windsor <dwindsor@gmail.com>
> > > ---
> > > 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.

-- 
paul moore
www.paul-moore.com


[prev in list] [next in list] [prev in thread] [next in thread]