From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Moore Subject: Re: [PATCH 2/2] audit: don't reset working wait time accidentally with auditd Date: Mon, 02 Feb 2015 16:16:08 -0500 Message-ID: <11389559.uhaFElqDAR@sifl> References: <2192ffc51189b5caa7d7172d59fea6fcc8bf07a5.1422392773.git.rgb@redhat.com> <4410568.1yJqvi4AlT@sifl> <20150130211044.GY18752@madcap2.tricolour.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20150130211044.GY18752@madcap2.tricolour.ca> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Richard Guy Briggs Cc: linux-audit@redhat.com, eparis@parisplace.org List-Id: linux-audit@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 > > > --- > > > > > > 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