linux-stable.git/arch/ia64, branch linux-3.16.y Linux kernel stable tree arch/ia64: Define early_memunmap() 2020-05-22T20:19:25+00:00 Daniel Kiper daniel.kiper@oracle.com 2014-06-30T17:52:55+00:00 5a6db48462743eb24beb3c9193f9bdda6e3d50a7 commit 4fa62481e231111373418f0d95dd1f24f6e83321 upstream. This is odd to use early_iounmap() function do tear down mapping created by early_memremap() function, even if it works right now, because they belong to different set of functions. The former is I/O related function and the later is memory related. So, create early_memunmap() macro which in real is early_iounmap(). This thing will help to not confuse code readers longer by mixing functions from different classes. EFI patches following this patch uses that functionality. Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com> Cc: Tony Luck <tony.luck@intel.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk> 
commit 4fa62481e231111373418f0d95dd1f24f6e83321 upstream.

This is odd to use early_iounmap() function do tear down mapping
created by early_memremap() function, even if it works right now,
because they belong to different set of functions. The former is
I/O related function and the later is memory related. So, create
early_memunmap() macro which in real is early_iounmap(). This
thing will help to not confuse code readers longer by mixing
functions from different classes.

EFI patches following this patch uses that functionality.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Cc: Tony Luck <tony.luck@intel.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
ia64: Use get_signal() signal_setup_done() 2019-05-02T20:41:43+00:00 Richard Weinberger richard@nod.at 2013-10-07T21:07:51+00:00 6062ad89ccca9e16339849ffd04f051eacd5e7a6 commit 98c20309b97fc30001adf643cf876125f334fd8a upstream. Use the more generic functions get_signal() signal_setup_done() for signal delivery. This inverts also the return codes of force_sigsegv_info() and setup_frame() to follow the kernel convention. Signed-off-by: Richard Weinberger <richard@nod.at> [bwh: Backported to 3.16 as dependency of commit 35634ffa1751 "signal: Always notice exiting tasks"] Signed-off-by: Ben Hutchings <ben@decadent.org.uk> 
commit 98c20309b97fc30001adf643cf876125f334fd8a upstream.

Use the more generic functions get_signal() signal_setup_done()
for signal delivery.
This inverts also the return codes of force_sigsegv_info()
and setup_frame() to follow the kernel convention.

Signed-off-by: Richard Weinberger <richard@nod.at>
[bwh: Backported to 3.16 as dependency of commit 35634ffa1751
 "signal: Always notice exiting tasks"]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Make asm/word-at-a-time.h available on all architectures 2018-10-21T07:46:11+00:00 Chris Metcalf cmetcalf@ezchip.com 2015-04-29T16:48:40+00:00 a45cee23a3cba600f23e14daeabbe9a50fd0ecde commit a6e2f029ae34f41adb6ae3812c32c5d326e1abd2 upstream. Added the x86 implementation of word-at-a-time to the generic version, which previously only supported big-endian. Omitted the x86-specific load_unaligned_zeropad(), which in any case is also not present for the existing BE-only implementation of a word-at-a-time, and is only used under CONFIG_DCACHE_WORD_ACCESS. Added as a "generic-y" to the Kbuilds of all architectures that didn't previously have it. Signed-off-by: Chris Metcalf <cmetcalf@ezchip.com> [bwh: Backported to 3.16: - Drop change in arch/nios2 - Adjust context] Signed-off-by: Ben Hutchings <ben@decadent.org.uk> 
commit a6e2f029ae34f41adb6ae3812c32c5d326e1abd2 upstream.

Added the x86 implementation of word-at-a-time to the
generic version, which previously only supported big-endian.

Omitted the x86-specific load_unaligned_zeropad(), which in
any case is also not present for the existing BE-only
implementation of a word-at-a-time, and is only used under
CONFIG_DCACHE_WORD_ACCESS.

Added as a "generic-y" to the Kbuilds of all architectures
that didn't previously have it.

Signed-off-by: Chris Metcalf <cmetcalf@ezchip.com>
[bwh: Backported to 3.16:
 - Drop change in arch/nios2
 - Adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
ia64: drop _PAGE_FILE and pte_file()-related helpers 2018-10-03T03:09:54+00:00 Kirill A. Shutemov kirill.shutemov@linux.intel.com 2015-02-10T22:10:36+00:00 7115166ebb95bcd09e32f46a957ce6f5acb28203 commit 636a002b704e0a36cefb5f4cf0293fab858fc46c upstream. We've replaced remap_file_pages(2) implementation with emulation. Nobody creates non-linear mapping anymore. This patch also increase number of bits availble for swap offset. Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Cc: Tony Luck <tony.luck@intel.com> Cc: Fenghua Yu <fenghua.yu@intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk> 
commit 636a002b704e0a36cefb5f4cf0293fab858fc46c upstream.

We've replaced remap_file_pages(2) implementation with emulation.  Nobody
creates non-linear mapping anymore.

This patch also increase number of bits availble for swap offset.

Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
ia64: convert unwcheck.py to python3 2018-06-16T21:22:33+00:00 Corentin Labbe clabbe@baylibre.com 2018-02-14T12:19:06+00:00 c72aca3619178e23a8c87c058158661c67692b61 commit bd5edbe677948d0883f59d9625c444818d5284b1 upstream. Since my system use python3 as default, arch/ia64/scripts/unwcheck.py no longer run. This patch convert it to the python3 syntax. I have ran it with python2/python3 while printing values of start/end/rlen_sum which could be impacted by this change and I see no difference. Fixes: 94a47083522e ("scripts: change scripts to use system python instead of env") Signed-off-by: Corentin Labbe <clabbe@baylibre.com> Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk> 
commit bd5edbe677948d0883f59d9625c444818d5284b1 upstream.

Since my system use python3 as default, arch/ia64/scripts/unwcheck.py no
longer run.

This patch convert it to the python3 syntax.
I have ran it with python2/python3 while printing values of
start/end/rlen_sum which could be impacted by this change and I see no difference.

Fixes: 94a47083522e ("scripts: change scripts to use system python instead of env")
Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
ptrace: Don't allow accessing an undumpable mm 2018-01-01T20:52:11+00:00 Eric W. Biederman ebiederm@xmission.com 2016-11-22T18:06:50+00:00 aa3fbddbb80119b4cffbb45581c8542d9dcdec79 commit 84d77d3f06e7e8dea057d10e8ec77ad71f721be3 upstream. It is the reasonable expectation that if an executable file is not readable there will be no way for a user without special privileges to read the file. This is enforced in ptrace_attach but if ptrace is already attached before exec there is no enforcement for read-only executables. As the only way to read such an mm is through access_process_vm spin a variant called ptrace_access_vm that will fail if the target process is not being ptraced by the current process, or the current process did not have sufficient privileges when ptracing began to read the target processes mm. In the ptrace implementations replace access_process_vm by ptrace_access_vm. There remain several ptrace sites that still use access_process_vm as they are reading the target executables instructions (for kernel consumption) or register stacks. As such it does not appear necessary to add a permission check to those calls. This bug has always existed in Linux. Fixes: v1.0 Reported-by: Andy Lutomirski <luto@amacapital.net> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> [bwh: Backported to 3.16: - Pass around only a write flag, not gup_flags - Adjust context] Signed-off-by: Ben Hutchings <ben@decadent.org.uk> 
commit 84d77d3f06e7e8dea057d10e8ec77ad71f721be3 upstream.

It is the reasonable expectation that if an executable file is not
readable there will be no way for a user without special privileges to
read the file.  This is enforced in ptrace_attach but if ptrace
is already attached before exec there is no enforcement for read-only
executables.

As the only way to read such an mm is through access_process_vm
spin a variant called ptrace_access_vm that will fail if the
target process is not being ptraced by the current process, or
the current process did not have sufficient privileges when ptracing
began to read the target processes mm.

In the ptrace implementations replace access_process_vm by
ptrace_access_vm.  There remain several ptrace sites that still use
access_process_vm as they are reading the target executables
instructions (for kernel consumption) or register stacks.  As such it
does not appear necessary to add a permission check to those calls.

This bug has always existed in Linux.

Fixes: v1.0
Reported-by: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
[bwh: Backported to 3.16:
 - Pass around only a write flag, not gup_flags
 - Adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
ia64: copy_from_user() should zero the destination on access_ok() failure 2016-11-20T01:17:27+00:00 Al Viro viro@zeniv.linux.org.uk 2016-08-19T01:31:41+00:00 b0a2fd659bc2d991a1d8ba1f8cc454cd59eda3bc commit a5e541f796f17228793694d64b507f5f57db4cd7 upstream. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> [bwh: Backported to 3.16: no calls to check_object_size()] Signed-off-by: Ben Hutchings <ben@decadent.org.uk> 
commit a5e541f796f17228793694d64b507f5f57db4cd7 upstream.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
[bwh: Backported to 3.16: no calls to check_object_size()]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
efi/reboot: Add generic wrapper around EfiResetSystem() 2015-05-12T08:36:34+00:00 Matt Fleming matt.fleming@intel.com 2014-06-13T11:22:22+00:00 c4bb687a50aa5021bc1837e1ec6bd1d6062e2cb7 commit 8562c99cdd30217dea3609e268572f8764f401a5 upstream. Implement efi_reboot(), which is really just a wrapper around the EfiResetSystem() EFI runtime service, but it does at least allow us to funnel all callers through a single location. It also simplifies the callsites since users no longer need to check to see whether EFI_RUNTIME_SERVICES are enabled. Cc: Tony Luck <tony.luck@intel.com> Tested-by: Mark Salter <msalter@redhat.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com> Cc: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Luis Henriques <luis.henriques@canonical.com> 
commit 8562c99cdd30217dea3609e268572f8764f401a5 upstream.

Implement efi_reboot(), which is really just a wrapper around the
EfiResetSystem() EFI runtime service, but it does at least allow us to
funnel all callers through a single location.

It also simplifies the callsites since users no longer need to check to
see whether EFI_RUNTIME_SERVICES are enabled.

Cc: Tony Luck <tony.luck@intel.com>
Tested-by: Mark Salter <msalter@redhat.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Cc: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
vm: add VM_FAULT_SIGSEGV handling support 2015-02-04T10:58:27+00:00 Linus Torvalds torvalds@linux-foundation.org 2015-01-29T18:51:32+00:00 903575f1b008e275bae8e55adf12907efc012f72 commit 33692f27597fcab536d7cbbcc8f52905133e4aa7 upstream. The core VM already knows about VM_FAULT_SIGBUS, but cannot return a "you should SIGSEGV" error, because the SIGSEGV case was generally handled by the caller - usually the architecture fault handler. That results in lots of duplication - all the architecture fault handlers end up doing very similar "look up vma, check permissions, do retries etc" - but it generally works. However, there are cases where the VM actually wants to SIGSEGV, and applications _expect_ SIGSEGV. In particular, when accessing the stack guard page, libsigsegv expects a SIGSEGV. And it usually got one, because the stack growth is handled by that duplicated architecture fault handler. However, when the generic VM layer started propagating the error return from the stack expansion in commit fee7e49d4514 ("mm: propagate error from stack expansion even for guard page"), that now exposed the existing VM_FAULT_SIGBUS result to user space. And user space really expected SIGSEGV, not SIGBUS. To fix that case, we need to add a VM_FAULT_SIGSEGV, and teach all those duplicate architecture fault handlers about it. They all already have the code to handle SIGSEGV, so it's about just tying that new return value to the existing code, but it's all a bit annoying. This is the mindless minimal patch to do this. A more extensive patch would be to try to gather up the mostly shared fault handling logic into one generic helper routine, and long-term we really should do that cleanup. Just from this patch, you can generally see that most architectures just copied (directly or indirectly) the old x86 way of doing things, but in the meantime that original x86 model has been improved to hold the VM semaphore for shorter times etc and to handle VM_FAULT_RETRY and other "newer" things, so it would be a good idea to bring all those improvements to the generic case and teach other architectures about them too. Reported-and-tested-by: Takashi Iwai <tiwai@suse.de> Tested-by: Jan Engelhardt <jengelh@inai.de> Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com> # "s390 still compiles and boots" Cc: linux-arch@vger.kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> [ luis: backported to 3.16: - file renamed: arch/powerpc/mm/copro_fault.c -> arch/powerpc/platforms/cell/spu_fault.c - dropped changes to arch/nios2/mm/fault.c ] Signed-off-by: Luis Henriques <luis.henriques@canonical.com> 
commit 33692f27597fcab536d7cbbcc8f52905133e4aa7 upstream.

The core VM already knows about VM_FAULT_SIGBUS, but cannot return a
"you should SIGSEGV" error, because the SIGSEGV case was generally
handled by the caller - usually the architecture fault handler.

That results in lots of duplication - all the architecture fault
handlers end up doing very similar "look up vma, check permissions, do
retries etc" - but it generally works.  However, there are cases where
the VM actually wants to SIGSEGV, and applications _expect_ SIGSEGV.

In particular, when accessing the stack guard page, libsigsegv expects a
SIGSEGV.  And it usually got one, because the stack growth is handled by
that duplicated architecture fault handler.

However, when the generic VM layer started propagating the error return
from the stack expansion in commit fee7e49d4514 ("mm: propagate error
from stack expansion even for guard page"), that now exposed the
existing VM_FAULT_SIGBUS result to user space.  And user space really
expected SIGSEGV, not SIGBUS.

To fix that case, we need to add a VM_FAULT_SIGSEGV, and teach all those
duplicate architecture fault handlers about it.  They all already have
the code to handle SIGSEGV, so it's about just tying that new return
value to the existing code, but it's all a bit annoying.

This is the mindless minimal patch to do this.  A more extensive patch
would be to try to gather up the mostly shared fault handling logic into
one generic helper routine, and long-term we really should do that
cleanup.

Just from this patch, you can generally see that most architectures just
copied (directly or indirectly) the old x86 way of doing things, but in
the meantime that original x86 model has been improved to hold the VM
semaphore for shorter times etc and to handle VM_FAULT_RETRY and other
"newer" things, so it would be a good idea to bring all those
improvements to the generic case and teach other architectures about
them too.

Reported-and-tested-by: Takashi Iwai <tiwai@suse.de>
Tested-by: Jan Engelhardt <jengelh@inai.de>
Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com> # "s390 still compiles and boots"
Cc: linux-arch@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[ luis: backported to 3.16:
  - file renamed: arch/powerpc/mm/copro_fault.c ->
    arch/powerpc/platforms/cell/spu_fault.c
  - dropped changes to arch/nios2/mm/fault.c ]
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
vgaarb: Don't default exclusively to first video device with mem+io 2014-10-09T19:23:49+00:00 Bruno Prémont bonbons@linux-vserver.org 2014-08-24T21:09:53+00:00 ce027dac592c0ada241ce0f95ae65856828ac450 commit 86fd887b7fe350819dae5b55e7fef05b511c8656 upstream. Commit 20cde694027e ("x86, ia64: Move EFI_FB vga_default_device() initialization to pci_vga_fixup()") moved boot video device detection from efifb to x86 and ia64 pci/fixup.c. For dual-GPU Apple computers above change represents a regression as code in efifb did forcefully override vga_default_device while the merge did not (vgaarb happens prior to PCI fixup). To improve on initial device selection by vgaarb (it cannot know if PCI device not behind bridges see/decode legacy VGA I/O or not), move the screen_info based check from pci_video_fixup() to vgaarb's init function and use it to refine/override decision taken while adding the individual PCI VGA devices. This way PCI fixup has no reason to adjust vga_default_device anymore but can depend on its value for flagging shadowed VBIOS. This has the nice benefit of removing duplicated code but does introduce a #if defined() block in vgaarb. Not all architectures have screen_info and would cause compile to fail without it. Link: https://bugzilla.kernel.org/show_bug.cgi?id=84461 Reported-and-Tested-By: Andreas Noever <andreas.noever@gmail.com> Signed-off-by: Bruno Prémont <bonbons@linux-vserver.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: Matthew Garrett <matthew.garrett@nebula.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 86fd887b7fe350819dae5b55e7fef05b511c8656 upstream.

Commit 20cde694027e ("x86, ia64: Move EFI_FB vga_default_device()
initialization to pci_vga_fixup()") moved boot video device detection from
efifb to x86 and ia64 pci/fixup.c.

For dual-GPU Apple computers above change represents a regression as code
in efifb did forcefully override vga_default_device while the merge did not
(vgaarb happens prior to PCI fixup).

To improve on initial device selection by vgaarb (it cannot know if PCI
device not behind bridges see/decode legacy VGA I/O or not), move the
screen_info based check from pci_video_fixup() to vgaarb's init function and
use it to refine/override decision taken while adding the individual PCI
VGA devices.  This way PCI fixup has no reason to adjust vga_default_device
anymore but can depend on its value for flagging shadowed VBIOS.

This has the nice benefit of removing duplicated code but does introduce a
#if defined() block in vgaarb.  Not all architectures have screen_info and
would cause compile to fail without it.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=84461
Reported-and-Tested-By: Andreas Noever <andreas.noever@gmail.com>
Signed-off-by: Bruno Prémont <bonbons@linux-vserver.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Matthew Garrett <matthew.garrett@nebula.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>