linux-toradex.git/arch/x86/kernel/asm-offsets_64.c, branch v4.4.77

x86/asm/entry: (Re-)rename __NR_entry_INT80_compat_max to __NR_syscall_compat_max

2015-06-08T21:43:38+00:00

Brian Gerst noticed that I did a weird rename in the following commit:

   b2502b418e63 ("x86/asm/entry: Untangle 'system_call' into two entry points: entry_SYSCALL_64 and entry_INT80_32")

which renamed __NR_ia32_syscall_max to __NR_entry_INT80_compat_max.

Now the original name was a misnomer, but the new one is a misnomer as well,
as all the 32-bit compat syscall entry points (sysenter, syscall) share the
system call table, not just the INT80 based one.

Rename it to __NR_syscall_compat_max.

Reported-by: Brian Gerst 
Cc: Andrew Morton 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar

x86/asm/entry: Rename compat syscall entry points

2015-06-08T06:47:36+00:00

Rename the following system call entry points:

	ia32_cstar_target       -> entry_SYSCALL_compat
	ia32_syscall            -> entry_INT80_compat

The generic naming scheme for x86 system call entry points is:

	entry_MNEMONIC_qualifier

where 'qualifier' is one of _32, _64 or _compat.

Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar

x86/asm: Merge common 32-bit values in asm-offsets.c

2015-04-15T09:28:49+00:00

Merge common values for 32-bit native and compat.

Signed-off-by: Brian Gerst 
Acked-by: Andy Lutomirski 
Cc: Andy Lutomirski 
Cc: Denys Vlasenko 
Link: http://lkml.kernel.org/r/1428844486-6638-1-git-send-email-brgerst@gmail.com
Signed-off-by: Ingo Molnar

x86/asm/entry/64/compat: Change the 32-bit sysenter code to use sp0

2015-03-06T07:32:58+00:00

The ia32 sysenter code loaded the top of the kernel stack into
rsp by loading kernel_stack and then adjusting it.  It can be
simplified to just read sp0 directly.

This requires the addition of a new asm-offsets entry for sp0.

Signed-off-by: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Linus Torvalds 
Cc: Oleg Nesterov 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/88ff9006163d296a0665338585c36d9bfb85235d.1425611534.git.luto@amacapital.net
Signed-off-by: Ingo Molnar

Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2014-12-14T19:51:50+00:00

Pull x86 fixes from Ingo Molnar:
 "Misc fixes (mainly Andy's TLS fixes), plus a cleanup"

* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/tls: Disallow unusual TLS segments
  x86/tls: Validate TLS entries to protect espfix
  MAINTAINERS: Add me as x86 VDSO submaintainer
  x86/asm: Unify segment selector defines
  x86/asm: Guard against building the 32/64-bit versions of the asm-offsets*.c file directly
  x86_64, switch_to(): Load TLS descriptors before switching DS and ES
  x86/mm: Use min() instead of min_t() in the e820 printout code
  x86/mm: Fix zone ranges boot printout
  x86/doc: Update documentation after file shuffling

x86/asm: Guard against building the 32/64-bit versions of the asm-offsets*.c file directly

2014-12-11T10:43:56+00:00

Sometimes it is helpful to build a kernel compilation unit
directly, i.e.:

  make .../.i

in order to look at compiler output.

Since asm-offsets_{32,64}.c are included by asm-offsets.c and
building them directly doesn't evaluate the macros used (thus
making the preprocessor output not very useful), error out when
an attempt is made to build them. Issue a hint for the user to
build asm-offsets.c instead.

Suggested-by: Michael Matz 
Signed-off-by: Borislav Petkov 
Cc: Michal Marek 
Cc: Linus Torvalds 
Link: http://lkml.kernel.org/r/1418139917-12722-1-git-send-email-bp@alien8.de
Signed-off-by: Ingo Molnar

x86/asm: Fix typo in arch/x86/kernel/asm_offset_64.c

2014-10-28T10:24:17+00:00

Drop double entry for pt_regs_bx.

This seems to be a typo - resulting in a double entry in the
generated include/generated/asm-offsets.h, which is not necessary.

Build-tested and booted on x86 64 box to make sure it was not
doing any strange magic.... after all it was in the kernel in
this form for almost 10 years.

Signed-off-by: Nicholas Mc Guire 
Cc: Jan Beulich 
Cc: Andy Lutomirski 
Cc: Linus Torvalds 
Link: http://lkml.kernel.org/r/20141027172805.GA19760@opentech.at
Signed-off-by: Ingo Molnar

x86, gdt, hibernate: Store/load GDT for hibernate path.

2013-05-02T18:27:35+00:00

The git commite7a5cd063c7b4c58417f674821d63f5eb6747e37
("x86-64, gdt: Store/load GDT for ACPI S3 or hibernate/resume path
is not needed.") assumes that for the hibernate path the booting
kernel and the resuming kernel MUST be the same. That is certainly
the case for a 32-bit kernel (see check_image_kernel and
CONFIG_ARCH_HIBERNATION_HEADER config option).

However for 64-bit kernels it is OK to have a different kernel
version (and size of the image) of the booting and resuming kernels.
Hence the above mentioned git commit introduces an regression.

This patch fixes it by introducing a 'struct desc_ptr gdt_desc'
back in the 'struct saved_context'. However instead of having in the
'save_processor_state' and 'restore_processor_state' the
store/load_gdt calls, we are only saving the GDT in the
save_processor_state.

For the restore path the lgdt operation is done in
hibernate_asm_[32|64].S in the 'restore_registers' path.

The apt reader of this description will recognize that only 64-bit
kernels need this treatment, not 32-bit. This patch adds the logic
in the 32-bit path to be more similar to 64-bit so that in the future
the unification process can take advantage of this.

[ hpa: this also reverts an inadvertent on-disk format change ]

Suggested-by: "H. Peter Anvin" 
Acked-by: "Rafael J. Wysocki" 
Signed-off-by: Konrad Rzeszutek Wilk 
Link: http://lkml.kernel.org/r/1367459610-9656-2-git-send-email-konrad.wilk@oracle.com
Signed-off-by: H. Peter Anvin

x32: If configured, add x32 system calls to system call tables

2012-02-20T20:52:06+00:00

If CONFIG_X86_X32_ABI is defined, add the x32 system calls to the
system call tables.

Signed-off-by: H. Peter Anvin

x32: Add x32 system calls to syscall/syscall_64.tbl

2012-02-20T20:48:49+00:00

Split the 64-bit system calls into "64" (64-bit only) and "common"
(64-bit or x32) and add the x32 system call numbers.

Signed-off-by: H. Peter Anvin