<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/arch/parisc/kernel/entry.S, branch v4.16.7</title>
<subtitle>Clone of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git</subtitle>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/'/>
<entry>
<title>parisc: Fix alignment of pa_tlb_lock in assembly on 32-bit SMP kernel</title>
<updated>2018-01-02T21:21:54+00:00</updated>
<author>
<name>Helge Deller</name>
<email>deller@gmx.de</email>
</author>
<published>2018-01-02T19:36:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=88776c0e70be0290f8357019d844aae15edaa967'/>
<id>88776c0e70be0290f8357019d844aae15edaa967</id>
<content type='text'>
Qemu for PARISC reported on a 32bit SMP parisc kernel strange failures
about "Not-handled unaligned insn 0x0e8011d6 and 0x0c2011c9."

Those opcodes evaluate to the ldcw() assembly instruction which requires
(on 32bit) an alignment of 16 bytes to ensure atomicity.

As it turns out, qemu is correct and in our assembly code in entry.S and
pacache.S we don't pay attention to the required alignment.

This patch fixes the problem by aligning the lock offset in assembly
code in the same manner as we do in our C-code.

Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
Cc: &lt;stable@vger.kernel.org&gt; # v4.0+
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Qemu for PARISC reported on a 32bit SMP parisc kernel strange failures
about "Not-handled unaligned insn 0x0e8011d6 and 0x0c2011c9."

Those opcodes evaluate to the ldcw() assembly instruction which requires
(on 32bit) an alignment of 16 bytes to ensure atomicity.

As it turns out, qemu is correct and in our assembly code in entry.S and
pacache.S we don't pay attention to the required alignment.

This patch fixes the problem by aligning the lock offset in assembly
code in the same manner as we do in our C-code.

Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
Cc: &lt;stable@vger.kernel.org&gt; # v4.0+
</pre>
</div>
</content>
</entry>
<entry>
<title>Revert "parisc: Re-enable interrupts early"</title>
<updated>2017-12-17T20:06:25+00:00</updated>
<author>
<name>John David Anglin</name>
<email>dave.anglin@bell.net</email>
</author>
<published>2017-11-14T00:35:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=9352aeada4d8d8753fc0e414fbfe8fdfcb68a12c'/>
<id>9352aeada4d8d8753fc0e414fbfe8fdfcb68a12c</id>
<content type='text'>
This reverts commit 5c38602d83e584047906b41b162ababd4db4106d.

Interrupts can't be enabled early because the register saves are done on
the thread stack prior to switching to the IRQ stack.  This caused stack
overflows and the thread stack needed increasing to 32k.  Even then,
stack overflows still occasionally occurred.

Background:
Even with a 32 kB thread stack, I have seen instances where the thread
stack overflowed on the mx3210 buildd.  Detection of stack overflow only
occurs when we have an external interrupt.  When an external interrupt
occurs, we switch to the thread stack if we are not already on a kernel
stack.  Then, registers and specials are saved to the kernel stack.

The bug occurs in intr_return where interrupts are reenabled prior to
returning from the interrupt.  This was done incase we need to schedule
or deliver signals.  However, it introduces the possibility that
multiple external interrupts may occur on the thread stack and cause a
stack overflow.  These might not be detected and cause the kernel to
misbehave in random ways.

This patch changes the code back to only reenable interrupts when we are
going to schedule or deliver signals.  As a result, we generally return
from an interrupt before reenabling interrupts.  This minimizes the
growth of the thread stack.

Fixes: 5c38602d83e5 ("parisc: Re-enable interrupts early")
Signed-off-by: John David Anglin &lt;dave.anglin@bell.net&gt;
Cc: &lt;stable@vger.kernel.org&gt; # v4.10+
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This reverts commit 5c38602d83e584047906b41b162ababd4db4106d.

Interrupts can't be enabled early because the register saves are done on
the thread stack prior to switching to the IRQ stack.  This caused stack
overflows and the thread stack needed increasing to 32k.  Even then,
stack overflows still occasionally occurred.

Background:
Even with a 32 kB thread stack, I have seen instances where the thread
stack overflowed on the mx3210 buildd.  Detection of stack overflow only
occurs when we have an external interrupt.  When an external interrupt
occurs, we switch to the thread stack if we are not already on a kernel
stack.  Then, registers and specials are saved to the kernel stack.

The bug occurs in intr_return where interrupts are reenabled prior to
returning from the interrupt.  This was done incase we need to schedule
or deliver signals.  However, it introduces the possibility that
multiple external interrupts may occur on the thread stack and cause a
stack overflow.  These might not be detected and cause the kernel to
misbehave in random ways.

This patch changes the code back to only reenable interrupts when we are
going to schedule or deliver signals.  As a result, we generally return
from an interrupt before reenabling interrupts.  This minimizes the
growth of the thread stack.

Fixes: 5c38602d83e5 ("parisc: Re-enable interrupts early")
Signed-off-by: John David Anglin &lt;dave.anglin@bell.net&gt;
Cc: &lt;stable@vger.kernel.org&gt; # v4.10+
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>scripts/spelling.txt: add regsiter -&gt; register spelling mistake</title>
<updated>2017-05-09T00:15:13+00:00</updated>
<author>
<name>Stephen Boyd</name>
<email>sboyd@codeaurora.org</email>
</author>
<published>2017-05-08T22:57:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=ad61dd303a0f2439bb104349e2d2ec91a3010ce0'/>
<id>ad61dd303a0f2439bb104349e2d2ec91a3010ce0</id>
<content type='text'>
This typo is quite common.  Fix it and add it to the spelling file so
that checkpatch catches it earlier.

Link: http://lkml.kernel.org/r/20170317011131.6881-2-sboyd@codeaurora.org
Signed-off-by: Stephen Boyd &lt;sboyd@codeaurora.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This typo is quite common.  Fix it and add it to the spelling file so
that checkpatch catches it earlier.

Link: http://lkml.kernel.org/r/20170317011131.6881-2-sboyd@codeaurora.org
Signed-off-by: Stephen Boyd &lt;sboyd@codeaurora.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>parisc: Re-enable interrupts early</title>
<updated>2016-12-12T21:21:50+00:00</updated>
<author>
<name>Helge Deller</name>
<email>deller@gmx.de</email>
</author>
<published>2016-10-24T19:55:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=5c38602d83e584047906b41b162ababd4db4106d'/>
<id>5c38602d83e584047906b41b162ababd4db4106d</id>
<content type='text'>
Since kernel 3.9 we re-enable interrupts quite late due to commit c207a76bf15
("parisc: only re-enable interrupts if we need to schedule or deliver signals
when returning to userspace"). At that time the parisc kernel had no dedicated
IRQ stack, and this commit prevented kernel stack overflows.

But since commit 200c880420a ("parisc: implement irq stacks") we now have an
IRQ stack, so we may be safe now.  And when CONFIG_DEBUG_STACKOVERFLOW=y is
enabled, we can even check at runtime for overflows.

Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Since kernel 3.9 we re-enable interrupts quite late due to commit c207a76bf15
("parisc: only re-enable interrupts if we need to schedule or deliver signals
when returning to userspace"). At that time the parisc kernel had no dedicated
IRQ stack, and this commit prevented kernel stack overflows.

But since commit 200c880420a ("parisc: implement irq stacks") we now have an
IRQ stack, so we may be safe now.  And when CONFIG_DEBUG_STACKOVERFLOW=y is
enabled, we can even check at runtime for overflows.

Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>parisc: Add cfi_startproc and cfi_endproc to assembly code</title>
<updated>2016-10-05T20:54:40+00:00</updated>
<author>
<name>Helge Deller</name>
<email>deller@gmx.de</email>
</author>
<published>2016-10-05T20:28:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=f39cce654f9a1df331d7e1ba703f5f06a79f2159'/>
<id>f39cce654f9a1df331d7e1ba703f5f06a79f2159</id>
<content type='text'>
Add ENTRY_CFI() and ENDPROC_CFI() macros for dwarf debug info and
convert assembly users to new macros.

Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add ENTRY_CFI() and ENDPROC_CFI() macros for dwarf debug info and
convert assembly users to new macros.

Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>parisc: Use long jump to reach ftrace_return_to_handler()</title>
<updated>2016-05-23T21:44:44+00:00</updated>
<author>
<name>Helge Deller</name>
<email>deller@gmx.de</email>
</author>
<published>2016-05-23T21:23:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=5fece5ad24ab5b57f51f3f18bc9332545ea8705a'/>
<id>5fece5ad24ab5b57f51f3f18bc9332545ea8705a</id>
<content type='text'>
Depending on config options we will need to use a long jump to reach
ftrace_return_to_handler().  Additionally only compile the
parisc_return_to_handler code when CONFIG_FUNCTION_GRAPH_TRACER is set.

Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Depending on config options we will need to use a long jump to reach
ftrace_return_to_handler().  Additionally only compile the
parisc_return_to_handler code when CONFIG_FUNCTION_GRAPH_TRACER is set.

Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>parisc: Merge ftrace C-helper and assembler functions into .text.hot section</title>
<updated>2016-05-22T19:46:21+00:00</updated>
<author>
<name>Helge Deller</name>
<email>deller@gmx.de</email>
</author>
<published>2016-04-29T20:07:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=4df3c9ec12077384e0add54f28a9b079a87b59ef'/>
<id>4df3c9ec12077384e0add54f28a9b079a87b59ef</id>
<content type='text'>
When enabling all-branch ftrace support (CONFIG_PROFILE_ALL_BRANCHES)
the kernel gets really huge and some ftrace assembler functions like
mcount can't reach the ftrace helper functions which are written in C.
Avoid this problem of too distant branches by moving the ftrace C-helper
functions into the .text.hot section which is put in front of the
standard .text section by the linker.

Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When enabling all-branch ftrace support (CONFIG_PROFILE_ALL_BRANCHES)
the kernel gets really huge and some ftrace assembler functions like
mcount can't reach the ftrace helper functions which are written in C.
Avoid this problem of too distant branches by moving the ftrace C-helper
functions into the .text.hot section which is put in front of the
standard .text section by the linker.

Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>parisc: Fix ftrace function tracer</title>
<updated>2016-04-14T15:47:19+00:00</updated>
<author>
<name>Helge Deller</name>
<email>deller@gmx.de</email>
</author>
<published>2016-04-13T20:27:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=366dd4ea9d5f0eb78fdf4982d76506f99480ec0a'/>
<id>366dd4ea9d5f0eb78fdf4982d76506f99480ec0a</id>
<content type='text'>
Fix the FTRACE function tracer for 32- and 64-bit kernel.
The former code was horribly broken.

Reimplement most coding in assembly and utilize optimizations, e.g. put
mcount() and ftrace_stub() into one L1 cacheline.

Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Fix the FTRACE function tracer for 32- and 64-bit kernel.
The former code was horribly broken.

Reimplement most coding in assembly and utilize optimizations, e.g. put
mcount() and ftrace_stub() into one L1 cacheline.

Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>parisc: Add Huge Page and HUGETLBFS support</title>
<updated>2015-11-22T11:23:10+00:00</updated>
<author>
<name>Helge Deller</name>
<email>deller@gmx.de</email>
</author>
<published>2015-11-21T23:07:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=736d2169338a50c8814efc186b5423aee43b0c68'/>
<id>736d2169338a50c8814efc186b5423aee43b0c68</id>
<content type='text'>
This patch adds huge page support to allow userspace to allocate huge
pages and to use hugetlbfs filesystem on 32- and 64-bit Linux kernels.
A later patch will add kernel support to map kernel text and data on
huge pages.

The only requirement is, that the kernel needs to be compiled for a
PA8X00 CPU (PA2.0 architecture). Older PA1.X CPUs do not support
variable page sizes. 64bit Kernels are compiled for PA2.0 by default.

Technically on parisc multiple physical huge pages may be needed to
emulate standard 2MB huge pages.

Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch adds huge page support to allow userspace to allocate huge
pages and to use hugetlbfs filesystem on 32- and 64-bit Linux kernels.
A later patch will add kernel support to map kernel text and data on
huge pages.

The only requirement is, that the kernel needs to be compiled for a
PA8X00 CPU (PA2.0 architecture). Older PA1.X CPUs do not support
variable page sizes. 64bit Kernels are compiled for PA2.0 by default.

Technically on parisc multiple physical huge pages may be needed to
emulate standard 2MB huge pages.

Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>parisc: Initialize the fault vector earlier in the boot process.</title>
<updated>2015-11-22T11:22:43+00:00</updated>
<author>
<name>Helge Deller</name>
<email>deller@gmx.de</email>
</author>
<published>2015-11-20T09:50:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=4182d0cdf853fb044b969318289ae9f451f69c86'/>
<id>4182d0cdf853fb044b969318289ae9f451f69c86</id>
<content type='text'>
A fault vector on parisc needs to be 2K aligned.  Furthermore the
checksum of the fault vector needs to sum up to 0 which is being
calculated and written at runtime.

Up to now we aligned both PA20 and PA11 fault vectors on the same 4K
page in order to easily write the checksum after having mapped the
kernel read-only (by mapping this page only as read-write).
But when we want to map the kernel text and data on huge pages this
makes things harder.
So, simplify it by aligning both fault vectors on 2K boundries and write
the checksum before we map the page read-only.

Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
A fault vector on parisc needs to be 2K aligned.  Furthermore the
checksum of the fault vector needs to sum up to 0 which is being
calculated and written at runtime.

Up to now we aligned both PA20 and PA11 fault vectors on the same 4K
page in order to easily write the checksum after having mapped the
kernel read-only (by mapping this page only as read-write).
But when we want to map the kernel text and data on huge pages this
makes things harder.
So, simplify it by aligning both fault vectors on 2K boundries and write
the checksum before we map the page read-only.

Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</pre>
</div>
</content>
</entry>
</feed>
