<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/git/stable/linux-stable.git/arch/parisc, branch linux-4.16.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<id>https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/atom?h=linux-4.16.y</id>
<link rel='self' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/atom?h=linux-4.16.y'/>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/'/>
<updated>2018-06-20T19:01:46+00:00</updated>
<entry>
<title>parisc: Move setup_profiling_timer() out of init section</title>
<updated>2018-06-20T19:01:46+00:00</updated>
<author>
<name>Helge Deller</name>
<email>deller@gmx.de</email>
</author>
<published>2018-05-18T14:12:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=ce841083dc4d1c9188738bd6ccd176593a068e9e'/>
<id>urn:sha1:ce841083dc4d1c9188738bd6ccd176593a068e9e</id>
<content type='text'>
[ Upstream commit 01f56832cfb6fcc204e7203f46841b6185ebd574 ]

No other architecture has setup_profiling_timer() in the init section,
thus on parisc we face this section mismatch warning:
 Reference from the function devm_device_add_group() to the function .init.text:setup_profiling_timer()

Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>parisc: drivers.c: Fix section mismatches</title>
<updated>2018-06-20T19:01:33+00:00</updated>
<author>
<name>Helge Deller</name>
<email>deller@gmx.de</email>
</author>
<published>2018-04-20T21:19:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=c3a28e6c556ec735c682d37dc6d047b7259cd126'/>
<id>urn:sha1:c3a28e6c556ec735c682d37dc6d047b7259cd126</id>
<content type='text'>
[ Upstream commit b819439fea305a0bfd6ca23a7994fd1a8847c0d8 ]

Fix two section mismatches in drivers.c:
1) Section mismatch in reference from the function alloc_tree_node() to
   the function .init.text:create_tree_node().
2) Section mismatch in reference from the function walk_native_bus() to
   the function .init.text:alloc_pa_dev().

Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>parisc: time: Convert read_persistent_clock() to read_persistent_clock64()</title>
<updated>2018-06-20T19:01:21+00:00</updated>
<author>
<name>Baolin Wang</name>
<email>baolin.wang@linaro.org</email>
</author>
<published>2018-04-19T06:51:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=26251fb91cf85aa17ed24ed4fa833d6ec70fb67a'/>
<id>urn:sha1:26251fb91cf85aa17ed24ed4fa833d6ec70fb67a</id>
<content type='text'>
[ Upstream commit f76cdd00ef0e39d880139b074e3b247594dff95a ]

The read_persistent_clock() uses a timespec, which is not year 2038 safe
on 32bit systems. On parisc architecture, we have implemented generic
RTC drivers that can be used to compensate the system suspend time, but
the RTC time can not represent the nanosecond resolution, so this patch
just converts to read_persistent_clock64() with timespec64.

Signed-off-by: Baolin Wang &lt;baolin.wang@linaro.org&gt;
Acked-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>parisc: Fix HPMC handler by increasing size to multiple of 16 bytes</title>
<updated>2018-04-19T06:54:06+00:00</updated>
<author>
<name>Helge Deller</name>
<email>deller@gmx.de</email>
</author>
<published>2018-03-24T20:18:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=f628af5d6b1ed4bf828ae2fe4ce8a94bb7c24dcf'/>
<id>urn:sha1:f628af5d6b1ed4bf828ae2fe4ce8a94bb7c24dcf</id>
<content type='text'>
commit d5654e156bc4d68a87bbaa6d7e020baceddf6e68 upstream.

Make sure that the HPMC (High Priority Machine Check) handler is 16-byte
aligned and that it's length in the IVT is a multiple of 16 bytes.
Otherwise PDC may decide not to call the HPMC crash handler.

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

</content>
</entry>
<entry>
<title>parisc: Fix out of array access in match_pci_device()</title>
<updated>2018-04-19T06:54:06+00:00</updated>
<author>
<name>Helge Deller</name>
<email>deller@gmx.de</email>
</author>
<published>2018-03-25T21:53:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=e3b14f0d0cf061ff4e881d277dc852b0fa389676'/>
<id>urn:sha1:e3b14f0d0cf061ff4e881d277dc852b0fa389676</id>
<content type='text'>
commit 615b2665fd20c327b631ff1e79426775de748094 upstream.

As found by the ubsan checker, the value of the 'index' variable can be
out of range for the bc[] array:

UBSAN: Undefined behaviour in arch/parisc/kernel/drivers.c:655:21
index 6 is out of range for type 'char [6]'
Backtrace:
 [&lt;104fa850&gt;] __ubsan_handle_out_of_bounds+0x68/0x80
 [&lt;1019d83c&gt;] check_parent+0xc0/0x170
 [&lt;1019d91c&gt;] descend_children+0x30/0x6c
 [&lt;1059e164&gt;] device_for_each_child+0x60/0x98
 [&lt;1019cd54&gt;] parse_tree_node+0x40/0x54
 [&lt;1019d86c&gt;] check_parent+0xf0/0x170
 [&lt;1019d91c&gt;] descend_children+0x30/0x6c
 [&lt;1059e164&gt;] device_for_each_child+0x60/0x98
 [&lt;1019d938&gt;] descend_children+0x4c/0x6c
 [&lt;1059e164&gt;] device_for_each_child+0x60/0x98
 [&lt;1019cd54&gt;] parse_tree_node+0x40/0x54
 [&lt;1019cffc&gt;] hwpath_to_device+0xa4/0xc4

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

</content>
</entry>
<entry>
<title>parisc: Handle case where flush_cache_range is called with no context</title>
<updated>2018-03-17T10:49:39+00:00</updated>
<author>
<name>John David Anglin</name>
<email>dave.anglin@bell.net</email>
</author>
<published>2018-03-07T13:18:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=9ef0f88fe5466c2ca1d2975549ba6be502c464c1'/>
<id>urn:sha1:9ef0f88fe5466c2ca1d2975549ba6be502c464c1</id>
<content type='text'>
Just when I had decided that flush_cache_range() was always called with
a valid context, Helge reported two cases where the
"BUG_ON(!vma-&gt;vm_mm-&gt;context);" was hit on the phantom buildd:

 kernel BUG at /mnt/sdb6/linux/linux-4.15.4/arch/parisc/kernel/cache.c:587!
 CPU: 1 PID: 3254 Comm: kworker/1:2 Tainted: G D 4.15.0-1-parisc64-smp #1 Debian 4.15.4-1+b1
 Workqueue: events free_ioctx
  IAOQ[0]: flush_cache_range+0x164/0x168
  IAOQ[1]: flush_cache_page+0x0/0x1c8
  RP(r2): unmap_page_range+0xae8/0xb88
 Backtrace:
  [&lt;00000000404a6980&gt;] unmap_page_range+0xae8/0xb88
  [&lt;00000000404a6ae0&gt;] unmap_single_vma+0xc0/0x188
  [&lt;00000000404a6cdc&gt;] zap_page_range_single+0x134/0x1f8
  [&lt;00000000404a702c&gt;] unmap_mapping_range+0x1cc/0x208
  [&lt;0000000040461518&gt;] truncate_pagecache+0x98/0x108
  [&lt;0000000040461624&gt;] truncate_setsize+0x9c/0xb8
  [&lt;00000000405d7f30&gt;] put_aio_ring_file+0x80/0x100
  [&lt;00000000405d803c&gt;] aio_free_ring+0x8c/0x290
  [&lt;00000000405d82c0&gt;] free_ioctx+0x80/0x180
  [&lt;0000000040284e6c&gt;] process_one_work+0x21c/0x668
  [&lt;00000000402854c4&gt;] worker_thread+0x20c/0x778
  [&lt;0000000040291d44&gt;] kthread+0x2d4/0x2e0
  [&lt;0000000040204020&gt;] end_fault_vector+0x20/0xc0

This indicates that we need to handle the no context case in
flush_cache_range() as we do in flush_cache_mm().

In thinking about this, I realized that we don't need to flush the TLB
when there is no context.  So, I added context checks to the large flush
cases in flush_cache_mm() and flush_cache_range().  The large flush case
occurs frequently in flush_cache_mm() and the change should improve fork
performance.

The v2 version of this change removes the BUG_ON from flush_cache_page()
by skipping the TLB flush when there is no context.  I also added code
to flush the TLB in flush_cache_mm() and flush_cache_range() when we
have a context that's not current.  Now all three routines handle TLB
flushes in a similar manner.

Signed-off-by: John David Anglin &lt;dave.anglin@bell.net&gt;
Cc: stable@vger.kernel.org # 4.9+
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</content>
</entry>
<entry>
<title>Merge branch 'parisc-4.16-1' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux</title>
<updated>2018-03-02T21:05:20+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2018-03-02T21:05:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=5fbdefcf685defd8bc5a8f37b17538d25c58d77a'/>
<id>urn:sha1:5fbdefcf685defd8bc5a8f37b17538d25c58d77a</id>
<content type='text'>
Pull parisc fixes from Helge Deller:

 - a patch to change the ordering of cache and TLB flushes to hopefully
   fix the random segfaults we very rarely face (by Dave Anglin).

 - a patch to hide the virtual kernel memory layout due to security
   reasons.

 - two small patches to make the kernel run more smoothly under qemu.

* 'parisc-4.16-1' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
  parisc: Reduce irq overhead when run in qemu
  parisc: Use cr16 interval timers unconditionally on qemu
  parisc: Check if secondary CPUs want own PDC calls
  parisc: Hide virtual kernel memory layout
  parisc: Fix ordering of cache and TLB flushes
</content>
</entry>
<entry>
<title>parisc: Reduce irq overhead when run in qemu</title>
<updated>2018-03-02T09:05:07+00:00</updated>
<author>
<name>Helge Deller</name>
<email>deller@gmx.de</email>
</author>
<published>2018-02-12T20:43:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=636a415bcc7f4fd020ece8fd5fc648c4cef19c34'/>
<id>urn:sha1:636a415bcc7f4fd020ece8fd5fc648c4cef19c34</id>
<content type='text'>
When run under QEMU, calling mfctl(16) creates some overhead because the
qemu timer has to be scaled and moved into the register. This patch
reduces the number of calls to mfctl(16) by moving the calls out of the
loops.

Additionally, increase the minimal time interval to 8000 cycles instead
of 500 to compensate possible QEMU delays when delivering interrupts.

Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
Cc: stable@vger.kernel.org # 4.14+
</content>
</entry>
<entry>
<title>parisc: Use cr16 interval timers unconditionally on qemu</title>
<updated>2018-03-02T09:04:59+00:00</updated>
<author>
<name>Helge Deller</name>
<email>deller@gmx.de</email>
</author>
<published>2018-01-12T21:44:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=5ffa8518851f1401817c15d2a7eecc0373c26ff9'/>
<id>urn:sha1:5ffa8518851f1401817c15d2a7eecc0373c26ff9</id>
<content type='text'>
When running on qemu we know that the (emulated) cr16 cpu-internal
clocks are syncronized. So let's use them unconditionally on qemu.

Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
Cc: stable@vger.kernel.org # 4.14+
</content>
</entry>
<entry>
<title>parisc: Check if secondary CPUs want own PDC calls</title>
<updated>2018-03-02T09:04:46+00:00</updated>
<author>
<name>Helge Deller</name>
<email>deller@gmx.de</email>
</author>
<published>2018-01-12T21:51:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=0ed1fe4ad394e54783bbffa84102faf435661a2e'/>
<id>urn:sha1:0ed1fe4ad394e54783bbffa84102faf435661a2e</id>
<content type='text'>
The architecture specification says (for 64-bit systems): PDC is a per
processor resource, and operating system software must be prepared to
manage separate pointers to PDCE_PROC for each processor.  The address
of PDCE_PROC for the monarch processor is stored in the Page Zero
location MEM_PDC. The address of PDCE_PROC for each non-monarch
processor is passed in gr26 when PDCE_RESET invokes OS_RENDEZ.

Currently we still use one PDC for all CPUs, but in case we face a
machine which is following the specification let's warn about it.

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