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

On Tue, Feb 28, 2017 at 5:11 PM, Paul Moore <paul(a)paul-moore.com&gt; wrote: > 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. Quick update on this: I needed to rebase the audit/next branch for other reasons so I've gone ahead and merged 15/19 and 16/19 into audit/next; they should go to Linus during the next merge window. Thanks for your patience.

-- paul moore www.paul-moore.com