RFE: add kernel audit queue statistics

[stevegrubb]

People have varying workloads as well as audit rules. Right now the consensus is to set the backlog to 8192. This eats up memory on some smaller systems. It should be simple to add an unsigned int to hold the value of the maximum depth used in the backlog. It would be displayed as part of the audit status control response. With this, people could make an educated guess about how deep to make the backlog. We may even be able to cut the recommendation down with some hard evidence.

[pcmoore]

It is important to keep in mind that the backlog setting doesn't reserve any memory, it simply allows the backlog to grow up to a specified limit. If the backlog queue is eating up memory on smaller systems then the real problem isn't the backlog setting, it is either an overly verbose set of audit rules, problems reading the backlog quickly (auditd), or both.

I'm strongly tempted to close this as I don't see this as a problem, but I'll leave it open so @stevegrubb can respond and perhaps provide more information on the reason for this request.

[stevegrubb]

Yeah, looks like the skb_queue_tail changed how it used to work. It would still be useful to gather metrics.

[pcmoore]

Okay, queue stats are something else entirely, and I fear that a single maximum backlog depth value by itself isn't going to be terribly interesting. I'm going to adjust this RFE to be about better audit queue statistics and we can sort out what that means (e.g. avg queue depth, max queue depth, last 24h, etc.).

[pcmoore]

Related list discussion from spring/summer 2020:

• https://lore.kernel.org/linux-audit/20200616045855.GA1699@linux-kernel-dev

[rgbriggs]

See Max Englander's 2020-07-04 v5.9-rc1 b43870c ("audit: report audit wait metric in audit status reply").

In audit_log_start() in the ratelimited case, add audit_backlog_wait_time_actual to the stats printed to klog.