Re: [PATCH 15/19] kernel: convert audit_tree.count from atomic_t to refcount_t

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