Re: [PATCH 2/2] audit: don't reset working wait time accidentally with auditd

[Paul Moore <pmoore@redhat.com>]

On Friday, January 30, 2015 04:10:44 PM Richard Guy Briggs wrote:
> 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@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.

Okay, thanks for the clarification on both patches.  If I have one nit, it 
would be that you could have merged both patches into a single patch; just 
something to remember for future submissions.

Like the tree pruning thread patch, I'm going to queue this up for after this 
upcoming merge window.

> > As a general comment, not directed at anyone in particular, the audit
> > backlog/queue handling looks a little odd ...
> 
> Indeed...

I suspect we'll need to look closer at this code in the future, or rather I'll 
*want* to look closer at this in the future but for right now I think we've 
got enough to deal with.

-- 
paul moore
security @ redhat