Skip to content

L
linux
Switch branch/tag
  1. 12 Aug, 2014 24 commits
  3. 02 Aug, 2014 1 commit
  5. 31 Jul, 2014 2 commits
    • Arnaldo Carvalho de Melo's avatar
      perf symbols: Make sure --symfs usage includes the path separator · 972f393b
      Arnaldo Carvalho de Melo authored 
      Minchan reported that perf failed to load vmlinux if --symfs argument
doesn't end with '/' character.

Fix it by making sure that the '/' path separator is used when composing
pathnames with a --symfs provided directory name.
Reported-by: default avatarMinchan Kim <minchan@kernel.org>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/n/tip-8n4s6b6zvsez5ktanw006125@git.kernel.orgSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      972f393b
    • Arnaldo Carvalho de Melo's avatar
      perf evlist: Don't run workload if not told to · 5f1c4225
      Arnaldo Carvalho de Melo authored 
      The perf_evlist__prepare_workload() method works by forking and then
waiting on a fd that must be written to to allow the workload to be
exec()ed.

But if the tool calling it fails to, say, set up the events with which
it wants to sample the workload for, it will not call
perf_evlist__start_workload(), but even in this case the workload ended
up running:

  [acme@zoo linux]$ trace /bin/echo workload ends up running, it should not...
  Couldn't mmap the events: Operation not permitted
  workload ends up running, it should not...
  [acme@zoo linux]$

So check if at least one byte was written before letting exec() be
called.

Now the expected behaviour:

  [acme@zoo linux]$ trace /bin/echo workload ends up running, it should not...
  Couldn't mmap the events: Operation not permitted
  [acme@zoo linux]$
Acked-by: default avatarJiri Olsa <jolsa@redhat.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Don Zickus <dzickus@redhat.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Link: http://lkml.kernel.org/n/tip-oh1ixo8m74rf295a05gfjw8b@git.kernel.orgSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      5f1c4225
  7. 30 Jul, 2014 2 commits
  9. 28 Jul, 2014 5 commits
  11. 27 Jul, 2014 5 commits
  13. 26 Jul, 2014 1 commit
    • Linus Torvalds's avatar
      Fix gcc-4.9.0 miscompilation of load_balance() in scheduler · 2062afb4
      Linus Torvalds authored 
      Michel Dänzer and a couple of other people reported inexplicable random
oopses in the scheduler, and the cause turns out to be gcc mis-compiling
the load_balance() function when debugging is enabled.  The gcc bug
apparently goes back to gcc-4.5, but slight optimization changes means
that it now showed up as a problem in 4.9.0 and 4.9.1.

The instruction scheduling problem causes gcc to schedule a spill
operation to before the stack frame has been created, which in turn can
corrupt the spilled value if an interrupt comes in.  There may be other
effects of this bug too, but that's the code generation problem seen in
Michel's case.

This is fixed in current gcc HEAD, but the workaround as suggested by
Markus Trippelsdorf is pretty simple: use -fno-var-tracking-assignments
when compiling the kernel, which disables the gcc code that causes the
problem.  This can result in slightly worse debug information for
variable accesses, but that is infinitely preferable to actual code
generation problems.

Doing this unconditionally (not just for CONFIG_DEBUG_INFO) also allows
non-debug builds to verify that the debug build would be identical: we
can do

    export GCC_COMPARE_DEBUG=1

to make gcc internally verify that the result of the build is
independent of the "-g" flag (it will make the compiler build everything
twice, toggling the debug flag, and compare the results).

Without the "-fno-var-tracking-assignments" option, the build would fail
(even with 4.8.3 that didn't show the actual stack frame bug) with a gcc
compare failure.

See also gcc bugzilla:

  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61801Reported-by: default avatarMichel Dänzer <michel@daenzer.net>
Suggested-by: default avatarMarkus Trippelsdorf <markus@trippelsdorf.de>
Cc: Jakub Jelinek <jakub@redhat.com>
Cc: stable@kernel.org
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      2062afb4
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7