<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/arch/arm/kernel, branch linux-3.18.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-3.18.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-3.18.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2019-04-27T07:30:22Z</updated>
<entry>
<title>ARM: 8840/1: use a raw_spinlock_t in unwind</title>
<updated>2019-04-27T07:30:22Z</updated>
<author>
<name>Sebastian Andrzej Siewior</name>
</author>
<published>2019-02-13T16:14:42Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=61c4d9023651d8a0a2f636285a9af44bd072d519'/>
<id>urn:sha1:61c4d9023651d8a0a2f636285a9af44bd072d519</id>
<content type='text'>
[ Upstream commit 74ffe79ae538283bbf7c155e62339f1e5c87b55a ]

Mostly unwind is done with irqs enabled however SLUB may call it with
irqs disabled while creating a new SLUB cache.

I had system freeze while loading a module which called
kmem_cache_create() on init. That means SLUB's __slab_alloc() disabled
interrupts and then

-&gt;new_slab_objects()
 -&gt;new_slab()
  -&gt;setup_object()
   -&gt;setup_object_debug()
    -&gt;init_tracking()
     -&gt;set_track()
      -&gt;save_stack_trace()
       -&gt;save_stack_trace_tsk()
        -&gt;walk_stackframe()
         -&gt;unwind_frame()
          -&gt;unwind_find_idx()
           =&gt;spin_lock_irqsave(&amp;unwind_lock);

Signed-off-by: Sebastian Andrzej Siewior &lt;bigeasy@linutronix.de&gt;
Signed-off-by: Russell King &lt;rmk+kernel@armlinux.org.uk&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ARM: 8808/1: kexec:offline panic_smp_self_stop CPU</title>
<updated>2019-02-20T09:08:55Z</updated>
<author>
<name>Yufen Wang</name>
</author>
<published>2018-11-02T10:51:31Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=a160cf4ee87a8f5a14c6814dacf408ee4499a514'/>
<id>urn:sha1:a160cf4ee87a8f5a14c6814dacf408ee4499a514</id>
<content type='text'>
[ Upstream commit 82c08c3e7f171aa7f579b231d0abbc1d62e91974 ]

In case panic() and panic() called at the same time on different CPUS.
For example:
CPU 0:
  panic()
     __crash_kexec
       machine_crash_shutdown
         crash_smp_send_stop
       machine_kexec
         BUG_ON(num_online_cpus() &gt; 1);

CPU 1:
  panic()
    local_irq_disable
    panic_smp_self_stop

If CPU 1 calls panic_smp_self_stop() before crash_smp_send_stop(), kdump
fails. CPU1 can't receive the ipi irq, CPU1 will be always online.
To fix this problem, this patch split out the panic_smp_self_stop()
and add set_cpu_online(smp_processor_id(), false).

Signed-off-by: Yufen Wang &lt;wangyufen@huawei.com&gt;
Signed-off-by: Russell King &lt;rmk+kernel@armlinux.org.uk&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ARM: 8771/1: kprobes: Prohibit kprobes on do_undefinstr</title>
<updated>2018-05-25T08:54:54Z</updated>
<author>
<name>Masami Hiramatsu</name>
</author>
<published>2018-05-13T04:04:16Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=8414385f8dd48a8e4ea1808a2776594ceca7e02c'/>
<id>urn:sha1:8414385f8dd48a8e4ea1808a2776594ceca7e02c</id>
<content type='text'>
commit eb0146daefdde65665b7f076fbff7b49dade95b9 upstream.

Prohibit kprobes on do_undefinstr because kprobes on
arm is implemented by undefined instruction. This means
if we probe do_undefinstr(), it can cause infinit
recursive exception.

Fixes: 24ba613c9d6c ("ARM kprobes: core code")
Signed-off-by: Masami Hiramatsu &lt;mhiramat@kernel.org&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Russell King &lt;rmk+kernel@armlinux.org.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ARM: 8720/1: ensure dump_instr() checks addr_limit</title>
<updated>2017-11-15T09:04:13Z</updated>
<author>
<name>Mark Rutland</name>
</author>
<published>2017-11-02T17:44:28Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=1530d28a893e621c079af741a724cec5ec9e9d93'/>
<id>urn:sha1:1530d28a893e621c079af741a724cec5ec9e9d93</id>
<content type='text'>
commit b9dd05c7002ee0ca8b676428b2268c26399b5e31 upstream.

When CONFIG_DEBUG_USER is enabled, it's possible for a user to
deliberately trigger dump_instr() with a chosen kernel address.

Let's avoid problems resulting from this by using get_user() rather than
__get_user(), ensuring that we don't erroneously access kernel memory.

So that we can use the same code to dump user instructions and kernel
instructions, the common dumping code is factored out to __dump_instr(),
with the fs manipulated appropriately in dump_instr() around calls to
this.

Signed-off-by: Mark Rutland &lt;mark.rutland@arm.com&gt;
Signed-off-by: Russell King &lt;rmk+kernel@armlinux.org.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ARM: 8452/3: PJ4: make coprocessor access sequences buildable in Thumb2 mode</title>
<updated>2017-05-15T07:19:09Z</updated>
<author>
<name>Ard Biesheuvel</name>
</author>
<published>2015-12-22T07:24:59Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=94a4e4e467d7a951fcc45e7b49c74eda3e00c7ea'/>
<id>urn:sha1:94a4e4e467d7a951fcc45e7b49c74eda3e00c7ea</id>
<content type='text'>
commit 5008efc83bf85b647aa1cbc44718b1675bbb7444 upstream.

The PJ4 inline asm sequence to write to cp15 cannot be built in Thumb-2
mode, due to the way it performs arithmetic on the program counter, so it
is built in ARM mode instead. However, building C files in ARM mode under
CONFIG_THUMB2_KERNEL is problematic, since the instrumentation performed
by subsystems like ftrace does not expect having to deal with interworking
branches.

Since the sequence in question is simply a poor man's ISB instruction,
let's use a straight 'isb' instead when building in Thumb2 mode. Thumb2
implies V7, so 'isb' should always be supported in that case.

Acked-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Acked-by: Nicolas Pitre &lt;nico@linaro.org&gt;
Signed-off-by: Ard Biesheuvel &lt;ard.biesheuvel@linaro.org&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>
</entry>
<entry>
<title>ARM: 8383/1: nommu: avoid deprecated source register on mov</title>
<updated>2017-04-30T03:49:17Z</updated>
<author>
<name>Stefan Agner</name>
</author>
<published>2015-06-02T19:43:24Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=12ebe5ca67dc8743d8cba7ef2019a2f72bb480b7'/>
<id>urn:sha1:12ebe5ca67dc8743d8cba7ef2019a2f72bb480b7</id>
<content type='text'>
commit 970d96f9a81b0dd83ddd8bce0e5e1ba31881c5f5 upstream.

In Thumb2 mode, the stack register r13 is deprecated if the
destination register is the program counter (r15). Similar to
head.S, head-nommu.S uses r13 to store the return address used
after configuring the CPU's CP15 register. However, since we do
not enable a MMU, there will be no address switch and it is
possible to use branch with link instruction to call
__after_proc_init.

Avoid using r13 completely by using bl to call __after_proc_init
and get rid of __secondary_switched.

Beside removing unnecessary complexity, this also fixes a
compiler warning when compiling a !MMU kernel:
Warning: Use of r13 as a source register is deprecated when r15
is the destination register.

Tested-by: Maxime Coquelin &lt;mcoquelin.stm32@gmail.com&gt;
Signed-off-by: Stefan Agner &lt;stefan@agner.ch&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>[PATCH] arm: fix handling of F_OFD_... in oabi_fcntl64()</title>
<updated>2016-09-11T13:57:24Z</updated>
<author>
<name>Al Viro</name>
</author>
<published>2015-12-29T01:47:08Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=db9e37a1c5f21cec095da9ed53a2c0cbeeb24ee6'/>
<id>urn:sha1:db9e37a1c5f21cec095da9ed53a2c0cbeeb24ee6</id>
<content type='text'>
[ Upstream commit 76cc404bfdc0d419c720de4daaf2584542734f42 ]

Cc: stable@vger.kernel.org # 3.15+
Reviewed-by: Jeff Layton &lt;jeff.layton@primarydata.com&gt;
Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</content>
</entry>
<entry>
<title>ARM: fix PTRACE_SETVFPREGS on SMP systems</title>
<updated>2016-06-20T03:47:42Z</updated>
<author>
<name>Russell King</name>
</author>
<published>2016-05-30T22:14:56Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=b0f8d64a5f8aa3dceff51bf83b58378627bf27d9'/>
<id>urn:sha1:b0f8d64a5f8aa3dceff51bf83b58378627bf27d9</id>
<content type='text'>
[ Upstream commit e2dfb4b880146bfd4b6aa8e138c0205407cebbaf ]

PTRACE_SETVFPREGS fails to properly mark the VFP register set to be
reloaded, because it undoes one of the effects of vfp_flush_hwstate().

Specifically vfp_flush_hwstate() sets thread-&gt;vfpstate.hard.cpu to
an invalid CPU number, but vfp_set() overwrites this with the original
CPU number, thereby rendering the hardware state as apparently "valid",
even though the software state is more recent.

Fix this by reverting the previous change.

Cc: &lt;stable@vger.kernel.org&gt;
Fixes: 8130b9d7b9d8 ("ARM: 7308/1: vfp: flush thread hwstate before copying ptrace registers")
Acked-by: Will Deacon &lt;will.deacon@arm.com&gt;
Tested-by: Simon Marchi &lt;simon.marchi@ericsson.com&gt;
Signed-off-by: Russell King &lt;rmk+kernel@armlinux.org.uk&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
</entry>
<entry>
<title>ARM: fix Thumb2 signal handling when ARMv6 is enabled</title>
<updated>2015-10-28T02:13:00Z</updated>
<author>
<name>Russell King</name>
</author>
<published>2015-09-11T15:44:02Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=a1c34031c6db90aa8b905d616369e573d301b86c'/>
<id>urn:sha1:a1c34031c6db90aa8b905d616369e573d301b86c</id>
<content type='text'>
[ Upstream commit 9b55613f42e8d40d5c9ccb8970bde6af4764b2ab ]

When a kernel is built covering ARMv6 to ARMv7, we omit to clear the
IT state when entering a signal handler.  This can cause the first
few instructions to be conditionally executed depending on the parent
context.

In any case, the original test for &gt;= ARMv7 is broken - ARMv6 can have
Thumb-2 support as well, and an ARMv6T2 specific build would omit this
code too.

Relax the test back to ARMv6 or greater.  This results in us always
clearing the IT state bits in the PSR, even on CPUs where these bits
are reserved.  However, they're reserved for the IT state, so this
should cause no harm.

Cc: &lt;stable@vger.kernel.org&gt;
Fixes: d71e1352e240 ("Clear the IT state when invoking a Thumb-2 signal handler")
Acked-by: Tony Lindgren &lt;tony@atomide.com&gt;
Tested-by: H. Nikolaus Schaller &lt;hns@goldelico.com&gt;
Tested-by: Grazvydas Ignotas &lt;notasas@gmail.com&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
</entry>
<entry>
<title>ARM: 8221/1: PJ4: allow building in Thumb-2 mode</title>
<updated>2015-06-15T17:59:52Z</updated>
<author>
<name>Ard Biesheuvel</name>
</author>
<published>2015-05-28T23:31:28Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=0096d0ccb701079017f2ad698d56b89838251724'/>
<id>urn:sha1:0096d0ccb701079017f2ad698d56b89838251724</id>
<content type='text'>
Two files that get included when building the multi_v7_defconfig target
fail to build when selecting THUMB2_KERNEL for this configuration.

In both cases, we can just build the file as ARM code, as none of its
symbols are exported to modules, so there are no interworking concerns.
In the iwmmxt.S case, add ENDPROC() declarations so the symbols are
annotated as functions, resulting in the linker to emit the appropriate
mode switches.

Acked-by: Nicolas Pitre &lt;nico@linaro.org&gt;
Tested-by: Olof Johansson &lt;olof@lixom.net&gt;
Signed-off-by: Ard Biesheuvel &lt;ard.biesheuvel@linaro.org&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
(cherry picked from commit 13d1b9575ac2c2da143cd2236b6cf0fc314570f8)
Cc: &lt;stable@vger.kernel.org&gt; # v3.18+
Signed-off-by: Kevin Hilman &lt;khilman@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
</entry>
</feed>
