* [PATCH] Re: name_count maxed, losing inode data: dev=00:05, inode=5221
@ 2010-02-03 17:39 Christian Kujau
2010-02-08 8:38 ` Christian Kujau
0 siblings, 1 reply; 3+ messages in thread
From: Christian Kujau @ 2010-02-03 17:39 UTC (permalink / raw)
To: LKML; +Cc: eparis, sandeen, Ralf.Hildebrandt, Udo.Wolter, ext-users
Ralf Hildebrandt reported[0] the following messages on ext3-users:
name_count maxed, losing inode data: dev=00:05, inode=5221
because the filesystem in question is indeed ext3. However, this warning
is not generated by ext3 code but by the audit framework. While the
origins of these messages are discussed elsewhere[1] the following
patch modifies the printks in question so that users know where these
messages are coming from. There may be other places within the audit
framework needing the same treatment.
[0] http://www.redhat.com/archives/ext3-users/2010-February/msg00000.html
[1] https://bugzilla.redhat.com/show_bug.cgi?id=495207
Signed-off-by: Christian Kujau <lists@nerdbynature.de>
Reported-by: Ralf Hildebrandt <Ralf.Hildebrandt@charite.de>
Cc: Eric Paris <eparis@redhat.com>
auditsc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/linux-2.6-git/kernel/auditsc.c.orig b/linux-2.6-git/kernel/auditsc.c
index fc0f928..17d8708 100644
--- a/linux-2.6-git/kernel/auditsc.c.orig
+++ b/linux-2.6-git/kernel/auditsc.c
@@ -1893,14 +1893,14 @@ static int audit_inc_name_count(struct audit_context *context,
{
if (context->name_count >= AUDIT_NAMES) {
if (inode)
- printk(KERN_DEBUG "name_count maxed, losing inode data: "
+ 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");
+ printk(KERN_DEBUG "audit: name_count maxed, losing inode data\n");
return 1;
}
context->name_count++;
--
BOFH excuse #298:
Not enough interrupts
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH] Re: name_count maxed, losing inode data: dev=00:05, inode=5221
2010-02-03 17:39 [PATCH] Re: name_count maxed, losing inode data: dev=00:05, inode=5221 Christian Kujau
@ 2010-02-08 8:38 ` Christian Kujau
2010-02-17 16:37 ` Eric Paris
0 siblings, 1 reply; 3+ messages in thread
From: Christian Kujau @ 2010-02-08 8:38 UTC (permalink / raw)
To: LKML; +Cc: eparis, sandeen, Ralf.Hildebrandt, Udo.Wolter, ext-users
On Wed, 3 Feb 2010 at 09:39, Christian Kujau wrote:
> Ralf Hildebrandt reported[0] the following messages on ext3-users:
>
> name_count maxed, losing inode data: dev=00:05, inode=5221
>
> because the filesystem in question is indeed ext3. However, this warning
> is not generated by ext3 code but by the audit framework. While the
> origins of these messages are discussed elsewhere[1] the following
> patch modifies the printks in question so that users know where these
> messages are coming from. There may be other places within the audit
> framework needing the same treatment.
...ping?
>
> [0] http://www.redhat.com/archives/ext3-users/2010-February/msg00000.html
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=495207
>
> Signed-off-by: Christian Kujau <lists@nerdbynature.de>
> Reported-by: Ralf Hildebrandt <Ralf.Hildebrandt@charite.de>
> Cc: Eric Paris <eparis@redhat.com>
>
> auditsc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/linux-2.6-git/kernel/auditsc.c.orig b/linux-2.6-git/kernel/auditsc.c
> index fc0f928..17d8708 100644
> --- a/linux-2.6-git/kernel/auditsc.c.orig
> +++ b/linux-2.6-git/kernel/auditsc.c
> @@ -1893,14 +1893,14 @@ static int audit_inc_name_count(struct audit_context *context,
> {
> if (context->name_count >= AUDIT_NAMES) {
> if (inode)
> - printk(KERN_DEBUG "name_count maxed, losing inode data: "
> + 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");
> + printk(KERN_DEBUG "audit: name_count maxed, losing inode data\n");
> return 1;
> }
> context->name_count++;
>
> --
> BOFH excuse #298:
>
> Not enough interrupts
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
--
BOFH excuse #258:
That's easy to fix, but I can't be bothered.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] Re: name_count maxed, losing inode data: dev=00:05, inode=5221
2010-02-08 8:38 ` Christian Kujau
@ 2010-02-17 16:37 ` Eric Paris
0 siblings, 0 replies; 3+ messages in thread
From: Eric Paris @ 2010-02-17 16:37 UTC (permalink / raw)
To: Christian Kujau; +Cc: LKML, sandeen, Ralf.Hildebrandt, Udo.Wolter, ext-users
On Mon, 2010-02-08 at 00:38 -0800, Christian Kujau wrote:
> On Wed, 3 Feb 2010 at 09:39, Christian Kujau wrote:
> > Ralf Hildebrandt reported[0] the following messages on ext3-users:
> >
> > name_count maxed, losing inode data: dev=00:05, inode=5221
> >
> > because the filesystem in question is indeed ext3. However, this warning
> > is not generated by ext3 code but by the audit framework. While the
> > origins of these messages are discussed elsewhere[1] the following
> > patch modifies the printks in question so that users know where these
> > messages are coming from. There may be other places within the audit
> > framework needing the same treatment.
>
> ...ping?
I'm tracking these issues as Red Hat bz 445757. I've got a patch which
removes the restriction of 20 inodes being accessed in one syscall which
I've floated to Al Viro to see what he thinks. Since the restriction is
gone we won't lose names and thus it removes these messages altogether.
You are not forgotten!
-Eric
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2010-02-17 16:38 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-02-03 17:39 [PATCH] Re: name_count maxed, losing inode data: dev=00:05, inode=5221 Christian Kujau
2010-02-08 8:38 ` Christian Kujau
2010-02-17 16:37 ` Eric Paris
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).