objtool: Hide unnecessary compiler error message

The check for using old libelf prints an error message when libelf.h is
not available but does not abort. This may confuse so hide the compiler
error

objtool: Hide unnecessary compiler error message

The check for using old libelf prints an error message when libelf.h is
not available but does not abort. This may confuse so hide the compiler
error message.

Signed-off-by: David Engraf <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Josh Poimboeuf <[email protected]>

show more ...

tools: Remove redundant quiet setup

Q is exported from Makefile.include so it is not necessary to manually
set it.

Reviewed-by: Jiri Olsa <[email protected]>
Signed-off-by: Charlie Jenkins <charlie@

tools: Remove redundant quiet setup

Q is exported from Makefile.include so it is not necessary to manually
set it.

Reviewed-by: Jiri Olsa <[email protected]>
Signed-off-by: Charlie Jenkins <[email protected]>
Acked-by: Andrii Nakryiko <[email protected]>
Acked-by: Quentin Monnet <[email protected]>
Cc: Adrian Hunter <[email protected]>
Cc: Alexander Shishkin <[email protected]>
Cc: Alexei Starovoitov <[email protected]>
Cc: Benjamin Tissoires <[email protected]>
Cc: Daniel Borkmann <[email protected]>
Cc: Daniel Lezcano <[email protected]>
Cc: Eduard Zingerman <[email protected]>
Cc: Hao Luo <[email protected]>
Cc: Ian Rogers <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Jiri Kosina <[email protected]>
Cc: John Fastabend <[email protected]>
Cc: Josh Poimboeuf <[email protected]>
Cc: KP Singh <[email protected]>
Cc: Lukasz Luba <[email protected]>
Cc: Mark Rutland <[email protected]>
Cc: Martin KaFai Lau <[email protected]>
Cc: Mykola Lysenko <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Rafael J. Wysocki <[email protected]>
Cc: Shuah Khan <[email protected]>
Cc: Song Liu <[email protected]>
Cc: Stanislav Fomichev <[email protected]>
Cc: Steven Rostedt (VMware) <[email protected]>
Cc: Yonghong Song <[email protected]>
Cc: Zhang Rui <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>

show more ...

objtool: Also include tools/include/uapi

When building objtool against a sysroot that contains a stripped down
version of the UAPI headers, the following error happens:

In file included from ar

objtool: Also include tools/include/uapi

When building objtool against a sysroot that contains a stripped down
version of the UAPI headers, the following error happens:

In file included from arch/x86/decode.c:10:
In file included from .../tools/arch/x86/include/asm/insn.h:10:
In file included from <sysroot>/include/asm/byteorder.h:9:
In file included from <sysroot>/include/linux/byteorder/little_endian.h:15:
In file included from <sysroot>/include/linux/stddef.h:9:
In file included from .../tools/include/linux/compiler_types.h:36:
.../tools/include/linux/compiler-gcc.h:3:2: error: "Please don't include <linux/compiler-gcc.h> directly, include <linux/compiler.h> instead."
3 | #error "Please don't include <linux/compiler-gcc.h> directly, include <linux/compiler.h> instead."
| ^
1 error generated.

As hinted by the error, this is because <sysroot>/include/linux/stddef.h
(a stripped-down version of uapi/include/linux/stddef.h) includes
linux/compiler_types.h directly. However, this gets resolved to
tools/include/linux/compiler_types.h, which is not expected to be
included directly.

To resolve this, I added tools/include/uapi to the include paths when
building objtool. With this trick, linux/stddef.h is resolved to
tools/include/uapi/linux/stddef.h, which doesn't include
linux/compiler_types.h.

Signed-off-by: HONG Yifan <[email protected]>
Signed-off-by: Josh Poimboeuf <[email protected]>

show more ...

objtool/LoongArch: Enable orc to be built

Implement arch-specific init_orc_entry(), write_orc_entry(), reg_name(),
orc_type_name(), print_reg() and orc_print_dump(), then set BUILD_ORC as
y to build

objtool/LoongArch: Enable orc to be built

Implement arch-specific init_orc_entry(), write_orc_entry(), reg_name(),
orc_type_name(), print_reg() and orc_print_dump(), then set BUILD_ORC as
y to build the orc related files.

Co-developed-by: Jinyang He <[email protected]>
Signed-off-by: Jinyang He <[email protected]>
Co-developed-by: Youling Tang <[email protected]>
Signed-off-by: Youling Tang <[email protected]>
Signed-off-by: Tiezhu Yang <[email protected]>
Signed-off-by: Huacai Chen <[email protected]>

show more ...

objtool: Fix HOSTCC flag usage

HOSTCC is always wanted when building objtool. Setting CC to HOSTCC
happens after tools/scripts/Makefile.include is included, meaning
flags (like CFLAGS) are set assum

objtool: Fix HOSTCC flag usage

HOSTCC is always wanted when building objtool. Setting CC to HOSTCC
happens after tools/scripts/Makefile.include is included, meaning
flags (like CFLAGS) are set assuming say CC is gcc, but then it can be
later set to HOSTCC which may be clang. tools/scripts/Makefile.include
is needed for host set up and common macros in objtool's
Makefile. Rather than override the CC variable to HOSTCC, just pass CC
as HOSTCC to the sub-makes of Makefile.build, the libsubcmd builds and
also to the linkage step.

Signed-off-by: Ian Rogers <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Josh Poimboeuf <[email protected]>

show more ...

objtool: Properly support make V=1

The Q variable was being used but never correctly set up. Add the
setting up and use in place of @.

Signed-off-by: Ian Rogers <[email protected]>
Link: https://l

objtool: Properly support make V=1

The Q variable was being used but never correctly set up. Add the
setting up and use in place of @.

Signed-off-by: Ian Rogers <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Josh Poimboeuf <[email protected]>

show more ...

objtool: Install libsubcmd in build

Including from tools/lib can create inadvertent dependencies. Install
libsubcmd in the objtool build and then include the headers from
there.

Signed-off-by: Ian

objtool: Install libsubcmd in build

Including from tools/lib can create inadvertent dependencies. Install
libsubcmd in the objtool build and then include the headers from
there.

Signed-off-by: Ian Rogers <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Josh Poimboeuf <[email protected]>

show more ...

objtool: Remove libsubcmd.a when make clean

The file libsubcmd.a still exists after make clean, remove it.

Signed-off-by: Tiezhu Yang <[email protected]>
Signed-off-by: Josh Poimboeuf <jpoimbo

objtool: Remove libsubcmd.a when make clean

The file libsubcmd.a still exists after make clean, remove it.

Signed-off-by: Tiezhu Yang <[email protected]>
Signed-off-by: Josh Poimboeuf <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

objtool: Remove inat-tables.c when make clean

When build objtool on x86, the generated file inat-tables.c is in
arch/x86/lib instead of arch/x86, use the correct dir to remove it
when make clean.

$

objtool: Remove inat-tables.c when make clean

When build objtool on x86, the generated file inat-tables.c is in
arch/x86/lib instead of arch/x86, use the correct dir to remove it
when make clean.

$ cd tools/objtool
$ make
[...]
GEN arch/x86/lib/inat-tables.c
[...]

Signed-off-by: Tiezhu Yang <[email protected]>
Signed-off-by: Josh Poimboeuf <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

objtool: Ditch subcommands

Objtool has a fairly singular focus. It runs on object files and does
validations and transformations which can be combined in various ways.
The subcommand model has neve

objtool: Ditch subcommands

Objtool has a fairly singular focus. It runs on object files and does
validations and transformations which can be combined in various ways.
The subcommand model has never been a good fit, making it awkward to
combine and remove options.

Remove the "check" and "orc" subcommands in favor of a more traditional
cmdline option model. This makes it much more flexible to use, and
easier to port individual features to other arches.

Signed-off-by: Josh Poimboeuf <[email protected]>
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Reviewed-by: Miroslav Benes <[email protected]>
Link: https://lkml.kernel.org/r/5c61ebf805e90aefc5fa62bc63468ffae53b9df6.1650300597.git.jpoimboe@redhat.com

show more ...

kbuild: Allow kernel installation packaging to override pkg-config

Add HOSTPKG_CONFIG to allow tooling that builds the kernel to override
what pkg-config and parameters are used.

Signed-off-by: Chu

kbuild: Allow kernel installation packaging to override pkg-config

Add HOSTPKG_CONFIG to allow tooling that builds the kernel to override
what pkg-config and parameters are used.

Signed-off-by: Chun-Tse Shao <[email protected]>
Reviewed-by: Nick Desaulniers <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

kbuild: replace $(if A,A,B) with $(or A,B)

$(or ...) is available since GNU Make 3.81, and useful to shorten the
code in some places.

Covert as follows:

$(if A,A,B) --> $(or A,B)

This patch a

kbuild: replace $(if A,A,B) with $(or A,B)

$(or ...) is available since GNU Make 3.81, and useful to shorten the
code in some places.

Covert as follows:

$(if A,A,B) --> $(or A,B)

This patch also converts:

$(if A, A, B) --> $(or A, B)

Strictly speaking, the latter is not an equivalent conversion because
GNU Make keeps spaces after commas; if A is not empty, $(if A, A, B)
expands to " A", while $(or A, B) expands to "A".

Anyway, preceding spaces are not significant in the code hunks I touched.

Signed-off-by: Masahiro Yamada <[email protected]>
Reviewed-by: Nicolas Schier <[email protected]>

show more ...

objtool: Refactor ORC section generation

Decouple ORC entries from instructions. This simplifies the
control/data flow, and is going to make it easier to support alternative
instructions which chan

objtool: Refactor ORC section generation

Decouple ORC entries from instructions. This simplifies the
control/data flow, and is going to make it easier to support alternative
instructions which change the stack layout.

Signed-off-by: Josh Poimboeuf <[email protected]>

show more ...

objtool: Rework header include paths

Currently objtool headers are being included either by their base name
or included via ../ from a parent directory. In case of a base name usage:

#include "war

objtool: Rework header include paths

Currently objtool headers are being included either by their base name
or included via ../ from a parent directory. In case of a base name usage:

#include "warn.h"
#include "arch_elf.h"

it does not make it apparent from which directory the file comes from.
To make it slightly better, and actually to avoid name clashes some arch
specific files have "arch_" suffix. And files from an arch folder have
to revert to including via ../ e.g:
#include "../../elf.h"

With additional architectures support and the code base growth there is
a need for clearer headers naming scheme for multiple reasons:
1. to make it instantly obvious where these files come from (objtool
itself / objtool arch|generic folders / some other external files),
2. to avoid name clashes of objtool arch specific headers, potential
obtool arch generic headers and the system header files (there is
/usr/include/elf.h already),
3. to avoid ../ includes and improve code readability.
4. to give a warm fuzzy feeling to developers who are mostly kernel
developers and are accustomed to linux kernel headers arranging
scheme.

Doesn't this make it instantly obvious where are these files come from?

#include <objtool/warn.h>
#include <arch/elf.h>

And doesn't it look nicer to avoid ugly ../ includes? Which also
guarantees this is elf.h from the objtool and not /usr/include/elf.h.

#include <objtool/elf.h>

This patch defines and implements new objtool headers arranging
scheme. Which is:
- all generic headers go to include/objtool (similar to include/linux)
- all arch headers go to arch/$(SRCARCH)/include/arch (to get arch
prefix). This is similar to linux arch specific "asm/*" headers but we
are not abusing "asm" name and calling it what it is. This also helps
to prevent name clashes (arch is not used in system headers or kernel
exports).

To bring objtool to this state the following things are done:
1. current top level tools/objtool/ headers are moved into
include/objtool/ subdirectory,
2. arch specific headers, currently only arch/x86/include/ are moved into
arch/x86/include/arch/ and were stripped of "arch_" suffix,
3. new -I$(srctree)/tools/objtool/include include path to make
includes like <objtool/warn.h> possible,
4. rewriting file includes,
5. make git not to ignore include/objtool/ subdirectory.

Signed-off-by: Vasily Gorbik <[email protected]>
Acked-by: Peter Zijlstra (Intel) <[email protected]>
Acked-by: Masami Hiramatsu <[email protected]>
Signed-off-by: Josh Poimboeuf <[email protected]>

show more ...

tools: Factor HOSTCC, HOSTLD, HOSTAR definitions

Several Makefiles in tools/ need to define the host toolchain variables.
Move their definition to tools/scripts/Makefile.include

Signed-off-by: Jean

tools: Factor HOSTCC, HOSTLD, HOSTAR definitions

Several Makefiles in tools/ need to define the host toolchain variables.
Move their definition to tools/scripts/Makefile.include

Signed-off-by: Jean-Philippe Brucker <[email protected]>
Signed-off-by: Andrii Nakryiko <[email protected]>
Acked-by: Jiri Olsa <[email protected]>
Acked-by: Rafael J. Wysocki <[email protected]>
Link: https://lore.kernel.org/bpf/[email protected]

show more ...

objtool: Allow nested externs to enable BUILD_BUG()

Currently BUILD_BUG() macro is expanded to smth like the following:
do {
extern void __compiletime_assert_0(void)

objtool: Allow nested externs to enable BUILD_BUG()

Currently BUILD_BUG() macro is expanded to smth like the following:
do {
extern void __compiletime_assert_0(void)
__attribute__((error("BUILD_BUG failed")));
if (!(!(1)))
__compiletime_assert_0();
} while (0);

If used in a function body this obviously would produce build errors
with -Wnested-externs and -Werror.

Build objtool with -Wno-nested-externs to enable BUILD_BUG() usage.

Signed-off-by: Vasily Gorbik <[email protected]>
Signed-off-by: Josh Poimboeuf <[email protected]>

show more ...

objtool: Define 'struct orc_entry' only when needed

Implementation of ORC requires some definitions that are currently
provided by the target architecture headers. Do not depend on these
definitions

objtool: Define 'struct orc_entry' only when needed

Implementation of ORC requires some definitions that are currently
provided by the target architecture headers. Do not depend on these
definitions when the orc subcommand is not implemented.

This avoid requiring arches with no orc implementation to provide dummy
orc definitions.

Signed-off-by: Julien Thierry <[email protected]>
Reviewed-by: Miroslav Benes <[email protected]>
Signed-off-by: Josh Poimboeuf <[email protected]>

show more ...

objtool: Enable compilation of objtool for all architectures

Objtool currently only compiles for x86 architectures. This is
fine as it presently does not support tooling for other
architectures. How

objtool: Enable compilation of objtool for all architectures

Objtool currently only compiles for x86 architectures. This is
fine as it presently does not support tooling for other
architectures. However, we would like to be able to convert other
kernel tools to run as objtool sub commands because they too
process ELF object files. This will allow us to convert tools
such as recordmcount to use objtool's ELF code.

Since much of recordmcount's ELF code is copy-paste code to/from
a variety of other kernel tools (look at modpost for example) this
means that if we can convert recordmcount we can convert more.

We define weak definitions for subcommand entry functions and other weak
definitions for shared functions critical to building existing
subcommands. These return 127 when the command is missing which signify
tools that do not exist on all architectures. In this case the "check"
and "orc" tools do not exist on all architectures so we only add them
for x86. Future changes adding support for "check", to arm64 for
example, can then modify the SUBCMD_CHECK variable when building for
arm64.

Objtool is not currently wired in to KConfig to be built for other
architectures because it's not needed for those architectures and
there are no commands it supports other than those for x86. As more
command support is enabled on various architectures the necessary
KConfig changes can be made (e.g. adding "STACK_VALIDATION") to
trigger building objtool.

[ jpoimboe: remove aliases, add __weak macro, add error messages ]

Cc: Julien Thierry <[email protected]>
Signed-off-by: Matt Helsley <[email protected]>
Signed-off-by: Josh Poimboeuf <[email protected]>

show more ...

objtool: Split out arch-specific CFI definitions

Some CFI definitions used by generic objtool code have no reason to vary
from one architecture to another. Keep those definitions in generic
code an

objtool: Split out arch-specific CFI definitions

Some CFI definitions used by generic objtool code have no reason to vary
from one architecture to another. Keep those definitions in generic
code and move the arch-specific ones to a new arch-specific header.

Signed-off-by: Julien Thierry <[email protected]>
Acked-by: Peter Zijlstra (Intel) <[email protected]>
Reviewed-by: Miroslav Benes <[email protected]>
Signed-off-by: Josh Poimboeuf <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>

show more ...

objtool: Always do header sync check

Currently, the check of tools files against kernel equivalent is only
done after every object file has been built. This means one might fix
build issues against

objtool: Always do header sync check

Currently, the check of tools files against kernel equivalent is only
done after every object file has been built. This means one might fix
build issues against outdated headers without seeing a warning about
this.

Check headers before any object is built. Also, make it part of a
FORCE'd recipe so every attempt to build objtool will report the
outdated headers (if any).

Signed-off-by: Julien Thierry <[email protected]>
Acked-by: Peter Zijlstra (Intel) <[email protected]>
Reviewed-by: Miroslav Benes <[email protected]>
Signed-off-by: Josh Poimboeuf <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>

show more ...

kbuild: support LLVM=1 to switch the default tools to Clang/LLVM

As Documentation/kbuild/llvm.rst implies, building the kernel with a
full set of LLVM tools gets very verbose and unwieldy.

Provide

kbuild: support LLVM=1 to switch the default tools to Clang/LLVM

As Documentation/kbuild/llvm.rst implies, building the kernel with a
full set of LLVM tools gets very verbose and unwieldy.

Provide a single switch LLVM=1 to use Clang and LLVM tools instead
of GCC and Binutils. You can pass it from the command line or as an
environment variable.

Please note LLVM=1 does not turn on the integrated assembler. You need
to pass LLVM_IAS=1 to use it. When the upstream kernel is ready for the
integrated assembler, I think we can make it default.

We discussed what we need, and we agreed to go with a simple boolean
flag that switches both target and host tools:

https://lkml.org/lkml/2020/3/28/494
https://lkml.org/lkml/2020/4/3/43

Some items discussed, but not adopted:

- LLVM_DIR

When multiple versions of LLVM are installed, I just thought supporting
LLVM_DIR=/path/to/my/llvm/bin/ might be useful.

CC = $(LLVM_DIR)clang
LD = $(LLVM_DIR)ld.lld
...

However, we can handle this by modifying PATH. So, we decided to not do
this.

- LLVM_SUFFIX

Some distributions (e.g. Debian) package specific versions of LLVM with
naming conventions that use the version as a suffix.

CC = clang$(LLVM_SUFFIX)
LD = ld.lld(LLVM_SUFFIX)
...

will allow a user to pass LLVM_SUFFIX=-11 to use clang-11 etc.,
but the suffixed versions in /usr/bin/ are symlinks to binaries in
/usr/lib/llvm-#/bin/, so this can also be handled by PATH.

Signed-off-by: Masahiro Yamada <[email protected]>
Reviewed-by: Nathan Chancellor <[email protected]>
Tested-by: Nathan Chancellor <[email protected]> # build
Tested-by: Nick Desaulniers <[email protected]>
Reviewed-by: Nick Desaulniers <[email protected]>

show more ...

objtool: Fix ARCH=x86_64 build error

Building objtool with ARCH=x86_64 fails with:

$make ARCH=x86_64 -C tools/objtool
...
CC arch/x86/decode.o
arch/x86/decode.c:10:22: fatal err

objtool: Fix ARCH=x86_64 build error

Building objtool with ARCH=x86_64 fails with:

$make ARCH=x86_64 -C tools/objtool
...
CC arch/x86/decode.o
arch/x86/decode.c:10:22: fatal error: asm/insn.h: No such file or directory
#include <asm/insn.h>
^
compilation terminated.
mv: cannot stat ‘arch/x86/.decode.o.tmp’: No such file or directory
make[2]: *** [arch/x86/decode.o] Error 1
...

The root cause is that the command-line variable 'ARCH' cannot be
overridden. It can be replaced by 'SRCARCH', which is defined in
'tools/scripts/Makefile.arch'.

Signed-off-by: Shile Zhang <[email protected]>
Signed-off-by: Josh Poimboeuf <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
Reviewed-by: Kamalesh Babulal <[email protected]>
Link: https://lore.kernel.org/r/d5d11370ae116df6c653493acd300ec3d7f5e925.1579543924.git.jpoimboe@redhat.com

show more ...

objtool: Clobber user CFLAGS variable

If the build user has the CFLAGS variable set in their environment,
objtool blindly appends to it, which can cause unexpected behavior.

Clobber CFLAGS to ensur

objtool: Clobber user CFLAGS variable

If the build user has the CFLAGS variable set in their environment,
objtool blindly appends to it, which can cause unexpected behavior.

Clobber CFLAGS to ensure consistent objtool compilation behavior.

Reported-by: Valdis Kletnieks <[email protected]>
Tested-by: Valdis Kletnieks <[email protected]>
Signed-off-by: Josh Poimboeuf <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Link: https://lkml.kernel.org/r/83a276df209962e6058fcb6c615eef9d401c21bc.1567121311.git.jpoimboe@redhat.com
Signed-off-by: Ingo Molnar <[email protected]>

show more ...

objtool: Move x86 insn decoder to a common location

The kernel tree has three identical copies of the x86 instruction
decoder. Two of them are in the tools subdir.

The tools subdir is supposed to

objtool: Move x86 insn decoder to a common location

The kernel tree has three identical copies of the x86 instruction
decoder. Two of them are in the tools subdir.

The tools subdir is supposed to be completely standalone and separate
from the kernel. So having at least one copy of the kernel decoder in
the tools subdir is unavoidable. However, we don't need *two* of them.

Move objtool's copy of the decoder to a shared location, so that perf
will also be able to use it.

Signed-off-by: Josh Poimboeuf <[email protected]>
Reviewed-by: Masami Hiramatsu <[email protected]>
Acked-by: Peter Zijlstra (Intel) <[email protected]>
Cc: Adrian Hunter <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: [email protected]
Link: http://lore.kernel.org/lkml/55b486b88f6bcd0c9a2a04b34f964860c8390ca8.1567118001.git.jpoimboe@redhat.com
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>

show more ...

objtool: Allow AR to be overridden with HOSTAR

Currently, this Makefile hardcodes GNU ar, meaning that if it is not
available, there is no way to supply a different one and the build will
fail.

$

objtool: Allow AR to be overridden with HOSTAR

Currently, this Makefile hardcodes GNU ar, meaning that if it is not
available, there is no way to supply a different one and the build will
fail.

$ make AR=llvm-ar CC=clang LD=ld.lld HOSTAR=llvm-ar HOSTCC=clang \
HOSTLD=ld.lld HOSTLDFLAGS=-fuse-ld=lld defconfig modules_prepare
...
AR /out/tools/objtool/libsubcmd.a
/bin/sh: 1: ar: not found
...

Follow the logic of HOST{CC,LD} and allow the user to specify a
different ar tool via HOSTAR (which is used elsewhere in other
tools/ Makefiles).

Signed-off-by: Nathan Chancellor <[email protected]>
Signed-off-by: Josh Poimboeuf <[email protected]>
Reviewed-by: Nick Desaulniers <[email protected]>
Reviewed-by: Mukesh Ojha <[email protected]>
Cc: <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Link: http://lkml.kernel.org/r/80822a9353926c38fd7a152991c6292491a9d0e8.1558028966.git.jpoimboe@redhat.com
Link: https://github.com/ClangBuiltLinux/linux/issues/481
Signed-off-by: Ingo Molnar <[email protected]>

show more ...