From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0469BC433DB for ; Sun, 17 Jan 2021 21:13:10 +0000 (UTC) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 773A42247F for ; Sun, 17 Jan 2021 21:13:09 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 773A42247F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=tempfail smtp.mailfrom=linux-audit-bounces@redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1610917988; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=GbjgaA29EQlQeKc/R+cUPZj9cNWzDTVHFR0aX4FSvUA=; b=SymxJE+wziG8MJ+K1zbj3Ids/k+CamjfsA60U49IQN7bZ1Rfaxh/hD7oOsVp2Jo5Xx2fxF VHDCmsZQLJUKFwtNAF1KZeCTDlAeEPmygEXmSLpnP8IqRPSV46ICZ0Ut8KiiY0jKu0MBN1 0VJoEp0jIhk4Xh06kpe5Q0+dTrZT4Xg= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-489-JW1-a5ZUOHKT5WA-d2dXFA-1; Sun, 17 Jan 2021 16:13:06 -0500 X-MC-Unique: JW1-a5ZUOHKT5WA-d2dXFA-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 80FAD59; Sun, 17 Jan 2021 21:13:02 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.20]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E7FF55D9CC; Sun, 17 Jan 2021 21:13:01 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id 8595A180954D; Sun, 17 Jan 2021 21:12:42 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 10HLCeti030413 for ; Sun, 17 Jan 2021 16:12:40 -0500 Received: by smtp.corp.redhat.com (Postfix) id 2798160C15; Sun, 17 Jan 2021 21:12:40 +0000 (UTC) Received: from x2.localnet (ovpn-113-60.rdu2.redhat.com [10.10.113.60]) by smtp.corp.redhat.com (Postfix) with ESMTP id C7E8560BE2; Sun, 17 Jan 2021 21:12:32 +0000 (UTC) From: Steve Grubb To: burn@swtf.dyndns.org, linux-audit@redhat.com Subject: Re: Occasional delayed output of events Date: Sun, 17 Jan 2021 16:12:32 -0500 Message-ID: <5445873.DvuYhMxLoT@x2> Organization: Red Hat In-Reply-To: References: <30c5dbc14368a1919717e2f39d2d4c29463c3108.camel@iinet.net.au> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-loop: linux-audit@redhat.com Cc: Richard Guy Briggs , Linux Audit X-BeenThere: linux-audit@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Linux Audit Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=linux-audit-bounces@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Sunday, January 17, 2021 9:07:08 AM EST Paul Moore wrote: > On Fri, Jan 15, 2021 at 9:43 PM Burn Alting wrote: > > On Fri, 2021-01-15 at 19:35 -0500, Richard Guy Briggs wrote: > >> Or we go back to userspace code looking for the EOE record? This > >> doesn't help if they arrive out of order. Do we number the records in > >> the kernel? N of M... > > > > I like the N of M concept but there would be a LOT of change - especially > > for all the non-kernel event sources. The EOE would be the most > > seamless, but at a cost. My preference is to allow the 2 second 'timer' > > to be configurable. > > Agree with Burn, numbering the records coming up from the kernel is > going to be a real nightmare, and not something to consider lightly. > Especially when it sounds like we don't yet have a root cause for the > issue. A very long time ago, we had numbered records. But it was decided that there's no real point in it and we'd rather just save disk space. I know that the kernel does not serialize the events headed for user space. But I'm curious how an event gets stuck and others can jump ahead while one that's already inflight can get hung for 4 seconds before it's next record goes out? -Steve -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit