<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/arch/mips/kernel/process.c, branch v4.14.331</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>MIPS: Remove function size check in get_frame_info()</title>
<updated>2019-03-13T21:03:22+00:00</updated>
<author>
<name>Jun-Ru Chang</name>
<email>jrjang@realtek.com</email>
</author>
<published>2019-01-29T03:56:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a09faaf5d2de312ec77029933fc80f5a79aadb90'/>
<id>a09faaf5d2de312ec77029933fc80f5a79aadb90</id>
<content type='text'>
[ Upstream commit 2b424cfc69728224fcb5fad138ea7260728e0901 ]

Patch (b6c7a324df37b "MIPS: Fix get_frame_info() handling of
microMIPS function size.") introduces additional function size
check for microMIPS by only checking insn between ip and ip + func_size.
However, func_size in get_frame_info() is always 0 if KALLSYMS is not
enabled. This causes get_frame_info() to return immediately without
calculating correct frame_size, which in turn causes "Can't analyze
schedule() prologue" warning messages at boot time.

This patch removes func_size check, and let the frame_size check run
up to 128 insns for both MIPS and microMIPS.

Signed-off-by: Jun-Ru Chang &lt;jrjang@realtek.com&gt;
Signed-off-by: Tony Wu &lt;tonywu@realtek.com&gt;
Signed-off-by: Paul Burton &lt;paul.burton@mips.com&gt;
Fixes: b6c7a324df37b ("MIPS: Fix get_frame_info() handling of microMIPS function size.")
Cc: &lt;ralf@linux-mips.org&gt;
Cc: &lt;jhogan@kernel.org&gt;
Cc: &lt;macro@mips.com&gt;
Cc: &lt;yamada.masahiro@socionext.com&gt;
Cc: &lt;peterz@infradead.org&gt;
Cc: &lt;mingo@kernel.org&gt;
Cc: &lt;linux-mips@vger.kernel.org&gt;
Cc: &lt;linux-kernel@vger.kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 2b424cfc69728224fcb5fad138ea7260728e0901 ]

Patch (b6c7a324df37b "MIPS: Fix get_frame_info() handling of
microMIPS function size.") introduces additional function size
check for microMIPS by only checking insn between ip and ip + func_size.
However, func_size in get_frame_info() is always 0 if KALLSYMS is not
enabled. This causes get_frame_info() to return immediately without
calculating correct frame_size, which in turn causes "Can't analyze
schedule() prologue" warning messages at boot time.

This patch removes func_size check, and let the frame_size check run
up to 128 insns for both MIPS and microMIPS.

Signed-off-by: Jun-Ru Chang &lt;jrjang@realtek.com&gt;
Signed-off-by: Tony Wu &lt;tonywu@realtek.com&gt;
Signed-off-by: Paul Burton &lt;paul.burton@mips.com&gt;
Fixes: b6c7a324df37b ("MIPS: Fix get_frame_info() handling of microMIPS function size.")
Cc: &lt;ralf@linux-mips.org&gt;
Cc: &lt;jhogan@kernel.org&gt;
Cc: &lt;macro@mips.com&gt;
Cc: &lt;yamada.masahiro@socionext.com&gt;
Cc: &lt;peterz@infradead.org&gt;
Cc: &lt;mingo@kernel.org&gt;
Cc: &lt;linux-mips@vger.kernel.org&gt;
Cc: &lt;linux-kernel@vger.kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: VDSO: Always map near top of user memory</title>
<updated>2018-10-18T07:16:23+00:00</updated>
<author>
<name>Paul Burton</name>
<email>paul.burton@mips.com</email>
</author>
<published>2018-09-25T22:51:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=86717a97f9218de798c6d33e0014ab9325e18f56'/>
<id>86717a97f9218de798c6d33e0014ab9325e18f56</id>
<content type='text'>
commit ea7e0480a4b695d0aa6b3fa99bd658a003122113 upstream.

When using the legacy mmap layout, for example triggered using ulimit -s
unlimited, get_unmapped_area() fills memory from bottom to top starting
from a fairly low address near TASK_UNMAPPED_BASE.

This placement is suboptimal if the user application wishes to allocate
large amounts of heap memory using the brk syscall. With the VDSO being
located low in the user's virtual address space, the amount of space
available for access using brk is limited much more than it was prior to
the introduction of the VDSO.

For example:

  # ulimit -s unlimited; cat /proc/self/maps
  00400000-004ec000 r-xp 00000000 08:00 71436      /usr/bin/coreutils
  004fc000-004fd000 rwxp 000ec000 08:00 71436      /usr/bin/coreutils
  004fd000-0050f000 rwxp 00000000 00:00 0
  00cc3000-00ce4000 rwxp 00000000 00:00 0          [heap]
  2ab96000-2ab98000 r--p 00000000 00:00 0          [vvar]
  2ab98000-2ab99000 r-xp 00000000 00:00 0          [vdso]
  2ab99000-2ab9d000 rwxp 00000000 00:00 0
  ...

Resolve this by adjusting STACK_TOP to reserve space for the VDSO &amp;
providing an address hint to get_unmapped_area() causing it to use this
space even when using the legacy mmap layout.

We reserve enough space for the VDSO, plus 1MB or 256MB for 32 bit &amp; 64
bit systems respectively within which we randomize the VDSO base
address. Previously this randomization was taken care of by the mmap
base address randomization performed by arch_mmap_rnd(). The 1MB &amp; 256MB
sizes are somewhat arbitrary but chosen such that we have some
randomization without taking up too much of the user's virtual address
space, which is often in short supply for 32 bit systems.

With this the VDSO is always mapped at a high address, leaving lots of
space for statically linked programs to make use of brk:

  # ulimit -s unlimited; cat /proc/self/maps
  00400000-004ec000 r-xp 00000000 08:00 71436      /usr/bin/coreutils
  004fc000-004fd000 rwxp 000ec000 08:00 71436      /usr/bin/coreutils
  004fd000-0050f000 rwxp 00000000 00:00 0
  00c28000-00c49000 rwxp 00000000 00:00 0          [heap]
  ...
  7f67c000-7f69d000 rwxp 00000000 00:00 0          [stack]
  7f7fc000-7f7fd000 rwxp 00000000 00:00 0
  7fcf1000-7fcf3000 r--p 00000000 00:00 0          [vvar]
  7fcf3000-7fcf4000 r-xp 00000000 00:00 0          [vdso]

Signed-off-by: Paul Burton &lt;paul.burton@mips.com&gt;
Reported-by: Huacai Chen &lt;chenhc@lemote.com&gt;
Fixes: ebb5e78cc634 ("MIPS: Initial implementation of a VDSO")
Cc: Huacai Chen &lt;chenhc@lemote.com&gt;
Cc: linux-mips@linux-mips.org
Cc: stable@vger.kernel.org # v4.4+
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit ea7e0480a4b695d0aa6b3fa99bd658a003122113 upstream.

When using the legacy mmap layout, for example triggered using ulimit -s
unlimited, get_unmapped_area() fills memory from bottom to top starting
from a fairly low address near TASK_UNMAPPED_BASE.

This placement is suboptimal if the user application wishes to allocate
large amounts of heap memory using the brk syscall. With the VDSO being
located low in the user's virtual address space, the amount of space
available for access using brk is limited much more than it was prior to
the introduction of the VDSO.

For example:

  # ulimit -s unlimited; cat /proc/self/maps
  00400000-004ec000 r-xp 00000000 08:00 71436      /usr/bin/coreutils
  004fc000-004fd000 rwxp 000ec000 08:00 71436      /usr/bin/coreutils
  004fd000-0050f000 rwxp 00000000 00:00 0
  00cc3000-00ce4000 rwxp 00000000 00:00 0          [heap]
  2ab96000-2ab98000 r--p 00000000 00:00 0          [vvar]
  2ab98000-2ab99000 r-xp 00000000 00:00 0          [vdso]
  2ab99000-2ab9d000 rwxp 00000000 00:00 0
  ...

Resolve this by adjusting STACK_TOP to reserve space for the VDSO &amp;
providing an address hint to get_unmapped_area() causing it to use this
space even when using the legacy mmap layout.

We reserve enough space for the VDSO, plus 1MB or 256MB for 32 bit &amp; 64
bit systems respectively within which we randomize the VDSO base
address. Previously this randomization was taken care of by the mmap
base address randomization performed by arch_mmap_rnd(). The 1MB &amp; 256MB
sizes are somewhat arbitrary but chosen such that we have some
randomization without taking up too much of the user's virtual address
space, which is often in short supply for 32 bit systems.

With this the VDSO is always mapped at a high address, leaving lots of
space for statically linked programs to make use of brk:

  # ulimit -s unlimited; cat /proc/self/maps
  00400000-004ec000 r-xp 00000000 08:00 71436      /usr/bin/coreutils
  004fc000-004fd000 rwxp 000ec000 08:00 71436      /usr/bin/coreutils
  004fd000-0050f000 rwxp 00000000 00:00 0
  00c28000-00c49000 rwxp 00000000 00:00 0          [heap]
  ...
  7f67c000-7f69d000 rwxp 00000000 00:00 0          [stack]
  7f7fc000-7f7fd000 rwxp 00000000 00:00 0
  7fcf1000-7fcf3000 r--p 00000000 00:00 0          [vvar]
  7fcf3000-7fcf4000 r-xp 00000000 00:00 0          [vdso]

Signed-off-by: Paul Burton &lt;paul.burton@mips.com&gt;
Reported-by: Huacai Chen &lt;chenhc@lemote.com&gt;
Fixes: ebb5e78cc634 ("MIPS: Initial implementation of a VDSO")
Cc: Huacai Chen &lt;chenhc@lemote.com&gt;
Cc: linux-mips@linux-mips.org
Cc: stable@vger.kernel.org # v4.4+
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: Use async IPIs for arch_trigger_cpumask_backtrace()</title>
<updated>2018-07-17T09:39:23+00:00</updated>
<author>
<name>Paul Burton</name>
<email>paul.burton@mips.com</email>
</author>
<published>2018-06-22T17:55:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=0818c44b8df72205298208b21a14c9e3959bb3b3'/>
<id>0818c44b8df72205298208b21a14c9e3959bb3b3</id>
<content type='text'>
commit b63e132b6433a41cf311e8bc382d33fd2b73b505 upstream.

The current MIPS implementation of arch_trigger_cpumask_backtrace() is
broken because it attempts to use synchronous IPIs despite the fact that
it may be run with interrupts disabled.

This means that when arch_trigger_cpumask_backtrace() is invoked, for
example by the RCU CPU stall watchdog, we may:

  - Deadlock due to use of synchronous IPIs with interrupts disabled,
    causing the CPU that's attempting to generate the backtrace output
    to hang itself.

  - Not succeed in generating the desired output from remote CPUs.

  - Produce warnings about this from smp_call_function_many(), for
    example:

    [42760.526910] INFO: rcu_sched detected stalls on CPUs/tasks:
    [42760.535755]  0-...!: (1 GPs behind) idle=ade/140000000000000/0 softirq=526944/526945 fqs=0
    [42760.547874]  1-...!: (0 ticks this GP) idle=e4a/140000000000000/0 softirq=547885/547885 fqs=0
    [42760.559869]  (detected by 2, t=2162 jiffies, g=266689, c=266688, q=33)
    [42760.568927] ------------[ cut here ]------------
    [42760.576146] WARNING: CPU: 2 PID: 1216 at kernel/smp.c:416 smp_call_function_many+0x88/0x20c
    [42760.587839] Modules linked in:
    [42760.593152] CPU: 2 PID: 1216 Comm: sh Not tainted 4.15.4-00373-gee058bb4d0c2 #2
    [42760.603767] Stack : 8e09bd20 8e09bd20 8e09bd20 fffffff0 00000007 00000006 00000000 8e09bca8
    [42760.616937]         95b2b379 95b2b379 807a0080 00000007 81944518 0000018a 00000032 00000000
    [42760.630095]         00000000 00000030 80000000 00000000 806eca74 00000009 8017e2b8 000001a0
    [42760.643169]         00000000 00000002 00000000 8e09baa4 00000008 808b8008 86d69080 8e09bca0
    [42760.656282]         8e09ad50 805e20aa 00000000 00000000 00000000 8017e2b8 00000009 801070ca
    [42760.669424]         ...
    [42760.673919] Call Trace:
    [42760.678672] [&lt;27fde568&gt;] show_stack+0x70/0xf0
    [42760.685417] [&lt;84751641&gt;] dump_stack+0xaa/0xd0
    [42760.692188] [&lt;699d671c&gt;] __warn+0x80/0x92
    [42760.698549] [&lt;68915d41&gt;] warn_slowpath_null+0x28/0x36
    [42760.705912] [&lt;f7c76c1c&gt;] smp_call_function_many+0x88/0x20c
    [42760.713696] [&lt;6bbdfc2a&gt;] arch_trigger_cpumask_backtrace+0x30/0x4a
    [42760.722216] [&lt;f845bd33&gt;] rcu_dump_cpu_stacks+0x6a/0x98
    [42760.729580] [&lt;796e7629&gt;] rcu_check_callbacks+0x672/0x6ac
    [42760.737476] [&lt;059b3b43&gt;] update_process_times+0x18/0x34
    [42760.744981] [&lt;6eb94941&gt;] tick_sched_handle.isra.5+0x26/0x38
    [42760.752793] [&lt;478d3d70&gt;] tick_sched_timer+0x1c/0x50
    [42760.759882] [&lt;e56ea39f&gt;] __hrtimer_run_queues+0xc6/0x226
    [42760.767418] [&lt;e88bbcae&gt;] hrtimer_interrupt+0x88/0x19a
    [42760.775031] [&lt;6765a19e&gt;] gic_compare_interrupt+0x2e/0x3a
    [42760.782761] [&lt;0558bf5f&gt;] handle_percpu_devid_irq+0x78/0x168
    [42760.790795] [&lt;90c11ba2&gt;] generic_handle_irq+0x1e/0x2c
    [42760.798117] [&lt;1b6d462c&gt;] gic_handle_local_int+0x38/0x86
    [42760.805545] [&lt;b2ada1c7&gt;] gic_irq_dispatch+0xa/0x14
    [42760.812534] [&lt;90c11ba2&gt;] generic_handle_irq+0x1e/0x2c
    [42760.820086] [&lt;c7521934&gt;] do_IRQ+0x16/0x20
    [42760.826274] [&lt;9aef3ce6&gt;] plat_irq_dispatch+0x62/0x94
    [42760.833458] [&lt;6a94b53c&gt;] except_vec_vi_end+0x70/0x78
    [42760.840655] [&lt;22284043&gt;] smp_call_function_many+0x1ba/0x20c
    [42760.848501] [&lt;54022b58&gt;] smp_call_function+0x1e/0x2c
    [42760.855693] [&lt;ab9fc705&gt;] flush_tlb_mm+0x2a/0x98
    [42760.862730] [&lt;0844cdd0&gt;] tlb_flush_mmu+0x1c/0x44
    [42760.869628] [&lt;cb259b74&gt;] arch_tlb_finish_mmu+0x26/0x3e
    [42760.877021] [&lt;1aeaaf74&gt;] tlb_finish_mmu+0x18/0x66
    [42760.883907] [&lt;b3fce717&gt;] exit_mmap+0x76/0xea
    [42760.890428] [&lt;c4c8a2f6&gt;] mmput+0x80/0x11a
    [42760.896632] [&lt;a41a08f4&gt;] do_exit+0x1f4/0x80c
    [42760.903158] [&lt;ee01cef6&gt;] do_group_exit+0x20/0x7e
    [42760.909990] [&lt;13fa8d54&gt;] __wake_up_parent+0x0/0x1e
    [42760.917045] [&lt;46cf89d0&gt;] smp_call_function_many+0x1a2/0x20c
    [42760.924893] [&lt;8c21a93b&gt;] syscall_common+0x14/0x1c
    [42760.931765] ---[ end trace 02aa09da9dc52a60 ]---
    [42760.938342] ------------[ cut here ]------------
    [42760.945311] WARNING: CPU: 2 PID: 1216 at kernel/smp.c:291 smp_call_function_single+0xee/0xf8
    ...

This patch switches MIPS' arch_trigger_cpumask_backtrace() to use async
IPIs &amp; smp_call_function_single_async() in order to resolve this
problem. We ensure use of the pre-allocated call_single_data_t
structures is serialized by maintaining a cpumask indicating that
they're busy, and refusing to attempt to send an IPI when a CPU's bit is
set in this mask. This should only happen if a CPU hasn't responded to a
previous backtrace IPI - ie. if it's hung - and we print a warning to
the console in this case.

I've marked this for stable branches as far back as v4.9, to which it
applies cleanly. Strictly speaking the faulty MIPS implementation can be
traced further back to commit 856839b76836 ("MIPS: Add
arch_trigger_all_cpu_backtrace() function") in v3.19, but kernel
versions v3.19 through v4.8 will require further work to backport due to
the rework performed in commit 9a01c3ed5cdb ("nmi_backtrace: add more
trigger_*_cpu_backtrace() methods").

Signed-off-by: Paul Burton &lt;paul.burton@mips.com&gt;
Patchwork: https://patchwork.linux-mips.org/patch/19597/
Cc: James Hogan &lt;jhogan@kernel.org&gt;
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: Huacai Chen &lt;chenhc@lemote.com&gt;
Cc: linux-mips@linux-mips.org
Cc: stable@vger.kernel.org # v4.9+
Fixes: 856839b76836 ("MIPS: Add arch_trigger_all_cpu_backtrace() function")
Fixes: 9a01c3ed5cdb ("nmi_backtrace: add more trigger_*_cpu_backtrace() methods")
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit b63e132b6433a41cf311e8bc382d33fd2b73b505 upstream.

The current MIPS implementation of arch_trigger_cpumask_backtrace() is
broken because it attempts to use synchronous IPIs despite the fact that
it may be run with interrupts disabled.

This means that when arch_trigger_cpumask_backtrace() is invoked, for
example by the RCU CPU stall watchdog, we may:

  - Deadlock due to use of synchronous IPIs with interrupts disabled,
    causing the CPU that's attempting to generate the backtrace output
    to hang itself.

  - Not succeed in generating the desired output from remote CPUs.

  - Produce warnings about this from smp_call_function_many(), for
    example:

    [42760.526910] INFO: rcu_sched detected stalls on CPUs/tasks:
    [42760.535755]  0-...!: (1 GPs behind) idle=ade/140000000000000/0 softirq=526944/526945 fqs=0
    [42760.547874]  1-...!: (0 ticks this GP) idle=e4a/140000000000000/0 softirq=547885/547885 fqs=0
    [42760.559869]  (detected by 2, t=2162 jiffies, g=266689, c=266688, q=33)
    [42760.568927] ------------[ cut here ]------------
    [42760.576146] WARNING: CPU: 2 PID: 1216 at kernel/smp.c:416 smp_call_function_many+0x88/0x20c
    [42760.587839] Modules linked in:
    [42760.593152] CPU: 2 PID: 1216 Comm: sh Not tainted 4.15.4-00373-gee058bb4d0c2 #2
    [42760.603767] Stack : 8e09bd20 8e09bd20 8e09bd20 fffffff0 00000007 00000006 00000000 8e09bca8
    [42760.616937]         95b2b379 95b2b379 807a0080 00000007 81944518 0000018a 00000032 00000000
    [42760.630095]         00000000 00000030 80000000 00000000 806eca74 00000009 8017e2b8 000001a0
    [42760.643169]         00000000 00000002 00000000 8e09baa4 00000008 808b8008 86d69080 8e09bca0
    [42760.656282]         8e09ad50 805e20aa 00000000 00000000 00000000 8017e2b8 00000009 801070ca
    [42760.669424]         ...
    [42760.673919] Call Trace:
    [42760.678672] [&lt;27fde568&gt;] show_stack+0x70/0xf0
    [42760.685417] [&lt;84751641&gt;] dump_stack+0xaa/0xd0
    [42760.692188] [&lt;699d671c&gt;] __warn+0x80/0x92
    [42760.698549] [&lt;68915d41&gt;] warn_slowpath_null+0x28/0x36
    [42760.705912] [&lt;f7c76c1c&gt;] smp_call_function_many+0x88/0x20c
    [42760.713696] [&lt;6bbdfc2a&gt;] arch_trigger_cpumask_backtrace+0x30/0x4a
    [42760.722216] [&lt;f845bd33&gt;] rcu_dump_cpu_stacks+0x6a/0x98
    [42760.729580] [&lt;796e7629&gt;] rcu_check_callbacks+0x672/0x6ac
    [42760.737476] [&lt;059b3b43&gt;] update_process_times+0x18/0x34
    [42760.744981] [&lt;6eb94941&gt;] tick_sched_handle.isra.5+0x26/0x38
    [42760.752793] [&lt;478d3d70&gt;] tick_sched_timer+0x1c/0x50
    [42760.759882] [&lt;e56ea39f&gt;] __hrtimer_run_queues+0xc6/0x226
    [42760.767418] [&lt;e88bbcae&gt;] hrtimer_interrupt+0x88/0x19a
    [42760.775031] [&lt;6765a19e&gt;] gic_compare_interrupt+0x2e/0x3a
    [42760.782761] [&lt;0558bf5f&gt;] handle_percpu_devid_irq+0x78/0x168
    [42760.790795] [&lt;90c11ba2&gt;] generic_handle_irq+0x1e/0x2c
    [42760.798117] [&lt;1b6d462c&gt;] gic_handle_local_int+0x38/0x86
    [42760.805545] [&lt;b2ada1c7&gt;] gic_irq_dispatch+0xa/0x14
    [42760.812534] [&lt;90c11ba2&gt;] generic_handle_irq+0x1e/0x2c
    [42760.820086] [&lt;c7521934&gt;] do_IRQ+0x16/0x20
    [42760.826274] [&lt;9aef3ce6&gt;] plat_irq_dispatch+0x62/0x94
    [42760.833458] [&lt;6a94b53c&gt;] except_vec_vi_end+0x70/0x78
    [42760.840655] [&lt;22284043&gt;] smp_call_function_many+0x1ba/0x20c
    [42760.848501] [&lt;54022b58&gt;] smp_call_function+0x1e/0x2c
    [42760.855693] [&lt;ab9fc705&gt;] flush_tlb_mm+0x2a/0x98
    [42760.862730] [&lt;0844cdd0&gt;] tlb_flush_mmu+0x1c/0x44
    [42760.869628] [&lt;cb259b74&gt;] arch_tlb_finish_mmu+0x26/0x3e
    [42760.877021] [&lt;1aeaaf74&gt;] tlb_finish_mmu+0x18/0x66
    [42760.883907] [&lt;b3fce717&gt;] exit_mmap+0x76/0xea
    [42760.890428] [&lt;c4c8a2f6&gt;] mmput+0x80/0x11a
    [42760.896632] [&lt;a41a08f4&gt;] do_exit+0x1f4/0x80c
    [42760.903158] [&lt;ee01cef6&gt;] do_group_exit+0x20/0x7e
    [42760.909990] [&lt;13fa8d54&gt;] __wake_up_parent+0x0/0x1e
    [42760.917045] [&lt;46cf89d0&gt;] smp_call_function_many+0x1a2/0x20c
    [42760.924893] [&lt;8c21a93b&gt;] syscall_common+0x14/0x1c
    [42760.931765] ---[ end trace 02aa09da9dc52a60 ]---
    [42760.938342] ------------[ cut here ]------------
    [42760.945311] WARNING: CPU: 2 PID: 1216 at kernel/smp.c:291 smp_call_function_single+0xee/0xf8
    ...

This patch switches MIPS' arch_trigger_cpumask_backtrace() to use async
IPIs &amp; smp_call_function_single_async() in order to resolve this
problem. We ensure use of the pre-allocated call_single_data_t
structures is serialized by maintaining a cpumask indicating that
they're busy, and refusing to attempt to send an IPI when a CPU's bit is
set in this mask. This should only happen if a CPU hasn't responded to a
previous backtrace IPI - ie. if it's hung - and we print a warning to
the console in this case.

I've marked this for stable branches as far back as v4.9, to which it
applies cleanly. Strictly speaking the faulty MIPS implementation can be
traced further back to commit 856839b76836 ("MIPS: Add
arch_trigger_all_cpu_backtrace() function") in v3.19, but kernel
versions v3.19 through v4.8 will require further work to backport due to
the rework performed in commit 9a01c3ed5cdb ("nmi_backtrace: add more
trigger_*_cpu_backtrace() methods").

Signed-off-by: Paul Burton &lt;paul.burton@mips.com&gt;
Patchwork: https://patchwork.linux-mips.org/patch/19597/
Cc: James Hogan &lt;jhogan@kernel.org&gt;
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: Huacai Chen &lt;chenhc@lemote.com&gt;
Cc: linux-mips@linux-mips.org
Cc: stable@vger.kernel.org # v4.9+
Fixes: 856839b76836 ("MIPS: Add arch_trigger_all_cpu_backtrace() function")
Fixes: 9a01c3ed5cdb ("nmi_backtrace: add more trigger_*_cpu_backtrace() methods")
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: Call dump_stack() from show_regs()</title>
<updated>2018-07-17T09:39:23+00:00</updated>
<author>
<name>Paul Burton</name>
<email>paul.burton@mips.com</email>
</author>
<published>2018-06-22T17:55:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=14ab9902422c96cf2ab4db289edaf10ee605059c'/>
<id>14ab9902422c96cf2ab4db289edaf10ee605059c</id>
<content type='text'>
commit 5a267832c2ec47b2dad0fdb291a96bb5b8869315 upstream.

The generic nmi_cpu_backtrace() function calls show_regs() when a struct
pt_regs is available, and dump_stack() otherwise. If we were to make use
of the generic nmi_cpu_backtrace() with MIPS' current implementation of
show_regs() this would mean that we see only register data with no
accompanying stack information, in contrast with our current
implementation which calls dump_stack() regardless of whether register
state is available.

In preparation for making use of the generic nmi_cpu_backtrace() to
implement arch_trigger_cpumask_backtrace(), have our implementation of
show_regs() call dump_stack() and drop the explicit dump_stack() call in
arch_dump_stack() which is invoked by arch_trigger_cpumask_backtrace().

This will allow the output we produce to remain the same after a later
patch switches to using nmi_cpu_backtrace(). It may mean that we produce
extra stack output in other uses of show_regs(), but this:

  1) Seems harmless.
  2) Is good for consistency between arch_trigger_cpumask_backtrace()
     and other users of show_regs().
  3) Matches the behaviour of the ARM &amp; PowerPC architectures.

Marked for stable back to v4.9 as a prerequisite of the following patch
"MIPS: Call dump_stack() from show_regs()".

Signed-off-by: Paul Burton &lt;paul.burton@mips.com&gt;
Patchwork: https://patchwork.linux-mips.org/patch/19596/
Cc: James Hogan &lt;jhogan@kernel.org&gt;
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: Huacai Chen &lt;chenhc@lemote.com&gt;
Cc: linux-mips@linux-mips.org
Cc: stable@vger.kernel.org # v4.9+
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 5a267832c2ec47b2dad0fdb291a96bb5b8869315 upstream.

The generic nmi_cpu_backtrace() function calls show_regs() when a struct
pt_regs is available, and dump_stack() otherwise. If we were to make use
of the generic nmi_cpu_backtrace() with MIPS' current implementation of
show_regs() this would mean that we see only register data with no
accompanying stack information, in contrast with our current
implementation which calls dump_stack() regardless of whether register
state is available.

In preparation for making use of the generic nmi_cpu_backtrace() to
implement arch_trigger_cpumask_backtrace(), have our implementation of
show_regs() call dump_stack() and drop the explicit dump_stack() call in
arch_dump_stack() which is invoked by arch_trigger_cpumask_backtrace().

This will allow the output we produce to remain the same after a later
patch switches to using nmi_cpu_backtrace(). It may mean that we produce
extra stack output in other uses of show_regs(), but this:

  1) Seems harmless.
  2) Is good for consistency between arch_trigger_cpumask_backtrace()
     and other users of show_regs().
  3) Matches the behaviour of the ARM &amp; PowerPC architectures.

Marked for stable back to v4.9 as a prerequisite of the following patch
"MIPS: Call dump_stack() from show_regs()".

Signed-off-by: Paul Burton &lt;paul.burton@mips.com&gt;
Patchwork: https://patchwork.linux-mips.org/patch/19596/
Cc: James Hogan &lt;jhogan@kernel.org&gt;
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: Huacai Chen &lt;chenhc@lemote.com&gt;
Cc: linux-mips@linux-mips.org
Cc: stable@vger.kernel.org # v4.9+
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: prctl: Disallow FRE without FR with PR_SET_FP_MODE requests</title>
<updated>2018-06-05T09:41:58+00:00</updated>
<author>
<name>Maciej W. Rozycki</name>
<email>macro@mips.com</email>
</author>
<published>2018-05-15T22:04:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=8a6576219da8df6c72e6123f1313ad77d8c92288'/>
<id>8a6576219da8df6c72e6123f1313ad77d8c92288</id>
<content type='text'>
commit 28e4213dd331e944e7fca1954a946829162ed9d4 upstream.

Having PR_FP_MODE_FRE (i.e. Config5.FRE) set without PR_FP_MODE_FR (i.e.
Status.FR) is not supported as the lone purpose of Config5.FRE is to
emulate Status.FR=0 handling on FPU hardware that has Status.FR=1
hardwired[1][2].  Also we do not handle this case elsewhere, and assume
throughout our code that TIF_HYBRID_FPREGS and TIF_32BIT_FPREGS cannot
be set both at once for a task, leading to inconsistent behaviour if
this does happen.

Return unsuccessfully then from prctl(2) PR_SET_FP_MODE calls requesting
PR_FP_MODE_FRE to be set with PR_FP_MODE_FR clear.  This corresponds to
modes allowed by `mips_set_personality_fp'.

References:

[1] "MIPS Architecture For Programmers, Vol. III: MIPS32 / microMIPS32
    Privileged Resource Architecture", Imagination Technologies,
    Document Number: MD00090, Revision 6.02, July 10, 2015, Table 9.69
    "Config5 Register Field Descriptions", p. 262

[2] "MIPS Architecture For Programmers, Volume III: MIPS64 / microMIPS64
    Privileged Resource Architecture", Imagination Technologies,
    Document Number: MD00091, Revision 6.03, December 22, 2015, Table
    9.72 "Config5 Register Field Descriptions", p. 288

Fixes: 9791554b45a2 ("MIPS,prctl: add PR_[GS]ET_FP_MODE prctl options for MIPS")
Signed-off-by: Maciej W. Rozycki &lt;macro@mips.com&gt;
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: linux-mips@linux-mips.org
Cc: &lt;stable@vger.kernel.org&gt; # 4.0+
Patchwork: https://patchwork.linux-mips.org/patch/19327/
Signed-off-by: James Hogan &lt;jhogan@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 28e4213dd331e944e7fca1954a946829162ed9d4 upstream.

Having PR_FP_MODE_FRE (i.e. Config5.FRE) set without PR_FP_MODE_FR (i.e.
Status.FR) is not supported as the lone purpose of Config5.FRE is to
emulate Status.FR=0 handling on FPU hardware that has Status.FR=1
hardwired[1][2].  Also we do not handle this case elsewhere, and assume
throughout our code that TIF_HYBRID_FPREGS and TIF_32BIT_FPREGS cannot
be set both at once for a task, leading to inconsistent behaviour if
this does happen.

Return unsuccessfully then from prctl(2) PR_SET_FP_MODE calls requesting
PR_FP_MODE_FRE to be set with PR_FP_MODE_FR clear.  This corresponds to
modes allowed by `mips_set_personality_fp'.

References:

[1] "MIPS Architecture For Programmers, Vol. III: MIPS32 / microMIPS32
    Privileged Resource Architecture", Imagination Technologies,
    Document Number: MD00090, Revision 6.02, July 10, 2015, Table 9.69
    "Config5 Register Field Descriptions", p. 262

[2] "MIPS Architecture For Programmers, Volume III: MIPS64 / microMIPS64
    Privileged Resource Architecture", Imagination Technologies,
    Document Number: MD00091, Revision 6.03, December 22, 2015, Table
    9.72 "Config5 Register Field Descriptions", p. 288

Fixes: 9791554b45a2 ("MIPS,prctl: add PR_[GS]ET_FP_MODE prctl options for MIPS")
Signed-off-by: Maciej W. Rozycki &lt;macro@mips.com&gt;
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: linux-mips@linux-mips.org
Cc: &lt;stable@vger.kernel.org&gt; # 4.0+
Patchwork: https://patchwork.linux-mips.org/patch/19327/
Signed-off-by: James Hogan &lt;jhogan@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: Validate PR_SET_FP_MODE prctl(2) requests against the ABI of the task</title>
<updated>2018-01-17T08:45:17+00:00</updated>
<author>
<name>Maciej W. Rozycki</name>
<email>macro@mips.com</email>
</author>
<published>2017-11-27T09:33:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a8caed0170147c55daf79793d72ed01b16610cf1'/>
<id>a8caed0170147c55daf79793d72ed01b16610cf1</id>
<content type='text'>
commit b67336eee3fcb8ecedc6c13e2bf88aacfa3151e2 upstream.

Fix an API loophole introduced with commit 9791554b45a2 ("MIPS,prctl:
add PR_[GS]ET_FP_MODE prctl options for MIPS"), where the caller of
prctl(2) is incorrectly allowed to make a change to CP0.Status.FR or
CP0.Config5.FRE register bits even if CONFIG_MIPS_O32_FP64_SUPPORT has
not been enabled, despite that an executable requesting the mode
requested via ELF file annotation would not be allowed to run in the
first place, or for n64 and n64 ABI tasks which do not have non-default
modes defined at all.  Add suitable checks to `mips_set_process_fp_mode'
and bail out if an invalid mode change has been requested for the ABI in
effect, even if the FPU hardware or emulation would otherwise allow it.

Always succeed however without taking any further action if the mode
requested is the same as one already in effect, regardless of whether
any mode change, should it be requested, would actually be allowed for
the task concerned.

Signed-off-by: Maciej W. Rozycki &lt;macro@mips.com&gt;
Fixes: 9791554b45a2 ("MIPS,prctl: add PR_[GS]ET_FP_MODE prctl options for MIPS")
Reviewed-by: Paul Burton &lt;paul.burton@mips.com&gt;
Cc: James Hogan &lt;james.hogan@mips.com&gt;
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/17800/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit b67336eee3fcb8ecedc6c13e2bf88aacfa3151e2 upstream.

Fix an API loophole introduced with commit 9791554b45a2 ("MIPS,prctl:
add PR_[GS]ET_FP_MODE prctl options for MIPS"), where the caller of
prctl(2) is incorrectly allowed to make a change to CP0.Status.FR or
CP0.Config5.FRE register bits even if CONFIG_MIPS_O32_FP64_SUPPORT has
not been enabled, despite that an executable requesting the mode
requested via ELF file annotation would not be allowed to run in the
first place, or for n64 and n64 ABI tasks which do not have non-default
modes defined at all.  Add suitable checks to `mips_set_process_fp_mode'
and bail out if an invalid mode change has been requested for the ABI in
effect, even if the FPU hardware or emulation would otherwise allow it.

Always succeed however without taking any further action if the mode
requested is the same as one already in effect, regardless of whether
any mode change, should it be requested, would actually be allowed for
the task concerned.

Signed-off-by: Maciej W. Rozycki &lt;macro@mips.com&gt;
Fixes: 9791554b45a2 ("MIPS,prctl: add PR_[GS]ET_FP_MODE prctl options for MIPS")
Reviewed-by: Paul Burton &lt;paul.burton@mips.com&gt;
Cc: James Hogan &lt;james.hogan@mips.com&gt;
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/17800/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: Refactor handling of stack pointer in get_frame_info</title>
<updated>2017-09-06T11:21:44+00:00</updated>
<author>
<name>Matt Redfearn</name>
<email>matt.redfearn@imgtec.com</email>
</author>
<published>2017-08-08T12:22:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=56dfb7001a396ef6c7928adcb890043ff55e9977'/>
<id>56dfb7001a396ef6c7928adcb890043ff55e9977</id>
<content type='text'>
Commit 34c2f668d0f6 ("MIPS: microMIPS: Add unaligned access support.")
added handling of microMIPS instructions to manipulate the stack
pointer. The code that was added violates code style rules with long
lines caused by lots of nested conditionals.

The added code interprets (inline) any known stack pointer manipulation
instruction to find the stack frame size. Handling the microMIPS cases
added quite a bit of complication to this function.

Refactor is_sp_move_ins to perform the interpretation of the immediate
as the instruction manipulating the stack pointer is found. This reduces
the amount of indentation required in get_frame_info, and more closely
matches the operation of is_ra_save_ins.

Suggested-by: Maciej W. Rozycki &lt;macro@imgtec.com&gt;
Signed-off-by: Matt Redfearn &lt;matt.redfearn@imgtec.com&gt;
Cc: Marcin Nowakowski &lt;marcin.nowakowski@imgtec.com&gt;
Cc: Ingo Molnar &lt;mingo@kernel.org&gt;
Cc: Paul Burton &lt;paul.burton@imgtec.com&gt;
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/16958/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Commit 34c2f668d0f6 ("MIPS: microMIPS: Add unaligned access support.")
added handling of microMIPS instructions to manipulate the stack
pointer. The code that was added violates code style rules with long
lines caused by lots of nested conditionals.

The added code interprets (inline) any known stack pointer manipulation
instruction to find the stack frame size. Handling the microMIPS cases
added quite a bit of complication to this function.

Refactor is_sp_move_ins to perform the interpretation of the immediate
as the instruction manipulating the stack pointer is found. This reduces
the amount of indentation required in get_frame_info, and more closely
matches the operation of is_ra_save_ins.

Suggested-by: Maciej W. Rozycki &lt;macro@imgtec.com&gt;
Signed-off-by: Matt Redfearn &lt;matt.redfearn@imgtec.com&gt;
Cc: Marcin Nowakowski &lt;marcin.nowakowski@imgtec.com&gt;
Cc: Ingo Molnar &lt;mingo@kernel.org&gt;
Cc: Paul Burton &lt;paul.burton@imgtec.com&gt;
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/16958/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: Stacktrace: Fix microMIPS stack unwinding on big endian systems</title>
<updated>2017-09-06T11:21:00+00:00</updated>
<author>
<name>Matt Redfearn</name>
<email>matt.redfearn@imgtec.com</email>
</author>
<published>2017-08-08T12:22:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=41885b02127c7ae169dc94542de4a8eed175495a'/>
<id>41885b02127c7ae169dc94542de4a8eed175495a</id>
<content type='text'>
The stack unwinding code uses the mips_instuction union to decode the
instructions it finds. That union uses the __BITFIELD_FIELD macro to
reorder depending on endianness. The stack unwinding code always places
16bit instructions in halfword 1 of the union. This makes the union
accesses correct for little endian systems. Similarly, 32bit
instructions are reordered such that they are correct for little endian
systems. This handling leaves unwinding the stack on big endian systems
broken, as the mips_instruction union will then look for the fields in
the wrong halfword.

To fix this, use a logical shift to place the 16bit instruction into the
correct position in the word field of the union. Use the same shifting
to order the 2 halfwords of 32bit instuctions. Then replace accesses to
the halfword with accesses to the shifted word.
In the case of the ADDIUS5 instruction, switch to using the
mm16_r5_format union member to avoid the need for a 16bit shift.

Fixes: 34c2f668d0f6 ("MIPS: microMIPS: Add unaligned access support.")
Signed-off-by: Matt Redfearn &lt;matt.redfearn@imgtec.com&gt;
Reviewed-by: James Hogan &lt;james.hogan@imgtec.com&gt;
Cc: Marcin Nowakowski &lt;marcin.nowakowski@imgtec.com&gt;
Cc: Ingo Molnar &lt;mingo@kernel.org&gt;
Cc: Paul Burton &lt;paul.burton@imgtec.com&gt;
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/16956/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The stack unwinding code uses the mips_instuction union to decode the
instructions it finds. That union uses the __BITFIELD_FIELD macro to
reorder depending on endianness. The stack unwinding code always places
16bit instructions in halfword 1 of the union. This makes the union
accesses correct for little endian systems. Similarly, 32bit
instructions are reordered such that they are correct for little endian
systems. This handling leaves unwinding the stack on big endian systems
broken, as the mips_instruction union will then look for the fields in
the wrong halfword.

To fix this, use a logical shift to place the 16bit instruction into the
correct position in the word field of the union. Use the same shifting
to order the 2 halfwords of 32bit instuctions. Then replace accesses to
the halfword with accesses to the shifted word.
In the case of the ADDIUS5 instruction, switch to using the
mm16_r5_format union member to avoid the need for a 16bit shift.

Fixes: 34c2f668d0f6 ("MIPS: microMIPS: Add unaligned access support.")
Signed-off-by: Matt Redfearn &lt;matt.redfearn@imgtec.com&gt;
Reviewed-by: James Hogan &lt;james.hogan@imgtec.com&gt;
Cc: Marcin Nowakowski &lt;marcin.nowakowski@imgtec.com&gt;
Cc: Ingo Molnar &lt;mingo@kernel.org&gt;
Cc: Paul Burton &lt;paul.burton@imgtec.com&gt;
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/16956/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: microMIPS: Fix decoding of swsp16 instruction</title>
<updated>2017-09-06T11:20:25+00:00</updated>
<author>
<name>Matt Redfearn</name>
<email>matt.redfearn@imgtec.com</email>
</author>
<published>2017-08-08T12:22:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=cea8cd498f4f1c30ea27e3664b3c671e495c4fce'/>
<id>cea8cd498f4f1c30ea27e3664b3c671e495c4fce</id>
<content type='text'>
When the immediate encoded in the instruction is accessed, it is sign
extended due to being a signed value being assigned to a signed integer.
The ISA specifies that this operation is an unsigned operation.
The sign extension leads us to incorrectly decode:

801e9c8e:       cbf1            sw      ra,68(sp)

As having an immediate of 1073741809.

Since the instruction format does not specify signed/unsigned, and this
is currently the only location to use this instuction format, change it
to an unsigned immediate.

Fixes: bb9bc4689b9c ("MIPS: Calculate microMIPS ra properly when unwinding the stack")
Suggested-by: Paul Burton &lt;paul.burton@imgtec.com&gt;
Signed-off-by: Matt Redfearn &lt;matt.redfearn@imgtec.com&gt;
Reviewed-by: James Hogan &lt;james.hogan@imgtec.com&gt;
Cc: Marcin Nowakowski &lt;marcin.nowakowski@imgtec.com&gt;
Cc: Miodrag Dinic &lt;miodrag.dinic@imgtec.com&gt;
Cc: Ingo Molnar &lt;mingo@kernel.org&gt;
Cc: David Daney &lt;david.daney@cavium.com&gt;
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/16957/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When the immediate encoded in the instruction is accessed, it is sign
extended due to being a signed value being assigned to a signed integer.
The ISA specifies that this operation is an unsigned operation.
The sign extension leads us to incorrectly decode:

801e9c8e:       cbf1            sw      ra,68(sp)

As having an immediate of 1073741809.

Since the instruction format does not specify signed/unsigned, and this
is currently the only location to use this instuction format, change it
to an unsigned immediate.

Fixes: bb9bc4689b9c ("MIPS: Calculate microMIPS ra properly when unwinding the stack")
Suggested-by: Paul Burton &lt;paul.burton@imgtec.com&gt;
Signed-off-by: Matt Redfearn &lt;matt.redfearn@imgtec.com&gt;
Reviewed-by: James Hogan &lt;james.hogan@imgtec.com&gt;
Cc: Marcin Nowakowski &lt;marcin.nowakowski@imgtec.com&gt;
Cc: Miodrag Dinic &lt;miodrag.dinic@imgtec.com&gt;
Cc: Ingo Molnar &lt;mingo@kernel.org&gt;
Cc: David Daney &lt;david.daney@cavium.com&gt;
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/16957/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: microMIPS: Fix decoding of addiusp instruction</title>
<updated>2017-09-06T11:19:49+00:00</updated>
<author>
<name>Matt Redfearn</name>
<email>matt.redfearn@imgtec.com</email>
</author>
<published>2017-08-08T12:22:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a0ae2b08331a9882150618e0c81ea837e4a37ace'/>
<id>a0ae2b08331a9882150618e0c81ea837e4a37ace</id>
<content type='text'>
Commit 34c2f668d0f6 ("MIPS: microMIPS: Add unaligned access support.")
added handling of microMIPS instructions to manipulate the stack
pointer. Unfortunately the decoding of the addiusp instruction was
incorrect, and performed a left shift by 2 bits to the raw immediate,
rather than decoding the immediate and then performing the shift, as
documented in the ISA.

This led to incomplete stack traces, due to incorrect frame sizes being
calculated. For example the instruction:
801faee0 &lt;do_sys_poll&gt;:
801faee0:       4e25            addiu   sp,sp,-952

As decoded by objdump, would be interpreted by the existing code as
having manipulated the stack pointer by +1096.

Fix this by changing the order of decoding the immediate and applying
the left shift. Also change to accessing the instuction through the
union to avoid the endianness problem of accesing halfword[0], which
will fail on big endian systems.

Cope with the special behaviour of immediates 0x0, 0x1, 0x1fe and 0x1ff
by XORing with 0x100 again if mod(immediate) &lt; 4. This logic was tested
with the following test code:

int main(int argc, char **argv)
{
	unsigned int enc;
	int imm;

	for (enc = 0; enc &lt; 512; ++enc) {
		int tmp = enc &lt;&lt; 2;
		imm = -(signed short)(tmp | ((tmp &amp; 0x100) ? 0xfe00 : 0));
		unsigned short tmp = enc;
		tmp = (tmp ^ 0x100) - 0x100;
		if ((unsigned short)(tmp + 2) &lt; 4)
			tmp ^= 0x100;
		imm = -(signed short)(tmp &lt;&lt; 2);
		printf("%#x\t%d\t-&gt;\t(%#x\t%d)\t%#x\t%d\n",
		       enc, enc,
		       (short)tmp, (short)tmp,
		       imm, imm);
	}
	return EXIT_SUCCESS;
}

Which generates the table:

input encoding	-&gt;	tmp (matching manual)	frame size
-----------------------------------------------------------------------
0	0	-&gt;	(0x100		256)	0xfffffc00	-1024
0x1	1	-&gt;	(0x101		257)	0xfffffbfc	-1028
0x2	2	-&gt;	(0x2		2)	0xfffffff8	-8
0x3	3	-&gt;	(0x3		3)	0xfffffff4	-12
...
0xfe	254	-&gt;	(0xfe		254)	0xfffffc08	-1016
0xff	255	-&gt;	(0xff		255)	0xfffffc04	-1020
0x100	256	-&gt;	(0xffffff00	-256)	0x400		1024
0x101	257	-&gt;	(0xffffff01	-255)	0x3fc		1020
...
0x1fc	508	-&gt;	(0xfffffffc	-4)	0x10		16
0x1fd	509	-&gt;	(0xfffffffd	-3)	0xc		12
0x1fe	510	-&gt;	(0xfffffefe	-258)	0x408		1032
0x1ff	511	-&gt;	(0xfffffeff	-257)	0x404		1028

Thanks to James Hogan for the test code &amp; verifying the logic.

Fixes: 34c2f668d0f6 ("MIPS: microMIPS: Add unaligned access support.")
Suggested-by: James Hogan &lt;james.hogan@imgtec.com&gt;
Signed-off-by: Matt Redfearn &lt;matt.redfearn@imgtec.com&gt;
Cc: Marcin Nowakowski &lt;marcin.nowakowski@imgtec.com&gt;
Cc: Ingo Molnar &lt;mingo@kernel.org&gt;
Cc: Paul Burton &lt;paul.burton@imgtec.com&gt;
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/16955/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Commit 34c2f668d0f6 ("MIPS: microMIPS: Add unaligned access support.")
added handling of microMIPS instructions to manipulate the stack
pointer. Unfortunately the decoding of the addiusp instruction was
incorrect, and performed a left shift by 2 bits to the raw immediate,
rather than decoding the immediate and then performing the shift, as
documented in the ISA.

This led to incomplete stack traces, due to incorrect frame sizes being
calculated. For example the instruction:
801faee0 &lt;do_sys_poll&gt;:
801faee0:       4e25            addiu   sp,sp,-952

As decoded by objdump, would be interpreted by the existing code as
having manipulated the stack pointer by +1096.

Fix this by changing the order of decoding the immediate and applying
the left shift. Also change to accessing the instuction through the
union to avoid the endianness problem of accesing halfword[0], which
will fail on big endian systems.

Cope with the special behaviour of immediates 0x0, 0x1, 0x1fe and 0x1ff
by XORing with 0x100 again if mod(immediate) &lt; 4. This logic was tested
with the following test code:

int main(int argc, char **argv)
{
	unsigned int enc;
	int imm;

	for (enc = 0; enc &lt; 512; ++enc) {
		int tmp = enc &lt;&lt; 2;
		imm = -(signed short)(tmp | ((tmp &amp; 0x100) ? 0xfe00 : 0));
		unsigned short tmp = enc;
		tmp = (tmp ^ 0x100) - 0x100;
		if ((unsigned short)(tmp + 2) &lt; 4)
			tmp ^= 0x100;
		imm = -(signed short)(tmp &lt;&lt; 2);
		printf("%#x\t%d\t-&gt;\t(%#x\t%d)\t%#x\t%d\n",
		       enc, enc,
		       (short)tmp, (short)tmp,
		       imm, imm);
	}
	return EXIT_SUCCESS;
}

Which generates the table:

input encoding	-&gt;	tmp (matching manual)	frame size
-----------------------------------------------------------------------
0	0	-&gt;	(0x100		256)	0xfffffc00	-1024
0x1	1	-&gt;	(0x101		257)	0xfffffbfc	-1028
0x2	2	-&gt;	(0x2		2)	0xfffffff8	-8
0x3	3	-&gt;	(0x3		3)	0xfffffff4	-12
...
0xfe	254	-&gt;	(0xfe		254)	0xfffffc08	-1016
0xff	255	-&gt;	(0xff		255)	0xfffffc04	-1020
0x100	256	-&gt;	(0xffffff00	-256)	0x400		1024
0x101	257	-&gt;	(0xffffff01	-255)	0x3fc		1020
...
0x1fc	508	-&gt;	(0xfffffffc	-4)	0x10		16
0x1fd	509	-&gt;	(0xfffffffd	-3)	0xc		12
0x1fe	510	-&gt;	(0xfffffefe	-258)	0x408		1032
0x1ff	511	-&gt;	(0xfffffeff	-257)	0x404		1028

Thanks to James Hogan for the test code &amp; verifying the logic.

Fixes: 34c2f668d0f6 ("MIPS: microMIPS: Add unaligned access support.")
Suggested-by: James Hogan &lt;james.hogan@imgtec.com&gt;
Signed-off-by: Matt Redfearn &lt;matt.redfearn@imgtec.com&gt;
Cc: Marcin Nowakowski &lt;marcin.nowakowski@imgtec.com&gt;
Cc: Ingo Molnar &lt;mingo@kernel.org&gt;
Cc: Paul Burton &lt;paul.burton@imgtec.com&gt;
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/16955/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
