<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/arch/parisc/mm, branch linux-4.4.y</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=linux-4.4.y</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=linux-4.4.y'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2021-11-26T10:58:38+00:00</updated>
<entry>
<title>parisc: fix warning in flush_tlb_all</title>
<updated>2021-11-26T10:58:38+00:00</updated>
<author>
<name>Sven Schnelle</name>
<email>svens@stackframe.org</email>
</author>
<published>2021-10-09T18:24:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2a4b6e778c74b200d461f45c4cbd370eebb6ff35'/>
<id>urn:sha1:2a4b6e778c74b200d461f45c4cbd370eebb6ff35</id>
<content type='text'>
[ Upstream commit 1030d681319b43869e0d5b568b9d0226652d1a6f ]

I've got the following splat after enabling preemption:

[    3.724721] BUG: using __this_cpu_add() in preemptible [00000000] code: swapper/0/1
[    3.734630] caller is __this_cpu_preempt_check+0x38/0x50
[    3.740635] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.15.0-rc4-64bit+ #324
[    3.744605] Hardware name: 9000/785/C8000
[    3.744605] Backtrace:
[    3.744605]  [&lt;00000000401d9d58&gt;] show_stack+0x74/0xb0
[    3.744605]  [&lt;0000000040c27bd4&gt;] dump_stack_lvl+0x10c/0x188
[    3.744605]  [&lt;0000000040c27c84&gt;] dump_stack+0x34/0x48
[    3.744605]  [&lt;0000000040c33438&gt;] check_preemption_disabled+0x178/0x1b0
[    3.744605]  [&lt;0000000040c334f8&gt;] __this_cpu_preempt_check+0x38/0x50
[    3.744605]  [&lt;00000000401d632c&gt;] flush_tlb_all+0x58/0x2e0
[    3.744605]  [&lt;00000000401075c0&gt;] 0x401075c0
[    3.744605]  [&lt;000000004010b8fc&gt;] 0x4010b8fc
[    3.744605]  [&lt;00000000401080fc&gt;] 0x401080fc
[    3.744605]  [&lt;00000000401d5224&gt;] do_one_initcall+0x128/0x378
[    3.744605]  [&lt;0000000040102de8&gt;] 0x40102de8
[    3.744605]  [&lt;0000000040c33864&gt;] kernel_init+0x60/0x3a8
[    3.744605]  [&lt;00000000401d1020&gt;] ret_from_kernel_thread+0x20/0x28
[    3.744605]

Fix this by moving the __inc_irq_stat() into the locked section.

Signed-off-by: Sven Schnelle &lt;svens@stackframe.org&gt;
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>parisc: Fix kernel panic in mem_init()</title>
<updated>2020-06-03T06:12:12+00:00</updated>
<author>
<name>Helge Deller</name>
<email>deller@gmx.de</email>
</author>
<published>2020-05-28T20:29:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=85cb412a93b20697399d7d428dee53e8076c9a4f'/>
<id>urn:sha1:85cb412a93b20697399d7d428dee53e8076c9a4f</id>
<content type='text'>
commit bf71bc16e02162388808949b179d59d0b571b965 upstream.

The Debian kernel v5.6 triggers this kernel panic:

 Kernel panic - not syncing: Bad Address (null pointer deref?)
 Bad Address (null pointer deref?): Code=26 (Data memory access rights trap) at addr 0000000000000000
 CPU: 0 PID: 0 Comm: swapper Not tainted 5.6.0-2-parisc64 #1 Debian 5.6.14-1
  IAOQ[0]: mem_init+0xb0/0x150
  IAOQ[1]: mem_init+0xb4/0x150
  RP(r2): start_kernel+0x6c8/0x1190
 Backtrace:
  [&lt;0000000040101ab4&gt;] start_kernel+0x6c8/0x1190
  [&lt;0000000040108574&gt;] start_parisc+0x158/0x1b8

on a HP-PARISC rp3440 machine with this memory layout:
 Memory Ranges:
  0) Start 0x0000000000000000 End 0x000000003fffffff Size   1024 MB
  1) Start 0x0000004040000000 End 0x00000040ffdfffff Size   3070 MB

Fix the crash by avoiding virt_to_page() and similar functions in
mem_init() until the memory zones have been fully set up.

Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
Cc: stable@vger.kernel.org # v5.0+
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;


</content>
</entry>
<entry>
<title>parisc: Fix vmap memory leak in ioremap()/iounmap()</title>
<updated>2019-10-29T08:13:29+00:00</updated>
<author>
<name>Helge Deller</name>
<email>deller@gmx.de</email>
</author>
<published>2019-10-04T17:23:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b7f9ec253c281a72a99e2ba2c81191f2753d990a'/>
<id>urn:sha1:b7f9ec253c281a72a99e2ba2c81191f2753d990a</id>
<content type='text'>
commit 513f7f747e1cba81f28a436911fba0b485878ebd upstream.

Sven noticed that calling ioremap() and iounmap() multiple times leads
to a vmap memory leak:
	vmap allocation for size 4198400 failed:
	use vmalloc=&lt;size&gt; to increase size

It seems we missed calling vunmap() in iounmap().

Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
Noticed-by: Sven Schnelle &lt;svens@stackframe.org&gt;
Cc: &lt;stable@vger.kernel.org&gt; # v3.16+
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>parisc: Fix map_pages() to not overwrite existing pte entries</title>
<updated>2018-11-21T08:27:30+00:00</updated>
<author>
<name>Helge Deller</name>
<email>deller@gmx.de</email>
</author>
<published>2018-10-12T20:37:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ae53e64ea305d278857d31ea2d20dcad7a6ac929'/>
<id>urn:sha1:ae53e64ea305d278857d31ea2d20dcad7a6ac929</id>
<content type='text'>
commit 3c229b3f2dd8133f61bb81d3cb018be92f4bba39 upstream.

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

Cc: stable@vger.kernel.org
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>parisc: Report SIGSEGV instead of SIGBUS when running out of stack</title>
<updated>2017-07-21T05:44:56+00:00</updated>
<author>
<name>Helge Deller</name>
<email>deller@gmx.de</email>
</author>
<published>2017-07-02T20:00:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e18ca17b9040bedd3768a257d46537471eff45a1'/>
<id>urn:sha1:e18ca17b9040bedd3768a257d46537471eff45a1</id>
<content type='text'>
commit 247462316f85a9e0479445c1a4223950b68ffac1 upstream.

When a process runs out of stack the parisc kernel wrongly faults with SIGBUS
instead of the expected SIGSEGV signal.

This example shows how the kernel faults:
do_page_fault() command='a.out' type=15 address=0xfaac2000 in libc-2.24.so[f8308000+16c000]
trap #15: Data TLB miss fault, vm_start = 0xfa2c2000, vm_end = 0xfaac2000

The vma-&gt;vm_end value is the first address which does not belong to the vma, so
adjust the check to include vma-&gt;vm_end to the range for which to send the
SIGSEGV signal.

This patch unbreaks building the debian libsigsegv package.

Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>parisc: Unbreak handling exceptions from kernel modules</title>
<updated>2016-04-20T06:41:52+00:00</updated>
<author>
<name>Helge Deller</name>
<email>deller@gmx.de</email>
</author>
<published>2016-04-08T16:32:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4d6deebe06c5383dffe9cba859378ca708d4076d'/>
<id>urn:sha1:4d6deebe06c5383dffe9cba859378ca708d4076d</id>
<content type='text'>
commit 2ef4dfd9d9f288943e249b78365a69e3ea3ec072 upstream.

Handling exceptions from modules never worked on parisc.
It was just masked by the fact that exceptions from modules
don't happen during normal use.

When a module triggers an exception in get_user() we need to load the
main kernel dp value before accessing the exception_data structure, and
afterwards restore the original dp value of the module on exit.

Noticed-by: Mikulas Patocka &lt;mpatocka@redhat.com&gt;
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>parisc: Protect huge page pte changes with spinlocks</title>
<updated>2016-02-17T20:30:57+00:00</updated>
<author>
<name>Helge Deller</name>
<email>deller@gmx.de</email>
</author>
<published>2015-11-26T20:14:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=583097a3b2cef0bee535c8acc4189ceacb8bb6c6'/>
<id>urn:sha1:583097a3b2cef0bee535c8acc4189ceacb8bb6c6</id>
<content type='text'>
commit b0e551313ebde17764f3a5ed273df524d1e7e690 upstream.

PA-RISC doesn't have atomic instructions to modify page table entries, so it
takes spinlock in the TLB handler and modifies the page table entry
non-atomically. If you modify the page table entry without the spinlock, you
may race with TLB handler on another CPU and your modification may be lost.
Protect against that with usage of purge_tlb_start() and purge_tlb_end() which
handles the TLB spinlock.

Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>Merge branch 'parisc-4.4-2' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux</title>
<updated>2015-11-22T20:50:58+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2015-11-22T20:50:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=94521b2fd27b5ef43573f9f425a48839fa80ebaa'/>
<id>urn:sha1:94521b2fd27b5ef43573f9f425a48839fa80ebaa</id>
<content type='text'>
Pull parisc update from Helge Deller:
 "This patchset adds Huge Page and HUGETLBFS support for parisc"

Honestly, the hugepage support should have gone through in the merge
window, and is not really an rc-time fix.  But it only touches
arch/parisc, and I cannot find it in myself to care.  If one of the
three parisc users notices a breakage, I will point at Helge and make
rude farting noises.

* 'parisc-4.4-2' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
  parisc: Map kernel text and data on huge pages
  parisc: Add Huge Page and HUGETLBFS support
  parisc: Use long branch to do_syscall_trace_exit
  parisc: Increase initial kernel mapping to 32MB on 64bit kernel
  parisc: Initialize the fault vector earlier in the boot process.
  parisc: Add defines for Huge page support
  parisc: Drop unused MADV_xxxK_PAGES flags from asm/mman.h
  parisc: Drop definition of start_thread_som for HP-UX SOM binaries
  parisc: Fix wrong comment regarding first pmd entry flags
</content>
</entry>
<entry>
<title>parisc: Map kernel text and data on huge pages</title>
<updated>2015-11-22T11:23:19+00:00</updated>
<author>
<name>Helge Deller</name>
<email>deller@gmx.de</email>
</author>
<published>2015-11-21T23:07:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=41b85a1163386f8328ad570f383973cb3975d2fa'/>
<id>urn:sha1:41b85a1163386f8328ad570f383973cb3975d2fa</id>
<content type='text'>
Adjust the linker script and map_pages() to map kernel text and data on
physical 1MB huge/large pages.

Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</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.radix-linux.su/kernel/linux.git/commit/?id=736d2169338a50c8814efc186b5423aee43b0c68'/>
<id>urn:sha1: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>
</entry>
</feed>
