/* * Copied from the kernel sources to tools/: * * Memory barrier definitions. This is based on information published * in the Processor Abstraction Layer and the System Abstraction Layer * manual. * * Copyright (C) 1998-2003 Hewlett-Packard Co * David Mosberger-Tang * Copyright (C) 1999 Asit Mallick * Copyright (C) 1999 Don Dugger */ #ifndef _TOOLS_LINUX_ASM_IA64_BARRIER_H #define _TOOLS_LINUX_ASM_IA64_BARRIER_H #include /* * Macros to force memory ordering. In these descriptions, "previous" * and "subsequent" refer to program order; "visible" means that all * architecturally visible effects of a memory access have occurred * (at a minimum, this means the memory has been read or written). * * wmb(): Guarantees that all preceding stores to memory- * like regions are visible before any subsequent * stores and that all following stores will be * visible only after all previous stores. * rmb(): Like wmb(), but for reads. * mb(): wmb()/rmb() combo, i.e., all previous memory * accesses are visible before all subsequent * accesses and vice versa. This is also known as * a "fence." * * Note: "mb()" and its variants cannot be used as a fence to order * accesses to memory mapped I/O registers. For that, mf.a needs to * be used. However, we don't want to always use mf.a because (a) * it's (presumably) much slower than mf and (b) mf.a is supported for * sequential memory pages only. */ /* XXX From arch/ia64/include/uapi/asm/gcc_intrin.h */ #define ia64_mf() asm volatile ("mf" ::: "memory") #define mb() ia64_mf() #define rmb() mb() #define wmb() mb() #endif /* _TOOLS_LINUX_ASM_IA64_BARRIER_H */ it.cgi/linux/net-next.git/tree/include/crypto/internal/scompress.h?id=ab78c1d286df46ddc7aeaef2c22e27b7ec061ecc'>treecommitdiff
'>3
AgeCommit message (Expand)AuthorFilesLines
space:
mode:
authorJiri Slaby <jslaby@suse.cz>2017-01-18 14:29:21 +0100
committerIngo Molnar <mingo@kernel.org>2017-01-19 08:39:44 +0100
commitb5b46c4740aed1538544f0fa849c5b76c7823469 (patch)
tree125e7aced4835bad6f6a0c0d02d012f333caf922 /tools/testing/selftests/ptp
parentfa19a769f82fb9a5ca000b83cacd13fcaeda51ac (diff)
objtool: Fix IRET's opcode
The IRET opcode is 0xcf according to the Intel manual and also to objdump of my vmlinux: 1ea8: 48 cf iretq Fix the opcode in arch_decode_instruction(). The previous value (0xc5) seems to correspond to LDS. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Acked-by: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20170118132921.19319-1-jslaby@suse.cz Signed-off-by: Ingo Molnar <mingo@kernel.org>
Diffstat (limited to 'tools/testing/selftests/ptp')