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@xxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxx > > ReportedBy: jd1008@xxxxxxxxx > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
