<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/arch/parisc/kernel, branch linux-5.19.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.19.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.19.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2022-10-24T07:56:45Z</updated>
<entry>
<title>parisc: Fix userspace graphics card breakage due to pgtable special bit</title>
<updated>2022-10-24T07:56:45Z</updated>
<author>
<name>Helge Deller</name>
</author>
<published>2022-10-14T08:18:53Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=68a1aac5bdd5ba681d6406115ac0214d74bf498f'/>
<id>urn:sha1:68a1aac5bdd5ba681d6406115ac0214d74bf498f</id>
<content type='text'>
commit 70be49f2f6223ddd2fcddb0089a40864c37e1494 upstream.

Commit df24e1783e6e ("parisc: Add vDSO support") introduced the vDSO
support, for which a _PAGE_SPECIAL page table flag was needed.  Since we
wanted to keep every page table entry in 32-bits, this patch re-used the
existing - but yet unused - _PAGE_DMB flag (which triggers a hardware break
if a page is accessed) to store the special bit.

But when graphics card memory is mmapped into userspace, the kernel uses
vm_iomap_memory() which sets the the special flag. So, with the DMB bit
set, every access to the graphics memory now triggered a hardware
exception and segfaulted the userspace program.

Fix this breakage by dropping the DMB bit when writing the page
protection bits to the CPU TLB.

In addition this patch adds a small optimization: if huge pages aren't
configured (which is at least the case for 32-bit kernels), then the
special bit is stored in the hpage (HUGE PAGE) bit instead. That way we
can skip to reset the DMB bit.

Fixes: df24e1783e6e ("parisc: Add vDSO support")
Cc: &lt;stable@vger.kernel.org&gt; # 5.18+
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: Add runtime check to prevent PA2.0 kernels on PA1.x machines</title>
<updated>2022-09-15T08:47:08Z</updated>
<author>
<name>Helge Deller</name>
</author>
<published>2022-08-21T12:49:58Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=078dac729f733cbf55fd25bd0ac0ed70f299b2ab'/>
<id>urn:sha1:078dac729f733cbf55fd25bd0ac0ed70f299b2ab</id>
<content type='text'>
[ Upstream commit 591d2108f3abc4db9f9073cae37cf3591fd250d6 ]

If a 32-bit kernel was compiled for PA2.0 CPUs, it won't be able to run
on machines with PA1.x CPUs. Add a check and bail out early if a PA1.x
machine is detected.

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 exception handler for fldw and fstw instructions</title>
<updated>2022-08-31T15:17:59Z</updated>
<author>
<name>Helge Deller</name>
</author>
<published>2022-08-20T15:59:17Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=760dc9f658d7fb133007eba63fa012618752fd48'/>
<id>urn:sha1:760dc9f658d7fb133007eba63fa012618752fd48</id>
<content type='text'>
commit 7ae1f5508d9a33fd58ed3059bd2d569961e3b8bd upstream.

The exception handler is broken for unaligned memory acceses with fldw
and fstw instructions, because it trashes or uses randomly some other
floating point register than the one specified in the instruction word
on loads and stores.

The instruction "fldw 0(addr),%fr22L" (and the other fldw/fstw
instructions) encode the target register (%fr22) in the rightmost 5 bits
of the instruction word. The 7th rightmost bit of the instruction word
defines if the left or right half of %fr22 should be used.

While processing unaligned address accesses, the FR3() define is used to
extract the offset into the local floating-point register set.  But the
calculation in FR3() was buggy, so that for example instead of %fr22,
register %fr12 [((22 * 2) &amp; 0x1f) = 12] was used.

This bug has been since forever in the parisc kernel and I wonder why it
wasn't detected earlier. Interestingly I noticed this bug just because
the libime debian package failed to build on *native* hardware, while it
successfully built in qemu.

This patch corrects the bitshift and masking calculation in FR3().

Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>parisc: io_pgetevents_time64() needs compat syscall in 32-bit compat mode</title>
<updated>2022-08-17T13:13:48Z</updated>
<author>
<name>Helge Deller</name>
</author>
<published>2022-08-01T15:36:15Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=844a857bbce3687af5fb1ba4c2e9243016766717'/>
<id>urn:sha1:844a857bbce3687af5fb1ba4c2e9243016766717</id>
<content type='text'>
commit 6431e92fc827bdd2d28f79150d90415ba9ce0d21 upstream.

For all syscalls in 32-bit compat mode on 64-bit kernels the upper
32-bits of the 64-bit registers are zeroed out, so a negative 32-bit
signed value will show up as positive 64-bit signed value.

This behaviour breaks the io_pgetevents_time64() syscall which expects
signed 64-bit values for the "min_nr" and "nr" parameters.
Fix this by switching to the compat_sys_io_pgetevents_time64() syscall,
which uses "compat_long_t" types for those parameters.

Cc: &lt;stable@vger.kernel.org&gt; # v5.1+
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: Drop pa_swapper_pg_lock spinlock</title>
<updated>2022-08-17T13:13:48Z</updated>
<author>
<name>Helge Deller</name>
</author>
<published>2022-07-19T04:19:41Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=6f0c087a68e5ce6b1de8ba18ed59f14c606e74d5'/>
<id>urn:sha1:6f0c087a68e5ce6b1de8ba18ed59f14c606e74d5</id>
<content type='text'>
commit 3fbc9a7de0564c55d8a9584c9cd2c9dfe6bd6d43 upstream.

This spinlock was dropped with commit b7795074a046 ("parisc: Optimize
per-pagetable spinlocks") in kernel v5.12.

Remove it to silence a sparse warning.

Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
Reported-by: kernel test robot &lt;lkp@intel.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # v5.12+
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>parisc: Fix device names in /proc/iomem</title>
<updated>2022-08-17T13:13:48Z</updated>
<author>
<name>Helge Deller</name>
</author>
<published>2022-07-18T15:06:47Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=5c9e6c5e86a09314fb52c01be03010715cbdc369'/>
<id>urn:sha1:5c9e6c5e86a09314fb52c01be03010715cbdc369</id>
<content type='text'>
commit cab56b51ec0e69128909cef4650e1907248d821b upstream.

Fix the output of /proc/iomem to show the real hardware device name
including the pa_pathname, e.g. "Merlin 160 Core Centronics [8:16:0]".
Up to now only the pa_pathname ("[8:16.0]") was shown.

Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
Cc: &lt;stable@vger.kernel.org&gt; # v4.9+
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>parisc: Fix vDSO signal breakage on 32-bit kernel</title>
<updated>2022-07-02T16:36:58Z</updated>
<author>
<name>Helge Deller</name>
</author>
<published>2022-07-01T07:00:41Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=aa78fa905b4431c432071a878da99c2b37fc0e79'/>
<id>urn:sha1:aa78fa905b4431c432071a878da99c2b37fc0e79</id>
<content type='text'>
Addition of vDSO support for parisc in kernel v5.18 suddenly broke glibc
signal testcases on a 32-bit kernel.

The trampoline code (sigtramp.S) which is mapped into userspace includes
an offset to the context data on the stack, which is used by gdb and
glibc to get access to registers.

In a 32-bit kernel we used by mistake the offset into the compat context
(which is valid on a 64-bit kernel only) instead of the offset into the
"native" 32-bit context.

Reported-by: John David Anglin &lt;dave.anglin@bell.net&gt;
Tested-by: John David Anglin &lt;dave.anglin@bell.net&gt;
Fixes: 	df24e1783e6e ("parisc: Add vDSO support")
CC: stable@vger.kernel.org # 5.18
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</content>
</entry>
<entry>
<title>parisc/unaligned: Fix emulate_ldw() breakage</title>
<updated>2022-06-27T19:30:11Z</updated>
<author>
<name>Helge Deller</name>
</author>
<published>2022-06-26T23:39:11Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=96b80fcd2705fc50ebe1f7f3ce204e861b3099ab'/>
<id>urn:sha1:96b80fcd2705fc50ebe1f7f3ce204e861b3099ab</id>
<content type='text'>
The commit e8aa7b17fe41 broke the 32-bit load-word unalignment exception
handler because it calculated the wrong amount of bits by which the value
should be shifted. This patch fixes it.

Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
Fixes: e8aa7b17fe41 ("parisc/unaligned: Rewrite inline assembly of emulate_ldw()")
Cc: stable@vger.kernel.org   # v5.18
</content>
</entry>
<entry>
<title>parisc: Fix flush_anon_page on PA8800/PA8900</title>
<updated>2022-06-26T10:23:15Z</updated>
<author>
<name>John David Anglin</name>
</author>
<published>2022-06-18T15:14:34Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=e9ed22e6e5010997a2f922eef61ca797d0a2a246'/>
<id>urn:sha1:e9ed22e6e5010997a2f922eef61ca797d0a2a246</id>
<content type='text'>
Anonymous pages are allocated with the shared mappings colouring,
SHM_COLOUR. Since the alias boundary on machines with PA8800 and
PA8900 processors is unknown, flush_user_cache_page() might not
flush all mappings of a shared anonymous page. Flushing the whole
data cache flushes all mappings.

This won't fix all coherency issues with shared mappings but it
seems to work well in practice.  I haven't seen any random memory
faults in almost a month on a rp3440 running as a debian buildd
machine.

There is a small preformance hit.

Signed-off-by: John David Anglin &lt;dave.anglin@bell.net&gt;
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
Cc: stable@vger.kernel.org   # v5.18+
</content>
</entry>
<entry>
<title>Merge tag 'for-5.19/parisc-2' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux</title>
<updated>2022-06-04T20:50:23Z</updated>
<author>
<name>Linus Torvalds</name>
</author>
<published>2022-06-04T20:50:23Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=23df9ba64bb9e26cfee6b34f5c3ece49a8a61ee1'/>
<id>urn:sha1:23df9ba64bb9e26cfee6b34f5c3ece49a8a61ee1</id>
<content type='text'>
Pull more parisc architecture updates from Helge Deller:
 "A fix to prevent crash at bootup if CONFIG_SCHED_MC is enabled, and
  add auto-detection of primary graphics card for framebuffer driver"

* tag 'for-5.19/parisc-2' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
  parisc/stifb: Keep track of hardware path of graphics card
  parisc/stifb: Implement fb_is_primary_device()
  parisc: fix a crash with multicore scheduler
</content>
</entry>
</feed>
