From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755042AbcLBADA (ORCPT ); Thu, 1 Dec 2016 19:03:00 -0500 Received: from mail-vk0-f67.google.com ([209.85.213.67]:35087 "EHLO mail-vk0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750789AbcLBAC7 (ORCPT ); Thu, 1 Dec 2016 19:02:59 -0500 MIME-Version: 1.0 X-Originating-IP: [96.230.190.88] In-Reply-To: <20161201014455.GD26507@breakpoint.cc> References: <1479215774-29810-1-git-send-email-fw@strlen.de> <20161201014455.GD26507@breakpoint.cc> From: Paul Moore Date: Thu, 1 Dec 2016 19:02:57 -0500 Message-ID: Subject: Re: [PATCH] audit: remove the audit freelist To: Florian Westphal Cc: linux-kernel@vger.kernel.org, linux-audit@redhat.com, Eric Paris Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Nov 30, 2016 at 8:44 PM, Florian Westphal wrote: > Paul Moore wrote: >> On Tue, Nov 15, 2016 at 8:16 AM, Florian Westphal wrote: >> > allows better debugging as freeing audit buffers now always honors slub >> > debug hooks (e.g. object poisoning) and leak checker can detect the >> > free operation. >> > >> > Removal also results in a small speedup (using >> > single rule 'iptables -A INPUT -i lo -j AUDIT --type drop'): >> > >> > super_netperf 4 -H 127.0.0.1 -l 360 -t UDP_RR -- -R 1 -m 64 >> > Before: >> > 294953 >> > After: >> > 298013 >> > >> > (alloc/free no longer serializes on spinlock, allocator can use percpu >> > pool). >> > >> > Signed-off-by: Florian Westphal >> > --- >> > kernel/audit.c | 53 ++++++++--------------------------------------------- >> > 1 file changed, 8 insertions(+), 45 deletions(-) >> >> Sorry for the delay, I was hoping to have some time to play around >> with this and offer a more meaningful comment ... I've often wondered >> about converting audit_buffer, and audit_context for that matter, over >> to their own kmem_cache; have you considered that? Or was this >> proposed due to simplicity? > > Not sure I understand, you could still convert it on top of this. > (Although audit_buffer is just 24 bytes after this patch so it will > come from 32byte kmalloc slab). I'm not arguing against this patch, partly just musing out loud, partly just seeing if you had experimented with creating a audit_buffer specific kmem_cache (I'm guessing the answer here is "no"). If we do convert to a kmem_cache this patch would be the obvious first step. I'd also want to cobble together some tests we can use to measure performance. Using netperf is good, but I'd also like to exercise the syscall records as it is probably easier to isolate the audit subsystem that way. > I don't think it makes sense to keep this DIY cache on top of slub > cache. I agree, there probably isn't much sense in keeping this around. In case you're interested, I started tracking this on GitHub at the link below: * https://github.com/linux-audit/audit-kernel/issues/29 -- paul moore www.paul-moore.com