This old problem was also reported in redhat in redhat bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=445757 in mid 2008. The message is coming from kernel/auditsc.c in audit_inc_name_count(): static int audit_inc_name_count(struct audit_context *context, const struct inode *inode) { if (context->name_count >= AUDIT_NAMES) { if (inode) printk(KERN_DEBUG "audit: name_count maxed, losing inode data: " "dev=%02x:%02x, inode=%lu\n", 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"); return 1; } context->name_count++; #if AUDIT_DEBUG context->ino_count++; #endif return 0; } I wish the kernel would also dump the stack, and funcs param values into /var/log/messages so a user can take a look at the source and do some searching for the cause of this. Also, if you can advise on how I can rebuild the kernel so that it will drop into the debugger when this happens, would be a great help.
The complete message is: Oct 2 10:15:43 vger kernel: audit: name_count maxed, losing inode data: dev=00:05, inode=4 What's strange is that I have no device in /dev with major of 0 and minor of 5.
(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Sat, 9 Oct 2010 06:58:14 GMT bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=19932 > > Summary: Getting lots of name_count maxed, losing inode data > messages in /var/log/messages > Product: Other > Version: 2.5 > Kernel Version: 2.6.35.7 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: Other > AssignedTo: other_other@kernel-bugs.osdl.org > ReportedBy: jd1008@gmail.com > Regression: No > > > This old problem was also reported in redhat in redhat bugzilla: > https://bugzilla.redhat.com/show_bug.cgi?id=445757 > in mid 2008. > > > The message is coming from kernel/auditsc.c in audit_inc_name_count(): > > > static int audit_inc_name_count(struct audit_context *context, > const struct inode *inode) > { > if (context->name_count >= AUDIT_NAMES) { > if (inode) > printk(KERN_DEBUG "audit: name_count maxed, losing > inode data: " > "dev=%02x:%02x, inode=%lu\n", > 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"); > return 1; > } > context->name_count++; > #if AUDIT_DEBUG > context->ino_count++; > #endif > return 0; > } > > I wish the kernel would also dump the stack, and funcs param values into > /var/log/messages > so a user can take a look at the source and do some searching > for the cause of this. > > Also, if you can advise on how I can rebuild the kernel so that > it will drop into the debugger when this happens, would be a great > help. >
On Mon, 2010-10-11 at 14:34 -0700, Andrew Morton wrote: > (switched to email. Please respond via emailed reply-to-all, not via the > bugzilla web interface). > > On Sat, 9 Oct 2010 06:58:14 GMT > bugzilla-daemon@bugzilla.kernel.org wrote: > > > https://bugzilla.kernel.org/show_bug.cgi?id=19932 > > > > Summary: Getting lots of name_count maxed, losing inode data > > messages in /var/log/messages > > Product: Other > > Version: 2.5 > > Kernel Version: 2.6.35.7 > > Platform: All > > OS/Version: Linux > > Tree: Mainline > > Status: NEW > > Severity: normal > > Priority: P1 > > Component: Other > > AssignedTo: other_other@kernel-bugs.osdl.org > > ReportedBy: jd1008@gmail.com > > Regression: No > > > > > > This old problem was also reported in redhat in redhat bugzilla: > > https://bugzilla.redhat.com/show_bug.cgi?id=445757 > > in mid 2008. > > > > > > The message is coming from kernel/auditsc.c in audit_inc_name_count(): > > > > > > static int audit_inc_name_count(struct audit_context *context, > > const struct inode *inode) > > { > > if (context->name_count >= AUDIT_NAMES) { > > if (inode) > > printk(KERN_DEBUG "audit: name_count maxed, losing > > inode data: " > > "dev=%02x:%02x, inode=%lu\n", > > 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"); > > return 1; > > } > > context->name_count++; > > #if AUDIT_DEBUG > > context->ino_count++; > > #endif > > return 0; > > } > > > > I wish the kernel would also dump the stack, and funcs param values into > > /var/log/messages > > so a user can take a look at the source and do some searching > > for the cause of this. > > > > Also, if you can advise on how I can rebuild the kernel so that > > it will drop into the debugger when this happens, would be a great > > help. The audit systems has a hard coded value of 20 for the number of inodes/pathnames it will collect information about in a single syscall. Loading modules (such as kvm) are known to create all sorts of entries in debugfs which overflows audit's tracking. I also know that mounting nfs the first time can do it setting up rpcfs. I fixed it in RHEL by just changing the static 20 to a dynamic list but I don't think Al liked that solution for upstream and instead wanted to find all of the places we were overrunning 20 (hell overrunning 5 is a problem) and figure out how to stop them from overrunning (typically by disabling audit was his thought) I just haven't gotten back to it as they are harmless (if scary sounding) -Eric
Thanks Eric. For a seconds I thought that perhaps I was doing something to corrupt the in-core inodes, and thus currupting the FS. I will ignore it. Please close the bug as a duplpicate of the bug files in redhat bugzilla.