From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Moore Subject: Re: [PATCH V4 (was V6)] audit: save signal match info in case entry passed in is the one deleted Date: Tue, 04 Aug 2015 19:04:04 -0400 Message-ID: <2901073.DtnZNkzh6Q@sifl> References: <79ae63edcc644461001cd37b8ff1f9b1458f45f7.1438446636.git.rgb@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Return-path: In-Reply-To: <79ae63edcc644461001cd37b8ff1f9b1458f45f7.1438446636.git.rgb@redhat.com> Sender: linux-kernel-owner@vger.kernel.org To: Richard Guy Briggs Cc: linux-audit@redhat.com, linux-kernel@vger.kernel.org, sgrubb@redhat.com, eparis@redhat.com List-Id: linux-audit@redhat.com On Saturday, August 01, 2015 03:44:01 PM Richard Guy Briggs wrote: > Move the access to the entry for audit_match_signal() to the beginning of > the function in case the entry found is the same one passed in. This will > enable it to be used by audit_remove_mark_rule(). > > Signed-off-by: Richard Guy Briggs > --- > kernel/auditfilter.c | 3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/kernel/auditfilter.c b/kernel/auditfilter.c > index 4cb9b44..afb63b3 100644 > --- a/kernel/auditfilter.c > +++ b/kernel/auditfilter.c > @@ -943,6 +943,7 @@ static inline int audit_del_rule(struct audit_entry > *entry) int ret = 0; > #ifdef CONFIG_AUDITSYSCALL > int dont_count = 0; > + int match_signal = !audit_match_signal(entry); > > /* If either of these, don't count towards total */ > if (entry->rule.listnr == AUDIT_FILTER_USER || > @@ -972,7 +973,7 @@ static inline int audit_del_rule(struct audit_entry > *entry) if (!dont_count) > audit_n_rules--; > > - if (!audit_match_signal(entry)) > + if (match_signal) > audit_signals--; > #endif > mutex_unlock(&audit_filter_mutex); Why not simply move this second CONFIG_AUDITSYSCALL above the list_del() calls? Am I missing something? Also, while we're fixing up audit_del_rule(), why not also move the mutex_unlock() call to after the "out" jump target and then drop the mutex_unlock() call in the audit_find_rule() error case? Not your fault, but the code seems silly as-is. -- paul moore security @ redhat