Re: [Bug #15196] kmem_cache_create: duplicate cache ccid2_h

From: Neil Horman
Date: Mon Feb 01 2010 - 06:55:33 EST


On Sun, Jan 31, 2010 at 11:20:50PM -0800, David Miller wrote:
> From: Xiaotian Feng <xtfeng@xxxxxxxxx>
> Date: Mon, 1 Feb 2010 11:30:02 +0800
>
> > On Mon, Feb 1, 2010 at 8:22 AM, Rafael J. Wysocki <rjw@xxxxxxx> 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@xxxxxxxxxxxxxxxxx>
> >> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/