Re: [PATCH] audit: add backlog high water mark metric

[Steve Grubb]

On Wednesday, April 15, 2026 11:21:52 AM Eastern Daylight Time Paul Moore 
wrote:
> On Wed, Apr 15, 2026 at 11:19 AM Paul Moore <paul@xxxxxxxxxxxxxx> wrote:
> > On Tue, Apr 14, 2026 at 11:45 PM Steve Grubb <sgrubb@xxxxxxxxxx> wrote:
> > > On Friday, April 10, 2026 5:34:08 PM Eastern Daylight Time Paul Moore 
wrote:
> > > > On Mon, Mar 23, 2026 at 11:07 AM Ricardo Robaina
> > > > <rrobaina@xxxxxxxxxx>
> > > 
> > > wrote:
> > ...
> > 
> > > ... compliance-driven systems that must use a finite backlog limit for
> > > memory safety but cannot tolerate dropped events ...> 
> > You must pick one of those two requirements, or at the very least
> > prioritize them; it is simply impossible to both limit the backlog
> > queue and require zero dropped events.
> 
> To be perfectly honest, it's also impossible to require zero dropped
> events.  Even in the most extreme configurations where the admin
> decides to panic the system, that only happens once the system reaches
> the point where it is dropping events.  We try *really* hard to not
> drop events, but it is always going to be a possibility.

You're helping make the point.  Those administrators have decided reliable 
auditing is more important than system availability. backlog_max_depth gives 
them the one thing they currently lack: advance warning. If the high-water 
mark is consistently approaching the backlog limit, they have actionable 
information to raise the limit, reduce audit rule coverage, or address the 
underlying load - before the system goes down. These are exactly the users 
who would benefit the most from this metric.

-Steve