<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/arch/parisc, branch v6.4.2</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>parisc: fix expand_stack() conversion</title>
<updated>2023-07-01T11:12:41+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2023-06-30T06:04:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=0d98e5325f1f423be19c6124905133951cc17198'/>
<id>0d98e5325f1f423be19c6124905133951cc17198</id>
<content type='text'>
commit ea3f8272876f2958463992f6736ab690fde7fa9c upstream.

In commit 8d7071af8907 ("mm: always expand the stack with the mmap write
lock held") I tried to deal with the remaining odd page fault handling
cases.  The oddest one is ia64, which has stacks that grow both up and
down.  And because ia64 was _so_ odd, I asked people to verify the end
result.

But a close second oddity is parisc, which is the only one that has a
main stack growing up (our "CONFIG_STACK_GROWSUP" config option).  But
it looked obvious enough that I didn't worry about it.

I should have worried a bit more.  Not because it was particularly
complex, but because I just used the wrong variable name.

The previous vma isn't called "prev", it's called "prev_vma".  Blush.

Fixes: 8d7071af8907 ("mm: always expand the stack with the mmap write lock held")
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit ea3f8272876f2958463992f6736ab690fde7fa9c upstream.

In commit 8d7071af8907 ("mm: always expand the stack with the mmap write
lock held") I tried to deal with the remaining odd page fault handling
cases.  The oddest one is ia64, which has stacks that grow both up and
down.  And because ia64 was _so_ odd, I asked people to verify the end
result.

But a close second oddity is parisc, which is the only one that has a
main stack growing up (our "CONFIG_STACK_GROWSUP" config option).  But
it looked obvious enough that I didn't worry about it.

I should have worried a bit more.  Not because it was particularly
complex, but because I just used the wrong variable name.

The previous vma isn't called "prev", it's called "prev_vma".  Blush.

Fixes: 8d7071af8907 ("mm: always expand the stack with the mmap write lock held")
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mm: always expand the stack with the mmap write lock held</title>
<updated>2023-07-01T11:12:40+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2023-06-24T20:45:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=fb32951c89030c5f9944ca8aa10301d7eb733b49'/>
<id>fb32951c89030c5f9944ca8aa10301d7eb733b49</id>
<content type='text'>
commit 8d7071af890768438c14db6172cc8f9f4d04e184 upstream.

This finishes the job of always holding the mmap write lock when
extending the user stack vma, and removes the 'write_locked' argument
from the vm helper functions again.

For some cases, we just avoid expanding the stack at all: drivers and
page pinning really shouldn't be extending any stacks.  Let's see if any
strange users really wanted that.

It's worth noting that architectures that weren't converted to the new
lock_mm_and_find_vma() helper function are left using the legacy
"expand_stack()" function, but it has been changed to drop the mmap_lock
and take it for writing while expanding the vma.  This makes it fairly
straightforward to convert the remaining architectures.

As a result of dropping and re-taking the lock, the calling conventions
for this function have also changed, since the old vma may no longer be
valid.  So it will now return the new vma if successful, and NULL - and
the lock dropped - if the area could not be extended.

Tested-by: Vegard Nossum &lt;vegard.nossum@oracle.com&gt;
Tested-by: John Paul Adrian Glaubitz &lt;glaubitz@physik.fu-berlin.de&gt; # ia64
Tested-by: Frank Scheiner &lt;frank.scheiner@web.de&gt; # ia64
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 8d7071af890768438c14db6172cc8f9f4d04e184 upstream.

This finishes the job of always holding the mmap write lock when
extending the user stack vma, and removes the 'write_locked' argument
from the vm helper functions again.

For some cases, we just avoid expanding the stack at all: drivers and
page pinning really shouldn't be extending any stacks.  Let's see if any
strange users really wanted that.

It's worth noting that architectures that weren't converted to the new
lock_mm_and_find_vma() helper function are left using the legacy
"expand_stack()" function, but it has been changed to drop the mmap_lock
and take it for writing while expanding the vma.  This makes it fairly
straightforward to convert the remaining architectures.

As a result of dropping and re-taking the lock, the calling conventions
for this function have also changed, since the old vma may no longer be
valid.  So it will now return the new vma if successful, and NULL - and
the lock dropped - if the area could not be extended.

Tested-by: Vegard Nossum &lt;vegard.nossum@oracle.com&gt;
Tested-by: John Paul Adrian Glaubitz &lt;glaubitz@physik.fu-berlin.de&gt; # ia64
Tested-by: Frank Scheiner &lt;frank.scheiner@web.de&gt; # ia64
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>parisc: Delete redundant register definitions in &lt;asm/assembly.h&gt;</title>
<updated>2023-06-17T04:48:11+00:00</updated>
<author>
<name>Ben Hutchings</name>
<email>benh@debian.org</email>
</author>
<published>2023-06-14T22:00:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b5b2a02bcaac7c287694aa0db4837a07bf178626'/>
<id>b5b2a02bcaac7c287694aa0db4837a07bf178626</id>
<content type='text'>
We define sp and ipsw in &lt;asm/asmregs.h&gt; using ".reg", and when using
current binutils (snapshot 2.40.50.20230611) the definitions in
&lt;asm/assembly.h&gt; using "=" conflict with those:

arch/parisc/include/asm/assembly.h: Assembler messages:
arch/parisc/include/asm/assembly.h:93: Error: symbol `sp' is already defined
arch/parisc/include/asm/assembly.h:95: Error: symbol `ipsw' is already defined

Delete the duplicate definitions in &lt;asm/assembly.h&gt;.

Also delete the definition of gp, which isn't used anywhere.

Signed-off-by: Ben Hutchings &lt;benh@debian.org&gt;
Cc: stable@vger.kernel.org # v6.0+
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
We define sp and ipsw in &lt;asm/asmregs.h&gt; using ".reg", and when using
current binutils (snapshot 2.40.50.20230611) the definitions in
&lt;asm/assembly.h&gt; using "=" conflict with those:

arch/parisc/include/asm/assembly.h: Assembler messages:
arch/parisc/include/asm/assembly.h:93: Error: symbol `sp' is already defined
arch/parisc/include/asm/assembly.h:95: Error: symbol `ipsw' is already defined

Delete the duplicate definitions in &lt;asm/assembly.h&gt;.

Also delete the definition of gp, which isn't used anywhere.

Signed-off-by: Ben Hutchings &lt;benh@debian.org&gt;
Cc: stable@vger.kernel.org # v6.0+
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>parisc: Fix flush_dcache_page() for usage from irq context</title>
<updated>2023-05-24T17:03:49+00:00</updated>
<author>
<name>Helge Deller</name>
<email>deller@gmx.de</email>
</author>
<published>2023-05-24T15:07:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=61e150fb310729c98227a5edf6e4a3619edc3702'/>
<id>61e150fb310729c98227a5edf6e4a3619edc3702</id>
<content type='text'>
Since at least kernel 6.1, flush_dcache_page() is called with IRQs
disabled, e.g. from aio_complete().

But the current implementation for flush_dcache_page() on parisc
unintentionally re-enables IRQs, which may lead to deadlocks.

Fix it by using xa_lock_irqsave() and xa_unlock_irqrestore()
for the flush_dcache_mmap_*lock() macros instead.

Cc: linux-parisc@vger.kernel.org
Cc: stable@kernel.org # 5.18+
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Since at least kernel 6.1, flush_dcache_page() is called with IRQs
disabled, e.g. from aio_complete().

But the current implementation for flush_dcache_page() on parisc
unintentionally re-enables IRQs, which may lead to deadlocks.

Fix it by using xa_lock_irqsave() and xa_unlock_irqrestore()
for the flush_dcache_mmap_*lock() macros instead.

Cc: linux-parisc@vger.kernel.org
Cc: stable@kernel.org # 5.18+
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>parisc: Handle kgdb breakpoints only in kernel context</title>
<updated>2023-05-24T13:46:12+00:00</updated>
<author>
<name>Helge Deller</name>
<email>deller@gmx.de</email>
</author>
<published>2023-05-24T12:34:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=6888ff04e37d01295620a73f3f7efbc79f6ef152'/>
<id>6888ff04e37d01295620a73f3f7efbc79f6ef152</id>
<content type='text'>
The kernel kgdb break instructions should only be handled when running
in kernel context.

Cc: &lt;stable@vger.kernel.org&gt; # v5.4+
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The kernel kgdb break instructions should only be handled when running
in kernel context.

Cc: &lt;stable@vger.kernel.org&gt; # v5.4+
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>parisc: Handle kprobes breakpoints only in kernel context</title>
<updated>2023-05-24T13:46:12+00:00</updated>
<author>
<name>Helge Deller</name>
<email>deller@gmx.de</email>
</author>
<published>2023-05-24T12:31:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=df419492e428b6a2bce98d0f613c58a13da6666c'/>
<id>df419492e428b6a2bce98d0f613c58a13da6666c</id>
<content type='text'>
The kernel kprobes break instructions should only be handled when running
in kernel context.

Cc: &lt;stable@vger.kernel.org&gt; # v5.18+
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The kernel kprobes break instructions should only be handled when running
in kernel context.

Cc: &lt;stable@vger.kernel.org&gt; # v5.18+
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>parisc: Allow to reboot machine after system halt</title>
<updated>2023-05-24T13:46:12+00:00</updated>
<author>
<name>Helge Deller</name>
<email>deller@gmx.de</email>
</author>
<published>2023-05-22T20:57:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=2028315cf59bb899a5ac7e87dc48ecb8fac7ac24'/>
<id>2028315cf59bb899a5ac7e87dc48ecb8fac7ac24</id>
<content type='text'>
In case a machine can't power-off itself on system shutdown,
allow the user to reboot it by pressing the RETURN key.

Cc: &lt;stable@vger.kernel.org&gt; # v4.14+
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In case a machine can't power-off itself on system shutdown,
allow the user to reboot it by pressing the RETURN key.

Cc: &lt;stable@vger.kernel.org&gt; # v4.14+
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>parisc: Enable LOCKDEP support</title>
<updated>2023-05-24T12:27:28+00:00</updated>
<author>
<name>Helge Deller</name>
<email>deller@gmx.de</email>
</author>
<published>2023-05-23T07:06:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=adf8e96a7ea670d45b5de7594acc67e8f4787ae6'/>
<id>adf8e96a7ea670d45b5de7594acc67e8f4787ae6</id>
<content type='text'>
Cc: &lt;stable@vger.kernel.org&gt; # v6.0+
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Cc: &lt;stable@vger.kernel.org&gt; # v6.0+
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>parisc: Add lightweight spinlock checks</title>
<updated>2023-05-24T12:23:07+00:00</updated>
<author>
<name>Helge Deller</name>
<email>deller@gmx.de</email>
</author>
<published>2023-05-22T13:11:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=15e64ef6520ea8702998db05b87fa5c3d3d40710'/>
<id>15e64ef6520ea8702998db05b87fa5c3d3d40710</id>
<content type='text'>
Add a lightweight spinlock check which uses only two instructions
per spinlock call. It detects if a spinlock has been trashed by
some memory corruption and then halts the kernel. It will not detect
uninitialized spinlocks, for which CONFIG_DEBUG_SPINLOCK needs to
be enabled.

This lightweight spinlock check shouldn't influence runtime, so it's
safe to enable it by default.

The __ARCH_SPIN_LOCK_UNLOCKED_VAL constant has been choosen small enough
to be able to be loaded by one LDI assembler statement.

Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add a lightweight spinlock check which uses only two instructions
per spinlock call. It detects if a spinlock has been trashed by
some memory corruption and then halts the kernel. It will not detect
uninitialized spinlocks, for which CONFIG_DEBUG_SPINLOCK needs to
be enabled.

This lightweight spinlock check shouldn't influence runtime, so it's
safe to enable it by default.

The __ARCH_SPIN_LOCK_UNLOCKED_VAL constant has been choosen small enough
to be able to be loaded by one LDI assembler statement.

Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>parisc: Use num_present_cpus() in alternative patching code</title>
<updated>2023-05-23T16:17:32+00:00</updated>
<author>
<name>Helge Deller</name>
<email>deller@gmx.de</email>
</author>
<published>2023-05-19T10:12:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b6405f0829d7b1dd926ba3ca5f691cab835abfaa'/>
<id>b6405f0829d7b1dd926ba3ca5f691cab835abfaa</id>
<content type='text'>
When patching the kernel code some alternatives depend on SMP vs. !SMP.
Use the value of num_present_cpus() instead of num_online_cpus() to
decide, otherwise we may run into issues if and additional CPU is
enabled after having loaded a module while only one CPU was enabled.

Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
Cc: &lt;stable@vger.kernel.org&gt; # v6.1+
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When patching the kernel code some alternatives depend on SMP vs. !SMP.
Use the value of num_present_cpus() instead of num_online_cpus() to
decide, otherwise we may run into issues if and additional CPU is
enabled after having loaded a module while only one CPU was enabled.

Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
Cc: &lt;stable@vger.kernel.org&gt; # v6.1+
</pre>
</div>
</content>
</entry>
</feed>
