Re: Does audit work on stable/12? Audit-related panic on latest stable/12
Date: Tue, 19 Oct 2021 04:36:22 UTC
On Mon, Oct 18, 2021 at 7:02 PM Lev Serebryakov <lev@freebsd.org> wrote: > > > I've upgraded one of my servers from 11.4 to latest stable/12. This server is unique in me fleet because it has audit (and auditd) enabled. > > First of all, right after (source-based, buildworld & Ko) upgrade dmesg becomes flooded with: > > BSM conversion requested for unknown event 43224 > BSM conversion requested for unknown event 43225 > BSM conversion requested for unknown event 43234 > BSM conversion requested for unknown event 43238 > > And after several minutes of work I've got panic: > > Sleeping thread (tid 101199, pid 51147) owns a non-sleepable lock > BSM conversion requested for unknown event 43224 > KDB: stack backtrace of thread 101199: > #0 0xffffffff804d0f34 at mi_switch+0xd4 > BSM conversion requested for unknown event 43224 > BSM conversion requested for unknown event 43224 > #1 0xffffffff8051ca2c at sleepq_wait+0x2c > #2 0xffffffff80467d62 at _cv_wait+0xf2 > #3 0xffffffff80719573 at audit_commit+0x243 > #4 0xffffffff80719866 at audit_syscall_exit+0x26 > #5 0xffffffff804d7f8a at kern_thr_exit+0x14a > #6 0xffffffff804d7e37 at sys_thr_exit+0x67 > #7 0xffffffff807a1557 at amd64_syscall+0x387 > #8 0xffffffff8077a7ae at fast_syscall_common+0xf8 > panic: sleeping thread > cpuid = 6 > time = 1634604615 > KDB: stack backtrace: > #0 0xffffffff8050e925 at kdb_backtrace+0x65 > #1 0xffffffff804c5bcb at vpanic+0x17b > #2 0xffffffff804c5a43 at panic+0x43 > #3 0xffffffff80523702 at propagate_priority+0x282 > #4 0xffffffff805242cc at turnstile_wait+0x30c > #5 0xffffffff804abd29 at __mtx_lock_sleep+0x199 > #6 0xffffffff804d7ec2 at kern_thr_exit+0x82 > #7 0xffffffff804d7e37 at sys_thr_exit+0x67 > #8 0xffffffff807a1557 at amd64_syscall+0x387 > #9 0xffffffff8077a7ae at fast_syscall_common+0xf8 > > > Now, I've turned off auditd and server looks Ok (at least, it is stable for 30 minutes). But I need audit on this server. Is it known problem? Is it configuration problem? > > > -- > // Lev Serebryakov audit has at least some coverage in CI, but apparently not enough. Would you share your /etc/security configuration? Event 43224 is thr_new, which certainly should be known everywhere, so I'm wondering if you have a bad build somehow. Are you using GENERIC or do you have a custom kernel config?