linux-stable.git/arch/parisc, branch v4.19.2 Linux kernel stable tree parisc: Fix exported address of os_hpmc handler 2018-11-13T19:08:18+00:00 Helge Deller deller@gmx.de 2018-10-14T19:58:00+00:00 e41a6afda6399d018b321e7b320c15abbe549ea0 commit 99a3ae51d557d8e38a7aece65678a31f9db215ee upstream. In the C-code we need to put the physical address of the hpmc handler in the interrupt vector table (IVA) in order to get HPMCs working. Since on parisc64 function pointers are indirect (in fact they are function descriptors) we instead export the address as variable and not as function. This reverts a small part of commit f39cce654f9a ("parisc: Add cfi_startproc and cfi_endproc to assembly code"). Signed-off-by: Helge Deller <deller@gmx.de> Cc: <stable@vger.kernel.org> [4.9+] Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 99a3ae51d557d8e38a7aece65678a31f9db215ee upstream.

In the C-code we need to put the physical address of the hpmc handler in
the interrupt vector table (IVA) in order to get HPMCs working.  Since
on parisc64 function pointers are indirect (in fact they are function
descriptors) we instead export the address as variable and not as
function.

This reverts a small part of commit f39cce654f9a ("parisc: Add
cfi_startproc and cfi_endproc to assembly code").

Signed-off-by: Helge Deller <deller@gmx.de>
Cc: <stable@vger.kernel.org>    [4.9+]
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
parisc: Fix map_pages() to not overwrite existing pte entries 2018-11-13T19:08:18+00:00 Helge Deller deller@gmx.de 2018-10-12T20:37:46+00:00 72f6b9c076c93a79508d2f653f213be333096a97 commit 3c229b3f2dd8133f61bb81d3cb018be92f4bba39 upstream. Fix a long-existing small nasty bug in the map_pages() implementation which leads to overwriting already written pte entries with zero, *if* map_pages() is called a second time with an end address which isn't aligned on a pmd boundry. This happens for example if we want to remap only the text segment read/write in order to run alternative patching on the code. Exiting the loop when we reach the end address fixes this. Cc: stable@vger.kernel.org Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 3c229b3f2dd8133f61bb81d3cb018be92f4bba39 upstream.

Fix a long-existing small nasty bug in the map_pages() implementation which
leads to overwriting already written pte entries with zero, *if* map_pages() is
called a second time with an end address which isn't aligned on a pmd boundry.
This happens for example if we want to remap only the text segment read/write
in order to run alternative patching on the code. Exiting the loop when we
reach the end address fixes this.

Cc: stable@vger.kernel.org
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
parisc: Fix address in HPMC IVA 2018-11-13T19:08:18+00:00 John David Anglin dave.anglin@bell.net 2018-10-06T17:11:30+00:00 dcfc49721c9a342d725782da7b2ab7bbb7ace8d1 commit 1138b6718ff74d2a934459643e3754423d23b5e2 upstream. Helge noticed that the address of the os_hpmc handler was not being correctly calculated in the hpmc macro. As a result, PDCE_CHECK would fail to call os_hpmc: <Cpu2> e800009802e00000 0000000000000000 CC_ERR_CHECK_HPMC <Cpu2> 37000f7302e00000 8040004000000000 CC_ERR_CPU_CHECK_SUMMARY <Cpu2> f600105e02e00000 fffffff0f0c00000 CC_MC_HPMC_MONARCH_SELECTED <Cpu2> 140003b202e00000 000000000000000b CC_ERR_HPMC_STATE_ENTRY <Cpu2> 5600100b02e00000 00000000000001a0 CC_MC_OS_HPMC_LEN_ERR <Cpu2> 5600106402e00000 fffffff0f0438e70 CC_MC_BR_TO_OS_HPMC_FAILED <Cpu2> e800009802e00000 0000000000000000 CC_ERR_CHECK_HPMC <Cpu2> 37000f7302e00000 8040004000000000 CC_ERR_CPU_CHECK_SUMMARY <Cpu2> 4000109f02e00000 0000000000000000 CC_MC_HPMC_INITIATED <Cpu2> 4000101902e00000 0000000000000000 CC_MC_MULTIPLE_HPMCS <Cpu2> 030010d502e00000 0000000000000000 CC_CPU_STOP The address problem can be seen by dumping the fault vector: 0000000040159000 <fault_vector_20>: 40159000: 63 6f 77 73 stb r15,-2447(dp) 40159004: 20 63 61 6e ldil L%b747000,r3 40159008: 20 66 6c 79 ldil L%-1c3b3000,r3 ... 40159020: 08 00 02 40 nop 40159024: 20 6e 60 02 ldil L%15d000,r3 40159028: 34 63 00 00 ldo 0(r3),r3 4015902c: e8 60 c0 02 bv,n r0(r3) 40159030: 08 00 02 40 nop 40159034: 00 00 00 00 break 0,0 40159038: c0 00 70 00 bb,*< r0,sar,40159840 <fault_vector_20+0x840> 4015903c: 00 00 00 00 break 0,0 Location 40159038 should contain the physical address of os_hpmc: 000000004015d000 <os_hpmc>: 4015d000: 08 1a 02 43 copy r26,r3 4015d004: 01 c0 08 a4 mfctl iva,r4 4015d008: 48 85 00 68 ldw 34(r4),r5 This patch moves the address setup into initialize_ivt to resolve the above problem. I tested the change by dumping the HPMC entry after setup: 0000000040209020: 8000240 0000000040209024: 206a2004 0000000040209028: 34630ac0 000000004020902c: e860c002 0000000040209030: 8000240 0000000040209034: 1bdddce6 0000000040209038: 15d000 000000004020903c: 1a0 Signed-off-by: John David Anglin <dave.anglin@bell.net> Cc: <stable@vger.kernel.org> Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 1138b6718ff74d2a934459643e3754423d23b5e2 upstream.

Helge noticed that the address of the os_hpmc handler was not being
correctly calculated in the hpmc macro.  As a result, PDCE_CHECK would
fail to call os_hpmc:

<Cpu2> e800009802e00000  0000000000000000  CC_ERR_CHECK_HPMC
<Cpu2> 37000f7302e00000  8040004000000000  CC_ERR_CPU_CHECK_SUMMARY
<Cpu2> f600105e02e00000  fffffff0f0c00000  CC_MC_HPMC_MONARCH_SELECTED
<Cpu2> 140003b202e00000  000000000000000b  CC_ERR_HPMC_STATE_ENTRY
<Cpu2> 5600100b02e00000  00000000000001a0  CC_MC_OS_HPMC_LEN_ERR
<Cpu2> 5600106402e00000  fffffff0f0438e70  CC_MC_BR_TO_OS_HPMC_FAILED
<Cpu2> e800009802e00000  0000000000000000  CC_ERR_CHECK_HPMC
<Cpu2> 37000f7302e00000  8040004000000000  CC_ERR_CPU_CHECK_SUMMARY
<Cpu2> 4000109f02e00000  0000000000000000  CC_MC_HPMC_INITIATED
<Cpu2> 4000101902e00000  0000000000000000  CC_MC_MULTIPLE_HPMCS
<Cpu2> 030010d502e00000  0000000000000000  CC_CPU_STOP

The address problem can be seen by dumping the fault vector:

0000000040159000 <fault_vector_20>:
    40159000:   63 6f 77 73     stb r15,-2447(dp)
    40159004:   20 63 61 6e     ldil L%b747000,r3
    40159008:   20 66 6c 79     ldil L%-1c3b3000,r3
        ...
    40159020:   08 00 02 40     nop
    40159024:   20 6e 60 02     ldil L%15d000,r3
    40159028:   34 63 00 00     ldo 0(r3),r3
    4015902c:   e8 60 c0 02     bv,n r0(r3)
    40159030:   08 00 02 40     nop
    40159034:   00 00 00 00     break 0,0
    40159038:   c0 00 70 00     bb,*< r0,sar,40159840 <fault_vector_20+0x840>
    4015903c:   00 00 00 00     break 0,0

Location 40159038 should contain the physical address of os_hpmc:

000000004015d000 <os_hpmc>:
    4015d000:   08 1a 02 43     copy r26,r3
    4015d004:   01 c0 08 a4     mfctl iva,r4
    4015d008:   48 85 00 68     ldw 34(r4),r5

This patch moves the address setup into initialize_ivt to resolve the
above problem.  I tested the change by dumping the HPMC entry after setup:

0000000040209020:  8000240
0000000040209024: 206a2004
0000000040209028: 34630ac0
000000004020902c: e860c002
0000000040209030:  8000240
0000000040209034: 1bdddce6
0000000040209038:   15d000
000000004020903c:      1a0

Signed-off-by: John David Anglin <dave.anglin@bell.net>
Cc: <stable@vger.kernel.org>
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
parisc: Fix uninitialized variable usage in unwind.c 2018-10-16T09:37:29+00:00 Helge Deller deller@gmx.de 2018-10-16T06:21:48+00:00 cf8afe5c53621eda385be961bc72329a2adcd767 As noticed by Dave Anglin, the last commit introduced a small bug where the potentially uninitialized r struct is used instead of the regs pointer as input for unwind_frame_init(). Fix it. Signed-off-by: Helge Deller <deller@gmx.de> Reported-by: John David Anglin <dave.anglin@bell.net> 
As noticed by Dave Anglin, the last commit introduced a small bug where
the potentially uninitialized r struct is used instead of the regs
pointer as input for unwind_frame_init(). Fix it.

Signed-off-by: Helge Deller <deller@gmx.de>
Reported-by: John David Anglin <dave.anglin@bell.net>
Merge branch 'parisc-4.19-2' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux 2018-08-22T21:06:37+00:00 Linus Torvalds torvalds@linux-foundation.org 2018-08-22T21:06:37+00:00 45b74a65b9934d5e1520d97aa4e09cf2b8c69ac0 Pull more parisc updates from Helge Deller: - fix boot failure of 64-bit kernel. It got broken by the unwind optimization commit in merge window. - fix 64-bit userspace support (static 64-bit applications only, e.g. we don't yet have 64-bit userspace support in glibc). - consolidate unwind initialization code. - add machine model description to stack trace. * 'parisc-4.19-2' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux: parisc: Add hardware description to stack traces parisc: Fix boot failure of 64-bit kernel parisc: Consolidate unwind initialization calls parisc: Update comments in syscall.S regarding wide userland parisc: Fix ptraced 64-bit applications to call 64-bit syscalls parisc: Restore possibility to execute 64-bit applications 
Pull more parisc updates from Helge Deller:

 - fix boot failure of 64-bit kernel. It got broken by the unwind
   optimization commit in merge window.

 - fix 64-bit userspace support (static 64-bit applications only, e.g.
   we don't yet have 64-bit userspace support in glibc).

 - consolidate unwind initialization code.

 - add machine model description to stack trace.

* 'parisc-4.19-2' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
  parisc: Add hardware description to stack traces
  parisc: Fix boot failure of 64-bit kernel
  parisc: Consolidate unwind initialization calls
  parisc: Update comments in syscall.S regarding wide userland
  parisc: Fix ptraced 64-bit applications to call 64-bit syscalls
  parisc: Restore possibility to execute 64-bit applications
parisc: Add hardware description to stack traces 2018-08-21T12:46:26+00:00 Helge Deller deller@gmx.de 2018-08-21T06:15:42+00:00 dbf2a4b1ffab2867505be3b24221d5efa2200c91 Signed-off-by: Helge Deller <deller@gmx.de> 
Signed-off-by: Helge Deller <deller@gmx.de>
parisc: Fix boot failure of 64-bit kernel 2018-08-21T12:32:44+00:00 Helge Deller deller@gmx.de 2018-08-21T12:31:32+00:00 8801ccb9fa524c195322c26b6d44e99827772bde Commit c8921d72e390 ("parisc: Fix and improve kernel stack unwinding") broke booting of 64-bit kernels. On 64-bit kernels function pointers are actually function descriptors which require dereferencing. In this patch we instead declare functions in assembly code which are referenced from C-code as external data pointers with the ENTRY() macro and thus can use a simple external reference to the functions. Signed-off-by: Helge Deller <deller@gmx.de> Fixes: c8921d72e390 ("parisc: Fix and improve kernel stack unwinding") 
Commit c8921d72e390 ("parisc: Fix and improve kernel stack unwinding")
broke booting of 64-bit kernels. On 64-bit kernels function pointers are
actually function descriptors which require dereferencing. In this patch
we instead declare functions in assembly code which are referenced from
C-code as external data pointers with the ENTRY() macro and thus can use
a simple external reference to the functions.

Signed-off-by: Helge Deller <deller@gmx.de>
Fixes: c8921d72e390 ("parisc: Fix and improve kernel stack unwinding")
mm: convert return type of handle_mm_fault() caller to vm_fault_t 2018-08-17T23:20:28+00:00 Souptick Joarder jrdr.linux@gmail.com 2018-08-17T22:44:47+00:00 50a7ca3c6fc86955f99fc432fc8a186b968b365b Use new return type vm_fault_t for fault handler. For now, this is just documenting that the function returns a VM_FAULT value rather than an errno. Once all instances are converted, vm_fault_t will become a distinct type. Ref-> commit 1c8f422059ae ("mm: change return type to vm_fault_t") In this patch all the caller of handle_mm_fault() are changed to return vm_fault_t type. Link: http://lkml.kernel.org/r/20180617084810.GA6730@jordon-HP-15-Notebook-PC Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com> Cc: Matthew Wilcox <willy@infradead.org> Cc: Richard Henderson <rth@twiddle.net> Cc: Tony Luck <tony.luck@intel.com> Cc: Matt Turner <mattst88@gmail.com> Cc: Vineet Gupta <vgupta@synopsys.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will.deacon@arm.com> Cc: Richard Kuo <rkuo@codeaurora.org> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Michal Simek <monstr@monstr.eu> Cc: James Hogan <jhogan@kernel.org> Cc: Ley Foon Tan <lftan@altera.com> Cc: Jonas Bonn <jonas@southpole.se> Cc: James E.J. Bottomley <jejb@parisc-linux.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Palmer Dabbelt <palmer@sifive.com> Cc: Yoshinori Sato <ysato@users.sourceforge.jp> Cc: David S. Miller <davem@davemloft.net> Cc: Richard Weinberger <richard@nod.at> Cc: Guan Xuetao <gxt@pku.edu.cn> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: "Levin, Alexander (Sasha Levin)" <alexander.levin@verizon.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 
Use new return type vm_fault_t for fault handler.  For now, this is just
documenting that the function returns a VM_FAULT value rather than an
errno.  Once all instances are converted, vm_fault_t will become a
distinct type.

Ref-> commit 1c8f422059ae ("mm: change return type to vm_fault_t")

In this patch all the caller of handle_mm_fault() are changed to return
vm_fault_t type.

Link: http://lkml.kernel.org/r/20180617084810.GA6730@jordon-HP-15-Notebook-PC
Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Matt Turner <mattst88@gmail.com>
Cc: Vineet Gupta <vgupta@synopsys.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Richard Kuo <rkuo@codeaurora.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Michal Simek <monstr@monstr.eu>
Cc: James Hogan <jhogan@kernel.org>
Cc: Ley Foon Tan <lftan@altera.com>
Cc: Jonas Bonn <jonas@southpole.se>
Cc: James E.J. Bottomley <jejb@parisc-linux.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Palmer Dabbelt <palmer@sifive.com>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Cc: David S. Miller <davem@davemloft.net>
Cc: Richard Weinberger <richard@nod.at>
Cc: Guan Xuetao <gxt@pku.edu.cn>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: "Levin, Alexander (Sasha Levin)" <alexander.levin@verizon.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
parisc: Consolidate unwind initialization calls 2018-08-17T15:00:08+00:00 Helge Deller deller@gmx.de 2018-08-17T15:00:08+00:00 9e0d5c451f9e559dd06af3fff49a0d2068c634c4 Signed-off-by: Helge Deller <deller@gmx.de> 
Signed-off-by: Helge Deller <deller@gmx.de>
parisc: Update comments in syscall.S regarding wide userland 2018-08-17T14:45:41+00:00 Helge Deller deller@gmx.de 2018-08-16T20:36:26+00:00 54c770da992387abfa7df4817404d000ef034fa8 We do support running 64-bit userspace processes, although there isn't yet full gcc and glibc support. Anyway, fix the comments to reflect the reality. Signed-off-by: Helge Deller <deller@gmx.de> 
We do support running 64-bit userspace processes, although there isn't
yet full gcc and glibc support. Anyway, fix the comments to reflect the
reality.

Signed-off-by: Helge Deller <deller@gmx.de>