Hi Stephane,
stephane eranian wrote:
> On Thu, Dec 18, 2008 at 11:00 PM, Corey J Ashford <cjash...@us.ibm.com> wrote:
>> Thanks for your reply, Stephane,
>>
>> "stephane eranian" <eran...@googlemail.com> wrote on 12/18/2008 01:56:16
>> AM:
>>
>>> Corey,
>>>
>>> I looked at the pfm_handle_work() code. Normally
>>> this functions gets called only if the TIF_PERFMON_WORK
>>> flag is set. On Power, it seems the logic is coded differently.
>>> You call systematically and in pfm_handle_work() you check
>>> the flag, and if not set you return.
>>>
>>> During boot, I don't expect TIF_PERFMON_WORK to be set.
>>> So I don't understand why FTRACER would have a problem
>>> with a function that does a simple test and returns.
>> Yes, in fact it appears that the call to _mcount is made even before the
>> test of TIF_PERFMON_WORK is made. Reading the ftrace.txt docs, it appears
>> that these _mcount calls are inserted by the compiler at the beginning of
>> every function, through the addition of gcc's -pg switch, if
>> CONFIG_DYNAMIC_FTRACE is true. However, the docs are out of date, I
>> think, and the -pg flag is dependent only upon CONFIG_FUNCTION_TRACER
>> being true (see Makefile).
>>
>> But why this is causing a problem only on this call, I don't yet know. The
>> _mcount code is in assembler, and might possibly make some incorrect
>> assumptions about how the registers are initialized.
>>
> Yes, but I wonder what's so special in a function that does:
>
> void pfm_handle_work(struct pt_regs *regs)
> {
> struct pfm_context *ctx;
> unsigned long flags, dummy_flags;
> int type, ret, info;
>
> #ifdef CONFIG_PPC
> /*
> * This is just a temporary fix. Obviously we'd like to fix the
> powerpc
> * code to make that check before calling __pfm_handle_work() to
> * prevent the function call overhead, but the call is made from
> * assembly code, so it will take a little while to figure out how to
> * perform the check correctly.
> */
> if (!test_thread_flag(TIF_PERFMON_WORK))
> return;
> #endif
>
> And you should hit that test and return.
>
> Maybe this is because it is always called from assembly.
I think you were pretty close to putting your finger on the problem.
After stepping through the code, I see that it is looping, and I believe
I know what the problem is. When CONFIG_PERFMON is defined, we call
pfm_handle_work before do_signal. But the problem is that the second
parameter to do_signal is initialized in the code that precedes these
two calls. The second parameter is passed in r4, and in the case of
having CONFIG_PERFMON turned on, we end up changing the value of r4 in
the process of calling pfm_handle_work. Depending on the changed value
of r4, it can cause an infinite looping problem.
As an experiment, I reversed the two calls, so that pfm_handle_work
occurs after do_signal, and so that r4 is still valid. This allowed the
kernel to boot up even with CONFIG_FUNCTION_TRACER enabled.
My question to you is: is it ok to call do_signal before
pfm_handle_work, or must it be done in the other order?
Regards,
- Corey
Corey Ashford
Software Engineer
IBM Linux Technology Center, Linux Toolchain
Beaverton, OR
503-578-3507
cjash...@us.ibm.com
------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
