<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/arch/mips/include, branch v3.18.22</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>MIPS: Make set_pte() SMP safe.</title>
<updated>2015-08-19T17:15:59+00:00</updated>
<author>
<name>David Daney</name>
<email>david.daney@cavium.com</email>
</author>
<published>2015-08-04T00:48:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=204041c4a640f004a5df152434f05b96ee76dfab'/>
<id>204041c4a640f004a5df152434f05b96ee76dfab</id>
<content type='text'>
[ Upstream commit 46011e6ea39235e4aca656673c500eac81a07a17 ]

On MIPS the GLOBAL bit of the PTE must have the same value in any
aligned pair of PTEs.  These pairs of PTEs are referred to as
"buddies".  In a SMP system is is possible for two CPUs to be calling
set_pte() on adjacent PTEs at the same time.  There is a race between
setting the PTE and a different CPU setting the GLOBAL bit in its
buddy PTE.

This race can be observed when multiple CPUs are executing
vmap()/vfree() at the same time.

Make setting the buddy PTE's GLOBAL bit an atomic operation to close
the race condition.

The case of CONFIG_64BIT_PHYS_ADDR &amp;&amp; CONFIG_CPU_MIPS32 is *not*
handled.

Signed-off-by: David Daney &lt;david.daney@cavium.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/10835/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 46011e6ea39235e4aca656673c500eac81a07a17 ]

On MIPS the GLOBAL bit of the PTE must have the same value in any
aligned pair of PTEs.  These pairs of PTEs are referred to as
"buddies".  In a SMP system is is possible for two CPUs to be calling
set_pte() on adjacent PTEs at the same time.  There is a race between
setting the PTE and a different CPU setting the GLOBAL bit in its
buddy PTE.

This race can be observed when multiple CPUs are executing
vmap()/vfree() at the same time.

Make setting the buddy PTE's GLOBAL bit an atomic operation to close
the race condition.

The case of CONFIG_64BIT_PHYS_ADDR &amp;&amp; CONFIG_CPU_MIPS32 is *not*
handled.

Signed-off-by: David Daney &lt;david.daney@cavium.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/10835/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: Flush RPS on kernel entry with EVA</title>
<updated>2015-08-19T17:15:43+00:00</updated>
<author>
<name>James Hogan</name>
<email>james.hogan@imgtec.com</email>
</author>
<published>2015-07-31T15:29:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e1c3e51cf7e1de53b9279ac6a02ceb8630dd15f2'/>
<id>e1c3e51cf7e1de53b9279ac6a02ceb8630dd15f2</id>
<content type='text'>
[ Upstream commit 3aff47c062b944a5e1f9af56a37a23f5295628fc ]

When EVA is enabled, flush the Return Prediction Stack (RPS) present on
some MIPS cores on entry to the kernel from user mode.

This is important specifically for interAptiv with EVA enabled,
otherwise kernel mode RPS mispredicts may trigger speculative fetches of
user return addresses, which may be sensitive in the kernel address
space due to EVA's overlapping user/kernel address spaces.

Signed-off-by: James Hogan &lt;james.hogan@imgtec.com&gt;
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: Markos Chandras &lt;markos.chandras@imgtec.com&gt;
Cc: Leonid Yegoshin &lt;leonid.yegoshin@imgtec.com&gt;
Cc: linux-mips@linux-mips.org
Cc: &lt;stable@vger.kernel.org&gt; # 3.15.x-
Patchwork: https://patchwork.linux-mips.org/patch/10812/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 3aff47c062b944a5e1f9af56a37a23f5295628fc ]

When EVA is enabled, flush the Return Prediction Stack (RPS) present on
some MIPS cores on entry to the kernel from user mode.

This is important specifically for interAptiv with EVA enabled,
otherwise kernel mode RPS mispredicts may trigger speculative fetches of
user return addresses, which may be sensitive in the kernel address
space due to EVA's overlapping user/kernel address spaces.

Signed-off-by: James Hogan &lt;james.hogan@imgtec.com&gt;
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: Markos Chandras &lt;markos.chandras@imgtec.com&gt;
Cc: Leonid Yegoshin &lt;leonid.yegoshin@imgtec.com&gt;
Cc: linux-mips@linux-mips.org
Cc: &lt;stable@vger.kernel.org&gt; # 3.15.x-
Patchwork: https://patchwork.linux-mips.org/patch/10812/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: Fix KVM guest fixmap address</title>
<updated>2015-07-05T14:12:46+00:00</updated>
<author>
<name>James Hogan</name>
<email>james.hogan@imgtec.com</email>
</author>
<published>2015-04-27T14:07:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=19194bcaea1812960b0d3927f728b30f4a850581'/>
<id>19194bcaea1812960b0d3927f728b30f4a850581</id>
<content type='text'>
[ Upstream commit 8e748c8d09a9314eedb5c6367d9acfaacddcdc88 ]

KVM guest kernels for trap &amp; emulate run in user mode, with a modified
set of kernel memory segments. However the fixmap address is still in
the normal KSeg3 region at 0xfffe0000 regardless, causing problems when
cache alias handling makes use of them when handling copy on write.

Therefore define FIXADDR_TOP as 0x7ffe0000 in the guest kernel mapped
region when CONFIG_KVM_GUEST is defined.

Signed-off-by: James Hogan &lt;james.hogan@imgtec.com&gt;
Cc: linux-mips@linux-mips.org
Cc: &lt;stable@vger.kernel.org&gt; # v3.10+
Patchwork: https://patchwork.linux-mips.org/patch/9887/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 8e748c8d09a9314eedb5c6367d9acfaacddcdc88 ]

KVM guest kernels for trap &amp; emulate run in user mode, with a modified
set of kernel memory segments. However the fixmap address is still in
the normal KSeg3 region at 0xfffe0000 regardless, causing problems when
cache alias handling makes use of them when handling copy on write.

Therefore define FIXADDR_TOP as 0x7ffe0000 in the guest kernel mapped
region when CONFIG_KVM_GUEST is defined.

Signed-off-by: James Hogan &lt;james.hogan@imgtec.com&gt;
Cc: linux-mips@linux-mips.org
Cc: &lt;stable@vger.kernel.org&gt; # v3.10+
Patchwork: https://patchwork.linux-mips.org/patch/9887/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: Octeon: Delete override of cpu_has_mips_r2_exec_hazard.</title>
<updated>2015-05-17T23:12:34+00:00</updated>
<author>
<name>Ralf Baechle</name>
<email>ralf@linux-mips.org</email>
</author>
<published>2015-03-25T12:21:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=3552e350208a52dcfe043093b7eba7d68473ea3f'/>
<id>3552e350208a52dcfe043093b7eba7d68473ea3f</id>
<content type='text'>
[ Upstream commit f05ff43355e6997c18f82ddcee370a6e5f8643ce ]

This is no longer needed with the fixed, new and improved definition
of cpu_has_mips_r2_exec_hazard in &lt;asm/cpu-features.h&gt;.

For a discussion, see http://patchwork.linux-mips.org/patch/9539/.

Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit f05ff43355e6997c18f82ddcee370a6e5f8643ce ]

This is no longer needed with the fixed, new and improved definition
of cpu_has_mips_r2_exec_hazard in &lt;asm/cpu-features.h&gt;.

For a discussion, see http://patchwork.linux-mips.org/patch/9539/.

Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: Octeon: Remove udelay() causing huge IRQ latency</title>
<updated>2015-05-17T23:12:33+00:00</updated>
<author>
<name>Alexander Sverdlin</name>
<email>alexander.sverdlin@nokia.com</email>
</author>
<published>2015-03-18T13:05:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=9ba256194c36f2881d49767373d3185d6cd6bb0b'/>
<id>9ba256194c36f2881d49767373d3185d6cd6bb0b</id>
<content type='text'>
[ Upstream commit 73bf3c2a500b2db8ac966469591196bf55afb409 ]

udelay() in PCI/PCIe read/write callbacks cause 30ms IRQ latency on Octeon
platforms because these operations are called from PCI_OP_READ() and
PCI_OP_WRITE() under raw_spin_lock_irqsave().

Signed-off-by: Alexander Sverdlin &lt;alexander.sverdlin@nokia.com&gt;
Cc: linux-mips@linux-mips.org
Cc: David Daney &lt;ddaney@cavium.com&gt;
Cc: Rob Herring &lt;robh@kernel.org&gt;
Cc: Jiri Kosina &lt;jkosina@suse.cz&gt;
Cc: Randy Dunlap &lt;rdunlap@infradead.org&gt;
Cc: Masanari Iida &lt;standby24x7@gmail.com&gt;
Cc: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Cc: Mathias &lt;mathias.rulf@nokia.com&gt;
Patchwork: https://patchwork.linux-mips.org/patch/9576/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 73bf3c2a500b2db8ac966469591196bf55afb409 ]

udelay() in PCI/PCIe read/write callbacks cause 30ms IRQ latency on Octeon
platforms because these operations are called from PCI_OP_READ() and
PCI_OP_WRITE() under raw_spin_lock_irqsave().

Signed-off-by: Alexander Sverdlin &lt;alexander.sverdlin@nokia.com&gt;
Cc: linux-mips@linux-mips.org
Cc: David Daney &lt;ddaney@cavium.com&gt;
Cc: Rob Herring &lt;robh@kernel.org&gt;
Cc: Jiri Kosina &lt;jkosina@suse.cz&gt;
Cc: Randy Dunlap &lt;rdunlap@infradead.org&gt;
Cc: Masanari Iida &lt;standby24x7@gmail.com&gt;
Cc: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Cc: Mathias &lt;mathias.rulf@nokia.com&gt;
Patchwork: https://patchwork.linux-mips.org/patch/9576/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: asm: asm-eva: Introduce kernel load/store variants</title>
<updated>2015-05-17T23:11:51+00:00</updated>
<author>
<name>Markos Chandras</name>
<email>markos.chandras@imgtec.com</email>
</author>
<published>2015-03-09T14:54:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=301080ae27c98e8530f6820b29d38f8c6f027a81'/>
<id>301080ae27c98e8530f6820b29d38f8c6f027a81</id>
<content type='text'>
[ Upstream commit 60cd7e08e453bc6828ac4b539f949e4acd80f143 ]

Introduce new macros for kernel load/store variants which will be
used to perform regular kernel space load/store operations in EVA
mode.

Signed-off-by: Markos Chandras &lt;markos.chandras@imgtec.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # v3.15+
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/9500/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 60cd7e08e453bc6828ac4b539f949e4acd80f143 ]

Introduce new macros for kernel load/store variants which will be
used to perform regular kernel space load/store operations in EVA
mode.

Signed-off-by: Markos Chandras &lt;markos.chandras@imgtec.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # v3.15+
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/9500/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: lose_fpu(): Disable FPU when MSA enabled</title>
<updated>2015-05-17T23:11:51+00:00</updated>
<author>
<name>James Hogan</name>
<email>james.hogan@imgtec.com</email>
</author>
<published>2015-02-25T13:08:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=00f1187a9cb84924936a4b6310e36be2ad0e8a15'/>
<id>00f1187a9cb84924936a4b6310e36be2ad0e8a15</id>
<content type='text'>
[ Upstream commit f8483988cadd7dd22de928db29ed3bcbe02faf78 ]

The lose_fpu() function only disables the FPU in CP0_Status.CU1 if the
FPU is in use and MSA isn't enabled.

This isn't necessarily a problem because KSTK_STATUS(current), the
version of CP0_Status stored on the kernel stack on entry from user
mode, does always get updated and gets restored when returning to user
mode, but I don't think it was intended, and it is inconsistent with the
case of only the FPU being in use. Sometimes leaving the FPU enabled may
also mask kernel bugs where FPU operations are executed when the FPU
might not be enabled.

So lets disable the FPU in the MSA case too.

Fixes: 33c771ba5c5d ("MIPS: save/disable MSA in lose_fpu")
Signed-off-by: James Hogan &lt;james.hogan@imgtec.com&gt;
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: Paul Burton &lt;paul.burton@imgtec.com&gt;
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/9323/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit f8483988cadd7dd22de928db29ed3bcbe02faf78 ]

The lose_fpu() function only disables the FPU in CP0_Status.CU1 if the
FPU is in use and MSA isn't enabled.

This isn't necessarily a problem because KSTK_STATUS(current), the
version of CP0_Status stored on the kernel stack on entry from user
mode, does always get updated and gets restored when returning to user
mode, but I don't think it was intended, and it is inconsistent with the
case of only the FPU being in use. Sometimes leaving the FPU enabled may
also mask kernel bugs where FPU operations are executed when the FPU
might not be enabled.

So lets disable the FPU in the MSA case too.

Fixes: 33c771ba5c5d ("MIPS: save/disable MSA in lose_fpu")
Signed-off-by: James Hogan &lt;james.hogan@imgtec.com&gt;
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: Paul Burton &lt;paul.burton@imgtec.com&gt;
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/9323/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: KVM: Handle MSA Disabled exceptions from guest</title>
<updated>2015-05-17T23:11:50+00:00</updated>
<author>
<name>James Hogan</name>
<email>james.hogan@imgtec.com</email>
</author>
<published>2015-02-06T11:11:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=707ff2258e57b45383f402e010dc3c5115e0a835'/>
<id>707ff2258e57b45383f402e010dc3c5115e0a835</id>
<content type='text'>
[ Upstream commit 98119ad53376885819d93dfb8737b6a9a61ca0ba ]

Guest user mode can generate a guest MSA Disabled exception on an MSA
capable core by simply trying to execute an MSA instruction. Since this
exception is unknown to KVM it will be passed on to the guest kernel.
However guest Linux kernels prior to v3.15 do not set up an exception
handler for the MSA Disabled exception as they don't support any MSA
capable cores. This results in a guest OS panic.

Since an older processor ID may be being emulated, and MSA support is
not advertised to the guest, the correct behaviour is to generate a
Reserved Instruction exception in the guest kernel so it can send the
guest process an illegal instruction signal (SIGILL), as would happen
with a non-MSA-capable core.

Fix this as minimally as reasonably possible by preventing
kvm_mips_check_privilege() from relaying MSA Disabled exceptions from
guest user mode to the guest kernel, and handling the MSA Disabled
exception by emulating a Reserved Instruction exception in the guest,
via a new handle_msa_disabled() KVM callback.

Signed-off-by: James Hogan &lt;james.hogan@imgtec.com&gt;
Cc: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
Cc: Paul Burton &lt;paul.burton@imgtec.com&gt;
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: Gleb Natapov &lt;gleb@kernel.org&gt;
Cc: linux-mips@linux-mips.org
Cc: kvm@vger.kernel.org
Cc: &lt;stable@vger.kernel.org&gt; # v3.15+
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 98119ad53376885819d93dfb8737b6a9a61ca0ba ]

Guest user mode can generate a guest MSA Disabled exception on an MSA
capable core by simply trying to execute an MSA instruction. Since this
exception is unknown to KVM it will be passed on to the guest kernel.
However guest Linux kernels prior to v3.15 do not set up an exception
handler for the MSA Disabled exception as they don't support any MSA
capable cores. This results in a guest OS panic.

Since an older processor ID may be being emulated, and MSA support is
not advertised to the guest, the correct behaviour is to generate a
Reserved Instruction exception in the guest kernel so it can send the
guest process an illegal instruction signal (SIGILL), as would happen
with a non-MSA-capable core.

Fix this as minimally as reasonably possible by preventing
kvm_mips_check_privilege() from relaying MSA Disabled exceptions from
guest user mode to the guest kernel, and handling the MSA Disabled
exception by emulating a Reserved Instruction exception in the guest,
via a new handle_msa_disabled() KVM callback.

Signed-off-by: James Hogan &lt;james.hogan@imgtec.com&gt;
Cc: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
Cc: Paul Burton &lt;paul.burton@imgtec.com&gt;
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: Gleb Natapov &lt;gleb@kernel.org&gt;
Cc: linux-mips@linux-mips.org
Cc: kvm@vger.kernel.org
Cc: &lt;stable@vger.kernel.org&gt; # v3.15+
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: HTW: Prevent accidental HTW start due to nested htw_{start, stop}</title>
<updated>2015-03-06T22:53:01+00:00</updated>
<author>
<name>Markos Chandras</name>
<email>markos.chandras@imgtec.com</email>
</author>
<published>2015-01-26T13:04:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=09f2e748e02e8133c3effdba371b1dd20a16015d'/>
<id>09f2e748e02e8133c3effdba371b1dd20a16015d</id>
<content type='text'>
commit ed4cbc81addbc076b016c5b979fd1a02f0897f0a upstream.

activate_mm() and switch_mm() call get_new_mmu_context() which in turn
can enable the HTW before the entryhi is changed with the new ASID.
Since the latter will enable the HTW in local_flush_tlb_all(),
then there is a small timing window where the HTW is running with the
new ASID but with an old pgd since the TLBMISS_HANDLER_SETUP_PGD
hasn't assigned a new one yet. In order to prevent that, we introduce a
simple htw counter to avoid starting HTW accidentally due to nested
htw_{start,stop}() sequences. Moreover, since various IPI calls can
enforce TLB flushing operations on a different core, such an operation
may interrupt another htw_{stop,start} in progress leading inconsistent
updates of the htw_seq variable. In order to avoid that, we disable the
interrupts whenever we update that variable.

Signed-off-by: Markos Chandras &lt;markos.chandras@imgtec.com&gt;
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/9118/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.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 ed4cbc81addbc076b016c5b979fd1a02f0897f0a upstream.

activate_mm() and switch_mm() call get_new_mmu_context() which in turn
can enable the HTW before the entryhi is changed with the new ASID.
Since the latter will enable the HTW in local_flush_tlb_all(),
then there is a small timing window where the HTW is running with the
new ASID but with an old pgd since the TLBMISS_HANDLER_SETUP_PGD
hasn't assigned a new one yet. In order to prevent that, we introduce a
simple htw counter to avoid starting HTW accidentally due to nested
htw_{start,stop}() sequences. Moreover, since various IPI calls can
enforce TLB flushing operations on a different core, such an operation
may interrupt another htw_{stop,start} in progress leading inconsistent
updates of the htw_seq variable. In order to avoid that, we disable the
interrupts whenever we update that variable.

Signed-off-by: Markos Chandras &lt;markos.chandras@imgtec.com&gt;
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/9118/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: asm: pgtable: Prevent HTW race when updating PTEs</title>
<updated>2015-03-06T22:52:55+00:00</updated>
<author>
<name>Markos Chandras</name>
<email>markos.chandras@imgtec.com</email>
</author>
<published>2015-01-26T09:40:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e3201ff0eeeef367dcd8d5fafbcab180df5b4e76'/>
<id>e3201ff0eeeef367dcd8d5fafbcab180df5b4e76</id>
<content type='text'>
commit fde3538a8a711aedf1173ecb2d45aed868f51c97 upstream.

Whenever we modify a page table entry, we need to ensure that the HTW
will not fetch a stable entry. And for that to happen we need to ensure
that HTW is stopped before we modify the said entry otherwise the HTW
may already be in the process of reading that entry and fetching the
old information. As a result of which, we replace the htw_reset() calls
with htw_{stop,start} in more appropriate places. This also removes the
remaining users of htw_reset() and as a result we drop that macro

Signed-off-by: Markos Chandras &lt;markos.chandras@imgtec.com&gt;
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/9116/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.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 fde3538a8a711aedf1173ecb2d45aed868f51c97 upstream.

Whenever we modify a page table entry, we need to ensure that the HTW
will not fetch a stable entry. And for that to happen we need to ensure
that HTW is stopped before we modify the said entry otherwise the HTW
may already be in the process of reading that entry and fetching the
old information. As a result of which, we replace the htw_reset() calls
with htw_{stop,start} in more appropriate places. This also removes the
remaining users of htw_reset() and as a result we drop that macro

Signed-off-by: Markos Chandras &lt;markos.chandras@imgtec.com&gt;
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/9116/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
</feed>
