Re: [BUG][PATCH] audit: audit_log_start running on auditd shouldnot stop

From: Eric Paris
Date: Fri Oct 25 2013 - 11:12:35 EST

On Fri, 2013-10-25 at 10:36 +0900, Toshiyuki Okajima wrote:

> 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) |

Ugggh, definitely a problem. Adding a similar hack to systemd really
does not seem like an acceptable answer. It seems to me that in


we do not need to hold the audit_cmd_mutex. So a quick and dirty patch
should be to just drop the mutex there (and we need to verify there
aren't issues running the audit_filter_user() without the lock). That
will take care of systemd and anything USING audit. It still means that
you could race with something configuring audit and auditd shutting
down. Seems like a good quick and dirty 'fix' while we work on a better

To take care of that I think maybe we could drop the cmd_mutex every
time we call audit_log_start. That's not necessarily going to be
pretty. Maybe make a new switch at the top of the function which knows
which operations we are going to have to allocate an audit_buffer. Drop
the lock, allocate the buffer, then retake the lock to finish running

Maybe that second option isn't so hard and we can go directly after that
instead of just dealing with userspace audit messages?


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at