Page MenuHomeFreeBSD

audit: convert audit event class lookup to lockless
ClosedPublic

Authored by gallatin on Oct 17 2025, 6:36 PM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Nov 21, 7:20 AM
Unknown Object (File)
Mon, Nov 3, 3:37 AM
Unknown Object (File)
Fri, Oct 31, 3:50 PM
Unknown Object (File)
Thu, Oct 30, 4:40 PM
Unknown Object (File)
Oct 21 2025, 2:07 PM
Unknown Object (File)
Oct 21 2025, 2:07 PM
Unknown Object (File)
Oct 21 2025, 2:14 AM
Unknown Object (File)
Oct 20 2025, 8:35 PM
Subscribers

Details

Summary

When system call auditing is configured, we see measurable performance loss on high core count servers due to atomic operations in the uncontended rw read lock of evclass_lock. This rw lock protects the evclass hash table. A contrived example of 64 threads continuously reading a byte from per-thread files shows 99% of the time spent in this stack: amd64_syscall -> audit_syscall_enter -> au_event_class -> __rw_rlock_int

Given that the evclass hash table can never have items removed, only added, using a mutex to serialize additions and converting to ck_list allows sufficient protection for lockless lookups. In the contrived example, this change increases performance from 5M reads/sec to 70M reads/sec on an AMD 7502P. In the real world, it gets us back about 1.5% CPU on busy servers.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

Do you have stats how many classes can be realistically present? maybe this would be way faster single-threaded by iterating an array?

In D53176#1214928, @mjg wrote:

Do you have stats how many classes can be realistically present? maybe this would be way faster single-threaded by iterating an array?

I have no idea.. I'm just trying to make the bare min. change to avoid breaking anything and get this atomic off of our hotlist..
If I was going to make an array, I'd make an array au_class_t ev_to_class[65536]; since au_event_t is 16 bits, and it seems to be looking
up a 32b class given a 16b event.

But I really don't want to touch this code in any meaningful way. I just want it to stop hurting us.

This revision is now accepted and ready to land.Oct 20 2025, 6:59 PM
markj added inline comments.
sys/security/audit/audit_bsm_db.c
206

I believe this table can get the same treatment. It doesn't look like it's accessed in a critical path though.

sys/security/audit/audit_bsm_db.c
206

Yes. But since its not in the critical path, I think I'll just leave it alone.