From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mitchell Blank Jr Subject: Re: [PATCH] [AUDIT] auditfilter.c cleanup/const-ification Date: Mon, 3 Apr 2006 16:46:24 -0700 Message-ID: <20060403234624.GH3157@gaz.sfgoth.com> References: <20060403125128.GG3157@gaz.sfgoth.com> <200604031656.05141.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <200604031656.05141.sgrubb@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Steve Grubb Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com Steve Grubb wrote: > These are good cleanups. In a way, I wished this was 2 patches instead of 1. Yeah, sorry. I got a little carried away I guess. I can split them if that helps. > The other one I'd probably want to > put in the test kernel for a week or two just to make sure nothing relied on > the state. It's pretty clear from inspection. Look: | static int audit_filter_user_rules(struct netlink_skb_parms *cb, | struct audit_krule *rule, | enum audit_state *state) OK, so it's a static function... and it has only one caller, where: | enum audit_state state; [...] | if (audit_filter_user_rules(cb, &e->rule, &state)) { | if (state == AUDIT_DISABLED) | ret = 0; That's all the code that looks at "state". It's never stored anywhere; it's just lost after that test. The only other possibility where it could be used is if audit_filter_user_rules() were relying on it to be stable each time its run but that's clearly not the case because audit_filter_user_rules() only writes to "*state"; it never reads from it. So I'm pretty confident that this is a safe cleanup. -Mitch