On Fri, 25 Jul 2014 11:29:06 -0700
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Fri, Jul 25, 2014 at 7:02 AM, Steven Rostedt <rostedt@goodmis.org> wrote:
> >
> > But wouldn't it be rather trivial to run a static analyzer on the final
> > vmlinux to make sure there are no red zones? I mean, you would only need
> > to read each function and check to make sure that the offset of rbp is
> > within the change of rsp, wouldn't you?
> >
> > Almost seems like an objdump -rd into a perl script could do this.
> 
> I'm sure it's possible, but it sounds potentially complicated. It's
> not like the function prologue is fixed, and gcc will create code
> (including conditional branches etc) before the whole frame setup if
> there are simple things that can be done purely with the
> callee-clobbered registers etc.
> 
> Some simple pattern to make sure that the "sub $frame-size,%rsp" comes
> before any accesses to (%rbp) (when frame pointers are enabled)
> *might* work, but it might also end up missing things.
> 
> You want to try?
> 

I tried :-)

Seems to stay clean with my x86_64 vmlinux build. I compiled the fair.s
file and tested it and it got this:

$ objump -dr fair.o | ./check-vmlinux.pl
ERROR: <load_balance>: depth=-40 offset=136 at 4210
    3572:	48 c7 85 78 ff ff ff 	movq   $0x0,-0x88(%rbp)
ERROR: <sched_group_set_shares>: depth=8 offset=48 at 5734
    4a79:	48 89 45 d0          	mov    %rax,-0x30(%rbp)
ERROR: <sched_group_set_shares>: depth=8 offset=48 at 5743
    4a9c:	48 8b 75 d0          	mov    -0x30(%rbp),%rsi

The sched_group_set_shares errors seem to be bogus as that is done
after %rbp has been popped. Looks to be code that was jumped to from
the main body. I could probably fix this by ignoring code after a pop
of %rbp. Or make it more complex and be a bit smarter about branches.

The script will read a file if passed by parameter, otherwise it reads
standard input.

e.g.

$ objump -dr fair.o | ./check-vmlinux.pl

or

$ objdump -dr fair.o > /tmp/fair.dump
$ ./check-vmlinux.pl /tmp/fair.dump

produce the same.

It's a little hacky, but I only spent a half hour at most on it.

-- Steve