Re: Dynamic Debug broken on 2.6.35-rc3?

[Thomas Renninger]

Hi,

it's this one:
commit ff49d74ad383f54041378144ca1a229ee9aeaa59
Author: Yehuda Sadeh <yehuda@xxxxxxxxxxxxxxx>
Date:   Sat Jul 3 13:07:35 2010 +1000

which touches same code than Jason's fix does.
Possibly this patch also addresses (only parts of?) this problem?
Jason: Do you mind having a look at the latest git version and review
Yehuda's  and adjust your patch if still necessary.
If Yehuda's patch is fixing this already, we still need it backported for
2.6.34 stable kernel and further?

One question about dynamic debug (unrelated to the mem corruption
issue):
Would it make sense to initialize dynamic debug earlier, somewhen shortly
after __setup is called.
Then a boot param ddebug_enable="xy" could be added.
The param could be in /sys/../control format or just be "all"?
My idea is to be able to track all the pr_debug calls (as) early (as possible) 
at boot up.
One example is ec.c. Currently it is not possible to see the pr_debug messages
when EC accesses are done when the ACPI interpreter is started, there
is no userspace and no sysfs yet.
Same for PCI related pr_debug messages at early PCI(e) initialization time?
Would that be possible or do I miss something?

Thanks,

     Thomas

On Friday 09 July 2010 03:30:19 pm Jason Baron wrote:
> On Fri, Jul 09, 2010 at 01:03:08PM +0200, Thomas Renninger wrote:
> > Hi,
> >
> > I can confirm that this patch fixes the issue for me.
> >
> > On Thursday 08 July 2010 23:53:00 Andrew Morton wrote:
> > > On Thu, 8 Jul 2010 17:39:28 -0400
> > >
> > > Jason Baron <jbaron@xxxxxxxxxx> wrote:
> > > > Make sure we properly call ddebug_remove_module() when a module fails
> > > > to load. In addition, pass the pointer to the "debug table", to both
> > > > ddebug_add_module(), and ddebug_remove_module() so that we can
> > > > uniquely identify each set of debug statements. In this way even
> > > > modules with the same name can be properly identified and removed.
> > > >
> > > >
> > > > Signed-off-by: Jason Baron <jbaron@xxxxxxxxxx>
> > >
> > > It'd be nice to track the Reported-by:s.  And the Tested-by:s if/when
> > > they arrive.  SighIllDoIt.
> > >
> > > The patch (almost) applies to 2.6.34.  So are we missing a Cc:stable
> > > tag as well?
> >
> > I'll resubmit with some more meta info and will include
> > stable@xxxxxxxxxxx
> >
> > Could it be that this isn't a regression, but a bug that was always
> > present, but only gets exposed if you add modules with a specific
> > implementation, e.g. specific declarations of functions missing, etc.?
>
> Hi Thomas,
>
> yes, this race has likely been present for a while (i'd have to look at
> specific kernel versions to verify). I suspect its getting exposed now
> due to more usage of this feature, and the proliferation of kernel
> modules...
>
> > I tried to patch this into a 2.6.32.X kernel. While some hunks did not
> > succeed, it looks like an adjusted patch should get submitted for older
> > stable kernels as well?:
>
> if nobody else has done the 2.6.32 stable patch, I can do it, just let
> me know.
>
> thanks again for reporting this to me.
>
> thanks,
>
> -Jason


--
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/