profile_pc() bogus since <= 2.6.19 (x86 at least)?

profile_pc() bogus since <= 2.6.19 (x86 at least)?

[Jan Beulich]

Ingo,

while the comment at the top of kernel/spinlock.c states so:

 * Note that some architectures have special knowledge about the
 * stack frames of these functions in their profile_pc. If you
 * change anything significant here that could change the stack
 * frame contact the architecture maintainers.

the actual code doesn't seem to match this anymore. With all (and
even before that, many) functions being written in C, there cannot
be validly made assumptions about the stack frame layout. Indeed,
if I check the disassembly framed by __lock_text_{start,end} on
x86, there are a number of functions that push one or two registers
(in lock_kernel() even stack variables are being allocated), which
clearly breaks profile_pc()'s assumptions.

Since it's been this way for so long, I wonder how frequently this
code is actually being exercised...

Jan

Re: profile_pc() bogus since <= 2.6.19 (x86 at least)?

[Ingo Molnar]

* Jan Beulich <jbeulich@novell.com> wrote:

> Ingo,
> 
> while the comment at the top of kernel/spinlock.c states so:
> 
>  * Note that some architectures have special knowledge about the
>  * stack frames of these functions in their profile_pc. If you
>  * change anything significant here that could change the stack
>  * frame contact the architecture maintainers.
> 
> the actual code doesn't seem to match this anymore. With all (and even 
> before that, many) functions being written in C, there cannot be 
> validly made assumptions about the stack frame layout. Indeed, if I 
> check the disassembly framed by __lock_text_{start,end} on x86, there 
> are a number of functions that push one or two registers (in 
> lock_kernel() even stack variables are being allocated), which clearly 
> breaks profile_pc()'s assumptions.
> 
> Since it's been this way for so long, I wonder how frequently this 
> code is actually being exercised...

yeah - i guess it's not really relevant anymore now that lockdep saves 
full stack traces. I doubt anyone bothers to look at wchan anymore. We 
might even remove all the __lock and __sched sections and annotations?

	Ingo

Re: profile_pc() bogus since <= 2.6.19 (x86 at least)?

[Jan Beulich]

>>> Ingo Molnar <mingo@elte.hu> 05.03.08 16:37 >>>
>
>* Jan Beulich <jbeulich@novell.com> wrote:
>
>> Ingo,
>> 
>> while the comment at the top of kernel/spinlock.c states so:
>> 
>>  * Note that some architectures have special knowledge about the
>>  * stack frames of these functions in their profile_pc. If you
>>  * change anything significant here that could change the stack
>>  * frame contact the architecture maintainers.
>> 
>> the actual code doesn't seem to match this anymore. With all (and even 
>> before that, many) functions being written in C, there cannot be 
>> validly made assumptions about the stack frame layout. Indeed, if I 
>> check the disassembly framed by __lock_text_{start,end} on x86, there 
>> are a number of functions that push one or two registers (in 
>> lock_kernel() even stack variables are being allocated), which clearly 
>> breaks profile_pc()'s assumptions.
>> 
>> Since it's been this way for so long, I wonder how frequently this 
>> code is actually being exercised...
>
>yeah - i guess it's not really relevant anymore now that lockdep saves 
>full stack traces. I doubt anyone bothers to look at wchan anymore. We 
>might even remove all the __lock and __sched sections and annotations?

Since drivers/oprofile/cpu_buffer.c and kernel/profile.c both have a
reference to profile_pc(), I'm not so sure about that. Perhaps if a
replacement for these two can be found...

Jan