Add RapidIO-specific modalias generation to enable udev notifications
about RapidIO-specific events.

The RapidIO modalias string format is shown below:

"rapidio:vNNNNdNNNNavNNNNadNNNN"

Where:
v  - Device Vendor ID (16 bit),
d  - Device ID (16 bit),
av - Assembly Vendor ID (16 bit),
ad - Assembly ID (16 bit),

as they are reported in corresponding Capability Registers (CARs)
of each RapidIO device.
Signed-off-by: NAlexandre Bounine <alexandre.bounine@idt.com>
Cc: Matt Porter <mporter@kernel.crashing.org>
Cc: Li Yang <leoli@freescale.com>
Cc: Kumar Gala <galak@kernel.crashing.org>
Cc: Andre van Herk <andre.van.herk@Prodrive.nl>
Cc: Micha Nelissen <micha.nelissen@Prodrive.nl>
Cc: Stef van Os <stef.van.os@Prodrive.nl>
Cc: Jean Delvare <jdelvare@suse.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Add a file to cache the CamelCase variables found by <commit> to reduce
the time it takes to scan the include/ directory.

Filename is '.checkpatch-camelcase.<commit>' and it is created only only
if a .git directory exists.

<commit> is determined by the last non-merge commit id in the
include/ path.

Reduces checkpatch run time by ~12 cpu seconds on my little netbook.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The current $logFunction regular expression allows names like dev_warn,
e_dbg, netdev_info, etc, but some log functions are now written like
e_dev_warn, so allow 1 or 2 word blocks with an underscore before the
logging level.
Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
Tested-by: NAaron Brown <aaron.f.brown@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

When using --strict, CamelCase uses are described with CHECK: messages.
These CamelCase uses may be acceptable and should not generate these
messages when the variable is already defined in a file from the
include/...  path.

So, change checkpatch to read all the .h files in include/...  and look
for preexisting CamelCase #defines, typedefs and function prototypes.

Add these to the existing camelcase hash so that any uses in the patch or
file can be ignored.

There are currently ~3500 files in include/.  It takes about 10 cpu
seconds on my little netbook to grep for and preseed these existing uses.

That's about 4x the time for a similar git grep.

This preseeding is only done once when using --strict and only when there
is a CamelCase use found.

If a .git directory is found, it uses 'git ls-files include' If not, it
uses 'find $root/include -name "*.h"
Signed-off-by: NJoe Perches <joe@perches.com>
Cc: Andy Whitcroft <apw@canonical.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Many existing variable names use SI like variants that should be otherwise
obvious and acceptable.

Whitelist them from the CamelCase message.
Signed-off-by: NJoe Perches <joe@perches.com>
Suggested-by: NPhil Carmody <phil.carmody@partner.samsung.com>
Acked-by: NPhil Carmody <phil.carmody@partner.samsung.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Moving this test allows the --fix option to work better.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Some patches have simple defects in whitespace and formatting that
checkpatch could correct automatically.  Attempt to do so.

Add a --fix option to create a "<inputfile>.EXPERIMENTAL-checkpatch-fixes"
file that tries to use normal kernel style for some of these formatting
errors.

Add warnings against using this file without verifying the changes.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Some false positives exist on this test.

For instance:
	*va_arg(args, signed char *) = val.s;
or
	memset(foo, 0, sizeof(struct bar *) * baz));

Ignore lines that have an arithmetic operator or assignment
after what appears to be a cast to a pointer "(foo *)".

Add $Arithmetic convenience variable.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Comparing to true or false is error prone.

Add tests for the various forms of (foo == true) && (false != bar)
that are only reported with --strict.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Check to make sure the blank lines aren't comment lines like:

  bool foo(bool bar)
  {
	/* Don't warn on a leading comment */
	return !bar;
	/* Don't warn on a trailing comment either */
  }
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Figure out first how to determine if this is in a struct declaration or in
a function body before enabling this.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Allow "#define foo struct.member" without bleating a warning.

This also allows "#define foo bar.baz->qux" and so on.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Comparing get_jiffies_64() is almost always wrong and time_before64 and
time_after64 should be used instead.

Warn on any comparison to get_jiffies_64().
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Comparing jiffies is almost always wrong and time_before and time_after
should be used instead.

Warn on any comparison to jiffies.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Some block comments in network are written as:

	/* block comment line 1
	   block comment line 2
	 */

Emit a warning on the "block comment line 2" because it should be

	/* block comment line 1
	 * block comment line 2
	 */

This warning is only emitted on the second line of a block comment.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Show the first line of the comment after a line with just /* to better
show where the defective comment style is in the file.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Commit be987d9f ("checkpatch: improve CamelCase test for Page") added
it but it shouldn't be there.  Must have been my fault.

Make sure that the tested variable doesn't contain a constant.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Add another test for memory allocation style to follow
Documentation/CodingStyle:

		Chapter 14: Allocating memory

The preferred form for passing a size of a struct is the following:

	p = kmalloc(sizeof(*p), ...);
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The gcc extension for binary constants that start with 0b is only
supported with gcc version 4.3 or higher.

The kernel can still be compiled with earlier versions of gcc, so have
checkpatch emit a warning for these constants.

Restructure checkpatch's constant finding code a bit to support finding
these binary constants.
Signed-off-by: NJoe Perches <joe@perches.com>
Suggested-by: NAndrew Morton <akpm@linux-foundation.org>
Cc: Andy Whitcroft <apw@canonical.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Do not bleat a message on nominally acceptable CamelCase uses that are
separated by an _ like drm_core_has_MTRR.

CamelCase tests are also a bit noisy against certain types of code
acceptable to some kernel developers.

Make the test applicable only with --strict.
Signed-off-by: NJoe Perches <joe@perches.com>
Cc: Andy Whitcroft <apw@canonical.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Previously, the #line parsing regex ended with ({WS}+[0-9]+)?. The {WS}
could match line-break characters. If the #line directive did not contain
the optional flags field at the end, this could cause any integer data on
the next line to be consumed as part of the #line directive parsing. This
could cause syntax errors (i.e. #line parsing consuming the leading 0
from a hex literal 0x1234, leaving x1234 to be parsed as cell data,
which is a syntax error), or invalid compilation results (i.e. simply
consuming literal 1234 as part of the #line processing, thus removing it
from the cell data).

Fix this by replacing {WS} with [ \t] so that it can't match line-breaks.

Convert all instances of {WS}, even though the other instances should be
irrelevant for any well-formed #line directive. This is done for
consistency and ultimate safety.

[Cherry picked from DTC commit a1ee6f068e1c8dbc62873645037a353d7852d5cc]
Reported-by: NIan Campbell <Ian.Campbell@citrix.com>
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Acked-by: NDavid Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

This patch merely updates the generated dtc parser and lexer files to
the output generated by Bison 2.5. The previous versions were generated
from version 2.4.1. The only reason for this commit is to minimize the
diff on the next commit which fixes a bug in the DTC #line directive
parsing. Otherwise the Bison changes would be intermingled with the
functional changes.
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

Various temporary files used when building DTB files were not suffixed with
.tmp and therefore were not cleaned up by "make clean".
Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
Reviewed-by: NStephen Warren <swarren@nvidia.com>
Tested-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NGrant Likely <grant.likely@linaro.org>

As is done for other architectures, sort the exception table at
build-time rather than during boot.

Since sortextable appears to be a standalone C program relying on the
host elf.h to provide EM_AARCH64, I've had to add a conditional check in
order to allow cross-compilation on machines that aren't running a
bleeding-edge libc-dev.
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>

menu_add_prop() applies upper menus' visibilities to actual prompts
by AND-ing the prompts visibilities with the upper menus ones.

This creates a further reference to the menu's visibilities and when
the expression reduction functions do their work, they may remove or
modify expressions that have multiple references, thus causing
unpredictable side-effects.

The following example Kconfig constructs a case where this causes
problems: a menu and a prompt which's visibilities depend on the same
symbol.  When invoking mconf with this Kconfig and pressing "Z" we
see a problem caused by a free'd expression still referenced by the
menu's visibility:

------------------------------------------------------------------------
mainmenu "Kconfig Testing Configuration"

config VISIBLE
	def_bool n

config Placeholder
	bool "Place holder"

menu "Invisible"
	visible if VISIBLE

config TEST_VAR
	bool "Test option" if VISIBLE

endmenu
------------------------------------------------------------------------

This patch fixes this problem by creating copies of the menu's
visibility expressions before AND-ing them with the prompt's one.
Signed-off-by: NDirk Gouders <dirk@gouders.net>
[yann.morin.1998@free.fr: move variable into its block-scope,
                          keep lines <80 chars, typo]
Tested-by: N"Yann E. MORIN" <yann.morin.1998@free.fr>
Reviewed-by: N"Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: N"Yann E. MORIN" <yann.morin.1998@free.fr>

When entering an empty dialog, using the movement keys resulted in
unexpected characters beeing displayed, other keys like "z" and "h"
did not work as expected.

This patch handles the movement keys as well as other keys, especially
"z", "h" and "/".
Signed-off-by: NDirk Gouders <dirk@gouders.net>
[yann.morin.1998@free.fr: keep lines <80 chars, so reorder test]
Tested-by: N"Yann E. MORIN" <yann.morin.1998@free.fr>
Reviewed-by: N"Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: N"Yann E. MORIN" <yann.morin.1998@free.fr>

In commit b40b25ff (kbuild: always run gcc -E on *.dts, remove cmd_dtc_cpp),
dts building was changed to always use the C preprocessor. This meant
that the .dts file passed to dtc is not the original, but the
preprocessed one.

When compiling with a separate build directory (i.e., with O=), this
preprocessed file will not live in the same directory as the original.
When the .dts file includes .dtsi files, dtc will look for them in the
build directory, not in the source directory and compilation will fail.

The commit referenced above tried to fix this by passing arch/*/boot/dts
as an include path to dtc. However, for mips, the .dts files are not in
this directory, so dts compilation on mips breaks for some targets.

Instead of hardcoding this particular include path, this commit just
uses the directory of the .dts file that is being compiled, which
effectively restores the previous behaviour wrt includes. For most .dts
files, this path is just the same as the previous hardcoded
arch/*/boot/dts path.

This was tested on a mips (rt3052) and an arm (bcm2835) target.
Signed-off-by: NMatthijs Kooijman <matthijs@stdin.nl>
Reviewed-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NMichal Marek <mmarek@suse.cz>

When --*-after options are used, two parameters are parsed from the
command-line before the adequate function is called:
  - the `before' option, after which the new option will be inserted,
  - the name of the option to enable/disable/modularise.

With the short version of --*-after options (namely -E, -D, -M), the
parsing step is not performed which leads to processing unset variables.

Add options -E, -D, -M to the test that triggers assignment of parameters
for --*-after options.
Signed-off-by: NClement Chauplannaz <chauplac@gmail.com>
Acked-by: NAndi Kleen <ak@linux.intel.com>
Signed-off-by: NYann E. MORIN <yann.morin.1998@free.fr>

Commit 65013203 dropped the rpm spec as a
prerequisite for the binrpm-pkg target but forgot to update $< usage,
which causes the rule to break.

This commit fixes that by replacing $< with the spec name.
Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>
Signed-off-by: NMichal Marek <mmarek@suse.cz>

Searching for PPC_EFIKA results in a segmentation fault, and it's
because get_symbol_prop() returns NULL.

In this case CONFIG_PPC_EFIKA is defined in arch/powerpc/platforms/
52xx/Kconfig, so it won't be parsed if ARCH!=PPC, but menuconfig knows
this symbol when it parses sound/soc/fsl/Kconfig:

    config SND_MPC52xx_SOC_EFIKA
        tristate "SoC AC97 Audio support for bbplan Efika and STAC9766"
        depends on PPC_EFIKA

This bug was introduced by commit bcdedcc1 ("menuconfig: print more
info for symbol without prompts").
Reported-and-tested-by: NBorislav Petkov <bp@alien8.de>
Signed-off-by: NLi Zefan <lizefan@huawei.com>
Tested-by: NLibo Chen <libo.chen@huawei.com>
Reviewed-by: N"Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: NMichal Marek <mmarek@suse.cz>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Make sure devicetable-offsets.h is cleaned in the scripts/mod directory
Signed-off-by: NAndreas Schwab <schwab@linux-m68k.org>
Tested-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NMichal Marek <mmarek@suse.cz>

When we search a config symbol, if it has no prompt the position of this
symbol in the Kconfig file and it's dependencies are not printed.  This
can be inconvenient, especially when it's set to n and we want to find out
why.

the following is an example:

before:

Symbol: GENERIC_SMP_IDLE_THREAD [=y]
Type  : boolean
  Selected by: X86 [=y]

after:

Symbol: GENERIC_SMP_IDLE_THREAD [=y]
Type  : boolean
  Defined at arch/Kconfig:213
  Selected by: X86 [=y]
Signed-off-by: NWeng Meiling <wengmeiling.weng@huawei.com>
Signed-off-by: NLibo Chen <libo.chen@huawei.com>
Cc: Michal Marek <mmarek@suse.cz>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

As people started using Suggested-by as standard signature, adding
"Suggested-by" to the standard signature so that checkpatch won't
generate warning when Suggested-by is used in patch signature
Signed-off-by: NMugunthan V N <mugunthanvnm@ti.com>
Cc: Andy Whitcroft <apw@canonical.com>
Cc: Joe Perches <joe@perches.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This check was intended to catch extra newlines at the end of a function
definition, but it would trigger on any closing brace, including those
of inline functions and macro definitions, triggering false positives.
Now, only closing braces on a line by themselves trigger this check.

Tested with:

$ cat test.h
/* test.h - Test file */

static inline int foo(void) { return 0; }

static inline int bar(void)
{
        return 1;

}

$ ./scripts/checkpatch.pl --strict -f test.h # Before this commit
CHECK: Blank lines aren't necessary before a close brace '}'
+
+static inline int foo(void) { return 0; }

CHECK: Blank lines aren't necessary before a close brace '}'
+
+}

total: 0 errors, 0 warnings, 2 checks, 9 lines checked

$ ./scripts/checkpatch.pl --strict -f test.h # After this commit
CHECK: Blank lines aren't necessary before a close brace '}'
+
+}

total: 0 errors, 0 warnings, 1 checks, 9 lines checked
Signed-off-by: NMatthijs Kooijman <matthijs@stdin.nl>
Cc: Andy Whitcroft <apw@canonical.com>
Acked-by: NJoe Perches <joe@perches.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Make space before semicolon a warning instead of a --strict CHK test.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Complain about files with an executable bit set that are not in a scripts/
directory and are not type .pl, .py, .awk, or .sh

Based on an initial patch from Stephen.
Signed-off-by: NJoe Perches <joe@perches.com>
Acked-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Add a check for seq_printf use with a constant format without additional
arguments.  Suggest seq_puts instead.
Signed-off-by: NJoe Perches <joe@perches.com>
Suggested-by: NBjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

On Thu, 2013-03-14 at 13:30 +0000, David Woodhouse wrote:
> If krealloc() returns NULL, it *doesn't* free the original. So any code
> of the form 'foo = krealloc(foo, …);' is almost certainly a bug.

So add a check for it to checkpatch.
Signed-off-by: NJoe Perches <joe@perches.com>
Tested-by: NGuenter Roeck <linux@roeck-us.net>
Acked-by: NGuenter Roeck <linux@roeck-us.net>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Andy Whitcroft <apw@canonical.com>
Cc: Jean Delvare <khali@linux-fr.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Create a new N: entry type in MAINTAINERS which performs a regex match
against filenames; either those extracted from patch +++ or --- lines,
or those specified on the command-line using the -f option.

This provides the same benefits as using a K: regex option to match a
set of filenames (see commit eb90d085 "get_maintainer: allow
keywords to match filenames"), but without the disadvantage that
"random" file content, such as comments, will ever match the regex.
Hence, revert most of that commit.

Switch the Tegra entry from using K: to N:

[akpm@linux-foundation.org: fix typo in docs, per Marcin]
Reported-by: NMarcin Slusarz <marcin.slusarz@gmail.com>
Suggested-by: NJoe Perches <joe@perches.com>
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Acked-by: NJoe Perches <joe@perches.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

It can accidentally happen that the faulting insn (the exact instruction
bytes) is repeated a little further on in the trace.  This causes that
same instruction to be tagged twice, see example below.

What we want to do, however, is to track back from the end of the whole
disassembly so many lines as the slice which starts with the faulting
instruction is long.  This leads us to the actual faulting instruction
and *then* we tag it.

While we're at it, we can drop the sed "g" flag because we address only
this one line.

Also, if we point to an instruction which changes decoding depending on
the slice being objdumped, like a Jcc insn, for example, we do not even
tag it as a faulting instruction because the instruction decode changes
in the second slice but we use that second format as a regex on the
fsrst disassembled buffer and more often than not that instruction
doesn't match.

Again, simply tag the line which is deduced from the original "<>"
marking we've received from the kernel.

This also solves the pathologic issue of multiple tagging like this:

  29:*  0f 0b                   ud2         <-- trapping instruction
  2b:*  0f 0b                   ud2         <-- trapping instruction
  2d:*  0f 0b                   ud2         <-- trapping instruction

Double tagging example:

Code: 34 dd 40 30 ad 81 48 c7 c0 80 f6 00 00 48 8b 3c 30 48 01 c6 b8 ff ff ff ff 48 8d 57 f0 48 39 f7 74 2f 49 8b 4c 24 08 48 8b 47 f0 <48> 39 48 08 75 0e eb 2a 66 90 48 8b 40 f0 48 39 48 08 74 1e 48
All code
========
   0:   34 dd                   xor    $0xdd,%al
   2:   40 30 ad 81 48 c7 c0    xor    %bpl,-0x3f38b77f(%rbp)
   9:   80 f6 00                xor    $0x0,%dh
   c:   00 48 8b                add    %cl,-0x75(%rax)
   f:   3c 30                   cmp    $0x30,%al
  11:   48 01 c6                add    %rax,%rsi
  14:   b8 ff ff ff ff          mov    $0xffffffff,%eax
  19:   48 8d 57 f0             lea    -0x10(%rdi),%rdx
  1d:   48 39 f7                cmp    %rsi,%rdi
  20:   74 2f                   je     0x51
  22:   49 8b 4c 24 08          mov    0x8(%r12),%rcx
  27:   48 8b 47 f0             mov    -0x10(%rdi),%rax
  2b:*  48 39 48 08             cmp    %rcx,0x8(%rax)     <-- trapping instruction
  2f:   75 0e                   jne    0x3f
  31:   eb 2a                   jmp    0x5d
  33:   66 90                   xchg   %ax,%ax
  35:   48 8b 40 f0             mov    -0x10(%rax),%rax
  39:*  48 39 48 08             cmp    %rcx,0x8(%rax)     <-- trapping instruction
  3d:   74 1e                   je     0x5d
  3f:   48                      rex.W
Signed-off-by: NBorislav Petkov <bp@suse.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>