From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Viro Subject: Re: Audit issue Date: Thu, 8 Nov 2007 09:56:51 -0500 Message-ID: <20071108145651.GC28304@devserv.devel.redhat.com> References: <200710301248.24261.sgrubb@redhat.com> <200711080927.14472.sgrubb@redhat.com> <20071108143218.GB28304@devserv.devel.redhat.com> <200711080947.41645.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <200711080947.41645.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 On Thu, Nov 08, 2007 at 09:47:40AM -0500, Steve Grubb wrote: > On Thursday 08 November 2007 09:32:18 Alexander Viro wrote: > > > Thanks for posting this patch. Is it impossible to "repair " processes by > > > simply adding a context if the pointer is NULL? > > > > At which point would you do that? > > Possibly on syscall exit? Shouldn't the kernel have released all locks by that > point? And what about syscall entry...isn't that before any locking starts to > occur? You do not get there unless you have ->audit_context != NULL. And if you remove that check, you are in for more overhead. > True, but I'm thinking this will cause performance to go down if the audit > system was ever enabled. It doesn't look as bad as the audit system actually > being on, but it may be doing unnecessary allocations I think. *shrug* Easy enough to test - boot with audit disabled, run benchmarks, enable it, flush all caches (e.g. by memory pressure), rerun the benchmarks, compare... I don't think it will be serious problem, but if it will we can always look for trickier solutions.