On 15/01/29, Paul Moore wrote:
On Tuesday, January 27, 2015 07:34:02 PM Richard Guy Briggs wrote:
> During a queue overflow condition while we are waiting for auditd to drain
> the queue to make room for regular messages, we don't want a successful
> auditd that has bypassed the queue check to reset the backlog wait time.
>
> Signed-off-by: Richard Guy Briggs <rgb(a)redhat.com>
> ---
> kernel/audit.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
I'm still wondering why we ever change audit_backlog_wait_time, it is only so
we don't end up calling wait_for_auditd() multiple times while we are waiting
for the queue to drain?
Not exactly. Up to the timeout, all subsequent callers will wait for
auditd as well. It is so that if wait_for_auditd() does time out, we
don't make new callers after that timeout wait, but return an error
immediately. If/when auditd does manage to succeed and recover after
that wait time, it will reset the wait time and resume normal operation.
As a general comment, not directed at anyone in particular, the audit
backlog/queue handling looks a little odd ...
Indeed...
> diff --git a/kernel/audit.c b/kernel/audit.c
> index b333f03..73293ea 100644
> --- a/kernel/audit.c
> +++ b/kernel/audit.c
> @@ -1395,7 +1395,8 @@ struct audit_buffer *audit_log_start(struct
> audit_context *ctx, gfp_t gfp_mask, return NULL;
> }
>
> - audit_backlog_wait_time = audit_backlog_wait_time_master;
> + if (!reserve)
> + audit_backlog_wait_time = audit_backlog_wait_time_master;
>
> ab = audit_buffer_alloc(ctx, gfp_mask, type);
> if (!ab) {
--
paul moore
- RGB
--
Richard Guy Briggs <rbriggs(a)redhat.com>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545