Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752050AbdDIDC1 (ORCPT ); Sat, 8 Apr 2017 23:02:27 -0400 Received: from mail-it0-f52.google.com ([209.85.214.52]:36317 "EHLO mail-it0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751479AbdDIDCW (ORCPT ); Sat, 8 Apr 2017 23:02:22 -0400 Date: Sat, 8 Apr 2017 22:02:20 -0500 From: Seth Forshee To: Paul Moore , Eric Paris Cc: linux-audit@redhat.com, linux-kernel@vger.kernel.org Subject: audit regressions in 4.11 Message-ID: <20170409030220.GA33027@ubuntu-hedt> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 784 Lines: 17 I've observed audit regressions in 4.11-rc when not using a userspace audit daemon. The most obvious issue is that audit messages are not appearing in dmesg anymore. If a sufficient number of audit messages are generated the kernel will also start invoking the OOM killer. It looks like previously, when there's no auditd in userspace kauditd would call kauditd_hold_skb(), which prints the message using printk and either frees the skb or queues it (with a limit on the number of queued skb's by default). Since 5b52330bbfe6 "audit: fix auditd/kernel connection state tracking" when there's no auditd kauditd will instead use the retry queue, which has no limit. But it will not process the retry queue when there's no auditd, so messages pile up there indefinitely. Thanks, Seth