[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100201115518.GA25094@hmsreliant.think-freely.org>
Date: Mon, 1 Feb 2010 06:55:18 -0500
From: Neil Horman <nhorman@...driver.com>
To: David Miller <davem@...emloft.net>
Cc: xtfeng@...il.com, rjw@...k.pl, htd@...cy-poultry.org,
linux-kernel@...r.kernel.org, kernel-testers@...r.kernel.org
Subject: Re: [Bug #15196] kmem_cache_create: duplicate cache ccid2_h
On Sun, Jan 31, 2010 at 11:20:50PM -0800, David Miller wrote:
> From: Xiaotian Feng <xtfeng@...il.com>
> Date: Mon, 1 Feb 2010 11:30:02 +0800
>
> > On Mon, Feb 1, 2010 at 8:22 AM, Rafael J. Wysocki <rjw@...k.pl> wrote:
> >> This message has been generated automatically as a part of a report
> >> of recent regressions.
> >>
> >> The following bug entry is on the current list of known regressions
> >> from 2.6.32. Please verify if it still should be listed and let me know
> >> (either way).
> >>
> >>
> >> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15196
> >> Subject : kmem_cache_create: duplicate cache ccid2_h
> >> Submitter : Heinz Diehl <htd@...cy-poultry.org>
> >> Date : 2010-01-30 18:33 (2 days old)
> >> References : http://marc.info/?l=linux-kernel&m=126487640324942&w=4
> >
> > Cced Neil,
> >
> > I think this one is introduced by commit
> > de4ef86cfce60d2250111f34f8a084e769f23b16,
> > passing char *slab_name_fmt as function parameter, but vsnprintf is
> > using sizeof(slab_name_fmt),
> > which is 8 (or 4 in 32bit kernel) instead of 32 as old version.
> >
> > Does following patch resolve this bug, Heinz?
>
> There seems to be even more to this than that. Neils
> patch seems to need completely reverting.
>
> See the patch set posted by Gerrit Renker:
>
> http://marc.info/?l=linux-netdev&m=126500585823775&w=2
> http://marc.info/?l=linux-netdev&m=126500591923880&w=2
>
Dave, some of this doesn't make the least bit of sense to me. I get the sizeof
error, thats clear (and I apologize, I should have seen that), but Gerrits
revert of the dccp_probe changes is non-sensical. I'm not sure I even follow
the comments:
>Previously (during about 4 years of this module's history) there had never
>been a problem with the 'silent dependency' that the commit tried to fix:
>this dependency is deliberate and required, since dccp_probe performs probing
>of dccp connections and hence needs to know about dccp internals.
He claims this dependency is deliberate and requires, to which I agree, but he
would seem to fix that by making the dccp_probe module error out in the event
that dccp wasn't loaded. Why bother with that?
Neil
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists