There is a race condition between systemd and auditd: systemd |auditd -------------------------------------------+----------------------------------- ... | -> audit_receive |... -> mutex_lock(&audit_cmd_mutex) |-> audit_receive ... -> audit_log_start | -> mutex_lock(&audit_cmd_mutex) -> wait_for_auditd | // wait for systemd -> schedule_timeout(60*HZ) |
This fix will take care of systemd and anything USING audit. It still means that we could race with something configuring audit and auditd shutting down. The idea of dropping the lock at the top of audit_receive_msg() isn't as clean as I had hoped, with AUDIT_ADD_RULE, AUDIT_TRIM, AUDIT_MAKE_EQUIV all potentially allocating additional audit buffers indirectly through trim_marked(). It may make sense to have trim_marked() send its queue through a new thread. Richard Guy Briggs (3): selinux: call WARN_ONCE() instead of calling audit_log_start() smack: call WARN_ONCE() instead of calling audit_log_start() audit: drop audit_cmd_lock in AUDIT_USER family of cases kernel/audit.c | 2 ++ security/selinux/ss/services.c | 12 ++++-------- security/smack/smack_lsm.c | 5 ++--- 3 files changed, 8 insertions(+), 11 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/