<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/arch, branch v3.11.7</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>ARM: integrator: deactivate timer0 on the Integrator/CP</title>
<updated>2013-11-04T12:35:19+00:00</updated>
<author>
<name>Linus Walleij</name>
<email>linus.walleij@linaro.org</email>
</author>
<published>2013-10-07T13:19:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b0e0b97c59f6116b12cd33c59aa803a8aac1f6e0'/>
<id>b0e0b97c59f6116b12cd33c59aa803a8aac1f6e0</id>
<content type='text'>
commit 29114fd7db2fc82a34da8340d29b8fa413e03dca upstream.

This fixes a long-standing Integrator/CP regression from
commit 870e2928cf3368ca9b06bc925d0027b0a56bcd8e
"ARM: integrator-cp: convert use CLKSRC_OF for timer init"

When this code was introduced, the both aliases pointing the
system to use timer1 as primary (clocksource) and timer2
as secondary (clockevent) was ignored, and the system would
simply use the first two timers found as clocksource and
clockevent.

However this made the system timeline accelerate by a
factor x25, as it turns out that the way the clocking
actually works (totally undocumented and found after some
trial-and-error) is that timer0 runs @ 25MHz and timer1
and timer2 runs @ 1MHz. Presumably this divider setting
is a boot-on default and configurable albeit the way to
configure it is not documented.

So as a quick fix to the problem, let's mark timer0 as
disabled, so the code will chose timer1 and timer2 as it
used to.

This also deletes the two aliases for the primary and
secondary timer as they have been superceded by the
auto-selection

Cc: Rob Herring &lt;rob.herring@calxeda.com&gt;
Cc: Russell King &lt;linux@arm.linux.org.uk&gt;
Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Signed-off-by: Olof Johansson &lt;olof@lixom.net&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 29114fd7db2fc82a34da8340d29b8fa413e03dca upstream.

This fixes a long-standing Integrator/CP regression from
commit 870e2928cf3368ca9b06bc925d0027b0a56bcd8e
"ARM: integrator-cp: convert use CLKSRC_OF for timer init"

When this code was introduced, the both aliases pointing the
system to use timer1 as primary (clocksource) and timer2
as secondary (clockevent) was ignored, and the system would
simply use the first two timers found as clocksource and
clockevent.

However this made the system timeline accelerate by a
factor x25, as it turns out that the way the clocking
actually works (totally undocumented and found after some
trial-and-error) is that timer0 runs @ 25MHz and timer1
and timer2 runs @ 1MHz. Presumably this divider setting
is a boot-on default and configurable albeit the way to
configure it is not documented.

So as a quick fix to the problem, let's mark timer0 as
disabled, so the code will chose timer1 and timer2 as it
used to.

This also deletes the two aliases for the primary and
secondary timer as they have been superceded by the
auto-selection

Cc: Rob Herring &lt;rob.herring@calxeda.com&gt;
Cc: Russell King &lt;linux@arm.linux.org.uk&gt;
Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Signed-off-by: Olof Johansson &lt;olof@lixom.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: 7851/1: check for number of arguments in syscall_get/set_arguments()</title>
<updated>2013-11-04T12:35:18+00:00</updated>
<author>
<name>AKASHI Takahiro</name>
<email>takahiro.akashi@linaro.org</email>
</author>
<published>2013-10-09T14:58:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=3ec722ae43d74f5ab13e89999245c1ce862fe3ea'/>
<id>3ec722ae43d74f5ab13e89999245c1ce862fe3ea</id>
<content type='text'>
commit 3c1532df5c1b54b5f6246cdef94eeb73a39fe43a upstream.

In ftrace_syscall_enter(),
    syscall_get_arguments(..., 0, n, ...)
        if (i == 0) { &lt;handle ORIG_r0&gt; ...; n--;}
        memcpy(..., n * sizeof(args[0]));
If 'number of arguments(n)' is zero and 'argument index(i)' is also zero in
syscall_get_arguments(), none of arguments should be copied by memcpy().
Otherwise 'n--' can be a big positive number and unexpected amount of data
will be copied. Tracing system calls which take no argument, say sync(void),
may hit this case and eventually make the system corrupted.
This patch fixes the issue both in syscall_get_arguments() and
syscall_set_arguments().

Acked-by: Will Deacon &lt;will.deacon@arm.com&gt;
Signed-off-by: AKASHI Takahiro &lt;takahiro.akashi@linaro.org&gt;
Signed-off-by: Will Deacon &lt;will.deacon@arm.com&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&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 3c1532df5c1b54b5f6246cdef94eeb73a39fe43a upstream.

In ftrace_syscall_enter(),
    syscall_get_arguments(..., 0, n, ...)
        if (i == 0) { &lt;handle ORIG_r0&gt; ...; n--;}
        memcpy(..., n * sizeof(args[0]));
If 'number of arguments(n)' is zero and 'argument index(i)' is also zero in
syscall_get_arguments(), none of arguments should be copied by memcpy().
Otherwise 'n--' can be a big positive number and unexpected amount of data
will be copied. Tracing system calls which take no argument, say sync(void),
may hit this case and eventually make the system corrupted.
This patch fixes the issue both in syscall_get_arguments() and
syscall_set_arguments().

Acked-by: Will Deacon &lt;will.deacon@arm.com&gt;
Signed-off-by: AKASHI Takahiro &lt;takahiro.akashi@linaro.org&gt;
Signed-off-by: Will Deacon &lt;will.deacon@arm.com&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>x86: avoid remapping data in parse_setup_data()</title>
<updated>2013-10-18T17:55:02+00:00</updated>
<author>
<name>Linn Crosetto</name>
<email>linn@hp.com</email>
</author>
<published>2013-08-13T21:46:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=587326a4cd292acf89704fb6e7e6e73fab87da44'/>
<id>587326a4cd292acf89704fb6e7e6e73fab87da44</id>
<content type='text'>
commit 30e46b574a1db7d14404e52dca8e1aa5f5155fd2 upstream.

Type SETUP_PCI, added by setup_efi_pci(), may advertise a ROM size
larger than early_memremap() is able to handle, which is currently
limited to 256kB. If this occurs it leads to a NULL dereference in
parse_setup_data().

To avoid this, remap the setup_data header and allow parsing functions
for individual types to handle their own data remapping.

Signed-off-by: Linn Crosetto &lt;linn@hp.com&gt;
Link: http://lkml.kernel.org/r/1376430401-67445-1-git-send-email-linn@hp.com
Acked-by: Yinghai Lu &lt;yinghai@kernel.org&gt;
Reviewed-by: Pekka Enberg &lt;penberg@kernel.org&gt;
Signed-off-by: H. Peter Anvin &lt;hpa@linux.intel.com&gt;
Cc: Paul Gortmaker &lt;paul.gortmaker@windriver.com&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 30e46b574a1db7d14404e52dca8e1aa5f5155fd2 upstream.

Type SETUP_PCI, added by setup_efi_pci(), may advertise a ROM size
larger than early_memremap() is able to handle, which is currently
limited to 256kB. If this occurs it leads to a NULL dereference in
parse_setup_data().

To avoid this, remap the setup_data header and allow parsing functions
for individual types to handle their own data remapping.

Signed-off-by: Linn Crosetto &lt;linn@hp.com&gt;
Link: http://lkml.kernel.org/r/1376430401-67445-1-git-send-email-linn@hp.com
Acked-by: Yinghai Lu &lt;yinghai@kernel.org&gt;
Reviewed-by: Pekka Enberg &lt;penberg@kernel.org&gt;
Signed-off-by: H. Peter Anvin &lt;hpa@linux.intel.com&gt;
Cc: Paul Gortmaker &lt;paul.gortmaker@windriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>compiler/gcc4: Add quirk for 'asm goto' miscompilation bug</title>
<updated>2013-10-18T17:54:57+00:00</updated>
<author>
<name>Ingo Molnar</name>
<email>mingo@kernel.org</email>
</author>
<published>2013-10-10T08:16:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=586ff7faf652f1f44576adb63bd2fa7c9ae8c08b'/>
<id>586ff7faf652f1f44576adb63bd2fa7c9ae8c08b</id>
<content type='text'>
commit 3f0116c3238a96bc18ad4b4acefe4e7be32fa861 upstream.

Fengguang Wu, Oleg Nesterov and Peter Zijlstra tracked down
a kernel crash to a GCC bug: GCC miscompiles certain 'asm goto'
constructs, as outlined here:

  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58670

Implement a workaround suggested by Jakub Jelinek.

Reported-and-tested-by: Fengguang Wu &lt;fengguang.wu@intel.com&gt;
Reported-by: Oleg Nesterov &lt;oleg@redhat.com&gt;
Reported-by: Peter Zijlstra &lt;a.p.zijlstra@chello.nl&gt;
Suggested-by: Jakub Jelinek &lt;jakub@redhat.com&gt;
Reviewed-by: Richard Henderson &lt;rth@twiddle.net&gt;
Cc: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Cc: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Link: http://lkml.kernel.org/r/20131015062351.GA4666@gmail.com
Signed-off-by: Ingo Molnar &lt;mingo@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 3f0116c3238a96bc18ad4b4acefe4e7be32fa861 upstream.

Fengguang Wu, Oleg Nesterov and Peter Zijlstra tracked down
a kernel crash to a GCC bug: GCC miscompiles certain 'asm goto'
constructs, as outlined here:

  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58670

Implement a workaround suggested by Jakub Jelinek.

Reported-and-tested-by: Fengguang Wu &lt;fengguang.wu@intel.com&gt;
Reported-by: Oleg Nesterov &lt;oleg@redhat.com&gt;
Reported-by: Peter Zijlstra &lt;a.p.zijlstra@chello.nl&gt;
Suggested-by: Jakub Jelinek &lt;jakub@redhat.com&gt;
Reviewed-by: Richard Henderson &lt;rth@twiddle.net&gt;
Cc: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Cc: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Link: http://lkml.kernel.org/r/20131015062351.GA4666@gmail.com
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: stack protector: Fix per-task canary switch</title>
<updated>2013-10-18T17:54:57+00:00</updated>
<author>
<name>James Hogan</name>
<email>james.hogan@imgtec.com</email>
</author>
<published>2013-10-07T11:14:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=7e7db3b653c929be0f98bc733fa8eb19f9d9bee8'/>
<id>7e7db3b653c929be0f98bc733fa8eb19f9d9bee8</id>
<content type='text'>
commit 8b3c569a3999a8fd5a819f892525ab5520777c92 upstream.

Commit 1400eb6 (MIPS: r4k,octeon,r2300: stack protector: change canary
per task) was merged in v3.11 and introduced assembly in the MIPS resume
functions to update the value of the current canary in
__stack_chk_guard. However it used PTR_L resulting in a load of the
canary value, instead of PTR_LA to construct its address. The value is
intended to be random but is then treated as an address in the
subsequent LONG_S (store).

This was observed to cause a fault and panic:

CPU 0 Unable to handle kernel paging request at virtual address 139fea20, epc == 8000cc0c, ra == 8034f2a4
Oops[#1]:
...
$24   : 139fea20 1e1f7cb6
...
Call Trace:
[&lt;8000cc0c&gt;] resume+0xac/0x118
[&lt;8034f2a4&gt;] __schedule+0x5f8/0x78c
[&lt;8034f4e0&gt;] schedule_preempt_disabled+0x20/0x2c
[&lt;80348eec&gt;] rest_init+0x74/0x84
[&lt;804dc990&gt;] start_kernel+0x43c/0x454
Code: 3c18804b  8f184030  8cb901f8 &lt;af190000&gt; 00c0e021  8cb002f0 8cb102f4  8cb202f8  8cb302fc

This can also be forced by modifying
arch/mips/include/asm/stackprotector.h so that the default
__stack_chk_guard value is more likely to be a bad (or unaligned)
pointer.

Fix it to use PTR_LA instead, to load the address of the canary value,
which the LONG_S can then use to write into it.

Reported-by: bobjones (via #mipslinux on IRC)
Signed-off-by: James Hogan &lt;james.hogan@imgtec.com&gt;
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: Gregory Fong &lt;gregory.0xf0@gmail.com&gt;
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/6026/
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 8b3c569a3999a8fd5a819f892525ab5520777c92 upstream.

Commit 1400eb6 (MIPS: r4k,octeon,r2300: stack protector: change canary
per task) was merged in v3.11 and introduced assembly in the MIPS resume
functions to update the value of the current canary in
__stack_chk_guard. However it used PTR_L resulting in a load of the
canary value, instead of PTR_LA to construct its address. The value is
intended to be random but is then treated as an address in the
subsequent LONG_S (store).

This was observed to cause a fault and panic:

CPU 0 Unable to handle kernel paging request at virtual address 139fea20, epc == 8000cc0c, ra == 8034f2a4
Oops[#1]:
...
$24   : 139fea20 1e1f7cb6
...
Call Trace:
[&lt;8000cc0c&gt;] resume+0xac/0x118
[&lt;8034f2a4&gt;] __schedule+0x5f8/0x78c
[&lt;8034f4e0&gt;] schedule_preempt_disabled+0x20/0x2c
[&lt;80348eec&gt;] rest_init+0x74/0x84
[&lt;804dc990&gt;] start_kernel+0x43c/0x454
Code: 3c18804b  8f184030  8cb901f8 &lt;af190000&gt; 00c0e021  8cb002f0 8cb102f4  8cb202f8  8cb302fc

This can also be forced by modifying
arch/mips/include/asm/stackprotector.h so that the default
__stack_chk_guard value is more likely to be a bad (or unaligned)
pointer.

Fix it to use PTR_LA instead, to load the address of the canary value,
which the LONG_S can then use to write into it.

Reported-by: bobjones (via #mipslinux on IRC)
Signed-off-by: James Hogan &lt;james.hogan@imgtec.com&gt;
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: Gregory Fong &lt;gregory.0xf0@gmail.com&gt;
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/6026/
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>ARC: Ignore ptrace SETREGSET request for synthetic register "stop_pc"</title>
<updated>2013-10-18T17:54:56+00:00</updated>
<author>
<name>Vineet Gupta</name>
<email>vgupta@synopsys.com</email>
</author>
<published>2013-10-10T14:03:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a04324b3536234679d98bc98fc37ccd755440446'/>
<id>a04324b3536234679d98bc98fc37ccd755440446</id>
<content type='text'>
commit 5b24282846c064ee90d40fcb3a8f63b8e754fd28 upstream.

ARCompact TRAP_S insn used for breakpoints, commits before exception is
taken (updating architectural PC). So ptregs-&gt;ret contains next-PC and
not the breakpoint PC itself. This is different from other restartable
exceptions such as TLB Miss where ptregs-&gt;ret has exact faulting PC.
gdb needs to know exact-PC hence ARC ptrace GETREGSET provides for
@stop_pc which returns ptregs-&gt;ret vs. EFA depending on the
situation.

However, writing stop_pc (SETREGSET request), which updates ptregs-&gt;ret
doesn't makes sense stop_pc doesn't always correspond to that reg as
described above.

This was not an issue so far since user_regs-&gt;ret / user_regs-&gt;stop_pc
had same value and both writing to ptregs-&gt;ret was OK, needless, but NOT
broken, hence not observed.

With gdb "jump", they diverge, and user_regs-&gt;ret updating ptregs is
overwritten immediately with stop_pc, which this patch fixes.

Reported-by: Anton Kolesov &lt;akolesov@synopsys.com&gt;
Signed-off-by: Vineet Gupta &lt;vgupta@synopsys.com&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 5b24282846c064ee90d40fcb3a8f63b8e754fd28 upstream.

ARCompact TRAP_S insn used for breakpoints, commits before exception is
taken (updating architectural PC). So ptregs-&gt;ret contains next-PC and
not the breakpoint PC itself. This is different from other restartable
exceptions such as TLB Miss where ptregs-&gt;ret has exact faulting PC.
gdb needs to know exact-PC hence ARC ptrace GETREGSET provides for
@stop_pc which returns ptregs-&gt;ret vs. EFA depending on the
situation.

However, writing stop_pc (SETREGSET request), which updates ptregs-&gt;ret
doesn't makes sense stop_pc doesn't always correspond to that reg as
described above.

This was not an issue so far since user_regs-&gt;ret / user_regs-&gt;stop_pc
had same value and both writing to ptregs-&gt;ret was OK, needless, but NOT
broken, hence not observed.

With gdb "jump", they diverge, and user_regs-&gt;ret updating ptregs is
overwritten immediately with stop_pc, which this patch fixes.

Reported-by: Anton Kolesov &lt;akolesov@synopsys.com&gt;
Signed-off-by: Vineet Gupta &lt;vgupta@synopsys.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ARC: Fix signal frame management for SA_SIGINFO</title>
<updated>2013-10-18T17:54:56+00:00</updated>
<author>
<name>Christian Ruppert</name>
<email>christian.ruppert@abilis.com</email>
</author>
<published>2013-10-02T09:13:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a4e42e8bbdc9fb7482dd181c332ae668c15f1750'/>
<id>a4e42e8bbdc9fb7482dd181c332ae668c15f1750</id>
<content type='text'>
commit 10469350e345599dfef3fa78a7c19fb230e674c1 upstream.

Previously, when a signal was registered with SA_SIGINFO, parameters 2
and 3 of the signal handler were written to registers r1 and r2 before
the register set was saved. This led to corruption of these two
registers after returning from the signal handler (the wrong values were
restored).
With this patch, registers are now saved before any parameters are
passed, thus maintaining the processor state from before signal entry.

Signed-off-by: Christian Ruppert &lt;christian.ruppert@abilis.com&gt;
Signed-off-by: Vineet Gupta &lt;vgupta@synopsys.com&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 10469350e345599dfef3fa78a7c19fb230e674c1 upstream.

Previously, when a signal was registered with SA_SIGINFO, parameters 2
and 3 of the signal handler were written to registers r1 and r2 before
the register set was saved. This led to corruption of these two
registers after returning from the signal handler (the wrong values were
restored).
With this patch, registers are now saved before any parameters are
passed, thus maintaining the processor state from before signal entry.

Signed-off-by: Christian Ruppert &lt;christian.ruppert@abilis.com&gt;
Signed-off-by: Vineet Gupta &lt;vgupta@synopsys.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ARC: Workaround spinlock livelock in SMP SystemC simulation</title>
<updated>2013-10-18T17:54:56+00:00</updated>
<author>
<name>Vineet Gupta</name>
<email>vgupta@synopsys.com</email>
</author>
<published>2013-09-25T11:23:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=7e0e1ac946d1040f3c31ea5861da9aa5cb6d8b3b'/>
<id>7e0e1ac946d1040f3c31ea5861da9aa5cb6d8b3b</id>
<content type='text'>
commit 6c00350b573c0bd3635436e43e8696951dd6e1b6 upstream.

Some ARC SMP systems lack native atomic R-M-W (LLOCK/SCOND) insns and
can only use atomic EX insn (reg with mem) to build higher level R-M-W
primitives. This includes a SystemC based SMP simulation model.

So rwlocks need to use a protecting spinlock for atomic cmp-n-exchange
operation to update reader(s)/writer count.

The spinlock operation itself looks as follows:

	mov reg, 1		; 1=locked, 0=unlocked
retry:
	EX reg, [lock]		; load existing, store 1, atomically
	BREQ reg, 1, rety	; if already locked, retry

In single-threaded simulation, SystemC alternates between the 2 cores
with "N" insn each based scheduling. Additionally for insn with global
side effect, such as EX writing to shared mem, a core switch is
enforced too.

Given that, 2 cores doing a repeated EX on same location, Linux often
got into a livelock e.g. when both cores were fiddling with tasklist
lock (gdbserver / hackbench) for read/write respectively as the
sequence diagram below shows:

           core1                                   core2
         --------                                --------
1. spin lock [EX r=0, w=1] - LOCKED
2. rwlock(Read)            - LOCKED
3. spin unlock  [ST 0]     - UNLOCKED
                                         spin lock [EX r=0,w=1] - LOCKED
                      -- resched core 1----

5. spin lock [EX r=1] - ALREADY-LOCKED

                      -- resched core 2----
6.                                       rwlock(Write) - READER-LOCKED
7.                                       spin unlock [ST 0]
8.                                       rwlock failed, retry again

9.                                       spin lock  [EX r=0, w=1]
                      -- resched core 1----

10  spinlock locked in #9, retry #5
11. spin lock [EX gets 1]
                      -- resched core 2----
...
...

The fix was to unlock using the EX insn too (step 7), to trigger another
SystemC scheduling pass which would let core1 proceed, eliding the
livelock.

Signed-off-by: Vineet Gupta &lt;vgupta@synopsys.com&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 6c00350b573c0bd3635436e43e8696951dd6e1b6 upstream.

Some ARC SMP systems lack native atomic R-M-W (LLOCK/SCOND) insns and
can only use atomic EX insn (reg with mem) to build higher level R-M-W
primitives. This includes a SystemC based SMP simulation model.

So rwlocks need to use a protecting spinlock for atomic cmp-n-exchange
operation to update reader(s)/writer count.

The spinlock operation itself looks as follows:

	mov reg, 1		; 1=locked, 0=unlocked
retry:
	EX reg, [lock]		; load existing, store 1, atomically
	BREQ reg, 1, rety	; if already locked, retry

In single-threaded simulation, SystemC alternates between the 2 cores
with "N" insn each based scheduling. Additionally for insn with global
side effect, such as EX writing to shared mem, a core switch is
enforced too.

Given that, 2 cores doing a repeated EX on same location, Linux often
got into a livelock e.g. when both cores were fiddling with tasklist
lock (gdbserver / hackbench) for read/write respectively as the
sequence diagram below shows:

           core1                                   core2
         --------                                --------
1. spin lock [EX r=0, w=1] - LOCKED
2. rwlock(Read)            - LOCKED
3. spin unlock  [ST 0]     - UNLOCKED
                                         spin lock [EX r=0,w=1] - LOCKED
                      -- resched core 1----

5. spin lock [EX r=1] - ALREADY-LOCKED

                      -- resched core 2----
6.                                       rwlock(Write) - READER-LOCKED
7.                                       spin unlock [ST 0]
8.                                       rwlock failed, retry again

9.                                       spin lock  [EX r=0, w=1]
                      -- resched core 1----

10  spinlock locked in #9, retry #5
11. spin lock [EX gets 1]
                      -- resched core 2----
...
...

The fix was to unlock using the EX insn too (step 7), to trigger another
SystemC scheduling pass which would let core1 proceed, eliding the
livelock.

Signed-off-by: Vineet Gupta &lt;vgupta@synopsys.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ARC: Fix 32-bit wrap around in access_ok()</title>
<updated>2013-10-18T17:54:56+00:00</updated>
<author>
<name>Vineet Gupta</name>
<email>vgupta@synopsys.com</email>
</author>
<published>2013-09-26T13:20:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=7b081aded13f3437ed26e70e12f23aad69e68ad6'/>
<id>7b081aded13f3437ed26e70e12f23aad69e68ad6</id>
<content type='text'>
commit 0752adfda15f0eca9859a76da3db1800e129ad43 upstream.

Anton reported

 | LTP tests syscalls/process_vm_readv01 and process_vm_writev01 fail
 | similarly in one testcase test_iov_invalid -&gt; lvec-&gt;iov_base.
 | Testcase expects errno EFAULT and return code -1,
 | but it gets return code 1 and ERRNO is 0 what means success.

Essentially test case was passing a pointer of -1 which access_ok()
was not catching. It was doing [@addr + @sz &lt;= TASK_SIZE] which would
pass for @addr == -1

Fixed that by rewriting as [@addr &lt;= TASK_SIZE - @sz]

Reported-by: Anton Kolesov &lt;Anton.Kolesov@synopsys.com&gt;
Signed-off-by: Vineet Gupta &lt;vgupta@synopsys.com&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 0752adfda15f0eca9859a76da3db1800e129ad43 upstream.

Anton reported

 | LTP tests syscalls/process_vm_readv01 and process_vm_writev01 fail
 | similarly in one testcase test_iov_invalid -&gt; lvec-&gt;iov_base.
 | Testcase expects errno EFAULT and return code -1,
 | but it gets return code 1 and ERRNO is 0 what means success.

Essentially test case was passing a pointer of -1 which access_ok()
was not catching. It was doing [@addr + @sz &lt;= TASK_SIZE] which would
pass for @addr == -1

Fixed that by rewriting as [@addr &lt;= TASK_SIZE - @sz]

Reported-by: Anton Kolesov &lt;Anton.Kolesov@synopsys.com&gt;
Signed-off-by: Vineet Gupta &lt;vgupta@synopsys.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ARC: Handle zero-overhead-loop in unaligned access handler</title>
<updated>2013-10-18T17:54:55+00:00</updated>
<author>
<name>Mischa Jonker</name>
<email>mjonker@synopsys.com</email>
</author>
<published>2013-09-26T13:44:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=49cac7d9e62954e2235ae342ee15e0e0a7995a16'/>
<id>49cac7d9e62954e2235ae342ee15e0e0a7995a16</id>
<content type='text'>
commit c11eb222fd7d4db91196121dbf854178505d2751 upstream.

If a load or store is the last instruction in a zero-overhead-loop, and
it's misaligned, the loop would execute only once.

This fixes that problem.

Signed-off-by: Mischa Jonker &lt;mjonker@synopsys.com&gt;
Signed-off-by: Vineet Gupta &lt;vgupta@synopsys.com&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 c11eb222fd7d4db91196121dbf854178505d2751 upstream.

If a load or store is the last instruction in a zero-overhead-loop, and
it's misaligned, the loop would execute only once.

This fixes that problem.

Signed-off-by: Mischa Jonker &lt;mjonker@synopsys.com&gt;
Signed-off-by: Vineet Gupta &lt;vgupta@synopsys.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
</feed>
