lkml.org 
[lkml]   [2010]   [Mar]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.6.33 GP fault only when built with tracing
Mathieu Desnoyers wrote:
> * Randy Dunlap (randy.dunlap@oracle.com) wrote:
>> On Fri, 19 Mar 2010 14:46:10 -0400 Mathieu Desnoyers wrote:
>>
>>> * Randy Dunlap (randy.dunlap@oracle.com) wrote:
>>>> On 03/18/10 17:59, Mathieu Desnoyers wrote:
>>>>> * Steven Rostedt (rostedt@goodmis.org) wrote:
>>>>>> On Thu, 2010-03-18 at 16:26 -0700, Randy Dunlap wrote:
>>>>>>> I can build/boot 2.6.33 with CONFIG_TRACE/TRACING disabled successfully,
>>>>>>> but when I enable lots of tracing config options and then boot with
>>>>>>> ftrace=nop on the kernel command line, I see a GP fault when the parport &
>>>>>>> parport_pc modules are loading/initializing.
>>>>>> Do you see it without adding the "ftrace=nop"? The only thing that
>>>>>> should do is expand the ring buffer on boot up.
>>>>>>
>>>>>>> It happens in drivers/parport/share.c::parport_register_device(), when that
>>>>>>> function calls try_module_get().
>>>>>>>
>>>>>>> If I comment out the trace_module_get() calls in include/linux/module.h,
>>>>>>> the kernel boots with no problems.
>>>>>>
>>>>>> Interesting. Well, trace_module_get() is a TRACE_EVENT tracepoint. But
>>>>>> should be disabled here. It may be something to do with DEFINE_TRACE.
>>>>>>
>>>>>> (added Mathieu to Cc since he wrote that code)
>>>>> can you try replacing the "local_read(__module_ref_addr(module, cpu))" argument
>>>>> with "0" ?
>>>> Yes, that boots with no problems.
>>> clickety-clicketa... git blame include/linux/module.h :
>>>
>>> commit 7ead8b8313d92b3a69a1a61b0dcbc4cd66c960dc
>>> Author: Li Zefan <lizf@cn.fujitsu.com>
>>> Date: Mon Aug 17 16:56:28 2009 +0800
>>>
>>> tracing/events: Add module tracepoints
>>>
>>> (Adding Li Zefan in CC)
>>>
>>> Two things:
>>>
>>> 1) In this commit, most of the tracepoints contain argument with side-effects.
>>> These do not belong there; they should be moved into TRACE_EVENT macros.
>>>
>>> 2) There seem to be a null-pointer bug with
>>> local_read(__module_ref_addr(module, cpu)) in try_module_get(). This should
>>> be investigated even if we move the argument to TRACE_EVENT.
>> Hi Li,
>>
>> Fix this, please?
>>
>
> While we wait for the sun to move to other time zones, can you check if the
> following patch fixes your problem ?
>

Sorry, I overlooked this mail thread..

I'll make a patch to move side-effects arguments from trace_module_xxx()
to the definition of TRACE_EVENT().

But it's for reducing overhead when tracepoints are disabled, this should
not be the real cultprit of the bug here.

>
> module: fix __module_ref_addr()
>
> __module_ref_addr() should use per_cpu_ptr() to obfuscate the pointer
> (RELOC_HIDE is needed for per cpu pointers).
>
> This non-standard per-cpu pointer use has been introduced by commit
> 720eba31f47aeade8ec130ca7f4353223c49170f
>

So the uptream kernel is free from this bug, because __module_ref_addr()
has gone.

> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
> CC: Eric Dumazet <dada1@cosmosbay.com>
> CC: Rusty Russell <rusty@rustcorp.com.au>
> ---
> include/linux/module.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Index: linux-2.6-lttng/include/linux/module.h
> ===================================================================
> --- linux-2.6-lttng.orig/include/linux/module.h 2010-03-23 18:11:14.000000000 -0400
> +++ linux-2.6-lttng/include/linux/module.h 2010-03-23 18:14:07.000000000 -0400
> @@ -467,7 +467,7 @@ void symbol_put_addr(void *addr);
> static inline local_t *__module_ref_addr(struct module *mod, int cpu)
> {
> #ifdef CONFIG_SMP
> - return (local_t *) (mod->refptr + per_cpu_offset(cpu));
> + return (local_t *) per_cpu_ptr(mod->refptr, cpu);
> #else
> return &mod->ref;
> #endif
>
>


\
 
 \ /
  Last update: 2010-03-24 02:43    [W:0.062 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site