public inbox for linux-audit@redhat.com
 help / color / mirror / Atom feed
From: Richard Guy Briggs <rgb@redhat.com>
To: linux-audit@redhat.com
Cc: Richard Guy Briggs <rbriggs@redhat.com>
Subject: [PATCH 1/6] audit: refactor hold queue flush
Date: Thu, 24 Jan 2013 13:15:10 -0500	[thread overview]
Message-ID: <1359051315-20905-2-git-send-email-rgb@redhat.com> (raw)
In-Reply-To: <1359051315-20905-1-git-send-email-rgb@redhat.com>

The hold queue flush code is an autonomous chunk of code that can be
refactored, removed from kauditd_thread() into flush_hold_queue() and
flattenned for better legibility.

Signed-off-by: Richard Guy Briggs <rbriggs@redhat.com>
---

This is a code clean up in preparation to add a multicast netlink socket to
kaudit for read-only userspace clients such as systemd, in addition to the
bidirectional audit userspace client.

 kernel/audit.c | 62 +++++++++++++++++++++++++++++++++++++---------------------
 1 file changed, 40 insertions(+), 22 deletions(-)

diff --git a/kernel/audit.c b/kernel/audit.c
index d596e53..4bf486c 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -417,34 +417,52 @@ static void kauditd_send_skb(struct sk_buff *skb)
 		consume_skb(skb);
 }
 
+/*
+ * flush_hold_queue - empty the hold queue if auditd appears
+ *
+ * If auditd just started, drain the queue of messages already
+ * sent to syslog/printk.  Remember loss here is ok.  We already
+ * called audit_log_lost() if it didn't go out normally.  so the
+ * race between the skb_dequeue and the next check for audit_pid
+ * doesn't matter.
+ *
+ * If you ever find kauditd to be too slow we can get a perf win
+ * by doing our own locking and keeping better track if there
+ * are messages in this queue.  I don't see the need now, but
+ * in 5 years when I want to play with this again I'll see this
+ * note and still have no friggin idea what i'm thinking today.
+ */
+static void flush_hold_queue(void)
+{
+	struct sk_buff *skb;
+
+	if (!audit_default || !audit_pid)
+		return;
+
+	skb = skb_dequeue(&audit_skb_hold_queue);
+	if (likely(!skb))
+		return;
+
+	while (skb && audit_pid) {
+		kauditd_send_skb(skb);
+		skb = skb_dequeue(&audit_skb_hold_queue);
+	}
+
+	/*
+	 * if auditd just disappeared but we
+	 * dequeued an skb we need to drop ref
+	 */
+	if (skb)
+		consume_skb(skb);
+}
+
 static int kauditd_thread(void *dummy)
 {
 	struct sk_buff *skb;
 
 	set_freezable();
 	while (!kthread_should_stop()) {
-		/*
-		 * if auditd just started drain the queue of messages already
-		 * sent to syslog/printk.  remember loss here is ok.  we already
-		 * called audit_log_lost() if it didn't go out normally.  so the
-		 * race between the skb_dequeue and the next check for audit_pid
-		 * doesn't matter.
-		 *
-		 * if you ever find kauditd to be too slow we can get a perf win
-		 * by doing our own locking and keeping better track if there
-		 * are messages in this queue.  I don't see the need now, but
-		 * in 5 years when I want to play with this again I'll see this
-		 * note and still have no friggin idea what i'm thinking today.
-		 */
-		if (audit_default && audit_pid) {
-			skb = skb_dequeue(&audit_skb_hold_queue);
-			if (unlikely(skb)) {
-				while (skb && audit_pid) {
-					kauditd_send_skb(skb);
-					skb = skb_dequeue(&audit_skb_hold_queue);
-				}
-			}
-		}
+		flush_hold_queue();
 
 		skb = skb_dequeue(&audit_skb_queue);
 		wake_up(&audit_backlog_wait);
-- 
1.8.0.2

  reply	other threads:[~2013-01-24 18:15 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-24 18:15 [PATCH 0/6] audit: add restricted capability read-only netlink multicast socket Richard Guy Briggs
2013-01-24 18:15 ` Richard Guy Briggs [this message]
2013-01-24 18:15 ` [PATCH 2/6] audit: flatten kauditd_thread wait queue code Richard Guy Briggs
2013-01-24 18:15 ` [PATCH 3/6] audit: move kaudit thread start from auditd registration to kaudit init Richard Guy Briggs
2013-01-24 18:15 ` [PATCH 4/6] netlink: add send and receive capability requirement and capability flags Richard Guy Briggs
2013-01-24 18:15 ` [PATCH 5/6] audit: add restricted capability read-only netlink multicast socket Richard Guy Briggs
2013-01-24 18:15 ` [PATCH 6/6] audit: send multicast messages only if there are listeners Richard Guy Briggs

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1359051315-20905-2-git-send-email-rgb@redhat.com \
    --to=rgb@redhat.com \
    --cc=linux-audit@redhat.com \
    --cc=rbriggs@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox