[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHC9VhQm9JEFozFMvNuBc_dx+XAqvJCY_Z8Dyf7q_RyDcNu=QA@mail.gmail.com>
Date: Tue, 23 May 2023 22:03:36 -0400
From: Paul Moore <paul@...l-moore.com>
To: Ivan Babrou <ivan@...udflare.com>
Cc: audit@...r.kernel.org, linux-kernel@...r.kernel.org,
kernel-team@...udflare.com, Eric Paris <eparis@...hat.com>
Subject: Re: [PATCH] audit: check syscall bitmap on entry to avoid extra work
On Tue, May 23, 2023 at 5:50 PM Ivan Babrou <ivan@...udflare.com> wrote:
> On Tue, May 23, 2023 at 12:59 PM Paul Moore <paul@...l-moore.com> wrote:
> > Before seriously considering something like this, I would really like
> > to see some time put into profiling the original overhead and some
> > designs on how that could be improved. Without that, patches like
> > this look like drive-by band-aids which have already caused enough
> > headaches for audit maintenance.
>
> Hello Paul,
>
> Could you elaborate on what exactly you would like to see added? It's
> not clear to me what is missing.
I should have been more clear, let me try again ...
>From my perspective, this patch adds code and complexity to deal with
the performance impact of auditing. In some cases that is the right
thing to do, but I would much rather see a more in-depth analysis of
where the audit hot spots are in this benchmark, and some thoughts on
how we might improve that. In other words, don't just add additional
processing to bypass (slower, more involved) processing; look at the
processing that is currently being done and see if you can find a way
to make it faster. It will likely take longer, but the results will
be much more useful.
Does that make sense?
--
paul-moore.com
Powered by blists - more mailing lists