From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: file watch question Date: Fri, 16 Aug 2013 18:08:16 -0400 Message-ID: <1490880.Q3Wb8I5eeY@x2> References: <520E894A.6010403@magitekltd.com> <520E9A69.9030208@magitekltd.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <520E9A69.9030208@magitekltd.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: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Friday, August 16, 2013 04:32:25 PM LC Bruzenak wrote: > On 08/16/2013 03:19 PM, LC Bruzenak wrote: > > The line saying, "Unlike most syscall auditing rules, watches do not > > impact performance based on the number of rules sent to the kernel" - > > does this mean that BOTH the "-w" and "syscall" rules have no > > performance impact? > > Nevermind; I see that the rule in force (with auditctl -l) is the same > regardless of the way it is specified in the auditctl line. The -w form is for backward compatibility with the original patch. It also turns out to be more concise to type. But auditctl translates it to a syscall rule with the -F path or -F dir depending on what it detects the object to be at rule loading time. The Syscall form does allow more fine grained control. The reason it doesn't have performance impact like normal syscall rules is because it gets moved to a list that is not evaluated every syscall. A normal syscall rule will get evaluated for every syscall because it has to see if the syscall number is of interest and then it checks the next rule. All of my attempts to measure performance impact of watches showed that its in the cache noise. Last time I measured was about 7 years ago but I don't think anything has changed that would affect the old results. http://people.redhat.com/sgrubb/files/watch-perf.tar.gz -Steve