Re: [PATCH 15/19] kernel: convert audit_tree.count from atomic_t to refcount_t
From: Kees Cook <hidden>
Date: 2017-03-01 00:16:41
Also in:
linux-fsdevel, lkml
On Tue, Feb 28, 2017 at 2:11 PM, Paul Moore [off-list ref] wrote:
On Tue, Feb 21, 2017 at 2:15 AM, Reshetova, Elena [off-list ref] wrote:quoted
quoted
On Mon, Feb 20, 2017 at 5:19 AM, Elena Reshetova [off-list ref] wrote:quoted
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 <redacted> Signed-off-by: Kees Cook <redacted> Signed-off-by: David Windsor <redacted> --- 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