[AUDIT/workaround] Increase AUDIT_NAMES array len

dmesg:
audit: name_count maxed, losing inode data: dev=00:05, inode=10118
audit: name_count maxed, losing inode data: dev=00:05, inode=10118
audit: name_count maxed, losing inode data: dev=00:05, inode=10118
audit: name_count maxed, losing inode data: dev=00:05, inode=10118
audit: name_count maxed, losing inode data: dev=00:05, inode=10118

This messages appear because of audit code has fixed array len for
handled inodes. This patch is workaround to increase array size for
inodes with minimal code changes. Mainstream does not have right fix for
it now so patch has to be back-ported from 3.0.1 or 3.0.1. Make debugging
message more verbose to track if we reached limit.

commit 449cedf099b23a250e7d61982e35555ccb871182
Author: Eric Paris <eparis@redhat.com>
Date:   Mon Apr 5 16:16:26 2010 -0400

    audit: preface audit printk with audit

    There have been a number of reports of people seeing the message:
    "name_count maxed, losing inode data: dev=00:05, inode=3185"
    in dmesg.  These usually lead to people reporting problems to the filesystem
    group who are in turn clueless what they mean.

    Eventually someone finds me and I explain what is going on and that
    these come from the audit system.  The basics of the problem is that the
    audit subsystem never expects a single syscall to 'interact' (for some
    wish washy meaning of interact) with more than 20 inodes.  But in fact
    some operations like loading kernel modules can cause changes to lots of
    inodes in debugfs.

    There are a couple real fixes being bandied about including removing the
    fixed compile time limit of 20 or not auditing changes in debugfs (or
    both) but neither are small and obvious so I am not sending them for
    immediate inclusion (I hope Al forwards a real solution next devel
    window).

    In the meantime this patch simply adds 'audit' to the beginning of the
    crap message so if a user sees it, they come blame me first and we can
    talk about what it means and make sure we understand all of the reasons
    it can happen and make sure this gets solved correctly in the long run.

    Signed-off-by: Eric Paris <eparis@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index 00d79df03e766e2b62abc1f8ffe5b501056334bf..d4d48ea55133859fd3e3eb2ff68453ddf38f1351 100644 (file)
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -72,7 +72,7 @@
 
 /* AUDIT_NAMES is the number of slots we reserve in the audit_context
  * for saving names from getname(). */
-#define AUDIT_NAMES    20
+#define AUDIT_NAMES   1024 
 
 /* Indicates that audit should log the full pathname. */
 #define AUDIT_NAME_FULL -1
@@ -1902,14 +1902,16 @@ static int audit_inc_name_count(struct audit_context *context,
 {
        if (context->name_count >= AUDIT_NAMES) {
                if (inode)
-                       printk(KERN_DEBUG "audit: name_count maxed, losing inode data: "
+                       printk(KERN_DEBUG "audit: name_count maxed(%d/%d), losing inode data: "
                               "dev=%02x:%02x, inode=%lu\n",
+                              context->name_count, AUDIT_NAMES,
                               MAJOR(inode->i_sb->s_dev),
                               MINOR(inode->i_sb->s_dev),
                               inode->i_ino);
 
                else
-                       printk(KERN_DEBUG "name_count maxed, losing inode data\n");
+                       printk(KERN_DEBUG "name_count maxed(%d/%d), losing inode data\n", 
+                                       context->name_count, AUDIT_NAMES);
                return 1;
        }
        context->name_count++;