linux-kernel - Re: problem with function

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Thu, 18 Jun 2009 20:32:34 -0400 (EDT)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
cc:	Jake Edge <jake@....net>, LKML <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...e.hu>,
	Frederic Weisbecker <fweisbec@...il.com>
Subject: Re: problem with function_graph self-test?


On Thu, 18 Jun 2009, Jeremy Fitzhardinge wrote:
> >
> > This is something that gcc is screwing with us. After spending all day 
> > today trying to figure out what is happening, I finally found it in the 
> > assembly.
> >
> > In the timer_stats_update_stats function, I get this at the beginning:
> >
> > 00000327 <timer_stats_update_stats>:
> >  327:   57                      push   %edi
> >  328:   8d 7c 24 08             lea    0x8(%esp),%edi
> >  32c:   83 e4 e0                and    $0xffffffe0,%esp
> >  32f:   ff 77 fc                pushl  0xfffffffc(%edi)
> >  332:   55                      push   %ebp
> >  333:   89 e5                   mov    %esp,%ebp
> >  335:   57                      push   %edi
> >  336:   56                      push   %esi
> >  337:   53                      push   %ebx
> >  338:   81 ec 8c 00 00 00       sub    $0x8c,%esp
> >  33e:   e8 fc ff ff ff          call   33f <timer_stats_update_stats+0x18>
> >                         33f: R_386_PC32 mcount
> >
> >
> > And this at the end of the function:
> >
> >  4f6:   8d 67 f8                lea    0xfffffff8(%edi),%esp
> >  4f9:   5f                      pop    %edi
> >  4fa:   c3                      ret    
> >   
> 
> Something to do with using _RET_IP_ in spin_unlock_irqrestore() perhaps?

No, it was the fact that there was a local variable of type struct entry, 
where entry was defined to be ____cacheline_aligned_in_smp. But that was 
not the end of it. It happens throughout the code. The next hit was in 
tcp_ack(). But it has something to do with -Os on i386.

-- Steve

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/